Base de Datos

Base de Datos I
Ing. Diana López A. Mgs.
dlopez@ecotec.edu.ec

AGENDA
• Reglas de Normalización
• Generalidades
• Las reglas de normalización.

Transformación Modelo ER a Relacional
Tres reglas básicas
Las tres reglas básicas para convertir un esquema en el modelo E/R al
relacional son las siguientes:
1) Todo tipo de entidad se convierte en una relación.
2) Todo tipo de relación M:M (muchos a muchos) se transforma en una
relación.
3) Para todo tipo de relación 1:M se realiza lo que se denomina propagación
de clave (regla general), o se crea una nueva relación.

Tres reglas básicas
Debido a que el modelo relacional no distingue entre entidades y relaciones,
ambos conceptos deben representarse mediante relaciones. Esto implica una
perdida de semántica con respecto al esquema E/R:
 Las relaciones M:M no se distinguen de las entidades (ambas se
transforman en tablas).
 Las 1:M se suelen representar mediante una propagación de clave,
desapareciendo incluso el nombre de la relación.

Tres reglas básicas - Ejemplo
EDITORIAL LIBRO AUTOR
EDITA ESCRIBE
1 n n n
Nombre_e
Codigo Nombre_a
LIBRO( Código, Título, Idioma, …, Editorial)
EDITORIAL( Nombre_e, Dirección, Ciudad, País)
AUTOR( Nombre_a, Nacionalidad, Institución)
ESCRIBE(Nombre_a, Código)
CLAVE AJENA

Reglas detalladas de Transformación
Transformación de Entidades
Cada tipo de entidad se convierte en una tabla.
La tabla se llamará igual que el tipo de entidad de donde proviene.
Transformación de Atributos de Entidades
Cada atributo de una entidad se transforma en una columna de la tabla a la
que ha dado lugar la entidad.
Teniendo en cuenta que existen atributos identificador principal, otros que son
identificadores alternativos (únicos) y el resto de los atributos que no son
identificadores – atributos no principales-.
Esta regla se divide en subreglas.

Atributos Identificadores
Los atributos que son identificadores principales pasan a formar la clave
primaria de la tabla.
Atributos Identificadores Alternativos
Se les denomina mediante un cláusula denomina UNIQUE.
Atributos No Identificadores
Se representan solo como columnas de la tabla correspondiente.

PROFESOR
Dirección
Télefono
Materia
Cod_Prof
Nombre
DNI
Cod_prof Nombre DNI Dirección Teléfono Materia
PROFESOR
CREATE TABLE Profesor (
Cod_Prof Código,
Nombre Nombres,
DNI DNIS, NOT NULL
Dirección Lugares,
Télefono Nos_Teléfono,
Materia Materias,
PRIMARY KEY (Cod_prof),
UNIQUE (DNI) );

Atributos Multivaluados
Puesto que el modelo relacional no permite dominios multivaluados, deberá
crearse una nueva tabla cuyos únicos atributos ( y clave primaria ) será la
concatenación de la clave primaria de la entidad original y el atributo
multivaluado.
Además, se debe crear una clave ajena referenciado a la tabla primaria.
PROFESOR
Télefono
Cod_Prof
Nombre
n
Persona ( dni, nombre, ……)
Telefonos ( dni, número )
CLAVE AJENA

Transformación de relaciones M:M
Un tipo de relación M:M se transforma en una tabla que tendrá como clave
primaria la concatenación de las claves primarias (CP) de los tipos de
entidades que asocia.
Además, cada uno de los atributos que forman la clave primaria de esta tabla
también son claves ajenas que referencian a las tablas en que se han
convertido las entidades relacionadas (claves primarias).
PROFESOR
CURSO
IMPARTE
n
n
Cod_prof
Cod_curso
Modelo Relacional
PROFESOR ( Cod_prof, ….. )
CURSO ( Cod_curso )
IMPARTE ( Cod_curso, Cod_prof )

Transformación de relaciones 1:N
Existen dos soluciones:
 Propagar la clave principal del tipo de entidad que tiene la
cardinalidad máxima 1 a la que tiene N (propagación de clave). Esta
es la regla habitual.
 Transformar la relación en una tabla como si se tratara de una
relación M:M; pero ahora la clave primaria de la tabla creada es sólo
la clave primaria de la tabla a la que le corresponde la cardinalidad n.
La opción b) se utiliza cuando:
 El número de ejemplares relacionados de la entidad que propaga su clave es
muy pequeño y, por tanto, existirían muchos valores nulos en la clave
propagada.
 Se prevé que la relación en un futuro se convertirá en un tipo M:M
 La relación tiene atributos propios y no es deseable propagarlos ( a fin de
conservar la semántica ).

PROFESOR
DEPARTAMENTO
PERTENECE
n
1
Cod_prof
Cod_dep
Modelo Relacional
PROFESOR ( Cod_prof, ….., Cod_dep )
DEPARTAMENTO (Cod_dep, … )

Transformación de relaciones 1:1
Una relación de tipo 1:1 es un caso particular de una relación 1:N, por lo que
se puede aplicar las dos opciones ya comentadas: crear una nueva tabla o
realizar propagación de clave, en este caso la propagación se puede hacer
en ambos sentidos)
Los criterios para aplicar una u otra regla y para propagar la clave se basan:
 Las cardinalidades mínimas.
 Recoger la mayor cantidad de semántica posible.
 Evitar los valores nulos o aumentar la eficiencia.

Si las entidades que se asocian poseen cardinalidades (0,1), suele ser
conveniente transformar la relación 1:1 en una tabla.
HOMBRE
MUJER
MATRIMONIO
(0,1)
(0,1)
Cod_Hombre
Cod_Mujer
Modelo Relacional
MATRIMONIO (Cod_Hombre, Cod_Mujer)
HOMBRE ( Cod_Hombre )
MUJER ( Cod_Mujer )
Clave Alternativa
UNIQUE, NOT NULL

Si las entidades que participan en la interrelación poseen cardinalidades
(0,1) y (1,1), conviene propagar la clave de la entidad con cardinalidades
(1,1) a la tabla resultante de la entidad con cardinalidad.
Modelo Relacional
PROFESOR ( Cod_prof )
DEPARTAMENTO ( Cod_dep, Cod_prof )
PROFESOR
DEPARTAMENTO
RESPONSABLE
(1,1)
(0,1)
Cod_prof
Cod_dep
Clave Ajena
NOT NULL

En el caso de que ambas entidades presenten cardinalidad (1,1), se puede
propagar la clave de cualquiera de ellas a la tabla resultante de la otra,
teniendo en cuenta en este caso los accesos más frecuentes y prioritarios a
los datos de las tablas.

Transformación de atributos de relaciones
Si la relación se transforma en una tabla, todos sus atributos pasan a ser
columnas de la tabla.
En caso de que la relación se transforme mediante propagación de clave,
sus atributos migran junto a la clave a la tabla correspondiente.
PROFESOR
CURSO
IMPARTE
1,n
1,n
Cod_prof
Cod_curso
Nro_Horas
Modelo Relacional
PROFESOR ( Cod_prof, …..)
IMPARTE ( Cod_prof, Cod_curso, Num_Hora )
CURSO ( Cod_curso, …)

Transformación de Dependencias en Identificación y en
Existencia.
La manera de transformar una relación de este tipo es utilizar el mecanismo
de propagación de clave, creando una clave ajena, con nulos no permitidos,
en la tabla de la entidad dependiente, con la característica de obligar a una
modificación y un borrado en cascada.
Además, en el caso de dependencia en identificación la clave primaria de la
tabla en la que se ha transformado la entidad débil debe estar formada por la
concatenación de las claves de las dos entidades participantes.
CURSO
EDICION
TIENE
Cod_Curso
Cod_Edición
Modelo Relacional
CURSO ( Cód_Curso, …. )
EDICION ( Cód_edicion, Cod_curso, ….)
Clave Ajena – NOT NULL – On Delete
Cascade – On Update Cascada.

Transformación de Generalización (tipos y subtipos)
Existen tres soluciones de transformación al modelo relacional:
a) Englobar todos los atributos de la entidad y sus subtipos en una sola tabla.
En general, se debe adoptar esta solución cuando los subtipos se
diferencien en muy pocos atributos y las relaciones que los asocian con el
resto de las entidades del esquema sean las mismas para todos (o casi
todos) los subtipos.
b) Crear una tabla para el supertipo y tantas tablas como subtipos haya, con
sus atributos correspondientes. Esta es la solución adecuada cuando
existen muchos atributos distintos entre los subtipos y se quieren mantener
de todas maneras los atributos comunes a todos ellos en una tabla.
c) Considerar tablas distintas para cada subtipo, que contengan, además de
los atributos propios, los atributos comunes. Se elegirá esta opción cuando
se den las mismas condiciones anteriores.

Ejemplo:
PROFESOR
DOCTOR NO DOCTOR
Año_doc
Materia_doc

Ejemplo:
Transformación
Opción a) PROFESOR (Cod_prof, nombre, ….., tipo, Año_doc, Materia_doc,..)
Opción b) PROFESOR (Cod_prof, Nombre, ….)
DOCTOR (Cod_prof, …… )
NO_DOCTOR (Cod_prof, …..)
Opción c) DOCTOR (Cod_prof, Nombre, ……, Año_doc, ….)
NO_DOCTOR ( Cod_prof, Nombre, ……)

Aunque es posible elegir cualquiera de las tres estrategias para la
transformación de un tipo y sus subtipos al modelo relacional,
 desde un punto de vista exclusivamente semántico la opción b es la mejor.
 desde el punto de vista de la eficiencia deberá tenerse en cuenta que:
 Opción a: el acceso a una fila que refleje toda la información de una
determinada entidad es mucho más rápido (no hace falta combinar varias
tablas).
 Opción b: la menos eficiente aunque es la mejor desde un punto de vista
exclusivamente semántico.
 Opción c: Con esta solución se aumenta la eficiencia ante determinadas
consultas ( las que afectan a todos los atributos, tanto comunes como propios,
de un subtipo) pero se disminuye ante otras. Esta solución es la que pierde más
semántica.

Se deberá elegir una estrategia u otra dependiendo de que sea la semántica o
la eficiencia la que prime para el usuario en un momento determinado.

Transformación de atributos derivados
No existe una representación directa. Por tanto, se deben tratar como atributos
normales, que pasarán a ser columnas de la tabla correspondiente. Además se
deberá, construir un disparador que calcule el valor del atributo derivado
cada vez que se inserten o borren las ocurrencias de los atributos que
intervienen en el calculo y añadir las restricciones correspondientes.

Ejercicios
Transforme a modelo relacional los ejercicios que fueron resueltos en
clases Modelo E/R
Ejercicio 1
Ejercicio 2
Ejercicio 3

EJERCICIO 1
Realizar el modelo entidad-relación a partir del siguiente enunciado:
“Una empresa vende productos a varios clientes. Se necesita conocer los
datos personales de los clientes (nombre, apellidos, cedula, dirección y fecha
de nacimiento). Cada producto tiene un nombre y un código, así como un
precio unitario. Un cliente puede comprar varios productos a la empresa, y
un mismo producto puede ser comprado por varios clientes.
Los productos son suministrados por diferentes proveedores. Se debe tener
en cuenta que un producto sólo puede ser suministrado por un proveedor, y
que un proveedor puede suministrar diferentes productos. De cada proveedor
se desea conocer el RUC, nombre y dirección”.

Modelo E-R a Relacional
• Cliente-Productos
Transformación de relaciones N:N
Transformar la relación en una tabla como si se tratara de una
relación M:M; pero ahora la clave primaria de la tabla creada es
sólo la clave primaria de la tabla a la que le corresponde la
cardinalidad n.
Cliente (Id-Cliente, nombre, apellido, dirección, fecha de
nacimiento)
Productos (código, nombre, precio unitario)
Compra (Id-cliente, código)

• Productos -proveedores Transformación de relaciones 1:N
Propagar la clave principal del tipo de entidad
que tiene la cardinalidad máxima 1 a la que tiene
N (propagación de clave). Esta es la regla
habitual.
Productos (código, nombre, precio unitario,
RUC)
Proveedor (RUC, nombre, dirección)

Modelo Relacional
Transformar a Modelo Relacional al Ejercicio 1
Cliente (Id-Cliente, nombre, apellido, definición, fecha de nacimiento)
Producto (código, nombre, precio unitario, RUC)
Proveedor (RUC, nombre, dirección)
Compra (Id-cliente, código)

Modelo Relacional
Id-cliente Nombre Apellido Dirección F de nacimiento
Tabla: cliente
código Nombre Precio unitario RUC
Tabla: producto
RUC Nombre Dirección
Tabla: proveedor

Modelo Relacional
Id-cliente código
Tabla: compra

EJERCICIO 2
Realizar el modelo entidad-relación a partir del siguiente enunciado
“Se desea informatizar la gestión de una empresa de transportes que reparte paquetes por toda
España. Los encargados de llevar los paquetes son los camioneros, de los que se quiere guardar el
cedula, nombre, teléfono, dirección, salario y población en la que vive.
De los paquetes transportados interesa conocer el código de paquete, descripción, destinatario y
dirección del destinatario. Un camionero distribuye muchos paquetes, y un paquete sólo puede ser
distribuido por un camionero.
De las provincias a las que llegan los paquetes interesa guardar el código de provincia y el nombre. Un
paquete sólo puede llegar a una provincia. Sin embargo, a una provincia pueden llegar varios paquetes.
De los camiones que llevan los camioneros, interesa conocer la matrícula, modelo, tipo y potencia. Un
camionero puede conducir diferentes camiones en fechas diferentes, y un camión puede ser
conducido por varios camioneros”.

Modelo ER a Relacional- Ejercicio 2

Transformación de 1:N
Existen dos soluciones:
Propagar la clave principal del tipo de entidad que tiene la cardinalidad máxima 1 a la que tiene N
(propagación de clave). Esta es la regla habitual.
Transformar la relación en una tabla como si se tratara de una relación M:M; pero ahora la clave primaria de la
tabla creada es sólo la clave primaria de la tabla a la que le corresponde la cardinalidad n.
CAMIONERO(RUC, NOMBRE, TELEFONO, DIRECCION, SALARIO,POBLACION)
PAQUETES(COD_PAQUETE, DESCRIPCION, DESTINO, DIR_DESTINATARIO, RUC)

Transformación de relaciones N:N
Transformar la relación en una tabla como si se tratara de una
relación M:M; pero ahora la clave primaria de la tabla creada es
sólo la clave primaria de la tabla a la que le corresponde la
cardinalidad n.
CAMIONERO(RUC, NOMBRE, TELEFONO, DIRECCION, SALARIO, POBLACION
CAMIONES(PLACA, MODELO, TIPO, POTENCIA)
CONDUCE(RUC, PLACA)

Propagar la clave principal del tipo de entidad que tiene la
cardinalidad máxima 1 a la que tiene N (propagación de clave).
Esta es la regla habitual.
PAQUETES(COD_PAQUETE, DESCRIPCION, DESTINO,
DIR_DESTINATARIO, APARTADO_POSTAL)
PROVINCIA(APARTADO_POSTAL, NOMBRE)

Modelo Relacional
Tablas:
Camionero (RUC, nombre, teléfono, dirección, salario, población)
Paquetes (cod_paquete, descripción, destino, dirección de destinatario,
RUC, apartado_postal)
Camiones (placa, modelo, potencia, tipo)
Provincia (apartado_postal, nombre)
Conduce (RUC, placa)

EJERCICIO 4
A partir del siguiente supuesto diseñar el modelo entidad-relación:
“Se desea diseñar una base de datos para almacenar y gestionar la información empleada por una
empresa dedicada a la venta de automóviles, teniendo en cuenta los siguientes aspectos:
• La empresa dispone de una serie de carros para su venta. Se necesita conocer la matrícula, marca y
modelo, el color y el precio de venta de cada carro.
• Los datos que interesa conocer de cada cliente son el NIF, nombre, dirección, ciudad y número de
teléfono: además, los clientes se diferencian por un código interno de la empresa que se incrementa
automáticamente cuando un cliente se da de alta en ella. Un cliente puede comprar tantos carros
como desee a la empresa. Un carro determinado solo puede ser comprado por un único cliente.
• El concesionario también se encarga de llevar a cabo las revisiones que se realizan a cada carro. Cada
revisión tiene asociado un código que se incrementa automáticamente por cada revisión que se
haga. De cada revisión se desea saber si se ha hecho cambio de filtro, si se ha hecho cambio de
aceite, si se ha hecho cambio de frenos u otros. Los carros pueden pasar varias revisiones en el
concesionario”.

CLIENTE(NIF, NOMBRE, DIRECCION, CIUDAD, TELEFONO)
AUTO(MATRICULA, MARCA, MODELO, COLOR, NIF)

AUTOS(MATRICULA, MARACA, MODELO, COLOR, NIF)
REVISION(CAMBIO_DE_FILTRO, CAMBIO_DE_ACEITE, CAMBIO_DE_FRENOS, OTROS, MATRICULA)

Modelo Relacional
• Cliente (NIF, nombre, dirección, ciudad, teléfono, código interno)
• Auto (Matricula, marca, modelo, color, precio, NIF)
• Revisión (Código, cambio de filtro, cambio de aceite, cambio de frenos, otros cambios, matricula)
NIF nombre dirección ciudad teléfono Código interno
matricula marca modelo color Precio NIF
Tabla: Cliente
Tabla: Auto
código c. de filtro c. de aceite c. de frenos Otros cambios matricula
Tabla: revisión

Tarea
A partir del siguiente enunciado diseñar el modelo entidad-relación.
“Se desea diseñar la base de datos de un Instituto. En la base de
datos se desea guardar los datos de los profesores del Instituto (DNI,
nombre, dirección y teléfono). Los profesores imparten módulos, y
cada módulo tiene un código y un nombre. Cada alumno está
matriculado en un módulo. De cada alumno se desea
guardar el nº de expediente, nombre, apellidos y fecha de
nacimiento. Los profesores pueden impartir varios módulos, pero un
módulo sólo puede ser impartido por un profesor. Cada curso tiene
un grupo de alumnos, uno de los cuales es el delegado del grupo”.
Luego convierta al Modelo Relacional

Solución
• Profesores (cedula_profesor, nombre, dirección, teléfono)
• Modulo (código, nombre, cedula_profesor)
• Alumno (N° de expediente, nombre, apellido, fecha de nacimiento,
código de modulo)
• Delegado (N° de expediente, Nombre)

Base de Datos

Recomendados

Recomendados

Más contenido relacionado

Similar a Base de Datos

Similar a Base de Datos (20)

Último

Último (20)

Base de Datos

Notas del editor