Bases de datos – 3. Normalización

Introducción

Bienvenidos una vez más compañeros. Estamos, posiblemente, ante el rootie más pesado de todo el blog. La normalización es un proceso muy importante, pero requiere de muchos conceptos teóricos que no podemos pasar por alto si queremos entender y desarrollar una base de datos perfecta. No hay más narices que pasar por aquí. Es como el típico miniboss que tiene un gritón de HP y sólo te da una llave que necesitas sí o sí para continuar tu aventura.

you-died-gif

La normalización de bases de datos es un proceso que consiste en designar y aplicar una serie de reglas a las relaciones obtenidas tras haber desarrollado el modelo entidad-relación.

Las bases de datos relacionales se normalizan para:

  • Evitar la redundancia de los datos.
  • Disminuir problemas de actualización de los datos en las tablas.
  • Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relación. Para considerarla como tal, hace falta que se cumplan las restricciones que mencionamos en el rootie modelo entidad-relación:

  • Cada tabla debe tener su nombre único.
  • No puede haber dos filas iguales. No se permiten los duplicados.
  • Todos los datos en una columna deben ser del mismo tipo.

Dependencias

Hablamos de dependencias funcionales cuando un atributo tiene una conexión con otro y necesita que éste exista o sea válido para que él tenga sentido.

450px-dependenciafunional
B es funcionalmente dependiente de A

Por ejemplo: FechaDeNacimiento -> Edad. Tu edad depende del día en que naciste 🙂 – tiene sentido, gracias Susan, nunca se me habría ocurrido -.

Propiedades de la dependencia funcional:

  • Dependencia funcional reflexiva: si y está incluido en x, entonces x -> y. Por ejemplo: si la dirección o el nombre de una persona están incluidos en el DNI, entonces con el DNI podemos determinar la dirección o su nombre.
  • Dependencia funcional aumentativa: x -> y entonces xz -> yz. Ejemplo: si con el DNI se determina el nombre de una persona, entonces con el DNI más la dirección también se determina el nombre y su dirección.
  • Dependencia funcional transitiva: si Y depende funcionalmente de X y Z de Y, pero X no depende funcionalmente de Y, se dice entonces que Z depende transitivamente de X.

    dependencia funcional transitiva
    FechaDeNacimiento -> Edad -> Conducir

Propiedades deducidas:

  • Unión: x -> y y x -> z entonces x -> yz
  • Pseudo-Transitiva: x -> y y wy -> z entonces wx -> z
  • Descomposición: x -> y y z está incluido en y entonces x -> z

Formas normales

Este apartado es lo suficientemente extenso y concreto como para tener su propio rootie dedicado. Un breve resumen podría ser el siguiente: se dice que una base de datos está en la forma normal N cuando todas sus tablas están con dicha forma normal N. Existen 6 formas normales, pero en general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayoría de las bases de datos. Las formas normales (NF) proporcionan los criterios para determinar el grado de vulnerabilidad de una tabla a inconsistencias y anomalías lógicas. Cuanto más alta sea la forma normal aplicable a una tabla, menos vulnerable será a inconsistencias y anomalías.

Desnormalización

La desnormalización es un proceso que se realiza después de haber formalizado la base de datos. Consiste en agregar redundancia a cambio de ganar rendimiento. Pero Susan, si nos habías dicho que la redundancia es mala malísima, ¿ahora sí se permite? Los modelos relacionales están muy bien en la teoría, sobre el papel. Cuando nos movemos a un entorno real en el que el número de tablas, relaciones y tuplas aumentan considerablemente y de manera casi exponencial, la cosa cambia.

la-cosa-cambia

Imaginad que tenemos varias tablas con millones de registros y queremos hacer una consulta que las relacione todas. Si hicimos bien el MER y su posterior normalización, nos habrá quedado una estructura muy bonita y perfecta con claves primarias y foráneas, tablas relación de cardinalidades N:M…, pero los datos pueden estar separados físicamente en el disco. La unión de estas tablas (con la cláusula JOIN – la veremos cuando hablemos de consultas -) puede ser prohibitivamente lenta.

Por esto, es responsabilidad del diseñador de la base de datos prever estos inconvenientes y agregar cierta redundancia de datos precisamente para evitar tener que unir muchas tablas en las futuras consultas. Pros y contras de la desnormalización:

  • Pro: ayuda a mejorar el rendimiento.
  • Pro: menor número de tablas.
  • Pro: mejora la velocidad de las consultas.
  • Contra: redundancia de datos.
  • Contra: menor integridad de los datos.

Podéis leer más sobre desnormalización en este enlace.

Reglas de Codd

Codd se percató de que existían bases de datos en el mercado las cuales decían ser relacionales, pero lo único que hacían era guardar la información en las tablas, sin estar estas tablas literalmente normalizadas; entonces éste publicó 12 reglas que un verdadero sistema relacional debería tener, en la práctica algunas de ellas son difíciles de realizar. Un sistema podrá considerarse «más relacional» cuanto más siga estas reglas. wikipedia

 

En el siguiente rootie veremos la teoría concreta sobre las formas normales y ejemplos de normalización de las tablas para, al menos, las 3 primeras formas normales.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *