Modelo ER

Este curso trata de las técnicas

involucradas en el modelo y diseño
de bases de datos. La transformación
efectiva de los requerimientos del
negocio en un sistema operacional
requiere de un conjunto integrado de
Métodos, Herramientas y
Técnicas.
 Modelo ER

Métodos Técnicas

Herramientas
 Métodos
 En casi cualquier método de
desarrollo existen una serie de
tareas para la elaboración del
proyecto. A la manera en que estas
tareas son estructuradas se le llama
metodología. Algunas tareas pueden
ser comunes en la mayoría de
métodos, aunque podrían tener
nombre diferente.
Tarea Propósito
Definición de Requerimientos del Se Obtiene un entendimiento de las
Negocio. necesidades y objetivos del negocio.
Examinar el Sistema existente Obtener un entendimiento detallado
del sistema existente.
Arquitectura Técnica Especifica las bases técnicas del
proyecto
Diseño y Construcción de la BD Diseña y Construye la BD a partir de
los requerimientos de información.
Diseño y Construcción de Módulos Diseña y Construye los detalles
técnicos y funcionales de cada
modulo.
Conversión de Datos Migrar y convertir data existente
Documentación Producirla de forma impresa o
ayudas en línea
Pruebas Probar la calidad del sistema de una
manera integrada.
Entrenamiento Entrenar a usuarios y
administradores a usar el nuevo
sistema
Transición Construye un plan para el uso del
 Plan de trabajo incluyendo
metodos y tiempos.
Definición de Requerimientos del ▒▒▒▒▒
Negocio.
Examinar el Sistema existente ▒▒▒▒▒
Arquitectura Técnica ▒▒▒▒▒▒▒▒▒▒
Diseño y Construcción de la BD ▒▒▒▒▒▒▒▒▒▒
Diseño y Construcción de ▒▒▒▒▒▒▒▒▒▒
Módulos
Conversión de Datos ▒▒▒▒▒▒▒▒▒▒▒▒▒▒
Documentación ▒▒▒▒▒▒▒▒▒▒▒▒▒
Pruebas ▒▒▒▒▒▒▒▒▒▒
Entrenamiento ▒▒▒▒▒▒▒▒▒▒▒▒▒
Transición ▒▒▒▒▒▒▒▒▒▒▒▒▒
Soporte post sistema
▒▒▒
 Herramientas:

Existen muchas herramientas que

ayudan en el diseño y construcción
de aplicaciones y Bases de Datos,
Como: Oracle Designer/2000 y Erwin.
 Técnicas:
Existe un gran número de técnicas
disponibles para ayudarle a crear un
sistema, pero generalmente estas caen
dentro de tres categorías:
 Datos: Modela los requerimientos de
información del sistema.
 Procesos: Modela las funciones del
sistema.
 Referencia Cruzada: Se asegura de que
todos los datos requeridos por una función
estén disponibles y que todos los datos
modelados sean usados por una función.
Trataremos con algunas técnicas de
modelo de datos:
 Normalización, también llamada TNF
o análisis de datos relacional (RDA).
 Primer Borrador del diseño de la
Base de Datos
El tema se enfocará en las técnicas de
modelado más que en las
herramientas.
 Desarrollo de la Base de Datos y la
Aplicación

R e q u e r im ie n t o s d e l
N e g o c io

M o d e lo E R , M o d e lo d e D a to s C h e q u e o C ru z a d o M o d e lo d e D a to s
C o n c e p tu a l D e fin ic ió n d e F u n c io n e s
D e fin ic ió n d e E n tid a d e s C o n c e p tu a l

T a b la s , In d ic e s M o d u lo s ( p a n ta lla s ,
V is ta s D is e ñ o d e B a s e d e D a to s C h e q u e o C ru z a d o D is e ñ o d e B a s e d e D a to s
re p o rte s , m e n u ,
u tilid a d e s )

C o n s tr u c c ió n d e B a s e d e C o n s tr u c c ió n d e B a s e d e
D a to s D a to s

B a s e d e D a to s A p lic a c ió n

S is t e m a O p e r a c io n a l
Proceso de Desarrollo de BD

Modelo Conceptual de Datos

Diseño Lógico de la Base de Datos

Construcción Base Datos Física

Base de Datos Operacional

Terminología
Conceptual Lógico
(Vista del Negocio) (Vista del Sistema)

Análisis Diseño
Entidad Tabla
Relación Llave Foránea (FK)
Atributo Columna
identificador Llave Primaria (PK)
Único Llave única
Independencia del Hardware y
Software
 El modelo conceptual de datos debe ser
independiente del hardware o softaware,
el cual eventualmente será usado en la
implementación. Esto permite que se tome
una vista objetiva de las necesidades del
negocio sin las restricciones de un
ambiente especifico. Esto da el potencial
de poder fabricar un prototipo de los
requerimientos, para diferentes
ambientes, asi, si el ambiente necesita ser
cambiado despues de la implementación,
Independencia del Hardware y
Software
El modelo original solo necesita ser
aplicado en el nuevo ambiente, sin
necesidad de repetir los
requerimientos de la fase de
definición.
Un Modelo ER de la fase de diseño
podria ser aplicado a cualquier tipo
de Base de Datos:
 Jerarquica, Red, Relacional y Arch.
Planos
 Elementos Principales de un
Diagrama Entidad-Relación
 Entidades
 Atributos
 Supertipos
 Subtipos
 Arcos
 identificadores únicos
 Relaciones: Mandatoria u opcional, De Uno
a Muchos, de Muchos a Muchos y de uno
 Relaciones:
 Mandatoria u opcional
 De Uno a Muchos
 De Muchos a Muchos, y
 De uno a uno
 Recursiva

 Un Modelo puede incluir información No

Diagramática:
 Descripciones de entidades y atributos
 Formatos de atributos, valores permitidos
 Dominios
 Reglas del negocio
 Valores derivados
 Algoritmos
 Entidad
Una entidad debe pensarse como una cosa
de significancia acerca de la cual el
negocio necesita guardar información.
Cosa....
Todas las entidades son cosas, pero, no
todas las cosas son entidades.

De significancia...
Se tiene que estar seguro de que el negocio,
para el cual usted esta modelando, esta
realmente
Interesado en esa “Cosa” (entidad).

 Puede ser significante, pero si no se

necesita guardar información de esa
“cosa” entonces no es una entidad...
 La entidad se representa por un
rectangulo con los bordes
redondeados, El nombre de la
entidad debe ir en la parte superior
en mayuscula y en singular, el
nombre puede llevar un sinonimo,
separado del nombre por una pleca
“/”
 Entidad
Entidad

COMPAÑÍA / CIA EMPLEADO

CLENTE
nombre Atributo
apellido s
 Instancias de Una Entidad

Cuando se identifica una entidad, se

identifica un grupo de cosas, dentro
de ese grupo existen instancias
individuales.
Ej, En una cia. Que tiene muchos
departamentos, la entidad
DEPARTAMENTO tiene muchas
instancias: personal, contabilidad,
finanzas, etc...
 Identificando una Entidad
 Identificar un Nombre
 Es significante?
 El negocio necesita guardar información
acerca de la misma?
 Es un grupo o una instancia?
 Identificando una Instancia
Única
 Cada Instancia de una entidad debe
ser identificable de manera única de
las otras instancias de la misma
entidad. Un atributo o conjunto de
atributos que haga esto es llamado
identificador Único (UID).
 Relación Uno a muchos
 Una relación M:1 o M a 1 tiene un
grado de uno a mas en una dirección
y un grado de uno y solo uno en la
otra.
 Es el mas común tipo de relación,
tambien se conoce con el nombre de
Padre-Hijo o Maestro-Detalle.
 La mayoría de relaciones uno a
muchos tienen entidades hijas
opcionales y
 Entidades Padres mandatorias. Esto
significa que una Instancia de Padre
puede existir sin estar asociado a los
hijos, pero los hijos no pueden existir
sin el Padre. En terminos de sistema,
la entidad padre es creada y hasta
entonces los hijos pueden ser
pegados a esa entidad.
 Visitado por

Cliente Vendedor
Asignado A

Este ejemplo muestra como las reglas

del negocio se trasladan a un modelo
de datos simple.
 Un vendedor puede ser asignado a
muchos clientes
 Un vendedor puede ser asignado a
ningún cliente
 Un cliente podría siempre tratar con un
vendedor especifico
 Un cliente podría nunca tratar con un
vendedor
 La cia. Necesita guardar información
de los clientes aunque no tengan
vendedor asignado.
 La cia. Necesita guardar información
de los vendedores, aunque no
tengan clientes asignados.
 Relación Muchos a Muchos
 M:M o M a M tiene un grado de uno a
muchos en ambas direcciones.
 La relación M:M es bastante común
al comienzo del análisis, sin embargo
este tipo de relación debe resolverse
para que está quede lista para el
diseño.
 La mayoría de las relaciones muchos
a muchos son opcionales en ambas
direcciones. Esto significa que una
instancia de cada entidad entidad
puede existir sin ninguna asociación.
En términos de sistema, Cada una
puede crearse independientemente y
después asociarse.
 Atendido por

Paciente Enfermera
Asignado A

 Una enfermera podría ser

responsable por algunos pacientes.
 Una enfermera podría ser
responsable de ningún paciente
 Un paciente podría tener varias
enfermeras que lo atiendan
 Un paciente podría tener ninguna
enfermera asignada a su cuidado
 El hospital necesita guardar
información de los pacientes, aun si
estos no tienen asignado una
enfermera.
 El hospital necesita guardar
información de las enfermeras, aun
si estas no tienen asignado un
paciente.
 Relación Uno a Uno
 1:1 o 1 a 1 tiene el grado de uno y
solo uno en ambas direcciones.
 Es bastante rara, Si se identifica una,
se debería investigar un poco más
los requerimientos de información
del negocio, pueda ser que las dos
entidades sean la misma.
 Opcionalidad Uno a Uno
 La relación uno a uno que es
mandatoria en ambos sentidos es
bastante rara y significa que el
negocio requiere que una instancia
de cada entidad sea creada
simultáneamente. Esto indica que las
entidades podrían ser, casi con
seguridad, la misma entidad.
 Usada por

Bicicleta Ciclista
El que maneja la

 Una bicicleta puede ser usada por un

ciclista.
 Una bicicleta puede ser usada solo
por un ciclista.
 Una bicicleta podría ser usada por
nadie.
 Un ciclista puede usar una bicicleta
 Un ciclista puede usar solo una
bicicleta
 Un ciclista puede no usar una
bicicleta
 El club necesita guardar información
de los ciclistas, aun si estos no usan
las bicicletas
 El club necesita guardar información
de las bicicletas, aun si estas no son
usadas
Determinando la existencia
de una relación
El primer paso que debe tomar después de haber
identificado sus entidades es decidir la relación
entre esas entidades. Siempre pregúntese acerca
de la existencia de la relación, no asuma nada.
Examine cada entidad en relación a la otra entidad
y hágase la siguiente pregunta:
 ¿Hay una relación significativa entre estas dos
entidades?
 También examine cada entidad con relación a sí
misma, podría encontrar que una instancia tiene
una relación significativa con otra instancia de la
misma entidad.
 Ej. :
¿Existe una relación significativa entre
miembros y rentas?
 Si es razonable que exista porque

cada miembro renta películas.

 Nombrando las
relaciones
 El nombre de la relación es muy importante, es la
manera de mostrar que entiende de que manera
se une la información del negocio, siempre
considere cuidadosamente el nombre cuando
identifique una relación.
 ¿Como esta la primera entidad relacionada con la
segunda?
 ¿Como esta la segunda entidad relacionada con
la primera?
 ¿Que reglas del negocio juntan las entidades?
 ¿Que pasaría si estas entidades no se relacionan?
 Ej: Si tomamos una renta de videos
 ¿Cómo se relaciona copia con
originales?
 Cada copia es de un original
 ¿Cómo se relaciona original con
copia?
 Cada original esta disponible como
una copia.
 Nombres pares:
 Los nombres de las relaciones son a
menudo pares, ej:
 Basado en y la base de
 Comprado a y el suplidor de
 Operado por y el operador
de
 Representado por y la
representación de
 Responsable por y el
responsable de
 No use “relacionado a” o “asociado con”,
la sola presencia de la relación ya indica
una asociación, busque un nombre
significativo en términos del negocio.
 Determinando el grado
 Determine el grado en cada dirección de la
relación
 ¿Puede más de una instancia de la primera
entidad estar relacionada con la segunda?
 ¿ Puede más de una instancia de la segunda
entidad estar relacionada con la primera?
 Ej: hablando de renta de videos
 ¿Cuántos originales puede tener una copia?
 Una copia solo puede tener un titulo original.
 ¿Cuentas copias existen para un original?
 Cada original puede tener muchas copias.
 Determinando la
opcionalidad
 Se debe determinar en cada dirección de la
relación
 ¿Debe la primera entidad estar asociada a la
segunda?
 ¿Debe la segunda entidad estar asociada a la
primera?
 ¿Existe alguna excepción?
 ¿Que pasaría si alguna de las entidades existiera
y la otra no?
 Recuerde que mandatorio significa que si una
instancia de una entidad existe entonces una
instancia de la otra entidad también debe existir.
Una relación opcional significa que “es posible”
en algunas circunstancias que una exista sin la
otra, aun si esta existencia sea solo por un
 Ej: de los videos
 ¿Para cada original debe existir siempre
una copia?
 Un original podría no tener ninguna copia
disponible todavía, así que no haría
referencia a ninguna copia aun.
 ¿Para cada copia debe existir siempre un
original?
 Si, cada copia debe tener siempre un
original.
 Recuerde que la relación mandatoria es
una línea continua y la opcional es una
línea punteada.
 Atributos
 Son información acerca de la cual una entidad necesita
saber o guardar, los atributos describen una entidad así:
 Calificándola
 Identificándola
 Clasificándola
 Cuantificándola
 Expresando su estado
 Los atributos representan un tipo de descripción o detalle
para cada instancia.
 Ej: 77511 o 75318 pueden ser valores para el atributo de
numero de empleado.
 Juan puede ser un valor para el atributo primer_nombre.
 Cuándo considere nombres para los atributos asegúrese de
que sean claros y concisos, evite la ambigüedad, por
ejemplo cantidad es un nombre confuso, ¿qué cantidad
seria?, cantidad ordenada, cantidad enviada, retirnada....
todas son posibles interpretaciones así que asegúrese de
usar un nombre especifico.
 No necesita incluir el nombre de la entidad en los atributos,
por ej: si la entidad es curso y el atributo es código, no
necesita poner codigo_curso, el nombre curso es implícito
por el nombre de la entidad.
 Si el nombre de un atributo tiene más de una palabra
sepárelo con un espacio.
 Nombrar un atributo fecha siempre es peligroso, asegúrese
de que entiende exactamente para que es ese campo fecha
y documéntelo.
 Hágase la siguiente pregunta: Que información necesito
conocer o guardar acerca de la entidad “X” y si esa es
información es necesaria y significativa:
 Ej
 Entidad: Atributos:
 Personas------------------- primer nombre, primer apellido
 Opcionalidad de
atributos
 Los atributos pueden ser opcionales y
mandatorios
 Los opcionales se les pone una O al lado izq. Del
atributo y
 Los mandatorios se les pone un * a l lado izq. Del
atributo.
 Ej: el código es mandatorio, en cambio una
descripción puede ser opcional.
 Identificadores únicos de atributos:
 Pueden ser simples y compuestos, simples son un
solo atributo y compuestos varios. Se marcan con
un símbolo # e identifican de manera única cada
instancia diferenciándola de las demás.