12 Reglas de Codd para una RDBMS

Aunque la mayoría de nosotros pensamos que cualquier base de datos compatible con SQL se
considera automáticamente una base de datos relacional, esto no siempre es así, al menos no
completamente. En el capítulo 1, se discutieron los conceptos básicos y fundamentos de la teoría
relacional, pero ninguna discusión sobre este tema estaría completa sin tener en cuenta las normas que se
formularon en 1985 en un artículo de dos partes publicado por la revista Computerworld ("¿Es realmente
su DBMS relacional? "y" ¿Su DBMS ejecuta estas reglas? "por E.F. Codd, Computerworld, 14 de octubre y
21 de octubre de 1985). Muchos sitios web quedaron fuera de la línea de estas normas. Estas normas van
más allá de la teoría relacional y define criterios más específicos que deben ser atendidas en un RDBMS, si
es para ser verdaderamente relacional.

Puede parecer una noticia vieja, pero los mismos criterios todavía se pueden utilizar hoy para
medir las relaciones internacionales en una base de datos. Estas reglas son con frecuencia presentadas en
las conversaciones cuando se habla de lo bien que un servidor de base de datos concreto se lleva a cabo.
Les presento las reglas de este apéndice, junto con breves comentarios acerca de si SQL Server 2008
cumple con cada uno de ellos, o de otra manera. La teoría relacional ha recorrido un largo camino desde
que estas reglas se publicaron por primera vez, y "serios" teóricos han mejorado y perfeccionado la teoría
relacional enormemente desde entonces, como era de esperar. Un buen lugar para un aprendizaje más
grave es la página web http://www.dbdebunk.com, dirigido por C.J. Date y Fabian Pascal, o cualquiera de
sus libros. Si desea ver los debates en la teoría, el grupo de noticias de la comp.databases.theory es un
lugar realmente interesante. Por supuesto, como la portada de este libro dice, mi objetivo es el sentido
práctico, con una base en la teoría, por lo que no voy a profundizar demasiado en la teoría aquí en
absoluto. Presento a estas 12 reglas, simplemente para establecer una base para lo que es una base de
datos relacional que comenzó a ser y en gran medida lo que es y lo que debe ser hoy en día.

Todas estas normas se basan en lo que se refiere a veces como el principio fundamental
(Regla Cero), que establece que para cualquier sistema que se llama un sistema de gestión de base de
datos relacional, la capacidad relacional debe ser capaz de gestionarla por completo.

Para el resto de este apéndice, voy a tratar de SQL Server 2008 específicamente como un motor
de base de datos relacional, no en cualquiera de las demás formaciones en las que podría ser utilizado,
tales como un almacén de datos normal, un dispositivo de almacenamiento de documentos, o cualquier
otro forma en que puede utilizar SQL Server como motor de almacenamiento.
1.- REGLA DE LA INFORMACIÓN
Toda la información en la base de datos relacional se representa exactamente de una y sólo una
manera como valores en las tablas.

Esta norma constituye una definición informal de una base de datos relacional e indica que cada
pieza de datos que almacena de forma permanente en una base de datos se encuentra en una tabla.

En general, SQL Server cumple con esta regla, porque no podemos almacenar cualquier
información en otra cosa que no sea una tabla. No podemos usar las variables en el código de persistir los
datos, y por lo tanto son de ámbito de un solo lote.

2.- REGLA DEL ACCESO GARANTIZADO

Todos y cada uno de los datos (valor atómico) se garantizan que sean lógicamente accesibles
recurriendo a una combinación de nombre de la tabla, el valor de clave principal, y el nombre de la
columna.

Esta norma hace hincapié en la importancia de las claves principales para la localización de datos
en la base de datos. El nombre de la tabla localiza la tabla correcta, el nombre de la columna encuentra la
columna correcta, y el valor de clave primaria encuentra la fila que contiene un elemento de información
de interés. En otras palabras, cada pieza (número atómico) de los datos es accesible por la combinación de
nombre de la tabla, el valor de clave principal, y el nombre de la columna. Esta norma, especifica
exactamente la forma en que los datos de acceso que utilicen un lenguaje como el acceso de Transact-SQL
(T-SQL) en SQL Server.

Usando SQL, podemos buscar el valor de clave principal (que se garantiza que sea único, basado
en la teoría relacional, siempre y cuando se ha definido), y una vez que tenemos la fila, los datos se
acceden a través del nombre de la columna. También podemos acceder a los datos por cualquiera de las
columnas de la tabla, aunque no siempre son garantía de recibir una sola fila de nuevo.

3.- REGLA DEL TRATAMIENTO SISTEMÁTICO DE VALORES

NULOS
Los valores NULL (distinta de la cadena de caracteres vacía o una cadena de caracteres en blanco
y distinta de cero o cualquier otro número) son compatibles con el RDBMS completamente relacional para
representar la información que falta en una forma sistemática independiente del tipo de datos.

Esta norma requiere que el RDBMS admita distintas posiciones de marcación NULL
independientemente del tipo de datos. Los NULL son distintos de una cadena de caracteres vacía o
cualquier otro número, y siempre deben considerarse como valores desconocidos.
 Los NULL se deben propagar a través de operaciones matemáticas, así como operaciones de
cadenas. NULL + <anything> = NULL, la lógica es que NULL significa "desconocido". Si se agrega algo
conocido a algo desconocido, que aún no sabe lo que tiene, por lo que es aún desconocido.

Hay algunas opciones de configuración de SQL Server que pueden personalizar la forma en que
los valores NULL son tratados. La mayoría de estas opciones existen a causa de algunas malas prácticas que
se permitió en las primeras versiones de SQL Server:

• ANSI_NULLS:
Determina cómo se manejan las comparaciones NULL. Cuando es OFF, NULL = NULL es True para
la comparación, y cuando está en ON (por defecto), NULL = NULL devuelve UNKNOWN.
• CONCAT_NULL_YIELDS_NULL:
Cuando el ajuste de CONCAT_NULL_YIELDS_NULL se establece en ON, los valores NULL son
tratados adecuadamente, de modo que NULL + "String value' = NULL.
Cuando el ajuste de CONCAT_NULL_YIELDS_NULL se establece en OFF, que se permite por
compatibilidad con SQL Server, los valores NULL son tratados de una manera no estándar, tales
que NULL + ‘String value' = 'String value’.

4.- REGLA DEL CATÁLOGO DINÁMICO EN LÍNEA BASADO

EN EL MODELO RELACIONAL
La descripción de base de datos está representada en el nivel lógico de la misma manera como los
datos ordinarios, para que los usuarios autorizados puedan aplicar el mismo lenguaje relacional a las
interrogantes que se aplican a los datos regulares.

Esta norma requiere que una base de datos relacional se describa a sí misma. En otras palabras,
la base de datos debe contener ciertas tablas cuyo sistema de columnas describan la estructura de la base
de datos en sí, o, alternativamente, la descripción de base de datos está contenida en los cuadros
accesibles para el usuario.

Esta regla se está convirtiendo en una realidad en cada nueva versión de SQL Server, al igual que
con la aplicación de las vistas del sistema INFORMATION_SCHEMA. El INFORMATION_SCHEMA es un
esquema que tiene un conjunto de puntos de vista para mirar la mayor parte de los metadatos en las
tablas, las relaciones, las limitaciones, e incluso el código en la base de datos.

Cualquier otra cosa que usted necesite saber, las podrá ver en las vistas del sistema (en el
esquema SYS). Son los puntos de vista del sistema que sustituye las tablas del sistema en 2005 que había
utilizado desde el principio de los tiempos de SQL Server. Estos puntos de vista son mucho más fáciles de
leer y usar, y la mayoría de todos los datos se explican por sí mismos, en lugar de requerir operaciones bit a
bit en algunas columnas para encontrar el valor.
5.- REGLA DEL SUBLENGUAJE DE DATO COMPLETO
Un sistema relacional puede soportar varios lenguajes y varios modos de uso de terminales. Sin
embargo, debe haber al menos una lengua cuyas declaraciones se pueden expresar, por una sintaxis bien
definida, como cadenas de caracteres y cuya capacidad de soportar todo lo siguiente es comprensible: a.
definición de datos, b. definición de la vista, c. manipulación de datos (interactiva y por programa), d.
restricciones de integridad, e. autorización, f. límites de la transacción (inicio, commit y rollback).

Ello exige la regla de la existencia de un lenguaje de base de datos relacional -como SQL- para
manipular los datos. SQL como tal, no lo requiere específicamente. El lenguaje debe ser capaz de soportar
todas las funciones principales de un DBMS: la creación de una base de datos, la recuperación y la
introducción de datos, implementación de seguridad de base de datos, y así sucesivamente. T-SQL cumple
esta función de SQL Server y realiza todas las tareas de definición y manipulación de datos necesario para
acceder a los datos.

SQL es un lenguaje no procedimental, ya que no especifica "cómo" suceden las cosas, u otros
casos. Simplemente se formula una pregunta al servidor relacional, y se hace el trabajo.

6.- REGLA DE LA ACTUALIZACIÓN DE VISTAS

Todas las vistas que son teóricamente actualizables son también actualizables por el sistema.

Las vistas son tablas virtuales utilizadas para dar distintos usuarios a una base de datos de
diferentes puntos de vista de su estructura. Es una de las reglas más difíciles de aplicar en la práctica, y no
todo producto comercial cumple en la actualidad.

Una vista es teóricamente actualizable, siempre y cuando está hecha de columnas que
corresponden directamente a las columnas de la tabla real. En SQL Server, las vistas son actualizables,
siempre y cuando no se actualice más de una sola tabla en la declaración, ni se pueda actualizar un campo
derivado o constante. SQL Server 2000 implementó disparadores INSTEAD OF que se pueden aplicar a una
vista. Por lo tanto, esta regla puede técnicamente cumplir con los desencadenadores INSTEAD OF, pero en
lo que puede ser una manera menos sencilla. Tienes que tener cuidado al considerar la forma de aplicar las
actualizaciones, especialmente si la vista contiene una cláusula GROUP BY y, posiblemente, los agregados.
7.- REGLA DE LA INSERCIÓN, ACTUALIZACIÓN Y BORRADO
DE ALTO NIVEL
La capacidad de manejar una relación base o una relación derivada como un solo operando se
aplica no sólo a la recuperación de datos, sino también a la inserción, actualización y supresión de datos.

Esta norma hace hincapié en el carácter orientado a conjuntos de una base de datos relacional.
Se refiere a que las filas tratarán de establecer las operaciones de insertar, eliminar y actualización. La
norma tiene por objeto prohibir las implementaciones que sólo admiten una fila -a la vez- y la modificación
de navegación de la base de datos. El lenguaje SQL cubre esta regla a través de las instrucciones INSERT,
UPDATE y DELETE.

Incluso el CLR no le permite acceder a los archivos físicos donde se almacenan los datos, pero
BCP no tiene cómo ir alrededor de este. Como siempre, tienes que ser muy cuidadoso al utilizar las
herramientas de bajo nivel que pueden modificar los datos sin pasar por la típica sintaxis SQL, ya que
puede pasar por alto las reglas que se han establecido, al presentar inconsistencias en sus datos.

8.- REGLA DE LA INDEPENDENCIA FÍSICA DE LOS DATOS

Los programas de aplicación y actividades del terminal permanecen inalterados a nivel lógico
cada vez que se realicen cambios en cualquier representación de almacenamiento o métodos de acceso.

Las solicitudes aún deben trabajar con la misma sintaxis, incluso cuando se realizan cambios en la
forma en que implementa la base de datos de almacenamiento de datos interno y métodos de acceso. Esta
regla implica que la forma en que se almacenan físicamente los datos debe ser independiente de la forma
lógica en la que se accede a ella. Esto está diciendo que los usuarios no deben preocuparse acerca de cómo
se almacenan los datos o cómo es que se accedan. De hecho, los usuarios de los datos sólo deben ser
capaces de llegar a la definición básica que los datos necesitan.

Otras cosas que no debe afectar a la vista del usuario de los datos son los siguientes:

• Adición de índices: los índices determinan cómo se almacenan los datos, sin embargo, el
usuario, a través de SQL, nunca sabe que los índices se están utilizando.
• Cambiar el grupo de archivos de un objeto: el sólo mover una tabla a un nuevo grupo de
archivos no afectará a la solicitud. Para acceder a los datos, de igual forma no importa donde se
encuentre físicamente.
• En el particionado: Más allá de mover tablas enteras en torno a grupos de archivos diferentes,
las partes se pueden mover alrededor de una tabla mediante el uso de tecnologías de separación
para extender el acceso a todos los diferentes subsistemas independientes para mejorar el
rendimiento.
• Modificar el motor de almacenamiento: De vez en cuando, Microsoft tiene que modificar la
forma en que SQL Server opera (sobre todo en las actualizaciones de versión principal). Sin
embargo, las sentencias SQL parecen acceder a los datos de la misma manera como lo hicieron
en cualquier versión anterior, sólo que (parece) más rápido.
 Microsoft ha puesto mucho trabajo en esta área, ya que SQL Server tiene un motor
independiente relacional y, el motor de almacenamiento, y OLE DB se utilizan para pasar datos entre los
dos. Lea más sobre este en SQL Server 2008 Books Online in the “Database Engine Components” topic or in
Inside Microsoft SQL Server 2005:The Storage Engine byKalen Delaney (Microsoft Press, 2006).

9.- REGLA DE LA INDEPENDENCIA LÓGICA DE LOS DATOS

Los programas de aplicación y actividades del terminal permanecen inalterados a nivel lógico
cuando quiera que se realicen cambios a las tablas base que preserven la información

Junto con la regla 8, esta regla aísla el programa de usuario o la aplicación de la implementación
de bajo nivel de la base de datos. Juntos, precisan que el acceso o técnicas específicas de almacenamiento
utilizado por el RDBMS -e incluso los cambios en la estructura de las tablas de la base de datos- no deben
afectar a la capacidad del usuario para trabajar con los datos.
De esta forma, si agrega una columna a una tabla y si las tablas se dividen de una manera que no
añade ni resta columnas, a continuación, los programas de aplicación que llame a la base de datos deben
ser inalterables.

Por ejemplo, supongamos que tiene la tabla de la Figura A-1

Figura A-1 Una tabla pequeña.

Entonces usted decide dividirlas verticalmente en dos tablas (ver Figura A-2).

Figura A-2 Dividir una tabla pequeña en dos tablas.

A continuación puede crear esta imagen:

CREATE VIEW baseTable

AS
SELECT baseTableId, column1, column2
FROM baseTableA
JOIN baseTableB
ON baseTableA.baseTableId = baseTableB.baseTableId
 El usuario no debería verse afectado. Si se va a poner en práctica los desencadenadores INSTEAD
OF en la vista que tenía el mismo número de columnas con el mismo nombre, perfectamente podría
satisfacer la necesidad de gestionar la manera de manejar la forma exacta de la tabla. Tenga en cuenta que
el manejo de las columnas de identidad puede ser difícil en las vistas, ya que requieren datos a registrar,
incluso cuando los datos no serán utilizados. Véase el capítulo 6 para obtener más detalles sobre la
creación de desencadenadores INSTEAD OF.

Por supuesto, no siempre se puede trabajar con esta regla si las columnas o tablas se eliminan
del sistema, pero puede hacer que la regla funcione si las columnas y los datos son simplemente
agregados.
_______________________________________________________________________
TIP: Siempre dé acceso a datos de RDBMS por su nombre, y no por la posición o utilizando el
comodín *SELECT. Las columnas no deben hacer diferencia alguna en la aplicación.__________________

10.- REGLA DE LA INDEPENDENCIA DE INTEGRIDAD

Las restricciones de integridad específica a una base de datos relacional particular deben ser
definidos en el sublenguaje de datos relacional y almacenables en el catálogo, no en los programas de
aplicación.

La base de datos debe ser compatible con un mínimo de las restricciones de integridad
siguientes:

• La integridad de entidad: Ninguno de los componentes de una clave principal se le permite

tener un valor NULL.
• La integridad referencial: Para cada valor de la clave foránea distinto de NULL en una base de
datos relacional, debe existir una clave primaria correspondiente del mismo dominio.

Esta regla dice que el lenguaje de base de datos debe apoyar las restricciones de integridad que
restringen los datos que se pueden introducir en la base de datos y las modificaciones de base de datos
que se pueden hacer. En otras palabras, el RDBMS interno debe ser compatible con la definición y la
ejecución de la integridad de entidad (claves primarias) y la integridad referencial (claves foráneas).

Se requiere que la base de datos esté en condiciones de aplicar restricciones para proteger los
datos de los valores no válidos y que el diseño de base de datos segura es necesario para asegurar que la
integridad referencial se consigue. SQL Server 2008 hace un gran trabajo proporcionando las herramientas
para que esta norma sea una realidad. Podemos proteger nuestros datos de los valores inválidos para la
mayoría de cualquier caso posible con las limitaciones y los factores desencadenantes. La mayor parte del
capítulo 6 se gastó en abarcar los métodos que podemos utilizar en SQL Server para implementar la
integridad de la independencia.
11.- REGLA DE LA INDEPENDENCIA DE DISTRIBUCIÓN
El sublenguaje de manipulación de datos de un DBMS relacional debe permitir que los programas
de aplicación y las actividades de la terminal permanezcan lógicamente inalterables siempre y cuando los
datos estén físicamente centralizados o distribuidos.

Esta regla dice que el lenguaje de base de datos debe ser capaz de manipular los datos ubicados
en otros sistemas informáticos. En esencia, debemos ser capaces de dividir los datos del RDBMS en
múltiples sistemas físicos sin que el usuario pueda darse cuenta de ello. SQL Server 2008 admite
transacciones distribuidas entre las fuentes de SQL Server, así como otros tipos de fuentes utilizando el
servicio de Coordinación de Transacciones Distribuidas de Microsoft (MDTC).

Otra posibilidad de la independencia de distribución es un grupo de servidores de base de datos

que trabaja a más o menos como si fueran uno. Los servidores de bases de datos de trabajo en conjunto de
este tipo son considerados como federated (federados). Con cada versión nueva de SQL Server, el concepto
de compartir la carga sin problemas en servidores de base de datos federados se está convirtiendo en una
realidad definitiva.

12.- REGLA DE LA NO SUBERSIÓN

Si un sistema relacional tiene o es compatible con un lenguaje de bajo nivel (un solo registro a la
vez), ese lenguaje de bajo nivel no puede ser utilizado para subvertir o eludir las normas de integridad o
restricciones expresadas en el lenguaje relacional de más alto nivel (múltiples registros, a la vez).

Esta norma exige que los métodos alternativos de acceso a los datos, no sean capaces de eludir
las restricciones de integridad, lo que significa que los usuarios no puedan violar las reglas de la base de
datos de cualquier manera. Para la mayoría de aplicaciones de SQL Server 2008, esta regla se sigue, porque
no hay métodos para llegar a los datos en bruto ni cambar los otros valores previstos por los métodos de la
base de datos. Sin embargo, SQL Server 2008 viola esta regla en dos lugares:

• La copia masiva: De forma predeterminada, puede utilizar las rutinas de copia masiva para
insertar datos en la tabla directamente y alrededor de las validaciones de servidor de base de
datos.
• Desactivación de restricciones y disparadores: Hay sintaxis para deshabilitar las restricciones y
desencadenadores, pero no por subvertir esta regla.

Es siempre una buena práctica asegurarse de utilizar estos dos elementos con cuidado. Pues
dejan grandes agujeros en la integridad de sus datos, porque permiten que los valores sean insertados en
cualquier columna.

Debido a que usted está esperando los datos a ser protegidos por la restricción que ha aplicado,
los datos de valor de los errores pueden ocurrir en los programas que utilizan los datos, sin ser revalidados
primero.
Resumen
Las 12 reglas de Codd para Bases de Datos Relacionales pueden ser utilizadas para explicar
mucho acerca de cómo SQL Server opera en la actualidad. Estas reglas fueron un gran paso adelante para
determinar si un proveedor de bases de datos podría llamar a su sistema "relacional" y presentó grandes
desafíos para los desarrolladores de la aplicación de base de datos.

Quince años más tarde, incluso la aplicación de la más compleja de estas normas se está tratando
de lograr, a pesar de que SQL Server (y otros RDBMS) aún están lejos de alcanzar todos sus objetivos.

Traducido por Juan Carlos Romero Chero, alumno de IV ciclo de la escuela de Ingeniería de Software de la
Universidad Privada Antenor Orrego, Trujillo-Perú, 2011.