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?

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 Localización. Resultado

# identificador. Fecha de Contacto

Si Un Atributo tiene múltiples valores, se crea una entidad adicional y lo relaciona con la Regla de la Segunda Forma entidad original 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 Balance. Fecha de Apertura. Localización de Banco

# Numero. Nombre.

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.

Para

CUENTA # Codigo de Grado Numero de Maestro Descricion de Grado Nombre del Curso

Para

CURSO

Formado Con

# Numero de Curso. Nombre de Curso Numero de Maestro Código de departamento Nombre de departamento Nombre de maestro Apellido de maestro

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 # ID Nombre Descripción

SURTIDO POR

VENDEDOR # Codigo Nombre

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.

Para

CATALAGO # Precio actual Cantidad del paquete Unidad de medida

VENDEDOR

DETERMIN ADO CON

# Codigo Nombre

Para ASIGNADA


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 Apellido Nombre Numero telefonico

CURSO # Codigo. Nombre 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 # Id Apellido Nombre Numero telefonico

CURSO # Codigo. Nombre Cuota 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 # Id Nombre

ASIGNADO A

PROYECTO # Nemero 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 # Id Nombre

PROYECTO # Numero. 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

# ID Nombre Descripción

VENDEDOR # Codigo Nombre

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

# Precio actual Cantidad del paquete Unidad de medida

Para ASIGNADA


Para

VENDEDOR

DETERMIN ADO CON

# Codigo Nombre

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

# Numero de catalogo Pecio actual Cantidad de paquete Unidad de medida

Para

VENDEDOR # Codigo Nombre DETERMINA DO CON

Para ASIGNADA


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.

PROTAGONIZ ADA POR

PELICULA # ID Titulo Categoría

ACTOR

PROTAGONIST A EN

# Código Apellido real Nombre real Fecha de 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

PELICULA # Id Ttulo Categoria

PROTAGONISTA EN

ACTOR # Código Apellido real 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.”

MIENBRO

INTERESADO EN

APLICAION

# Identificador 

Nombre



Apellido. Titulo Cuota recibida



Direccion. Numero telefonico Tipo de menbresia

AREA DE

DE INTERES PARA

# Codigo  Nombre

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 # ID Nombre Apellido.

EL COMPRADOR DE

ORDENADO POR

PRODUCTO # Numero Nombre Existencia.

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.

EQUIPO

COMPANIA

DIVICION

DENTRO DE

COMPUESTO DE

DEPARTAMENTO

DEPARTAMENTO

DENTRO DE COMPUESTO POR

DIVISION

EQUIPO


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


DIVISION


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 ASALARIADO

EMPLEADO POR HONORARIOS

Costo por hora. Costo por horas extras.

Salario

ASIGNADO A

COMPUIESTO DE COMPUIESTO DE

EMPLEADO ASALARIADO

EMPLEADO 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 PLANEADOR

AVION DE 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

ESTUDIANTE # Id Apellido. Nombre Numero telefónico.

TOMADO POR

CURSO # Código Nombre Duración Cuota.

ENSEÑADO POR

MAESTRO DE

INSTRUCTOR

# Id  Nombre  Apellido  Numero telefónico

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

C 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 DE OFICINA

TRABAJO MANUAL

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

C

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 # Id. Fecha de Vigencia

TIENE

CONTRATO # Id. 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.

TRABAJA PARA

SOCIO # ID Nombre Apellido.

COMPAÑIA # Codigo Nombre 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 # Id Apellido Nombre

COMPAÑÍA # Codigo. 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

# Codigo Direccion

PERSONA # Id 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

renta # De la fecha o la fecha

Arrendatario de

Para Rentado por

Departamento # Código Dirección

# Id Nombre Apellido

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

# ID APELLIDO NOMBRE

OCUPADO

PUESTO # TITULO DE TRABAJO O DESCRIPCION DE TRABAJO

POR EMPLEADA POR PATRON DE

INCLUIDO EN

PATRON DE DEPARTAMENTO # Codigo Direccion

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

PERSONA

OCUPANTE DE

# ID APELLIDO NOMBRE

PUESTO HISTORIA DEL PUESTO OCUPADO POR

# TITULO DE TRABAJO O DESCRIPCION DE TRABAJO

SUJETO A TRABAJADO EN

HISTORIA DE LA COMPAÑIA

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

TRABAJADO POR

¿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 POR

PROTAGONISTA EN

ACTOR CINTA

LA COPIA

# identificador

# NUMERO FORMATO

TITULO CATEGORIA

RENTADA POR EL ARRENDATARIO DE CLIENTE # NUMERO DE SOCIO APELLIDO NOMBRE NUMERO TELEFONO DIRECCION

PELICULA

CODIGO NOMBRE ARTISTICO NOMBRE REAL APELLIDO REAL FECHA DE NACIMIENTO

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

MIEMBRO

INTERESADO EN

COMPUTADORA

# ID NOMBRE APELLIDO TITULO PAGARES RECIBIDOS DIRECCION NUMERO TELEFONO TIPO DE MEMBRESIA

PLATAFORMA DE

# Id DESCRIPCION 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 ------------100 200

APELLIDO -------------SANCHEZ BRIONES

NOMBRE -------------DAVID JAIME

NO_DEPTO ---------------10 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

100 210 210 405 375

APELLIDO

SANCHEZ ARIAS BRIONES GOMEZ JONHSON

NOMBRE

DAVID ADRIANA JAIME JOSE LUCIA

NO_DEPTO

10 15 10 12 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 104 104 105 103 105

NO_CUENTA

BALANCE

77560 77956 89570 65890 76964

12.000.60 100.10 65.776.00 15.001.85 5.00

FECHA_APERTURA 21.Oct.89 16.Ene.85 10.Mar.71 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

100 210 210 405 375

APELLIDO


NOMBRE


NO_DEPTO

10 15 10 12 06

Tabla Empleados EJEMPLO ¿ como es que la tabla CUENTA viola las reglas de las llaves primarias?

Llave Primaria NO_BANCO 104 104 103 105

NO_CUENTA

BALANCE

77560 77956 89570

12.000.60 100.10 65.776.00 15.001.85 5.00

76964

FECHA_APERTURA 21.Oct.89 16.Ene.85 10.Mar.71 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

100 210 210 405 375

APELLIDO


NOMBRE


NO_DEPTO

10 15 10 12 06

NOMINA

9710 8730 1157 3394 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 NO_EMP

100 210 210 405 375

Llave Alterna APELLIDO


NOMBRE


NO_DEPTO

10 15 10 12 06

NOMINA

9710 8730 1157 3394 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 NO_EMP

Llave Foránea APELLIDO

100 210 210 405 375

Llave primaria NO_DEPTO 10 15 12 25


NOMBRE


NO_DEPTO

10 15 10 12 25

NOMINA

9710 8730 1157 3394 4477

NOMBRE_DEPTO FINANZAS OPERACIONES MANUFACTURA 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 104 150 103 105 TABLA BANCO

NOMBRE_BANCO CARNET COMERMEX BANCOMER BANAMEX

Llave Foránea Llave Primaria NO_BANCO NO_CUENTA 103 75760 104 77956 150 89570 103 33347 105 76954 TABLA CUENTA

BALANCE 12.000.60 100.10 65.776.00 15.001.85 5.00

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 Integridad de entidades Integridad referencial Integridad de columnas

Integridad definida por el usuario

EXPLICACION 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 ANALISIS

DISEÑO

MODELO CONCEPTUAL DE DATOS

- MODELO DE DATOS ENTIDAD-RELACION - DEFINICIONES DE ENTIDADES

DISEÑO DE BASE DE DATOS

CONSTRUCCIÓN DE LA BASE DE DATOS CONSTRUCCION

BASE DE DATOS OPERACIONAL

- DEFINICIONES DE TABLAS, INDICES, VISTAS, CLUSTERS Y DE ESPACIO.

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

Tipo llave Nulos único Ejemplo

PK

NOMBRE

APELLIDO

PUESTO

FECHA_PAGO

SAL

COMM

MGR

NODEPT

FK1

FK2

NN.U

NN

NN

NN

NN

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

CURSO # Código Nombre Cuota Duración

Tomado por

Enseñado por

Para Registrado en

INSTRUCTOR ESTUDIANTE # Id Nombre Apellido Numero telefono

# ID Nombre 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 TIPO DE LLAVE NULOS UNICO EJEMPLO

INST_ID

NOMBRE

APELLIDO

NN

NN

NN

NOTELEF

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 Tipo de llave Nulos / Únicos Ejemplo

INST_ID

NOMBRE

APELLIDO

NN

NN

NN

10 18 73 95 301

NANCY MARIA PETE KATHY ERIC

HALL GONZALEZ CASSIDY ANDRONICA CAMPLIN

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.

NOTELEF

798-2251 756-1891 301-2291 483-9221 535-3166

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

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

Tipo de llave

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

# Fecha de inicio Fecha terminación grado

Tomado por

Curso # código Nombre Cuota duración

Para

Registrado por

Nombre de la tabla MATRICULA Columna TIPO DE LLAVE NULOS / UNICOS EJEMPLOS

FECHA_REG FECHA_TER GRADO

NN 20.JUL.91 05.SEP.95 14.JUN.91 08.MAY.91 05.MAY.91

29.JUL.91 ---------28.JUN.91 28.JUN91 21.MAY.91

--------------A B A

CODIGO CURSO PK.FK1

ESTUDIO

NN.UI

NN.UI

344 401 717 717 401

47593 15402 94572 94572 51304

PK.FK2

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 longitud

# numero de registro ciudad de registro Desembarcado en

Nombre de la tabla MUELLE COLUMNA TIPO DE LLAVE NULOS / UNICOS EJEMPLO

# id nombre apellido M_NUMtelefono PK

LON

NN,U

NN

344 075 554 341 570

100 1000 500 80 600

Nombre de la tabla BARCO COLUMNA NUM_REG TIPO DE PK LLAVE

CIU_REG PK

NOMBRE

NULO / UNICO EJEMPLO

NN,UI

NN,UI

NN

134X89 004455678 1114088

PANAMA NORWAY UNITED STATES UNITED STATES PANANA

SUN KING PRINCESS EXXON POSSIDON RUN RUNNER AVION

Y1.0998-1 A02345

TIPO

M_NUM FK

U2 CRUISE TANKER

554 570 075

YACHR

344

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 * nombre * apellido

BAJO LAS ORDENES DE

Nombre de la tabla: EMPLEADO: Columna

EMP_ID

NOMBRE

APELLIDO

MGR_ID

Tipo de llave

PK

Nulos/

NN.U

NN

NN

7450

MARY

SMITH

5579

LESLIE

STERNE

7450

6714

JANET

GETRY

5579

9451

BILL

ABLE

7450

3040

JUAN

GOMEZ

9451

FK

Únicos

Ejemplos

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 * nombre * apellido

CASADO

Columna

PERS_ID

NOMBRE

APELLIDO

ID_ESP

Tipo de llave

PK

Nulos/

NN.U

NN

NN

U2

7450

MARY

SMITH

------

5579

SUSAN

JONES

9451

6714

JANET

GENTRY

3040

9451

BILL

JONES

5579

3040

JERRY

JOHNSON

6714

FK

Únicos

Ejemplos

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 nombre apellido empleo fecha de pago salrio comisión

DEPARTAMENTO

Asignado a Responsabilidad de

Bajo las ordenes de Gerente de

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

LINEA #  número  cantidad  precio

PRODUCTO

para

ContenidoORDEN en #

 número  fecha de pedido

Contenedora de

#

requerido por medio de

 número  nombre  unidad de medida

Nombre de la tabla Columna Tipo de llave Nulos/ Único

Ejemplo


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 PRODUCTO  Cantidad  Precio actual

PRODUCTO

Por

 código  precio estándar

#

 número

Mostrado en

LINEA DE ORDEN DE SERVICIO  Cuota

#

ORDEN

Parte de

Nombre de la Tabla: PRODUCTO

Columna

COD-

PRECIO-

PROD

PROD

Nombre de la Tabla: ORDEN

TIPO DE LLAVE

Columna

ORDEN TIPO DE

PK

LLAVE

Nulos/ Únicos

N.N.U

N.N

Columna Tipos de llave Nulos/ Únicos

Nombre de la Tabla: LÍNEA_ORDEN_SERVICIO

Tipos de llave Nulos/ Únicos

PK

Nulos/

Nombre de la Tabla: LÍNEA_ORDEN_PRODUCTO

Columna

NUM-

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

DEPARTAMENTO #

Alquilado por

 número

Ubicado en Contenedor de PISO #

 número

Ubicado en Contenedor de EDIFICIO #

 id  nombre  dirección

El arrendatario de

INQUILINO #  id  nombre

Nombre de la Tabla Columna Tipo de llave Nulos/ Único

Ejemplo


Ejemplo


Ejemplo


Ejemplo


Ejemplo


Ejemplo


Ejemplo


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 VENTA # 



código nombre

EMPLEADO

Representado por responsable

compuesta de

Dentro de Nombre de la Tabla Columna Tipo de llave Nulos/ Único

Ejemplo

#    

id nombre apellido cuota posición


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 EntidadRelació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

OFICINA

Rentado por

INDIVIDUAL #  id

arredantario de # #

 Id del edificio  Número de oficina

rentado por arredentario de

rentado por arrendatario de

SOCIEDAD #  código COMPAÑIA #  número

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

# #

 Id del edificio  Número de oficina

Rentado por Arrendatario de



INDIVIDUAL #  id SOCIEDAD #  código COMPAÑIA #  número

Nombre de la tabla: OFICINA Columna

ID_EDIFICIO NUM_OFICINA

ID_IND

COD_SOCIAL

NUM_CIA

PK1

PK2

PK3

tipo de llave

PK

PK

Nulos/

NN.U1

NN.U1

1024

101

512

210

977

144

3041

510

10844

2371

430

54101

Única

Ejemplo

30045 A4431 54532

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.

# #

INDIVIDUAL #  id


OFICINA  Id del edificio  Número de oficina

SOCIEDAD #  código


COMPAÑIA #  número

Rentado por Arrendatario de Nombre de la Tabla: OFICINA Columna

ID-EDIFICIO

NUM_OFICINA

REN_DE

tipo de llave

PK

PK

FK

Nulos/ Única

NN.U1

NN.U1

NN

NN

1024

101

30045

I

512

210

A4431

S

977

144

54532

I

3041

510

10844

C

2371

430

54101

C

Ejemplo

TIPO_RENTA

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.

MUNICIPIO #  código  nombre

ESTUDIANTE

DE La casa de

#

Id  apellido  Nombre

ESTADO id  nombre del estado

#

De La casa de

#

De La casa de

Nombre de la Tabla: ESTUDIANTE

Columna Tipo de llave Nulos/ Único

Ejemplo

PAIS  id  nombre

Nombre de la Tabla: MUNICIPIO


Ejemplo

Nombre de la tabla: ESTADO


Ejemplo

Nombre de la tabla: PAÍS


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 #

DE #

 Id  apellido  Nombre

MUNICIPIO  código  nombre

La casa de ESTADO id  nombre del estado

#

De La casa de

PAIS #

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

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

#

número de clave  nombre  apellido

EMPLEADO

EMPLEADO ASALARIADO


 salario

 costo por hora  costos por horas extras Miembro de

Asignado a compuesto de

DEPARTAMENTO  código

compuesto de

SINDICATO #  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 B C

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

#


EMPLEADO

EMPLEADO ASALARIADO


 salario


Asignado a compuesto de DEPARTAMENTO  código

compuesto de SINDICATO #  número

Nombre de la Tabla: EMPLEADO Columna NUM NOMBR APELLID TIPO_ _ E O EMPLE CVE A Tipo de PK llave Nulos/ NN.U NN NN NN Único 4579 JAIME JUÁREZ E 6631 KAREN DIDONAT E O 1190 MIGUEL ALVAREZ E 370 MARIA PENA E Ejemplo 800 PEDRO MEDINA E 7147 JOSE LUNA NE 6794 JULIA OSUNA NE 941 JAVIER BARBA NE 985 JOSE GOMEZ NE 969 CLAUDI LOPEZ NE A

SAL

COSTO_H HR_EXT NO_SIN COD_DEP R R D TO PK1

PK2 NN

29000 25000

40 35

42700 44050 38450

40 30 35 35 30 45 30 15

8.50 6.75 12.00 9.50 10.50

12.75 11.50 18.00 16.15 15.75

201 150 201 201 180

Las columnas de la tabla EMPLEADO son derivadas de los atributos y las relaciones del supertipo y todos sus subtipos.

Tipo de Entidad Supertipo

Columnas para Atributos NUM_CVE, NOMBRE,

Columnas FK para Relaciones 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.

TABLA B

A 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

#


EMPLEADO

EMPLEADO ASALARIADO


 salario


Asignado a compuesto de

compuesto de

DEPARTAMENTO  código

SINDICATO #  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

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

Único

Ejemplo

EJEMPLO Crear una tabla separada para el subtipo EMPLEADO POR HONORARIOS

EMPLEADO

EMPLEADO ASALARIADO  salario

#

número de clave  nombre  apellido EMPLEADO POR HONORARIOS


Asignado a compuesto de DEPARTAMENTO  código

compuesto de #

SINDICATO  número

Nombre de la Tabla: EMPLEADO POR HONORARIOS. Column a Tipo de

NUM_C VE PK

NOMB RE

APELL IDO

NN.U

NN

NN

4579

JAIME

JUÁRE

COSTO_ HR

HR_EX TR

NO_SIN D PK1

COD_DEP TO PK2

llave Nulos/

NN

Único 11.7

14.3

362

40

10.00

3.56

315

35

8.25

2.4

185

40

Z 6631

KARE

DIDON

N

ATO

MIGUE

ALVA

L

REZ

370

MARIA

PENA

13.4

11.5

178

30

800

PEDRO

MEDIN

11.2

15.8

415

35

1190 Ejemplo

A 7147

JOSE

LUNA

8.50

12.75

201

35

6794

JULIA

OSUN

6.75

11.50

150

30

12.00

18.00

201

45

9.50

16.15

201

30

10.50

15.75

180

45

A 941

1020

JAVIE

BARB

R

A

JOSE

GOME Z

3500

CLAU DIA

LOPEZ

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 PRODUCTO  Cantidad  Precio actual

PRODUCTO

Por

 código  precio estándar

#

 número

Mostrado en

LINEA DE ORDEN DE SERVICIO  Cuota

#

ORDEN

Parte de Compuesto de

Nombre de la Tabla: PRODUCTO

Columna

COD-

PRECIO-

PROD

PROD

TIPO DE LLAVE

Columna

NUMORDEN

TIPO DE PK

LLAVE

Nulos/ Únicos

Nombre de la Tabla: ORDEN

PK

Nulos/ N.N.U

N.N

Únicos

N.N.U

Nombre de la Tabla: LÍNEA_ORDEN


SeparataER1

Recommend Documents