S9 ResumenDiseñoConceptual y GeneraciónEsquemaLógico

Docente: Pamela Cristina Landero Sepúlveda
1
UNIDAD 2: MODELAMIENTO
GENERAR UN ESQUEMA LÓGICO (MR) A PARTIR DEL ESQUEMA MER
REPASO ETAPA DE DISEÑO CONCEPTUAL y CONOCER LA ETAPA DISEÑO LÓGICO
Para diseñar una base de datos, recuerde que se generan 3 esquemas que dependen de la etapa de diseño
en la que estamos. Después de haber terminado con la etapa de diseño conceptual (donde generamos el
esquema conceptual aplicando el modelo conceptual MER), seguimos ahora con la etapa de diseño
lógico.
MER
MR
En la esta etapa de Diseño Lógico tomamos el esquema conceptual con todas sus definiciones y
generamos un ESQUEMA LÓGICO aplicando reglas de transformación de acuerdo con lo que establece
el Modelo Relacional (MR).
La transformación de un esquema MER S1 a su respectivo esquema MR (o lógico) S2, consiste en
transformar las estructuras y las restricciones del esquema conceptual para generar un esquema
lógico con sus respectivas estructuras y restricciones.
Docente: Pamela Cristina Landero Sepúlveda
Docente: Pamela Cristina Landero Sepúlveda
2
Recordemos que las estructuras del esquema conceptual MER son los Tipos de Entidad (TE) y los
Tipos de Relaciones (TR) donde se encuentran organizados los datos (o atributos) de la Base de Datos; y
las restricciones las asociamos a los atributos de cada TE o TR tales como: atributo clave primaria, clave
secundaria, atributo compuesto, derivado, atributo relación, cardinalidades, etc. Para recordar esto,
adjunto parte de la identificación de atributos y restricciones que realizamos en el caso de la empresa que
arrienda maquinaria:
Figura 1: Ejemplo de Parte de la Identificación de atributos organizados en TE y TR y sus restricciones del
caso de una BD para una empresa que arrienda maquinarias
Durante esta etapa de diseño conceptual, después de identificar restricciones para cada dato almacenado
en la base de datos, organizados en TR y TE, realizamos un diagrama MER equivalente. En el ejemplo
consideramos 2 soluciones posibles (registrando historia y sin historia). Se recuerda el esquema MER para
el caso donde no se almacena historia de arriendos para el mismo cliente y máquina (donde se mantiene
la última fecha del arriendo):
Figura 2: Uno de los Esquema MER generado en el Diseño Conceptual para la empresa arriendo de maquinaria
Docente: Pamela Cristina Landero Sepúlveda
Docente: Pamela Cristina Landero Sepúlveda
3
Los datos y cómo se organizan estos datos (en TE o TR), los supuestos del modelado, las restricciones
expresadas en el esquema y otras restricciones no expresadas en el esquema, son necesarias
definirlas (narrativamente), ya que forman parte de los requerimientos de almacenamiento de la base
de datos, por lo tanto, el usuario debe validarlos y formalizarlos oportunamente para que todas estas
decisiones, acuerdos y definiciones reflejen la base de datos que realmente se necesita implementar.
Recuerde también que esta base de datos debe permitir, además, satisfacer los requerimientos de
informes/consultas que los usuarios necesitan para tomar sus decisiones.
A continuación, entrego ejemplos de supuestos, de las restricciones (expresadas y no expresadas en el
esquema) y de algunos requerimientos de informes que se definieron en la base de datos de la figura 2.
SUPUESTOS (decisiones tomadas por el diseñador durante el modelamiento que se deben formalizar y
aclarar con el usuario ya que en muchos casos pueden causar impactos desde un punto de vista
operativo):
a) De los dos atributos que son únicos (rut y celular), se decidió considerar el rut como el atributo
que identifica a cada cliente.
b) Las máquinas se ingresan a la base de datos antes de que sean arrendadas por los clientes, por lo
tanto, en la BD pueden existir máquinas sin estar arrendadas.
c) Los clientes pueden registrarse en esta base de datos sin necesidad de arrendar una maquinaria
en ese mismo momento, es decir, pueden ingresar sus datos personales y después, en otro
momento, arrendar maquinarias, por lo tanto, pueden existir clientes almacenados en esta BD que
nunca han arrendado maquinarias o que nunca lo hagan.
d) Al usuario no le interesa registrar historia de cada uno de los arriendos que realiza un cliente a una
misma máquina. Es decir, la misma ocurrencia cliente-máquina, consistirá en actualizar la fecha
del arriendo previo con la fecha del nuevo arriendo.
e) Esta base de datos no está considerando la devolución, por lo tanto, se asume que la máquina que
se va a arrendar está disponible.
f) En esta base de datos no se almacenan proveedores que podrían abastecernos de maquinarias ya
que es obligatorio que el proveedor haya abastecido al menos una máquina para poder registrarlo
a esta base de datos.
RESTRICCIONES EXPRESADAS EN EL ESQUEMA:
a) Los clientes pueden arrendar varias maquinarias, pero también pueden no arrendar.
b) Las máquinas pueden ser arrendadas por varios clientes, pero también pueden no estar
arrendadas.
c) El código de la máquina es único, ninguna otra máquina puede tenerlo.
d) El RUT del cliente es único, ningún otra cliente puede tenerlo.
e) El cliente (rut) y la máquina (código), en conjunto, son datos únicos para el arriendo, es decir, no
puede existir otro arriendo con el mismo rut-código.
f) etc. (todas las que se identificaron en el análisis de los datos o atributos)
RESTRICCIONES NO EXPRESADAS EN EL ESQUEMA (EJEMPLOS):
a) La edad del cliente se deriva a partir de la fecha de su nacimiento que consiste en calcular la
diferencia entre el año actual con el año de su nacimiento.
b) El teléfono del cliente debe ser mayor a 8 dígitos (>9999999).
Docente: Pamela Cristina Landero Sepúlveda
Docente: Pamela Cristina Landero Sepúlveda
4
c) La fecha de nacimiento de un cliente se ha definido que debe ser mayor a 1-01-1900.
d) La BD no debe recibir un RUT inválido, es decir el DV debe corresponder al rut ingresado.
e) Las fechas de mantención de la máquina son distintas. Cada vez que se ingresa una fecha para una
máquina determinada debe ser mayor a la ingresada previamente.
f) La fecha de arriendo no puede ser menor a la fecha en que se compró la máquina que se está
arrendando.
REQUERIMIENTOS DE CONSULTAS E INFORMES (EJEMPLOS):
a) Ranking con las máquinas más arrendadas.
b) Informe de las máquinas que no han tenido mantenciones para un periodo dado (fecha 1, 2 o 3).
c) Informe de las maquinarias que están arrendadas actualmente con la información de sus clientes.
d) Ranking de los clientes que más han participado de los arriendos.
NOTA:
Se recuerda que la notación que estamos utilizando en las cardinalidades de las
relaciones, es la restricción estructural (no se confunda con otras notaciones donde
usan las cardinalidades cruzadas, que NO es el caso de esta asignatura).
ETAPA DISEÑO LÓGICO:
Después de haber terminado la etapa de Diseño Conceptual con la correcta validación y aceptación (por
parte de los usuarios) del esquema conceptual generado y su documentación, se continúa con la etapa
de diseño lógico que consiste en tomar este esquema conceptual y transformarlo en un esquema
lógico aplicando las reglas de transformación que nos provee el Modelo Relacional (MR).
REGLAS DE GENERACIÓN DE UN ESQUEMA MER A UN ESQUEMA LÓGICO (MR):
I. REGLAS DE GENERACIÓN de Tipos de Entidad (TE) y sus atributos:
1) Un TE se transforma en TABLA (en la literatura, tabla es una relación) y sus atributos se transforman
en columnas. Las columnas se agregan a continuación del nombre de la tabla entre paréntesis y
separadas por “,”. Si un atributo es compuesto, cada composición se transforma en columnas
distintas.
2) Si el atributo de un TE es una relación y tiene cardinalidad (0,1) o (1,1), podría
transformarse en una columna, que sería la clave primaria del TE con el que se
relaciona (columna llamada FK). Agregar o no esta columna FK a la tabla, va a depender de
las siguientes situaciones para cada triada (TE – TR – TE) ya que sólo UNA de las dos TE puede
recibir la FK. Usted debe aplicar la que su esquema MER esté usando:
Docente: Pamela Cristina Landero Sepúlveda
Docente: Pamela Cristina Landero Sepúlveda
SITUACIÓN 1:
5
En esta situación 1, no hay duda de que el TE-1
recibe la FK (PK de TE-2) ya que la cardinalidad
de su atributo relación es (0,1) o (1,1) y el TE con
el que se relaciona tienen cardinalidad máxima
n. La FK es opcional u obligatoria dependiendo de
la cardinalidad mínima (0 o 1) del atributo
relación de TE-1.
SITUACIÓN 2:
En esta situación, el diseñador debe tomar la
decisión de cuál TE (TE- 1 o TE-2) recibe la FK, lo
importante que sólo uno de los TE la reciba. Del
mismo modo, la FK quedará opcional u
obligatoria según corresponda.
SITUACIÓN 3:
En esta última situación, no hay duda de que el
TE que recibe la FK es el TE-2 ya que su atributo
relación es el que tiene la cardinalidad
obligatoria.
Estas situaciones, también se aplican a atributos que son relaciones recursivas (la
FK proviene del mismo TE), donde de igual modo, la misma tabla recibe su columna PK que
también se comporta como FK.
3) Si el atributo de un TE es multivaluado, se transforma en una tabla nueva, cuyas columnas son
la clave primaria del TE (que también se comporta como FK) y el atributo multivaluado. La PK para
esta nueva tabla muchas veces se compone por ambas columnas. Elegir una PK conveniente (según
el tipo de dato del multivaluado).
4) Las restricciones representadas y no representadas en el esquema MER se transforman en:
• PK (PRIMARY KEY): columna(s) del IP del TE (incluye restricción de NOT NULL)
• UK (UNIQUE KEY): columna(s) de la(s) clave(s) secundaria(s) del TE
• FK (FOREIGN KEY): columna(s) que es la restricción de relación entre entidades. Aquí debe indicar
la columna FK y la tabla donde proviene dicha FK.
• NOT NULL: columna(s) cuyo dato es obligatorio.
• CHECK CONSTRAINTS: son restricciones no representadas en el esquema MER que se expresan
en esta etapa de diseño lógico como checks (ejemplo: fecha inicio contrato menor a la fecha fin).
Docente: Pamela Cristina Landero Sepúlveda
Docente: Pamela Cristina Landero Sepúlveda
6
• TRIGGERS: son restricciones no representadas en el esquema MER que no es posible asociarla a
un check. Se expresan en esta etapa de diseño lógico usando pseudocódigo (u otro elemento de
diseño), haciendo énfasis al evento (insert, update o delete) que debe suceder sobre esta tabla
para gatillar la restricción (ejemplo: cuando se inserta una venta se debe actualizar
automáticamente el stock de los productos disminuyéndolo según la cantidad vendida). Estos
triggers son implementados a través de programación de Base de Datos.
5) El TE Débil, se transforma en tabla, del mismo modo que un TE, pero la PK se compone de la clave
primaria interna del TE débil más la clave primaria externa (del TE desde donde proviene la
debilidad), donde esta última también se comporta como FK.
II. REGLAS DE GENERACIÓN de Tipos de Relaciones (TR):
6) Los TR se transforman en TABLAS sólo si todas sus cardinalidades máximas son mayores que 1:
a) Si el TR NO se transforma en tabla y posee atributos (que no son IP), agregue estos atributos
como columnas nuevas, a la tabla donde se encuentra la FK asociada a la relación. Revise la
opcionalidad de esta FK para decidir si las columnas que está agregando son obligatorias o no.
b) Si el TR se transforma en tabla, aplique las reglas 1, 3 y 4 de transformación considerando que
la PK está compuesta por los atributos identificadores de los TE con los que se relaciona y donde
cada una de estas relaciones posee distintas FK.
III. REGLAS DE GENERACIÓN de JERARQUÍAS (Generalización/Especialización):
La transformación va a depender del contexto y del esquema MER completo. El ingeniero (o diseñador de
la base de datos) debe escoger entre tres alternativas que se indican a continuación, considerando la
existencia o no de relaciones en el supertipo y/o subtipos y de la cobertura (total/parcial,
exclusiva/superpuesta) entre el supertipo con sus subtipos.
Sería ideal tener los datos en una sola tabla (en el SUPERTIPO) o generar el menor número de tablas,
pero existen circunstancias en que esto no es posible.
Docente: Pamela Cristina Landero Sepúlveda
Docente: Pamela Cristina Landero Sepúlveda
7
Las tres alternativas de transformación y algunas sugerencias para tomar la mejor decisión se exponen a
continuación:
7) CASO 1: Generar SÓLO el SUPERTIPO y eliminar los subtipos.
Recomendaciones sugeridas para tomar esta decisión:
a) Si la cobertura es (t,e) o (p,e) y:
• si los subtipos no tienen relaciones, esta alternativa es muy conveniente.
• si los subtipos tienen relaciones pero todos reciben las FK(s) correspondiente(s), puede
elegir esta alternativa considerando las restricciones que controlen los datos de estas FKs,
en caso contrario (al menos un subtipo no recibe la FK correspondiente), no es una
alternativa conveniente.
• si los subtipos tienen muchas relaciones que involucre crear varias restricciones para
controlar los datos de las Fks, es mejor que no tome esta opción.
b) Si la cobertura es superpuesta NO tome esta alternativa en ningún caso.
REGLAS DE GENERACIÓN para esta alternativa:
a) Agregue una columna “tipo” cuyo valor indica el subtipo que posee cada instancia. Asocie un
CHECK a esta columna “tipo” indicando los valores posibles asignados.
b) Las columnas de los subtipos se traspasan al supertipo y se agregan los CHECKS para que los
valores de dichas columnas sean distintas de nulo dependiendo del “tipo” de cada instancia.
c) Las relaciones de los subtipos (donde TODAS deben recibir la(s) FK(s) correspondiente(s)), se
traspasan al supertipo, agregando las FKs y sus respectivos CHECKs para controlar los datos de
estas FKs en base a cuál subtipo pertenece cada relación.
8) CASO 2: Generar los SUBTIPOS y eliminar el supertipo.
Recomendaciones sugeridas para tomar esta decisión:
a) Se sugiere tomar esta alternativa si la alternativa 1 no es factible de aplicar.
b) Para todos los casos de cobertura (t,e), (p,e), (t,s) y (p,s):
• si el supertipo no tiene relaciones, esta alternativa es muy conveniente, considerando que
para la cobertura parcial se puede agregar un subtipo “OTRO” para que todas las instancias
del supertipo estén presentes en los subtipos.
• si el supertipo tiene relaciones pero todas reciben las FK(s) correspondiente(s), puede
elegir esta alternativa, agregando todas las Fks en cada uno de los subtipos, en caso
contrario (al menos una relación del supertipo no recibe la FK correspondiente), no es una
alternativa conveniente.
REGLAS DE GENERACIÓN para esta alternativa:
a) Cada uno de los subtipos recibe las columnas que tiene el SUPERTIPO.
b) Transformar cada subtipo como TE independiente (aplique reglas 1 a la 4 para cada uno).
c) Las relaciones del supertipo (donde TODAS deben recibir la FK correspondiente), se traspasan
a cada uno de los subtipos agregando las FKs correspondientes a cada uno.
Docente: Pamela Cristina Landero Sepúlveda
Docente: Pamela Cristina Landero Sepúlveda
8
9) CASO 3: Generar el SUPERTIPO y los SUBTIPOS.
Recomendaciones sugeridas para tomar esta decisión:
a) Es una alternativa que puede tomar en todos los casos, pero se sugiere que la tome cuando las
alternativas 1 y 2 no son factibles o ambas son muy complejas de aplicar (demasiadas
restricciones para controlar los datos de las Fk(s)).
REGLAS DE TRANSFORMACIÓN para esta alternativa:
a) Transformar el supertipo y los subtipos de manera independiente donde cada uno de los
subtipos recibe sólo la PK del supertipo que se comporta también como FK.
GENERAR ESQUEMA LÓGICO PARA EL EJEMPLO DE LA FIGURA 2:
Ahora vamos a generar el esquema lógico de la figura 2, a partir de su esquema conceptual junto con sus
restricciones (representas y no representadas en el esquema) que fueron documentadas:
Se sugiere primero aplicar las reglas para cada TE con todos sus atributos (incluidos los atributos
relaciones) y al final transformar los TR.
Aplicando las reglas 1, 2 y 4 para el TE CLIENTE, su tabla no recibe FK porque no cumple con las
condiciones indicadas en la regla 2; las restricciones representadas en el esquema conceptual se
generaron en PK, UK, FK y NOT NULL; del mismo modo, las restricciones no representadas en el esquema
conceptual se generaron en CHECK y TRIGGER de base de datos.
Del mismo modo, se aplicaron las reglas para el TE MAQUINARIA, pero adicionalmente, al aplicar la regla
2 (con situación 1) su tabla recibe la FK prov_codigoProv; por otro lado, aplicando la regla 3 (para
atributos multivaluados) se genera una tabla adicional que llamamos FECHAS_MANT_MAQUINARIA.
El TR arrienda se transformó en tabla, aplicando la regla 6 b); y al aplicar la regla 6 a) para el TR provee,
se agrega la columna fechaProvee a MAQUINARIAS. Y así sucesivamente, por lo tanto, el esquema lógico
generado queda de la siguiente forma:
Docente: Pamela Cristina Landero Sepúlveda
Docente: Pamela Cristina Landero Sepúlveda
9
CLIENTES (rut, nombre, apellido, calle, numero, comuna, fechaNacimiento, edad, celular)
PK: rut
UK1: celular
FK: ---NOT NULL: nombre, apellido, calle, numero, comuna, fechaNacimiento, edad, celular
CHECK1: numero > 0
CHECK2: edad > 18
CHECK3: celular > 9999999
CHECK4: fechaNacimiento > 1-01-1900
TRIGGER1: al insertar un cliente, gatillar el procedimiento que valida el DV del rut.
TRIGGER2: al insertar y modificar un cliente gatillar, el procedimiento que calcula la edad.
MAQUINARIAS (codigoMaq, nombre, descripción, prov_codigoProv, fechaProvee)
PK: codigoMaq
UK1: ---FK1: prov_codigoProv referencia a PROVEEDORES
NOT NULL: nombre, descripción, prov_codigoProv, fechaProvee
CHECK1: codigoMaq > 0
FECHAS_MANT_MAQUINARIA (maq_codigoMaq, fechaMantencion)
PK: maq_codigoMaq, fechaMantencion
UK1: ---FK1: maq_codigoMaq referencia a MAQUINARIAS
NOT NULL: --CHECK1: ---TRIGGER1: al insertar una fecha de mantención de la máquina, gatillar el procedimiento que valide si la fecha
ingresada es menor a la fecha de la mantención previa si corresponde.
PROVEEDORES (codigoProv, nombre)
PK: codigoProv
UK1: ---FK1: ---NOT NULL: nombre
CHECK1: codigoProv > 0
ARRIENDOS (cli_rut, maq_codigoMaq, fechaArriendo)
PK: cli_rut,maq codigoMaq
UK1: ---FK1: cli_rut referencia a CLIENTES
FK1: cod_codigoMaq referencia a MAQUINARIAS
NOT NULL: fechaArriendo
TRIGGER1: FECHAARRIENDO > MAQUINARIAS.FECHAPROVEE
Una de las tareas importantes de esta etapa, es la utilización de estándares. Estos estándares se aplican a
aspectos asociados a formatos y documentación, por ejemplo, en la definición de nombres de
restricciones y nombres de tablas, entre otros.
Para documentar el esquema lógico de esta base de datos, puedes utilizar el siguiente formato:
Docente: Pamela Cristina Landero Sepúlveda
Docente: Pamela Cristina Landero Sepúlveda
TABLA
DESCRIPCION
COLUMNA
10
ARRIENDOS
NOMBRE CORTO
Se almacenan los arriendos de maquinarias
TIPO
LARGO
PK
UK
FK
CLI_RUT
VARCHAR
9
X
ARR_CLI_FK
MAQ_CODIGOMAQ
INTEGER
6
X
ARR_MAQ_FK
FECHAARRIENDO
DATE
NOT
NULL
CHECK
OBSERVACIÓN
X
NOMBRE FK
FOREING KEY
ARR
TABLA QUE REFERENCIA
ARR_CLI_FK: (CLI_RUT)
CLIENTES
ARR_MAQ_FK: (MAQ_CODIGOMAQ)
MAQUINARIAS
NOMBRE CHECK
ESPECIFICACIÓN DEL CHECK
CHECK
CONSTRAINTS
RESTRICCIÓN QUE EJECUTA
NOMBRE TRIGGER
TRIGGERS
TRG_ARR_INS_UPD
TABLA
DESCRIPCION
validarFechaArriendo (FECHAARRIENDO)
GATILLA
I
U
x
x
OBSERVACIÓN
D
FECHAARRIENDO >
MAQUINARIAS.FECHAPROVEE
CLIENTES
NOMBRE CORTO
Se almacenan los arriendos de maquinarias
COLUMNA
Tipo
RUT
NOMBRE
UK
FK
NOT NULL
LARGO
PK
VARCHAR
9
X
VARCHAR
50
X
APELLIDO
VARCHAR
50
X
CALLE
VARCHAR
50
X
NUMERO
INTEGER
6
X
COMUNA
VARCHAR
30
X
FECHANAC
DATE
EDAD
INTEGER
3
CELULAR
INTEGER
10
CLI
CHECK
OBSERVACIÓN
El último dígito es el DV
CLI_NUMERO_CK
X
X
X
CLI_EDAD_CK
X
CLI_CELULAR_CK
NOMBRE FK
Derivada de la fecha de
nacimiento
TABLA QUE REFERENCIA
FOREING KEY
NOMBRE CHECK
CHECK
CONSTRAINTS
NUMERO > 0
CLI_EDAD CK
EDAD > 18
CLI_CELULAR CK
CELULAR > 9999999
NOMBRE TRIGGER
TRIGGERS
ESPECIFICACIÓN DEL CHECK
CLI_NUMERO_ CK
TRG_CLI_INS
TRG_CLI_UPD
Docente: Pamela Cristina Landero Sepúlveda
RESTRICCIÓN QUE EJECUTA
validarRut (RUT)
obtenerEdad (FECHANAC)
obtenerEdad (FECHANAC)
GATILLA
I
U
D
OBSERVACIÓN
Ejecuta dos restricciones:
Validar Rut y obtener edad
x
X
Ejecuta el procedimiento que
obtiene la edad
Docente: Pamela Cristina Landero Sepúlveda
11
De esta manera, usted puede completar la documentación del diseño lógico de esta base de datos
llenando las tablas que faltan: MAQUINARIAS, PROVEEDORES y FECHAS_MANT_MAQUINARIA.
Por lo tanto, junto con la documentación de este esquema lógico, terminamos esta etapa agregando
también el diagrama lógico asociado:
Docente: Pamela Cristina Landero Sepúlveda