Reglas de Codd para bases de

datos relacionales

Bases de Datos I
René F. Navarro
Reglas de Codd
 Propuestas por Edgar F. Codd

2
Regla 1: Información
 Toda la información en una base de datos relacional se
representa explícitamente en el nivel lógico mediante
tablas y sólo mediante tablas.
◼ Por tanto, los metadatos (diccionario, catálogo) se representan y
se manipulan exactamente igual que los datos de usuario,
usando quizás el mismo lenguaje (ejemplo SQL).

3
Regla 1: Información
 Todos los datos deben estar almacenados en las tablas
 Esas tablas deben de cumplir las premisas del modelo
relacional
 No puede haber información a la que accedemos por otra
vía

4
5
6
Regla 2: Acceso garantizado
 Para todos y cada uno de los datos (valores atómicos) de
una base de datos relacional se garantiza que son
accesibles a nivel lógico utilizando una combinación de
nombre de tabla, valor de clave primaria y nombre de
columna.
◼ Cualquier dato almacenado en una base de datos relacional
tiene que poder ser direccionado unívocamente.
◼ Para ello hay que indicar en qué tabla está, cuál es la columna y
cuál es la fila (mediante la clave primaria).

7
Regla 2: Acceso garantizado
 Cualquier dato es accesible sabiendo la clave de su fila y
el nombre de su columna o atributo
 Por ejemplo el “Sánchez” es un dato al que podremos
acceder conociendo la clave de la persona en concreto y
usando el atributo “Primer apellido”
 Si a un dato no podemos acceder de esta forma, no
estamos usando un modelo relacional

8
Regla 3: Tratamiento sistemático de los
valores nulos
 Se debe disponer de valores nulos (distintos de la cadena
vacía, blancos, 0, etc.) para representar información
desconocida o no aplicable de manera sistemática,
independientemente del tipo de datos.

9
Regla 3: Tratamiento sistemático de los
valores nulos
 Esos valores pueden dar significado a la columna que los
contiene (una persona sin teléfono, tendrá valor nulo en el
teléfono)
 El SGBD tiene que tener la capacidad de manejar valores
nulos
 El SGBD reconocerá este valor como un valor distinto de
cualquier otro
 El SGBD sabrá aplicarle la lógica apropiada
 Es un valor independiente del tipo de datos de la columna
10
Regla 4: Catalogo dinámico en línea basado en
modelo relacional
 La descripción de la base de datos se representa a nivel
lógico de la misma manera que los datos normales, de
modo que los usuarios autorizados pueden aplicar el
mismo lenguaje relacional a su consulta, igual que lo
aplican a los datos normales.

11
Regla 4: Catalogo dinámico en línea basado en
modelo relacional
 El catálogo en línea es el diccionario de datos
 El diccionario de datos se debe de poder consultar usando
las mismas técnicas que para los datos
 Los metadatos, por tanto, se organizan también en tablas
relacionales
 Si SELECT es la instrucción que consulta datos, también
será la que consulta los metadatos

12
Regla 5: Sublenguaje de datos completo
 Un sistema relacional debe soportar varios lenguajes y varios
modos de uso de terminal (e.g. llenar formularios, etc.). Sin
embargo, debe existir al menos un lenguaje cuyas sentencias
sean expresables, mediante una sintaxis bien definida, como
cadenas de caracteres y que sea completo, soportando:
◼ Definición de datos, definición de vistas, manipulación de datos
(interactiva y por programa), restricciones de integridad, restricciones
de transacciones (begin, commit, rollback).

13
Regla 5: Sublenguaje de datos completo
 Al menos tiene que existir un lenguaje capaz de hacer todas
las funciones del SGBD
 No puede haber funciones fuera de ese lenguaje
 Puede haber otros lenguajes en el SGBD para hacer ciertas
tareas
 Pero esas tareas también se deben poder hacer con el
“lenguaje completo”

14
Regla 6: Actualización de vistas
 Todas las vistas que son teóricamente actualizables se
pueden actualizar también por el sistema.
◼ El problema es determinar cuáles son las vistas
teóricamente actualizables, ya que no está muy claro.
◼ Cada sistema puede hacer unas suposiciones particulares
sobre las vistas que son actualizables.

15
Regla 6: Actualización de vistas
 Las vistas tienen que mostrar información actualizada
 No puede haber diferencia entre los datos de las vistas
y los datos de las tablas base

16
Regla 7: Inserción, actualización y borrado de
alto nivel
 La capacidad de manejar una relación base o derivada como
un solo operando se aplica no sólo a la recuperación de los
datos (consultas), sino también a la inserción, actualización y
borrado de datos.
◼ Esto es, el lenguaje de manejo de datos también debe ser de alto
nivel (de conjuntos).
◼ Algunos sistemas de bases de datos inicialmente sólo podían
modificar las filas de una tabla de una en una (un registro de cada
vez).

17
Regla 7: Inserción, actualización y borrado de
alto nivel
 La idea es que el lenguaje que maneja la BD sea muy
amigable
 Eso implica que las operaciones DML trabajen con
conjuntos de filas a la vez
 Para modificar, eliminar o añadir datos no hará falta
programar de la forma en la que lo hacen los lenguajes de
tercera generación como C o Java

18
Regla 8: Independencia física de datos
 Los programas de aplicación y actividades del terminal
permanecen inalterados a nivel lógico cualesquiera
sean los cambios efectuados, tanto en la
representación del almacenamiento, como en los
métodos de acceso.
◼ El modelo relacional es un modelo lógico de datos, y oculta
las características de su representación física.

19
Regla 8: Independencia física de datos
 Cambios en la física de la BD no afecta a las aplicaciones
ni a los esquemas lógicos
 El acceso a las tablas (elemento lógico) no cambia porque
la física de la base de datos cambie

20
Regla 9: Independencia lógica de los datos
 Los programas de aplicación y actividades en terminal
permanecen inalterados a nivel lógico cualesquiera sean los
cambios que se realicen a las tablas base que preserven la
información.
◼ Cuando se modifica el esquema lógico preservando información (no
valdría por ejemplo, eliminar un atributo) no es necesario modificar
nada en niveles superiores.
◼ Ejemplos de cambios que preservan la información:
 Añadir un atributo a una tabla base.
 Sustituir dos tablas base por la unión de las mismas. Usando vistas
de la unión se pueden recrear las tablas anteriores. 21
Regla 9: Independencia lógica de los datos
 Cambios en el esquema lógico (tablas) de la BD no
afectan al resto de esquemas
 Si cambiamos nombres de tabla, o de columna o
modificamos información de las filas, las aplicaciones
(esquema externo) no se ven afectadas
 Es más difícil de conseguir

22
Regla 10: Independencia de integridad
 Los restricciones de integridad específicas para una
determinada base de datos relacional deben poder ser
definidos en el sublenguaje de datos relacional, y
almacenables en el catálogo, no en los programas de
aplicación.
◼ El objetivo de las bases de datos no es sólo almacenar los datos, sino
también sus relaciones y evitar que estas restricciones se codifiquen
en los programas.
◼ Por tanto en una base de datos relacional se deben poder definir
restricciones de integridad.
23
Regla 10: Independencia de integridad
 Las reglas de integridad (restricciones) deben de ser gestionadas y
almacenadas por el SGBD

24
Regla 11: Independencia de distribución
 Una Base de Datos Relacional es independencia de la
distribución.
◼ Las mismas órdenes y programas se ejecutan igual en una base de
datos centralizada que en una distribuida.
◼ Las bases de datos son fácilmente distribuibles.
◼ Esta regla es responsable de tres tipos de transparencia de
distribución:
 Transparencia de Localización. El usuario tiene la impresión de que trabaja con una base de datos local. (Regla
de Independencia Física)
 Transparencia de Fragmentación: El usuario no se da cuenta de que la relación con que trabaja está fragmentada.
(Regla de Independencia Lógica).
 Transparencia de Replicación: El usuario no se da cuenta de que pueden existir copias (réplicas) de una misma
relación en diferentes lugares.

25
Regla 11: Independencia de distribución
 Que la base de datos se almacene o gestione de forma
distribuida en varios servidores, no afecta al uso de la
misma ni a la programación de las aplicaciones de usuario
 El esquema lógico es el mismo independientemente de si
la BD es distribuida o no

26
Regla 12: No subversión
 Si un sistema relacional tiene un lenguaje de bajo nivel (un
registro a la vez), ese bajo nivel no puede ser usado para
subvertir (saltarse) las reglas de integridad y las restricciones
expresadas en los lenguajes relacionales de más alto nivel
(una relación a la cada vez).
◼ Algunos problemas no se pueden solucionar directamente con el
lenguaje de alto nivel.
◼ Normalmente se usa SQL incorporado en un lenguaje anfitrión para
solucionar estos problemas. Se utiliza el concepto de cursor para
tratar individualmente las filas de una tabla. En cualquier caso no debe
ser posible saltarse las restricciones de integridad impuestos al tratar
27
las filas a ese nivel.
Regla 12: No subversión
 La base de datos no permitirá que exista un lenguaje o forma
de acceso, que permita saltarse las reglas anteriores

28