Optimización de Bases de Datos: 3FN, Desnormalización y Jerarquías

Clasificado en Informática

Escrito el en español con un tamaño de 4,78 KB

Tercera Forma Normal (3FN)

Una relación está en Tercera Forma Normal (3FN) si y solo si ya está en 2FN y, además, no pueden existir dependencias funcionales transitivas entre atributos que no formen parte de la clave. En otras palabras, todos los determinantes han de ser claves candidatas.

Conversión a 3FN

Para convertir una relación que no está en 3FN en varias que sí lo están, se sigue este proceso:

  1. Buscar todas las dependencias funcionales (DF) existentes en la relación.
  2. Para cada dependencia funcional cuyo determinante no sea clave candidata, se eliminan los atributos del lado derecho (los dependientes) de la relación original.
  3. Se crea una nueva relación con los atributos del lado izquierdo (el determinante) y los del lado derecho de esa dependencia funcional. El determinante se convierte en la clave primaria de esta nueva relación.
  4. Repetir el proceso para todas las dependencias funcionales que incumplan la 3FN.

Un esquema de base de datos que alcanza la 3FN se considera eficiente y libre de la mayoría de las anomalías de actualización.

Desnormalización

En ocasiones, en bases de datos (BD) que han sido rigurosamente normalizadas, se pueden detectar problemas de rendimiento, especialmente en operaciones de consulta que requieren unir muchas tablas. La desnormalización es el proceso controlado de introducir redundancia para mejorar el rendimiento.

Razones para la Desnormalización

  1. Evita que se tenga que agregar en la aplicación una gran cantidad de código complejo para reconstruir información (por ejemplo, direcciones completas a partir de varias tablas).
  2. Las consultas basadas en datos desnormalizados (como una dirección completa en un solo campo) utilizan una sintaxis SQL más sencilla y rápida al reducir el número de joins.
  3. Los errores en los datos redundantes (como direcciones) se limitan a registros individuales, aunque aumenta el riesgo de inconsistencias.

Eliminación de Relaciones Jerárquicas

El modelo relacional no dispone de mecanismos nativos que permitan representar relaciones jerárquicas (herencia, supertipos/subtipos) directamente. Por lo tanto, es necesario transformarlas. Existen tres posibilidades principales:

Eliminación del Supertipo

Se transfieren todos los atributos del supertipo a cada uno de los subtipos. Cada vínculo del supertipo se replica y se aplica a cada subtipo. Esta técnica solo se puede aplicar a relaciones jerárquicas totales y exclusivas.

  • Inconvenientes: Aumenta el número de vínculos y relaciones en el esquema, haciéndolo más complejo.
  • Recomendación: Es mejor aplicar esta técnica solo cuando el supertipo tenga pocos atributos y vínculos.

Eliminación de los Subtipos

Se transfieren todos los atributos de los subtipos al supertipo de entidad. Cada vínculo de cada subtipo se aplica ahora al supertipo. Se puede aplicar a cualquier tipo de relación jerárquica.

  • Inconveniente: Puede generar una gran cantidad de valores nulos en la tabla del supertipo, ya que un registro solo pertenecerá a uno de los subtipos originales.
  • Ventaja: El esquema resultante es más sencillo, con menos tablas.

Eliminación de la Jerarquía Completa

La interrelación jerárquica se transforma en tantas interrelaciones 1:1 como subtipos haya, manteniendo las cardinalidades originales. Los subtipos se transforman en tipos de entidad débiles por existencia (si se traspasa a los subtipos la clave del supertipo) o débiles por identificación. Este método sirve para cualquiera de los cuatro tipos de relaciones jerárquicas.

  • Ventaja: En principio, es el sistema más flexible y completo para eliminar jerarquías.
  • Inconveniente: Complica significativamente el esquema original al añadir más tablas y relaciones.

Diccionario de Datos

El diccionario de datos es el conjunto de metadatos que contiene las características lógicas y físicas de los datos que se van a utilizar en el sistema de base de datos (SBD) que se está programando.

Razones para su Utilización

  1. Documentar las características del SBD para que todos los participantes en el proyecto tengan una fuente común de información.
  2. Registrar características adicionales del sistema (validaciones, formatos, permisos) de tal manera que toda la información pueda localizarse con rapidez.
  3. Facilitar la localización de errores y omisiones en el diseño de la base de datos.

Entradas relacionadas: