Bases de datos relacionales

Diseño Lógico
 Introducción
• Los datos se almacenan en tablas.
• El concepto de relación en el modelo
relacional es diferente del concepto de
relación en el modelo E-R.
• Informalmente, en el modelo relacional:
relación = tabla
• Dio origen a los los RDBMS (SGBD
Relacionales).
 Introducción
Modelo Modelo lógico (Relacional)
conceptual (E-R) Diagrama de base de datos

Transfor-
mación

ERROR FRECUENTE:
CONFUNDIR LOS CONCEPTOS DEL MODELO E-R CON
LOS DEL MODELO RELACIONAL.
 Ventajas
• Sencillo y maduro.
• Fácil modificación de datos y del esquema.
• Operadores con gran poder de manipulación de
los datos  álgebra y cálculo relacional
• Fundamentación teórica sólida (teoría de
conjuntos).
• Compatibilidad y estandarización.
 Ventajas
• Garantiza la independencia de los datos.
• Soportado por numerosos sistemas
comerciales que garantizan conectividad
con los lenguajes de programación más
usados (Java, C#, PHP, Visual Basic, etc.)
• Muy difundido: se consigue fácilmente
apoyo técnico.
 Desventajas
• Dificultad o imposibilidad para representar
– reglas complejas de negocio
– reglas de conocimiento (inferencia)*.
• Dificultad para manejar herencia (se trata de simular).
• Descompone un elemento de interés en varias
tablas*.
• El manejo de datos “complejos” (cf. con los atributos
grupales y multivaluados del modelo conceptual
semántico) podría llevar a diseños complejos.
 Elementos del modelo lógico
1. Tablas, Columnas, Filas y Campos (Primera Forma
Normal)
2. Definición de PK y FK
3. Conversión de Entidades del Modelo Conceptual.
1. Conversión de Relaciones:
1. 1:1

2. 1:M
3. M:M

2. Conversión de Relaciones Especiales:

• Supertipo – subtipo
• Dependencia
• Recursiva
Elementos del modelo relacional
• Relación (tabla):
– Concepto abstracto. Estructura: filas (tuplas) y
columnas (atributos).
– Se pueden definir por comprensión y por
extensión*:
• Ej.: Por comprensión: Estudiante = {x | x (carnet,
nombre, teléfono) es estudiante de la Universidad
Nacional de Colombia}

*Implica listar individualmente, los elementos de la relación.

 Elementos del modelo relacional
• Tupla:
– Cada instancia (fila o registro) de una tabla.
– Sirve para representar la instancia de una entidad del
modelo E-R.
– Cardinalidad o extensión de una relación: número de
tuplas.
Elementos del modelo relacional
• Atributo:
– Cada campo o columna de una relación.
– Grado o aridad de una relación: número de
atributos.
– El conjunto de atributos forman la cabecera de
la relación.
– Cada atributo está valuado o basado sobre un
dominio.
Elementos del modelo relacional
• Dominio:
– Colección, lista de valores.
– Un dominio es un tipo de datos.
– Pueden valuar a varios atributos.
 TIPOS DE CLAVES
• Una clave es una o más columnas de una tabla que identifica
una fila.
• Una clave única identifica una sola fila, una no única
identifica a varias filas.
• Una clave compuesta es una clave que contiene dos o más
atributos.
• Una tabla tiene una clave primaria única y puede tener
claves únicas adicionales llamadas claves candidatas.
 Claves
• Clave primaria de una relación:
– Equivale al identificador único (#, |) del modelo
E-R.

¡No confundir clave primaria (modelo relacional) e

identificador único (modelo E-R y semántico)!
 Claves
Regla de integridad de una clave primaria:
“Ningún componente de la clave primaria
acepta nulos”

¿Qué son? Algunos autores ni siquiera los

consideran como parte del modelo relacional…
 Claves
• Clave foránea (ajena o externa) Foreign
Key:
– Columna (puede ser compuesto) en una tabla
vehiculo que referencia a la clave primaria (o
alternativa) de una tabla propietario(R1 y R2 no
necesariamente diferentes).
– Especifica de forma explícita la forma en que
dos relaciones* se relacionan**.

* Relaciones en el sentido del modelo relacional. La clave foránea es

un concepto del
** Relacionan en el sentido del modelo E-R. modelo relacional
NO del modelo E-R.
FOREIGN KEY - CLAVE FORÁNEA

EMPLEADO
PK idEmpleado (int) DEPARTAMENTO
Nombre (char(30)) PK idDepartamento (int)
Dirección (char(30)) Nombre (char(30))
Teléfono (int)
FK idDepartamento (int)
 Claves
Regla de integridad referencial:
“Ningún componente de una clave foránea puede
contener valores que no están presentes en la clave
primaria a la que referencia”.
• ¿Puede una clave foránea aceptar nulos?
• ¿Cómo es el dominio de una clave foránea con
respecto al dominio de la clave primaria (o
alternativa) a la que referencia?
 Claves
• ¿Qué sucede si se pretende borrar el valor al que
referencia (“padre”) una clave foránea?
• Posibles cursos (políticas) de acción:
- Cascada.
- Restringido.
- Nulificación (no siempre es posible).
 Comparativo de términos
Relacional formal Informal Sistema de archivos
Relación Tabla Archivo
Tupla Fila Registro
Atributo Columna Campo
Instancia de una Conjunto de filas de Conjunto de registros
relación una tabla de un archivo
Cardinalidad Número de filas Número de registros
Grado o aridad Número de columnas Número de campos

Clave primaria Llave, identificador Sin equivalente

Clave foránea Llave externa o ajena, Sin equivalente
interrelación
Dominio Conjunto de valores Conjunto de valores
válidos válidos
 CONVERSIÓN DEL MODELO CONCEPTUAL MER AL
MODELO LÓGICO DB
•Cada entidad del modelo conceptual se transforma
directamente en una tabla.
•Los atributos de la entidad pasan a ser
automáticamente las columnas de la tabla..
CLIENTE CLIENTE
Entidad Tabla
PK idCliente (int)
idCliente
Atributos Columnas Nombre Nombre
Dirección
Teléfono
(char(30))
Dirección
(char(30))
Teléfono (int)
CONVERSIÓN DE RELACIONES
 RELACIONES 1:1
Si las entidades que se asocian poseen cardinalidades (0,1), entonces la relación se transforma en una
tabla, además de las dos tablas a las que se transforman cada una de las entidades:

HOMBRE MUJER
idHombre matrimonio idMujer
Nombre Nombre

HOMBRE MATRIMONIO MUJER

PK idHombre (int) FK PK idHombre (int) PK idMujer (int)
idHombre= idHombre idMujer= idMujer
Nombre (char(30)) FK PK idMujer (int) Nombre (char(30))
 RELACIONES 1:1
Si una de las entidades que participa en la relación posee cardinalidad (0,1), mientras que en la
otra es (1,1), conviene propagar la clave de la entidad con cardinalidad (1,1) a la tabla resultante
de la entidad de cardinalidades (0,1) con el fin de evitar que aparezcan valores nulos.
EMPLEADO
idEmpleado DEPARTAMENTO
Nombre idDepartamento
dirige
Dirección Nombre
Teléfono

EMPLEADO
DEPARTAMENTO
PK idEmpleado (int)
idEmpleado= idEmpleado PK idDepartamento (int)
Nombre (char(30))
Nombre (char(30))
Direccion (char(50))
FK idEmpleado(int)
Telefono (int)
 RELACIONES 1:1
En el caso de que ambas entidades presenten EQUIPO PRESIDENTE
cardinalidades (1,1), se puede propagar la clave de
cualquiera de ellas a la tabla resultante de la otra, codigo cedula
Nombre tiene Nombre
teniendo en cuenta en este caso los accesos más
frecuentes y prioritarios a los datos de las tablas. añoFundacion
Apellido

PRESIDENTE
EQUIPO
PK cedula (int)
PK Codigo (int) codigo= codigo
Nombre (char(30))
Nombre (char(30))
Apellido (char(30))
anoFundacion (int)
FK Codigo (int)
EQUIPO
PRESIDENTE
PK Codigo (int)
cedula= cedula PK cedula (int)
Nombre (char(30))
Nombre (char(30))
AnoFundacion (int)
Apellido (char(30))
FK Cedula (int)
 RELACIONES 1:M
• Las tablas derivadas de las relaciones se pueden eliminar.
• Los atributos que formaban parte de la tabla pasan a formar parte
de la tabla que representa la entidad con cardinalidad “varios”.
• Asimismo, si la relación tuviera atributos propios, también
pasarían a la tabla que representa la entidad con cardinalidad
“varios”.
 RELACIONES
EMPLEADO
1:M
idEmpleado DEPARTAMENTO
Nombre idDepartamento
trabaja
Dirección Nombre
Teléfono

EMPLEADO
PK idEmpleado (int)
DEPARTAMENTO
Nombre (char(30)) idDepartamento= idDepartamento
PK idDepartamento (int)
Direccion (char(50))
Nombre (char(30))
Telefono (int)
FK idDepartamento
(int)
 RELACIONES M:M
CLIENTE fechaCompra
idCliente PRODUCTOS
Nombre
Apellido Compra codProducto
Direccion Descripcion
Telefono

CLIENTE
COMPRA
PK idCliente (int)
PK idCompra (int) PRODUCTOS
Nombre (char(30))
FK idCliente (int) PK codProducto (int)
Apellido (char(30)) idCliente= idCliente codProducto=
Direccion(char(50) FK codProducto (int) codProducto Descripcion (char(50))
Telefono(int) fechaCompra (date)
RELACIONES TERNARIAS
fechaHora
CLIENTE
idCliente FORMAPAGO
Nombre
Paga idFormaPago
Direccion
Descripcion
Telefono

FACTURA

numFactura
montoTotal
 RELACIONES TERNARIAS
CLIENTE PAGO
PK idHombre (int) FK idFormaPago (int) FORMA_PAGO
Nombre (char(30)) FK idCliente (int) PK idFormaPago (int)
idCliente= idCliente idFormaPago=
Direccion idFormaPago Descripcion (char(50))
FK numFactura (int)
(char(50))
Telefono (int) fecha (date)
Hora (time)

numFactura= numFactura

FACTURA
PK numFactura (int)
montoTotal (numeric (20,2))
 SUPERTIPO - SUBTIPO
CLIENTE
idCliente CLIENTE
Nombre PK idCliente (int)
Direccion Nombre(char(30)
Telefono Direccion(char(50))
Ciudad
Telefono (int)

Empresa Persona
Cedula
RUC Estado EMPRESA PERSONA
Razon social civil FK, PK idCliente (int) FK, PK idCliente (int)
RUC (char(14)) Cedula (char(10))
RazonSocial(char(20)) EstadoCivil(char(10))
 RECURSIVA
Empleado Supervisa
idEmpleado
Nombre
Apellido
EMPLEADO
Dirección
Teléfono PK idEmpleado (int)
Nombre (char(30))
Apellido (char(30))
Descripcion (char(50))
Telefono (int)
FK jefe (int) idEmpleado2
idEmpleado=

idEmpleado= idEmpleado2
 DICCIONARIO DE DATOS
• Es un documento que muestra una descripción de
los elementos que componen cada tabla.
• Para cada atributo de la tabla se especifica:

Tabla Atribut Tipo de Domini Descripci

o Dato o ón
 Normalización

Cuando una tabla no está normalizada, cabe la posibilidad

que alguna celda no esté llena, que los datos se repitan,
que aparezcan dos datos o más en una celda, que algunos
datos como atributos incorrectos, que los datos no sean
valores simples,  o que la misma tabla no cuente con
claves primarias.
• Dependencia Funcional
• Primera Forma Normal
• Segunda Forma Normal
• Tercera Forma Normal
 Normalización
• El proceso de normalización de bases de datos
consiste en aplicar una serie de reglas a las tablas
obtenidas tras el paso del modelo conceptual al
modelo lógico.
• Las bases de datos relacionales se normalizan
para:
– Evitar la redundancia de los datos.
– Evitar problemas de actualización de los datos en las
tablas.
– Proteger la integridad de los datos.
 Normalización
• Según la propuesta original de Codd (1972), se somete un esquema de
relación a una serie de pruebas para "certificar” si pertenece o no a una
cierta forma normal.
• En un principio, Codd propuso tres formas normales, a las cuales llamó
primera, segunda y tercera formas normales (1FN, 2FN, 3FN).
• Posteriormente, Boyce y Codd propusieron una definición más estricta de
3FN, a la que se conoce como forma normal de Boyce‑Codd (FNBC).
• Todas estas formas normales se basan en las dependencias
funcionales entre los atributos de una tabla.
• Más adelante se propusieron una cuarta forma normal (4FN) y una quinta
(5FN), con fundamento en los conceptos de dependencias multivaluadas y
dependencias de reunión, respectivamente.
 Dependencia Funcional
• Ocurre cuando el valor de un atributo o varios
determina el valor de un segundo atributo o
varios
• AB (A determina funcionalmente a B)
• El atributo en la parte izquierda de la
dependencia funcional es llamado el
determinante
• Si conocemos el valor de A podemos conocer
el valor de B.
 Dependencia Funcional
•Por ejemplo, en una tabla
CLIENTE(Número_cliente,Nombre,Teléfono,Fecha_Nacimiento,Edad)
Existen las siguientes dependencias funcionales:
• DF: Número_cliente Nombre
• DF: Número_cliente Teléfono
• DF: Número_cliente Fecha_Nacimiento
• DF: Número_cliente Edad
• DF: Fecha_Nacimiento Edad

• Para comenzar el proceso de normalización tenemos que estudiar las

propiedades de todos los atributos de la tabla y analizar como están
relacionados entre sí, buscando las posibles dependencias funcionales que
existan.
• Otro de los pasos previos al proceso de normalización es decidir cual es la
clave primaria de la tabla.
 Primera Forma Normal
• Una tabla está en 1FN si satisface las siguientes
condiciones:
1. Todos los atributos son “atómicos”. Por ejemplo, en
el campo teléfono no tenemos varios teléfonos.
2. La tabla contiene una clave primaria única. Por
ejemplo el NIF para personas, la matrícula para
vehículos o un simple id autoincremental. Si no
tiene clave, no es 1FN.
3. La clave primaria no contiene atributos nulos. No
podemos tener filas para las que no haya clave (por
ejemplo, personas sin NIF o vehículos sin matrícula).
4. No debe existir variación en el número de
columnas. Si algunas filas tienen 8 columnas y
5. Los campos no clave deben identificarse por la clave. Es
decir, que los campos no clave dependen
funcionalmente de la clave. Esto es prácticamente lo
mismo que decir que existe clave primaria.
6. Debe Existir una independencia del orden tanto de las
filas como de las columnas, es decir, si los datos
cambian de orden no deben cambiar sus significados.
Por ejemplo, si en la tercera fila tenemos el tercer
mejor expediente y en la quinta fila el quinto, no
estamos en 1FN.
La primera forma normal se definió para prohibir los
atributos multivaluados, compuestos y sus
combinaciones.
• Cuando una tabla no está en primera forma
normal, se divide en otras tablas, repartiendo sus
atributos entre las resultantes. Normalmente la
idea es eliminar el atributo que viola la 1FN de la
relación original y colocarlo en una relación
aparte junto con la clave primaria de la relación
de partida.
 Segunda Forma
Normal
• Un esquema está en 2FN si:
– Está en 1FN.
– Y si todos los atributos no clave dependen
funcionalmente de la clave completa y no
sólo de una parte de esta.
• Este paso sólo se aplica a relaciones que
tienen claves compuestas, es decir, que están
formadas por mas de un atributo.
 Segunda Forma Normal
El atributo restante, Lugar actual de
trabajo, es dependiente solo en parte de la
clave candidata, llamada Empleado. Por lo
tanto la tabla no está en 2NF.

• Si una tabla no está en 2FN, se

le puede normalizar a varias
tablas en 2FN en las que los
atributos que dependen de
una parte de la clave formarán
una nueva tabla que tendrá
esa parte de la clave como
clave primaria.
 Tercera Forma Normal
• Una tabla está en 3NF si y solo si las dos
condiciones siguientes se mantienen:
1. La tabla está en la segunda forma
normal(2FN)
2. Ningún atributo no-­‐primario de la tabla es
dependiente transitivamente de una clave
candidata
• Es decir, una relación está en tercera forma
normal si todos los atributos de la relación
dependen funcionalmente sólo de la clave, y no
de ningún otro atributo
 Tercera Forma Normal
Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:

• La única clave candidata es {Torneo, Año}.

• La violación de la 3NF ocurre porque el atributo no primario Fecha de
nacimiento del ganador es dependiente transitivamente de {Torneo, Año} vía el
atributo no primario Ganador.
• El hecho de que la Fecha de nacimiento del ganador es funcionalmente
dependiente en el Ganador hace la tabla vulnerable a inconsistencias lógicas, pues
no hay nada que impida a la misma persona ser mostrada con diferentes fechas de
nacimiento en diversos registros.
• Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en
dos:
Tercera Forma Normal
 Tercera Forma Normal
idEmpleado Puesto Salario
Puesto Salario 100 Secretaria 3100
150 Gerente 3200
IdEmpleado Puesto Salario
200 Secretaria 3100
250 Subgerente 3200
300 Secretaria 3100

Relación que elimina la dependencia transitiva:

• La mayoría de
idEmpleado Puesto las tablas
Puesto Salario 3NF están
100 Secretaria Secretaria 3100 libres de
150 Gerente Gerente 3200 anomalías de
200 Secretaria Subgerente 3200
250 Subgerente
actualización,
300 Secretaria
inserción, y
borrado.