30092-S05-PRESENTACION - July Luo

Vista previa del material en texto

SESIÓN /5
MODELO CONCEPTUAL Y EL MODELO LÓGICO
/ TRANSFORMACIÓN DEL MODELO CONCEPTUAL AL MODELO LÓGICO
/ REGLAS DE TRANSFORMACIÓN
/ ENTIDAD INDEPENDIENTE Y DEPENDIENTE
/ EJERCICIO DE DISEÑO LÓGICO
NOMBRE DEL CURSO  SESIÓN XX
© ISIL. Todos los derechos reservados
1
/ INTRODUCCIÓN
En esta sesión desarrollaremos las Reglas de transformación para pasar del modelo conceptual al modelo lógico
NOMBRE DEL CURSO  SESIÓN XX
© 2018 ISIL. Todos los derechos reservados
TRANSFORMACIÓN DEL MODELO CONCEPTUAL AL MODELO LÓGICO
NOMBRE DEL CURSO  SESIÓN XX
© 2018 ISIL. Todos los derechos reservados
3
Para obtener el esquema lógico de base de datos, en primer lugar se debe tener a la mano el esquema conceptual de base de datos.
En segundo lugar se debe seleccionar el modelo lógico a utilizar
Finalmente se aplicar las reglas de transformación que a continuación se detallan.
/ TRANSFORMACIÓN DEL MODELO CONCEPTUAL AL MODELO LÓGICO
Haga clic para modificar el estilo de título del patrón
En el curso utilizamos el modelo lógico Relacional explicado anteriormente.
Al elegir un tipo de modelo lógico, se está eligiendo en realidad una Tecnología, que en nuestro caso es la Tecnología del Modelo Relacional de CODD.
4
Conceptual
Lógico
3 reglas de transformación
Simple
No técnico
Orientado al usuario
Completo
Lenguaje técnico
Neutro al sistema de base de datos
/ TRANSFORMACIÓN DEL MODELO CONCEPTUAL AL MODELO LÓGICO
Haga clic para modificar el estilo de título del patrón
REGLAS DE TRANSFORMACIÓN
NOMBRE DEL CURSO  SESIÓN XX
© 2018 ISIL. Todos los derechos reservados
6
REGLA 1
Toda entidad se convierte en una tabla que toma el nombre de la entidad. Los atributos de la entidad serán las columnas de la tabla y el atributo identificador principal será la clave primaria. 
/ REGLAS DE TRANSFORMACIÓN
Haga clic para modificar el estilo de título del patrón
A menos que se indique lo contrario los atributos no identificadores podrán tomar valores nulos.
7
REGLA 2: Relación No Identificadora
Las interrelaciones 1 : M ó 1 : 1 se transforman propagando el atributo identificador principal (PK) de la entidad que tiene cardinalidad máxima 1 a la que tiene cardinalidad máxima M (FK). Si la relación fuese 1:1 la propagación de clave podría hacerse en cualquier sentido.
/ REGLAS DE TRANSFORMACIÓN
Haga clic para modificar el estilo de título del patrón
El atributo propagado es una Clave Foránea que referencia a la tabla con cardinalidad máxima de 1.
A la Entidad que tiene Cardinalidad 1 en esta relación se la suele denominar Entidad Padre, y a la entidad que tiene el lado de la cardinalidad Muchos, se le denomina Entidad Hija.
El atributo que se propaga a la entidad hija se le llama Clave Foránea, y está ubicado junto con los atributos comunes de la Tabla.
8
Relación de uno a muchos (1:M)
Ejemplos:
/ REGLAS DE TRANSFORMACIÓN
Haga clic para modificar el estilo de título del patrón
La cardinalidad encontrada en esta relación obedece a las reglas de negocio de la realidad donde coexisten estas entidades.
Por ejemplo, un cliente puede tener una o muchas facturas.
Un cliente para ser cliente, tiene que tener registrada por lo menos una factura de una compra que realizó, quiere decir, que no podrán existir clientes sin factura.
Una factura sólo le pertenece a un cliente, no puede existir una factura que le pertenezca a varios clientes.
Una factura necesariamente le pertenece a un cliente, quiere decir, que no podría existir una factura que no le pertenezca a ningún cliente. 
El resultado, es que tenemos una relación de uno a muchos. Esta relación, se iba a transformar en el modelo lógico, de la siguiente manera:
A la entidad con cardinalidad uno, se le denomina, Entidad Padre, y a la entidad que tienen la cardinalidad de muchos, se le denomina Entidad Hija.
9
Relación No Identificadora
Los atributos identificadores se transforman en Claves Primarias (PK)
Las claves primarias se propagan desde la cardinalidad 1 hacia la cardinalidad M como llaves foráneas (FK)
La relación de cardinalidad de uno a muchos se transforma en una relación No Identificadora porque el atributo propagado NO es PK en la tabla de destino.
Se grafica con línea discontinua. Del lado de la cardinalidad M se incluye la “pata de gallo”
/ REGLAS DE TRANSFORMACIÓN
Haga clic para modificar el estilo de título del patrón
El atributo identificador de la entidad hija en el modelo conceptual, se transforma en clave primaria en el modelo lógico.
En la entidad hija, se transmite la clave primaria de la entidad Padre como clave foránea, resultando una relación llamada No Identificadora.
La llave foránea que se crea en la entidad hija, normalmente se le asigna el mismo nombre que tiene la clave primaria en Entidad Padre, aunque eso no es una regla obligatoria, podría asignarle a la clave foránea en Entidad hija un nombre diferente, pero, lo que sí es obligatorio es que la clave foránea tenga el mismo dominio que el que tiene la clave primaria en la entidad Padre.
10
REGLA 3. Relación Identificadora 
Las interrelaciones M:M se transforman en una tabla cuya clave primaria será la concatenación de los atributos principales de las entidades que se asocia; estos atributos serán claves Foráneas que referencian a las respectivas tablas donde son claves primarias. 
/ REGLAS DE TRANSFORMACIÓN
Haga clic para modificar el estilo de título del patrón
Los atributos de la interrelación serán columnas de la tabla.
La tabla intermedia que se incluye entre ambas entidades que tienen la cardinalidad de N.M (de muchos a muchos) resuelve la anomalía de muchos a muchos, en el modelo lógico relacional, ya que el modelo de Codd no se admiten relaciones de muchos a muchos, por que no se puede representar en dos dimensiones (en el modelo de Codd las estructuras son planas).
El atributo que se propaga a la entidad hija se le llama Clave Foránea, y está ubicado en la parte superior de la tabla formando parte de la Clave primaria de la tabla hija. 
11
Relación de muchos a muchos (M:M)
Ejemplo:
/ REGLAS DE TRANSFORMACIÓN
Haga clic para modificar el estilo de título del patrón
En este caso la cardinalidad resultante es debido a las reglas de negocio especificado siguiente:
Un producto podrá estar incluido en una o muchas facturas, inclusive, podría existir un producto que nunca sería vendido.
Una factura puede incluir a uno o muchos productos, pero no podría existir una factura donde no se considere ningún producto.
Esta cardinalidad resultante de muchos a muchos es una anomalía en el modelo lógico relacional, luego esta anomalía se resuelve incluyendo una entidad intermedia entre las dos entidades.
12
Relación Identificadora
Los atributos identificadores se transforman en Claves Primarias (PK)
Se crea una nueva tabla graficada con bordes redondeados.
La relación de cardinalidad de muchos a muchos se transforma en una relación Identificadora porque la entidad intermedia se compone por las PK’s de las otras dos, las cuales pasan a la entidad intermedia como claves foráneas (FK).
Se grafica con línea continua. Del lado de la nueva tabla se incluye la “pata de gallo” .
/ REGLAS DE TRANSFORMACIÓN
Haga clic para modificar el estilo de título del patrón
Esta entidad intermedia, tiene una clave primaria compuesta, formada por las claves primarias de las otras dos entidades que pasan como foráneas.
Las relaciones resultantes son del tipo conocida como Relación Identificadora.
La relación Identificadora, siempre parte de la clave primaria con cardinalidad uno, y a su llave foránea, con la cardinalidad correspondiente al cómo llega desde la entidad primera a la segunda en el modelo conceptual.
13
La relación de cardinalidad de muchos a muchos se transforma en una relación Identificadora.
Entre las dos entidades iniciales se grafica una entidad intermedia cuya PK está conformada por las PKs de las otras dos.
La PK de la nueva entidad intermedia se compone por las PK’s de las otras dos, las cuales pasan a la entidad intermedia como Claves Foráneas(FK).
La relación Identificadora se grafica con línea continua.
/ REGLAS DE TRANSFORMACIÓN
Haga clic para modificar el estilo de título del patrón
En una relación y Identificadora, la cardinalidad desde la Entidad Padre, siempre es uno. Por ejemplo, a un detalle de factura le corresponde siempre a una factura, en otras palabras, no podría existir un detalle de factura sin factura relacionada. Respeta el líder rebelde
14
	REGLA	Resumen	Cardinalidad	Tipo de línea
	1	Entidad  Tabla
Atributo  Campo	N/A	N/A
	2	PK se propaga  FK	1:1
1:M
M:1	Discontinua
	3	Se convierte en tabla
PK se propaga  FK / PK	M:M	Continua
/ REGLAS DE TRANSFORMACIÓN
Haga clic para modificar el estilo de título del patrón
ENTIDAD INDEPENDIENTE Y DEPENDIENTE
NOMBRE DEL CURSO  SESIÓN XX
© 2018 ISIL. Todos los derechos reservados
16
Entidad independiente
Una entidad cuyas instancias pueden ser identificadas unívocamente sin necesidad de determinar su relación con otra entidad. Tiene existencia propia.
A una entidad independiente también se la conoce como Entidad Fuerte ó Entidad Regular, la cual tiene atributos propios, además de aquellos necesarios para establecer asociaciones y que tiene entidades asociadas cuyas ocurrencias dependen de la existencia de ciertas ocurrencias en ella.
/ ENTIDAD INDEPENDIENTE Y DEPENDIENTE
Haga clic para modificar el estilo de título del patrón
Son aquellas que existen por sí mismas y que la existencia de una instancia o ejemplar en la entidad no depende de la existencia de otras instancias en otra entidad. La representación gráfica dentro del diagrama es mediante un rectángulo.
17
Entidad dependiente
Una entidad cuyas instancias no pueden ser identificadas unívocamente sin que se haya determinado su relación con otra entidad o entidades. No tiene existencia propia, su existencia depende de la existencia de otra u otras entidades Independientes.
A una Entidad Dependiente también se la conoce como Entidad Débil, la cual tiene atributos que le permiten establecer asociaciones con otras entidades y cuyas instancias dependen de la existencia de otras instancias de una entidad fuerte asociada.
/ ENTIDAD INDEPENDIENTE Y DEPENDIENTE
Haga clic para modificar el estilo de título del patrón
Toda entidad débil incorpora una relación implícita con una entidad fuerte. Esta relación
no necesita incorporarse como tabla en el modelo relacional. Sí se necesita incorporar la
clave de la entidad fuerte como clave externa en la entidad débil. Es más, normalmente esa
clave externa forma parte de la clave principal de la tabla que representa a la entidad débil.
En ocasiones el identificador de la entidad débil es suficiente para identificar los
ejemplares de dicha entidad, entonces ese identificador quedaría como clave principal,
pero el identificador de la entidad fuerte seguiría figurando como clave externa en la
entidad débil.
18
Como ejemplo de entidad dependiente tenemos a la entidad BLOQUE ó sección; un bloque ó sección de un CURSO no puede existir si el curso no existe.
Hay distintas maneras de representar gráficamente los elementos de un modelo de datos. Aquí utilizaremos la notación IE (Information Engineering). 
En la notación IE, una entidad dependiente se representa mediante un rectángulo de esquinas redondeadas y una línea que la une a la entidad de la que depende.
/ ENTIDAD INDEPENDIENTE Y DEPENDIENTE
Haga clic para modificar el estilo de título del patrón
 
Uno de los problemas que existirán en el diseño E/R es la decisión de si un determinado objeto o concepto se modela como un tipo de entidad o no. Por ejemplo, el color es habitualmente una propiedad de una entidad (como es el caso del color de un coche), pero en una fábrica de pinturas probablemente sería apropiado modelar el color como una entidad con sus propias propiedades.
 
Por esta razón, algunos autores han intentado precisar el concepto de entidad. Lo que debe cumplir una entidad es. 
Tiene que tener existencia propia.
Cada instancia de un tipo de entidad debe poder distinguirse de las demás.
Todos los ejemplares de un tipo de entidad deben tener las mismas propiedades.
 Como se puede observar por la propia definición, las entidades débiles nunca cumplirán la primera regla.
Un ejemplo de entidad débil sería EJEMPLAR, ya que la existencia de una instancia depende de la existencia del LIBRO, y por tanto, la desaparición de un determinado libro de la base de datos hace que desaparezcan todas las instancias de dicho libro. 
19
EJERCICIO DE DISEÑO LÓGICO
NOMBRE DEL CURSO  SESIÓN XX
© 2018 ISIL. Todos los derechos reservados
20
Se desea diseñar una base de datos que guarde la información de las reservas de una empresa dedicada al alquiler de automóviles. Los supuestos semánticos son los siguientes:
 
1. Un determinado cliente puede tener en un momento dado varias reservas.
2. Una reserva la realiza un único cliente, pero puede involucrar a varios coches.
3. Es importante registrar la fecha de comienzo de la reserva y la de terminación.
4. Todo coche tiene siempre asignado un número determinado de garaje, que no puede cambiar.
5. Cada reserva se realiza en una determinada agencia.
6. En la base de datos pueden existir clientes que no hayan hecho ninguna reserva.
7. Todas las entidades tienen una clave alfanumérica que las identifica unívocamente.
 
En base a lo enumerado, realiza el diseño Conceptual y Lógico, e indica aquellos supuestos que no se han considerado.
/ EJERCICIO DE DISEÑO LÓGICO
Haga clic para modificar el estilo de título del patrón
Primero descubre las entidades aplicando los conceptos revisados anteriormente. Luego relaciona las entidades resultantes, teniendo en cuenta el comportamiento de dichas entidades en el contexto de esta realidad. Por ejemplo un cliente no podría acercarse a un garaje y llevarse un auto, el encargado le diría que le presente su documento de reserva, tampoco podría ser la reserva en garaje, ni menos pagarle al encargado del garaje. Lo que tiene que ser el cliente es acercarse a una agencia y hacer sus trámites de reserva. Esto también podría causar alguna duda, el cliente primero se relaciona con agencia y luego se relaciona con la reserva?. Pues esta duda queda resuelta cuando se hace la siguiente pregunta ¿el que un cliente se acerque a una agencia asegura el proceso del alquiler? Pues no es así, ya que el cliente podría acercarse a la agencia, realizar muchas preguntas, y finalmente retirarse sin haber alquilado nada. Luego para que el proceso de alquiler se de es necesario que el cliente realice una reserva. Luego la entidad cliente primero se relaciona con la entidad reserva. 
21
Modelo Conceptual
/ EJERCICIO DE DISEÑO LÓGICO
Haga clic para modificar el estilo de título del patrón
Se verifican la existencia de cinco entidades comprobando que hay varias instancias y además tiene varios atributos.
Para que un cliente pueda alquilar un coche, primero tiene que realizar una reserva. 
En la reserva se incluyen los coches que se van a alquilar.
Una reserva de tramitar una agencia, lo cual es una oficina donde sólo se realiza dicho trámite.
Cada coche está asignado a un garaje.
Como podemos observar estas reglas de negocio tienen como resultado el diagrama anterior.
Para establecer las Cardinalidades, realizamos en los siguientes pasos.
Entre cliente y reserva:
Un cliente puede hacer una o muchas reservas, aunque también, puede existir un cliente que no haya realizado ninguna reserva. En sentido inverso una reserva sola la realiza un solo cliente, además, para que existe una reserva tiene que haberla hecho un cliente necesariamente.
Cardinalidad entre reserva y coche:
Una reserva puede incluir un coche o varios coches, pero no puede existir una reserva de sin que haya considerado un coche. Por otro lado, un coche puede estar incluido en una o muchas reservas, esto quiere decir, que un coche se puede alquilar muchas veces, por supuesto en tiempos diferentes. Inclusive, podría existir un coche que no esté incluido en ninguna reserva, esto quiere decir que nuncase ha alquilado dicho coche, este es el caso de un coche nuevo.
Cardinalidad entrar reserva y agencia:
En una agencia se pueden tramitar una o muchas reservas, pero también puede darse el caso de una agencia donde no se haya tramitado ninguna reserva, este es el caso, de una agencia nueva. Por otro lado una reserva necesariamente tiene que permitan hacer ninguna agencia, y sólo en una, no puede darse el caso de una reserva que se haya tramitado en dos agencias al mismo tiempo.
En el caso del coche con garaje:
En un garaje se pueden asignar uno o muchos coches, todo depende de la capacidad de dicho garaje, inclusive podría darse el caso de un garaje nuevo al cual no se le ha asignado ningún coche aun. Por otro lado todo coche al momento de registrarse, se le pide que asignar obligatoriamente un garaje y sólo uno. No puede existir un coche que no tenga garaje asignado.
De esta manera construir nos el diagrama de esta diapositiva, quedando como tarea culminarlo incluyendo los atributos de cada entidad. Considerar dos o tres atributos como máximo, subrayar el atributos identificador de cada entidad correspondiente.
22
Transformando al Modelo Lógico
/ EJERCICIO DE DISEÑO LÓGICO
Haga clic para modificar el estilo de título del patrón
La relación entre CLIENTE y RESERVA era de uno a muchos; esta relación se transformo en una relación No Identificadora, La entidad que tiene el lado uno de la cardinalidad se conoce como Entidad Padre, y la que tiene el lado de muchos se le conoce como Entidad Hija.
La entidad Padre le transmite su Clave primaria como clave Foránea a la Entidad hija. Este verifica que hay que hay un cero en el lado de reserva, ya que un cliente puede que no tenga ninguna reserva aun.
Algo similar pasa en la relación agencia reserva agencia es Padre y reserva es hija, luego la clave primaria de agencia se trasmite como foránea a la entidad hija reserva, también vemos que podría existir una agencia donde todavía no se ha hecho ninguna reserva (agencia nueva), por eso hay un cero en el lado de la cardinalidad en la entidad reserva. 
En el caso de la relación entre reserva y coche, se observa que hay una relación de muchos a muchos, lo que trae como consecuencia incluir una entidad intermedia que solucione esta anomalía de muchos a muchos, está entidad intermedia forma su clave primaria con las claves primarias de las otras dos entidades, reserva y coche, las cuales pasan a la entidad intermedia en la parte superior como foráneas, conformando en conjunto una clave primaria compuesta. Al encontrarse las claves foráneas en la parte superior de la entidad, denotan una relación Identificadora. Las Cardinalidades se trasladan del modelo conceptual al modelo lógico según la llegada de la cardinalidad en la entidad opuesta. En el caso de reserva hacia coche la llegada de uno a muchos por eso en el modelo lógico la cardinalidad que llega desde reserva a la entidad intermedia es de uno a muchos. En el caso contrario la cardinalidad del coche a reserva en el modelo conceptual llega con cero, uno o muchos, por eso en el modelo lógico la cardinalidad de llegada de coche a la entidad intermedia es de cero, uno o muchos.
En este caso particular a la entidad intermedia feria denominado detalle_reserva, debido a que en esta entidad se podrá detallar el precio de alquiler de cada uno de los autos por ejemplo que se alquiló en una reserva determinada.
23
El objetivo de esta sesión fue conocer como pasar del Modelo Conceptual al Modelo Lógico Relacional.
Una relación de uno a muchos conlleva a una relación no identificadora.
Una relación de muchos a muchos conlleva a relaciones identificadoras.
En una relación no identificadora la llave foránea forma parte de los atributos comunes en la entidad hija, y por el contrario en una relación identificadora la clave foránea está formando parte de la clave primaria en entidad hija.
Ahora podrás aplicar estos conocimientos y convenciones de los gráficos usados para diseñar un modelo Lógico, en diferentes realidades.
/ CONCLUSIÓN
Haga clic para modificar el estilo de título del patrón
24