1
© Bases de Datos / O.E.I../ U.P.M.
Diseño Lógico de Bases de Datos
n Modelo Entidad/Relaciónn Modelo Relacionaln Paso a tablas
Modelos de Datos
© Bases de Datos / O.E.I../ U.P.M.
Modelo Entidad-Relación
n Formulado por P.P. Chen en 1976n Modelo de datos que representa un
esquema de base de datos medianteentidades y asociaciones
n Describe una base de datos de una formasencilla y global
n Se realiza a partir de los requisitos de datosque debe cumplir una base de datos
2
© Bases de Datos / O.E.I../ U.P.M.
n Entidad• Objeto del mundo real que tiene existencia pos
sí mismo• Compuesto de ocurrencias de entidad• Ejemplo
– Entidad Clientes– Cliente “Pepe Perez” con DNI “12345678”
• Atributos: definen las propiedades de unaentidad, basados en un dominio (conjunto devalores posibles que puede tomar)
Entidades
© Bases de Datos / O.E.I../ U.P.M.
Entidades
n Atributo - Característica propia de unaentidad, común para todas lasocurrencias del mismo tipo
n Dominio - Conjunto de valorespermitidos para un atributo
n Para cada atributo hay que definir:• Nombre Descripción Dominio
Función (identificación o definición)
3
© Bases de Datos / O.E.I../ U.P.M.
Entidades
n Ejemplo:n Entidad: Empleado
Nombre de atributo: Código• Descripción: Código único por empleado
asignado por la empresa• Función: Identificación (+Definición)• Dominio: Números positivos de dos cifras
© Bases de Datos / O.E.I../ U.P.M.
Entidades
María AnguianoDNI: 36061281
Gran Vía 9
Sucursal BarcelonaCódigo: 02
Ocurrencias de entidad
Empleado Departamentos
DNI
Domicilio
Nombre
Código
Descrip.
Entidades
4
© Bases de Datos / O.E.I../ U.P.M.
Modelo Entidad-Relaciónn Relación o Asociación
• Expresa una asociación entre ocurrencias deentidad
• Puede tener atributos propios• Grado: número de entidades que asocia• Cardinalidad:
– número de ocurrencias de una entidad que puedenasociarse con otra entidad
– Máxima - 1:1, 1:N, N:1, N:M– Mínima - 0:0, 1:0, 0:1, 1:1
© Bases de Datos / O.E.I../ U.P.M.
Relaciones
n Conjunto de ocurrencias de relación delmismo tipo
Empleado DepartamentoTrabaja en
5
© Bases de Datos / O.E.I../ U.P.M.
Relaciones
n Las relaciones también pueden teneratributos
ProductoCliente Compra
Fecha
© Bases de Datos / O.E.I../ U.P.M.
Relaciones
n Es importante el “rol” o “papel” de cadaocurrencia
n Se denomina grado de una relación alnúmero de entidades que relaciona
Empleado Es Jefe de
Jefe
Subordinado
6
© Bases de Datos / O.E.I../ U.P.M.
Cardinalidad Máxima
• Número de ocurrencias de entidad que sepueden asociar como máximo a otra através de una relación
A Ba1
a2
an
b1
b2
bm
......
1:1
Ej.:Una persona tiene un coche y un coche es de una sola persona
© Bases de Datos / O.E.I../ U.P.M.
Cardinalidad
A Ba1
a2
an
b1
b2
bm
......
1:N
Ej.:Una persona tiene varios coches y un coche es de una sola persona
7
© Bases de Datos / O.E.I../ U.P.M.
Cardinalidad
A Ba1
a2
an
b1
b2
bm
......
N:1
Ej.: Una persona tiene un coche y un coche es de varias personas
© Bases de Datos / O.E.I../ U.P.M.
Cardinalidad
Ba1
a2
an
b1
b2
bm
......
N:M
A
Ej.:Una persona tiene varios coches y un coche es de varias personas
8
© Bases de Datos / O.E.I../ U.P.M.
Cardinalidad Mínima
• Número mínimo de ocurrencias de entidadque se deben asociar a otra a través deuna relación
• Posibilidades: 0:0, 0:1, 1:0, 1:1
Nota: Hay que tener especial cuidado con las mínimas 1:1
Empleado DepartamentoTrabaja en(0,1)(1,N)
© Bases de Datos / O.E.I../ U.P.M.
Cardinalidad
n Ej.:
Empleado DepartamentoTrabaja en
Compañía Pertenece
(1,M)
(1,1)
(0,N)
(0,1)
9
© Bases de Datos / O.E.I../ U.P.M.
Modelo Entidad-Relación
n Clave de Entidad• Atributo o conjunto de atributos que identifican
de forma única cada ocurrencia• Si una entidad no tiene clave se dice que es
débil y que tiene dependencia de Identificación• Una entidad es débil si depende de la
existencia de otra entidad
© Bases de Datos / O.E.I../ U.P.M.
Claves
n Dependencia de Identificación (ID) - Laentidad no tiene clave primaria
Cliente FacturaTiene(1,1) (0,M)
C#
Nombre
Domicilio
Código
Importe
Si la factura tiene códigos que se repiten por cliente, no tendráclave, pero sí un discriminador
Facturas tiene dependencia de ID respecto de Cliente
10
© Bases de Datos / O.E.I../ U.P.M.
Claves
n Dependencia de existencia - Laexistencia de una ocurrencia de entidaddependende de la existencia de otra
Cliente FacturaTiene(1,1) (0,M)
C#
Nombre
Domicilio
Código
Importe
Aunque Factura tenga clave, si se da de baja uncliente hay que dar de baja todas sus facturas
© Bases de Datos / O.E.I../ U.P.M.
Modelo Entidad-Relación
n Representación gráfica• Entidades: rectángulos• Atributos: incluidos en la entidad, o con elipses
conectadas a ésta• Relaciones: rombos o hexágonos, uniendo las
entidades asociadas• Cardinalidad: se detalla encima de las líneas
que asocian entidades
11
© Bases de Datos / O.E.I../ U.P.M.
Representación gráfica
E#NombreCategoría
Empleado
Trabaja
Fecha
Entidad con atributos
Relación con atributos
© Bases de Datos / O.E.I../ U.P.M.
Ejemplo
Cliente ProductoCompra(0,M)
C#
Nombre
Domicilio
Código
Precio
EmpleadoTrabajaDepartamento(1,1)
(0,N)
(0,M)
(0,M)(0,N)
Fecha
(0,N)
(1,M)
Nombre
E#
D# Descripción
12
© Bases de Datos / O.E.I../ U.P.M.
Modelo Entidad-Relaciónn Ejemplo (Requisitos)n Departamentos: código único por departamento y el nombren Proyectos: código único por proyecto y nombre. Cada proyecto se
gestiona por un solo depto y un depto puede gestionar variosn Empleados: código único de empleado, nombre y apellidos, dirección,
teléfono, fecha de nacimiento, sexo, si está casado o no y sueldo quepercibe.
n Un empleado pertenece a un solo depto y en un depto puede habervarios empleados. Por otro lado cada departamento tiene unempleado como jefe.
n Los empleados pueden participar en varios proyectos y en unproyecto pueden participar varios empleados, pero interesa saber eltiempo (en horas) que dedica cada empleado a los proyectos en losque participa.
© Bases de Datos / O.E.I../ U.P.M.
Modelo Entidad-Relación
n Ejemplo (Diagrama Entidad-Relación)EMPLEADO
E#NombreApellidosDirecciónTelefonoFechaNacSexoCasadoSueldo
DEPARTAMENTO
D#NombreDep
PROYECTO
P#NombreP
ES JEFE DE(1,1)
(0,1)
REALIZA
(0,N)
(1,1)
PERTENECE(1,N) (1,1)
PARTICIPA
(0,N)
(0,M)Tiempo
13
© Bases de Datos / O.E.I../ U.P.M.
Modelo E/R: Restricciones
n Si no se puede representar una relaciónN:M, usar dos relaciones 1:M
ProductoCliente Compra
Fecha
(0,M)(0,N)
ProductoCliente
Fecha
Detalle deCompra
Realiza Aparece(0,M) (1,1)(0,M)(1,1)
© Bases de Datos / O.E.I../ U.P.M.
Modelo Relacionaln Está basado en la teoría de conjuntos y en
el concepto matemático de relaciónn La estructura lógica principal son tablas o
relacionesn Cada relación tiene un número fijo de
columnas o atributos (esquema o intensión)y un número variable de filas o tuplas(extensión)
n Una BD relacional está compuesta porvarias tablas o relaciones
14
© Bases de Datos / O.E.I../ U.P.M.
Modelo Relacional
n Ejemplo
DNI Matricula38976 CC1232145 C8790
M1234
DNI Nombre Domicilio38976 Pepe Aquí2145 María Allí1234 Juan Aquí
Personas
CochesMatricula Modelo Año
M1234 Ford 1992Citroen 1995
CC123 Ford 1989C8790
2145
Tiene
© Bases de Datos / O.E.I../ U.P.M.
Atributosn Conjunto de símbolos tomados del
universo del modelo conceptualn Se usan letras para representarlos:
A,B,C,...n Descriptor: conjunto de uno o más
atributos (usaremos X,Y,Z,...)n Cada atributo se asocia con un conjunto
de valores posibles que denominamosdominio
15
© Bases de Datos / O.E.I../ U.P.M.
Tupla, cardinalidad y grado
n Ejemplo:
n Grado: Número de atributosn Cardinalidad: Número de tuplas
A1 A2 Ai An
a11 a12 a1j a1n
am1 am2 amj amn
R:Tupla
Atributo
© Bases de Datos / O.E.I../ U.P.M.
Condiciones para relaciones (I)
• Cada tabla debe contener un solo tipo defilas
• Cada fila debe ser única (sin repeticiones)• Cada columna tiene un nombre único• Cada columna tiene que ser única• Cada columna toma su valor de un
dominio
16
© Bases de Datos / O.E.I../ U.P.M.
Condiciones para relaciones (II)
• Un dominio puede ser común paradiferentes columnas
• Las filas pueden estar en cualquier orden• Las columnas pueden estar en cualquiert
orden
© Bases de Datos / O.E.I../ U.P.M.
Clave
n Cada relación tendrá una combinaciónde atributos que, tomados en conjunto,identifican de forma única cada tupla.
• Si tiene más de una, se elige la “principal”y las demás serán “alternas”
DNI
321
134
123
Domicilio
Aquí
Allí
Nombre
Pepe
Pepe
Juan
Teléfono
987
789
789
Allí
17
© Bases de Datos / O.E.I../ U.P.M.
Clave
• Al menos debe existir una clave• Tipos de claves
– Principal o primaria– Secundarias a alternas– Foráneas o externas
– Simples– Compuestas
ATENCION a las reglas de integridad
© Bases de Datos / O.E.I../ U.P.M.
Paso a Tablas (I)
n Entidades• Toda entidad se corresponde con una relación
Persona
DNINombreDomicilio
DNI Nombre Domicilio
Persona
DNI será la clave principal
18
© Bases de Datos / O.E.I../ U.P.M.
Paso a Tablas (II)n Relaciones binarias
• Relación N:M– Siempre será una tabla, con sus atributos + claves de
entidades asociadas
• Relación 1:N ó N:1– Añadir la clave de la tabla “uno” a la tabla “muchos” +
atributos de la relación (si procede)
• Relación 1:1– Si mínima es 1:1:
• Añadir la clave de una tabla cualquiera a la otra tabla +atributos de la relación (si procede)
– Si mínima es 0:1 ó 1:0:• Añadir la clave de la tabla “uno” a la tabla “cero” +
atributos de la relación (si procede)
© Bases de Datos / O.E.I../ U.P.M.
Paso a Tablas (III)
n Relaciones ternarias y n-arias• Estudiar las relaciones de dos en dos y aplicar las
reglas de relaciones binarias• Atención: se puede mejorar el diseño estudiando
redundancias
19
© Bases de Datos / O.E.I../ U.P.M.
Ejemplo
C# NombreDomicilio
Cliente
Código Precio
Producto
E# Nombre
Empleado
D# DescripciónDepartamento
D#
C# E# Código
Compra
Fecha
© Bases de Datos / O.E.I../ U.P.M.
Ejemplo (II)
EMPLEADO (E#, Nombre, Apellidos, Dirección, Telefono, FechaNac, Sexo, Casado, Sueldo, D# )
DEPARTAMENTO ( D#, NombreDep, E#
PROYECTO (P#, NombreP, D# )
PARTICIPA (E#, P#, Tiempo )