Skip to content Skip to navigation

Connexions

You are here: Home » Content » Un ejemplo simple de normalización de bases de datos relacionales (hasta 3FN)

Navigation

Recently Viewed

This feature requires Javascript to be enabled.

Un ejemplo simple de normalización de bases de datos relacionales (hasta 3FN)

Module by: Miguel-Angel Sicilia. E-mail the author

User rating (How does the rating system work?)
Ratings

Ratings allow you to judge the quality of modules. If other users have ranked the module then its average rating is displayed below. Ratings are calculated on a scale from one star (Poor) to five stars (Excellent).

How to rate a module

Hover over the star that corresponds to the rating you wish to assign. Click on the star to add your rating. Your rating should be based on the quality of the content. You must have an account and be logged in to rate content.

:
(0 ratings)

Summary: Se describe un ejemplo sencillo (de una sola tabla) de aplicación de la normalización de bases de datos relacionales.

El proceso de normalización de bases de datos relacionales

La normalización de bases de datos relacionales toma un esquema relacional y le aplica un conjunto de técnicas para producir un nuevo esquema que representa la misma información pero contiene menos redundancias y evita posibles anomalías en las inserciones, actualizaciones y borrados.

Breve recordatorio del modelo (formal) relacional

El modelo relacional de bases de datos se basa en un modelo formal especificado de acuerdo a la teoría de conjuntos. Una base de datos relacional puede considerarse como un conjunto de relaciones o tablas de la forma R(A1, ..., An), donde R es el nombre de la relación, que se define por una serie de atributos Ai.

Sobre las tablas relacionales se pueden definir diferentes restricciones. La integridad de entidad es una restricción que nos indica que cada entidad representada por una tupla tiene que ser diferente de las demás en su relación, es decir, debe haber algunos atributos cuyos valores identifiquen unívocamente las tuplas. La integridad referencial indica que una clave ajena solo debe contener valores que o bien sean nulos, o bien existan en la relación referenciada por la clave ajena.

El proceso de normalización

El proceso de normalización consiste en comprobar en secuencia si el esquema original está en 1FN, 2FN y 3FN, analizando las dependencias funcionales en cada paso.

Un ejemplo completo

Tenemos una empresa pública donde los puestos de trabajo están regulados por el Estado, de modo que las condiciones salariales están determinadas por el puesto. Se ha creado el siguiente esquema relacional

EMPLEADOS(nss, nombre, puesto, salario, emails) con nss como clave primaria.

Table 1
nss nombre puesto salario emails
111 Juan Pérez Jefe de Área 3000 juanp@ecn.es; jefe2@ecn.es
222 José Sánchez Administrativo 1500 jsanchez@ecn.es
333 Ana Díaz Administrativo 1500 adiaz@ecn.es; ana32@gmail.com
... ... ... ... ...

Primera forma normal (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.

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.
  • Se incluye un nuevo atributo M' que solo puede contener valores simples, de modo que si R'[M'] es uno de los valores que teníamos en R[M], entonces R'[K] = R[K]. En otras palabras, 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 EMPLEADOS'(a) con clave primaria (nss, email):

Table 2
nss nombre puesto salario email
111 Juan Pérez Jefe de Área 3000 juanp@ecn.es
111 Juan Pérez Jefe de Área 3000 jefe2@ecn.es
222 José Sánchez Administrativo 1500 jsanchez@ecn.es
333 Ana Díaz Administrativo 1500 adiaz@ecn.es
333 Ana Díaz Administrativo 1500 ana32@gmail.com
... ... ... ... ...

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.

Crear 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 EMPLEADOS'(b)

Table 3
nss nombre puesto salario
111 Juan Pérez Jefe de Área 3000
222 José Sánchez Administrativo 1500
333 Ana Díaz Administrativo 1500
... ... ... ...

Y además tendríamos una nueva tabla EMAILS con clave primaria (nss, email):

Table 4
nss email
111 juanp@ecn.es
111 jefe2@ecn.es
222 jsanchez@ecn.es
333 adiaz@ecn.es
333 ana32@gmail.com
... ...

Segunda forma normal (2FN)

Un esquema está en 2FN si:

Está en 1FN.

Todos sus atributos que no son de la clave principal tienen dependencia funcional completa respecto de todas las claves existentes en el esquema. En otras palabras, para determinar cada atributo no clave se necesita la clave primaria completa, no vale con una subclave.

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. Por tanto, de las soluciones anteriores, la tabla EMPLEADOS'(b) está en 1FN (y la tabla EMAILS no tiene atributos no clave), por lo que el esquema está en 2FN. Sin embargo, tenemos que examinar las dependencias funcionales de los atributos no clave de EMPLEADOS'(a). Las dependencias funcionales que tenemos son las siguientes:

nss->nombre, salario, email

puesto->salario

Como la clave es (nss, email), las dependencias de nombre, salario y email son incompletas, por lo que la relación no está en 2FN.

En general, tendremos que observar los atributos no clave que dependan de parte de la clave.

Para solucionar este problema, tenemos que hacer lo siguiente para los gupos de atributos con dependencia incompleta M:

Eliminar de R el atributo M.

Crear una nueva relación N con el atributo M y la parte de la clave primaria K de la que depende, que llamaremos K'.

La clave primaria de la nueva relación será K'.

Siguiendo el ejemplo anterior, crearíamos una nueva relación con los atributos que tienen dependencia incompleta:

Table 5
nss nombre puesto salario
111 Juan Pérez Jefe de Área 3000
222 José Sánchez Administrativo 1500
333 Ana Díaz Administrativo 1500
... ... ... ...

Y al eliminar de la tabla original estos atributos nos quedaría:

Table 6
nss email
111 juanp@ecn.es
111 jefe2@ecn.es
222 jsanchez@ecn.es
333 adiaz@ecn.es
333 ana32@gmail.com
... ...

Como vemos, la solución a la que llegamos es la misma que en la otra opción de solución para el problema de 1FN.

Tercera forma normal (3FN)

Una relación está en tercera forma normal si, y sólo si:

está en 2FN

y, además, cada atributo que no está incluido en la clave primaria no depende transitivamente de la clave primaria.

Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales entre atributos que no estén en la clave.

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 anterior, podemos detectar la siguiente transitividad:

nss->puesto

puesto->salario

Por lo tanto la descomposición sería la siguiente:

Table 7
nss nombre puesto
111 Juan Pérez Jefe de Área
222 José Sánchez Administrativo
333 Ana Díaz Administrativo
... ... ...

En la nueva tabla PUESTOS, la clave sería el puesto, que también queda como clave ajena referenciando la tabla EMPLEADOS. El resto de las tablas quedan como estaban.

Content actions

Give Feedback:

E-mail the module author | Rate module ( How does the rating system work?)

Rating system

Ratings

Ratings allow you to judge the quality of modules. If other users have ranked the module then its average rating is displayed below. Ratings are calculated on a scale from one star (Poor) to five stars (Excellent).

How to rate a module

Hover over the star that corresponds to the rating you wish to assign. Click on the star to add your rating. Your rating should be based on the quality of the content. You must have an account and be logged in to rate content.

(0 ratings)

Download:

Module PDF

Add module to:

My Favorites (?)

'My Favorites' is a special kind of lens which you can use to bookmark modules and collections directly in Connexions. 'My Favorites' can only be seen by you, and collections saved in 'My Favorites' can remember the last module you were on. You need a Connexions account to use 'My Favorites'.

| A lens (?)

Definition of a lens

Lenses

A lens is a custom view of Connexions content. You can think of it as a fancy kind of list that will let you see Connexions through the eyes of organizations and people you trust.

What is in a lens?

Lens makers point to Connexions materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

Who can create a lens?

Any individual Connexions member, a community, or a respected organization.

What are tags? tag icon

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

| External bookmarks