Fundamentos de la Normalización y las 12 Reglas de Codd para Bases de Datos Relacionales

Formas Normales Esenciales para el Diseño de Bases de Datos

Las formas normales (FN) son un conjunto de reglas que buscan reducir la redundancia y mejorar la integridad de los datos en una base de datos relacional.

Tercera Forma Normal (3FN)

La tabla se encuentra en 3FN si está en 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.

Forma Normal de Boyce-Codd (FNBC)

La tabla se encuentra en FNBC si cada determinante (atributo que determina completamente a otro) es clave candidata.

Cuarta Forma Normal (4FN)

Una tabla se encuentra en 4FN si, y solo si, para cada una de sus dependencias múltiples no funcionales $X \rightarrow \rightarrow Y$, siendo $X$ una superclave, $X$ es una clave candidata o un conjunto de claves primarias.

Quinta Forma Normal (5FN)

Una tabla se encuentra en 5FN si cumple los siguientes criterios:

• La tabla está en 4FN.
• No existen relaciones de dependencias no triviales que no siguen los criterios de las claves.

Las 12 Reglas de Codd para Sistemas de Gestión de Bases de Datos Relacionales (RDBMS)

Las reglas de Codd, formuladas por Edgar F. Codd, definen lo que se requiere para que un sistema de gestión de bases de datos sea considerado relacional.

Regla n.º 1 – La Regla de la Información

Toda información en un RDBMS está explícitamente representada de una sola manera por valores en una tabla.

Regla n.º 2 – La Regla del Acceso Garantizado

Cada ítem de datos debe ser lógicamente accesible al ejecutar una búsqueda que combine el nombre de la tabla, su clave primaria y el nombre de la columna.

Regla n.º 3 – Tratamiento Sistemático de los Valores Nulos

La información inaplicable o faltante puede ser representada a través de valores nulos.

Regla n.º 4 – La Regla de la Descripción de la Base de Datos

La descripción de la base de datos es almacenada de la misma manera que todos los datos ordinarios, esto es, en tablas y columnas, y debe ser accesible a los usuarios autorizados.

Regla n.º 5 – La Regla del Sublenguaje Integral

Debe haber al menos un lenguaje que sea integral para soportar la definición de datos, manipulación de datos, definición de vistas, restricciones de integridad y control de autorizaciones y transacciones.

Regla n.º 6 – La Regla de la Actualización de Vistas

Todas las vistas teóricamente actualizables deben ser actualizables por el sistema mismo.

Regla n.º 7 – La Regla de Insertar y Actualizar

La capacidad de manejar una base de datos con operandos simples aplica no solo para la recuperación o consulta de datos, sino también para la inserción, actualización y borrado de datos.

Regla n.º 8 – La Regla de la Independencia Física

El acceso de usuarios a la base de datos a través de terminales o programas de aplicación debe permanecer lógicamente consistente cuando haya cambios en los datos almacenados o se cambien los métodos de acceso a los datos.

Regla n.º 9 – La Regla de Independencia Lógica

Los programas de aplicación y las actividades de acceso por terminal deben permanecer lógicamente inalteradas cuando se hagan cambios en las tablas de la base de datos.

Regla n.º 10 – La Regla de la Independencia de la Integridad

Todas las restricciones de integridad deben ser definibles en los datos y almacenables en el catálogo, no en el programa de aplicación.

Regla n.º 11 – La Regla de la Distribución

El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos esté distribuida físicamente en distintos lugares sin que esto afecte o altere a los programas de aplicación.

Regla n.º 12 – Regla de la No-Subversión

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.