Documentos de Académico
Documentos de Profesional
Documentos de Cultura
S9 ResumenDiseñoConceptual y GeneraciónEsquemaLógicoMR PDF
S9 ResumenDiseñoConceptual y GeneraciónEsquemaLógicoMR PDF
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).
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, 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:
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
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).
c) La fecha de nacimiento de un cliente se ha definido que debe ser mayor a 1-01-1900.
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).
SITUACIÓN 1:
En esta situación 1, no hay duda de que el TE-1
recibe la FK (PK de TE-2) ya que la cardinalidad
del 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.
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.
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.
Las tres alternativas de transformación y algunas sugerencias para tomar la mejor decisión se exponen a
continuación:
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:
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
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 (LA
DOCUMENTACIÓN ES PARA LA ENTREGA FASE 3 DEL PROYECTO):
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: