Las 12 Reglas de Codd para Bases Relacionales

En el fascinante mundo de la gestión de datos, las bases de datos relacionales se han consolidado como un estándar fundamental. Pero, ¿qué define realmente a una base de datos como "relacional"? La respuesta nos lleva a los principios establecidos por Edgar Frank Ter Codd, un pionero que definió un conjunto de reglas para asegurar que los sistemas de gestión de bases de datos cumplieran con el rigor teórico y la integridad del modelo relacional. Estas son las célebres 12 reglas de Codd (a menudo incluyendo una regla cero fundamental), que actúan como un criterio de pureza y funcionalidad para cualquier sistema que aspire a ser verdaderamente relacional.

El Modelo Relacional: La Visión de Codd

Antes de las reglas, existía el modelo. A finales de los años 60, mientras modelos como el jerárquico y el de red (popularizado por la norma CODASYL) dominaban el panorama, Edgar F. Codd, trabajando en IBM, propuso una nueva forma de organizar los datos basada en la teoría de conjuntos y la lógica de predicados. Publicó su seminal documento "A Relational Model of data for Large Shared Data Banks" en 1970, que sentó las bases de lo que hoy conocemos como el Modelo Relacional.

La idea central era simplificar la interacción con los datos, alejando a los usuarios de los detalles físicos de almacenamiento. Codd visualizó los datos agrupados en "relaciones", estructuras lógicas que hoy llamamos más comúnmente tablas. Cada tabla representa una entidad y está compuesta por:

• Atributos: Las propiedades o características de la entidad (columnas).
• Tuplas: Cada instancia o registro de la entidad (filas).

Este enfoque conceptual, independiente de cómo se almacenaban físicamente los datos, fue revolucionario. Aunque IBM no adoptó inicialmente su modelo, empresas como Oracle vieron su potencial, llevando el modelo relacional a la prominencia que disfruta hoy en día.

Objetivos Clave del Modelo Relacional

Codd buscaba con su modelo relacional alcanzar varios objetivos cruciales:

• Independencia física: Cambios en el almacenamiento físico no deben afectar la vista lógica de los datos ni las aplicaciones.
• Independencia lógica: Cambios en la estructura lógica (tablas) no deben afectar las aplicaciones existentes, siempre que se preserve la información.
• Flexibilidad: El sistema debe permitir múltiples vistas de los datos adaptadas a diferentes usuarios o aplicaciones.
• Uniformidad: Todas las operaciones sobre los datos deben basarse en la estructura tabular uniforme.
• Sencillez: El modelo debía ser fácil de entender y manipular para los usuarios.

Las 12 Reglas (y la Regla 0) de Codd

Ante la aparición de sistemas que afirmaban ser relacionales pero no cumplían con los principios completos, Codd formalizó sus criterios en 1985. Estas reglas buscan garantizar que un Sistema Gestor de Bases de Datos Relacionales (SGBDR) sea verdaderamente relacional y mantenga la integridad de los datos.

Regla 0: La Regla Fundamental

Todo sistema que se defina como SGBDR debe poder gestionar la base de datos exclusivamente utilizando sus capacidades relacionales. Esto significa que no se deben necesitar interfaces no relacionales o de bajo nivel para realizar operaciones básicas.

Regla 1: La Regla de la Información

Toda la información en una base de datos relacional se representa de forma explícita a nivel lógico y de una única manera: mediante valores en tablas. Esto incluye tanto los datos de usuario como los metadatos (la descripción de la base de datos).

Regla 2: La Regla del Acceso Garantizado

Se garantiza que cada dato atómico (valor individual) es lógicamente accesible mediante una combinación del nombre de la tabla, el valor de la clave primaria de la fila y el nombre de la columna. No se requiere conocer la posición física o el orden de filas/columnas.

SELECT nombre FROM usuarios WHERE id_usuario = 15;

Este ejemplo muestra cómo se accede a un dato específico (el nombre) en una fila identificada por su clave primaria (id_usuario) dentro de una tabla (usuarios).

Regla 3: Tratamiento Sistemático de Valores Nulos

El SGBDR debe soportar y manejar de forma sistemática los valores nulos. Estos valores, distintos de ceros, espacios en blanco o cadenas vacías, se utilizan para representar información desconocida o inaplicable. El sistema debe permitir operar con ellos de forma lógica y coherente.

CREATE TABLE empleados ( id INT PRIMARY KEY, nombre VARCHAR(50), fecha_nacimiento DATE -- Puede contener valores NULL );

Regla 4: Catálogo Dinámico en Línea Basado en el Modelo Relacional

La descripción de la base de datos (metadatos o diccionario de datos) se debe almacenar de la misma manera que los datos normales (en tablas relacionales). Los usuarios autorizados pueden consultar estos metadatos utilizando el mismo lenguaje relacional que usan para los datos de usuario.

Esto permite consultar información sobre tablas, columnas, restricciones, etc., utilizando sentencias SQL estándar.

Regla 5: Regla Comprensiva del Sublenguaje de Datos Completo

Debe existir al menos un lenguaje relacional cuyas sentencias puedan expresarse como cadenas de caracteres y que soporte de forma completa la definición de datos (DDL), la definición de vistas, la manipulación de datos (DML), las restricciones de integridad y los límites de transacción (BEGIN, COMMIT, ROLLBACK). SQL es el ejemplo más conocido de dicho sublenguaje.

SELECT nombre, departamento_id FROM usuarios WHERE departamento_id = 5;

Este tipo de consulta, junto con INSERT, UPDATE, DELETE, CREATE TABLE, ALTER TABLE, etc., demuestra la capacidad de un lenguaje relacional completo.

Regla 6: Regla de Actualización de Vistas

Todas las vistas que sean teóricamente actualizables deben ser actualizables por el sistema. Si una vista representa un subconjunto directo de datos de una tabla base o una combinación simple, los cambios realizados en la vista deberían reflejarse correctamente en las tablas base subyacentes.

UPDATE departamentos SET nombre = 'Marketing Digital' WHERE id_departamento = 5;

Si 'departamentos' fuera una vista simple sobre una tabla base, esta operación debería ser posible.

Regla 7: Alto Nivel de Inserción, Actualización y Eliminación

Las operaciones de inserción, actualización y eliminación de datos deben poder realizarse sobre conjuntos de filas (tuplas) a la vez, no solo registro por registro. Los lenguajes relacionales (DML) operan sobre conjuntos, lo que simplifica y potencia la manipulación de datos a gran escala.

INSERT INTO usuarios (id, nombre, departamento) VALUES (101, 'Juan', 'Ventas'), (102, 'María', 'Marketing'); UPDATE usuarios SET departamento = 'Recursos Humanos' WHERE id IN (101, 102); DELETE FROM usuarios WHERE id = 103;

Estas sentencias manipulan múltiples registros con una sola instrucción.

Regla 8: Independencia Física de los Datos

Los cambios en la forma en que se almacenan físicamente los datos (métodos de acceso, estructuras de almacenamiento, etc.) no deben requerir cambios en los esquemas lógicos o en los programas de aplicación. La abstracción relacional oculta estos detalles al usuario y a las aplicaciones.

ALTER TABLE usuarios ADD COLUMN email VARCHAR(100);

Añadir una columna o cambiar un índice físico no debería romper las aplicaciones existentes que no usan esa nueva columna.

Regla 9: Independencia Lógica de los Datos

Los cambios en la estructura lógica de las tablas base (como añadir o eliminar columnas que pueden derivarse de otras, o dividir tablas) no deben requerir cambios en los programas de aplicación, siempre y cuando la información que usan las aplicaciones siga estando disponible.

ALTER TABLE usuarios ADD COLUMN fecha_contratacion DATE;

Similar a la independencia física, añadir una columna opcional no debería afectar las aplicaciones que no la necesitan.

Regla 10: Independencia de la Integridad

Las reglas de integridad específicas de la base de datos (restricciones, validaciones) deben definirse en el lenguaje relacional y almacenarse en el catálogo (diccionario de datos), no en los programas de aplicación. Esto garantiza que las reglas se apliquen de forma consistente, independientemente de cómo se acceda a los datos.

ALTER TABLE usuarios ADD CONSTRAINT ck_edad_legal CHECK (edad >= 18);

Esta regla de validación se aplica a todas las operaciones de inserción o actualización, independientemente de la aplicación que las realice.

Regla 11: Independencia de la Distribución

Si los datos de la base de datos están distribuidos físicamente en diferentes ubicaciones, esta distribución debe ser transparente para el usuario final y las aplicaciones. Los usuarios deben poder interactuar con la base de datos distribuida como si estuviera en un único lugar centralizado.

SELECT * FROM usuarios@servidor_remoto WHERE departamento_id = 5;

Una consulta puede acceder a datos distribuidos sin que el usuario necesite saber dónde residen físicamente.

Regla 12: La Regla de la No Subversión

Si el sistema relacional proporciona una interfaz de bajo nivel (por ejemplo, un lenguaje procedimental registro a registro), esta interfaz no debe permitir eludir o subvertir las reglas de integridad o seguridad definidas a través del lenguaje relacional de alto nivel. No se debe poder violar las restricciones relacionales accediendo a los datos por una puerta trasera de bajo nivel.

DELETE FROM usuarios WHERE edad < 25;

Incluso usando un lenguaje procedimental avanzado, esta operación debe respetar cualquier restricción de integridad o seguridad definida para la tabla 'usuarios'.

Estructura y Conceptos Clave en Bases de Datos Relacionales

El modelo relacional se fundamenta en conceptos bien definidos:

Relación o Tabla

Como se mencionó, la tabla es la representación visual de una relación. Contiene filas (tuplas) y columnas (atributos). El orden de filas y columnas no es significativo. Cada celda (intersección de fila y columna) contiene un único valor atómico.

Una tabla debe tener un nombre único dentro de la base de datos. Cada atributo tiene un nombre único dentro de su tabla.

Tupla

Cada fila en una tabla. Representa un objeto o entidad del mundo real. Una característica fundamental es que no puede haber dos tuplas idénticas en una tabla.

Dominio

El conjunto de todos los posibles valores que puede tomar un atributo. Va más allá del tipo de dato (entero, texto, fecha) e impone restricciones adicionales basadas en el significado del atributo (ej: edades entre 16 y 65, códigos de país válidos). Los dominios pueden definirse por intensión (una regla) o extensión (una lista de valores).

Grado y Cardinalidad

El grado de una relación es el número de atributos (columnas). La cardinalidad es el número de tuplas (filas). El grado es relativamente fijo, mientras que la cardinalidad varía constantemente a medida que se añaden o eliminan datos.

Sinónimos Terminológicos

Es común encontrar diferentes términos para los mismos conceptos en el mundo de las bases de datos. Aquí una tabla comparativa:

Los términos en negrita son los más utilizados hoy en día.

Tipos de Tablas

Principalmente se distinguen:

• Tablas Persistentes: Almacenan datos de forma permanente. Son la base del sistema. Se subdividen en:
  • Bases: Las tablas que almacenan los datos primarios.
  • Vistas: Tablas virtuales definidas por una consulta. No almacenan datos por sí mismas, sino la definición de cómo recuperarlos de tablas base.
  • Instantáneas (o Vistas Materializadas): Almacenan tanto la consulta como una copia de los datos resultantes. Son más rápidas de consultar que las vistas, pero sus datos pueden no estar completamente actualizados.
• Tablas Temporales: Creadas por el sistema o el usuario para uso temporal (ej: resultados intermedios de consultas). Se eliminan automáticamente al finalizar la sesión o la transacción.

Claves

Las claves son esenciales para identificar tuplas y establecer relaciones:

• Clave Candidata: Un conjunto mínimo de atributos que identifica de forma única cada tupla en una tabla. Una tabla puede tener varias claves candidatas.
• Clave Primaria (Primary Key): Una clave candidata elegida para ser el identificador principal de la tabla. Sus valores no pueden ser nulos ni repetirse (restricción UNIQUE y NOT NULL implícita).
• Clave Alternativa: Cualquier clave candidata que no fue elegida como clave primaria. Deben cumplir las restricciones UNIQUE y NOT NULL.
• Clave Externa, Ajena o Secundaria (Foreign Key): Un atributo o conjunto de atributos en una tabla cuyos valores coinciden con los valores de la clave primaria (o candidata) en otra tabla (o en la misma tabla). Establecen relaciones entre tablas y son la base de la integridad referencial.

La integridad referencial (Regla 12 de Codd en versiones posteriores, aunque la regla 10 ya hablaba de integridad) es vital: una clave externa solo puede contener valores que existan como clave primaria en la tabla referenciada, o bien ser nula. Esto asegura que las relaciones entre datos sean válidas. Las políticas de actualización y eliminación (CASCADE, SET NULL, NO ACTION, SET DEFAULT) sobre claves primarias relacionadas gestionan cómo reacciona el sistema ante cambios que afectarían las claves externas.

Restricciones

Las restricciones son reglas que los datos deben cumplir para ser considerados válidos:

• Inherententes: Propiedades intrínsecas del modelo relacional (tuplas únicas, orden irrelevante, valores atómicos).
• Semánticas: Reglas específicas definidas por el diseñador de la base de datos para asegurar la coherencia y validez de los datos. Incluyen:
  • Restricción de Clave Principal (Primary Key): Asegura unicidad y no nulidad del identificador principal.
  • Restricción de Unicidad (Unique): Impide valores duplicados en uno o más atributos (permite nulos, a diferencia de la clave primaria).
  • Obligatoriedad (Not Null): Impide que un atributo contenga el valor nulo.
  • Integridad Referencial (Foreign Key): Mantiene la coherencia entre tablas relacionadas mediante claves externas.
  • Regla de Validación (Check): Impone una condición lógica que los valores de uno o más atributos deben cumplir (ej: edad > 18, salario > 0).
  • Disparadores (Triggers): Código que se ejecuta automáticamente en respuesta a eventos específicos (INSERT, UPDATE, DELETE) para hacer cumplir reglas de integridad más complejas o realizar acciones automáticas.

Cumplimiento y Relevancia Actual

Codd publicó sus reglas en un momento de transición para asegurar que el modelo relacional no se diluyera. Si bien pocos SGBDR comerciales cumplen estrictamente con las 12 reglas en su totalidad, los sistemas líderes se adhieren a la gran mayoría de ellas. Las reglas sirvieron como una guía y un ideal para el desarrollo de SGBDR robustos y coherentes.

Aunque en los últimos años han surgido alternativas como las bases de datos NoSQL para abordar necesidades específicas (escalabilidad masiva, datos no estructurados), el modelo relacional y sus principios, encapsulados en las reglas de Codd, siguen siendo fundamentales y dominantes en la gestión de datos estructurados, especialmente donde la integridad y las transacciones complejas son críticas.

Preguntas Frecuentes sobre las Reglas de Codd

¿Por qué son 12 reglas si a menudo se mencionan 13 (Regla 0 a 12)?
Originalmente, Codd definió 12 reglas principales. Posteriormente, se añadió la Regla 0 como un preámbulo o requisito fundamental que todo sistema relacional debe cumplir: la gestión exclusiva a través de sus capacidades relacionales.

¿Algún SGBDR comercial cumple todas las reglas de Codd?
Es muy difícil encontrar un sistema que cumpla al pie de la letra con todas y cada una de las reglas, especialmente las reglas 6 (actualización de vistas universal) y 12 (no subversión total). Sin embargo, los principales SGBDR como Oracle Database, Microsoft SQL Server, PostgreSQL, etc., cumplen con la gran mayoría de ellas y son considerados sistemas relacionales.

¿Cuál es la regla más importante?
Varias reglas son consideradas críticas para la esencia del modelo relacional, como la Regla 1 (Información en tablas), la Regla 2 (Acceso Garantizado), la Regla 3 (Tratamiento de Nulos) y la Regla 10 (Independencia de la Integridad). La Regla 0 es fundamental para la definición misma de un sistema relacional.

¿Cómo se relacionan las reglas de Codd con la normalización de bases de datos?
Las reglas de Codd establecen los principios de un SGBDR. La normalización es un proceso de diseño de la estructura de la base de datos (las tablas y sus atributos) para reducir la redundancia y mejorar la integridad, basándose en la teoría relacional. Un SGBDR que cumple las reglas de Codd proporciona las herramientas y la base para implementar diseños normalizados.

¿Son las reglas de Codd todavía relevantes con la llegada de NoSQL?
Sí, son muy relevantes. Aunque las bases de datos NoSQL abordan diferentes problemas y no se basan en el modelo relacional, las reglas de Codd siguen siendo el estándar de oro para las bases de datos relacionales, que son indispensables para muchas aplicaciones que requieren integridad, transacciones ACID y consultas complejas sobre datos estructurados.

Si quieres conocer otros artículos parecidos a Las 12 Reglas de Codd para Bases Relacionales puedes visitar la categoría Bases de datos.