Modelo Entidad Relación

Modelo Entidad Relación
Base de Datos
Entidad
 Una Persona, lugar, cosa, concepto o suceso, real o
abstracto de interés para la Empresa.
 Características
Un Tipo de entidad tiene que tener existencia propia.
Cada ocurrencia de una entidad debe poder
distinguirse de las demás – “Ser Distinguible”
Todas las ocurrencia de un Tipo de Entidad deben
tener los mismos tipos de atributos – “No los mismos
Valores”
Definiciones de Entidad
 Un Objeto de Interés para el Negocio.

 Una Clase o Categoría de Cosa
 Un nombre de Cosa
 A nombre o Sustantivo
 Una cosa de significancia acerca de la
cual el negocio necesita información.
Definiciones de Atributo
 Usar Sustantivos para describir

Entidades.
 Especifica piezas de información cual
necesita ser conocida.
 Una entidad debería tener atributos
Diagramando Entidades
 Cuadro con bordes
 Singular, nombre único en
mayúsculas.
 Opcional Nombre sinónimo Empleado
 Nombres de atributos en nombre
nacimiento
minúsculas.
Compañía
Departamento
Socio
Instancias de Entidad
Gerencia
Personal Finanzas Ventas
EMPLEADO DEPARTAMENTO
Identificando una instancia Única
EMPLEADO
DNI
Nombre
Nacimiento
Salario
Identificando y Modelando
Entidades
 Identifica un Sustantivo
 Es Significativo?
 Es esta información acerca de la cual el
negocio necesita guardar?
 Es un grupo o una Instancia?
 Nombre de Entidad
 Escribe una descripción sobre ella
 Identifica unos pocos atributos
 Dibuja una Caja bordeada para ella
Ejercicio en Clase - Solución
Se desea diseñar una base de datos que guarde la información de las
reservas de una empresa dedicada al alquiler de automóviles. Los
supuestos semánticos son los siguientes:
Un determinado cliente puede tener en un momento dado varias
reservas.
Una reserva la realiza un único cliente, pero puede involucrar a varios
coches.
Es importante registrar la fecha de comienzo de la reserva y la de
terminación.
Todo coche tiene siempre asignado un número determinado de garaje,
que no puede cambiar.
Cada reserva se realiza en una determinada agencia.
En la base de datos pueden existir clientes que no hayan hecho
ninguna reserva.
Todas las entidades tienen una clave alfanumérica que las identifica
unívocamente. Se pide realizar el diseño del modelo E/R e indicar
aquellos supuestos que no han podido recogerse, así como los que ha
sido necesario introducir.
CLIENTE
AGENCIA
codigo codigo
nombres dirección
RESERVA
numero
fechacomienzo
fechaculminacion
COCHE GARAJE
placa numero
marca dirección
modelo
MODELANDO RELACIONES
Modelando Datos y Diseño de

Base de Datos Relacional
Objetivos
 Analizar y modelar las relaciones entre
entidades.
 Dibujar Relaciones iniciales entre
entidades.
 Leer las relaciones sobre un Diagrama
ER.
 Definir Claramente los nombres de las
relaciones.
Definición de Relaciones
 La manera de relacionar una Entidad con
Otra.
 Las reglas del negocio como enlace a las
necesidades de información del negocio.
 Una cosa tiene que hacer con otros.
 Una asociación nombrada entre
entidades.
Relacion Bi-Direccional
Base de Datos SMT COURSE
Ingeniería del
Software
INSTRUCTOR CURSO
Convenciones de Diagramación
 Una Línea entre dos Entidades
 Nombres de relaciones en
minúsculas.
 Opcionalidad (Cardinalidad Mínima)
Mandatoria – debe ser
Opcional – puede ser
 Grado (Cardinalidad Máxima)

Uno o mas
Uno y solo uno
Convenciones de Diagramación
COPIA TITULO
muchos
(pata de gallo) opcional
obligatoria uno
Sintaxis de la Relación
Debe ser Uno o mas

Nombre de la
Cada Entidad 1 o o Entidad 2
relación
Puede ser Uno y solo uno
Entidad Entidad
Opcionalidad Nombre Grado Objeto
Sujeto
Validación - Practica en clase
Asignado a
Validación – Solución en clase
Asignado a
Cada EMPLEADO debe tener asignado a uno y solo un DEPARTAMENTO

Validación – Practica en Clase
Responsable de
Validación – Solución en Clase
Responsable de
Cada DEPARTAMENTO puede ser responsable de uno o mas EMPLEADOS

Asignado a
EMPLEADO
DEPARTAMENTO
Responsable de
Cada EMPLEADO debe tener asignado a uno y solo un DEPARTAMENTO
Cada DEPARTAMENTO puede ser responsable de uno o mas EMPLEADOS

Validación – Practica en Clase
Matricularse en
ESTUDIANTE CURSO
Tomado por
Matricularse en
ESTUDIANTE CURSO
Tomado por
Cada ESTUDIANTE puede matricularse en uno o mas CURSOS
Cada CURSO puede ser tomado po uno o mas ESTUDIANTES

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
PACIENTE MEDICO
Asignado a
Relaciones de Uno a Uno
montada por
BICICLETA CICLISTA
Jinete de
Representa una fotografía en el tiempo

Analizando y Modelando
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 Lea la relación fuerte para validarla.
Determinando una Relación
Existente
Existencia
Nombre
SOCIO COPIA ALQUILER Grado
Opcionalidad
SOCIO Validar
COPIA
ALQUILER
SOCIO
ALQUILER
COPIA
Nombrando una Relación
Existencia
Cada Titulo esta disponible con una Nombre
copia y cada copia es de un Titulo
Grado
Opcionalidad
Validar
de
COPIA TITULO
disponible como
Determinando el Grado
Existencia
Cada título está disponible como copia, allí podría ser porciones Nombre
de copias pero hay solamente siempre un título en una copia Grado
Opcionalidad
Validar
uno
COPIA TITULO
muchos
Determinando la Opcionalidad
Existencia
Cada copia debe tener un título en ella pero necesitamos Nombre
la información sobre títulos incluso si no hay copia Grado
Opcionalidad
Validar
opcional
COPIA TITULO
mandatoria
Validando la Relación
Existencia
Cada copia debe estar de uno y solamente
un título, y cada título puede estar disponible Nombre
como unas o más copias Grado
Opcionalidad
Validar
de
COPIA TITULO
Disponible como
Resumen
 Estableciendo la existencia de una
relación.
 Nombre de la relación
 Determine el grado
 Determine la opcionalidad
 Lea la relación para validarla.
Practica
 Establecer las Relaciones para el Caso

tratado anteriormente.
AGENCIA
CLIENTE
código
código dirección
nombres
RESERVA
numero
Fecha comienzo
fecha culminación
COCHE
placa GARAJE
marca numero
modelo dirección
Agregando Detalle al
Diagrama.
Modelando Datos y Relaciones
Diseño de Base de Datos
Objetivos
 Identifica convenciones de la disposición
 Analizando requerimientos de Información desde
atributos.
 Modelando Atributos
 Identificar atributos multivaluados
 Validación de Atributos
 Identificar Datos Comunes y derivados.
 Entender el uso de dominios
 Identificar los componentes de un Almacén de Datos
Presentar el Diagrama E-R
 Limpio y Ordenado
 Texto inequívoco
 Memorable patterns
Presentar Normas
Los Cuervos Muertos Vuelan

Al este!
Atributos
Numero – Identifica a un Empleado
Nombre – Califica a un Empleado
Categoría Empleado (salario)

Clasifica a un empleado
Fecha de Cumpleaños - Califica a un Empleado
Estado del empleado (activo, licencia, culminado) -

Expresa el estado de un empleado
Buscando Atributos
Es este atributos realmente necesario ?
Guárdese de requisitos obsoletos de sistemas anteriores
Guárdese de datos derivados

Atribuya a convenciones de
Diagramación
 Dentro de la caja de
EMPLEADO la entidad
Numero identificador
Nombres
Apellidos  Singular
Salario bruto
Fecha de cumpleaños
Estado del empleado  Minúscula
Componentes Significativos
PERSONA PERSONA
apellidos
nombres nombres
Analice las cualidades agregadas
ITEM ITEM
type
codigo vendor
num
Verifique para el valor solo
ALQUILER
fecha de la transacción
cantidad total pagada
artículo
¿Puede una cualidad tener más de un

valor para un caso de la entidad?
Verifica un solo valor
ALQUILER
fecha de la transacción ¿Puede una cualidad tener más de un

cantidad total pagada valor para un caso de la entidad?
artículo
Sí, más de un artículo se puede alquilar a la vez. Una entidad falta.

Verifica un solo valor
ALQUILER
fecha de la transacción ¿Puede una cualidad tener más de un

cantidad total pagada
valor para un caso de la entidad?
artículo
Sí, más de un artículo se puede alquilar a la vez. Una entidad falta.
ALQUILER DE ALQUILER
ARTICULO
Fecha de transacción
Numero de articulo Cantidad total pagada
Atributos que tienen atributos
TITULO
Código de producto
titulo
descripción ¿La necesidad de información de ser
Detalles de la revisión almacenado sobre cualesquiera de las
cualidades?
Atributos que tienen atributos
TITULO
Código del producto
titulo
descripción ¿la necesidad de información debe ser
Detalle de Revision almacenado sobre cualesquiera de las
cualidades?
Sí, detalles de la revisión. Una entidad falta.

Atributos que tienen Atributos
TITLE
Código de Producto
titulo
Descripción ¿la necesidad de información debe ser
Detalle de revisión almacenado sobre cualesquiera de las
cualidades?
Sí, detalles de la revisión. Una entidad falta

.
REVISION TITULO
Código de producto
Autor titulo
comentario Descripción
Fecha registrada
Encontrar datos comunes o
derivados
 Cuenta
 Total
 Promedio máximo y mínimo
 Calculación
Las cualidades derivadas son

redundantes y pueden conducir a los
valores contrarios
Atributos opcionales
Atributos obligatorios
 Un valor se debe almacenar por cada
instancia de la entidad.
 Es marcada con una etiqueta

Atributos Opcionales
*
 Un valor se debe almacenar por cada
instancia de la entidad.
 Es marcada con una etiqueta o

Atributos Opcionales
EMPLEADO
divisa numérica
* Nombre
* Apellido
*o titulo
o Peso
Detalles y volúmenes de los
Atributos
Atributo - * Tamaño Del Motor

Formato Tipo Número
Longitud máxima 4
Longitud media 4
Lugar decimal 1
Unidad de la medida cc
Valores permisibles 900.1000.1500.1800.2000
Volumen Inicial El 100%

Usar un Dominio
Película
Mono
AUDIO
Stereo
MON
Audio STE
SUR
Juego
Surround
Sonido
Almacenamiento De los Datos
Datos del Datos de la

hecho referencia
Datos Meta datos

sumarios
Gerencia de la carga
Gerencia del almacén
Gerencia de la pregunta
RESUMEN
 Disposición de convenciones
 Identificación de atributos
 Atributos que tienen atributos
 Datos comunes y derivados
 Opcionalidad de atributos
 Validación de atributos
 Almacenamiento de datos
Practica
 Desarrollar un modelo entidad relación
incluyendo atributos opcionales
Únicos Identificadores
Datos que modelan y diseño de
base de datos emparentada
Objetivos
 Entender la necesidad de un único
identificador
 Identificar UIDs desde atributos
 Identificar UIDs desde las relaciones
 Identificar UIDs desde combinanciones
 Crear UIDs para cada entidad
Definición de un Único
Identificador
Cada instancia de la entidad debe poder ser identificado
únicamente
Una combinación de atributos o relaciones que

sirven para identificar una instancia especifica
de una entidad.
Identificador Único Simple
342 CLIENTE 876
# * Numero de cliente
Atributo simple
Marque el UID con etiqueta #

Compound UID - Attributes
567498
MEMBERSHIP
# * num
# o start date
Multiple attributes
Componentes de UID - Composición
CUENTA BANCO
* num # * num
¿Qué es lo que usted necesitaría para saber identificar

un caso específico de la CUENTA?
Componentes de UID - Composición
CUENTA BANCO
# * num # * num
Usa # para indicar que atributo Utilice una barra de UID

Es parte de la entidad UID para indicar
que una relación es parte
de
UID de la entidad
Componentes UID - Relaciones
ALQUILER DE ARTICULO
* Periodo de alquiler
o ¿Qué usted necesita saber
regresa la fecha
para identificar un caso
específico del ARTÍCULO DE
ALQUILER?
RENTAL COPIA
# * Num transacción # * Numero de inven
* día transacción * costo de compra
Componentes UID - Relaciones
ALQUILER DE ARTICULO
El artículo de alquiler
* Periodo de alquiler
o fecha de retorno requiere la transacción
de alquiler numérica y
inventario numérico
ALQUILER COPIA
# * num de transacción # * numero de inventario
* día de transacción * costo de compra
Relación De niveles múltiples
UIDs
BOLETO
FUNCIONAMIENTO JUEGO LUGAR
* Nro de asiento # * dia
# * hora # * titulo # * nombre
CLIENTE
# * nombre
¿Qué usted necesitaría saber para
identificar un caso específico del BOLETO?
Relación De niveles múltiples
UIDs
BOLETO FUNCIONAMIENTO Juego LUGAR
# * fecha
* num.asiento # * hora # * titulo # * nombre
Nombre de lugar + Titulo de juego+

CLIENTE
# * nombre
Dia del funcionamiento +
Hora del funcionamiento +
Nombre del cliente

Multiples UIDs
divisa numérica
EMPLEADO
#(1)* Divisa numérica

nómina de pago #(2) o Nombre
numérica
#(2) o Apellido
#(3) * Nomina de pago
Nombre y apellido numérica
RESUMEN
 Evaluar los atributos
 Considerar las relaciones
 Validar los UIDS
Practica
 6-1 crea UIDs para el modelo de
Hollywood creada en la práctica 4-4
 6-2 crea UIDs para el grupo de usuario del

modelo oráculo que se creó en la práctica
5-1
Resolución de muchos a
muchas relaciones
Objetivos
 Identificar las necesidades para la
intersección de entidades
 Crea una entidad interseccion
 Crea un UID para la nueva entidad
IDENTIFICANDO EL
PROBLEMA
Para este diagrama, ¿puede usted decir qué caso del
surtidor proporciona " Casablanca "?
TITULO supplier of
PROVEEDOR
# * Cod. producto # * No. proveedor
* nombre supplied by * nombre
¿En qué entidad usted almacenaría el precio de

compra de la cualidad?
Intersección de Entidades
ARTICULO DE CATALOGO
* precio de compra
para para
disponible como Surtido de
TITULO PROVEEDOR
TITLE
# * Cod. pro # * No. proveedor
* nombre * nombre
Identificadores Únicos
ARTICULO DE CATALOGO ARTICULO DE CATALOGO

* Precio de compra # * numero de catalogo
* precio de compra
para para O para para
Disponible como Surtido de Disponible como Surtido de
TITULO PROVEEDOR TITULO PROVEEDOR

# *TITLE
Cod.producto # * No.Proveedor # *TITLE
cod.prod # * No proveedor
* nombre * nombre * nombre * nombre
RESUMEN
 Identificar la necesidad de una entidad
intersección.
 Crear una entidad intersección
 Crear una UID para la nueva entidad
Practica
 7-1 crea una entidad intersección con un
UID para una relacion de muchos a
muchos en el modelo del grupo de usuario
del oráculo de la práctica 6-2
 7-2 crear una entidad intersección con un

UID y agregar atributos
Modelar jerarquías, redes
y papeles
Objetivos
 Identificar relaciones recursivas
 Modelar estructuras de red
 Identificar y modelar roles
MODELANDO RELACIONES
RECURSIVAS
...y yo ...pero, yo soy
Su jefa
...el es mi
jefe
Jefe de
EMPLEADO
administrado por
Modelar Datos Jerárquicos
EQUIPO
# nombre
Compañía
DEPARTAMENTO
# * nombre
Division
Departamentos
DIVISION
Equipo # * nombre
COMPAÑIA
# * nombre
JERARQUIAS COMO
RELACIONES RECURSIVAS
EQUIPO
# nombre
compuesto de
DEPARTAMENTO
# * nombre
ELEMENTO DE
ORGANIZACION
DIVISION # * name
* type dentro
# * nombre
COMPAÑIA
# * nombre
Estructura de trabajo
Una parte de
COMPONENTE
# * identifier
Compuesto de
Estructuras de Trabajo
Una parte de
COMPONENTE
# * identifier
Compuesto de
Compuesto de
COMPONENTE COMPONENTE
# * identifier Una parte de # * identifier
Estructuras de Trabajo
REGLA DE ASAMBLEA
o cantidad
para para
Una parte de Compuesto de
# * identifier # * identifier
Compuesto de
# * identifier Una parte de # * identifier
Network Structures
ASSEMBLY
RULE
o quantity
for for
made up
of a part of
COMPONENT
# * identifier
Identifying Roles
ENROLLMENT
* date enrolled
* fee
for for
taken by
included in taught by INSTRUCTOR
COURSE RUN # * id
STUDENT the * name
# * id teacher * salary
* location
* name * start date of
for COURSE
the # * code
subject * name
of
Modeling Roles
enrolled PERSON
ENROLLMENT on # * id
* date enrolled * name
for
* fee o salary
for the
teacher
of
taught
by
taken by
for COURSE
COURSE RUN
# * code
* location
included in * name
* start date
Summary
 Modeling hierarchies
 Modeling networks
 Modeling roles
Practice
 8-1 Develop two ER diagrams, one as a
hierarchical structure and one as a
recursive structure.
Modeling Complex
Structures
Data Modeling and Relational
Database Design
Objectives
 Identify and model exclusive entities
 Identify and model exclusive
relationships
 Model over time
 Identify and resolve fan traps
 Identify and resolve chasm traps
 Consider convergent and divergent
models
 Model non-transferable relationships
Exclusive Entities
TITLE
# * product code
* title
* description
MOVIE GAME
* category * category
* duration * medium
O audio
* minimum memory
Exclusive Entities
COPY
* inventory num acquired from COMPANY
o condition the source of
# * id
* name
* telephone num
MEMBERSHIP o supplier num
held by
o sales contact
# * num the holder
* start date of
* expiry date
o
termination
Splitting Entities
COMPANY
COPY
acquired from
# id
* inventory num
o condition * name
* telephone num
SUPPLIER
the source of * supplier num

MEMBERSHIP * sales contact
held by
# * num
* start date
the holder
* expiry date of OTHER
o
termination
Nesting Entities
EMPLOYEE
authorized SALES
to drive CLERICAL
CAR REP
driven by
HUMAN
RESOURCES
TELESALES
Nesting Entities
AIRCRAFT
AIRPLANE
POWERED AIRPLANE
PROP PLANE
GLIDER
JET PLANE
OTHER
HELICOPTER HOVERCRAFT
AIRCRAFT
Recursive Subtypes
ORGANIZATION ELEMENT
of
ORGANIZATION
COMPANY ELEMENT
(ORGANIZATION) the classification TYPE
for
DEPARTMENT within
(SUBDIVISION)
made up of
Modeling Exclusive
Relationships
COMPANY
held by * name
* postal area
the holder of 0 contact name
MEMBERSHIP o
* num
* start date
* expiry date
the holder of CUSTOMER
o termination o * num
* first name
held by * last name
Modeling Exclusivity
“We offer membership to individual customers and companies”
MEMBERSHIP
MEMBERSHIP
INDIVIDUAL ORGANIZATION
MEMBERSHIP
CUSTOMER COMPANY CUSTOMER COMPANY
MEMBER
CUSTOMER COMPANY
Modeling Data over Time
What if you need to hold an apartment’s

rental history?
APARTMENT PERSON
rented by
# * id
# * code * last name
* address the renter of
* first name
PERSON
RENTAL HISTORY for
# * id
# * from date * last name
o to date the renter of * first name
for
rented by
APARTMENT
# * code
* address
employed
MEMBER by COMPANY
# * id the # * code
* last name employer * name
* first name of
EMPLOYMENT
HISTORY ENTRY
# * from date
o to date
for for
the
employed employer
by of
MEMBER COMPANY
# * id
# * code
* last name
* name
* first name
Fan Traps
PERSON the holder of POSITION

# * id # * job title
* last name held by o job description
* first name
employed by
included in
COMPANY
# * code
the * name the
employer of employer of
Fan Traps
PERSON employed POSITION POSITION
as HISTORY for
# * id # * job title
o job description
* last name * start date held by
for o end date
* first name the
employed subject
at for of
for
COMPANY ORGANIZATION
HISTORY HISTORY
* start date * start date
o end date
o end date
for
for
COMPANY
the # * code
employer * name the employer
for for
Resolving Fan Traps
EMPLOYMENT at COMPANY
HISTORY
the # * code
#* start date * name
employer
o end date
for
as
for
a party to
POSITION
PERSON
included in # * job title
# * id o job description
* last name
* first name
Chasm Traps
EMPLOYEE
authorized
employed
to use
by
employer used by
of
DEPARTMENT COMPANY CAR
Resolving Chasm Traps
EMPLOYEE
employed authorized
by to use
employer of used by
DEPARTMENT COMPANY CAR
appear on appear on
for for
ALLOCATION
Convergence
THING
Divergence
ADDRESS
WORD LINE
ADDRESS
Do you really need this level of detail?

Transferable Relationships
PERSON works in DEPARTMENT

# * id
* last name # * code
employs
* first name
Head office
Personnel Finance Sales

Non-Transferable Relationships
COMPANY
# * id
* name
COPY
acquired from * telephone num
SUPPLIER
* inventory num * supplier num
o condition the source of
* sales contact
OTHER
Summary
 Exclusive entities - supertypes and
subtypes
 Exclusive relationships
 Modeling over time - extra entities
 Complex structures - fan and chasm traps
 When to stop - convergence and
divergence
 Non-transferable relationships
Practice
 9-1 Create an ER diagram using arcs
and subtypes
 9-2 Create an ER diagram for data over
time
Normalization
Data Modeling and Relational
Database Design
Objectives
 Define normalization
 Explain the benefits of normalization
 Place tables fully in third normal form
 Explain how conceptual data modeling
rules help towards normalized tables
ER Diagrams and Normalization
ER Diagramming Normalization
 Top down  Bottom up

approach approach
 Fast  Very slow
 Examine  Examine existing
requirements data
 Business  Mathematically
knowledge
• Top down create - bottom upbased
checking
• Accuracy
• Greater understanding of the data
Normalization Terminology
 Normal form
 Data group
 Repeating group
 Dependency
 Determinant
 Key
 Foreign key
 Transitive
Normalization
Screen Collect individual items of

Report data from every possible source
Form
Normalization
Customer name
Customer address
Customer tel num
Screen
Report Order num
Form Order date
Invoice address
List the items as raw data

Normalization
Customer name
Customer address
Customer tel num
Order num
Order date
Invoice address
0NF 1NF 2NF 3NF Perform the rules of

normalization on the data
cus nme
cus add
cus tno
Normalization
Create an ERD from the

normalized data groups
0NF 1NF 2NF 3NF
cus nme
cus add
cus tno
Reglas de Normalizacion
 Collect and list the raw data 0NF
 Remove repeating groups 1NF
 Remove part key dependencies 2NF
 Remove inter-data dependencies 3NF
 Remove inter-key dependencies BC NF
 Test and identify transitive dependencies
 Optimize
 Retest
 Draw and use the model
Collect the Raw Data
0NF
1NF
2NF
3NF
BC NF
Test
Optimize
Retest
0NF
# customer name
order num
product num
product description
quantity ordered
customer address
date ordered
Remove Repeating Groups
1NF
0NF
1NF
# customer name 2NF
0NF customer address 3NF
# customer name BC NF
order num Test
Optimize
product num
Retest
product description
quantity ordered # customer name FK
customer address # order num
date ordered product num
product description
quantity ordered
date ordered
Remove Part Key
Dependencies
1NF 0NF
2NF
1NF
NO CHANGE
2NF
# customer name # customer name 3NF
customer address customer address BC NF
Test
Optimize
Retest
# customer name FK
# order num FK
# customer name FK
# order num
product num # order num
product description product num
quantity ordered product description
date ordered quantity ordered
date ordered
Remove Inter-Data
Dependencies
3NF 0NF
2NF NO CHANGE 1NF
# customer name 2NF
# customer name customer address 3NF
customer address BC NF
NO CHANGE # customer name FK Test
# order num FK Optimize
Retest
# customer name FK
# order num FK # order num
product num FK
quantity ordered
# order num
date ordered
product num
product description # product num
quantity ordered product description
date ordered
Remove Inter-Key
Dependencies
BCNF 0NF
3NF
NO CHANGE 1NF
# customer name 2NF
# customer name customer address 3NF
customer address BC NF
Test
# order num
# customer name FK Optimize
FK customer name FK
# order num Retest
# order num
product num FK FK
# order num
quantity ordered NO CHANGE product num
date ordered quantity ordered
# product num date ordered
product description # product num
NO CHANGE product description
Using the Rules to Test
0NF
1NF
2NF
Does each item of data depend 3NF
upon the Key, the whole Key and BC NF
Test
nothing but the Key? Optimize
Retest
Optimize
BCNF 0NF
1NF
# customer num 2NF
OPTIMIZED DATA GROUPS
customer name 3NF
BC NF
# customer num
Test
BCNF customer name Optimize
Transitive customer address Retest
# customer name
customer address
# order num
# order num
product num FK
customer name FK
customer num FK
# order num quantity ordered
product num FK date ordered
quantity ordered
date ordered
Retest
0NF
1NF
2NF
Does each item of data still depend 3NF
BC NF
upon the KEY, the whole KEY and Test
nothing but the KEY? Optimize
Retest
Drawing a Diagram from the
Groups
Groups become entities
CUSTOMER
Data become attributes
# num
name
address Foreign Keys become
relationships
Keys become UIDs
ORDER PRODUCT
# num
num
qty ordered #
description
date ordered
Entities and Normalization
 Does any attribute
EMPLOYEE
have more than one
# * badge num
value?
# * payroll num  Does any attribute
* first name need just part of the
* last name
UID?
* payroll category
* date of birth  Is any attribute
* employment status
* previous departments
dependent on
another attribute
and not the UID?
 Does any part of the
RESUMEN
 Collect and list the raw data 0NF
 Remove repeating groups 1NF
 Remove part key dependencies 2NF
 Remove inter-data dependencies 3NF
 Remove inter-key dependencies BC NF
 Test and identify transitive dependencies
 Optimize and retest
 Draw and use the model
 Normalizing an existing ER diagram
Practica
 10-1 crea una colección de datos
normalizados
 10-2 crear diagramas de entidad relación
desde los grupos normalizados
 10-3 evaluar un diagrama de ER usando
las reglas TNF
 10-4 reescribir el diagrama de ER
totalmente normalizado
Revisar el modelo
Conceptual
OBJETIVOS
 Revisar las técnicas del modelo entidad

relación
 Revisar las técnicas de normalización

Entidad
 Un objeto de interés del negocio
 Una clase o categoría de cosa
 Nombre de una cosa o sustantivo
 Una cosa con significado los cuales
necesitan de información
 Caja blanda
 Nombre en singular EMPLEADO
 Nombre en mayúscula
Atributo
 Sustantivo usado para describir una entidad
 Pieza especifica de información los cuales
necesitan saber
EMPLEADO
 Dentro de la entidad
* numero
 Un nombre reducido * nomina
 Obligatorio u opcional * nombre

* apellido
* categoría de
nomina
* nacimiento
Relación
 Es la manera de relacionar una entidad con
otra
 Una regla del negocio que nos da
información que necesitamos
 Lo que una cosa tiene que hacer con otra
 Una asociación de nombres entre entidades.
assigned to
responsable
de
Cada EMPLEADO debería tener asignado uno y solamente un DEPARTAMENTO

Cada DEPARTAMENTO debería ser responsable de uno a muchos EMPLEADOS
UNICO IDENTIFICADOR
Cada instancia de la entidad debe poder ser identificado únicament
Una combinación de atributos o relaciones que

que identifican una instancia especifica en cada
entidad
Modelando Exclusividad
“Ofrecemos calidad de miembro a los clientes individuales y compañía
MIEMBRO
MIEMBRO
MEMBER
CLIENTE COMPAÑIA CLIENTE COMPAÑIA

Modelar jerarquías y redes
EQUIPO
# * nombre
Compuesto de
DEPARTAMENTO
# * nombre
ELEMENTOS DE
ORGANIZACION
DIVISION # * nombre
* tipo dentro
# *nombre
COMPANIA
# * nombre
Normalización y Diagramas ER
Diagrama ER Normalizacion
 Desde abajo  Desde arriba

 rapido  Muy lento
 Examina  Examina los datos
requerimientos  Basada
 Conocimiento de matematicamente
negocio
• Crea desde abajo- chequea desde
arriba
• Precisión
• Gran entendimiento de los datos
Reglas de Normalización
 Recoge y enumera las informaciones
Totales 0NF
 Quita la repetición de grupos 1NF
 Quitar parte de las dependencias de
Las llaves 2NF
 Quitar los datos internos de las
Dependencias. 3NF
 Quitar las llaves internas de las
Dependencias BC NF
 Identifica dependencias transitivas
 Optimiza
Entidades y Normalización
 ¿Algún atributo tiene
mas de un valor?
EMPLEADO
 ¿Algún atributo necesita
# * numero parte del UID?
# * nomina
 ¿Algún atributo es
* nombre dependiente de otro y no
* apellido del UID?
* categoría de nomina
* fecha de nacimiento
 ¿Alguna parte del UID
* estado de empleado depende de otra parte
* departamentos anteriores del UID?
RESUMEN
 Revisar las técnicas de entidad relación
 Revisar las técnicas de normalización.

Practica
 11-1 Diagrame una área completa del
grupo de usuario del oráculo de la
práctica 6-2
 11-2 Crear un diagrama ER para un
acuerdo legal(opcional)
 11-3 Crear un diagrama ER para enviar
un acuerdo legal. (opcional)
Diseño Inicial de Base de
Datos
Objetivos
 Explicar los ajustes del diseño de base de
datos en el proceso del desarrollo.
 Traducir un modelo ER a un diseño de
 Documentar un diseño de base de datos.
MOVIENDO DENTRO DEL
DISEÑO
Información de los requerimientos del negocio
Modelando datos
Vista del Negocio
conceptuales
Diseño de base
Vista del Sistema
de datos logico
Construccion
fisica de base de
datos
Operación de la base de datos

Revisión de Terminología
CONCEPTUAL LOGICO
(Vista del Negocio) (Vista del sistema)
ANALYSIS DESIGN
ENTIDAD TABLA
RELACION LLAVES DESCONOCIDAS
ATRIBUTOS COLUMNA
UNICO LLAVE PRIMARIA

IDENTIFICADOR UNICA LLAVE
Crear el diseño del contorno
1 Mapear entidades simples a tablas

2 Mapear atributos a columnas, y
mostrar datos de documentos
3 Mapear identificadores únicos a llaves
primarias
4 Mapear relaciones a llaves
desconocidas.
Mapas de Entidades Simples
Nombre de Tabla EMPLEADOS
EMPLEADO Column
#(1)*numero name
#(2)* nomina Key type
# (3)o nombre Nulls
#(3)* apellido
o posicion
Sample
data
Mapa de Atributos
Nombre de Tabla EMPLEADOS
BADGE_ PAYROLL_ FIRST_ LAST_ POSITION
EMPLEADO NUM NAME
Column NUM NAME
#(1)*numero name
#(2)* nomina Key type
# (3)o nombre Nulls
#(3)* apellido NN NN NN
o posicion
Sample
data
Mapa UIDs
Nombre de la tabla: EMPLEADO
EMPLOYEE NUM NAME
Column NUM NAME
#(1)*numero name
#(2)* nomina Key type PK UK1 UK2 UK2
# (3)o nombre Nulls
#(3)* apellido NN NN NN
o posicion
Sample
data
Mapa de Relaciones- M:1
Table Name: EMPLOYEES
EMPLEADO DEP_
Column NUM NUM NAME NAME NUM
#(1)*numero name
#(2)* nomina Key type PK UK1 UK2 UK2 FK
# (3)o nombre Nulls NN NN
#(3)* apellido NN NN
o posicion
Sample
data
DEPARTAMENTO
# * numero
* nombre
*
Mapa de Relaciones-
Obligatorio 1:1
Column ID TYPE CYCLIST
BICICLETA
name _ NUM Nombre de
Tabla:
# * id Key type PK FK, UK
BICICLETA
* tipo Nulls
NN NN NN
Sample
data
CICLISTA
# * numero
* nombre
*
Mapa de Relaciones- Opcional
1:1
Column CYCLIST Nombre de
ID TYPE
name _NUM Tabla:
BICICLETA
Key type PK FK, UK BICICLETA
# * id Nulls
NN NN
* tipo Sample
data
O
Column NUMBER NAME BICYCLE
name _ID Nombre de
CICLISTA PK FK, UK tabla:
Key type
CICLISTA
# * numero Nulls
* nombre NN NN
* Sample
data
Mapa de Relaciones- Recursiva
1:M
Table Name: EMPLEADOS
el encargado de BADGE_ PAYROLL_ FIRST_ LAST_ POSITION EMP_
Column NUM NUM NAME NAME MAN_
EMPLEADO name NUM
Key type PK UK1 UK2 UK2 FK

#(1)* numero
Nulls
#(2)* pago NN NN NN NN
# (3)o nombre
#(3)* apellido Sample
o posicion data
Administrado
por
Mapa de Relaciones- Recursiva
1:1
Nombre de tabla: PERSONAS
el esposo de
PERSON_
Column ID NAME SPOUSE
PERSONA _ID
name
Casada para Key type PK FK,UK
# * id Nulls
nombre NN NN
*
Sample
2345 ANN 6785
data
6785 RAY 2345

RESUMEN
 Mapas de entidades simples a tablas
 Mapas de atributos a columnas
 Mapa UIDs para una llave primaria
 Mapa de relaciones para llaves de
palabras claves
Practica
 12-1 crear una tabla inicial de dos
entidades
 12-2 crear una tabla inicial para tres
entidades
 12-3 crear una tabla inicial para cuatro
entidades
 12-4 crear una tabla inicial diseñada para
una ERD con una relación recursiva
(opcional)
Relaciones exclusivas y
entidades
Objetivos
 Examinar diseños de arcos explícitos
 Examinar diseños de arcos genéricos
 Examinar diseños de tablas de supertipos
y subtipos.
 Diseñar tablas solas
 Diseñar múltiples tablas
 Diseñar tablas de arco
Mapeando arcos
INDIVIDUAL
HABITACIONES
o # id
DE OFICINA
# ID *
* PARTNERSHIP
# N° habitación o
* # código
*
COMPANIA
o
# num
*
Subtipos de Mapas
TITULO
# * código producto
PELICULA  Diseño de tabla sola

* categoría
 Diseño de tablas
múltiples
 Implementación de
JUEGO
* medio
arcos
Diseño de Arco Explicito
INDIVIDUAL
Habitaciones de o # id
oficina
*
# ID SOCIEDAD
* o #
* code
# N° habita
Table Name: * o COMPANIA
# num
*
HABITACIONES DE OFICINA
BUILDING SUITE COMP_
Column name _ID IND_ID PART_CODE
_NO NUM
Key type PK PK FK1 FK2 FK3
Nulls NN NN
Sample 1024 101 30045
data 512 210 A4431
977 144 54532
3041 510 10844
DISEÑO DE ARCO GENERICO
INDIVIDUAL
HABITACIONES o # id
DE OFICINA *
# ID SOCIEDAD
* o #
* code
# No habita.
Nombre de tabla
* o COMPANIA
# number
*
Habitaciones de oficina
BUILDING SUITE
Column name _ID RENTER_ID RENTER_TYPE
_NO
Key type PK PK FK
Nulls NN NN NN NN
Sample
data
1024
512
977
3041
101
210
144
510
30045
A4431
54532
10844
I
P
I
C
!
DISEÑO DE UNA TABLA SOLA
TITULO
# * código producto
PELICULA JUEGO
Nombre de tabla:
* categoría * medio
TITULO
Categoría Medio
Nom.columna Cod.Produc Tipo
pelicula juego
Tipo dominante PK
Efecto NN NN
Muestra 453 M HORR
dato 516 G CD
677 M DRAMA
444 G CASS
Multi diseño de tablas
TITULO
# * código de producto
Nombre de tabla: PELICULA Nombre de tabla:
JUEGO
PELICULA * categoría * medio JUEGO
Nom.columna cod.prod Categ. pelicula Cod.prod Medio juego

Column name
Tipo dominante PK Tipo dominante PK
efecto NN NN efecto NN NN
muestra 453 HORR muestra 516 CD
dato 677 DRAMA dato 444 CASS
Diseño Del Arco De Tabla
EMPLEADO # * divisa numérica
* nombre
* apellido EMPLEADO
EMPLEADO FIJO
CONTRATADO
* salario * Precio por hora
* Tarifa en horas
Un miembro de
Miembro de
Compuesto de Compuesto de
DEPARTMENT UNION
# * code # * num
Diseño Del Arco De Tabla
Asignado a
# * divisa numérica # * código
* nombre compuesto de
* apellido
Clasificado como
Clasificado como
Un tipo de Un tipo de
Un miembro de
EMPLEADO EMPLEADO
UNION
FIJO CONTRATADO
•precio por hora # * num
* salario
•* Tarifa en horas
extras compuesto de
RESUMEN
 Escogiendo arcos de opciones
 Tabla explicita de diseño
 Tabla genérica de diseño
 Escogiendo supertipos y subtipos de
opciones
 Diseñar tablas solas
 Diseñar múltiples tablas
 Diseñar arcas de tablas
Practica
 13-1 crea un diseño explicito de la tabla
de arco
 13-2 crea un diseño genérico de la tabla
de arco
 13-3 Crea un solo subtipo de diseño de
tabla
 13-4 crea múltiples subtipos de diseño de
tabla
Fomente el Diseño de
Base de Datos
Objetivos
 Especifique los apremios de referencia de
la integridad
 Índices de Diseño
 Establecer una vista de base de datos
 Denormalice un diseño de base de datos
 Plan de Almacenamiento Físico
Integridad Referencial Especifica
DEPARTAMENTO EMPLEADO
RULE
FRED
DEPT 40
JOE RESTRINGIDO
BILL
FRED
JOE
CASCADA
DEPT 40
BILL
Integridad Referencial Especifica
DEPARTAMENTO EMPLEADO
RULE
FRED
DEPT 40 JOE ANULE
BILL
FRED
DEPT 40 JOE
BILL DEFECTO
DEPT 99999
Diseño del Índice de contorno
ADAMS DATA BLOCKS
ALLEN
SMITH
BLAKE ALLEN
BLAKE
JAMES WARD
CLARK
FORD JONES
JAMES MARTIN
REY
JONES BLAKE
CLARK
KING SCOTT
MARTIN KING
MILLER
TURNER MILLER
TURNER
SCOTT
ADAMS
SMITH
INDEX BLOCKS JAMES
FORD
TURNER MILLER
WARD
Establecer vistas
CUS_ CUS_ CUS_ ORD ORD ORD_

NO LNME FNME -NUM -DTE CUS_NO
Considerar Datos Derivados
LLAVES ARTIFICIALES
Cliente
#
o Nombre
# * Apellido
# * Dirección
Cliente
# * código
* Nombre
* Apellido
* Dirección
Planeando Almacenaje físico
 Estime la necesidad de disco necesitada
 Decida una colocación
 Defina una asignación de almacenaje
RESUMEN
 Define apremios de la referencia de
integridad
 Índices de diseño
 Establece vistas
 De normaliza el diseño
 Plan de almacenaje físico
Resumen
Datos que modelan y diseño
emparentada de base de datos
Resumen
CONCEPTUAL
ERM
LOGICAL
Tabla de definiciones
FISICO
Base de Datos

Modelo Entidad Relación

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modelo Entidad Relación

Cargado por

Copyright:

Formatos disponibles

Modelo Entidad Relación

 Un Objeto de Interés para el Negocio.

 Usar Sustantivos para describir

 Nombres de atributos en nombre

Personal Finanzas Ventas

Modelando Datos y Diseño de

 Grado (Cardinalidad Máxima)

Debe ser Uno o mas

Cada EMPLEADO debe tener asignado a uno y solo un DEPARTAMENTO

Cada DEPARTAMENTO puede ser responsable de uno o mas EMPLEADOS

Cada EMPLEADO debe tener asignado a uno y solo un DEPARTAMENTO

Cada DEPARTAMENTO puede ser responsable de uno o mas EMPLEADOS

Cada ESTUDIANTE puede matricularse en uno o mas CURSOS

Cada CURSO puede ser tomado po uno o mas ESTUDIANTES

Representa una fotografía en el tiempo

 Establecer las Relaciones para el Caso

Los Cuervos Muertos Vuelan

Nombre – Califica a un Empleado

Categoría Empleado (salario)

Fecha de Cumpleaños - Califica a un Empleado

Estado del empleado (activo, licencia, culminado) -

Es este atributos realmente necesario ?

Guárdese de requisitos obsoletos de sistemas anteriores

Guárdese de datos derivados

Analice las cualidades agregadas

¿Puede una cualidad tener más de un

fecha de la transacción ¿Puede una cualidad tener más de un

Sí, más de un artículo se puede alquilar a la vez. Una entidad falta.

fecha de la transacción ¿Puede una cualidad tener más de un

Sí, más de un artículo se puede alquilar a la vez. Una entidad falta.

Sí, detalles de la revisión. Una entidad falta.

Sí, detalles de la revisión. Una entidad falta

Las cualidades derivadas son

 Es marcada con una etiqueta

 Es marcada con una etiqueta o

Atributo - * Tamaño Del Motor

Volumen Inicial El 100%

Datos del Datos de la

Datos Meta datos

Gerencia del almacén

Una combinación de atributos o relaciones que

342 CLIENTE 876

Marque el UID con etiqueta #

¿Qué es lo que usted necesitaría para saber identificar

Usa # para indicar que atributo Utilice una barra de UID

Nombre de lugar + Titulo de juego+

Hora del funcionamiento +

Nombre del cliente

#(1)* Divisa numérica

 6-2 crea UIDs para el grupo de usuario del

¿En qué entidad usted almacenaría el precio de

disponible como Surtido de

ARTICULO DE CATALOGO ARTICULO DE CATALOGO

Disponible como Surtido de Disponible como Surtido de

TITULO PROVEEDOR TITULO PROVEEDOR

 7-2 crear una entidad intersección con un

the source of * supplier num

CUSTOMER COMPANY CUSTOMER COMPANY

What if you need to hold an apartment’s

PERSON the holder of POSITION

DEPARTMENT COMPANY CAR

Do you really need this level of detail?

PERSON works in DEPARTMENT

Personnel Finance Sales