1 Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y LógicoSICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico

2 OBJETIVOS Explicar los diferentes tipos de diagramas brevemente para propósitos de posibles conversiones. Diagrama de Chen Notación de Tablas Diagrama que utiliza el libro Diagrama que se va a utilizar en el curso Resolviendo Relaciones Muchos a Muchos Cuando debe ponerse la barra UID en las relaciones Ejercicios para Resolver Comparación entre el diagrama del libro y el que se va a utilizar en el curso Matriz de Relaciones

3 DIFERENTES TIPOS DE DIAGRAMASVolver a los Objetivos

4 USO DE DIAGRAMAS Existen muchos tipos de diagramas para crear los ERD (Entity Relational Diagram) de las Bases de Datos No existe un estándar establecido de cuál formato debe utilizarse. Para efectos del curso, vamos a utilizar una versión modificada de la que utiliza Oracle. Para los trabajos que hay que entregar y los exámenes vamos a utilizar ese modelo modificado únicamente. También vamos a examinar resumidamente los otros tipos de notaciones para familiarizarnos con ellos.

5 TIPOS DE DIAGRAMAS Hoffer-Prescott-MacFadden Notation. Visio Pro 2003.Allfusion ERwin Data Modeler 4.1 SP1. Sybase Power Designer 11.1. Oracle Designer 10G Modelo Chen (Modelo E-R creado por Peter Chen) Versión de Oracle modificada (que vamos a utilizar en el curso)

6 EJEMPLOS DE DIAGRAMAS - 1Símbolos Apéndice A

7 EJEMPLOS DE DIAGRAMAS - 2Relaciones, opcionalidad y grado o cardinalidad Apéndice A

8 DIAGRAMA DE CHEN Volver a los Objetivos

9 Componentes del Modelo E-R (Chen)Entity Relationship Composite entity Attribute Como este modelo se utiliza con bastante frecuencia, se discute un poco más detallado que los demás. Yufei Yuan Course Web Site

10 Connectivity (opcionalidad) and CardinalityProfessor 1 teaches M Course (1,1) (0,3) Optional entity Mandatory entity Cardinality Estos conceptos se van a explicar más adelante. Se ponen aquí para tenerlo de referencia en caso de que tengan que trabajar con un diagrama que tenga este formato. Yufei Yuan Course Web Site

11 Diferentes Relaciones en el Diagrama de ChenDatabase Systems: Design, Implementation, & Management, 7th Edition, Rob & Coronel

12 Ejemplo del modelo Chen para un Sistema Estudiantil de RegistroAttributes Course Number Description Instructor ID Name Room Rank Teaches Course Instructor M 1 1 1 Advises M M Course Enrollment Student 1 M Major Student Number Course Number Student Name Student Number Grade Yufei Yuan Course Web Site

13 Ejemplo del modelo Chen para un Sistema de Procesamiento de OrdenesProduct Number Description Customer Name Unit price S Name S ID Address Products Customer 1 1 Salesman Placed M prepared 1 M S ID OrderLine M Order M 1 Date Order Number Product Number Customer Name Order Number Quantity Yufei Yuan Course Web Site

14 Ejemplo del modelo Chen para una Compañía de ConstrucciónProject name Project Number Employee Number Employee Name Manager ID Hire Date Project Manages Employee 1 M 1 M M has Assigment M 1 Job class Assignment Number Hours Hour Rate Project Number Job Code Employee Number Job Description Yufei Yuan Course Web Site

15 NOTACIÓN DE TABLAS Volver a los Objetivos

16 Tables Customers (CustomerName, Address) Salesman (S-ID, S-Name)Products (Prod#, Description, UnitPrice) Orders (OrderNo, Date, S-ID, CustomerName) OrderLine (OrderNo, Prod#, Quantity) Más adelante hablaremos de este tipo de notación. Yufei Yuan Course Web Site

17 DIAGRAMA QUE UTILIZA EL LIBROVolver a los Objetivos

18 DIAGRAMA QUE UTILIZA EL LIBRO -1Entity symbols Attribute symbols A special entity that is also a relationship Relationship symbols Relationship degrees specify number of entity types involved Relationship cardinalities specify how many of each entity type is allowed Basic E-R notation (Figure 3-2) 8

19 DIAGRAMA QUE UTILIZA EL LIBRO - 2Sample E-R Diagram (Figure 3-1) Este diagrama se lee al revés del que vamos a utilizar en el curso Pág. 93 3

20 DIAGRAMA QUE SE VA A UTILIZAR EN EL CURSOVolver a los Objetivos

21 DIAGRAMA ORACLE MODIFICADOAhora vamos a explicar el modelo que vamos a utilizar en el curso. Es una variación de Oracle e integra símbolos de otros tipos de diagramas. Será utilizado para los proyectos y el examen. En la página(Moodle) hay un documento que tiene los diferentes símbolos y se pueden utilizar al momento de crear un ERD.

22 REGLAS PARA DIAGRAMAR Las entidades van en una caja (rectangular) sin bordes. Los nombres de las entidades se escriben en singular y en mayúsculas. Cada nombre debe ser único. Se puede poner un alias a una entidad que tenga más de un nombre entre paréntesis. Los nombres de los atributos van en letra minúscula.

23 EJEMPLOS ENTIDADES EN DIAGRAMASCLIENTE número nombre dirección teléfono crédito ESTUDIANTE número nombre edad genero seguro social departamento igs escuela procedencia ESTADIO (PARQUE) nombre dirección teléfono capacidad sillas capacidad carros

24 RELACIONES Como se mencionó anteriormente, es una asociación bi-direccional (ambas direcciones) e imprescindible entre dos entidades o entre una entidad y ella misma.

25 RELACIONES - SINTAXIS La sintaxis que vamos a utilizar para comprender las relaciones es: CADA entidad-1 nombre de la relación entidad-2 TIENE QUE SER O PUEDER SER Opcionalidad UNO O MÁS O UNO Y SOLO UNO Cardinalidad

26 RELACIONES - COMPONENTESNombre de la relación – Se utiliza una palabra que haga sentido al unir la relación entre dos entidades Opcionalidad – Sólo se puede indicar “tiene que ser” o “puede ser” Grado o Cardinalidad - Sólo se puede indicar “Uno o más” o “Uno y solo uno”

27 RELACIONES - EJEMPLOS DEPARTAMENTO - EMPLEADO ESTUDIANTE - CURSOCada DEPARTAMENTO puede ser habitado por uno o más EMPLEADO(s) ESTUDIANTE - CURSO Cada ESTUDIANTE puede tomar uno o más CURSO(s) EDIFICIO – APARTAMENTO Cada EDIFICIO tiene que poseer uno o más APARTAMENTO(s)

28 RELACIONES - DIAGRAMASLas relaciones se pueden diagramar de la siguiente forma: Una línea une las dos entidades El nombre de la relación va en minúsculas El diagrama de Opcionalidad es: Puede ser Tiene que ser El diagrama de Grado o Cardinalidad es: Uno o más Uno y solo uno

29 RELACIONES – DIAGRAMAS - EJEMPLOSDEPARTAMENTO - EMPLEADO Cada DEPARTAMENTO puede ser habitado por uno o más EMPLEADO(s) El nombre de la relación se pone arriba o abajo de la línea que une las dos entidades. DEPARTAMENTO id localización descripción EMPLEADO numero nombre seguro social habitado por

30 RELACIONES – DIAGRAMAS - EJEMPLOSESTUDIANTE - CURSO Cada ESTUDIANTE puede tomar uno o más CURSO(s) ESTUDIANTE número nombre seguro social CURSO código semestre descripción tomar

31 RELACIONES – DIAGRAMAS - EJEMPLOSEDIFICIO – APARTAMENTO Cada EDIFICIO tiene que poseer uno o más APARTAMENTO(s) EDIFICIO id localización descripción APARTAMENTO número piso cantidad cuartos poseer

32 IMPORTANTE UNA RELACIÓN ES BIDIRECCIONAL. Por lo tanto hay que detallar y diagramar la relación también del otro lado. FINALMENTE LOS DIAGRAMAS QUEDARÍAN ASÍ:

33 RELACIONES – DIAGRAMAS - EJEMPLOSDEPARTAMENTO - EMPLEADO Cada DEPARTAMENTO puede ser habitado por uno o más EMPLEADO(s) Cada EMPLEADO tiene que estar asignado a uno y solo un DEPARTAMENTO DEPARTAMENTO id localización descripción EMPLEADO numero nombre seguro social habitado por estar asignado

34 RELACIONES – DIAGRAMAS - EJEMPLOSESTUDIANTE - CURSO Cada ESTUDIANTE puede tomar uno o más CURSO(s) CadaCURSO puede ser tomado por uno o más ESTUDIANTE(S) ESTUDIANTE número nombre seguro social CURSO código semestre descripción tomar tomado por

35 RELACIONES – DIAGRAMAS - EJEMPLOSEDIFICIO – APARTAMENTO Cada EDIFICIO tiene que poseer uno o más APARTAMENTO(s) Cada APARTAMENTO tiene que ser poseido por uno y solo un EDIFICIO EDIFICIO id localización descripción APARTAMENTO número piso cantidad cuartos poseer poseido por

36 EJEMPLO DE UN ERD DE UN SISTEMA DE COMPRASORDEN número tipo fecha ARTÍCULO numero descripción peso emitida para incluido en almacenado en originado por el depósito para el originador de CLIENTE número nombre seguro social ALMACEN id descripción localización

37 EXISTEN 3 TIPOS DE RELACIONES ENTRE LAS ENTIDADESMuchos a uno (M : 1) Muchos a muchos (M : M) Uno a uno (1 : 1)

38 MUCHOS A UNO M a 1 o M : 1 Tiene un grado de uno o más en una parte de la relación y de uno y solo uno en la otra parte. Es el tipo de relación más común dentro de las bases de datos. Las relaciones de muchos a uno que sea obligatoria en ambas partres es rara.

39 MUCHOS A UNO - EJEMPLO 1 M∞ DEPARTAMENTO id localización descripciónhabitado por EMPLEADO numero nombre seguro social estar asignado 1 M∞

40 MUCHOS A MUCHOS M a M o M : MTiene un grado de uno o más en ambas partes. También es un tipo de relación común. Pueden ser opcionales en una o en ambas partes.

41 MUCHOS A MUCHOS - EJEMPLOCURSO código semestre descripción ESTUDIANTE número nombre seguro social tomar tomado por M ∞ M ∞

42 UNO A UNO 1 a 1 o 1 : 1 Tiene un grado de uno y sólo uno en ambas partes. Este tipo de relación es raro y más aún si ambas partes son obligatorias. Este tipo de relación podría indicar que ambas relaciones se puedan convertir en solo una.

43 UNO A UNO - EJEMPLO 1 1 CARRO tablilla MOTOR posee marca número modelodescripción posee está asignado 1 1

44 CONVENCIONES DE LOS ATRIBUTOSLos nombres de los atributos se crean pensando en el usuario (debe entenderlos) EL nombre de la entidad no debe incluirse como parte del nombre del atributo Deben ser específicos y descriptivos. (Ej. cantidad devuelta, fecha de nacimiento, etc.)

45 SÍMBOLOS PARA LOS ATRIBUTOS* - Significa obligatorio (el atributo debe ser llenado por el usuario, no se puede dejar en blanco) 0 – Significa opcional, el usuario no está obligado a llenar ese atributo. # - Identifica un atributo que es UID (también hay que ponerle el símbolo * obligatoriamente). (#) - UID segundario. Por ejemplo: seguro social.

46 UID’s EN RELACIONES Cuando deseamos que un UID se utilice en otra entidad relacionada, utilizamos el símbolo: Cuando deseamos incluir un UID como un campo foráneo (foreign key) en la otra entidad relacionada, utilizamos el símbolo: IMPORTANTE: En la entidad que lleva uno de esos dos símbolos, en el ERD NO se le especifica el atributo.

47 UID’s QUE USAN RELACIONESUna entidad puede ser identificada mediante una relación Consideremos el siguiente ejemplo; En la Banca, a cada banco se le asigna un número único. Dentro de cada banco, a cada cuenta se le asigna un número único. ¿Cuál sería entonces el UID de la entidad CUENTA? BANCO #* número CUENTA #* número manejador de manejada por

48 UID’s QUE USAN RELACIONES (Cont)Solución: Cada instancia de la entidad CUENTA se puede identificar por el atributo número y el BANCO específico al cual la cuenta pertenece. El número del BANCO es parte del UID de la entidad CUENTA BANCO #* número CUENTA #* número #* número_banco manejador de manejada por

49 UID’s QUE USAN RELACIONES (Cont)En este tipo de relación cualquier campo foráneo que provenga de otra entidad, no se puede representar (escribir) en esa entidad, por lo tanto se utiliza la barra UID para representar ese campo en la otra entidad. La barra UID indica que la relación con BANCO es parte del UID de CUENTA. BANCO #* número CUENTA #* número manejador de manejada por

50 UID SECUNDARIOS Y ARTIFICIALESUn UID secundario es aquel que nos puede permitir localizar una instancia en particular sin utilizar el UID ‘principal’. Por ejemplo en la entidad EMPLEADO, el número o código de empleado se puede utilizar ya que permite identificar por separado a cada instancia. Entonces, ¿Cuál podría se un UID secundario? EMPLEADO #* número nombre seguro_social fecha_nacimiento edad

51 UID SECUNDARIOS Y ARTIFICIALES (Cont.)En este caso el UID secundario debe ser el seguro social. Los demás atributos que se muestran aquí no cumplen con la condición de ser identificadores únicos. Se pone el símbolo (#) que lo identifica como UID secundario. EMPLEADO #* número nombre (#) seguro_social fecha_nacimiento edad

52 UID SECUNDARIOS Y ARTIFICIALES (Cont. - 2)¿Qué podríamos utilizar para identificar a la entidad CLIENTE? El seguro social de un cliente puede ser cuestionable y el teléfono puede cambiar constantemente. CLIENTE nombre dirección teléfono

53 UID SECUNDARIOS Y ARTIFICIALES (Cont. - 3)En este caso necesitamos utilizar un UID artificial que nos permita identificar a cada cliente en particular. Podría utilizarse el nombre código por ejemplo. Nota: Los UID artificiales se utilizan a menudo en el caso de que la empresa no tenga un atributo natural que identifique plenamente a una entidad. CLIENTE #* código nombre dirección teléfono

54 RESOLVIENDO RELACIONES MUCHOS A MUCHOSVolver a los Objetivos

55 Resolviendo Relaciones Muchos a MuchosLas relaciones M:M se resuelven con la creación de una nueva entidad. Se le llama entidad de intersección o asociativa. Finalmente se incluye dos relaciones M:1 para unir la entidad de intersección con las entidades que tenían una relación M:M.

56 Ejemplo - 1 Resuelva esta relación M:M ESTUDIANTE #* número * nombre* seguro social CURSO #* código * nombre * duracción tomar tomado por

57 Solución - 1 Nota: La entidad asociativa necesita tener el número deESTUDIANTE #* número * nombre * seguro social CURSO #* código * nombre * duracción para MATRICULA #* fecha matriculado o nota Parte de Nota: La entidad asociativa necesita tener el número de estudiante, código del curso y fecha de matrícula como su UID para que cada instancia (record) pueda ser única (valor del UID no se repita).

58 ANOTACIONES IMPORTANTESUna entidad de intersección o secundaria se puede reconocer por que tiene dos relaciones (muchas veces con su barra de UID) que la relacionan como muchos (M). Ejemplo: Barra UID MATRICULA #* fecha matriculado o nota Relación de muchos (M)

59 ANOTACIONES IMPORTANTES - 2Las relaciones que parten de una entidad de intersección o asociativa deben ser siempre mandatorias (TIENE). Ejemplo: Tiene MATRICULA #* fecha matriculado o nota Tiene

60 ANOTACIONES IMPORTANTES - 3Las entidades de intersección o asociativa muchas veces representan procesos reales de las empresas. Ejemplo: Matricula es un proceso real dentro de una institución universitaria. MATRICULA #* fecha matriculado o nota

61 ANOTACIONES IMPORTANTES - 4Algunas entidades de intersección o asociativa tienen un UID que no depende de las relaciones. Ejemplo: El UID de la entidad VENDEDOR y PRODUCTO no forma parte del UID de la entidad CATALOGO. En cambio son Foreign Key (FK). VENDEDOR #* id * nombre * seguro social incluido en CATALOGO #* id * precio * medida para PRODUCTO #* número * nombre * descripción incluido en para

62 ANOTACIONES IMPORTANTES - 5Algunas entidades de intersección o asociativa puede ser que no tengan atributos. Es la única excepción a la regla de que toda entidad debe tener atributos. Ejemplo: No tiene ningún atributo la entidad ACTOR-PELICULA. PELICULA #* id * título * categoría ACTOR #* código * nombre para ACTOR-PELICULA escenario para actor en

63 CUANDO DEBE PONERSE LA BARRA UID EN LAS RELACIONES (cuando un FK debe ser parte del PK)Volver a los Objetivos

64 DEFINIR FK COMO PARTE DEL PKLa situación más común para definir un Foreign Key como parte del Primary Key es cuando estamos rompiendo las relaciones muchos a muchos. En este caso al crear una tabla de intercepción, muchas veces no tiene uno o más atributos que la puedan identificiar por si misma. Bajo este caso, se necesita definir los PK de ambas tablas como FK de la tabla de intersección e inclusive definirlas también como PK. A continuación vemos un ejemplo:

65 DEFINIR FK COMO PARTE DEL PKEl siguiente ejemplo muestra una relación resuelta de muchos a muchos entre actor y película. La entidad intermedia ESTELARIZA sólo tiene un atributo que indica si un artista gano o no un óscar por la estelarización de una película. Como no tiene identificadores únicos, necesita el número del ACTOR y el código de la película. En este caso se necesitan ambos para poder identificar una instancia de la entidad ESTELARIZA. ACTOR #* número * nombre * fecha nacimiento PELICULA #* código * titulo * año filmación pertenecer ESTELARIZA o oscar hecha por hacer Parte de

66 DEFINIR FK COMO PARTE DEL PKEste otro ejemplo solo consta de dos entidades. La entidad principal (strong) llamanda EMPLEADOy la entidad secundaria (weak) llamada DEPENDIENTE. ¿Cuál de las dos alternativas sería la correcta? EMPLEADO #* número * nombre * género DEPENDIENTE #* número * nombre * género tener A B pertenecer EMPLEADO #* número * nombre * género DEPENDIENTE pertenecer tener

67 DEFINIR FK COMO PARTE DEL PKSiempre debemos pensar en los datos que componen las tablas ya que nos puede ayudar a determinar si se pone la barra de UID o no. En este caso la relación podría trabajar de ambas formas. Sin embargo si existen dos empleados (esposos) que tenga un mismo dependiente, se tiene que poner la barra de UID para identificar cada dependiente con su respectivo EMPLEADO. En este caso se tendría que repetir la información del DEPENDIENTE dos veces. (no estaría normalizado) Se podría evitar esta repetición con una entidad intermedia.

68 DEFINIR FK COMO PARTE DEL PKPor otro lado, si nunca se da la posibilidad de haber más de un EMPLEADO encargado de un dependiente, se podría poner la alternativa B. Esta alternativa incluso permite cambiar el nombre del empleado si se indicó uno incorrecto. Como no es parte del PK el cambio es sumamente sencillo. Si fuera parte del PK y en la Base de datos se indico que no se puede cambiar el valor de un PK, entonces se tendría que eliminar el record por completo y volverlo a escribir con el nuevo número de empleado. Este procedimiento puede ser más complicado de programar y menos eficiente.

69 RECOMENDACIONES Utilice la barra de UID siempre que la entidad no tenga uno o más atributos que la definan. Trate siempre de evitar la barra UID si se puede. Analice la posibilidad de eliminar una instancia de la entidad principal. ¿Cómo esto afecta a la entidad que tiene el FK o el FK-PK?

70 EJERCICIOS PARA RESOLVERVolver a los Objetivos

71 Ejercicios para resolver - 1CLIENTE #* id * nombre * dirección PRODUCTO #* código * nombre ordenador de ordenado por Nota: Debe terminar con cuatro entidades: ITEM, ORDEN, CLIENTE y PRODUCTO

72 Ejercicios para resolver - 2LIBRO #* isbn * titulo * cantidad páginas AUTOR #* id * nombre escrito por escribir

73 Ejercicios para resolver - 3Pág. 202

74 COMPARACIÓN ENTRE EL DIAGRAMA DEL LIBRO Y EL QUE SE VA A UTILIZAR EN EL CURSOVolver a los Objetivos

75 Relación Uno a Uno LIBRO Referencia PERSON CURSO casada con

76 Relación Uno a Muchos LIBRO Referencia CURSO registrado PATIENTPATIENT HISTORY registrado CURSO registrado para

77 Relación Muchos a MuchosLIBRO Referencia EMPLOYEE PROJECT asignado a CURSO asignado a

78 Relación Muchos a MuchosLIBRO Referencia EMPLOYEE COURSE tomar CURSO ofrecido a

79 Múltiples Relaciones LIBRO Referencia CURSO SCHEDULE asignado aincluye incluirse en PROFESSOR COURSE cualificado para CURSO cualificado por

80 Relación con Entidad AsociativaLIBRO Referencia CURSO EMPLOYEE COURSE poseer CERTIFICATE generar pertenecer a corresponder a

81 MATRIZ DE RELACIONES Volver a los Objetivos

82 Matriz de Relaciones Es una herramienta que ayuda a relacionar las diferentes entidades. También ayuda a dar un nombre a la relación entre las entidades. Recolecta una información adicional sobre las relaciones entre un conjunto de entidades.

83 EJEMPLO DE UNA MATRIZ DE RELACIONESFACILIDAD SLIP SOLICITUD CLIENTE SERVICIO ubicar estar ubicado en crear rentado por creada por contener rentar contenido en

84 DIAGRAMA QUE SE UTILIZÓ PARA LA MATRIZFACILIDAD #* id * nombre * dirección * ciudad * estado * zipcode DIAGRAMA QUE SE UTILIZÓ PARA LA MATRIZ SLIP #* id * numero * largo * renta anual * nombre del bote * tipo de bote SOLICITUD #* id * descripción * status * estimado de horas * horas usadas o fecha próximo servicio contener ubicar estar ubicado en creada por rentado por SISTEMA RENTA DE LOTES DE BOTES contener rentar contenido en CLIENTE #* id * nombre * dirección * ciudad * estado * zip code SERVICIO #* id * descripción

85 DETALLES IMPORTANTES AL UTILIZAR LAS MATRICES DE RELACIONESRelaciona las entidades de la parte izquierda con las entidades de la parte derecha. Deben ponerse todas las entidades y en el mismo orden en ambos lados. Al encontrar dos entidades que se relaciones, se pone el nombre de la relación, de no relacionarse, se pone una raya. La línea del medio divide y crea un efecto de espejo entre las relaciones.

86 CONVERTIR LA SIGUIENTE MATRIZ A ERD - 2

87 CONVERTIR LA SIGUIENTE MATRIZ A ERD - 1

88 CINCO PASOS AL MODELAR LAS RELACIONES EN LA MATRIZDetermine si hay relación entre dos entidades. Déle nombre a cada dirección de la relación. Determine la opcionalidad de cada dirección. Determine el grado o cardinalidad de cada dirección. Lea en voz alta la relación y coteje si hace sentido.

89 PASO - 1 DETERMINAR RELACIÓNEl siguiente ejemplo marca las relaciones entre las entidades.

90 PASO - 2 NOMBRAR CADA RELACIÓNAlgunas sugerencias para nombres son: integrado por comprador de operador de responsable de poseedor de habitado por emisora de el receptor de integrante de suplidor de operado por bajo la responsabilidad de poseído por habitante de emitida por para

91 PASO - 3 Determinar la Opcionalidad de la RelaciónPor ejemplo una relación entre EMPLEADO y DEPARTAMENTO se puede analizar de la siguiente forma: ¿Debe asignase un Empleado a un Departamento? ¿Esto es siempre así?, ¿Existe alguna situación en donde un Empleado no esté asignado a un departamento? No existe, por lo tanto, siempre tiene que estar asignado a un DEPARTAMENTO.

92 PASO - 3 (cont.)Determinar la Opcionalidad de la Relación¿Debe un DEPARTAMENTO ser responsable de un EMPLEADO? ¿Esto es siempre así? No, un DEPARTAMENTO no tiene que ser responsable de un EMPLEADO siempre. DEPARTAMENTO id localización descripción EMPLEADO numero nombre seguro social responsable de asignado a puede tiene

93 PASO - 4 Determinar el grado de la RelaciónTomando el mismo ejemplo de la relación entre EMPLEADO y DEPARTAMENTO debemos hacernos las siguientes preguntas: ¿Puede un EMPLEADO ser asignado a más de un DEPARTAMENTO? NO, un EMPLEADO sólo puede ser asignado a un DEPARTAMENTO. ¿Puede un DEPARTAMENTO ser responsable de uno o más EMPLEADOS? Sí, un DEPARTAMENTO puede ser responsable de uno o más EMPLEADOS.

94 PASO - 4 (cont.) Determinar el grado de la RelaciónFinalmente la opcionalidad y cardinalidad quedarían así: DEPARTAMENTO id localización descripción EMPLEADO numero nombre seguro social responsable de asignado a sólo un departamento Uno o más empleados

95 PASO - 5 Validar la RelaciónLea la relación en voz alta en ambas direcciones. Deben tener sentido en el contexto del negocio para el cual se está diseñando la base de datos. Cada DEPARTAMENTO puede ser responsable de uno o mas EMPLEADOS Cada EMPLEADO tiene que estar asignado a uno y solo un DEPARTAMENTO DEPARTAMENTO id localización descripción EMPLEADO numero nombre seguro social responsable de asignado a

96 REFERENCIAS Modern Database Management 8th Edition, Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden Yufei Yuan Course Web Site Database Systems: Design, Implementation, and Management, Seventh Edition, Rob and Coronel Profesor Alberto Prado - Universidad Interamericana, Recintro Metro