Base de Datos

Unidad 2
 Agenda

• Conjuntos Entidad
• Conjuntos Relación
• Cuestiones de Diseño
• Mapeo de Restricciones
• Llaves
• Diagrama Entidad Relación propuesta de Chen
• Extensiones de las características de los Diagramas E-R
• Aspectos del diseño en Diagramas ER
 Objetivos de Modelamiento de
Datos Conceptual
• Sintaxis. Documentar en forma precisa y clara los
requerimientos de información
• Comunicación del usuario. Se entiende fácilmente
la forma gráfica del modelo ER
• Fácil de desarrollar
• Definición del alcance. Provee una clara imagen
del alcance de los requerimientos de información
• Integración de múltiples aplicaciones
 Conjuntos Entidad
• Una Base de Datos puede ser modelada como :
– Una colección de entidades,
– Relaciones entre entidades.
• Una Entidad es un objeto que existe y es distinguido como
un objeto que existe y es distinguible de otro objetos.
Ejemplo: persona especifica, compañía, evento.
• Las entidades tienen atributos
Ejemplo: una persona tiene nombres y dirección
• Un Conjunto Entidad es un conjunto de entidades del
mismo tipo que comparte similares propiedades.
Ejemplo: conjunto de todas las personas, compañías,
arboles, feriados
 Conjunto Entidad Cliente y
Préstamo
Cliente Préstamo
Identificador nombre calle ciudad nro. monto
 Atributos
• Una entidad es representada por un conjunto de atributos, que son
propiedades descriptivas poseídas por todos los miembros de un
conjunto entidad.
Ejemplo:
cliente = (id-cliente, nombre-cliente, calle-cliente, ciudad-cliente)
préstamo = (numero-préstamo , monto)
• Dominio – el conjunto de valores permitidos para cada atributo
• Tipos de atributos:
– Atributos Simples y Compuestos.
– Atributos Único-Valor y Atributos Múltiple-Valor
• Ejm : atributo multivalorado: numero de fono
– Atributo Derivado
• Pueden ser calculados a partir de otros atributos
• Ejm : edad, dado una fecha de cumpleaños.
Atributos Compuestos
 Conjunto Relación
• Una relación es una asociación entre distintas entidades
Ejemplo:
Hayes deposito A-102
entidad cliente Conjunto Relación entidad Cuenta
• Un conjunto relación es una relación matemática entre n 
2 entidades, cada una tomada del conjunto entidad
{(e1, e2, … en) | e1  E1, e2  E2, …, en  En}

donde (e1, e2, …, en) es una relación

– Ejemplo:
(Hayes, A-102)  deposito
Conjunto Entidad “Prestar”
Cliente Préstamo
 Conjunto Relación (Continuación)
• Un atributo puede ser propiedad de un conjunto relación.
• Para una instancia, el conjunto relación depositar entre los
conjuntos entidad cliente y cuenta podrían tener el
atributo fecha de acceso
 El grado en un Conjunto Entidad
• Se refiere al numero de conjuntos entidad que participan en
un conjunto relación.
• El conjunto relación que relaciona dos conjuntos entidad
son binarios (su grado es 2). Generalmente muchos
conjuntos relación dentro de una Base de Datos son
binarios.
• El conjunto Relación podría envolver mas de dos conjuntos
entidad.
– Ejm. Suponga que los empleados de un banco podrían
tener ocupaciones (responsabilidades) en múltiples
sucursales, con diferentes ocupaciones en diferentes
sucursales. Luego existe un conjunto relación ternario
entre empleados, ocupaciones y sucursales
• Las relaciones entre mas de 2 conjuntos entidad son raras.
La mayoría son binarias.
 Mapeando Cardinalidades
• Expresa el numero de entidades con las una entidad
puede asociarse a través de un conjunto entidad.
• Muy utilizado en la descripción de conjuntos relación
binarios.
• Para un conjunto relación binario, el mapeo de la
cardinalidad debe ser uno de los sgtes tipos :
– Uno a uno
– Uno a muchos
– Muchos a uno
– Muchos a muchos
 Mapeando Cardinalidades

uno a uno Uno a muchos

Nota: Algunos elementos en A y B podrían no ser mapeados en cualquier
Elemento en el otro conjunto
 Mapeando Cardinalidades

Muchos a uno Muchos a muchos

Nota: Algunos elementos en A y B podrian no ser mapeados en cualquier
elemento en el otro conjunto.
Efecto del mapeo de Cardinalidades
en el diseño ER
• Podemos convertir el atributo “fecha de acceso (Access-date)” en un atributo de cuenta,
en lugar de un atributo de la relación, si asumimos que cada cuenta tiene solamente un
cliente
• Ejm: la relación de cuenta a cliente es de muchos a uno, o equivalentemente, de cliente a
cuenta es de uno a muchos
 Diagramas Entidad Relación
(D.E.R.) según Peter Chen

 Rectángulos representa a conjuntos entidad.

 Rombos representa a conjuntos relación.
 Líneas une atributos de un conjunto entidad y conjuntos relación con
conjuntos entidad.
 Elipses representa atributos
 Elipses con linea doble representa atributos multivaluados.
 Elipses con linea discontinua representa atributos derivados.
 Subrayado representa atributos definidos como clave
 Diagramas E-R con atributos
compuestos, multivalorados y
derivados
Conjunto Relación con atributos
 Roles
• Los conjuntos entidad unidos por una relación no necesitan ser
necesariamente distintos
• Las etiquetas “administrador” y “trabajador” son llamadas roles; ellos
especifican como la entidad empleado interactúa vía el conjunto relación “
trabajar para (works-for)”.
• Los Roles son indicados en los diagramas E-R, etiquetando las líneas que
conectan los rombos con el rectángulo.
• Las etiquetas de Roles son opcionales, y son usadas para clarificar la
semántica de una relación.
 Restricciones Cardinalidad
• Nosotros expresamos las restricciones de cardinalidad, dibujando o una línea
directa (), que significa “uno”, o una línea sin dirección (—), que significa
“muchos”, entre el conjunto relación y el conjunto entidad.
• Ejm : relación uno a uno :
– Un cliente es asociado con al menos un préstamo a través de la relación
“prestar (borrower)”.
– Un préstamo es asociado con al menos un cliente a través de la relación
“prestar (borrower)”
 Relación Uno a Muchos
• En la relación uno a muchos un préstamo es asociado con al menos un
cliente a través de la relación “prestar (borrower)”, un cliente es
asociado con varios (incluyendo 0) prestamos a través de la relación
“prestar (borrower)”
 Relación Muchos a Uno
• En una relación muchos a uno un préstamo es asociado con varios
(incluyendo 0) clientes a través de la relación “prestar (borrower)”, un
cliente es asociado con al menos un préstamo a través de la relación
“prestar (borrower)”
 Relación Muchos a Muchos

• Un cliente es asociados con varios (posiblemente 0) prestamos

a través de la relación “prestar (borrower)”
• Un préstamo es asociado con varios (posiblemente 0) clientes
a través de la relación “prestar (borrower)”
 Participación de un Conjunto
Entidad en un Conjunto Relación
 Participación Total (representada por doble línea): toda entidad en el conjunto
entidad participa en al menos una relación del conjunto relación.
 Ejm : la participación de un préstamo es total
 Todo préstamo debe tener un cliente asociado a el a través de la relacion
“prestar (borrower)”.
 Participación Parcial : algunas entidades podrían no participar en cualquier de
las relaciones del Conjunto Relación.
 Ejm : la participación de un cliente en la relación “prestar (borrower)” es
parcial.
Notación Alternativa para los limites
de la Cardinalidad
 Los limites de la cardinalidad pueden también expresar
restricciones de participación.
 Claves
• Una superclave de un conjunto Entidad es un
conjunto de uno o mas atributos cuyos valores
únicamente determinan cada entidad.
• Una clave Candidata de un conjunto entidad es
una superclave mínima.
– Código Cliente es la clave candidata de un
cliente
– Numero_de_Cuenta es la clave candidata de
una cuenta
• Algunas veces las claves candidatas podrían
existir, una de las claves candidatas es
seleccionada para ser la clave primaria.
 Claves para los Conjunto Relación
• La combinación de las claves primarias que participan en los
conjuntos entidad forman una súper clave de un Conjunto
Relación.
– (código_cliente, numero_cuenta) es la súper clave del
Conjunto Relación “depositar (depositor)”.
– NOTA: esto significa que un par de conjuntos entidad
pueden tener al menos una relación en un Conjunto
Relación en particular.
• Ejm: si nosotros deseamos tener todas las fechas de
deposito (Access-dates) de cada cuenta por cada
cliente, nosotros no podemos asumir una relación para
cada acceso. Nosotros podemos usar un atributo
multivalorado también.
• Debemos considerar el mapeo de la cardinalidad de un
conjunto relación cuando decidimos cuales son las claves
candidatas
• Necesitamos considerar la semántica de un conjunto relación
en seleccionar la clave primaria en el caso de mas de una clave
candidata
Diagrama E-R con relación Ternaria
Relaciones Binaria Vs. No-Binarias
• Algunas relaciones que aparecen como relaciones no-
binarias deberían ser representadas en una mejor forma
utilizando relaciones binarias
– Ejm: Los padres de una relación ternaria, relacionan a
un hijo con su padre y su madres, es mejor
reemplazarlo por dos relaciones binarias, Padre y
Madre.
• Usando dos relaciones binarias genera
información parcial (ejm : solamente la madre será
conocida)
– Pero existen solamente algunas relaciones que son
naturalmente no binarias
Convirtiendo relaciones No-Binarias
a forma Binaria
• En general, cualquier relación no binaria puede ser representada usando relaciones
binarias, creando un conjunto entidad artificial.
– La relación R entre los conjuntos entidad A, B y C pueden ser representados
usando un nuevo conjunto entidad E, y tres relaciones RA, RB y RC entre E y A, B
y C respectivamente
– Para cada relación en R, nosotros creamos una nueva entidad en E, y la
relacionamos con sus correspondientes entidades en A, B y C
– Nosotros necesitamos crear atributos de identificación para las instancias de E
– La conversión de restricciones podría no ser posible
– Existirían instancias en el esquema trasladado que no pueden corresponder a
cualquier instancia de R.
 Pautas para Diseño
• Utilizar conjuntos entidad vs. atributos
La selección principalmente depende de la estructura de
la empresa que esta siendo modelada, y la semántica
asociada con los atributos en cuestión.
• Utilizar conjuntos entidad vs. conjuntos relación
Posiblemente la línea guía es diseñada como un conjunto
relación que describe una acción que ocurre entre
entidades
• Conjuntos relación Binarios vs. N-arios
Aunque es posible reemplazar cualquier conjunto
relación no binario (n-ario, cuando n > 2) por un distinto
numero de conjuntos relación, un conjunto relación n-
ario muestra mas claramente que varias entidades
participando en una sola relación.
• Utilizar atributos de relaciones
 Conjunto Entidad Débil
• Un conjunto entidad que no tiene una clave primaria, se le
denomina como conjunto entidad débil.
• La existencia de un Conjunto entidad débil depende de la
existencia de un conjunto entidad fuerte
– Debe relacionar al conjunto entidad fuerte a través de un
conjunto relación uno a muchos para identificar al conjunto
entidad débil.
– Una Relación Fuerte se representa usando un rombo doble
• El Discriminador (discriminador o clave parcial) de un conjunto
entidad débil es el conjunto de atributos que son distinguidos
entre todas las atributos de un conjunto entidad débil.
• La clave primaria de un conjunto entidad débil es formado por
la clave primaria de los conjuntos entidad fuerte del cual el
conjunto entidad débil depende de su existencia, mas el
discriminador del conjunto entidad débil.
 Conjunto Entidad Débil (Cont.)
• El conjunto entidad débil se representa mediante
rectángulos dobles.
• Se subrayan los discriminadores de un conjunto entidad
débil con una línea discontinua.
• El numero de pago es el discriminador del conjunto
entidad pago.
• La clave Primaria para pago es (numero de pago, numero
de préstamo)
 Especialización
• Es un proceso de diseño Top-down; nosotros
diseñamos subgrupos dentro de un conjunto entidad
que son distintos de otras entidades en el conjunto.
• Estos subgrupos se convierten en conjuntos entidad de
un nivel mas bajo que tiene atributos o participan en
las relaciones que no son aplicadas al conjunto entidad
del nivel mas alto.
• Se representa por un triangulo etiquetado como “es
una (ISA)” (Ejm: un cliente “es una” persona).
• Herencia de Atributos, un conjunto entidad de nivel
mas bajo hereda todos los atributos y relaciones que
participan del conjunto entidad de nivel mas alto con
el que se encuentran enlazadas.
Ejemplo de Especialización
 Generalización
• Es un proceso de diseño Bottom-Up, que combina
un numero de conjuntos entidad que comparten las
mismas características dentro de un conjunto entidad
de mas alto nivel.
• La Especialización y Generalización son recíprocos
el uno al otro. Ellos son representados dentro de un
mismo Diagrama Entidad Relación.
• Los términos Especialización y Generalización son
usados en vice versa.
 Restricciones del diseño en la
Especialización y Generalización
• Se puede restringir que entidades pueden ser miembros
de un conjunto entidad de menor nivel.
– definidos por condición
– definidos por usuario
• Se puede restringir en que si una entidad podría
pertenecer a mas de un conjunto entidad de menor nivel
dentro de una generalización simple.
– exclusiva
– sobrelapada
• Completamente restrictiva especifica cuando si o no una
entidad en un conjunto entidad de mas alto nivel debe
pertenecer a al menos a uno de los conjuntos entidad de
menor nivel dentro de una especialización.
– total
– parcial
Diagrama E-R con relaciones
redundantes
 Agregación
• Los conjunto Relación works-on y manages representan
información sobrelapada.
• Elimina esta redundancia vía agregación
– Trata a la relación como una entidad abstracta.
– Permite relaciones entre relaciones
– Abstrae la relación en una nueva entidad.
• Sin introducir redundancia, el siguiente diagrama
representa que:
– Un empleado trabaja en una ocupación particular en
una sucursal particular (y podría trabajar en diferentes
ocupaciones en diferentes sucursales)
– Un combinación de empleado, sucursal y ocupación
podría tener un administrador asociado.
Diagrama E-R con agregación
 Decisiones en Diseño de
Diagramas E-R
• El uso de atributos y conjuntos entidad representan un
objeto.
• Cuando un concepto del mundo real es mejor expresado
por un conjunto entidad o un conjunto relación.
• El uso de relaciones ternarias versus un par de relaciones
binarias.
• El uso de un conjunto entidad débil o fuerte.
• El uso de generalización/especialización contribuye a la
modularidad en el diseño.
• El uso de la agregación puede tratar el conjunto entidad
agregado como un sola unidad sin tener que
preocuparnos de conocer los detalles de su estructura
interna.
Diagrama E-R para una
Empresa Financiera
Resumen de la notación de CHEN
para Diagramas E-R
Resumen de la notación de CHEN
para Diagramas E-R
 Definición de Entidades :
• Un objeto de interés para los negocios
• Una clase o categoría de las cosas
• Una cosa con un nombre
• Un sustantivo
• Un aspecto importante acerca del cual se necesita tener o conocer
información para los negocios
EMPLEADO
Diagramando Entidades :
 Cajas de cualquier dimensión con las esquinas
redondeadas
 Nombre único, en mayúsculas y singular
 Nombre de Sinónimo Opcional

COMPAÑÍA
(CLIENTE) DEPARTAMENTO

MEMBRECIA
 Definiciones de Atributos :
• Sustantivos que se usan para describir entidades
• Piezas específicas de información la que necesita ser conocida
• Una entidad debe tener atributos
EMPLEADO
Diagramando Atributos :
nombre
 Nombre único, en minusculas
 Escrito en singular fech_nac
 Nombre abstracto

COMPAÑÍA
(CLIENTE) DEPARTAMENTO
nombre descripción
dirección dirección

MEMBRECIA
codigo
fech_inscripción
Ocurrencias o instancias de
Entidades

Head office

Personnel Finance Sales

EMPLOYEE DEPARTMENT
Identificar una Única Instancia

EMPLEADO

codigo
nombre
fech_nacimiento
salario
Identificar y Modelar Entidades

• Examinar los sustantivos

– Es ésto importante?
– Hay información acerca de ésto que el negocio
necesite mantener?
– Es ésto un conjunto o una instancia o elemento?
• Nombre de la entidad
• Escribir una descripción de ésto
• Identificar unos cuantos atributos
• Dibujar una caja rectangular con las esquinas
redondeadas para cada entidad
 Ejercicio en Clase
“Soy el administrador de una compañía de capacitación
que provee cursos, impartidos por nuestros instructores,
sobre técnicas de administración. Enseñamos cursos, los
cuales tienen un código, nombre y costo. Introducción al
UNIX y Programando en C son dos de nuestros más
populares cursos.
Los cursos varían en duración desde uno a cuatro días.
Paul Rogers y María Gonzales son dos de nuestros
mejores instructores. Registramos el nombre de cada
instructor y el número telefónico. Los alumnos pueden
tomar varios cursos a través del tiempo y muchos lo
hacen. Jamie Brown de AT&T tomó todos los cursos que
ofrecemos !
Nos gusta tener el nombre y teléfono de cada
estudiante.”
 Ejercicio en Clase - Solución
“Soy el administrador de una compañía de capacitación
que provee CURSOS impartidos por nuestros
instructores, sobre técnicas de administración.
Enseñamos cursos, los cuales tienen un código, nombre,
y costo. Introducción al UNIX y Programando en C son
dos de nuestros más populares cursos.
Los cursos varían en duración desde uno a cuatro días.
Paul Rogers y Maria Gonzales son dos de nuestros
mejores instructores. Registramos el nombre de cada
INSTRUCTOR y número de teléfono. Los ALUMNOS
pueden tomar varios cursos a través del tiempo y
muchos lo hacen. Jamie Brown de AT&T tomó todos los
cursos que ofrecemos !
Nos gusta tener el nombre y teléfono de cada
estudiante.”
 Ejercicio en Clase - Solución

CURSO INSTRUCTOR ESTUDIANTE

codigo nombre nombre
nombre telefono telefono
costo
duración
 Definiciones de Relación

• La única manera de vincular entidades con

otras o consigo misma
• Las reglas de negocio mantiene juntos los
requerimientos de información del negocio
• Una cosa que tiene que hacer con otra
• Una asociación nombrada por entidades
Relaciones Bi-direccionales

DMDD COURSE SMT COURSE

SMT COURSE

INSTRUCTOR CURSO
Estándares de Diagramación

• Una linea entre dos entidades

• El nombre de la relación en minúscula
• Opcionalidad (Minimum cardinality)
Obligatoria - Debe
Opcional - Puede

• Grado (Maximum cardinality)

Una o más
Uno y sólo uno
Estándares de Diagramación

COPIA TITULO

Muchos
(pata de gallina) Opcional
Obligatoria Uno
 Sintaxis de Relaciones

Debe ser una o más

Nombre de la
Cada entidad1 o o entidad2
relación
puede ser una y sólo una

Sujeto Objecto
Opcionalidad Nombre Grado
 Validación

asignado a
EMPLEADO DEPARTAMENTO
 Validación

asignado a
EMPLEADO DEPARTAMENTO

Cada EMPLEADO debe estar asignado a uno y sólo un DEPARTMENTO

 Validación

EMPLEADO DEPARTAMENTO
responsable de
 Validación

EMPLEADO DEPARTAMENTO
responsable de

Cada DEPARTMENTO puede ser responsable de uno o más EMPLEADOS

 Validación

asignado a
EMPLOYEE
EMPLEADO DEPARTMENT
DEPARTAMENTO
responsable de

Cada EMPLEADO debe estar asignado a uno y sólo un DEPARTMENTO

Cada DEPARTMENTO puede ser responsable de uno o más EMPLEADOS

 Validación

matriculado en
ALUMNO CURSO
tomado por
 Validación

matriculado en
ALUMNO CURSO
tomado por

Cada ALUMNO puede matricularse en uno o más CURSOS

Cada CURSO debe ser tomado por uno o más ALUMNOS

Tipos de Relaciones

Muchos a uno

Muchos a muchos

Uno a uno
Relaciones de Muchos a Uno

Visitado por

CLIENTE REPRESENTANTE
DE VENTAS
asignado a
Relaciones de Muchos a Muchos

atendido por

PATIENT HEALTH CARE

WORKER
asignado a
 Relaciones de Uno a Uno

es montada por

BICICLETA CICLISTA
el manejador de

Representa una situación en un momento

 Analizar y Modelar Relaciones

1 Determine la existencia de una relación

2 Nombre cada dirección de la Relación
3 Determine el grado de cada dirección de la
Relación
4 Determine la opcionalidad de cada dirección
de la relación
5 Lee las relaciones para validarlas
 Determinar la Existencia de las
Relaciones
Existencia
Nombre
MEMBERSHIP COPY RENTAL Grado
Opcionalidad
MEMBERSHIP Validez
COPY
RENTAL

MEMBERSHIP

RENTAL

COPY
 Nombrando la Relación
Existencia
Cada título sirve como copia y cada Nombre
copia es de un título Grado
Opcionalidad
Validez

de
COPIA TITULO
sirve como
 Determinando el Grado
Existencia
Cada título sirve como copia, podrían haber muchas Nombre
copias pero hay solo un título de una copia Grado
Opcionalidad
Validez

uno

COPIA TITULO

muchos
 Determinando la Opcionalidad
Existencia
Todas las copias deben tener un título, pero
Nombre
necesitamos información acerca de los título
aunque no tenga copia Grado
Opcionalidad
Validez

opcional

COPIA TITULO

obligatoria
 Validando las Relaciones
Existencia
Cada copia debe ser de un solo título , y Nombre
cada título puede servir para una o más
Grado
copias
Opcionalidad
Validez

de
COPIA TITULO
sirve como
 Presentación del Diagrama ER

• Limpios y ordenados

• No usar textos ambiguo

• Textos memorizables
 Atributos

Número de clave - Identifica a un empleado

Nombre - Califica a un empleado

Tipo de nómina (semanal o salario)

- Clasifica a un empleado

Fecha de nacimiento - Cuantifica a un empleado

Estatus del Empleo (activo, abandonado o

terminado ) -
Expresa el estatus de un empleado
 Encontrando Atributos

Es éste un atributo que realmente se necesita ?

Cuidarse de los requerimientos obsoletos de un sistema anterior

Cuidarse de los datos derivados

 Estándares de Diagramación

EMPLEADO • Dentro de las cajas de

número de clave entidades
nombre
apellido
categoría de pago • Singular
fecha de nacimiento
estatus del empleado
• Minúsculas
Componentes importantes con
significado

PERSONA PERSONA
apellido
nombre nombre

Descomponer los atributos agregados

ARTICULO ARTICULO
tipo
código vendedor
número
Verificar que cada atributo tenga un
solo valor
RENTA

fecha de transacción

total a pagar
artículo

¿El atributo puede tener más de un valor para la

instancia de una entidad? Un atributo multivalor
o un grupo repetitivo no es un atributo válido
 Verificar un Valor Simple

RENTA
fecha de transacción
¿Puede un atributo tener más de un valor para
total a pagar una instancia de la entidad?
artículo

Si, más de un artículo pueden ser rentados al mismo tiempo. Entonces hace
falta otra entidad .
 Verificar un Valor Simple

RENTA
fecha de transacción
¿ Puede un atributo tener más de un
total a pagar valor para una instancia de la
artículo entidad?

Si, más de un artículo pueden ser rentados al mismo tiempo . Otra entidad es
necesaria

ARTICULO RENTA
´número de
fecha de transacción
artículos
total a pagar
 Atributos que tienen Atributos

CARGO
código del producto
cargo
descripción
revisión de detalles

¿La información necesita ser

descompuesta para alguno de los
atributos?
 Atributos que tienen Atributos

CARGO
código del producto
cargo
descripción ¿La información necesita ser
revisión de detalles descompuesta para alguno de los
atributos?

Sí, revisión de detalles . Se necesita otra entidad.

 Atributos que tienen Atributos

CARGO
código del producto
cargo
descripción ¿La información necesita ser
revisión dedetalles descompuesta para alguno de los
atributos?

Sí, revisión de detalles . Se necesita otra entidad.

REVISION CARGO
código del producto
cargo
autor descripción
comentario revisión de detalles
fecha de rev.
Encontrando Datos Derivados

• Contadores
• Totales
• Máximo, Mínimo, Promedio
• Otros cálculos

Eliminar los atributos derivados puede

causar inconsistencia de los datos .
 Opcionalidad de los Atributos
Atributos Obligatorios
• Un valor debe ser almacenado para cada instancia de
la entidad

• Marcarlo con
*
Atributos Opcionales
• Un valor puede ser almacenado para cada
instancia de la entidad
• Marcarlo con o
Opcionalidad de Atributos

EMPLEADO

número de clave
* nombre
* apellido
*o cargo
o peso
 Definición de Identificadores Únicos
Cada instancia de una entidad debe poder ser identificada
en forma única

Una combinación de atributos o relaciones que sirven

para identificar instancias específicas de una entidad
 Identificadores Únicos Simples
( UID )

342 CUSTOMER 876

# * customer num

Atributo Unico

Marcar el UID con #

 Componer UID - Atributos

567498

MEMBERSHIP
# * num
# * start date

Atributos Múltiples
Componer UID - Compuesto

ACCOUNT BANK

* num # * num

¿Qué necesitarías saber para identificar una instacia

específica de una CUENTA?
 Componer UID - Compuesto

ACCOUNT BANK

# * num # * num

Usar un # para indicar qué Usar una barra UID para

atributos son parte del UID indicar que la relación es
parte del UID
 Componer UID - Relaciones

RENTALITEM
* rental period
o ¿Qué se necesita saber para
return date
identificar una instancia
específica de RENTALITEM?

RENTAL COPY
# * transaction num # * inventory num
* transaction date * purchase cost
 Componer UID - Relaciones

RENTALITEM
* rental period Rentalitem requieren un
o
return date rental transaction num y
el inventory num

RENTAL COPY
# * transaction num # * inventory num
* transaction date * purchase cost
 Multi- Niveles de Relaciones UIDs

TICKET PERFORMANCE PLAY VENUE

# * date
* seat number # * time # * title # * name

CUSTOMER
# * name
¿Qué necesitarías saber para identificar una
instancia específica de TICKET?
 Multi- Niveles de Relaciones UIDs

TICKET PERFORMANCE PLAY VENUE

# * date
* seat number # * time # * title # * name

Venue.name + Play.title +
CUSTOMER
# * name
Performance.date +

Performance.time +

Customer.name
 Multiple UIDs o UIDs alternos

número de clave
EMPLOYEE

#(1)* número de clave

categoría de pago #(2) * nombre
#(2) * apellido
#(3) * categoría de
nombre y apellido pago
 Identificando el Problema

De este diagrama , puede decir cuál instancia

supplier provee “Casablanca”?

TITLE proveedor de
SUPPLIER
# * prod code # * supplier no
* name proveeido por * name

¿En cuál entidad almacenaría los precios de

adquisición de los productos?
 Entidades Intersección

CATALOG ITEM
* purchase price

para para

disponible en provedor de

TITLE SUPPLIER
TITLE
# * prod code # * supplier no
* name * name
 Identificadores Únicos

CATALOG ITEM CATALOG ITEM

* purchase price # * item num
* purchase price
for for O for for

disponible proveedor de disponible proveedor de

TITLE SUPPLIER TITLE SUPPLIER

# *TITLE
prod code # * supplier no # *TITLE
prod code # * supplier no
* name * name * name * name
Modelando Relaciones Recursivas

…y el mío …pero yo soy

su Jefe

…él es mi
Jefe

gerente de

EMPLOYEE
bajo las ordenes
de
 Modelando Datos Jerárquicos
EQUIPO
# nombre

Compañía
DEPARAMENTO
# * nombre
División

Departamento
DIVISION

Equipo # * nombre

COMPAÑIA
# * nombre
Jerarquías como Relaciones
Recursivas
EQUIPO
# nombre

compuesto de
DEPARTAMENTO
# * nombre
ELEMENTOS
DE ORGANIZACIÓN
DIVISION # * nombre
* tipo dentro de
# * nombre

COMPAÑIA
# * nombre
Estructuras de Redes
una parte de

COMPONENTE

# * identificador

compuesto de
 Estructuras de Redes

una parte de

COMPONENTE

# * identificador

compuesto de

compuesto de
COMPONENTE COMPONENTE
# * identificador una parte de # * identificador
 Estructuras de Redes

REGLAS DE
ENSAMBLAJE
o cantidad

para para
una parte de compuesto de

COMPONENT COMPONENT
# * identificador # * identifier

compuesto de
COMPONENT COMPONENT
# * identificador una parte de # * identificador
Estructuras de Redes

REGLAS DE ENSAMBLAJE

o cantidad
para para

compuesto
de una parte de

COMPONENT
# * identificador
 Identificar Roles
INSCRIPCION
* fecha de inscripción
* cuota de matrícula

para para

tomado por
registrado en enseñado por INSTRUCTOR
CURSO # * id
ESTUDIANTE profesor * nombre
(PERIODO)
# * id de * salario
* ubicación
* nombre * fecha de
inicio para CURSO
# * código
sujeto
* nombre
de
 Modelando Roles

inscrito PERSONA
INSCRIPCION en # * id
* fecha de inscrip.
para * nombre
*cuota o salario

para profesor de

enseñado
por
tomado por

para CURSO
CURSO (PERIODO)
* ubicación # * codigo
* fecha de inicio registrado * nombre
en
Entidades exclusivas subtipos

TITULO
# * código del producto
* título
* descripción

PELICULA JUEGO
* categoía * categoría
* duración * medio
O audio
* memoria mínima
 Entidades Excluyentes

MUESTRA
* número de obtenido de COMPAÑIA
inventario la fuente de
o condición
# * id
* nombre
#
ACCION * teléfono
o número proveedor
cogida por
* número o contacto de venta
* fecha de inicio dueño
de
* fecha de
caducación
o
terminación
 Dividiendo Entidades

MUESTRA COMPAÑIA
* número de obtenido de
# id
inventario *
* nombre
o condición
telefono
PROVEEDOR

ACCION la fuente de * núm. proveedor

* contacto de
# * número cogida por venta
* fecha de inicio
dueño
* fecha caducac. de OTROS
o terminación
 Anidando Entidades

EMPLEADO

autorizado SALES
el manejo CLERICAL
CARRO REP
manejado por

HUMAN
RESOURCES
TELESALES
Anidando Entidades

AERONAVE

AVION
AVION MOTORIZADO
A PROPULSION
PLANEADOR
JET

OTRA
HELICOPTERO HOVERCRAFT
AERONAVE
 Subtipos Recursivos

ELEMENTOS DE ORGANIZACION
de
TIPO DE
COMPAÑIA ELEMENTOS DE
(ORGANIZACION) clasificación para ORGANIZACION

DEPARTAMENTO dentro de
(SUBDIVISION)

compuesto de
Modelando Relaciones Exclusivas

COMPAÑIA

cogida por * nombre

* area postal
ACCION dueño de 0 nombre del
o contacto
* número
* fecha inicio
* fecha
dueño de CLIENTE
expiración o
o terminación * número
* nombre
tomada por * apellido
 Modelando Exclusividades

“Ofrecemos asociar a clientes individuales y compañías”

SOCIOS
SOCIOS
PERSONA PERSONA
NATURAL JURIDICA

SOCIO

CLIENTE COMPAÑIA CLIENTE COMPAÑIA

MIEMBROS

CLIENTES COMPAÑIA
Modelando Datos a través del Tiempo

¿Qué hacer si Usted necesita manejar el

registro histórico de un departamento?

DEPARTAMENTO PERSONA
rentado por
# * id
# * código * apellido
* dirección arrendatario
de * nombre
Modelando Datos a través del Tiempo

PERSONA
REGISTRO DE para
RENTA # * id
# * de la fecha * apellido
o a la fecha arrendatario * nombre
de

para

rentado por

APARTMENTO

# * código
* dirección
Modelando Datos a través del
Tiempo

trabaja para
EMPLEADO
COMPAÑIA
# * id
empleador # * código
* apellido * nombre
de
* nombre
Modelando Datos a través del
Tiempo
REGISTRO HISTORICO
DEL EMPLEADO
# * de la fecha
o a la fecha

para para

trabaja para empleador de

EMPLEADO COMPAÑIA
# * id
# * código
* apellido
* nombre
* nombre
 Trampa del anillo

PERSONA el ocupante de PUESTO

# * id # * cargo
* apellido ocupado por o descripción
* nombre del trabajo

empleada por
incluido en

COMPAÑIA
# * código
patrón de * nombre patrón de
 Trampa del anillo
ocupante
PERSONA de HISTORIA PUESTO
DEL por # * cargo
# * id PUESTO descripción
o
* apellido * de la fecha ocupado del trabajo
por o
* nombre a la fecha por sujeto
trabajando en a
por por
HISTORIA HISTORIA DE LA
DE LA CÍA. ORGANIZACION
* de la fecha * de la fecha
o a la fecha
o a la fecha

por
por
COMPAÑIA

trabajando # * código
por * nombre trabajando
por
 Resolviendo Trampa del anillo

HISTORIA DEL en COMPAÑIA

EMPLEADO
trabajador # * código
#* de la fecha * nombre
de
o a la fecha

como
por

una parte
PUESTO
PERSONA # * cargo
incluido en
o
descripción del
# * id trabajo
* apellido
* nombre
 Trampa del abismo

EMPLEADO

uso
trabaja
autorizado
para

patrón de usado
por COMPAÑÍA DE
DEPARTAMENTO AUTOS
Resolviendo Trampa del abismo

EMPLEADO

trabaja uso autorizado

para

patrón de usado
por
DEPARTAMENTO COMPAÑÍA DE AUTOS

aparece en aparece en

para para

ASIGNACION
Convergencia

COSA
 Divergencia

LINEA DE
PALABRA DIRECCION

DIRECCION

Necesita realmente este nivel de detalle?

 Relaciones Transferibles

PERSONA trabaja en DEPARTAMENTO

# * id
* apellido #*
emplea
* nombre código

Jefe

Personal Finanzas Ventas

 Relaciones No-Transferibles

COMPAÑIA

# * id
* nombre
MUESTRA obtenida de * teléfono
* número de PROVEEDOR
inventario * núm. proveedor
o condición la fuente de
* contacto de
ventas

OTROS