SeparataER1
97
MODELO DE DATOS CONCEPTUAL AVANZADO
-
Upload
enrique-lopez-f -
Category
Documents
-
view
120 -
download
7
Transcript of SeparataER1
MODELO DE DATOS
CONCEPTUAL
AVANZADO
OBJETIVOS DE LA SECCION
Al finalizar esta sección, el alumno será capaz de:
1. validar que un atributo sea puesto correctamente en base a la dependencia con el UID
de la enditidad.
2. resolver relaciones muchos a muchos con entidades intersección.
3. identificar y construir un modelo de datos avanzado incluyendo relaciones recursivas,
subtipos y relaciones exclusivas.
NORMALIZAR EL MODELO DE DATOS
Normalizar es un conjunto de base de datos relacional, pero sus principios se aplican al
modelo Conceptual de datos.
Validar cada atributo usando las reglas de normalización.
Regla de Forma Normal Descripción
Primera forma Normal (1 FN) Todos los atributos deben tener un
solo valor para cada instancia.
Segunda forma Normal(2 FN) Un atributo debe ser dependiente del
identificador único completo.
Tercera forma Normal (3 FN) Ningún atributo mo- UID puede ser
dependiente de otro atributo no - UID
Un modelo de datos entidad- relación normalizado se traslada automáticamente dentro de
un diseño de base de datos.
Notas
La tercera forma normal es un objetivo generalmente aceptado para eliminar
redundancias en un diseño de base de datos.
Formas normales arriba de la tercera forma normal no son comúnmente utilizadas.
Regla de la Primera Forma Normal
Todos los atributos deben tener un solo valor para cada instancia.
VALIDACION
Validar que cada atributo tenga un valor único para cada ocurrencia de la identidad.
Ningún atributo deberá tener valores repetidos.
Ejemplo:
¿LA Entidad CLIENTE cumple con la 1FN? Si, no cumple ¿Cómo se podría convertir a 1FN?
El atributo Fecha de Contacto tiene múltiples valores, por lo tanto la entidad CLIENTE no es
considerada como 1FN.
Crear una entidad adicional CONTACTO con una relación de M:1 hacia CLIENTE.
Regla de la Segunda Forma Normal
Un atributo debe ser dependiente del identificador único completo.
CLIENTE
# identificador.
Fecha de Contacto
CLIENTE
# identificador.
Fecha de Contacto
CONTACTO
# Fecha de Contacto
Localización.
Resultado
Si Un Atributo tiene múltiples valores, se crea una entidad adicional y lo relaciona con la
entidad original mediante una relación M:1
VALIDACION
Validar que cada atributo dependa completmnete de UID. Cada instancia específica
del UID debe determinar una sola instancia de cada atributo.
Validar que un atributo no dependa de una sola parte del UID de la entidad.
Ejemplo:
Cada instancia del código curso determina un valor especifico para el nombre, duración y
cuota. Los atributos están ubicados correctamente.
EJEMPLO:
Cada instancia de un BANCO y numero de cuenta determinan valores específicos del
balance y de la fecha de apertura para cuenta. El atributo de localización del banco esta mal
ubicado.
Este depende del BANCO, pero no del número de cuenta. Este no debería ser un atributo de
CUENTA.
CURSO
# Código
Nombre.
Duración.
Cuota.
BANCO
# Numero.
Nombre.
CUENTA
# Numero
Balance.
Fecha de Apertura.
Localización de Banco
Si un atributo no es depende del UID completo, esta fuera del lugar y debería ser movido
PRACTICA 4-1
Normalizar un modelo E-R.
1. Para el siguiente Modelo E-R, evaluar cada entidad contra las reglas de
normalización, identificar si el atributo esta colocado en el lugar correcto; si no lo
esta, identificar que regla de normalización se esta violando.
2. Opcionalmente, redibujar el diagrama E- R en la tercera forma Normal
CURSO
# Numero de Curso.
Nombre de Curso
Numero de Maestro
Código de departamento
Nombre de departamento
Nombre de maestro
Apellido de maestro
CUENTA
# Codigo de Grado
Numero de Maestro
Descricion de Grado
Nombre del Curso
BANCO
# Numero.
Nombre.
Para
Formado
Con
Para
Asignado A
RESOLUCION DE RELACIONES M:M
Algunos atributos pueden asociarse con Relaciones M:M.
Resolver relaciones M:M agregando una entidad intersección con esos atributos.
EJEMPLO:
Considerar la relación M:M entre PRODUCTO y VENDEDOR. ¿Cuál es el precio actual del
PRODUCTO específico para un VENDEDOR específico?
El precio actual parece ser un atributo de la relación entre PRODUCTO y VENDEDOR.
VENDEDOR
# Codigo
Nombre
PRODUCTO
# ID
Nombre
Descripción
SURTIDO POR
SURTIDOR DE
Los atributos únicamente describen entidades. Si los atributos describen
relaciones, las relaciones deberán ser resueltas.
Reemplazar o resolver una relación M:M con una entidad Intersección nueva y con dos
relaciones M:1.
Ejemplo.
La relación M:M entre PRODUCTO y VENDEDOR puede ser resuelta agregando una
entidad interseccion llamada CATALOGO. El precio actual es realmente un atributo de la
entidad CATALOGO.
Una ves que esta definida la entidad CATALOGO, se analiza la posibilidad de
requerimientos para atributos adicionales como:cantidad del paquete y unidad de medida. El
UID del CATALOGO es compuesto de estas dos relaciones.
Notas:
Una entidad interseccion es frecuentemente identificada por las dos relaciones que le
dieron origen, observar las dos barras UID del ejemplo.
Las relaciones desde una entidad intersección son siempre obligatorias.
Las entidades interseccion son muy comunes para representar situaciones de negocios
en l mundo real.
Las entidades intersección normalmente generan requerimientos para atributos
adicionales como el uso de entidades y fechas. Estas tienden a ser entidades volátiles
y de volumen alto.
CATALAGO
# Precio actual
Cantidad del paquete
Unidad de medida
Para
DETERMIN
ADO CON
Para
ASIGNADA
VENDEDOR
# Codigo
Nombre
PRODUCTO
# ID
Nombre
Descripción
Posicionar las entidades intersección de forma que permitan que “Los cuervos siempre
vuelen hacia el este o hacia el sur”
Forma Relación M:M
Forma Correcta de las entidades Intersección.
Notas:
Una entidad de referencia es una entidad que no ha tenido relaciones obligatorias a
esta.
Cuando las relaciones M:M son resueltas, la forma del diagrama puede ser confusa.
ENTIDAD
INTERSECCION
ENTIDADES
DE
REFERENCIA
El UID de una entidad intersección esta frecuentemente compuesta de las relaciones
entre las entidades que dieron origen.
EJEMPLO:
Resolver la siguiente relación M:M para acomodar los siguientes requerimientos:
“Cada estudiante tiene una fecha de registro en el curso, fecha de terminación del curso y el
grado del estudiante.”
Solución:
Agregar la entidad interseccion INSCRIPCIONES y las dos relaciones M:1.
INSCRIPCION tiene como atributos la fecha de registro, fecha de terminación y el grado.
El UID de INSCRIPCION es credo a partir de las relaciones entre ESTUDIANTE y CURSO.
Notas:
Este modelo únicamente guarda la última fecha en que un estudiante se inscribió en
un curso especifico. Si se necesita guardar múltiples fichas de registro, incluir el
atributo de fecha de registro como parte del UID.
CURSO
# Codigo.
Nombre
Cuota
Duracion.
ESTUDIANTE
# Id
Apellido
Nombre
Numero telefonico
ESTUDIANTE
# Id
Apellido
Nombre
Numero telefonico
CURSO
# Codigo.
Nombre
Cuota
Duracion.
INSCRIPCION
Fecha de registro
Fecha de terminación
Grado
PARA
REGITRADO EN
PARA
TOMADO POR
Las relaciones de una entidad interseccion hacia las dos entidades que le dieron
origen puede no ser muy adecuada para definirá de forma única cada ocurrencia de
la entidad interseccion.
EJEMPLO:
Resolver la siguiente relación M:M para acomodar estos requerimientos adicionales:
“Guardar la fecha en la que cada empleado es asignado a un proyecto, y la duración de la
asignación.”
Agregar una entidad intersección llamada TAREA ASIGNADA con los atributos fecha de
asignación y duración.
TAREA ASIGNADA se identifica parcialmente por las relaciones a EMPLEADO y a
PROYECTO sin embargo, estas dos relaciones no son suficientes para identificar de manera
única a una TAREA ASIGNADA. Un empleado puede tener múltiples asignaciones a
proyectos, con diferentes fechas de asignación. Por tanto, el UID de TAREA ASIGNADA
deberá incluir el EMPLEADO relacionándose con el PROYECTO relacionado, y el atributo
de FECHA ASIGNADA.
PROYECTO
# Nemero
Titulo.
EMPLEADO
# Id
Nombre
ASIGNADO A
ASIGNACION DE
EMPLEADO # Id
Nombre
PROYECTO
# Numero.
Titulo
TAREA ASIGNADA
Fecha asignada
Duración
PARA
ASIGNADO
PARA
SUJETO A
Una ves que se identifica una entidad interseccion, hay que buscar atributos adicionales
para describir la entidad interseccion.
Ejemplo:
¿Qué información se necesita conocer sobre la relación entre PRODUCTO y VENDEDOR?
“Nosotros necesitamos guardar el precio actual de un PRODUCTO especifico para un
VENDEDOR especifico.”
Resolver la siguiente relación M: M para acomodar los requerimientos adicionales.
Agregar la entidad intersección PRODUCTO VENDEDOR con un atributo de precio actual.
¿Qué otra información se necesita conocer sobre el PRODUCTO VENDEDOR?
“Nosotros también necesitamos conocer la cantidad empacada y la unidad de medida de cada
PRODUCTO VENDEDOR”
VENDEDOR
# Codigo
Nombre
PRODUCTO
# ID
Nombre
Descripción
SURTIDO POR
SURTIDOR DE
PRODUCTO VENDEDOR
# Precio actual
Cantidad del paquete
Unidad de medida
Para
DETERMIN
ADO CON
Para
ASIGNADA
VENDEDOR
# Codigo
Nombre
PRODUCTO
# ID
Nombre
Descripción
Buscar atributos que identifiquen o ayuden a identificar una entidad intersección.
Ejemplo.
¿Cómo identificar cada PRODUCTO VENDEDOR? ¿Se puede usar la combinación del
código VENDEDOR y la clave del PRODUCTO?
“No, nosotros tenemos un catalogo de todos los PRODUCTOS VENDEDOR, que se pueden
adquirir con cada VENDEDOR, y cada uno de ellos tiene un numero único en el catalogo”.
De acuerdo a las reglas de los negocios, cada PRODUCTO VENDEDOR tiene un numero
único, el catalogo. Por ello el atributo de NUMERO DE CATALAGO debería ser el UID del
PRODUCTO VENDEDOR.
PRODUCTO VENDEDOR
# Numero de catalogo
Pecio actual
Cantidad de paquete
Unidad de medida
Para
DETERMINA
DO CON
Para
ASIGNADA
VENDEDOR
# Codigo
Nombre
PRODUCTO
# ID
Nombre
Descripción
Resolver las relaciones M:M al final de la fase de análisis. Esta resolución forzada
puede resultar en una Entidad Intersección sin atributos.
Ejemplo:
En la situación de la tienda de videos, se definió la siguiente relación M:M.
Al final de la etapa de análisis, el usuario no ha definido algún atributo asociado con la
relación M:M . Resolver la relación M:M con una entidad interseccion sin ningún atributo.
Notas:
Una entidad interseccion si atributos es justamente una lista de referencia cruzada en
el doble sentido entre las ocurrencias de las Entidades.
Una entidad interseccion sin atributos es la excepción a la regla de una entidad debe
tener atributos para ser una entidad.
El UID para una entidad intersección vacía, es siempre compuesto de la relación de
las dos entidades que lo originaron.
ACTOR
# Código
Apellido real
Nombre real
Fecha de
nacimiento.
PELICULA
# ID
Titulo
Categoría
PROTAGONIZ
ADA POR
PROTAGONIST
A EN
PELICULA # Id
Ttulo
Categoria
ELENCO
DE ESTRELLAS
PARA PARA
PROTAGONISTA EN
ACTOR
# Código
Apellido real
Nombre real
Fecha de nacimiento.
PROTAGONIZADA POR
PRACTICA 4-2
Resolver las relaciones M:M.
1. En el modelo E-R de la práctica 3-10 referente al Grupo de Usuarios Oracle, una
relación M:M fue inicialmente modelada entre la entidad MIEMBRO y la entidad
AREA DE APLICAION.
Resolver esta relación M:M basada en el siguiente texto.
Requerimientos adicionales.
“También nos gustaría llevar una breve descripción del interés de cada miembro en cada área
especifica de aplicación. Por ejemplo, un miembro puede tener un sistema de aplicaron
contable muy grande, elaborado por el mismo. Otro miembro puede estar interesado en otra
área de aplicaron sin describir el mismo interés que el miembro anterior.”
AREA DE
APLICAION
# Codigo
Nombre
MIENBRO
# Identificador
Nombre
Apellido.
Titulo
Cuota recibida
Direccion.
Numero telefonico
Tipo de menbresia
INTERESADO
EN
DE INTERES
PARA
PRACTICA 4-3
Resolver una relación M:M.
1. Resolver la siguiente relación M:M entre CLIENTE y PRODUCTO. Agregar los
atributos fecha de orden, cantidad ordenada y precio.
PRODUCTO
# Numero
Nombre
Existencia.
CLIENTE
# ID
Nombre
Apellido.
EL
COMPRADOR
DE
ORDENADO
POR
MODELO JERARQUICO DE DATOS
Representación jerárquica de datos como un conjunto de relaciones muchos a uno.
Ejemplo:
Modelar la estructura de organización jerárquica de una compañía como un conjunto de
relaciones M:1.
Nota:
La forma del diagrama E-R de Oracle usando la convención de los cuervos siempre
vuelan hacia el este o hacia el sur causa que las jerarquías sean dibujadas de abajo
hacia arriba.
COMPANIA
DIVICION
DEPARTAMENTO
EQUIPO
EQUIPO
DEPARTAMENTO
DIVISION
COMPANIA
DENTRO DE COMPUESTO DE
DENTRO DE COMPUESTO POR
DENTRO DE COMPUESTO POR
Los UIS’s PATRA un conjunto de entidades jerárquicas pueden ser propagados a
través de relaciones múltiples.
Ejemplo:
¿Cuáles son los UID’s de las entidades PISO, DEPARTAMENTO y CUARTO?
El UID del CUARTO es la clave de cuarto y esta localizado dentro de un
DEPARTAMENTO.
El UID del DEPARTAMENTO es el número de habitación y esta localizada en un PISO.
El UID del PISO es el número de piso y esta contenido dentro del EDIFICIO.
CUARTO # Id
DEPARTAMENTO
# Numero
# Inquilino
PISO # Numero
EDIFICIO # Id.
Nombre
Dirección
LOCALIZADO
DENTRO DE COMPUESTO DE
LOZALIZADO EN COMPUESTO POR
CONTENIDO DENTRO COMPUESTO POR
Considerar la creación de atributos artificiales como ayuda par identifica las entidades
en relaciones jerárquicas.
EJEMPLO:
En una estructura típica de organización. ¿Qué puede identificar de manera única instancias
de las entidades de DIVICION, DEPARTAMENTO, y EQUIPO?.
Cada EQUIPO puede ser identificado basándose en su DEPARTAMENTO, DIVICION,
COMPANIA. O cada entidad tiene un código artificial de identificación único independiente.
NOTAS:
Los códigos artificiales de identificación deben ser únicos e independientes.
Si las estructuras jerárquicas cambian ocasionalmente, se recomienda usar
identificadores artificiales independientes.
EQUIPO
DEPARTAMENTO
DIVISION
COMPANIA
DENTRO DE COMPUESTO DE
DENTRO DE COMPUESTO POR
DENTRO DE COMPUESTO POR
RELACION DEL MODELO RECURSIVO
Una relación recursiva es la relación entre una entidad con ella misma.
EJEMPLO:
Leer la relación recursiva en el siguiente diagrama E-R.
Cada EMPLEADO puede estar bajo las órdenes de uno o solo un EMPLEADO.
Cada EMPLEADO puede ser gerente de uno o más EMPLEADOS.
NOTAS:
El ciclo puede aparecer en cualquier lado de cada entidad pero utilizando la
convención de “Los cuervos siempre vuelan hacia el sur o hacia el este”. Debemos
colocar el ciclo en el ángulo inferior derecho.
EMPLEADO
# Numero de clave
Nombre
apellido
empleo
fecha de pago
salario
comision
GERENTE DE
Modelar la lista de materiales como una relación recursiva de muchos a muchos
Ejemplo:
Para la organización de manufactura de automóviles, considerar todas las partes elementales
subensambles, ensamble y productos con estancia de entidad llamada COMPONENTE esta
forma el complejo modelo E-R anterior puede remodelado como una simple recursiva.
Cada COMPONENTE puede ser una parte de uno o más COMPONENTES.
Cada COMPONENTE puede estar compuesto por uno o más COMPONENTES.
COMPONENTE
# IDENTIFICADOR
Nombre
MODELAR SUBTIPOS
Usar subtipos para modelar exclusivamente tipos de entidad que tienen atributos o elaciones
comunes.
Ejemplo:
“Un negocio tiene definidos dos tipos de empleado: Asalariados y por Honorarios. Para
todos los empleados se guarda su número, nombre, apellido y departamento asignado. Para
los empleados asalariados guardar su salario. Para los empleados por Honorarios guardar el
costo por hora, costo por tiempo extra y sindicato.”
Crear un súper tipo EMPLEADO con dos subtipos. Cada EMPLEADO puede ser
EMPLEADO o ASALARIADO o EMPLEADO por HONORARIOS.
NOTA
Se debe tener cuidado con las instancias que pueden estar en ambos subtipos, la
construcción del subtipo- supertipo es incorrecta en esas instancias.
EMPLEADO
# Numero de clave
Nombre
Apellidos
EMPLEADO
ASALARIADO
Salario
EMPLEADO
POR HONORARIOS
Costo por hora.
Costo por horas extras.
EMPLEADO
ASALARIADO
EMPLEADO
ASALARIADO
ASIGNADO A COMPUIESTO DE
COMPUIESTO DE
Los subtipos pueden tener además subtipos. Normalmente dos o tres niveles de
profundidad son adecuados.
Ejemplo:
El AVION es un subtipo de AERONAVE y es un supertipo de AVION MOTORIZADO
PLANEADOR.
El JET hereda los atributos y relaciones de AVION MOTORIZADO, AVION Y de
AERONAVE.
AERONAVE
AVION
HELICOPTERO
HOVERCRAFT
OTRA AERONAVE
AVION DE
PROPULSION
JET
PLANEADOR
RELACIONES QUE MODELAN ROLES
Hay que ser precavidos con las entidades que representan roles.
EJEMPLO:
Es el modelo entidad relación para las compañía de entrenamiento, nosotros definimos una
entidad INSTRUCTOR y una entidad ESTUDIANTE. Este modelo trabaja bien si un
INSTRUCTOR nunca es un ESTUDIANTE, y un ESTUDIANTE nunca es un
INSTRUCTOR. Pero ¿Qué pasaría si el INSTRUCTOR también fuera ESTUDIANTE.?
Las entidades que representan roles pueden compartir instancias que se traslapan.
ESTUDIANTE # Id
Apellido.
Nombre
Numero telefónico.
INSCRIPCION
Fecha de inicio
Fecha de terminacion.
Grado.
PARA PARA
TOMADO POR
CURSO
# Código
Nombre
Duración
Cuota.
REGISTRADO EN
INSTRUCTOR
# Id
Nombre
Apellido
Numero telefónico
ENSEÑADO
POR
MAESTRO DE
Un supertipo es una entidad que tiene subtipos.
Un supertipo puede ser separado en dos o más subtipos mutuamente excluyentes.
Ejemplo:
Un EMPLEADO debe ser EMPLEADO ASLARIADO o EMPLADO POR HONORARIOS,
pero no ambos.
El supertipo puede tener atributos y relaciones compartidas por sus subtipos.
Ejemplo:
A todo EMPLEADO se le clasifica con nombre, apellido y número. Todos los
EMPLEADOS deben estar y solo un DEPARTAMENTO.
Cada subtipo puede tener sus propias relacione y atributos.
Ejemplo:
El subtipo EMPLEADO ASALARIADO tiene una atributo de salario.
El subtipo EMPLEADO POR HONORARIOS tiene como atributos costo por horas y costo
por tiempo extra y una relación con la entidad SINDICATO.
Notas:
Una subtipo que no tenga atributos o relaciones propias puede ser un sinónimo para la
entidad prototipo y no un subtipo.
MODELO DE RELACIONES EXCLUSIVOS
Modelar dos o más relaciones mutuamente excluyentes de la misma entidad usando
un arco.
EJEMPLO:
Una CUENTA BANCARIA debe pertenecer a una CONPAÑIA o ser PERSONAL.
Usar un arco para modelar esta relación.
Reglas de lectura para la relación exclusiva.
“Cada entidad A tiene un relación 1 con la entidad B una relación 2 con una entidad C 3 ”.
EJEMPLO:
Cada CUENTA BANCARIA debe pertenecer a una y solo una PERSONA o pertenecer a
una o solo una COMPAÑÍA.
Estándares para modelos de arco.
Las relaciones en arco frecuentemente tienen los mismo nombres de relación.
Las relaciones d arco deben ser todas obligatorias o todas opcionales.
Un arco pertenece a una sola entidad, y solamente debe incluir relaciones originadas
de entidad.
Una entidad puede tener múltiples arcos, pero una relación específica solamente
puede participar en un solo arco.
CUENTA BANCARIA
A
CONPAÑIA
C
PERSONAL
B
Todas la estancias de una entidad súper tipo deben pertenecer a una y solo u a de la
entidades de subtipo. Los subtipos deben formar un grupo completo in traslaparse.
Ejemplo:
En general los trabajos deben ser manuales o de oficina pero puede haber excepciones.
Reglas de lectura de supertipos.
“Subtipo, el cual es un tipo del supertipo”.
Ejemplo:
“Trabajos de OFICINA, los cuales son un tipo de TRABAJO.”
Siempre se usan subtipos OTROS cuando no se esta seguro completamente de los
conjuntos.
TRABAJO
TRABAJO MANUAL
OTRO
TRABAJO
TRABAJO DE
OFICINA
Escoger Entre Dos Convenciones Para Dibujo De Arcos.
Convención uno. Un arco con puntos opcionales.
Un punto dentro de este arco de be usarse para indicar que una relación pertenece al arco.
Convención dos. Arco sin puntos
Toda relación cruzada por un arco le pertenece. Un rompimiento en el arco indica una
relación que no esta incluida en el.
CONPAÑIA
C
Practica 4-5.
Desarrollar un modelo E-R.
1. desarrollar un modelo E-R que satisfaga los siguientes requerimientos.
“LA compañía de camine RIGHT- WAY renta pequeños camiones de mudanza y
trailer para uso local y en un solo sentido. Tenemos 347 oficinas de renta a través de la
región oeste de los barios tipos de camiones y trailer. Necesitamos implementar un
sistema para registrar nuestros contratos de renta y las asignaciones a nuestra vehículos.
Cada una de las oficinas renta vehículos que tienen en su inventario, unidades listas
para que los cliente s tomen posesión de ella inmediatamente. No hacemos
reservaciones, ni especulamos con la fecha en que el cliente regresara el vehículo
rentado. La oficina central supervisa la distribución de los vehículos, y dirige las
trasferencias de los vehículos de una oficina a otra.
Cada oficina de renta tiene un nombre como “LitletonRight-Way”. Cada oficina
también tiene un número único de tres dígitos. Nosotros también registramos la
dirección de la oficina.
Cada vehículo tiene un identificado único, registro del estado y una placa con su
numero de registro. Tenemos 5 tipos de vehículos diferentes: Camiones de 36 pies ,
camiones de 34 pies, camiones de 10 pies, trailer cubiertos de 8 pies, y trailer
descubiertos de 6 pies. Si tenemos un código para el tipo de vehículo. Para todos
nuestros vehículos necesitamos registrar la fecha en la que tuvo su último
mantenimiento la fecha de vencimiento de su registro. Para nuestros camiones
necesitamos conocer la lectura actual del Odómetro (aparato para medir la distancia en
la marcha), la capacidad del tanque de gasolina y si tiene o no un radio. Para mudanzas
larga los clientes prefieren que el vehículo tenga radio a notamos el viaje actual justo
antes de rentar un camión y otra ves cuando nos es regresado.
La mayoría de nuestros contratos de renta son para clientes individuales pero un
contrato de renta puede ser para un particular o para una compañía. Rentamos un
porcentaje pequeño de nuestros camiones a compañías. Asignamos un número de
identificador para cada compañía y registramos el nombre de la ksma y su dirección.
No , no necesitamos preocuparnos por información adicional sobre la empresa. Nuestro
grupo corporativo de ventas maneja toda la información de manera separada.
Para cada cliente particular registramos su nombre, teléfono de su casa, su dirección y
su licencia de conducir del estado: Número y Fecha de vencimiento. Nos gustaría llevar
el registro de nuestros clientes. Si un cliente daña nuestro vehículo, lo abandona o no
cubre por completo el monto de la cuenta, lo marcamos como un cliente de alto riesgo y
no lo volvemos a rentar nada.
Solamente le permitimos a una sola persona hacer un contrato de renta por renta
llevamos contratos separados de renta para cada vehículo. Si puede ser que un cliente
nos rente dos o más vehículos a la vez. Cada contrato de renta es identificado por el
número de la oficina que género el mismos un número de contrato de renta. También es
indispensable que conozcamos la fecha de renta, la duración anticuopada de la renta, la
oficina de renta en donde dejara la unidad, el monto del depósito dejado, la cuota de
renta diaria, y la cuota por milla. Por supuesto que por los trailer no hay cargo por
millaje. No no necesitamos automatizar el lado financiero de nuestro negocio, solo
necesitamos controlar nuestros contratos de renta y las funciones de asignación a
nuestro proyecto.”
Crear una entidad adicional para mantener los valores de ,os valores en el tiempo
Ejemplo:
Una firma de consultaría necesita mantener información acerca de sus contratos. Cada
contrato tiene una clave única, y se necesita tener la descripción del contrato, el estatus
del contrato (por ejemplo abierto, cerrado o suspendido). Inicialmente fue modelada la
siguiente entidad CONTRATO.
La entidad CONTRATO soporta un solo valor de estatus. La firma consultora quiere
llevar registro de las fechas de apertura, cierre o suspensión de cada contrato. Para
modelar los valores del estatus en el tiempo, agregar la entidad ESTATUS.
El UID de la entidad ESTATUS es la fecha de vigencia y el UID del CONTRATO.
Notas:
Usar una sola entidad para guardar los valores en le tiempo de múltiples
atributos asociado con una entidad (como CONTRATO).
CONTRATO
# Id.
Descripción.
Valor de estado.
Fecha de vigencia.
CONTRATO
# Id.
Descripcion
ESTATUS
# Id.
Fecha de Vigencia
ESTADO DE
TIENE
MODELOS DE DATOS DE TIEMPO
Agregar entidades adicionales y relaciones al modelo E-R para acomodar datos históricos.
Preguntas al usuario:
¿Se quiere una auditoria.?.
¿Los valores de los atributos pueden cambiar en el tiempo?.
¿Pueden cambiar las relaciones en el tiempo?.
¿Necesita consultar los valores antiguos?.
¿Necesita mantener versiones anteriores?
Nota:
validar cualquier requerimiento para almacenar datos históricos para el usuario.
Almacenar datos histórico innecesarios puede ser costoso.
Una entidad intersección se usa frecuentemente para mantener información acerca de
las relaciones que cambian con el tiempo.
Ejemplo:
Una sociedad de profesionistas quiere saber en que compañías, sus miembros han sido
empleado y la finalización de cada empleo (Por templo de una fecha a otra fecha). Hay una
relación M:M entre cada socio y entren cada compañía.
Agregar una entidad interseccion, REGISTRO HISTORICO DEL Empleado, para guardar
empleos que cada empleado ha tenido en el tiempo y las fechas de esos empleos.
Al incluir el atributo de la fecha en el UID del REGISTRO HISTORICO DEL EMPLEADO
modelo guardara muchas fechas de empleo para una sola compañía y para un solo empleado.
COMPAÑIA
# Codigo
Nombre
SOCIO
# ID
Nombre
Apellido.
TRABAJA
PARA
TRABAJADOR
DE
SOCIO
# Id
Apellido
Nombre
COMPAÑÍA # Codigo.
Nombre
REGISTRO HISTORICO DEL
EMPLEADO
De la Fecha
A la Fecha
PARA
TRABAJA PARA
PARA
TRABAJADOR DE
Agregar una nueva entidad para acomodar la relación que puede variar en el tiempo.
EJEMPLO
El dueño de unos departamentos quiere saber quines son los inquilinos de cada
uno de sus departamentos. (Solo tienen contratos de renta para una sola persona,
no con múltiples personas). El siguiente modelo E – R solo mantendrá el
inquilino actual de departamento.
Agregar la cantidad REGISTRO HISTORICO DE CUENTA para capturar los valores de las
relaciones de renta en el tiempo.
PERSONA
# Id
Nombre
Apellido
DEPARTAMENTO
# Codigo
Direccion
RENTADO POR
Registro histórico de
renta
# De la fecha
o la fecha
Para
Arrendatario
de
Para
Rentado por
persona
# Id
Nombre
Apellido
Departamento
# Código
Dirección
MODELAR RELACIONES COMPLEJAS
Cuidado con las relaciones M:M.
Ejemplo
Desarrollar un modelo E-R para la historia de empleados. Para cada persona, guardar su
puesto en la compañía en la que trabajo, las fechas de sus puestos obtenidos. Una persona
puede tener un puesto específico en la misma compañía múltiples veces durante su carrera.
Inicialmente el siguiente modelo E-R fue definido
Las fechas del puesto parecen ser un atributo de una relación. Resolver cada relación
M-M
PUESTO
# TITULO DE
TRABAJO O
DESCRIPCION DE
TRABAJO
PERSONA
# ID
APELLIDO
NOMBRE
OCUPANTE
DE
OCUPADO
POR
DEPARTAMENTO
# Codigo
Direccion
PATRON DE
PATRON DE
EMPLEADA
POR INCLUIDO
EN
PUESTO
# TITULO DE
TRABAJO O
DESCRIPCION DE
TRABAJO
PERSONA
# ID
APELLIDO
NOMBRE
OCUPANTE
DE
TRABAJADO
POR COMPAÑIA
# Codigo
Direccion
SUJETO A
TRABAJADO
POR
TRABAJADO
EN
OCUPADO
POR
HISTORIA
DE LA
COMPAÑIA
HISTORIA
DEL PUESTO
HISTORIA DE LA
ORGANIZACION
¿Que entidad intersección forman los atributos de fecha de puesto?, ¿todas ellas?,
¿ninguna de ellas?.
PRACTICA 4-6
Modelar datos a través del tiempo.
Modificar el modelo E-R de la tienda del videos para que satisfaga con los siguientes
requerimientos.
“tu sabes, necesitamos registrar todo el histórico de nuestras rentas. Cada vez que un cliente
renta un video, nos gustaría guardar la fecha de renta y el día en que regresará el video.
Todos nuestros videos se deben de regresar el siguiente día, así que no llevamos una cuota
por día de renta.
Al guardar esta historia de las rentas nos permitirá analizar el comportamiento de las mismas.
Seremos capaces de determinar cuantos videos renta cada cliente y cuantas veces un cliente
ha regresado un video tarde. Nosotros también debemos conocer cuantas veces un video en
particular ha sido usada, y así saber cuando retirar dicho video. Así podremos analizar las
preferencias de cine de nuestros clientes”.
CINTA
# NUMERO
FORMATO
Para
RENTADA
POR
EL
ARRENDATARIO
DE
LA COPIA PELICULA
# identificador TITULO
CATEGORIA
CLIENTE
# NUMERO DE
SOCIO
APELLIDO
NOMBRE
NUMERO TELEFONO
DIRECCION
ACTOR CODIGO NOMBRE ARTISTICO
NOMBRE REAL
APELLIDO REAL FECHA DE NACIMIENTO
ELENCO DE ESTRELLAS
Para
PROTAGONISTA
EN
PROTAGONIZADA
POR
PRACTICA 4-7
Hacer un modelo de relación compleja.
El modelo de E-R del grupo de usuarios de Oracle de la práctica 3-10 una relación M:M
Fue inicialmente modelada entre la entidad MIEMBRO y la entidad PLATAFORMA DE
COMPUTADORA. Revisar que esa relación satisfaga los siguientes requerimientos.
Requerimientos
“No solo necesitamos conocer que plataforma de computadora utiliza cada usuario. Además
necesitamos conocer que productos (RDBMS, Pro*C, SQL*Forms, SQL*TextRetriveal,
CASE, Financials, Etc.)maneja cada miembro y sobre que plataformas de computadora
corren. No necesitamos conocer la versión especifica de cada producto, solo el nombre
general del mismo”.
PLATAFORMA DE
COMPUTADORA
# Id DESCRIPCION
MIEMBRO
# ID
NOMBRE
APELLIDO
TITULO
PAGARES
RECIBIDOS
DIRECCION
NUMERO
TELEFONO
TIPO DE
MEMBRESIA
INTERESADO
EN
DE INTERES
PARA
PRACTICA 4-8
Practica opcional
Desarrollar un complejo E-R
1. Desarrollar un modelo E-R para la siguiente situación.
“ Mi nombre es Phil Sales y trabajo en los cruceros Shipmore. Hemos decidido que
nuestro sistema manual de reservaciones de pasajeros dentro de nuestros barcos no
funcionara más cuando tengamos nuevos barcos. Tendremos dos barcos mas, no botes,
los botes entran dentro de los barcos, y probablemente nos expandiremos a 5 o 6 para
1995. cada uno tiene un nombre como “gooosea”,”goodwind”, y el nuevo es “goodsky” ,
cada uno tiene la capacidad especifica de pasajeros y tiene un registro. El registro es el
país en donde se registro el barco. Necesitamos preocuparnos sobre el tonelaje o la
mecánica, o cualquier otra cosa sobre el barco.
Cada año sacamos un folleto información sobre cada crucero que ofrecemos. Cada
crucero tiene un nombre y una duración en días. Tenemos cruceros de tres, siete, once,
catorce días. Cada crucero también tiene un barco asignado específicamente a el alguna
gente solo le gusta viajar en barcos mas nuevos. Vamos a necesitar saber la antigüedad de
cada barco. Cada crucero se detiene en diferentes puertos. Un crucero de tres días solo
tendrá una parada siempre en el segundo del crucero, un crucero de siete días se detendrá
en tres puertos, y así sucesivamente. Los puertos van variando dependiendo de donde
haya salido el crucero. Los puertos son Los Ángeles, Miami, Anchorage. Los cruceros
por los Ángeles bajan a los puertos de México, como son cabo san Lucas y Mazatlán, los
cruceros de Miami van a las Bahamas y las islas vírgenes, y el crucero de Anchorage
hace paradas a lo largo de toda Alaska. Dependiendo de la duración de cada crucero, cada
barco hará llamadas a puertos en días diferentes mientras este afuera.
Los pasajeros que viajan con nosotros escogerán un crucero determinado, que tendrá
determinada duración y un “X” numero de puertos, y dependiendo del crucero que elija
nos dirá que cabinas esta disponible. Una vez que haya escogido una si esta disponible, la
podemos cotizar. Esto depende del número de personas en cada cabina y la “clase” de la
cabina. Siempre que boleteamos una cabina bajo el sistema manual, borramos la cabina
del pizarrón de corcho donde llevamos la disponibilidad a menos de que no este lleno y
el pasajero quiera compartirla con alguien mas si la cabina tiene capacidad para cuatro
personas, y los pasajero viajan solos entonces les va a costar mas. Cada pasajero es
boleteado y entonces recibimos su deposito después le pagamos su comisión a la gerencia
de viajes que haya hecho la reservación.”
CONCEPTO
DE BASE
DE DATOS
RELACIONAL
OBJETIVO DE LA SECCION
Al final de la sección el alumno será capaz de :
1. Entender que es una base de datos relacional.
2. Definir que son las llaves primarias.
3. Entender el concepto de integridad de datos.
INTRODUCCIÓN A LA BASE DE DATOS RELACIONAL
Una base de datos relacional es una base de datos que es percibida por el usuario como
una colección de relaciones o de tablas de dos dimensiones.
EJEMPLO
la tabla relacional contiene datos de empleados.
NO_EMP
APELLIDO NOMBRE NO_DEPTO
100
SANCHEZ DAVID 10
310
ARIAS ADRIANA 15
210
BRIONES JAIME 10
405
GOMEZ JOSE 12
378
MONTOYA LUCIA 25
NOTAS
las tablas de base de datos relacional son sencillas pero disciplinadas.
Una base de datos relacional debe tener integridad de datos, sus datos deben de
ser precisos y consistentes.
Las base de datos relacionales son manipuladas como un conjunto en un tiempo
en vez de un registro en un tiempo.
EJEMPLO
Para seleccionar todos los empleados que trabajan en el departamento 10, utilice la
siguiente introducción SQL.
SQL> SELET no_emp, apellido, nombre, no_depto
2 FROM empleado
3 WHERE no_depto = 10;
NO_EMP APELLIDO NOMBRE NO_DEPTO
------------- -------------- -------------- ----------------
100 SANCHEZ DAVID 10
200 BRIONES JAIME 10
el lenguaje estructurado de consulta(SQL) es utilizada parea manipular las bases de
datos relaciónales.
NOTAS
El instituto nacional americano de estándares (ANSI) ha establecido a SQL
como lenguaje estándar para operar sobre las bases de daros relaciónales.
Una base de datos relacional puede soportar un conjunto completo de
operaciones relaciónales. Las operaciones relacionales manipulan conjuntos
de valores de datos, tablas pueden ser utilizadas en la creación de otras tablas.
Las operaciones relacionales pueden ser anidadas.
LLAVES PRIMARIAS
Una llave primaria (PK) es una columna o grupo de columnas que identifican de manera
única a cada renglón de una tabla. Cada tabla tabla debe tener una llave primaria y una llave
primaria debe ser única.
EJEMPLO
La llave primaria para la tabla EMPLEADO consiste en la columna NO_EMP. Cada renglón
en la tabla es identificado de manera única por su valor en NO_EMP.
Llave primaria
NO_EMP APELLIDO NOMBRE NO_DEPTO
100 SANCHEZ DAVID 10
210 ARIAS ADRIANA 15
210 BRIONES JAIME 10
405 GOMEZ JOSE 12
375 JONHSON LUCIA 06
TABLA EMPLEADOS
NOTAS
No se aceptan duplicados en llave primaria. la llave primaria debe ser única.
El valor de las llaves primaria generalmente no se pueden cambiar.
El UID de una entidad ira de acuerdo con llave primaria en su tabla correspondiente
Una llave primaria que consta de varias columnas se llama llave primaria compuesta.
EJEMPLO
La llave primaria compuesta para la tabla CUENTA consta de la combinación de las
columnas NO_BANCO Y NO_CUENTA. cada renglon en la tabla esta identificado de
manera única por los valores de NO_BANCO Y NO_CUENTA.
Llave Primaria
NO_BANCO NO_CUENTA BALANCE FECHA_APERTURA
104 77560 12.000.60 21.Oct.89
104 77956 100.10
105 89570 65.776.00 16.Ene.85
103 65890 15.001.85 10.Mar.71
105 76964 5.00 28.Set.91
TABLA CUENTA
NOTA
Las columnas de una llave primaria compuesta deben de ser únicas en combinación de
columnas pueden tener duplicados en forma individual, pero en combinación no se permiten
duplicados.
Ninguna parte de la llave primaria debe ser nula.
EJEMPLO
NO_EMP es la llave primaria de la tabla EMPLEADO. por lo tanto NO_EMP debe ser
definida como NO NULA.
Clave primaria
NO_EMP APELLIDO NOMBRE NO_DEPTO
100 SANCHEZ DAVID 10
210 ARIAS ADRIANA 15
210 BRIONES JAIME 10
405 GOMEZ JOSE 12
375 JONHSON LUCIA 06
Tabla Empleados
EJEMPLO
¿ como es que la tabla CUENTA viola las reglas de las llaves primarias?
Llave Primaria
NO_BANCO NO_CUENTA BALANCE FECHA_APERTURA
104 77560 12.000.60 21.Oct.89
104 77956 100.10
89570 65.776.00 16.Ene.85
103 15.001.85 10.Mar.71
105 76964 5.00 28.Set.91
Tabla Cuenta
Dos de los reglones contienen valores NULOS en partes de la PK compuesta. NO_BANCO y
NO_CUENTA deben de ser definidos como NO NULOS.
Una tabla puede tener más de una columna o combinación de columnas que pueden
servir como la llave primaria de la tabla. Cada una de estas es llamada llave candidata
o alterna.
EJEMPLO
¿Cuales don las llaves candidatas de la tabla EMPLEDO?
NO_EMP APELLIDO NOMBRE NO_DEPTO NOMINA
100 SANCHEZ DAVID 10 9710
210 ARIAS ADRIANA 15 8730
210 BRIONES JAIME 10 1157
405 GOMEZ JOSE 12 3394
375 JONHSON LUCIA 06 4477
TABLA EMPLEADO
NO_EMP y NOMINA son las llaves candidatas
Seleccionar una llave candidata para ser la llave primaria para la tabla. Otros candidatos se
convierten en llaves alternas o llaves únicas.
EJEMPLO
Llave Primaria Llave Alterna
NO_EMP APELLIDO NOMBRE NO_DEPTO NOMINA
100 SANCHEZ DAVID 10 9710
210 ARIAS ADRIANA 15 8730
210 BRIONES JAIME 10 1157
405 GOMEZ JOSE 12 3394
375 JONHSON LUCIA 06 4477
NOTAS
Todas las llaves alternas deben de ser únicas y NO NULAS.
Los UID secundarios concuerdan con las alternas.
Los nombres de personas normalmente no son llaves alternas por que no se pueden
garantizar que sean únicas. Por ejemplo, en la tabla EMPLEADO la combinación
NOMBRE/APELLIDO probablemente no podría ser llave alterna.
LLAVES FORANEAS
Una llave foránea (FK) es una columna o combinación de columnas en la tabla, que se
refiera a una llave primaria en la misma o en otra tabla.
EJEMPLO
NO_DEPTO es FK en la tabla EMPLEADO y se refiere a los valores en la columna
NO_DEPTO de la tabla DEPARTAMENTO.
Llave Primaria Llave Foránea
NO_EMP APELLIDO NOMBRE NO_DEPTO NOMINA
100 SANCHEZ DAVID 10 9710
210 ARIAS ADRIANA 15 8730
210 BRIONES JAIME 10 1157
405 GOMEZ JOSE 12 3394
375 JONHSON LUCIA 25 4477
Llave primaria
NO_DEPTO NOMBRE_DEPTO
10 FINANZAS
15 OPERACIONES
12 MANUFACTURA
25 VENTAS
NOTAS
Las llaves foráneas son utilizadas para hacer “JOIN” entre tablas.
Las llaves foráneas se basa en los valores de los datos y son puramente lógicas.
La llave foránea puede ser repetida u nula.
Una llave foránea debe coincidir con una valor de una llave primaria existente.
EJEMPLO
La FK NO_DEPTO en la tabla EMPLEADO se refiere a los valores de la PK de
NO_DEPTO en la tabla DEPARTAMENTO.
Llave Primaria Llave Foranea
NO_EMP APELLIDO NO_DEPTO
100 SANCHEZ FINANZAS
310 ARIAS OPERACIONES
210 BRIONES MANUFACTURA
405 GOMEZ VENTAS
TABLA EMPLEADO
Llave primaria
NO_DEPTO NOMBRE_DEPTO
10 FINANZAS
15 OPERACIONES
12 MANUFACTURA
25 VENTAS
TABLA DEPARTAMENTO
Si una llave foránea es parte de una primaria, la FK no puede ser NULA.
EJEMPLO
En la tabla CUENTA, la FK NO_BANCO debe ser NO NULA porque es parte de la PK.
Llave Primaria
NO_BANCO NOMBRE_BANCO
104 CARNET
150 COMERMEX
103 BANCOMER
105 BANAMEX
TABLA BANCO
Llave Foránea Llave Primaria
NO_BANCO NO_CUENTA BALANCE
103 75760 12.000.60
104 77956 100.10
150 89570 65.776.00
103 33347 15.001.85
105 76954 5.00
TABLA CUENTA
INTEGRIDAD DE DATOS
La integridad de datos se refiere a la exactitud y consistencia de los datos.
Constraints de integridad de datos
Los constraints de integridad de datos define el estado relacional correcto de la base
de datos.
Los constraints de integridad de datos aseguran que los usuarios realizan únicamente
operaciones en la cuales dejaran a la base de datos en un estado correcto y consistente.
TIPO DE CONSTRAINT EXPLICACION
Integridad de entidades Ninguna parte de la llave primaria puede
ser nula.
Integridad referencial Una llave foránea debe coincidir con una
valor de una llave primaria.
Integridad de columnas Una columna solo debe contener valores
consistentes con el formato de datos
definidos para la columna.
Integridad definida por el usuario Los datos almacenados en la base de datos
deben cumplir con las reglas del negocio
Todos los contraints de integridad de datos deben ser forzados por el DBMS o el software de
aplicación.
NOTAS
un dato es inconsistente si existen múltiples copias d un registro y no todas las copias
han sido actualizadas. Una base de datos inconsistentes puede proveer información
incorrecta o contradictoria a los usuarios.
Las reglas del negocio también pueden determinar el estado correcto de una base de
datos. Estas reglas de negocios son llamados constraints de integridad de datos
definidas por el usuario.
EJEMPLO
Un negocio tiene las siguientes lista de contraints de integridad de datos definida por el
usuario.
A un empleado de confianza no se le paga por las primeras 5 horas de trabajo de
tiempo extra.
Ningún empleado del departamento de finanzas puede llevar el titulo de
“programador”.
La comisión de los vendedores no puede exceder de los 50% de su usuario.
NOTAS
los constraints de los datos definidos por el usuario pueden ser administrados por
políticos ser requeridos por las leyes gubernamentales.
Frecuentemente esas reglas son completamente arbitrarias al menos que parecen ser
arbitrarias.
Los constraints de integridad de datos definidos por el usuario pueden incluir
múltiples columnas y tablas.
DISEÑO
INICIAL DE LA
BASE DE DATOS
OBJETIVOS DE LA SECCION Al final de esta sección el alumno será capaz de:
1. Explicar como el diseño de una base de datos esta dentro del proceso de desarrollo de
la base de datos.
2. Trasladar un modelo entidad-relación a un diseño de base de datos relacional.
3. Documentar el diseño de la base de datos usando un mapa de instancias.
DISEÑO DE BASE DE DATOS
El diseño de la base de datos es ejecutado durante la etapa de diseño del ciclo de
desarrollo del sistema y es ejecutado conjuntamente con el de aplicaciones.
Requerimientos de información
ESTRATEGIAS - MODELO DE DATOS
ANALISIS ENTIDAD-RELACION
- DEFINICIONES DE ENTIDADES
DISEÑO
- DEFINICIONES DE TABLAS,
INDICES, VISTAS, CLUSTERS Y DE
ESPACIO.
CONSTRUCCION
BASE DE DATOS OPERACIONAL
MODELO
CONCEPTUAL
DE DATOS
DISEÑO DE
BASE DE
DATOS
CONSTRUCCIÓN
DE LA BASE
DE DATOS
El diseño de base de datos se lleva a cabo por medio de dos actividades.
Actividades de diseño de base de datos.
1. pasar el modelo E-R a tablas relacionales para producir el diseño inicial.
2. refinar el diseño inicial para producir un diseño completo de la base de datos.
Liberación del diseño de la base de datos
La etapa de diseñote la base de datos produce especificaciones de diseño para una base de
datos relacional incluyendo definiciones para tablas relacionales, índices, vistas, y espacio de
almacenamiento.
INTRODUCCIÓN AL DISEÑO INICIAL A LA BASE DE DATOS
Documentar cada tabla relacional en un mapa de instancias.
Mapa de instancias.
Nombre de la tabla: EMPLEADO
Columna
EMPNO NOMBRE APELLIDO PUESTO FECHA_PAGO SAL COMM MGR NODEPT
Tipo
llave
PK FK1 FK2
Nulos
único
NN.U NN NN NN NN
Ejemplo 7369
MARTHA SANCHEZ ARCHIVISTA 17.DIC.80 800 7902 20
7902
MIGUEL CANTO ANALISTA 03.DIC.81 1000 7566 50
7521
FIDEL SANCHEZ VENDEDOR 22.FEB.81 1250 6000 7698 30
7698
PEDRO INFANTE GERENTE 01.MAY.81 2850 10000 7839 30
7839
JORGE NEGRETE PRESIDENTE 12.NOV.81 5000 5000 10
NOTAS
los tipos validos de llaves son PK para una columna llave primaria, y FK para una
columna llave foránea.
Usar sufijos para distinguir entre múltiples columnas FK en una tabla, por ejemplo,
FK1 y FK2. etiquetar múltiples columnas con el mismo sufijo.
Usar NN para una columna que debe ser definida como NO NULA.
Usar U para la columna que debe ser única.
Si múltiples columnas deben ser únicas en combinación, etiquetadas con un sufijo,
por ejemplo UI.
Etiquetar una columna sencilla PK como NN,U.
Etiquetar múltiples columnas PK (compuestas) como NN,UI o como NN,UI,U.
Ya es familiar el modelo E-R de la compañía de entretenimiento, y sera usado para
ilustrar las actividades del diseño inicial de la base de datos.
Modelo E-R de la compañía de entretenimiento.
MATRICULA
# fecha de inicio
fecha de terminación
grado
Para
Tomado por
Para
Registrado en
CURSO
# Código
Nombre
Cuota
Duración
INSTRUCTOR
# ID
Nombre
Apellido
Numero telefono
ESTUDIANTE
# Id
Nombre
Apellido
Numero telefono
Enseñado
por
Seguir una serie de pasos para dibujar un modelo E-R para una serie de tablas y
producir un diseño inicial de base de datos.
Pasos en el diseño inicial en la base e datos
1. Mapear las entidades para las tablas.
2. Mapear atributos para columnas y documentar datos simples.
3. Mapear identificadores únicos a llaves primarias.
4. Mapear relaciones a llaves foráneas.
5. Elegir opciones de arco.
6. Elegir opciones de subtipo.
PASO 1 MAPEAR LAS ENTIDADES
Mapear la tabla para cada entidad. Crear unmapa de instancias para la nueva tabla. Registrar
únicamente el nombre de la tabla.
Ejemplo
Crear un mapa de instancias para la entidad INTRUCTOR el nombre de la tablas será
Instructor.
NOMBRE DE LA TABLA INSTRUCTOR
NOTAS
El nombre de la tabla debe ser fácil de identificar con el nombre de la entidad. El
nombre en plural de una entidad se usa algunas veces por que la tabla debe contener
un grupo de renglones.
Una entidad simple no es un subtipo o supertipo. En el paso 6 el diseñador debe
decidir como se hace una construcción supertipo o un subtipo.
COLUMNA TIPO DE
LLAVE
NULOS
UNICO
EJEMPLO
PASO 2 MAPEAR ATRIBUTOS A COLUMNAS
Mapear cada atributo de la entidad a una columna en su tabla correspondiente. Establecer los
atributos obligatorios para columnas NO NULAS (NN).
Ejemplo
Asignar los atributos de la entidad INSTRUCTOR a columnas en la tabla INSTRUCTOR.
Marcar como atributos obligatorios (NO NULOS) las columnas inst_id, nombre y apellido.
Nombre de la tabla INSTRUCTOR
Para cada atributo seleccionar un nombre corto pero significativo.
NOTAS
El nombre de las columnas debe ser fácil de identificar en un modelo E-R.
Prevenir al usuario de no usar las palabras reservadas de SQL para nombres de
columnas. Por ejemplo NUMBER.
Usar abreviaciones consistentes que no causen confusión al usuario y al programador.
Por ejemplo, ¿podría ser abreviado NÚMERO como NO o NUM y DEPTNO o
DEPTNUM?
los nombres de columnas cortos o pequeños reducirán el tiempo requerido para el
comando de SQL “parsing” .
COLUMNA INST_ID NOMBRE APELLIDO NOTELEF
TIPO DE
LLAVE
NULOS
UNICO
NN NN NN
EJEMPLO
Documentar renglones de ejemplo de datos en cada mapa de instancias.
Ejemplo
Documentar datos del ejemplo para las columnas de la tabla INSTRUCTOR
Columna INST_ID NOMBRE APELLIDO NOTELEF
Tipo de
llave
Nulos /
Únicos
NN NN NN
Ejemplo 10 NANCY HALL 798-2251
18 MARIA GONZALEZ 756-1891
73 PETE CASSIDY 301-2291
95 KATHY ANDRONICA 483-9221
301 ERIC CAMPLIN 535-3166
Fuentes para datos del ejemplo
notas de entrevistas a usuarios.
Mapa de instancias.
Sistemas actuales de computadoras.
Otros documentos de analisis.
Conversaciones adicionales con el usuario.
PASO 3 MAPEAR UIDS A LLAVES PRIMARIAS
Asignar cualquier atributo (s) que sea parte del UID de la entidad a columnas PK etiquetar
las columnas PK.
EJEMPLO
El atributo ID es el UID de la entidad INSTRUCTOR, entonces hacer que la columna
correspondiente INST_ID sea el PK de la tabla INSTRUCTOR.
Nombre de tabla instructor
Columna INST_ID NOMBRE APELLIDO NOTELEF
Tipo de
llave
Nulos /
Únicos
NN NN NN
Ejemplo 10 NANCY HALL 798-2251
18 MARIA GONZALEZ 756-1891
73 PETE CASSIDY 301-2291
95 KATHY ANDRONICA 483-9221
301 ERIC CAMPLIN 535-3166
Un tipo de llave PK indica una columna de llave primaria.
NOTAS
Todas las columnas etiquetadas con PK deben etiquetarse también con NN y U.
Asignar un UID que incluya múltiples atributos a una PK compuesta. Etiquetar estas
columnas NN y UI.
Si una entidad incluye una relación, agregar columnas de llaves foráneas para la tabla y
señalarlas como parte de la llave primaria.
Ejemplo
El UID de la entidad MATRICULA esta compuesta de una relación para CURSO y de una
relación para ESTUDIANTE agregar 2 columnas FK a la tabla Matricula, para el PK de la
tabla CURSO y para el PK de la tabla ESTUDIANTE.
Nombre de la tabla MATRICULA
Columna FECHA_REG FECHA_TER GRADO CODIGO
CURSO
ESTUDIO
TIPO DE
LLAVE
PK.FK1 PK.FK2
NULOS /
UNICOS
NN NN.UI NN.UI
EJEMPLOS 20.JUL.91 29.JUL.91 -------- 344 47593
05.SEP.95 ---------- -------- 401 15402
14.JUN.91 28.JUN.91 A 717 94572
08.MAY.91 28.JUN91 B 717 94572
05.MAY.91 21.MAY.91 A 401 51304
MATRICULA
# Fecha de inicio
Fecha terminación
grado
Para
Tomado
por
Para
Registrado por
Curso
# código
Nombre
Cuota
duración
NOTAS
Escoger un nombre único para cada columna FK y etiquetar la (S) columna (S) PK
Si existe múltiples columnas FK en una tabla, usar sufijos para distinguirlos, por FK1
y FK2. etiquetar múltiples columnas llave con el mismo sufijo.
Las PK compuesta deben de ser únicas en combinación y deben de ser etiquetas.
Agregar ejemplos de datos para las columnas FK.
Si una relación de 1:1 es opcional en ambas direcciones mover la FK en la tabla cualquiera
de la dos tablas de la relación
Ejemplo
Para la relación opcional 1:1 entre MUELLE y BARCO la columna FK puede colocarse en la
tabla MUELLE o BARCO. La columna M_NUM es agregada a la tabla barco y etiqueta
como única para forzar la relación 1:1.
Nombre de la tabla MUELLE
COLUMNA M_NUM LON
TIPO DE
LLAVE
PK
NULOS /
UNICOS
NN,U NN
EJEMPLO 344 100
075 1000
554 500
341 80
570 600
BARCO
# numero de registro
ciudad de registro
MUELLE
# numero
longitud
OCUPADO
POR
Desembarcado
en
# id
nombre
apellido
telefono
Nombre de la tabla BARCO
COLUMNA NUM_REG CIU_REG NOMBRE TIPO M_NUM
TIPO DE
LLAVE
PK PK FK
NULO /
UNICO
NN,UI NN,UI NN
U2
EJEMPLO 134X89 PANAMA SUN KING CRUISE 554
004455678 NORWAY PRINCESS TANKER 570
1114088 UNITED
STATES
EXXON
POSSIDON
075
Y1.0998-1 UNITED
STATES
RUN
RUNNER
YACHR 344
A02345 PANANA AVION YACHR 341
LLAVE PRIMARIA COMPUESTA
NOTA
La FK para la relación 1:1 debe ser siempre única. Pero permite nulos.
Para una relación recursiva 1:M, agregar una columna FK a la tabla. Esta columna FK debe
referenciar valores de la columna PK.
EJEMPLO
Para esta relación recursiva 1:M, agregar una columna FK a la tabla de EMPLEADO para
cada empleado que sea gerente. Nombrar la columna como MGR_ID para reflejar la relación.
GERENTE DE
Nombre de la tabla: EMPLEADO:
Columna EMP_ID NOMBRE APELLIDO MGR_ID
Tipo de llave
PK FK
Nulos/
Únicos
NN.U NN NN
Ejemplos
7450 MARY SMITH
5579 LESLIE STERNE 7450
6714 JANET GETRY 5579
9451 BILL ABLE 7450
3040 JUAN GOMEZ 9451
NOTAS
La columna FK hace referencia a un renglón e la misma tabla.
El nombre de la columna FK debe reflejar la relación.
Una FK recursiva nunca debe ser NO NULA.
EMPLEADO # * id
* nombre * apellido
BAJO LAS ORDENES DE
Para una relación recursiva 1:1, agregar una FK única a la tabla. Esta columna FK
debe referenciar un valor de la columna PK.
EJEMPLO
Para esta relación recursiva 1:1, agregar una columna única a la tabla PERSONA.
ESPOSO DE
Columna PERS_ID NOMBRE APELLIDO ID_ESP
Tipo de llave
PK FK
Nulos/
Únicos
NN.U NN NN U2
Ejemplos
7450 MARY SMITH ------
5579 SUSAN JONES 9451
6714 JANET GENTRY 3040
9451 BILL JONES 5579
3040 JERRY JOHNSON 6714
NOTAS
La combinación de columnas PK y FK siempre debe ser única para asegurar la
relación 1:1. Poniendo el PK y el FK como únicos (U) se garantiza que la
combinación será única.
Una FK recursiva nunca debe ser NO NULA.
PERSONA # * id
* nombre * apellido
CASADO
PRACTICA 6 – 1
Crear un diseño inicial de la base de datos.
1. Seguir los primeros cuatros pasos del Diseño Inicial de la Base de datos para mapear el
siguiente modelo E-R a un conjunto de tablas diseñadas inicialmente. Documentar los
diseños de las tablas en los mapas de instancias. Crear los datos de ejemplo como se
requieran.
Asignado a
Responsabilidad de
Bajo las ordenes de
Gerente de
EMPLEADO
numero clave
nombre
apellido
empleo
fecha de pago
salrio
comisión
# DEPARTAMENTO
número
nombre
localización
#
REPASO MAPEAR MODELOS E-R SIMPLES PARA TABLAS
Dibujar un modelo Entidad – Relación simple para un diseño inicial de la base de datos
usando los siguientes cuatro pasos:
PASOS
1. Mapear las entidades para las tablas.
2. Mapear atributos para columnas y documentar datos simples.
3. Mapear identificadores únicos a llaves primarias.
4. Mapear relaciones a llaves foráneas.
Documentar cada tabla de diseño en una tabla de Instancias.
PRACTICA 6 – 2
Crear un diseño inicial de la base de datos
1. Seguir los primeros cuatro pasos del Diseño inicial de la base de datos para mapear el
siguiente modelo E-R a un conjunto de tablas diseñadas inicialmente. Documentar el
diseño de tablas en los mapas de instancias. Crear los datos de ejemplos como se
requieran.
para
requerido por
medio de
Contenido en
Contenedora de
LINEA
número
cantidad
precio
#
PRODUCTO
número
nombre
unidad de medida
#
ORDEN
número
fecha de pedido
#
Nombre de la tabla
Columna
Tipo de llave
Nulos/ Único
Ejemplo
Nombre de la tabla
Columna
Tipo de llave
Nulos/ Único
Ejemplo
2. Utilizar el diseño de subtipo de tablas separadas y desarrollar un diseño de tabla para
este Modelo Entidad-Relación. Documentar el diseño en los mapas de instancias.
Mostrado en
Parte de
LINEA DE ORDEN
Número de item
Descripción
LINEA DE ORDEN DE PRODUCTO
Cantidad
Precio actual
#
LINEA DE ORDEN DE SERVICIO
Cuota
PRODUCTO código
precio estándar
#
ORDEN número
#
Por
Nombre de la Tabla: PRODUCTO Nombre de la Tabla: ORDEN
Nombre de la Tabla: LÍNEA_ORDEN_PRODUCTO
Columna
Tipos de
llave
Nulos/
Únicos
Nombre de la Tabla: LÍNEA_ORDEN_SERVICIO
Columna
Tipos de
llave
Nulos/
Únicos
Columna
COD-
PROD
PRECIO-
PROD
TIPO DE
LLAVE
PK
Nulos/
Únicos
N.N.U
N.N
Columna
NUM-
ORDEN
TIPO DE
LLAVE
PK
Nulos/
Únicos
N.N.U
PRACTICA 6-3
Crear un diseño inicial de la base de datos
1. Seguir los primeros cuatro pasos del Diseño inicial de la base de datos para mapear el
siguiente modelo E-R a un conjunto de tablas diseñadas inicialmente. Documentar el
diseño de tablas en los mapas de instancias. Crear los datos de ejemplos como se
requieran.
Alquilado por
El arrendatario de
Ubicado en
Contenedor de
Ubicado en
Contenedor de
DEPARTAMENTO
número
#
INQUILINO
id
nombre #
PISO
número
#
EDIFICIO
id
nombre
dirección
#
Nombre de la Tabla
Columna
Tipo de llave
Nulos/ Único
Ejemplo
Nombre de la tabla
Columna
Tipo de llave
Nulos/ Único
Ejemplo
Nombre de la tabla
Columna
Tipo de llave
Nulos/ Único
Ejemplo
Nombre de la Tabla
Columna
Tipo de llave
Nulos/ Único
Ejemplo
Nombre de la tabla
Columna
Tipo de llave
Nulos/ Único
Ejemplo
Nombre de la tabla
Columna
Tipo de llave
Nulos/ Único
Ejemplo
Nombre de la Tabla
Columna
Tipo de llave
Nulos/ Único
Ejemplo
Nombre de la tabla
Columna
Tipo de llave
Nulos/ Único
Ejemplo
PRACTICA 6-4
Práctica Opcional
Crear un diseño inicial de la base de datos.
1. Seguir los primeros cuatro pasos del Diseño inicial de la base de datos para mapear el
siguiente modelo E-R a un conjunto de tablas diseñadas inicialmente. Documentar el
diseño de tablas en los mapas de instancias. Usar las notas de la entrevista de la siguiente
página para seleccionar datos de ejemplos como se requieran.
Representado por
responsable
compuesta de
Dentro de
Nombre de la Tabla
Columna
Tipo de llave
Nulos/ Único
Ejemplo
LOCALIDAD DE VENTA
código
nombre
#
EMPLEADO
id
nombre
apellido
cuota
posición
#
Nombre de la tabla
Columna
Tipo de llave
Nulos/ Único
Ejemplo
2. Use las siguientes notas de entrevista para seleccionar datos de ejemplo para llenar los
mapas de instancias.
“Nuestra compañía vende productos a través de los Estados Unidos. Así que dividimos a
los Estados Unidos en cuatro regiones de ventas : la Región Norte, la Región Este, la
Región Sur y la Región Oeste. Cada región tiene un código único. Cada región de venta se
divide en distritos de ventas. Por ejemplo, la región del Oeste es dividida en los distritos de
Rocky Mountain, Noreste, Costa del Pacífico, y distritos del Pacífico. Cada distrito tiene
un código único.
Cada distrito se conforma de territorios de ventas. El distrito de Rocky Mountain lo
constituyen tres territorios: Wayoimi- Montana, Colorado y UTA-New México. El distrito
del noreste está formado por dos territorios: California y Nevada. El distrito del Pacífico
incluye los territorios de Hawai y de Alaska. Cada territorio tiene un código único de
territorio.
A su vez, cada territorio de ventas se descompone en área de ventas. Por ejemplo Colorado
está conformado de dos áreas de ventas: área formal y la vertiente Oeste. Cada área de
venta tiene un código único de ventas.
Cada vendedor es responsable de una o más áreas de ventas y tiene una cuota de venta
específica.
También tenemos gerentes de ventas que son responsables de uno o más distritos de ventas,
y los directores de ventas quienes son responsables de una o más regiones de ventas. Cada
gerente de ventas es responsable de los territorios dentro de sus distritos. Nosotros no
traslapamos las responsabilidades de nuestros empleados. Un área de venta es siempre la
responsabilidad de un solo vendedor y las responsabilidades de nuestros gerentes y
directores tampoco se sobreponen.
Algunas veces nuestros gerentes, vendedores y directores están de viaje o tienen
asignaciones especiales; por lo tanto, no tienen responsabilidades de ventas. Identificamos
a todo nuestro personal de ventas por su identificador de empleado. ”
MAPA DE TABLAS DE MODELOS COMPLEJOS E- R
Realizar los siguientes pasos adicionales para convertir un modelo complejo Entidad-
Relación en un diseño inicial de base de datos.
Pasos
5. Escoger Opciones de Arco.
6. Escoger Opciones de Subtipo
PASO 5 – ESCOGER OPCIONES DE ARCO
Los Arcos representan un tipo de llave foránea de alternativa múltiple. Escoger entre dos
alternativas de diseño para “mapear” arcos a llaves foráneas.
Alternativas de Diseño
Diseño de Arco Explícito
Diseño de Arco Genérico
EJEMPLO
Este modelo E-R mapeará cuatro tablas. La entidad OFICINA tiene un arco que atraviesa los
finales de tres relaciones. Las correspondientes columnas de FK deben ser agregadas a la
tabla OFICINA .
Usar un diseño de Arco Explicito o un diseño de Arco Genérico para agregar estas
alternativas múltiples de llaves foráneas
Rentado por
arredantario de
rentado por
arredentario de
rentado por
arrendatario de
NOTAS
También se utiliza el diseño de Arco Explicito o el diseño de Arco Genérico para
implementar múltiples llaves foráneas cuando un arco atraviesa un conjunto de
relaciones 1:1
Los Arcos solamente pueden atravesar el final de las relaciones que son o todas
obligatorias o todas opcionales.
OFICINA
Id del edificio
Número de oficina
#
#
INDIVIDUAL
id #
SOCIEDAD
código #
COMPAÑIA
número #
El Diseño de Arco Explícito crea una columna de llave foránea para cada relación que
incluye el arco.
EJEMPLO
El siguiente Modelo E-R contiene cuatro entidades simples, y serán mapeadas para cuatro
tablas por separado. El arco atraviesa el final de las tres relaciones. Por lo tanto, las FKs
deben de ser agregadas a la tabla OFICINA. Se utiliza un diseño de Arco Explícito para crear
una columna FK para cada relación.
Rentado por
Arrendatario de
Rentado por
Arrendatario de
Rentado por
Arrendatario de
Nombre de la tabla: OFICINA
NOTAS
El diseño de Arco Explícito soportará llaves foráneas múltiples con diferentes
formatos. Por ejemplo, NUM_OFICINA, ID_IND Y COD_SOCIAL, pueden tener
diferente formato de columna.
El software de aplicación debe forzar a una relación de exclusividad entre las llaves
foráneas.
Columna ID_EDIFICIO NUM_OFICINA ID_IND COD_SOCIAL NUM_CIA
tipo de llave PK PK PK1 PK2 PK3
Nulos/
Única
NN.U1 NN.U1
Ejemplo
1024 101 30045
512 210 A4431
977 144 54532
3041 510 10844
2371 430 54101
OFICINA
Id del edificio
Número de oficina
#
#
INDIVIDUAL
id #
SOCIEDAD
código #
COMPAÑIA
número #
El diseño se Arco Genérico crea una columna de llave foránea única y una columna
para marcar la relación del arco. Como las relaciones son exclusivas, solamente un
valor de FK existirá para cada renglón en la tabla.
EJEMPLO
Otra vez, crear cuatro tablas por separado para este Modelo E-R(Uno para cada entidad).
Como el arco atraviesa el final de las tres relaciones, las FKs se deben de agregar a la tabla
OFICINA. Utilizar un Diseño de Arco Genérico y crear una columna de llave foránea simple
y agregar un tipo de columna para indicar cual de las tres tablas está referenciada por la
columna FK en cada renglón. Por ejemplo, I para INDIVIDUAL, S para SOCIEDAD, y C
para COMPAÑÍA.
Rentado por
Arrendatario de
Rentado por
Arrendatario de
Rentado por
Arrendatario de
Nombre de la Tabla: OFICINA
NOTAS
Sí las relaciones debajo del arco son obligatorios, hacer ambas columnas NO
NULAS(NOT NULL).
Las llaves foráneas deben de compartir el mismo formato para todas las tablas
referenciadas.
La relación de exclusividad se forza automáticamente.
Columna ID-EDIFICIO NUM_OFICINA REN_DE TIPO_RENTA
tipo de llave PK PK FK
Nulos/ Única NN.U1 NN.U1 NN NN
Ejemplo
1024 101 30045 I
512 210 A4431 S
977 144 54532 I
3041 510 10844 C
2371 430 54101 C
OFICINA
Id del edificio
Número de oficina
#
#
INDIVIDUAL
id #
SOCIEDAD
código #
COMPAÑIA
número #
PRÁCTICA 6-5
Dibujar una estructura de arco a las tablas.
1.Utilizar un Diseño de Arco Explícito y desarrollar un diseño de tabla para este Modelo
Entidad-Relación. Documentar el diseño en los mapas de instancias.
DE
La casa de
De
La casa de
De
La casa de
Nombre de la Tabla: ESTUDIANTE
Columna
Tipo de llave
Nulos/ Único
Ejemplo
ESTUDIANTE
Id
apellido
Nombre
#
MUNICIPIO
código
nombre
#
ESTADO
id
nombre del estado
#
PAIS
id
nombre
#
Nombre de la Tabla: MUNICIPIO
Columna
Tipo de llave
Nulos/ Único
Ejemplo
Nombre de la tabla: ESTADO
Columna
Tipo de llave
Nulos/ Único
Ejemplo
Nombre de la tabla: PAÍS
Columna
Tipo de llave
Nulos/ Único
Ejemplo
2. Utilizar un Diseño de Arco Genérico y desarrollar un diseño de tabla para este Modelo
Entidad-Relación. Documentar el diseño en los mapas de instancias.
DE
La casa de
De
La casa de
De
La casa de
Nombre de la Tabla: ESTUDIANTE
Columna
Tipo de llave
Nulos/ Único
Ejemplo
Nombre de la Tabla: MUNICIPIO
Columna
Tipo de llave
Nulos/ Único
Ejemplo
ESTUDIANTE
Id
apellido
Nombre
#
MUNICIPIO
código
nombre
#
ESTADO
id
nombre del estado
#
PAIS
id
nombre
#
Nombre de la Tabla: ESTADO
Columna
Tipo de llave
Nulos/ Único
Ejemplo
Nombre de la Tabla: PAÍS
Columna
Tipo de llave
Nulos/ Único
Ejemplo
PASO 6 ESCOGER OPCIONES DE SUBTIPOS
Escoger cualquiera de las tres opciones para el mapeo de subtipos con tablas.
Opciones de Mapeo de Subtipos a Tablas.
Diseño de una sola Tabla
Diseño de Tablas Separadas
Implementación del Arco(Ver Apéndice E.p. E.3)
EJEMPLO
En el siguiente supertipo/subtipo, las entidades EMPLEADO, EMPLEADO ASALARIADO,
EMPLEADO POR HONORARIOS pueden ser mapeadas en una, dos o tres tablas
dependiendo de la opción seleccionada.
Asignado a
compuesto de compuesto de
Repaso de Conceptos de Subtipos/ Supertipos
Los subtipos heredan todos los atributos del supertipo y sus relaciones.
Los subtipos pueden tener atributos y relaciones propias.
Los subtipos deben de ser mutuamente excluyentes.
Opción 1. Diseño de Subtipo en una sola Tabla.
número de clave
nombre
apellido
EMPLEADO ASALARIADO salario
EMPLEADO POR HONORARIOS
costo por hora
costos por horas extras
EMPLEADO
#
Miembro de
DEPARTAMENTO
código SINDICATO
número #
Crear una sola tabla para el supertipo y mapear los subtipos dentro de esta tabla. La
tabla sencilla contendrá instancias de todos los subtipos.
Se usa el diseño de una sola tabla cuando el subtipo tiene pocas relaciones y atributos
propios.
Pasos de Diseño
1. Crear una sola tabla para el supertipo
2. Crear una columna para cada uno de los atributos del supertipo
3. Crear una columna TIPO para identificar a que subtipo pertenece cada renglón
4. Crear una columna para cada uno de los atributos del subtipo.
5. Crear columnas FK para cada una de las relaciones del supertipo.
6. Crear columnas FK para cada una de las relaciones del subtipo.
A
B
C
TABLA A
EJEMPLO
Mapear el supertipo EMPLEADO y sus subtipos dentro se una sola tabla EMPLEADO
Asignado a
compuesto de compuesto de
Nombre de la Tabla: EMPLEADO
Columna NUM
_
CVE
NOMBR
E
APELLID
O
TIPO_
EMPLE
A
SAL COSTO_H
R
HR_EXT
R
NO_SIN
D
COD_DEP
TO
Tipo de
llave
PK PK1 PK2
Nulos/
Único
NN.U NN NN NN NN
Ejemplo
4579 JAIME JUÁREZ E 29000 40
6631 KAREN DIDONAT
O
E 25000 35
1190 MIGUEL ALVAREZ E 42700 40
370 MARIA PENA E 44050 30
800 PEDRO MEDINA E 38450 35
7147 JOSE LUNA NE 8.50 12.75 201 35
6794 JULIA OSUNA NE 6.75 11.50 150 30
941 JAVIER BARBA NE 12.00 18.00 201 45
985 JOSE GOMEZ NE 9.50 16.15 201 30
969 CLAUDI
A
LOPEZ NE 10.50 15.75 180 15
número de clave
nombre
apellido
EMPLEADO ASALARIADO salario
EMPLEADO POR HONORARIOS
costo por hora
costos por horas extras
EMPLEADO
#
Miembro de
DEPARTAMENTO
código SINDICATO
número #
Las columnas de la tabla EMPLEADO son derivadas de los atributos y las relaciones del
supertipo y todos sus subtipos.
Tipo de Entidad Columnas para Atributos Columnas FK para Relaciones
Supertipo NUM_CVE, NOMBRE, COD_DEPTO
APELLIDO
Subtipo SAL, COSTO_HR, NO_SIND
HR_EXT
NOTAS
El diseño de subtipo de una sola tabla requiere una nueva columna tipo para
identificar el subtipo al que pertenece cada renglón. La columna TIPO_EMPLEA fue
agregada a la tabla EMPLEADO para este propósito.
Usar un Diseño de Subtipo en una sola Tabla cuando hay pocas relaciones atributos
propios.
Ventajas
El acceso al supertipo es directo
El subtipo puede ser accesado y modificado usando vistas.
Desventajas
Los requerimientos del subtipo NO NULO no se pueden forzar a nivel de base de
datos.
La lógica de las aplicaciones tendrán que manejar diferentes conjuntos de atributos
dependiendo del TIPO.
Opción 2. Diseño de subtipo en tablas Separadas
Mapear el subtipo en tablas separadas(Una para cada subtipo). Cada tabla contendrá
solamente instancias de un subtipo.
Pasos del Diseño
1. Crear una tabla para cada subtipo.
2. En cada tabla subtipo, crear columnas para los atributos del subtipo.
3. En cada tabla subtipo, crear columnas para los atributos del supertipo.
4. En cada tabla subtipo, crear columnas FK para las relaciones del subtipo.
5. En cada tabla subtipo, crear columnas FK para las relaciones del supertipo.
A
B
C
TABLA B
TABLA B
EJEMPLO
Hacer el supertipo EMPLEADO en dos tablas(Una para cada subtipo). Primero crear una
tabla separada para el subtipo EMPLEADO ASALARIADO
Asignado a
compuesto de compuesto de
Nombre de la Tabla: EMPLEADO ASALARIADO
Columna NUM_
CVE
NOMBRE APELLIDO SAL COD_DEPTO
Tipo de
llave
PK FK
Nulos/
Único
NN.U NN NN NN
Ejemplo
4579 JAIME JUÁREZ 29000 40
6631 KAREN DIDONATO 25000 35
1190 MIGUEL ALVAREZ 42700 40
370 MARIA PENA 44050 30
800 PEDRO MEDINA 38450 35
número de clave
nombre
apellido
EMPLEADO ASALARIADO salario
EMPLEADO POR HONORARIOS
costo por hora
costos por horas extras
EMPLEADO
#
Miembro de
DEPARTAMENTO
código SINDICATO
número #
EJEMPLO
Crear una tabla separada para el subtipo EMPLEADO POR HONORARIOS
Asignado a
compuesto de compuesto de
número de clave
nombre
apellido
EMPLEADO ASALARIADO salario
EMPLEADO POR HONORARIOS
costo por hora
costos por horas extras
EMPLEADO
#
Miembro de
DEPARTAMENTO
código SINDICATO
número #
Nombre de la Tabla: EMPLEADO POR HONORARIOS.
Column
a
NUM_C
VE
NOMB
RE
APELL
IDO
COSTO_
HR
HR_EX
TR
NO_SIN
D
COD_DEP
TO
Tipo de
llave
PK PK1 PK2
Nulos/
Único
NN.U NN NN NN
Ejemplo
4579 JAIME JUÁRE
Z
11.7 14.3 362 40
6631 KARE
N
DIDON
ATO
10.00 3.56 315 35
1190 MIGUE
L
ALVA
REZ
8.25 2.4 185 40
370 MARIA PENA 13.4 11.5 178 30
800 PEDRO MEDIN
A
11.2 15.8 415 35
7147 JOSE LUNA 8.50 12.75 201 35
6794 JULIA OSUN
A
6.75 11.50 150 30
941 JAVIE
R
BARB
A
12.00 18.00 201 45
1020 JOSE GOME
Z
9.50 16.15 201 30
3500 CLAU
DIA
LOPEZ 10.50 15.75 180 45
Se usa un Diseño de Subtipo de Tablas Separadas cuando hay muchas relaciones y
atributos de subtipos específicos.
Ventajas
La opcionalidad de los atributos del subtipo se forza a nivel de la base de datos.
La lógica de las aplicaciones no requiere de chequeo para los subtipos.
Desventajas
La consulta al supertipo requiere de un operador de UNIÓN.
Las vistas que enlazan dos tablas(mediante un join) son solamente de consulta.
El código del programa de aplicación debe de ser específico para cada tabla
individual.
El mantenimiento de los UID’s de los subtipos es difícil de implementar.
PRACTICA 6-6
Mapear subtipos a las tablas.
1. Utilizar el diseño de subtipo de una sola tabla y desarrollar un diseño de tabla para
este modelo Entidad- Relación. Documentar el diseño en los mapas de instancias.
Mostrado en
Parte de
Compuesto de
Nombre de la Tabla: PRODUCTO Nombre de la Tabla: ORDEN
Columna
COD-
PROD
PRECIO-
PROD
TIPO DE
LLAVE
PK
Nulos/
Únicos
N.N.U
N.N
Columna
NUM-
ORDEN
TIPO DE
LLAVE
PK
Nulos/
Únicos
N.N.U
LINEA DE ORDEN
Número de item
Descripción
LINEA DE ORDEN DE PRODUCTO
Cantidad
Precio actual
#
LINEA DE ORDEN DE SERVICIO
Cuota
PRODUCTO código
precio estándar
#
ORDEN número
#
Por
Nombre de la Tabla: LÍNEA_ORDEN
Columna
Tipo de
llave
Nulos/
Único
