NORMALIZACIN

FORMAS NORMALES
Un ejemplo tpico para mostrar una tabla que, estando en 3FN, mantiene dependencias funcionales,
puede ser una tabla que posee los atributos Direccin, Cdigo Postal y Ciudad, deduciendo que a Ciudades
diferentes le corresponden cdigos postales distintos.
Tabla en tercera forma normal
CPost Dir Ciud
3000 C/ Las Flores N17 Merida
4858 Av. Bolvar este N72 Maracay
En este caso hay dependencia entre el Cdigo Postal y la Ciudad, ya ccccdc< que, conocido el
Cdigo Postal se puede conocer la Ciudad, y conocida la Direccin y la Ciudad, se conoce el Cdigo Postal.
Para transformar la tabla en una tabla en FNBC se crea una tabla de Cdigos Postales y Ciudades,
eliminando de la tabla original la Ciudad, obtenindose dos tablas, una con los atributos Direccin y Cdigo
Postal y otra con el Cdigo Postal y la Ciudad


Tabla en forma normal de Boyce-Codd
CPost Ciud
3000 Merida
4858 Maracay

En la mayora de los casos, las relaciones en 3FN estarn en FNBC. Para Validar esto se deben ubicar
todos los determinantes existentes en la relacin as como todas las claves candidatas, se comparan ambos
conjuntos y si encuentra que hay algn determinante que no resulta ser clave candidata se demuestra que
Tabla en forma normal de Boyce-Codd
CPost Dir
3000 C/ Las Flores N17
4858 Av. Bolvar este N72
no esta en FNBC. Se comprueba que la relacin est en 1FN, todos los atributos son atmicos. Tambin est
en 2FN ya que no hay dependencias funcionalmente completas entre atributos que no sean clave (formen
parte de la clave). Y finalmente se verifica que no hay ningn atributo que dependa de forma transitiva de la
clave Primaria, luego est en 3FN. Usualmente se considera aceptable tener relaciones que lleguen slo
hasta la FNBC.
La definicin de la 3FN no produce diseos satisfactorios cuando se dan las siguientes condiciones, o lo
que es lo mismo, cuando una relacin NO ESTE EN FNBC concurrirn las siguientes circunstancias:
Existen varias claves candidatas.
Las claves candidatas son compuestas.
Las claves candidatas se encubren, tienen al menos un atributo en comn.
No hay un teorema sobre la divisin de la relacin, el motivo es que no se puede asegurar que al
descomponer una relacin en dos para conseguir la FNBC el significado de las relaciones obtenidas se
corresponda semnticamente a lo que representa la relacin inicial. En otras palabras, se puede tomar una
decisin equivocada al descomponer ya que puede que perdamos parte de la semntica de la relacin
anterior.


Consideremos una empresa donde un trabajador puede trabajar en varios departamentos. En cada
departamento hay varios responsables, pero cada trabajador slo tiene asignado uno. Tendramos una tabla
con las columnas:
trabajador(IDTrabajador, IDDepartamento, IDResponsable)
La nica clave candidata es IDTrabajador (que ser por tanto la clave primaria).
Si aadimos la limitacin de que el responsable slo puede serlo de un departamento, este detalle produce
una dependencia funcional ya que: Responsable Departamento
Por lo tanto hemos encontrado un determinante (IDResponsable) que sin embargo no es clave candidata.
Por ello, esta tabla no est en FNBC. En este caso la redundancia ocurre por mala seleccin de clave. La
repeticin del par [IDDepartamento + IDResponsable] es innecesaria y evitable.

Reglas de Codd
Codd se percat de que existan bases de datos en el mercado las cuales decan ser relacionales, pero lo nico que
hacan era guardar la informacin en las tablas, sin estar estas tablas literalmente normalizadas; entonces ste public
12 reglas que un verdadero sistema relacional debera tener, en la prctica algunas de ellas son difciles de realizar. Un
sistema podr considerarse "ms relacional" cuanto ms siga estas reglas.
Regla No. 1 - La Regla de la informacin
Toda la informacin en un RDBMS est explcitamente representada de una sola manera por valores en una
tabla.
Cualquier cosa que no exista en una tabla no existe del todo. Toda la informacin, incluyendo nombres de tablas,
nombres de vistas, nombres de columnas, y los datos de las columnas deben estar almacenados en tablas dentro de las
bases de datos. Las tablas que contienen tal informacin constituyen el Diccionario de Datos. Esto significa que todo
tiene que estar almacenado en las tablas.

Toda la informacin en una base de datos relacional se representa explcitamente en el nivel lgico exactamente de una
manera: con valores en tablas. Por tanto los metadatos (diccionario, catlogo) se representan exactamente igual que
los datos de usuario. Y puede usarse el mismo lenguaje (ej. SQL) para acceder a los datos y a los metadatos (regla 4)
Regla No. 2 - La regla del acceso garantizado
Cada tem de datos debe ser lgicamente accesible al ejecutar una bsqueda que combine el nombre de la
tabla, su clave primaria, y el nombre de la columna.

Esto significa que dado un nombre de tabla, dado el valor de la clave primaria, y dado el nombre de la columna
requerida, deber encontrarse uno y solamente un valor. Por esta razn la definicin de claves primarias para todas las
tablas es prcticamente obligatoria.

Regla No. 3 - Tratamiento sistemtico de los valores nulos
La informacin inaplicable o faltante puede ser representada a travs de valores nulos

Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser capaz de soportar el uso de valores nulos en el
lugar de columnas cuyos valores sean desconocidos.

Regla No. 4 - La regla de la descripcin de la base de datos
La descripcin de la base de datos es almacenada de la misma manera que los datos ordinarios, esto es, en
tablas y columnas, y debe ser accesible a los usuarios autorizados.

La informacin de tablas, vistas, permisos de acceso de usuarios autorizados, etc, debe ser almacenada exactamente de
la misma manera: En tablas. Estas tablas deben ser accesibles igual que todas las tablas, a travs de sentencias de SQL
(o similar).

Regla No. 5 - La regla del sub-lenguaje Integral
Debe haber al menos un lenguaje que sea integral para soportar la definicin de datos, manipulacin de
datos, definicin de vistas, restricciones de integridad, y control de autorizaciones y transacciones.

Esto significa que debe haber por lo menos un lenguaje con una sintaxis bien definida que pueda ser usado para
administrar completamente la base de datos.

Regla No. 6 - La regla de la actualizacin de vistas
Todas las vistas que son tericamente actualizables, deben ser actualizables por el sistema mismo.

La mayora de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos de actualizar vistas
complejas.

Regla No. 7 - La regla de insertar y actualizar
La capacidad de manejar una base de datos con operandos simples aplica no slo para la recuperacin o
consulta de datos, sino tambin para la insercin, actualizacin y borrado de datos'.

Esto significa que las clusulas para leer, escribir, eliminar y agregar registros (SELECT, UPDATE, DELETE e INSERT en
SQL) deben estar disponibles y operables, independientemente del tipo de relaciones y restricciones que haya entre las
tablas o no.

Regla No. 8 - La regla de independencia fsica
El acceso de usuarios a la base de datos a travs de terminales o programas de aplicacin, debe permanecer
consistente lgicamente cuando quiera que haya cambios en los datos almacenados, o sean cambiados los
mtodos de acceso a los datos.

El comportamiento de los programas de aplicacin y de la actividad de usuarios va terminales debera ser predecible
basados en la definicin lgica de la base de datos, y ste comportamiento debera permanecer inalterado,
independientemente de los cambios en la definicin fsica de sta.

Regla No. 9 - La regla de independencia lgica
Los programas de aplicacin y las actividades de acceso por terminal deben permanecer lgicamente
inalteradas cuando quiera que se hagan cambios (segn los permisos asignados) en las tablas de la base de
datos.

La independencia lgica de los datos especifica que los programas de aplicacin y las actividades de terminal deben ser
independientes de la estructura lgica, por lo tanto los cambios en la estructura lgica no deben alterar o modificar
estos programas de aplicacin.

Regla No. 10 - La regla de la independencia de la integridad
Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en el catalogo, no en
el programa de aplicacin.

Las reglas de integridad
1. Ningn componente de una clave primaria puede tener valores en blanco o nulos.
2. Para cada valor de clave fornea deber existir un valor de clave primaria concordante. La combinacin de
estas reglas aseguran que haya integridad referencial.
Regla No. 11 - La regla de la distribucin
El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos est distribuida
fsicamente en distintos lugares sin que esto afecte o altere a los programas de aplicacin.

El soporte para bases de datos distribuidas significa que una coleccin arbitraria de relaciones, bases de
datos corriendo en una mezcla de distintas mquinas y distintos sistemas operativos y que est conectada
por una variedad de redes, pueda funcionar como si estuviera disponible como en una nica base de datos
en una sola mquina.

Regla No. 12 - Regla de la no-subversin
Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera pueden ser usados para violar
la integridad de las reglas y restricciones expresadas en un lenguaje de alto nivel (como SQL).

Algunos productos solamente construyen una interfaz relacional para sus bases de datos No relacionales, lo
que hace posible la subversin (violacin) de las restricciones de integridad. Esto no debe ser permitido.