Contenido: Unidad de Trabajo 4: Diseño en El Modelo Relacional

Unidad de Trabajo 4: DISEÑO EN EL MODELO RELACIONAL
UNIDAD DE TRABAJO 4:
DISEÑO EN EL MODELO RELACIONAL
Contenido
1. El problema del diseño de una base de datos relacional. ................................................... 2
2. Dependencias funcionales .................................................................................................... 5
2.1. Tipos de dependencias funcionales ............................................................................... 5
2.2. Axiomas que permiten obtener las dependencias ....................................................... 7
3. Primera, segunda y tercera formas normales ...................................................................... 9
3.1. Primera forma normal (1FN).......................................................................................... 9
3.1.1. Solución 1: duplicar los registros con valores repetidos ....................................... 9
3.1.2. Solución 2: separar el atributo que viola 1FN en una tabla ................................ 10
3.2. Segunda forma normal (2FN) ...................................................................................... 11
3.3. Tercera forma normal (3FN) ........................................................................................ 12
4. Forma normal de Boyce-Codd ............................................................................................ 15
5. Cuarta forma normal ........................................................................................................... 16
6. Quinta forma normal .......................................................................................................... 18
GESTIÓN DE BASES DE DATOS 1

1. El problema del diseño de una base de datos relacional.

Una base de datos relacional es la representación de un determinado universo del discurso
según las reglas del modelo relacional (¡Error! No se encuentra el origen de la referencia.). El
diseño de una base de datos relacional o, en general, de una base de datos, consiste en
encontrar esa representación, o esquema, del universo del discurso.
Ilustración 1: Modelo Relacional
El diseñador puede obtener el esquema relacional directamente de la observación del

universo del discurso, representando el conjunto de objetos y reglas percibidos mediante un
conjunto de esquemas de relación y restricciones de integridad.
Un método de diseño alternativo al anterior consiste en obtener, primero, un esquema

conceptual utilizando un modelo adecuado, por ejemplo, el modelo Entidad-Relación, y
transformándolo, luego, en un esquema relacional por aplicación de unas determinadas
reglas de transformación.
Al utilizar uno u otro método, el diseñador puede cometer fallos en la percepción del universo
del discurso o en el paso del esquema conceptual al esquema relacional. Estos fallos van a dar
lugar a una falta de fidelidad del esquema con respecto a la realidad que trata de representar
y, como consecuencia, surgirán ciertos problemas en la base de datos.
En la Tabla 1: aparece la relación FACTURAS1 que podría pertenecer a cierto esquema

relacional. Esta relación fue diseñada para contener información relativa a las facturas y
clientes de una empresa, y aunque aparentemente es válida para realizar esa función,
presenta algunos problemas que hacen que su diseño no sea el más adecuado.
FACTURAS1
NUM_FACTURA LÍNEA REFERENCIA CANTIDAD CODIGO_CLIENTE FECHA CIF NOMBRE
008976 1 786543 12 654321 21-9-17 11223344B LUIS SUAREZ
008976 2 564322 48 654321 21-9-17 11223344B LUIS SUAREZ
008985 1 456789 100 123456 23-9-17 1234567J JUAN PEREZ
008985 2 564322 36 123456 23-9-17 1234567J JUAN PEREZ
008985 3 556677 50 123456 23-9-17 1234567J JUAN PEREZ

Tabla 1:Ejemplo de diseño con problemas

Concretamente, en FACTURAS1 se observa:

• Gran cantidad de redundancia: por cada línea de factura de un mismo cliente se repite
NOMBRE, CODIGO_CLIENTE y CIF, y por cada línea de una factura se repite su FECHA.
Como sabemos, las redundancias en una base de datos deben ser reducidas al mínimo y
estar siempre controladas por el SGBD.
• Posibilidad de aparición de anomalías de modificación, como consecuencia de la
redundancia. Si al modificar alguno de los datos redundantes la modificación no se realiza
en todas las tuplas donde se repite dicho dato, surgen incoherencias. Por ejemplo, si la
fecha de la factura 008976 se cambia al valor 22-9-17 y, por error, sólo se modifica una de
las dos tuplas correspondientes a dicha factura, la base de datos queda en un estado
inconsistente.
• Anomalías de inserción: no es posible registrar información de clientes que no tengan
facturas, ya que NUM_FACTURA y LINEA constituyen la clave primaria de la relación y, por
tanto, no pueden quedar a NULL.
• Anomalías de borrado: al eliminar una factura de un cliente que no tenga más facturas
registradas, se pierden también los datos del cliente.
Un diseño más cuidadoso podría habernos llevado a distinguir la información de

FACTURAS1 en tres relaciones (Tabla 2): una relación para almacenar los datos de
clientes, otra para la información de facturas y la tercera para los datos de cada línea de
las facturas. Tendríamos, así, el esquema, ya manejado en la unidad de trabajo anterior,
formado por las relaciones CLIENTES, FACTURAS y LINEAS FACTURAS, en el que la única
redundancia existente es controlada por el sistema, ya que corresponde a claves ajenas
y no hay posibilidad de que surjan anomalías de actualización.
Tabla 2: Diseño correcto
La teoría de la normalización permite analizar un esquema detectando en él posibles

problemas y facilitando su transformación en otro carente de ellos. Dicha teoría
establece las condiciones que deben cumplir las relaciones (en concreto, sus cabeceras)

para que no presenten los problemas del ejemplo anterior. Estas condiciones consisten
en ciertas restricciones definidas sobre los atributos de una relación denominadas
dependencias.
Se dice que un esquema de relación está en una determinada forma normal si satisface
un conjunto determinado de restricciones. Existen distintas formas normales. En la
Ilustración 2 se han representado las más características. El conjunto de restricciones que
definen una forma normal es, a su vez, un subconjunto de las restricciones que
caracterizan otras formas normales. Así, la quinta forma normal (5FN) incluye a la 4FN,
y ésta a la de Boyce/Codd que, a su vez, incluye a la 3FN y así sucesivamente.
Quinta forma normal (5FN)
Cuarta forma normal (4FN)
Forma normal de Boyce/Codd (FNBC)
Tercera forma normal (3FN)
Segunda forma normal (2FN)
Primera forma normal (1 FN)
Ilustración 2: Formas normales.
Como veremos más adelante, cuanto mayor sea el grado de la forma normal en que se
encuentra una relación, menos problemas presentará. Una relación puede ser
descompuesta en otras equivalentes que se encuentren en formas normales superiores.
En este tema intentaremos que nuestras relaciones cumplan, al menos, las tres primeras
formas normales
A lo largo de esta unidad de trabajo, cuando hablamos de diseño de una base de datos
nos referimos siempre al diseño lógico, olvidando su diseño físico. Es dec ir, aquí no nos
vamos a ocupar del diseño de las estructuras del nivel interno de la base de datos que
den lugar a un rendimiento óptimo del sistema.

2. Dependencias funcionales
La teoría de la normalización también se conoce como teoría de las dependencias por
basarse en ellas.
Las dependencias son propiedades que poseen los datos del universo del discurso y que,
por tanto, deben ser verificadas por cualquier extensión del esquema de relación al que
se asocien. Las dependencias representan importantes interrelaciones existentes entre
los atributos del mundo real, por lo que deben ser incluidas en los esquemas de relación.
Por ejemplo, atributos como DNI o nº de expediente de un alumno, tienen una fuerte
relación con atributos como el nombre, fecha de nacimiento, etc. Es decir, si sabemos
el DNI puedo averiguar el nombre de la persona que tiene ese DNI. E igual pasa con
matrícula de un vehículo, si lo conozco, puedo averiguar la marca o modelo del vehículo.
Existen varios tipos de dependencias, aunque ahora sólo vamos a tratar de las dependencias
funcionales, que son las más extendidas y constituyen la base de las tres primeras formas
normales.
Dado un esquema de relación R y los subconjuntos de sus atributos X e Y, se dice que Y

depende funcionalmente de X o que X determina o implica a Y, denotado X → Y, si, y sólo si,
cada valor de X tiene asociado, en todo momento, un único valor de Y.
X e Y son denominados descriptores.
X se conoce como determinante o implicante, e Y como implicado.
Por ejemplo, si tengo una relación como la siguiente:

Clientes (DNI, Nombre, Dirección, Teléfono, Fecha_nacimiento)
Se cumplirían las siguientes dependencias funcionales:
DNI → NOMBRE
DNI → DIRECCIÓN
DNI → TELÉFONO
DNI → FECHA_NACIMIENTO
En el universo del discurso correspondiente al ejemplo de la Tabla 1: existen, entre otras, las
siguientes dependencias funcionales:
NUM_FACTURA → FECHA
CODIGO_CLIENTE → NOMBRE
CIF → NOMBRE
NUM_FACTURA, LINEA → REFERENCIA
2.1. Tipos de dependencias funcionales
Se dice que el descriptor Y tiene dependencia funcional completa del descriptor compuesto
X (es decir, X tiene más de un atributo), si depende funcionalmente de X, pero no depende de
ninguno de sus subconjuntos.

La dependencia funcional NUM_FACTURA, LINEA → REFERENCIA es completa ya que LINEA

no es implicante de REFERENCIA, puesto que en la misma línea de diferentes facturas puede
haber distintos artículos, y NUM_FACTURA tampoco determina a REFERENCIA, pues en las
distintas líneas de la misma factura hay distintos artículos.
Una dependencia funcional es trivial cuando el implicado es un subconjunto del implicante.
Las dependencias funcionales NUM_FACTURA, LINEA → LINEA o CIF → CIF son triviales.
Se denomina dependencia funcional elemental a una dependencia funcional no trivial en la

que el implicado es un sólo atributo.
Las siguientes dependencias funcionales son elementales:
CODIGO_CLIENTE → CIF
Se dice que los descriptores X e Y son equivalentes si se verifica que X→Y e Y→X, pudiéndose
representar como X ↔ Y.
Los atributos CIF y CODIGO_CLIENTE son equivalentes ya que en el esquema de la Tabla 1: se

verifican las dos dependencias funcionales siguientes:
CIF → CODIGO_CLIENTE
Dados los descriptores X, Y, Z de la relación R, existe dependencia transitiva de Z respecto a

X a través de Y, si se cumple que X → Y, Y → Z y X e Y no son equivalentes.
Si, además, Z e Y tampoco son equivalentes, es decir, no se cumple que Z→Y, la dependencia
transitiva es estricta.
Si en la relación FACTURAS1 hubiésemos incluido el atributo PRECIO para representar el

precio unitario del artículo de cada línea de factura, se verificaría la dependencia funcional:
NUM_ FACTURA, LINEA → PRECIO
Esta dependencia es transitiva ya que también se cumple que:

REFERENCIA → PRECIO
y no es cierta la dependencia:
REFERENCIA → NUM_FACTURA, LINEA

A partir de un conjunto de dependencias funcionales es posible obtener otras que no estaban

incluidas en dicho conjunto. Así, dadas las dependencias:
CIF → CODIGO_CLIENTE
podemos deducir la existencia de CIF → NOMBRE, ya que, como vimos anteriormente, las dos
primeras dependencias implican que los atributos CIF y CODIGO_CLIENTE son equivalentes.
2.2. Axiomas que permiten obtener las dependencias
En 1974, W.W. Armstrong, en el artículo en que se formaliza por primera vez la teoría de las
dependencias funcionales, presenta un conjunto de axiomas que permiten obtener las
dependencias funcionales asociadas a un esquema de relación a partir de un subconjunto
conocido de ellas.
Una de las formas de expresar los tres axiomas básicos de Armstrong es la siguiente:
Sean X, Y, Z, W descriptores o atributos de una relación R.
1. Reflexividad.
Si Y es un subconjunto de X, entonces X → Y. Por ejemplo:
NUM_FACT, LÍNEA → NUM_FACT
2. Aumentatividad.
Si X → Y y Z es un subconjunto de W, entonces XW → YZ.
3. Transitividad.
Si X → Y e Y → Z, entonces X → Z. Por ejemplo:
NUM_FACT, LINEA → NUM_FACT
→ NUM_FACT, LÍNEA → COD_CLIENTE
NUM_FACT → COD_CLIENTE
En la notación anterior, XW representa X U W, e YZ representa Y U Z, es decir, la reunión de

los subconjuntos de atributos representados por X y W, en un caso, e Y y Z, en el otro.
De estos tres axiomas se pueden derivar otros como los siguientes:
4. Proyectividad o descomposición.
Si X → Y, entonces X → Y’, si Y’ es un subconjunto estricto de Y.
5. Aditividad o unión.
Si X → Y y X → Z, entonces X → YZ. Por ejemplo:
NUM_FACT → COD_CLIENTE
→ NUM_FACT → COD_CLIENTE, FECHA
NUM_FACT → FECHA

6. Pseudotransitividad.
Si X → Y e YW → Z, entonces XW → Z.
Así, por ejemplo, tomemos el conjunto de dependencias funcionales existentes en el universo

del discurso representado por la relación FACTURAS1:
NUM_FACTURA, LINEA→CANTIDAD
NUM_FACTURA→CODIGO_CLIENTE
COD_CLIENTE→NOMBRE
NUM_FACTURA→FECHA
COD_CLIENTE→CIF
NUM_FACTURA, LINEA→REFERENCIA
CIF→COD_CLIENTE
Se le pueden aplicar los axiomas para derivar de él todas las dependencias funcionales que se
verifican en cualquier extensión de la relación.
Por ejemplo, aplicando el axioma de reflexividad se obtiene:
NUM_FACTURA, LINEA → NUM_FACTURA
que es una dependencia trivial y carece de interés, pero aplicando el axioma de transitividad
a:
NUM_FACTURA, LINEA→NUM_FACTURA y NUM_FACTURA→COD_CLIENTE
llegamos a:
NUM_FACTURA, LINEA → COD_CLIENTE
Y aplicando el mismo axioma a:

NUM_FACTURA, LINEA→COD_CLIENTE y COD_CLIENTE→NOMBRE
se obtiene:
NUM_FACTURA, LINEA → NOMBRE
Ahora, el conjunto de dependencias asociado a FACTURAS1 incluye también las dependencias

NUM_FACTURA, LINEA→COD_CLIENTE y NUM_FACTURA, LINEA→NOMBRE. De forma
análoga se obtendrían el resto de dependencias que permiten demostrar que todos los
atributos de FACTURAS1 dependen del subconjunto {NUM_FACTURA, LINEA} y que, por
tanto, dicho subconjunto es una clave candidata de la relación.
Se dice que los axiomas de Armstrong constituyen un conjunto correcto y completo de reglas
de inferencia para un conjunto de dependencias funcionales. El término correcto se aplica en
el sentido de que toda dependencia derivada aplicando estos axiomas es una dependencia
funcional asociada al correspondiente esquema de relación. El conjunto de axiomas es
completo porque permite obtener todas las dependencias funcionales del esquema de
relación que se esté considerando.
Los axiomas de Armstrong son importantes en el diseño relacional, entre otras razones,
porque constituyen la base de los algoritmos que permiten hallar las claves candidatas de una
relación; o determinar la equivalencia entre conjuntos de dependencias, cuestión muy
importante en el proceso de normalización de un esquema.

3. Primera, segunda y tercera formas normales
3.1. Primera forma normal (1FN)
La primera forma normal, al igual que la segunda y la tercera, fue introducida por Codd.
Se dice que una relación está en primera forma normal (1FN) si, y sólo si, todos los dominios
subyacentes contienen sólo valores atómicos.
Como sabemos, la condición de que todos los atributos de una relación tengan valores
atómicos es una de las restricciones inherentes del modelo relacional, por lo que podemos
afirmar que toda relación, por el hecho de serlo, está en primera forma normal. De acuerdo
con esto, algunos autores consideran que toda relación está normalizada, y utilizan las
palabras normalización adicional cuando hablan del proceso de transformación de una
relación en otras que se encuentren en formas normales más avanzadas.
Por ejemplo, tenemos información de una empresa donde se indican los puestos de trabajo
de los diferentes empleados y las condiciones salariales están determinadas por el puesto
(¡Error! No se encuentra el origen de la referencia.). Se ha creado el siguiente esquema
relacional
DATOS_EMPLEADOS (nss, nombre, puesto, salario, emails)
DATOS_EMPLEADOS
NSS NOMBRE PUESTO SALARIO EMAIL
administracion@ecn.es;
111 JUAN PÉREZ JEFE DE ÁREA 3000
jefe2@ecn.es
222 JOSÉ SÁNCHEZ ADMINISTRATIVO 1500 administracion@ecn.es
administracion@ecn.es;
333 ANA DÍAZ ADMINISTRATIVO 1500
adiaz@ecn.es
Tabla 3: Ejemplo 1FN
Una tabla está en 1FN si sus atributos contienen valores atómicos. En el ejemplo, podemos
ver que el atributo emails puede contener más de un valor, por lo que viola 1FN.
En general, tenemos una relación R con clave primaria K. Si un atributo M viola la condición
de 1FN, tenemos dos opciones.
3.1.1. Solución 1: duplicar los registros con valores repetidos
En general, esta solución pasa por sustituir R por una nueva relación modificada R', en la cual
el atributo M que violaba 1FN se elimina y se incluye un nuevo atributo M' que solo puede
contener valores simples. Es decir, para una tupla con n valores duplicados en M, en la nueva
relación habrá n tuplas, que sólo varían en que cada una de ellas guarda uno de los valores
que había en M.

La clave primaria de R' es (K, M'), dado que podrá haber valores de K repetidos, para los
valores multivaluados en M.
Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla
DATOS_EMPLEADOS_SOLUCION1 con clave primaria (nss, email):
DATOS_EMPLEADOS_SOLUCION1
NSS NOMBRE PUESTO SALARIO EMAIL
111 JUAN PÉREZ JEFE DE ÁREA 3000 administracion@ecn.es
111 JUAN PÉREZ JEFE DE ÁREA 3000 jefe2@ecn.es
222 JOSÉ SÁNCHEZ ADMINISTRATIVO 1500 administracion@ecn.es
333 ANA DÍAZ ADMINISTRATIVO 1500 administracion@ecn.es
333 ANA DÍAZ ADMINISTRATIVO 1500 adiaz@ecn.es

Tabla 4: Solución 1-1FN
3.1.2. Solución 2: separar el atributo que viola 1FN en una tabla
En general, esta solución pasa por sustituir R por una nueva relación modificada R' que no
contiene el atributo M. Se crea una nueva relación N(K, M'), es decir, una relación con una
clave ajena K referenciando R', junto al atributo M', que es la variante mono-valuada del
atributo M. La nueva relación N tiene como clave (K, M').
Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla

DATOS_EMPLEADOS_SOLUCION2 con clave primaria nss:
DATOS_EMPLEADOS_SOLUCION2
NSS NOMBRE PUESTO SALARIO
111 JUAN PÉREZ JEFE DE ÁREA 3000
222 JOSÉ SÁNCHEZ ADMINISTRATIVO 1500
333 ANA DÍAZ ADMINISTRATIVO 1500

Tabla 5: Solución 2-1FN Empleados
Y además tendríamos una nueva tabla EMAILS con clave primaria (nss, email). En este caso
nss es también una clave ajena que apunta a DATOS_EMPLEADOS_SOLUCION2:
EMAILS
NSS EMAIL
111 administracion@ecn.es
111 jefe2@ecn.es
333 adiaz@ecn.es
Tabla 6: Solución 2-1FN Emails

3.2. Segunda forma normal (2FN)
Una relación está en segunda forma normal (2FN) si, y sólo si, está en primera forma normal
y todos los atributos tienen dependencia funcional completa respecto de cada una de las
claves.
Obsérvese que una relación cuyas claves candidatas están constituidas por atributos únicos
está siempre en 2FN, puesto que una dependencia funcional en que el implicante (X) es un
sólo atributo siempre es completa.
La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más
atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo),
entonces también está en 2FN.
Siguiendo con el ejemplo de los puntos anteriores tendríamos que comprobar si las tablas
obtenidas cumplen la 2FN. En el caso de la solución-1 (Tabla 5) tenemos que examinar las
dependencias funcionales de los atributos no clave con respecto las claves. Las dependencias
funcionales que tenemos son las siguientes:
NSS → NOMBRE
NSS → SALARIO
NSS → PUESTO
Como la clave es (nss, email), las dependencias de nombre, salario y puesto son incompletas
respecto a la clave, por lo que la relación no está en 2FN.
Para solucionar este problema, tenemos que crear dos nuevas relaciones (Tabla 7). Una
relación con los atributos con dependencia incompleta y la parte de la clave primaria de la
que dependen, que será la clave primaria de la nueva relación. Y la otra relación con el resto
de los atributos y la clave primaria compuesta.
EMPLEADOS_2FN EMAILS
NSS NOMBRE PUESTO SALARIO NSS EMAIL
111 JUAN PÉREZ JEFE DE ÁREA 3000 111 administracion@ecn.es
222 JOSÉ SÁNCHEZ ADMINISTRATIVO 1500 111 jefe2@ecn.es
333 ANA DÍAZ ADMINISTRATIVO 1500 222 administracion@ecn.es
Clave primaria: nss
333 adiaz@ecn.es
Clave primaria: nss y email

Clave ajena nss
Tabla 7: Solución 2FN
La relación FACTURAS1 está en 1FN pero no en 2FN, ya que los atributos CODIGO_CLIENTE,
FECHA, CIF y NOMBRE, todos ellos atributos no clave, no tienen dependencia funcional
completa de la única clave existente formada por la concatenación de NUM_FACTURA y
LÍNEA. Todos estos atributos tienen dependencia funcional completa de NUM_FACTURA,
siendo trivial la dependencia funcional de la clave.

NUM_FACTURA → CODIGO_CLIENTE
NUM_FACTURA → FECHA
NUM_FACTURA → CIF
NUM_FACTURA → NOMBRE
Un esquema de relación que se encuentre en 1FN siempre puede ser sustituido por
proyecciones adecuadas que se encuentren en 2FN.
FACTURAS2
NUM_FACTURA CODIGO CLIENTE FECHA CIF NOMBRE
008976 654321 21-9-97 11223344B LUIS SUAREZ
008985 123456 23-9-97 1234567J JUAN PEREZ
LINEAS_FACTURAS
NUM_FACTURA LÍNEA REFERENCIA CANTIDAD
008976 1 786543 12
008976 2 564322 48
008985 1 456789 100
008985 2 564322 36
008985 3 556677 50
Tabla 8: Proyecciones en 2FN de FACTURAS1
En la Tabla 8 aparecen las relaciones FACTURAS2 y LINEAS_FACTURAS que están en 2FN. La

clave primaria en la tabla FACTURAS2 es NUM_FACTURA. En la tabla LINEAS_FACTURAS la
clave primaria es (NUM_FACTURA, LINEA) y el atributo NUM_FACTURA también es clave
ajena.
En la relación LINEAS_FACTURAS ya no se dan los problemas de redundancia y anomalías de

actualización que tenía FACTURAS1, pero en FACTURAS2 se siguen manteniendo.
3.3. Tercera forma normal (3FN)

Una relación está en tercera forma normal (3FN) si, y sólo si, está en segunda forma normal
y no existen atributos que no pertenezcan a las claves que puedan ser conocidos mediante
otro atributo que no forme parte de ninguna de las claves, es decir, no hay dependencias
funcionales transitivas. Es decir, tenemos que buscar dependencias funcionales entre
atributos que no estén en la clave y eliminar esas dependencias.
En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias de

dependencias como la siguiente: K → A y A → B, donde A y B no pertenecen a la clave. La
solución a este tipo de dependencias está en separar en una tabla adicional N el/los atributos
B, y poner como clave primaria de N el atributo que define la transitividad A.
Siguiendo el ejemplo de la empresa donde se indican los puestos de trabajo de los diferentes
empleados y las condiciones salariales, tenemos que comprobar si hay alguna dependencia
entre los atributos que no forman parte de la clave en las tablas que se encuentran en la 2FN

(Tabla 7). En este caso nos encontramos que el salario de los empleados depende del puesto
de trabajo, es decir, tenemos la siguiente dependencia entre atributos que no son parte de la
clave, por tanto, la tabla EMPLEADOS_2FN no cumple la 3FN:
PUESTO → SALARIO
Ahora tenemos que descomponer la tabla EMPLEADOS_2FN para que cumpla la 3FN. Para
conseguirlo crearemos una tabla con los atributos que nos impiden que se cumpla la forma
normal (Tabla 9):
EMPLEADOS PUESTOS
NSS NOMBRE PUESTO PUESTO SALARIO
111 JUAN PÉREZ JEFE DE ÁREA JEFE DE ÁREA 3000
222 JOSÉ SÁNCHEZ ADMINISTRATIVO ADMINISTRATIVO 1500
333 ANA DÍAZ ADMINISTRATIVO ADMINISTRATIVO 1500

Tabla 9: Solución 3FN
En la nueva tabla PUESTOS, la clave primaria sería el puesto y en la tabla EMPLEADOS dejamos
como clave ajena el puesto que apunta a la nueva tabla. El resto de las tablas quedan como
estaban, por tanto, después de todo el proceso de normalización tendremos las siguientes
tablas (Tabla 10):
EMAILS PUESTOS
EMPLEADOS
NSS EMAIL PUESTO SAL.
NSS NOMBRE PUESTO
111 administracion@ecn.es JEFE DE ÁREA 3000
111 JUAN PÉREZ JEFE DE ÁREA
111 jefe2@ecn.es ADMINISTRATIVO 1500
222 JOSÉ SÁNCHEZ ADMINISTRATIVO
222 administracion@ecn.es ADMINISTRATIVO 1500
333 ANA DÍAZ ADMINISTRATIVO
333 adiaz@ecn.es
Tabla 10: Tablas normalizadas (3FN)
En la Tabla 8, la relación LINEAS_FACTURAS se encuentra en 3FN pero no ocurre lo mismo

con FACTURAS2; en esta relación los atributos CIF y NOMBRE tienen dependencia funcional
transitiva de la clave NUM_FACTURA a través del atributo CODIGO_CLIENTE. Es decir,
tenemos las siguientes dependencias:
En la Tabla 11 aparece la descomposición de FACTURAS2 en las relaciones FACTURAS y

CLIENTES, de las que se han eliminado las dependencias transitivas y por tanto se encuentran
en tercera forma normal. Se puede observar que las relaciones de la figura ya no presentan
los problemas de la relación FACTURAS1.

CLIENTES
CODIGO_CLIENTE CIF NOMBRE
654321 11223344B LUIS SUAREZ
123456 1234567J JUAN PEREZ
FACTURAS
NUM_FACTURA CODIGO_CLIENTE FECHA
008976 654321 21-9-97
008985 123456 23-9-97
LINEAS_FACTURAS
NUM_FACTURA LÍNEA REFERENCIA CANTIDAD
008976 1 786543 12
008976 2 564322 48
008985 1 456789 100
008985 2 564322 36
008985 3 556677 50
Tabla 11: Tablas en 3FN
La descomposición de un esquema de relación en otros que se encuentren en formas

normales superiores debe realizarse conservando la información y las dependencias.
Conservar las dependencias significa que el conjunto de dependencias asociadas al esquema
de relación original debe ser equivalente al conjunto asociado a sus proyecciones, mientras
que conservar la información significa que, en todo momento, la reunión natural de las
proyecciones debe dar lugar a la relación original, tanto en intensión como en extensión.
Se puede demostrar que las descomposiciones de las Tabla 10 y Tabla 11 mantienen tanto la
información como las dependencias respecto a las relaciones originales, pero no siempre
ocurre así.
Para evitar la pérdida de información, las descomposiciones deben ser realizadas según el
teorema de Heath.
El teorema de Heath dice:
Sea R {X, Y, Z} una relación, donde X, Y y Z son conjuntos de atributos. Si R satisface la

dependencia funcional X → Y, entonces R es igual a la reunión de las siguientes relaciones {X,
Y} y {X, Z}.
Por tanto, si la dependencia funcional que satisface FACTURAS2 (Tabla 8) es:

las dos tablas deberían tener en común el atributo CODIGO_CLIENTE:
CLIENTES (CODIGO_CLIENTE, CIF, NOMBRE)
FACTURAS (NUM_FACTURA, CODIGO_CLIENTE, FECHA)

Se puede comprobar, realizando la reunión de ambas tablas, que, en este caso, no hay pérdida
de información.
Rissanen demuestra que para que una descomposición conserve tanto la información como
las dependencias funcionales, debe ser realizada en proyecciones independientes.
Según Rissanen dos proyecciones R1 y R2 de una relación R son independientes si, y sólo si:
a) Toda dependencia funcional en R puede deducirse de las de R1 y R2.
b) Los atributos comunes de R1 y R2 forman una clave candidata de, al menos, una de las
dos relaciones.
4. Forma normal de Boyce-Codd

En la mayoría de los casos es suficiente que una relación se encuentre en 3FN para que no
presente anomalías, pero algunas relaciones con varias claves candidatas compuestas que se
solapan siguen presentando problemas, a pesar de cumplir las restricciones que establece
esta forma normal. Para resolver estos casos, Boyce y Codd establecieron en 1974 la forma
normal que lleva su nombre, tratándose, en realidad, de una definición más estricta de la 3FN.
Una relación se encuentra en forma normal de Boyce/Codd (FNBC) si, y sólo si, todo
determinante es clave candidata.
Es decir, en una relación que está en FNBC los únicos determinantes son las claves candidatas.
Vamos a utilizar como ejemplo la relación siguiente:
ACTIVIDADES_SOCIOS (DNI, CODIGO_SOCIO, CODIGO_ACTIVIDAD, FECHA_ALTA)
Esta relación fue diseñada para registrar las actividades practicadas por los socios de un club
deportivo. Sus claves candidatas son: {ACTIVIDAD, DNI} y {ACTIVIDAD, CODIGO_SOCIO}.
Asociadas a esta relación existen las siguientes dependencias funcionales:

ACTIVIDAD, DNI → FECHA_ALTA
ACTIVIDAD, CODIGO_SOCIO → FECHA_ALTA
DNI → CODIGO_SOCIO
CODIGO_SOCIO → DNI
Es evidente que la relación ACTIVIDADES_SOCIOS está en 3FN; su único atributo no clave

(FECHA_ALTA) tiene dependencia funcional completa y no transitiva de las claves. Pero para
que se encuentre en FNBC no puede haber más determinantes que las claves y eso no se
cumple. El atributo DNI, que no es clave, determina a CODIGO_SOCIO, e igualmente,
CODIGO_SOCIO determina a DNI.
Si una relación no tiene claves solapadas y está en 3FN, también se encuentra en FNBC.

Como en los casos anteriores, las anomalías presentes en una relación que no está en FNBC
desaparecen al sustituirla por sus proyecciones en FNBC. El paso a esta forma normal se
puede realizar, siempre, sin pérdida de información, pero no siempre es posible el
mantenimiento de las dependencias. Debido a esta pérdida de dependencias, muchas veces
es preferible dejar las relaciones en 3FN.
5. Cuarta forma normal

En la Tabla 12 aparece la relación TAQUILLAS_SOCIOS, diseñada para almacenar las taquillas
que los socios de un gimnasio tienen asignadas permanentemente para guardar sus objetos
personales. A cada socio se le asignan una o más taquillas, dependiendo de las actividades
deportivas practicadas por él o por cualquiera de sus familiares. Las taquillas de un socio
pueden ser usadas por él o por cualquiera de sus familiares; así, el socio A1111 comparte con
su familiar H0001 las taquillas 223 y 274, y el socio A2222 y sus familiares K0010 y K0011
tienen las taquillas 341 y 412.
TAQUILLAS_SOCIOS
CODIGO_SOCIO CODIGO_FAMILIAR TAQUILLA
A1111 H0001 223
A1111 H0001 274
A2222 K0010 341
A2222 K0010 412
A2222 K0011 341
A2222 K0011 412
Tabla 12: Ejemplo de relación con dependencias multivaluadas
Esta relación, cuya clave primaria está formada por sus tres atributos, está en FNBC, ya que
no tiene dependencias funcionales asociadas. No obstante, en ella hay redundancia y se
producen anomalías de actualización. Por ejemplo, para registrar el hecho de que al socio
A2222 se le asigna una nueva taquilla, será necesario añadir dos tuplas. Una para que la pueda
usar el familiar K0010 y otra para que la pueda usar el familiar K0011.
El problema radica en que en esta relación existen un tipo de dependencias denominado

dependencias multivaluadas.
Una dependencia multivaluada es una sentencia X →→ Y, donde X e Y son descriptores tales

que un cierto valor de X implica un conjunto bien definido de valores de Y, con independencia
de los demás atributos de la relación.
En la relación TAQUILLAS_SOCIOS, cada valor de CODIGO_SOCIO determina un conjunto de

una o más taquillas, independientemente de los familiares del socio; es decir, existe la
dependencia multivaluada CODIGO_SOCIO →→ TAQUILLA. También, existe la dependencia
CODIGO_SOCIO →→ CODIGO_FAMILIAR, ya que existe una relación entre socio y familiares,
independiente de las taquillas.

Las dependencias multivaluadas siempre aparecen por parejas; si en un esquema existe la

dependencia X→→Y, también existe la dependencia X→→A - (X U Y), donde A es el conjunto
de todos los atributos de la relación. Las dos dependencias funcionales que forman pareja se
representan: X →→Y | A - (X U Y). Por ejemplo,
CODIGO_SOCIO →→CODIGO_FAMILIAR|TAQUILLA
representa:
CODIGO_SOCIO →→CODIGO_FAMILIAR
CODIGO_SOCIO →→TAQUILLA
Una dependencia funcional es una dependencia multivaluada, donde cada valor del
determinante implica un único valor del implicado.
En 1977 R. Fagin enunció la cuarta forma normal.
Una relación se encuentra en cuarta forma normal (4FN) si, y sólo si, toda dependencia
multivaluada viene determinada por una clave candidata.
La relación TAQUILLAS_SOCIOS no está en 4FN, puesto que sus dependencias multivaluadas

CODIGO_SOCIO→→CODIGO_FAMILIAR | TAQUILLA tienen como determinante a
CODIGO_SOCIO que no es clave.
Una relación que no esté en 4FN puede ser descompuesta, sin pérdida de información, en dos
proyecciones que sí están en 4FN.
Los problemas que presenta la relación TAQUILLAS_SOCIOS desaparecen al sustituirla por las
dos proyecciones mostradas en la Tabla 13. Se puede comprobar que dichas proyecciones
están en 4FN.
F_SOCIOS T_SOCIOS
CODIGO_SOCIO CODIGO_FAMILIAR CODIGO_SOCIO TAQUILLA
A1111 H0001 A1111 223
A2222 K0010 A1111 274
A2222 K0011 A2222 341
A2222 412
Tabla 13: Proyecciones de la relación TAQUILLAS-SOCIOS
Es frecuente comenzar el proceso de normalización descomponiendo en proyecciones

independientes, teniendo en cuenta las dependencias multivaluadas. A continuación, se
seguiría con la normalización de dichas proyecciones, que pueden no estar en 2FN, 3FN o
FNBC.

6. Quinta forma normal

Hasta a aquí hemos visto cómo eliminar dependencias funcionales y multivaludas indeseadas
de una relación, descomponiéndola, sin pérdida de información, en dos de sus proyecciones.
Por este método se obtenían relaciones sin problemas de redundancia, que no presentaban
anomalías de actualización, y que, en definitiva, representaban con más fidelidad la realidad.
No obstante, existen relaciones para las que no es posible la descomposición en sólo dos
proyecciones conservando la información.
En la Tabla 14 tenemos la relación EQUIPOS diseñada para registrar los equipos que participan
en un campeonato escolar entre colegios. Cada tupla almacena los datos de un equipo: el
nombre del colegio, el deporte y la categoría. En las reglas del campeonato se establece que,
si un colegio presenta algún equipo de un determinado deporte, si ese colegio participa con
algún equipo en una determinada categoría, y si, además, hay competición de ese deporte en
esa categoría, obligatoriamente el colegio debe participar con un equipo de ese deporte y esa
categoría. Es decir, que si existen las tres tuplas siguientes:
(S. APOSTOL, VOLEIBOL, X)

(S. APOSTOL, X, ALEVIN)
(X, VOLEIBOL, ALEVIN)
donde X representa cualquier valor del correspondiente dominio.
También debe existir la tupla:
(S. APOSTOL, VOLEIBOL, ALEVIN)
EQUIPOS
COLEGIO DEPORTE CATEGORIA
S. APOSTOL BALONMANO ALEVIN
S. APOSTOL VOLEIBOL INFANTIL
A. SELA VOLEIBOL ALEVIN
S. APOSTOL VOLEIBOL ALEVIN
Tabla 14: Relación EQUIPOS
A pesar de que la relación está en 4FN (no tiene asociadas dependencias funcionales o
multivaludas no triviales), presenta anomalías de actualización. Así, si se pretende eliminar la
tupla (S. APOSTOL, VOLEIBOL, ALEVIN), necesariamente se debe eliminar también alguna de
las otras tres. De igual forma, si se inserta (A. SELA, BALONMANO, INFANTIL) habría que
insertar (A. SELA, VOLEIBOL, INFANTIL) y (S. APOSTOL, BALONMANO, INFANTIL).
Hasta ahora solucionamos el problema de las anomalías descomponiendo, sin pérdida de

información, la relación en dos de sus proyecciones. Sin embargo, en este caso no es posible.
En la Tabla 15 observamos que la descomposición de EQUIPOS en dos proyecciones se realiza
con pérdida de información, puesto que la tupla (S. APOSTOL, BALONMANO, INFANTIL) que

aparece en la reunión natural de las proyecciones, no estaba en EQUIPOS. Se podrían haber

elegido otras proyecciones, pero se seguiría produciendo pérdida de información.
C_DEPORTE C_CATEGORIA
COLEGIO DEPORTE COLEGIO CATEGORIA
S. APOSTOL BALONMANO S. APOSTOL ALEVIN
S. APOSTOL VOLEIBOL S. APOSTOL INFANTIL
A. SELA VOLEIBOL A. SELA ALEVIN
C_DEPORTE *C_CATEGORIA
COLEGIO DEPORTE CATEGORIA
S. APOSTOL BALONMANO ALEVIN
S. APOSTOL BALONMANO INFANTIL
S. APOSTOL VOLEIBOL INFANTIL
A. SELA VOLEIBOL ALEVIN
S. APOSTOL VOLEIBOL ALEVIN
Tabla 15: Descomposición con pérdida de información de EQUIPOS
No obstante, el problema queda resuelto si la descomposición se hace en tres proyecciones.

Se puede comprobar que la reunión natural de las proyecciones de EQUIPOS sobre (COLEGIO,
DEPORTE), (COLEGIO, CATEGORIA) y (DEPORTE, CATEGORIA) da como resultado la relación
EQUIPOS.
Una relación R satisface una dependencia de reunión respecto a sus proyecciones R1, R2, …,
Rn, denotado DR * (R1, R2, …, Rn), si, y sólo si, R es igual a la reunión natural de dichas
proyecciones.
Las dependencias de reunión también se conocen como dependencias de

proyección/reunión.
La relación EQUIPOS satisface la siguiente dependencia de reunión:
DR * (ΠCOLEGIO, DEPORTE (EQUIPOS),

ΠCOLEGIO, CATEGORIA (EQUIPOS),
ΠDEPORTE, CATEGORIA (EQUIPOS))
Fagin, en 1979, enunció la quinta forma normal, también conocida como forma normal de
proyección-reunión (PJ/NF, del inglés Projection-Join Normal Form).
Una relación R está en quinta forma normal (5FN) si, y sólo si, está en 4FN y toda dependencia
de reunión está implicada por una clave candidata.
Otra definición de 5FN es la que dice que “una relación está en 5FN sí, y sólo si, toda
dependencia (funcional, multivaluada o de reunión) es consecuencia de las claves
candidatas”.

Como ya vimos en el ejemplo, una relación que no esté en 5FN por tener una dependencia de
reunión, puede ser descompuesta, sin pérdida de información, en las n proyecciones sobre
las que se define dicha dependencia. Estas proyecciones están en 5FN.
Existen otras formas normales, pero la quinta es la forma normal final con respecto a la
proyección y la reunión. Es decir, si una relación está en 5FN se puede asegurar que no tiene
anomalías que puedan ser eliminadas por descomposición en proyecciones. Si se utiliza otro
operador distinto a la proyección, se podría hablar de otras formas normales y de otras
descomposiciones para lograr que las relaciones estén en dichas formas normales.
La mayoría de los autores propugnan que en el proceso de normalización de los esquemas de

relación se llegue hasta la 5FN, aunque, en algunos casos sea necesario, posteriormente, por
razones de eficiencia pasar a alguna forma normal inferior.

Contenido: Unidad de Trabajo 4: Diseño en El Modelo Relacional

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Contenido: Unidad de Trabajo 4: Diseño en El Modelo Relacional

Cargado por

Copyright:

Formatos disponibles

Unidad de Trabajo 4: DISEÑO EN EL MODELO RELACIONAL

GESTIÓN DE BASES DE DATOS 1

1. El problema del diseño de una base de datos relacional.

Ilustración 1: Modelo Relacional

El diseñador puede obtener el esquema relacional directamente de la observación del

Un método de diseño alternativo al anterior consiste en obtener, primero, un esquema

En la Tabla 1: aparece la relación FACTURAS1 que podría pertenecer a cierto esquema

008976 1 786543 12 654321 21-9-17 11223344B LUIS SUAREZ

008976 2 564322 48 654321 21-9-17 11223344B LUIS SUAREZ

008985 1 456789 100 123456 23-9-17 1234567J JUAN PEREZ

008985 2 564322 36 123456 23-9-17 1234567J JUAN PEREZ

008985 3 556677 50 123456 23-9-17 1234567J JUAN PEREZ

GESTIÓN DE BASES DE DATOS 2

Concretamente, en FACTURAS1 se observa:

Un diseño más cuidadoso podría habernos llevado a distinguir la información de

Tabla 2: Diseño correcto

La teoría de la normalización permite analizar un esquema detectando en él posibles

GESTIÓN DE BASES DE DATOS 3

Quinta forma normal (5FN)

Cuarta forma normal (4FN)

Forma normal de Boyce/Codd (FNBC)

Tercera forma normal (3FN)

Segunda forma normal (2FN)

Primera forma normal (1 FN)

Ilustración 2: Formas normales.

GESTIÓN DE BASES DE DATOS 4

Dado un esquema de relación R y los subconjuntos de sus atributos X e Y, se dice que Y

Por ejemplo, si tengo una relación como la siguiente:

2.1. Tipos de dependencias funcionales

GESTIÓN DE BASES DE DATOS 5

La dependencia funcional NUM_FACTURA, LINEA → REFERENCIA es completa ya que LINEA

Una dependencia funcional es trivial cuando el implicado es un subconjunto del implicante.

Se denomina dependencia funcional elemental a una dependencia funcional no trivial en la

Las siguientes dependencias funcionales son elementales:

Los atributos CIF y CODIGO_CLIENTE son equivalentes ya que en el esquema de la Tabla 1: se

Dados los descriptores X, Y, Z de la relación R, existe dependencia transitiva de Z respecto a

Si en la relación FACTURAS1 hubiésemos incluido el atributo PRECIO para representar el

NUM_ FACTURA, LINEA → PRECIO

Esta dependencia es transitiva ya que también se cumple que:

NUM_FACTURA, LINEA → REFERENCIA

REFERENCIA → NUM_FACTURA, LINEA

GESTIÓN DE BASES DE DATOS 6

A partir de un conjunto de dependencias funcionales es posible obtener otras que no estaban

2.2. Axiomas que permiten obtener las dependencias

Sean X, Y, Z, W descriptores o atributos de una relación R.

En la notación anterior, XW representa X U W, e YZ representa Y U Z, es decir, la reunión de

De estos tres axiomas se pueden derivar otros como los siguientes:

GESTIÓN DE BASES DE DATOS 7

Así, por ejemplo, tomemos el conjunto de dependencias funcionales existentes en el universo

Por ejemplo, aplicando el axioma de reflexividad se obtiene:

NUM_FACTURA, LINEA → NUM_FACTURA

Y aplicando el mismo axioma a:

Ahora, el conjunto de dependencias asociado a FACTURAS1 incluye también las dependencias

GESTIÓN DE BASES DE DATOS 8

3. Primera, segunda y tercera formas normales

3.1. Primera forma normal (1FN)

DATOS_EMPLEADOS (nss, nombre, puesto, salario, emails)

222 JOSÉ SÁNCHEZ ADMINISTRATIVO 1500 administracion@ecn.es

3.1.1. Solución 1: duplicar los registros con valores repetidos

GESTIÓN DE BASES DE DATOS 9

111 JUAN PÉREZ JEFE DE ÁREA 3000 administracion@ecn.es

111 JUAN PÉREZ JEFE DE ÁREA 3000 jefe2@ecn.es

222 JOSÉ SÁNCHEZ ADMINISTRATIVO 1500 administracion@ecn.es