sici-4030 base de datos prof. nelliud d. torres data modeling - diseño conceptual y lógico

SICI-4030Base de Datos

Prof. Nelliud D. Torres

Data Modeling - Diseño Conceptual y Lógico

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

DIFERENTES TIPOS DE DIAGRAMAS

Volver a los

Objetivos

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.

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)

EJEMPLOS DE DIAGRAMAS - 1

Apéndice ASímbolos

EJEMPLOS DE DIAGRAMAS - 2

Apéndice ARelaciones, opcionalidad y grado o cardinalidad

DIAGRAMA DE CHEN

Volver a los

Objetivos

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.

Connectivity (opcionalidad) and Cardinality

Professor teaches Course

Connectivity

1 M

(0,3) (1,1)

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

Database Systems: Design, Implementation, & Management, 7 th Edition, Rob & Coronel

Diferentes Relaciones en el Diagrama de Chen

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


Teaches

Advises

Course Enrollment

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


Placed

prepared

OrderLine

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


has

Manages

Assigment

NOTACIÓN DE TABLAS

Volver a los

Objetivos

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.

DIAGRAMA QUE UTILIZA EL LIBRO

Volver a los

Objetivos

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

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

DIAGRAMA QUE SE VA A UTILIZAR EN EL CURSO

Volver a los

Objetivos

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.

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.

EJEMPLOS ENTIDADES EN DIAGRAMAS

ESTADIO (PARQUE)nombredirecciónteléfonocapacidad sillascapacidad carros

CLIENTEnúmeronombredirecciónteléfonocréditoe-mail

ESTUDIANTEnúmeronombreedadgeneroseguro socialdepartamentoigsescuela procedencia

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.

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

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”

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)

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

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



tomar ESTUDIANTEnúmeronombreseguro social

CURSOcódigosemestredescripción



poseer EDIFICIOidlocalizacióndescripción

APARTAMENTOnúmeropisocantidad cuartos

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Í:


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





CadaCURSO puede ser tomado por uno o más ESTUDIANTE(S)

tomar

tomado por

ESTUDIANTEnúmeronombreseguro social




Cada APARTAMENTO tiene que ser poseido por uno y solo un EDIFICIO

poseer

poseido por

EDIFICIOidlocalizacióndescripción

APARTAMENTOnúmeropisocantidad cuartos

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

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)

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.

MUCHOS A UNO - EJEMPLO

habitado por

estar asignado

M∞

1



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.

MUCHOS A MUCHOS - EJEMPLO

M

∞

M

∞

tomar

tomado por


ESTUDIANTEnúmeronombreseguro social

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.

UNO A UNO - EJEMPLO

11

posee

está asignado

MOTORnúmerodescripción

CARROtablillamarcamodelo

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

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.

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.

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

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

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.

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

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.

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

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

RESOLVIENDO RELACIONES MUCHOS A MUCHOS

Volver a los

Objetivos

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.

Ejemplo - 1• Resuelva esta relación M:M

ESTUDIANTE

#* número * nombre * seguro social

CURSO

#* código* nombre* duracción

tomar

tomado por

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

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


Barra UID

Relación de muchos (M)

ANOTACIONES IMPORTANTES - 2• Las relaciones que parten de una entidad de

intersección o asociativa deben ser siempre mandatorias (TIENE).

• Ejemplo:

MATRICULA


Tiene

Tiene

ANOTACIONES IMPORTANTES - 3• Las entidades de intersección o asociativa

muchas veces representan procesos reales de las empresas.

• Ejemplo:

MATRICULA


Matricula es un proceso real dentro de una institución universitaria.

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

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

CUANDO DEBE PONERSE LA BARRA UID EN LAS RELACIONES

(cuando un FK debe ser parte del PK)

Volver a los

Objetivos

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:

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

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

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.

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.

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?

EJERCICIOS PARA RESOLVER

Volver a los

Objetivos

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


LIBRO

#* isbn * titulo * cantidad páginas

AUTOR

#* id* nombre

escrito por

escribir


Pág. 202

COMPARACIÓN ENTRE EL DIAGRAMA DEL LIBRO Y EL QUE SE VA A UTILIZAR EN EL CURSO

Volver a los

Objetivos

Relación Uno a Uno

LIBRO

CURSO

Referencia

PERSON

casada con

casada con

Relación Uno a Muchos

LIBRO

CURSO

Referencia

registrado

registrado para

PATIENT PATIENT HISTORY

Relación Muchos a Muchos

LIBRO

CURSO

Referencia

asignado a

asignado a

EMPLOYEE PROJECT

Relación Muchos a Muchos

LIBRO

CURSO

Referencia

tomar

ofrecido a

EMPLOYEE COURSE

Múltiples Relaciones

LIBRO

Referencia

CURSOPROFESSOR COURSE

incluyeSCHEDULEasignado aasignado aincluirse en

cualificado para

cualificado por

Relación con Entidad Asociativa

LIBRO

CURSO

Referencia

EMPLOYEE COURSEcorresponder a

CERTIFICATE

poseer

pertenecer a

generar

MATRIZ DE RELACIONES

Volver a los

Objetivos

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.

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

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

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.

CONVERTIR LA SIGUIENTE MATRIZ A ERD - 2

CONVERTIR LA SIGUIENTE MATRIZ A ERD - 1

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.

PASO - 1 DETERMINAR RELACIÓN

El siguiente ejemplo marca las relaciones entre las entidades.

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:

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.

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

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.

PASO - 4 (cont.) Determinar el grado de la Relación

Finalmente la opcionalidad y cardinalidad quedarían así:

DEPARTAMENTO


EMPLEADO


responsable de

asignado a

sólo un departamento

Uno o más empleados

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


EMPLEADO


responsable de

asignado a

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

sici-4030 base de datos prof. nelliud d. torres data modeling - diseño conceptual y lógico

Documents