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)
Segunda forma Normal(2 FN)
Tercera forma Normal (3 FN)
Todos los atributos deben tener un solo
valor para cada instancia.
Un atributo debe ser dependiente del
identificador único completo.
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?

CLIENTE
# identificador.
Fecha de Contacto

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.

CONTACTO CLIENTE
# Fecha de Contacto # identificador.
Localización. Fecha de Contacto
Resultado

Si Un Atributo tiene múltiples valores, se crea una entidad adicional y lo relaciona con la
Regla de
entidad la Segunda
original Forma
mediante una Normal
relación M:1
Un atributo debe ser dependiente del identificador único completo.

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:

CURSO
# Código
Nombre.
Duración.
Cuota.

Cada instancia del código curso determina un valor especifico para el nombre, duración y
cuota. Los atributos están ubicados correctamente.

EJEMPLO:

CUENTA BANCO
# Numero # Numero.
Balance. Nombre.
Fecha de Apertura.
Localización de Banco

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.

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.

CUENTA Para CURSO

# Codigo de Grado # Numero de Curso.
Numero de Maestro Nombre de Curso
Descricion de Grado Formado Numero de Maestro
Nombre del Curso Con Código de departamento
Nombre de departamento
Nombre de maestro
Apellido de maestro
Para

Asignado A

BANCO
# Numero.
Nombre.

2. Opcionalmente, redibujar el diagrama E- R en la tercera forma Normal

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?

PRODUCTO SURTIDO POR VENDEDOR

# ID # Codigo
Nombre Nombre
Descripción
SURTIDOR DE

El precio actual parece ser un atributo de la relación entre PRODUCTO y VENDEDOR.

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.

CATALAGO Para VENDEDOR

# Precio actual # Codigo
Cantidad del paquete Nombre
Unidad de medida DETERMIN
ADO CON

Para

ASIGNADA

PRODUCTO
# ID
Nombre
Descripción

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.
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.

ENTIDAD
INTERSECCION

ENTIDADES
DE
REFERENCIA

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.
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.”

ESTUDIANTE
# Id CURSO
Apellido # Codigo.
Nombre Nombre
Numero telefonico Cuota
Duracion.

Solución:
Agregar la entidad interseccion INSCRIPCIONES y las dos relaciones M:1.

INSCRIPCION
Fecha de registro
Fecha de terminación
Grado

PARA PARA

TOMADO POR
REGITRADO EN

ESTUDIANTE CURSO
# Id # Codigo.
Apellido Nombre
Nombre Cuota
Numero telefonico Duracion.

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.
 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.”

EMPLEADO ASIGNADO A PROYECTO

# Id
# Nemero
Nombre
Titulo.
ASIGNACION DE

Agregar una entidad intersección llamada TAREA ASIGNADA con los atributos fecha de
asignación y duración.

TAREA ASIGNADA
Fecha asignada
Duración

PARA PARA

SUJETO A
ASIGNADO

EMPLEADO PROYECTO
# Id # Numero.
Nombre Titulo

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.
 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.

PRODUCTO SURTIDO POR VENDEDOR

# ID # Codigo
Nombre Nombre
Descripción
SURTIDOR DE

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”

PRODUCTO VENDEDOR Para VENDEDOR

# Precio actual # Codigo
Cantidad del paquete Nombre
Unidad de medida DETERMIN
ADO CON

Para

ASIGNADA

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”.

PRODUCTO VENDEDOR Para VENDEDOR

# Numero de catalogo # Codigo
Pecio actual Nombre
Cantidad de paquete DETERMINA
Unidad de medida DO CON

Para

ASIGNADA

PRODUCTO
# ID
Nombre
Descripción

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.
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.

PELICULA PROTAGONIZ ACTOR

# ID ADA POR # Código
Titulo Apellido real
Categoría Nombre real
Fecha de
PROTAGONIST
A EN nacimiento.

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.

ELENCO
DE ESTRELLAS

PARA PARA

PROTAGONIZADA POR PROTAGONISTA EN

PELICULA ACTOR
# Id # Código
Ttulo Apellido real
Categoria Nombre real
Fecha de nacimiento.

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.
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.”

INTERESADO EN
MIEMBRO AREA DE
# Identificador APLICAION
# Codigo
Nombre DE INTERES Nombre
Apellido. PARA

Titulo
Cuota recibida
Direccion.
Numero telefonico
Tipo de menbresia
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.

CLIENTE EL PRODUCTO
COMPRADOR
# ID DE # Numero
Nombre Nombre
Apellido. Existencia.
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.

COMPANIA EQUIPO

DIVICION DENTRO DE
COMPUESTO DE

DEPARTAMENTO

DEPARTAMENTO
DENTRO DE
COMPUESTO POR

EQUIPO DIVISION

DENTRO DE
COMPUESTO POR

COMPANIA

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.
 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?

CUARTO
# Id

LOCALIZADO
DENTRO DE
COMPUESTO DE

DEPARTAMENTO
# Numero
# Inquilino

LOZALIZADO EN COMPUESTO POR

PISO
# Numero

CONTENIDO DENTRO
COMPUESTO POR

EDIFICIO
# Id.
Nombre
Dirección

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.
 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?.

EQUIPO

DENTRO DE
COMPUESTO DE

DEPARTAMENTO

DENTRO DE
COMPUESTO POR

DIVISION

DENTRO DE
COMPUESTO POR

COMPANIA

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.

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.

EMPLEADO
# Numero de clave
Nombre
apellido
empleo
fecha de pago
salario
comision
GERENTE DE

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.

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.

COMPONENTE
# IDENTIFICADOR
Nombre

 Cada COMPONENTE puede ser una parte de uno o más COMPONENTES.

 Cada COMPONENTE puede estar compuesto por uno o más COMPONENTES.

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.

EMPLEADO
# Numero de clave
Nombre
Apellidos
EMPLEADO EMPLEADO
ASALARIADO POR HONORARIOS

Costo por hora.

Salario Costo por horas extras.

ASIGNADO A COMPUIESTO DE
COMPUIESTO DE

EMPLEADO EMPLEADO
ASALARIADO ASALARIADO

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.
Los subtipos pueden tener además subtipos. Normalmente dos o tres niveles de
profundidad son adecuados.
Ejemplo:

AERONAVE

AVION

AVION DE
PLANEADOR PROPULSION

JET

HELICOPTERO

HOVERCRAFT

OTRA AERONAVE

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.

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.?

INSCRIPCION
Fecha de inicio
Fecha de terminacion.
Grado.

PARA PARA

REGISTRADO EN TOMADO POR

ENSEÑADO INSTRUCTOR
ESTUDIANTE CURSO POR # Id
# Id # Código Nombre
Apellido. Nombre Apellido
Nombre Duración Numero telefónico
Numero telefónico. Cuota. MAESTRO DE

Las entidades que representan roles pueden compartir instancias que se traslapan.

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.

PERSONAL

B
CUENTA BANCARIA
A
CONPAÑIA

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.

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.

TRABAJO
TRABAJO MANUAL TRABAJO DE
OFICINA

OTRO
TRABAJO

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.

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.

CONPAÑIA

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.

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.

CONTRATO
# Id.
Descripción.
Valor de estado.
Fecha de vigencia.

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.

ESTADO DE
ESTATUS CONTRATO
# Id. # Id.
Fecha de Vigencia TIENE Descripcion

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).

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.

SOCIO TRABAJA COMPAÑIA

PARA
# ID # Codigo
Nombre Nombre
Apellido.
TRABAJADOR
DE

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.

REGISTRO HISTORICO DEL

EMPLEADO
De la Fecha
A la Fecha

PARA PARA

TRABAJADOR DE
TRABAJA PARA

SOCIO COMPAÑÍA
# Id # Codigo.
Apellido Nombre
Nombre

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.

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.

DEPARTAMENTO RENTADO POR PERSONA

# Codigo # Id
Direccion Nombre
Apellido

Agregar la cantidad REGISTRO HISTORICO DE CUENTA para capturar los valores de las
relaciones de renta en el tiempo.

Registro histórico de Para persona

# Id
renta
Nombre
# De la fecha
Arrendatario Apellido
o la fecha de

Para

Rentado por

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

PERSONA OCUPANTE DE PUESTO

# ID
# TITULO DE
APELLIDO
TRABAJO O
NOMBRE
DESCRIPCION DE
OCUPADO POR TRABAJO

EMPLEADA
POR INCLUIDO EN
PATRON DE

PATRON DE

DEPARTAMENTO
# Codigo
Direccion

Las fechas del puesto parecen ser un atributo de una relación. Resolver cada relación
M-M

OCUPANTE DE

PERSONA PUESTO
# ID # TITULO DE
APELLIDO HISTORIA TRABAJO O
NOMBRE DEL PUESTO DESCRIPCION DE
OCUPADO POR TRABAJO

SUJETO A

TRABAJADO EN
HISTORIA HISTORIA DE LA
DE LA ORGANIZACION
COMPAÑIA TRABAJADO
POR
TRABAJADO POR
COMPAÑIA
# Codigo
Direccion

¿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”.

ELENCO DE ESTRELLAS

Para Para

PROTAGONIZADA PROTAGONISTA
POR EN

ACTOR
LA COPIA CODIGO
CINTA PELICULA
NOMBRE ARTISTICO
# NUMERO # identificador NOMBRE REAL
FORMATO TITULO APELLIDO REAL
CATEGORIA FECHA DE NACIMIENTO

RENTADA
POR

EL
ARRENDATARIO
DE

CLIENTE
# NUMERO DE
SOCIO
APELLIDO
NOMBRE
NUMERO TELEFONO
DIRECCION
 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”.

INTERESADO EN
PLATAFORMA DE
MIEMBRO
# ID COMPUTADORA
NOMBRE # Id
DESCRIPCION
DE INTERES PARA
APELLIDO

TITULO

PAGARES
RECIBIDOS

DIRECCION

NUMERO
TELEFONO

TIPO DE
MEMBRESIA

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
Integridad referencial
Integridad de columnas
Integridad definida por el usuario
Ninguna parte de la llave primaria puede
ser nula.
Una llave foránea debe coincidir con una
valor de una llave primaria.
Una columna solo debe contener valores
consistentes con el formato de datos
definidos para la columna.
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 - MODELO DE DATOS

ANALISIS CONCEPTUAL ENTIDAD-RELACION
DE DATOS - DEFINICIONES DE ENTIDADES

DISEÑO DE
DISEÑO BASE DE
DATOS

- DEFINICIONES DE TABLAS,
CONSTRUCCIÓN INDICES, VISTAS, CLUSTERS Y DE
DE LA BASE ESPACIO.
DE DATOS
CONSTRUCCION

BASE DE DATOS OPERACIONAL

 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 PK FK1 FK2

llave
Nulos NN.U NN NN NN NN
único
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 Para CURSO

# fecha de inicio # Código
fecha de terminación Nombre
grado Tomado por Cuota
Duración

Enseñado
Para por
Registrado en

INSTRUCTOR
# ID
ESTUDIANTE Nombre
# Id Apellido
Nombre Numero telefono
Apellido
Numero telefono
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

COLUMNA
TIPO DE
LLAVE
NULOS
UNICO
EJEMPLO

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.
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

COLUMNA INST_ID NOMBRE APELLIDO NOTELEF
TIPO DE
LLAVE
NULOS NN NN NN
UNICO
EJEMPLO

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” .
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 / NN NN NN
Únicos
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_I NOMBRE APELLIDO NOTELEF

D
Tipo de
llave

Nulos / NN NN NN
Únicos

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.

MATRICULA Para
Curso
# Fecha de inicio # código
Fecha terminación Nombre
grado Cuota
Tomado
por duración

Para

Registrado por

Nombre de la tabla MATRICULA

Columna FECHA_REG FECHA_TER GRADO CODIGO ESTUDIO

CURSO
TIPO DE PK.FK1 PK.FK2
LLAVE
NULOS / NN NN.UI NN.UI
UNICOS
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
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.

OCUPADO POR
MUELLE BARCO
# numero # numero de registro
longitud ciudad de registro

Desembarcado
en
# id
Nombre de la tabla MUELLE

COLUMNA M_NUM LON

TIPO DE PK
LLAVE
NULOS / NN,U NN
UNICOS
EJEMPLO 344 100
075 1000
554 500
341 80
570 600
Nombre de la tabla BARCO

COLUMNA NUM_REG CIU_REG NOMBRE TIPO M_NUM

TIPO DE PK PK FK
LLAVE

NULO / NN,UI NN,UI NN U2

UNICO
EJEMPLO 134X89 PANAMA SUN KING CRUISE 554
004455678 NORWAY PRINCESS TANKER 570
1114088 UNITED EXXON 075
STATES POSSIDON
Y1.0998-1 UNITED RUN YACHR 344
STATES RUNNER
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
EMPLEADO
# * id BAJO LAS
ORDENES DE
* nombre
* apellido

Nombre de la tabla: EMPLEADO:

Columna EMP_ID NOMBRE APELLIDO MGR_ID

Tipo de llave PK FK

Nulos/ NN.U NN NN
Únicos
7450 MARY SMITH
5579 LESLIE STERNE 7450
6714 JANET GETRY 5579
Ejemplos 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.

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

PERSONA
# * id CASADO

* nombre
* apellido

Columna PERS_ID NOMBRE APELLIDO ID_ESP

Tipo de llave PK FK

Nulos/ NN.U NN NN U2
Únicos
7450 MARY SMITH ------
5579 SUSAN JONES 9451
Ejemplos 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.

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.

EMPLEADO

# numero clave DEPARTAMENTO

nombre Asignado a
apellido # número
empleo nombre
Responsabilidad de
fecha de pago localización
salrio
comisión

Bajo las ordenes de

Gerente de

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.
 LINEA PRODUCTO

# número para número

cantidad # nombre
precio requerido por unidad de medida
medio de

ContenidoORDEN
en

# número
fecha de pedido
Contenedora de

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.

LINEA DE ORDEN

# Número de item
Descripción

LINEA DE ORDEN DE Por PRODUCTO

PRODUCTO # código
Cantidad precio estándar
Precio actual Mostrado en

LINEA DE ORDEN DE ORDEN

SERVICIO # número
Cuota
Parte de

Nombre de la Tabla: PRODUCTO Nombre de la Tabla: ORDEN

Columna NUM-
Nombre de la Tabla: ORDEN
LÍNEA_ORDEN_PRODUCTO TIPO DE
LLAVE PK
Col Nulos/

umn Únicos N.N.U

 a
Tipos de
llave
Nulos/
Únicos

Nombre de la Tabla: LÍNEA_ORDEN_SERVICIO

Columna
Tipos de
llave
Nulos/
Únicos

PRACTICA 6-3

DEPARTAMENTO INQUILINO
Crear un diseño inicial de la base de datos
# número # id
nombre
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.
PISO

# número

Alquilado por

EDIFICIO El arrendatario de

# id
nombre
dirección
 Ubicado en

Contenedor de

Ubicado en
Contenedor de

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.

LOCALIDAD DE EMPLEADO
VENTA
Representado por # id
nombre
# código apellido
nombre responsable
cuota
posición

compuesta de

Dentro de

Nombre de la Tabla

Columna
Tipo de llave
Nulos/ Único

Ejemplo
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 INDIVIDUAL

OFICINA id #
arredantario de
# Id del edificio SOCIEDAD
# Número de oficina rentado por código #
arredentario de
COMPAÑIA
número#
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.
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 INDIVIDUAL

OFICINA id #
Arrendatario de

# Id del edificio SOCIEDAD

# Número de oficina Rentado por código #
Arrendatario de
COMPAÑIA
número#
Rentado por
Arrendatario de

Nombre de la tabla: OFICINA

 Columna ID_EDIFICI NUM_OFICINA ID_IND COD_SOCIAL NUM_CIA
O
tipo de llave PK PK PK1 PK2 PK3
Nulos/ NN.U1 NN.U1
Única
1024 101 30045
512 210 A4431
977 144 54532
Ejemplo 3041 510 10844
2371 430 54101
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.
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 INDIVIDUAL

OFICINA
Arrendatario de id #

# Id del edificio SOCIEDAD

# Número de oficina Rentado por código #
Arrendatario de
COMPAÑIA
número#
Rentado por
Arrendatario de

Nombre de la Tabla: OFICINA

 Columna ID-EDIFICIO NUM_OFICINA REN_DE TIPO_RENTA
tipo de llave PK PK FK
Nulos/ Única NN.U1 NN.U1 NN NN
1024 101 30045 I
512 210 A4431 S
Ejemplo 977 144 54532 I
3041 510 10844 C
2371 430 54101 C
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.

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.

ESTUDIANTE MUNICIPIO
# código
DE nombre
# Id La casa de
apellido ESTADO
Nombre id
#
De nombre del estado
La casa de
PAIS
id
#
De nombre
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

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.

ESTUDIANTE MUNICIPIO
# código
DE nombre
# Id La casa de
apellido ESTADO
Nombre id
#
De nombre del estado
La casa de
PAIS
id
#
De nombre
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

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.

número de clave
EMPLEADO #
nombre
apellido

EMPLEADO EMPLEADO POR

ASALARIADO HONORARIOS
salario costo por hora
costos por horas extras

Miembro de

Asignado a

compuesto de compuesto de
DEPARTAMENTO SINDICATO
código número
#

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.
Crear una sola tabla para el supertipo y mapear los subtipos dentro de esta tabla. La
tabla sencilla contendrá instancias de todos los subtipos.

TABLA
A A

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.

 EJEMPLO

Mapear el supertipo EMPLEADO y sus subtipos dentro se una sola tabla EMPLEADO

número de clave
EMPLEADO #
nombre
apellido

EMPLEADO EMPLEADO POR

ASALARIADO HONORARIOS
salario costo por hora
costos por horas extras

Miembro de

Asignado a

compuesto de compuesto de
DEPARTAMENTO SINDICATO
código número
#

Nombre de la Tabla: EMPLEADO

Columna NUM NOMBR APELLID TIPO_ SAL COSTO_H HR_EXT NO_SIN COD_DEP
_ E O EMPLE R R D TO
CVE A
Tipo de PK PK1 PK2
llave
Nulos/ NN.U NN NN NN NN
Único
4579 JAIME JUÁREZ E 29000 40
6631 KAREN DIDONAT E 25000 35
O
1190 MIGUEL ALVAREZ E 42700 40
370 MARIA PENA E 44050 30
Ejemplo 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 LOPEZ NE 10.50 15.75 180 15
A
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.

A TABLA B

C TABLA B

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.
EJEMPLO

Hacer el supertipo EMPLEADO en dos tablas(Una para cada subtipo). Primero crear una
tabla separada para el subtipo EMPLEADO ASALARIADO

número de clave
EMPLEADO #
nombre
apellido

EMPLEADO EMPLEADO POR

ASALARIADO HONORARIOS
salario costo por hora
costos por horas extras

Miembro de

Asignado a

compuesto de compuesto de
DEPARTAMENTO SINDICATO
código número
#

Nombre de la Tabla: EMPLEADO ASALARIADO

Columna NUM_ NOMBRE APELLIDO SAL COD_DEPTO

CVE
Tipo de PK FK
llave
Nulos/ NN.U NN NN NN
Único
4579 JAIME JUÁREZ 29000 40
6631 KAREN DIDONATO 25000 35
1190 MIGUEL ALVAREZ 42700 40
Ejemplo 370 MARIA PENA 44050 30
800 PEDRO MEDINA 38450 35

EJEMPLO
Crear una tabla separada para el subtipo EMPLEADO POR HONORARIOS
número de clave
EMPLEADO #
nombre
apellido

EMPLEADO EMPLEADO POR

ASALARIADO HONORARIOS
salario costo por hora
costos por horas extras

Miembro de

Asignado a

compuesto de compuesto de
DEPARTAMENTO SINDICATO
código número
#
Nombre de la Tabla: EMPLEADO POR HONORARIOS.

Column NUM_C NOMB APELL COSTO_ HR_EX NO_SIN COD_DEP

a VE RE IDO HR TR D TO
Tipo de PK PK1 PK2
llave
Nulos/ NN.U NN NN NN
Único
4579 JAIME JUÁRE 11.7 14.3 362 40
Z
6631 KARE DIDON 10.00 3.56 315 35
N ATO
1190 MIGUE ALVAR 8.25 2.4 185 40
L EZ
Ejemplo 370 MARIA PENA 13.4 11.5 178 30
800 PEDRO MEDIN 11.2 15.8 415 35
A
7147 JOSE LUNA 8.50 12.75 201 35
6794 JULIA OSUN 6.75 11.50 150 30
A
941 JAVIER BARB 12.00 18.00 201 45
A
1020 JOSE GOME 9.50 16.15 201 30
Z
3500 CLAU LOPEZ 10.50 15.75 180 45
DIA
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.

LINEA DE ORDEN

# Número de item
Descripción

LINEA DE ORDEN DE Por PRODUCTO

PRODUCTO # código
Cantidad precio estándar
Precio actual Mostrado en

LINEA DE ORDEN DE ORDEN

SERVICIO # número
Cuota
Parte de

Compuesto de

Nombre de la Tabla: PRODUCTO Nombre de la Tabla: ORDEN

Columna NUM-
ORDEN
TIPO DE
LLAVE PK
Nombre de la Tabla: LÍNEA_ORDEN Nulos/
Únicos N.N.U

Columna
Tipo de
llave
Nulos/
Único