Diseño de Bases de Datos Relacionales

• Modelo de Datos Entidad-Relación

– Técnica Top-Down – De arriba hacia abajo
– Desarrollada por Chen en el 76
• Se ha extendido desde entonces.
• Algunos libros usan la notación de Chen
• Es un modelo conceptual que realiza análisis de los datos en
abstracto.
• Es fácil de usar, es gráfico y describe los principales objetos
de datos sin mucho detalle (Para más tarde)
• El modelo de Datos Entidad Relación más la normalización
crea el diseño de la Base de Datos
 Diseño de Bases de Datos Relacionales

• Definiciones:
– ¿Qué es una Entidad?
• Una “cosa” de interés para el sistema
• Un objeto que existe en el mundo real, con ciertas
propiedades y distinguible de otros objetos
• Un grupo de objetos de datos lógicamente
asociados, identificados por una única clave:
Grupo de Datos
– Los objetos de datos se llaman atributos
– Debe ser un nombre en singular, por ejemplo CLIENTE
 Diseño de Bases de Datos Relacionales

• Propósito del modelo Entidad-Relación:

– Crear un modelo de las entidades
subyacentes y estables en un sistema
• El modelo Entidad-Relación:
– Representa los datos en un entorno de
aplicación
– Registra
• Entidades
• Atributos de Entidades
• Relaciones entre las Entidades
 Diseño de Bases de Datos Relacionales

• Ejercicio: ¿Qué atributos se usarían para

describir las entidades GRADO y
DEPARTAMENTO?
 Diseño de Bases de Datos Relacionales

• Las Entidades se representan en este modelo

como una caja rectangular, el tipo de Entidad se
escribe dentro de la caja
• Claves: Deben ser capaces de identificar
unívocamente cada ocurrencia de una Entidad.
Para cada Entidad deberemos escoger uno o
más objetos para que sean un identificador
único para esa Entidad, como ejemplo
podríamos poner Ncuenta para poder encontrar
luego cada ocurrencia de la Entidad tipo
CLIENTE
 Diseño de Bases de Datos Relacionales

• Relaciones:
– El modelo gestiona las Relaciones entre las
Entidades
• Una asociación entre dos Entidades dentro del
sistema
• Se describe mediante verbos. Ejemplos:
– ‘PERSONA’ ‘TRABAJA’ en ‘DEPARTAMENTO’
– ‘PROFESOR’ ‘ENSEÑA’ en ‘AULA(S)’
– ‘ESTUDIANTE’ ‘POSEE’ ‘COCHE’
 Diseño de Bases de Datos Relacionales

• Representación de las relaciones

– La notación utilizada para representar estos
enlaces es una línea conectando las dos
Entidades.
– Hay unos tres tipos de relaciones:
• Relación uno a uno [1:1] Es rara
• Relación uno a varios [1:m]
• Relación varios a varios [m:n]
 Diseño de Bases de Datos Relacionales

• Relación uno a uno:

– Cada instancia de una Entidad E1 puede ser
asociada con sólo una de las instancias de la
Entidad E2 y se cumple también a la inversa
– Ejemplo:
• Un director dirige como mucho un departamento.
Un departamento es dirigido como mucho por un
director
 Diseño de Bases de Datos Relacionales

• Relación uno a varios:

– Cada instancia de una Entidad E1 puede ser
asociada con Cero o más instancias de la
Entidad E2 pero cada instancia de la Entidad
E2 sólo puede estar relacionada como mucho
con una de las instancias de E1.
– Ejemplo: Un Departamento emplea mucha
gente. Una persona es empleada como
mucho de un departamento
 Diseño de Bases de Datos Relacionales

• Relación Varios a Varios

– Cada instancia de una Entidad E1 puede ser
asociada con Cero o más instancias de la
Entidad E2 y cada instancia de la entidad E2
puede ser asociada con Cero o más
instancias de la Entidad E1
– Ejemplo: A un paciente se le pueden
prescribir varios medicamentos y un mismo
medicamento le puede ser prescrito a varios
pacientes
 Diseño de Bases de Datos Relacionales

• Las relaciones Varios a Varios se descomponen siempre en

dos relaciones Uno a Varios.
• En nuestro ejemplo:
– ‘Receta’ es una entidad en sí misma. Tiene atributos tales
como la fecha, firma del médico, nombre del medicamento,
cantidad, etc. Esta entidad se llama entidad de enlace.
– Dado que ‘Receta’ es una entidad, podemos hacer
relaciones entre ‘Paciente’ y ‘Receta’ y entre
‘Medicamento’ y ‘Receta’
– Así, una receta sólo puede ser para un paciente, pero
cada paciente puede tener muchas recetas (1:m)
– Las reglas del hospital estipulan que sólo puede haber una
receta por medicamento, obviamente un mismo
medicamento puede aparecer en muchas recetas
 Diseño de Bases de Datos Relacionales

• Ejercicio
– Una Universidad mantiene información sobre
los módulos que lleva un estudiante. Un curso
consiste en una serie de módulo. Cada
módulo lo lleva un profesor que pertenece a
una escuela. Un módulo sólo está asociado
con un curso. Una escuela emplea un número
de profesores e imparte una serie de cursos.
Un estudiante tiene varios módulos. Un
módulo puede ser estudiado por varios
estudiantes.
 Diseño de Bases de Datos Relacionales

• Normalización
– Objetivos:
• Tener los datos completamente definidos y en
detalle
• Identificar las interdependencias entre los datos
• Resolver ambigüedades
• Lograr registros óptimos
• Eliminar la duplicación de datos
• Lograr que los datos puedan ser mantenidos y/o
extendidos fácilmente
 Diseño de Bases de Datos Relacionales

• Queremos que nuestro análisis nos lleve

hasta la tercera forma normal:
• “Crea un conjunto no ambiguo de
relaciones (En el sentido de conjunto)
(Grupos de datos que toman parte en una
relación entre conjuntos) con todos los
elementos de datos y las relaciones entre
ellos mostrados claramente y asegura que
no haya elementos de datos que no se
tengan en cuenta”
 Diseño de Bases de Datos Relacionales

• Conceptos
– Relación = Tabla
– Fila = Tupla
– Columna = Dominio
 Diseño de Bases de Datos Relacionales

• Conceptos
– Una tabla debe, para cumplir el modelo
relacional
• No tener dos filas iguales. (Clave primaria)
• No tener en consideración el orden de las filas y
las columnas.
• Cada columna debe tener un nombre único
• La entidad equivadrá a una tabla
• La fila será una ocurrencia de la Entidad
• La columna corresponderá a un atributo de la
Entidad
 Diseño de Bases de Datos Relacionales

• Conceptos:
– Clave Ajena: La columna aparece en una
tabla y es clave primaria en otra tabla. Como
ejemplo, en la siguiente imagen,
Código_Artículo es clave primaria en
Artículos y clave ajena en Pedidos
 Diseño de Bases de Datos Relacionales

• Las tablas no normalizadas contienen:

– Grupos de campos repetidos
– Ambigüedad y redundancia
– No hay clave identificadas
• La normalización trata de conseguir:
– Quitar las ambigüedades semánticas
– Identificar las dependencias entre los datos
– Crear un conjunto de tablas cada una con una clave
única y con datos sólo dependientes de esa clave.
 Diseño de Bases de Datos Relacionales

• Pasos (proceso)
– Convertir los datos procedentes de cada
fuente a una forma no normalizada
– Convertir los datos de forma no normalizada
a Primera Forma Normal
– Convertir los datos de Primera Forma Normal
a Segunda Forma Normal
– Convertir los datos de Segunda Forma
Normal a Tercera Forma Normal
 Diseño de Bases de Datos Relacionales

• Determinar los datos: Primera Forma Normal:

– Determinar todos los atributos: Campos de datos
– Escoger una clave para la tabla no normalizada
• Clave debe ser única
• La clave no debe repetirse en una misma fila
• Debe escogerse un dominio pequeño
• Escoger claves numéricas o alfanuméricas (No
escoger claves alfabéticas
 Diseño de Bases de Datos Relacionales

• En nuestro ejemplo anterior, la clave

primaria de Artículos es Código_Artículo
• La idea es que un mismo grupo de datos
no se pueda repetir, por tanto para llegar a
primera forma normal debemos escoger
una clave primaria que sea siempre
diferente en cada registro para cada tabla
 Diseño de Bases de Datos Relacionales

• Segunda Forma Normal

– Quitar de la tabla aquellos atributos que sólo
dependan de parte de la clave, haciendo que
todos los atributos de cada tabla dependan
de la clave completa
 Diseño de Bases de Datos Relacionales

• Tercera Forma Normal

– Quitar las dependencias entre los datos. Es
decir, eliminar las dependencias funcionales
transitivas que pudiese haber.
– También, debe observarse si hay
dependencia funcionales entre los atributos
de la clave si ésta es compuesta.
 Diseño de Bases de Datos Relacionales

• Test para comprobar si una tabla está en

tercera forma normal:
– Dado un valor para la(s) clave(s) de una tabla, ¿Hay
un solo valor posible para cada atributo de datos
asociado? Si la respuesta es no, la tabla NO está en
tercera forma normal
• Detecta errores al pasar de primera a segunda forma normal
– ¿Cada atributo de datos depende directamente de la
clave? Si la respuesta es no, la tabla NO está en
tercera forma normal.
• Comprueba las dependencias funcionales transitivas
 Diseño de Bases de Datos Relacionales

• Resumen de diseño de Bases de Datos

Relacionales
– Empezar con la forma no normalizada
– Quitar los grupos que se repitan para la primera forma
normal
– Quitar las dependencias de sólo parte de la clave para
la segunda forma normal
– Quitar las dependencias entre los datos para la
tercera forma normal
– Aplicar los tests de tercera forma normal
– Optimizar mezclando relaciones que tengan la misma
clave
– Volver a aplicar los tests de Tercera Forma Normal