Hola, he leido este post y creo que cualquiera que esté empezando o lleve poco tiempo "jugando" con Bases de Datos Relacionales acabará confundido.
De manera que espero aclarar algun concepto, y si estoy equivocado en algún punto no duden en hacermelo saber
Lo primero que quería aclarar es el motivo que OBLIGA a Normalizar una Base de Datos.
Principalmente son tres, la mejora del rendimiento, asegurar la consitencia de los datos guardados y la mantenibilidad de la DB.
Respecto a la consitencia e integridad de los datos (que son 2 cosas muy diferentes) no hablaré, pueden buscar información en San Google que seguro lo explicarán mejor que yo.
En cuanto a la mantenibilidad, si alguien crea una aplicación basada en una DB normalizada cuando otra persona (o la misma al cabo de un tiempo) deber retomar dicha aplicación para añadir funcionalidades ahorrará MUCHO tiempo a la hora de comprender qué significado tiene cada tabla y sus relaciones con otras tablas, ya que las reglas para crear la estructura de la DB son conocidas e iguales para todo el mundo.
Respecto al rendimiento, la normalización siempre lo aumentará. Se ahorrará espacio en disco, memoria y tiempo de CPU ya que se optimizará la cantidad de información a guardar en las tablas y el tiempo de acceso a los datos.
Vuelvo a decirles que le pregunten a Google si quieren más detalles que justifiquen el porqué.
Algunos de los mensajes que he leido hablan de niveles de normalización y que una normalización excesiva puede "tumbar" o acabar con tu máquina...
Esta frase es un grave error que mezcla conceptos que nada tienen que ver.
Intentaré explicarme con claridad.
La Normalización consiste en aplicar una serie de reglas.
Es cierto que existen varios niveles de normalización, en función de si aplicas más reglas o menos.
Estas reglas que originalmente eran 12 acabaron simplificandose en lo que se conoce como FORMAS NORMALES (no recuerdo si eran 5 o 6).
Lo más habitual es que una DB normalizada aplique como mínimo las 3 primeras Formas Normales. Nivel mínimo para una Normalización correcta.
Personalmente recomiendo que se aplique hasta la BCNF (Boyce-Codd Normal Form) o 4ª Forma Normal que lleva el nombre del AUTOR de las reglas de Normalización.
Se pueden aplicar todas Formas Normales de forma que conseguirás un Diseño "purista" de tu DB. No es lo habitual, ya que tu diseño será más estricto y menos flexible a futuras modificaciones.
De modo que es cierto que existen diferentes "NIVELES" de Normalización, de hecho Oracle en su versión 8 solo implementaba estas 3 primeras Formas Normales y no incluyó el resto hasta la versión "9i" de su SGBD (Sistema Gestor de Base de Datos).
La normalización excesiva "tumbará" tu máquina...
No existe una normalización excesiva, o se normaliza o no se hace. O se hace bién, o se hace mal.
Esto se verá más claramente con el siguiente ejemplo.
Supongamos que tenemos una tabla con datos de empresas en la que aprecen unos campos reservados para la dirección,(calle, número, código postal, ...). Si vemos que varias de estas empresas tienen el mismo valor en el campo "calle" o "código_postal" podríamos pensar que sería útil tener una tabla para las direcciones y crear una clave foranea que relacione la tabla empresas con esta nueva tabla.
A continuación vemos que sucede lo mismo para las direcciones de los clientes...
Vuelve a suceder con las direcciones de los proveedores...
Nos damos cuenta de que los empleados de nuestra empresa también tienen dirección!!
Cuantas tablas para direcciones tendriamos que crear?
Puedo hacer una para todos y dejar en blanco los campos que no necesite para un empleado y sí necesite para una empresa cliente....
Eso sería aplicar FATAL las reglas de la Normalización.
Si se hace una aplicación sistemática e INCORRECTA de las Formas Normales entonces el rendimiento de tu DB empeorará pero no es culpa de la normalización, es culpa tuya!
La normalización en realidad se considera una herramienta imprescindible en proceso de creación de una DB, ese proceso se compone por un análisis de las necesidades de lo que se desea crear y un diseño.
Cuando se tienen estas dos cosas es cuando se implementa, no se puede empezar la casa por el tejado creando tablas y luego "moviendo" campos a otras tablas de nueva creación.
Se debe estudiar previamente que "entidades" y relaciones entre ellas se necesitarán y la normalización nos dirá que tablas se deben crear.
(la 3FN y la BCNF nos dicen que las relaciones n-m se deben romper creando 2 relaciones 1-n y m-1 y una tabla intermedia, incluso nos dice qué campos debe tener esa tabla intemedia!!!).
Lamento haberme extendido tanto, pero espero que aclare algunos conceptos a quien no lo tenía del todo claro.
Para terminar quería hacer un pequeño comentario respecto a la historia de la informática y a quien creó la primera DB relacional...
Las primeras DB estaban basadas en ficheros, y todo el mundo vió que se hacian lentas y problematicas en cuanto crecian en número de datos.
De forma que los señores de IBM empezaron un proyecto para definir como deberían ser las Bases de Datos Relacionales.
En ese proyecto trabajaba el señor Boyce Codd que les comenté antes. En IBM estaban tan contentos con su trabajo que en su honor la 4FN lleva su nombre...
Cual fué su sorpresa cuando al cabo de muy poco tiempo de que IBM publicara su trabajo (Definición, Análisis y Diseño de como deberían ser las DB-Relacionales) apareció una IMPLEMENTACIÓN de la ESPECIFICACIÓN que ellos habían realizado.
Esa Implementación de la primera DB Relacional la puso en el mercado una empresa que si no recuerdo mal se llamaba "RELATIONAL SOFTWARE".
No se extrañen si no la conocen, ya que, su existencia fue breve. Le cambiaron el nombre a esta compañía y la llamaron ORACLE.
Espero que les haya interesado este post.
MAC.