sici-4030 base de datos prof. nelliud d. torres data modeling - diseño conceptual y lógico
TRANSCRIPT
![Page 1: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/1.jpg)
SICI-4030Base de Datos
Prof. Nelliud D. Torres
Data Modeling - Diseño Conceptual y Lógico
![Page 2: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/2.jpg)
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
![Page 3: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/3.jpg)
DIFERENTES TIPOS DE DIAGRAMAS
Volver a los
Objetivos
![Page 4: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/4.jpg)
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.
![Page 5: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/5.jpg)
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)
![Page 6: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/6.jpg)
EJEMPLOS DE DIAGRAMAS - 1
Apéndice ASímbolos
![Page 7: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/7.jpg)
EJEMPLOS DE DIAGRAMAS - 2
Apéndice ARelaciones, opcionalidad y grado o cardinalidad
![Page 8: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/8.jpg)
DIAGRAMA DE CHEN
Volver a los
Objetivos
![Page 9: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/9.jpg)
Componentes del Modelo E-R (Chen)
Entity
Relationship
Composite entity
Attribute
Yufei Yuan Course Web Site
Como este modelo se utiliza con bastante frecuencia, se discute un poco más detallado que los demás.
![Page 10: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/10.jpg)
Connectivity (opcionalidad) and Cardinality
Professor teaches Course
Connectivity
1 M
(0,3) (1,1)
Mandatory entityOptional entity
Cardinality
Yufei Yuan Course Web Site
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.
![Page 11: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/11.jpg)
Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel
Diferentes Relaciones en el Diagrama de Chen
![Page 12: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/12.jpg)
Ejemplo del modelo Chen para un Sistema Estudiantil de Registro
CourseNumber
Description Instructor ID
Name
RankRoom
Course Instructor
CourseNumber
Grade
StudentNumber
Student
StudentNumber
Major
StudentName
1
M
M
M
M
11
1
Attributes
Yufei Yuan Course Web Site
Teaches
Advises
Course Enrollment
![Page 13: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/13.jpg)
Ejemplo del modelo Chen para un Sistema de Procesamiento de
OrdenesProductNumber
Description
Customer Name
Address
Unit price
Products Customer
ProductNumber
Quantity
OrderNumber
Order
OrderNumber
Date
CustomerName
1
M
M
M
1
1
S Name S ID
Salesman
1
M S ID
Yufei Yuan Course Web Site
Placed
prepared
OrderLine
![Page 14: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/14.jpg)
Ejemplo del modelo Chen para una Compañía de Construcción
ProjectNumber
Project name
Job Code Job
Description
HourRate
Manager ID
Project Employee
ProjectNumber
Hours
EmployeeNumber
Job class
EmployeeNumber
EmployeeName
1M
M
M 1
1
M
AssignmentNumber
Hire Date
Yufei Yuan Course Web Site
has
Manages
Assigment
![Page 15: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/15.jpg)
NOTACIÓN DE TABLAS
Volver a los
Objetivos
![Page 16: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/16.jpg)
Tables
• Customers (CustomerName, Address)
• Salesman (S-ID, S-Name)
• Products (Prod#, Description, UnitPrice)
• Orders (OrderNo, Date, S-ID, CustomerName)
• OrderLine (OrderNo, Prod#, Quantity)
Yufei Yuan Course Web Site
Más adelante hablaremos de este tipo de notación.
![Page 17: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/17.jpg)
DIAGRAMA QUE UTILIZA EL LIBRO
Volver a los
Objetivos
![Page 18: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/18.jpg)
Relationship degrees specify number of entity types involved
Entity symbols
A special entity that is also a relationship
Relationship symbols
Relationship cardinalities specify how many of each entity type is allowed
Attribute symbols
Basic E-R notation (Figure 3-2)
DIAGRAMA QUE UTILIZA EL LIBRO -1
![Page 19: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/19.jpg)
Sample E-R Diagram (Figure 3-1)
DIAGRAMA QUE UTILIZA EL LIBRO - 2
Pág. 93 Este diagrama se lee al revés del que vamos a utilizar en el curso
![Page 20: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/20.jpg)
DIAGRAMA QUE SE VA A UTILIZAR EN EL CURSO
Volver a los
Objetivos
![Page 21: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/21.jpg)
DIAGRAMA ORACLE MODIFICADO
• Ahora 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.
![Page 22: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/22.jpg)
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.
![Page 23: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/23.jpg)
EJEMPLOS ENTIDADES EN DIAGRAMAS
ESTADIO (PARQUE)nombredirecciónteléfonocapacidad sillascapacidad carros
CLIENTEnúmeronombredirecciónteléfonocréditoe-mail
ESTUDIANTEnúmeronombreedadgeneroseguro socialdepartamentoigsescuela procedencia
![Page 24: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/24.jpg)
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.
![Page 25: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/25.jpg)
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
UNO O MÁS
O
UNO Y SOLO UNO
Opcionalidad
Cardinalidad
![Page 26: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/26.jpg)
RELACIONES - COMPONENTES
• Nombre 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”
![Page 27: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/27.jpg)
RELACIONES - EJEMPLOS
DEPARTAMENTO - EMPLEADOCada DEPARTAMENTO puede ser habitado por uno o más EMPLEADO(s)
ESTUDIANTE - CURSOCada ESTUDIANTE puede tomar uno o más CURSO(s)
EDIFICIO – APARTAMENTOCada EDIFICIO tiene que poseer uno o más APARTAMENTO(s)
![Page 28: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/28.jpg)
RELACIONES - DIAGRAMASLas relaciones se pueden diagramar de la siguiente forma:1. Una línea une las dos entidades2. El nombre de la relación va en minúsculas3. El diagrama de Opcionalidad es:
• Puede ser• Tiene que ser
4. El diagrama de Grado o Cardinalidad es:• Uno o más• Uno y solo uno
![Page 29: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/29.jpg)
RELACIONES – DIAGRAMAS - EJEMPLOS
DEPARTAMENTO - EMPLEADOCada DEPARTAMENTO puede ser habitado por uno o más
EMPLEADO(s)
habitado por
El nombre de la relación se pone arriba o abajo de la línea que une las dos entidades.
DEPARTAMENTOidlocalizacióndescripción
EMPLEADOnumeronombreseguro social
![Page 30: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/30.jpg)
RELACIONES – DIAGRAMAS - EJEMPLOS
ESTUDIANTE - CURSOCada ESTUDIANTE puede tomar uno o más CURSO(s)
tomar ESTUDIANTEnúmeronombreseguro social
CURSOcódigosemestredescripción
![Page 31: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/31.jpg)
RELACIONES – DIAGRAMAS - EJEMPLOS
EDIFICIO – APARTAMENTOCada EDIFICIO tiene que poseer uno o más APARTAMENTO(s)
poseer EDIFICIOidlocalizacióndescripción
APARTAMENTOnúmeropisocantidad cuartos
![Page 32: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/32.jpg)
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Í:
![Page 33: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/33.jpg)
RELACIONES – DIAGRAMAS - EJEMPLOS
DEPARTAMENTO - EMPLEADOCada DEPARTAMENTO puede ser habitado por uno o más
EMPLEADO(s)
Cada EMPLEADO tiene que estar asignado a uno y solo un DEPARTAMENTO
habitado por
estar asignado
DEPARTAMENTOidlocalizacióndescripción
EMPLEADOnumeronombreseguro social
![Page 34: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/34.jpg)
RELACIONES – DIAGRAMAS - EJEMPLOS
ESTUDIANTE - CURSOCada ESTUDIANTE puede tomar uno o más CURSO(s)
CadaCURSO puede ser tomado por uno o más ESTUDIANTE(S)
tomar
tomado por
ESTUDIANTEnúmeronombreseguro social
CURSOcódigosemestredescripción
![Page 35: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/35.jpg)
RELACIONES – DIAGRAMAS - EJEMPLOS
EDIFICIO – APARTAMENTOCada EDIFICIO tiene que poseer uno o más APARTAMENTO(s)
Cada APARTAMENTO tiene que ser poseido por uno y solo un EDIFICIO
poseer
poseido por
EDIFICIOidlocalizacióndescripción
APARTAMENTOnúmeropisocantidad cuartos
![Page 36: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/36.jpg)
EJEMPLO DE UN ERD DE UN SISTEMA DE COMPRAS
el originador de
originado por
emitida para
incluido en
almacenado en
el depósito para
CLIENTEnúmeronombreseguro social
ALMACENiddescripciónlocalización
ARTÍCULOnumerodescripciónpeso
ORDENnúmerotipofecha
![Page 37: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/37.jpg)
TIPOS DE RELACIONES
EXISTEN 3 TIPOS DE RELACIONES ENTRE LAS ENTIDADES
1. Muchos a uno (M : 1)
2. Muchos a muchos (M : M)
3. Uno a uno (1 : 1)
![Page 38: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/38.jpg)
MUCHOS A UNOM a 1 o M : 1
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.
2. Es el tipo de relación más común dentro de las bases de datos.
3. Las relaciones de muchos a uno que sea obligatoria en ambas partres es rara.
![Page 39: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/39.jpg)
MUCHOS A UNO - EJEMPLO
habitado por
estar asignado
M∞
1
EMPLEADOnumeronombreseguro social
DEPARTAMENTOidlocalizacióndescripción
![Page 40: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/40.jpg)
MUCHOS A MUCHOSM a M o M : M
1. Tiene un grado de uno o más en ambas
partes.
2. También es un tipo de relación común.
3. Pueden ser opcionales en una o en
ambas partes.
![Page 41: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/41.jpg)
MUCHOS A MUCHOS - EJEMPLO
M
∞
M
∞
tomar
tomado por
CURSOcódigosemestredescripción
ESTUDIANTEnúmeronombreseguro social
![Page 42: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/42.jpg)
UNO A UNO1 a 1 o 1 : 1
1. Tiene un grado de uno y sólo uno en ambas partes.
2. Este tipo de relación es raro y más aún si ambas partes son obligatorias.
3. Este tipo de relación podría indicar que ambas relaciones se puedan convertir en solo una.
![Page 43: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/43.jpg)
UNO A UNO - EJEMPLO
11
posee
está asignado
MOTORnúmerodescripción
CARROtablillamarcamodelo
![Page 44: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/44.jpg)
CONVENCIONES DE LOS ATRIBUTOS
1. Los nombres de los atributos se crean pensando en el usuario (debe entenderlos)
2. EL nombre de la entidad no debe incluirse como parte del nombre del atributo
3. Deben ser específicos y descriptivos. (Ej. cantidad devuelta, fecha de nacimiento, etc.)
![Page 45: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/45.jpg)
SÍMBOLOS PARA LOS ATRIBUTOS
1. * - Significa obligatorio (el atributo debe ser llenado por el usuario, no se puede dejar en blanco)
2. 0 – Significa opcional, el usuario no está obligado a llenar ese atributo.
3. # - Identifica un atributo que es UID (también hay que ponerle el símbolo * obligatoriamente).
4. (#) - UID segundario. Por ejemplo: seguro social.
![Page 46: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/46.jpg)
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.
![Page 47: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/47.jpg)
UID’s QUE USAN RELACIONES• Una 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?
manejador de
manejada por
BANCO#* número
CUENTA#* número
![Page 48: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/48.jpg)
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.
manejador de
manejada por
BANCO#* número
CUENTA#* número#* número_banco
El número del BANCO es parte del UID de la entidad CUENTA
![Page 49: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/49.jpg)
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.
manejador de
manejada por
BANCO#* número CUENTA
#* número
La barra UID indica que la relación con BANCO es parte del UID de CUENTA.
![Page 50: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/50.jpg)
UID SECUNDARIOS Y ARTIFICIALES
Un 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úmeronombreseguro_socialfecha_nacimientoedad
![Page 51: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/51.jpg)
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.
EMPLEADO#* número nombre(#) seguro_social fecha_nacimiento edad
Se pone el símbolo (#) que lo identifica como UID secundario.
![Page 52: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/52.jpg)
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.
CLIENTEnombredirecciónteléfono
![Page 53: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/53.jpg)
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
![Page 54: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/54.jpg)
RESOLVIENDO RELACIONES MUCHOS A MUCHOS
Volver a los
Objetivos
![Page 55: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/55.jpg)
Resolviendo Relaciones Muchos a Muchos
• Las 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.
![Page 56: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/56.jpg)
Ejemplo - 1• Resuelva esta relación M:M
ESTUDIANTE
#* número * nombre * seguro social
CURSO
#* código* nombre* duracción
tomar
tomado por
![Page 57: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/57.jpg)
Solución - 1ESTUDIANTE
#* número * nombre * seguro social
CURSO
#* código* nombre* duracciónpara
MATRICULA
#* fecha matriculadoo nota
Parte de
para
Parte de
Nota: La entidad asociativa necesita tener el número deestudiante, código del curso y fecha de matrícula como su UIDpara que cada instancia (record) pueda ser única (valor del UID no se repita).
![Page 58: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/58.jpg)
ANOTACIONES IMPORTANTES• Una 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:
MATRICULA
#* fecha matriculadoo nota
Barra UID
Relación de muchos (M)
![Page 59: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/59.jpg)
ANOTACIONES IMPORTANTES - 2• Las relaciones que parten de una entidad de
intersección o asociativa deben ser siempre mandatorias (TIENE).
• Ejemplo:
MATRICULA
#* fecha matriculadoo nota
Tiene
Tiene
![Page 60: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/60.jpg)
ANOTACIONES IMPORTANTES - 3• Las entidades de intersección o asociativa
muchas veces representan procesos reales de las empresas.
• Ejemplo:
MATRICULA
#* fecha matriculadoo nota
Matricula es un proceso real dentro de una institución universitaria.
![Page 61: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/61.jpg)
ANOTACIONES IMPORTANTES - 4• Algunas 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
PRODUCTO
#* número* nombre* descripciónpara
CATALOGO
#* id* precio* medida
incluido en
para
incluido en
![Page 62: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/62.jpg)
ANOTACIONES IMPORTANTES - 5• Algunas 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-PELICULAescenario para
para
actor en
![Page 63: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/63.jpg)
CUANDO DEBE PONERSE LA BARRA UID EN LAS RELACIONES
(cuando un FK debe ser parte del PK)
Volver a los
Objetivos
![Page 64: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/64.jpg)
DEFINIR FK COMO PARTE DEL PK• La 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:
![Page 65: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/65.jpg)
DEFINIR FK COMO PARTE DEL PK• El 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
pertenecerESTELARIZA
o oscar
hecha por
hacer
Parte de
![Page 66: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/66.jpg)
DEFINIR FK COMO PARTE DEL PK• Este 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éneropertenecer
tener
EMPLEADO
#* número * nombre * género
DEPENDIENTE#* número* nombre* géneropertenecer
tener
A
B
![Page 67: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/67.jpg)
DEFINIR FK COMO PARTE DEL PK• Siempre 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.
![Page 68: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/68.jpg)
DEFINIR FK COMO PARTE DEL PK• Por 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.
![Page 69: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/69.jpg)
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?
![Page 70: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/70.jpg)
EJERCICIOS PARA RESOLVER
Volver a los
Objetivos
![Page 71: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/71.jpg)
Ejercicios para resolver - 1
CLIENTE
#* id * nombre * dirección
PRODUCTO
#* código* nombre
ordenador de
ordenado por
Nota: Debe terminar con cuatro entidades: ITEM, ORDEN, CLIENTE y PRODUCTO
![Page 72: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/72.jpg)
Ejercicios para resolver - 2
LIBRO
#* isbn * titulo * cantidad páginas
AUTOR
#* id* nombre
escrito por
escribir
![Page 73: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/73.jpg)
Ejercicios para resolver - 3
Pág. 202
![Page 74: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/74.jpg)
COMPARACIÓN ENTRE EL DIAGRAMA DEL LIBRO Y EL QUE SE VA A UTILIZAR EN EL CURSO
Volver a los
Objetivos
![Page 75: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/75.jpg)
Relación Uno a Uno
LIBRO
CURSO
Referencia
PERSON
casada con
casada con
![Page 76: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/76.jpg)
Relación Uno a Muchos
LIBRO
CURSO
Referencia
registrado
registrado para
PATIENT PATIENT HISTORY
![Page 77: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/77.jpg)
Relación Muchos a Muchos
LIBRO
CURSO
Referencia
asignado a
asignado a
EMPLOYEE PROJECT
![Page 78: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/78.jpg)
Relación Muchos a Muchos
LIBRO
CURSO
Referencia
tomar
ofrecido a
EMPLOYEE COURSE
![Page 79: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/79.jpg)
Múltiples Relaciones
LIBRO
Referencia
CURSOPROFESSOR COURSE
incluyeSCHEDULEasignado aasignado aincluirse en
cualificado para
cualificado por
![Page 80: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/80.jpg)
Relación con Entidad Asociativa
LIBRO
CURSO
Referencia
EMPLOYEE COURSEcorresponder a
CERTIFICATE
poseer
pertenecer a
generar
![Page 81: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/81.jpg)
MATRIZ DE RELACIONES
Volver a los
Objetivos
![Page 82: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/82.jpg)
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.
![Page 83: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/83.jpg)
EJEMPLO DE UNA MATRIZ DE RELACIONES
FACILIDAD SLIP SOLICITUD CLIENTE SERVICIO
FACILIDAD ubicar
SLIPestar
ubicado encrear rentado por
SOLICITUD creada por contener
CLIENTE rentar
SERVICIOcontenido
en
![Page 84: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/84.jpg)
DIAGRAMA QUE SE UTILIZÓ PARA LA MATRIZ
ubicar estar ubicado en
rentar
rentado por
contener
creada por
contener
contenido en
SISTEMA RENTA DE LOTES DE
BOTES CLIENTE#* id* nombre* dirección* ciudad* estado* zip code
FACILIDAD#* id* nombre* dirección* ciudad* estado* zipcode
SERVICIO#* id* descripción
SOLICITUD#* id* descripción* status* estimado de horas* horas usadaso fecha próximo servicio
SLIP#* id* numero* largo* renta anual* nombre del bote* tipo de bote
![Page 85: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/85.jpg)
DETALLES IMPORTANTES AL UTILIZAR LAS MATRICES DE RELACIONES
• Relaciona 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.
![Page 86: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/86.jpg)
CONVERTIR LA SIGUIENTE MATRIZ A ERD - 2
![Page 87: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/87.jpg)
CONVERTIR LA SIGUIENTE MATRIZ A ERD - 1
![Page 88: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/88.jpg)
CINCO PASOS AL MODELAR LAS RELACIONES EN LA MATRIZ
1. Determine si hay relación entre dos entidades.
2. Déle nombre a cada dirección de la relación.
3. Determine la opcionalidad de cada dirección.
4. Determine el grado o cardinalidad de cada dirección.
5. Lea en voz alta la relación y coteje si hace sentido.
![Page 89: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/89.jpg)
PASO - 1 DETERMINAR RELACIÓN
El siguiente ejemplo marca las relaciones entre las entidades.
![Page 90: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/90.jpg)
PASO - 2 NOMBRAR CADA RELACIÓN
• 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
Algunas sugerencias para nombres son:
![Page 91: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/91.jpg)
PASO - 3 Determinar la Opcionalidad de la Relación
Por 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.
![Page 92: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/92.jpg)
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
idlocalizacióndescripción
EMPLEADO
numeronombreseguro social
responsable de
asignado a
puede
tiene
![Page 93: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/93.jpg)
PASO - 4 Determinar el grado de la Relación
Tomando 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.
![Page 94: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/94.jpg)
PASO - 4 (cont.) Determinar el grado de la Relación
Finalmente la opcionalidad y cardinalidad quedarían así:
DEPARTAMENTO
idlocalizacióndescripción
EMPLEADO
numeronombreseguro social
responsable de
asignado a
sólo un departamento
Uno o más empleados
![Page 95: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/95.jpg)
PASO - 5 Validar la Relación
Lea 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 EMPLEADOSCada EMPLEADO tiene que estar asignado a uno y solo un DEPARTAMENTO
DEPARTAMENTO
idlocalizacióndescripción
EMPLEADO
numeronombreseguro social
responsable de
asignado a
![Page 96: SICI-4030 Base de Datos Prof. Nelliud D. Torres Data Modeling - Diseño Conceptual y Lógico](https://reader033.vdocuments.site/reader033/viewer/2022061604/5665b43b1a28abb57c9034af/html5/thumbnails/96.jpg)
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