[3.1] el modelo relacional

[3.1.1]introducción

Durante los primeros años de las bases de datos, se utilizó el modelo jerárquico como la primera forma de describir de forma más humana una base de datos. Después reinó el modelo en red especialmente en su norma Codasyl. Así a principios de los 70 parecía que el modelo a aplicar al implementar bases de datos sería Codasyl y lo sería por muchos años.

Sin embargo, Edgar Frank Codd definió las bases del modelo relacional a finales de los 60. En 1970 publica el documento “A Relational Model of data for Large Shared Data Banks” (“Un modelo relacional de datos para grandes bancos de datos compartidos”). Actualmente se considera que ese es uno de los documentos más influyentes de toda la historia de la informática. Lo es porque en él se definieron las bases del llamado Modelo Relacional de Bases de Datos. Anteriormente el único modelo teórico estandarizado era el modelo Codasyl que se utilizó masivamente en los años 70 como paradigma del modelo en red de bases de datos.

Codd se apoya en los trabajos de los matemáticos Cantor y Childs (cuya teoría de conjuntos es la verdadera base del modelo relacional). Según Codd, los datos se agrupan en relaciones (actualmente llamadas tablas), las cuales son una estructura que aglutina datos referidos a una misma entidad de forma organizada. Las relaciones, además, estructuran los datos de forma independiente respecto a su almacenamiento real en la computadora. Es decir, es un elemento conceptual, no físico.

Lo que Codd intentaba fundamentalmente es evitar que las usuarias y usuarios de la base de datos tuvieran que verse obligadas a aprender los entresijos internos del sistema. Esto es lo que ocurría con el modelo en red, dominante cuando Codd diseñó el modelo relacional, que era bastante físico. Su enfoque fue revolucionario al evitar conceptos del mundo de la computación en su modelo.

Aunque trabajaba para IBM, esta empresa no recibió de buen grado sus teorías. De hecho, IBM continuó trabajando en su sistema gestor de bases de datos en red IMS. Fueron otras empresas (en especial Oracle) las que implementaron sus teorías.

Pocos años después, el modelo se empezó a utilizar cada vez más hasta, finalmente, ser el modelo de bases de datos más popular. Hoy en día casi todas las bases de datos siguen este modelo, aunque en estos años han aparecido rivales cada vez más fuertes en las llamadas bases de datos NoSQL, que han demostrado un gran eficacia en bases de datos que necesitan una enorme cantidad de instrucciones de modificación por minuto.

[3.1.2]objetivos del modelo

Codd perseguía estos objetivos con su modelo relacional:

• Independencia física. La forma de almacenar los datos, debe ser absolutamente independiente del modelo conceptual de los mismos. Si la forma de almacenar los datos cambia (si cambia el esquema físico) , no es necesario cambiar los esquemas lógicos, funcionan perfectamente. Esto permite que los usuarios y usuarias se concentren en qué resultados desean obtener de la base de datos independientemente de cómo estén realmente almacenados los datos.
• Independencia lógica. Se refiere a que la lógica de la base de datos debe de ser independiente de la forma externa de acceso a la base de datos (los esquemas externos). Las aplicaciones que utilizan la base de datos no deben ser modificadas porque se modifique el esquema lógico de la misma. De una manera más precisa: gracias a esta independencia el esquema externo de la base de datos es realmente independiente del modelo lógico. En la práctica, esta independencia es difícil de conseguir.
• Flexibilidad. La base de datos ofrece fácilmente distintas vistas en función de los usuarios y aplicaciones. La visión de los datos se adapta al usuario que los requiere.
• Uniformidad. Las estructuras lógicas siempre tienen una única forma lógica (las tablas). Es decir, manejar el modelo relacional es manejar las tablas.
• Sencillez. Facilidad de manejo (algo cuestionable, pero ciertamente verdadero si comparamos con los sistemas gestores de bases de datos anteriores a este modelo).>

[3.1.3]historia del modelo relacional

Año	Hecho
1970	Codd publica las bases del modelo relacional
1971-72	Primeros desarrollos teóricos
1973-78	Primeros prototipos de base de datos relacional. Son el System R de IBM. En ese sistema se desarrolla Sequel que con el tiempo cambiará su nombre a SQL.
1974	La Universidad de Berkeley desarrolla Ingres, SGBD relacional basado en cálculo relacional. Utilizaba el lenguaje Quel desarrollado en las universidades y muy popular en la época en ámbitos académicos.
1978	Aparece el lenguaje QBE (Query By Example) lenguaje de acceso relacional a los archivos VSAM de IBM
1979	Aparece Oracle, el primer SGBD comercial relacional (ganando en unas semanas al System/38 de IBM). Implementa SQL y se convertirá en el sistema gestor de bases de datos relacionales líder del mercado. Codd revisa su modelo relacional y lanza el modelo RM/T como un intento de subsanar sus deficiencias.
1981	Aparece Informix como SGBD relacional para Unix
1983	Aparece DB2, el sistema gestor de bases de datos relacionales de IBM
1984	Aparece la base de datos Sybase que llegó a ser la segunda más popular (tras Oracle)
1986	ANSI normaliza el SQL (SQL/ANSI). SQL es ya de hecho el lenguaje principal de gestión de bases de datos relacionales.
1987	ISO también normaliza SQL. Es el SQL ISO(9075)
1988	La versión 6 de Oracle incorpora el lenguaje procedimental PL/SQL
1989	ISO revisa el estándar y publica el estándar SQL Addendum. Microsoft y Sybase desarrollan SQL Server para el sistema operativo OS/2 de Microsoft e IBM. Durante años Sybase y SQL Server fueron el mismo producto.
1990	Versión dos del modelo relacional (RM/V2) realizada por Codd. Propuesta de Michael Stonebraker para añadir al modelo relacional capacidades de orientación a objetos.
1992	ISO publica el estándar SQL 92 (todavía el más utilizado)
1995	Manifiesto de Darwen y Date en el que animan a reinterpretar el modelo relacional desde una perspectiva de objetos. Aparece el modelo objeto/relacional. Aparece MySQL una base de datos relacional de código abierto con licencia GNU que se hace muy popular entre los desarrolladores de páginas web.
1996	ANSI normaliza el lenguaje procedimental basado en SQL y lo llaman SQL/PSM. Permite técnicas propias de los lenguajes de programación estructurada. Aparece el SGBD abierto PostgreSQL como remodelación de la antigua Ingres, utilizando de forma nativa el lenguaje SQL (en lugar de Quel).
1999	ISO publica un nuevo estándar que incluye características más avanzadas. Se llama SQL 99 (también se le conoce como SQL 2000)
2000	Richard Hipp diseña SQLite base de datos relacional que ocupa muy poco, pero que ofrece prestaciones propias de sistemas más grandes. Es muy utilizada en aplicaciones, especialmente en los dispositivos móviles.
2003	ISO publica el estándar SQL 2003. En él se añade SQL/PSM al estándar.
2006	Estándar ISO. SQL 2006
2008	Estándar ISO. SQL 2008
2011	Estándar ISO. SQL 2011

[3.2] estructura de las bases de datos relacionales

[3.2.1]relación o tabla

Según el modelo relacional (desde que Codd lo enunció) el elemento fundamental del modelo es lo que se conoce como relación, aunque más habitualmente se le llama tabla (o también array o matriz). Codd definió el significado de las relaciones utilizando un lenguaje matemático. Para comprender visualmente este concepto siempre se han utilizado las tablas, ya que permiten representar la información de las relaciones en forma de filas y columnas.

No hay que confundir la idea de relación según el modelo de Codd, con lo que significa una relación en el modelo Entidad/Relación de Chen. No tienen nada que ver

Las relaciones constan de:

• Atributos. Es cada una de las propiedades de los datos de la relación (nombre, dni,...). Las relaciones representan conjuntos de objetos o elementos reales, cada atributo es propiedad o característica de dicho elemento.
• Tuplas. Referido a cada ejemplar, objeto o elemento de la relación. Por ejemplo si una relación almacena personas, una tupla representaría a una persona en concreto.

Puesto que una relación se representa como una tabla; podemos entender que las columnas de la tabla son los atributos; y las filas, las tuplas.

	atributo 1	atributo 2	atributo 3	atributo 4
valor 1,1	valor 1,2	valor 1,3	....	valor 1,n	<- tupla 1
valor 2,1	valor 2,2	valor 2,3	....	valor 2,n	<- tupla 2
.....	.....	......	....	.....	....
valor m,1	valor m,2	valor m,3	....	valor m,n	<- tupla m

La tabla superior representa la estructura de una relación según el modelo de Codd.

Ejemplo:

cod_empleado	nombre	apellido1	apellido2	salario
1	Juan	Marcos	Serra	35000
2	Adela	Heredia	Castro	28500
3	Carlos	Martínez	Juárez	21000
4	Sandra	Andérez	Pereira	41000
5	Izan	Mancho	Arrieta	34000
6	Petra	Pacheco	Castelo	25500

La forma de representar relaciones es mediante tablas regulares en las que las columnas se corresponden con los atributos y las filas con las tuplas. Esta forma es más visual y entendible.

[3.2.2]tupla

Se llama tupla a cada uno de los elementos de una relación. Hablando en términos de tabla, una tupla es una fila. Las tuplas, en el modelo relacional, cumplen estas premisas:

• Cada tupla se debe corresponder con un elemento del mundo real.
• No puede haber dos tuplas iguales (con todos los valores iguales).

[3.2.3]dominio

Un dominio contiene todos los posibles valores que puede tomar un determinado atributo. Dos atributos distintos pueden tener el mismo dominio.

Un dominio esta formado por un conjunto finito de valores del mismo tipo. A los dominios se les asigna un nombre y así podemos referirnos a ese nombre en más de un atributo, facilitando la aplicación de los mismos.

Por ejemplo si tenemos un atributo llamado Fecha_nac que sirve para almacenar fechas de nacimiento, podremos entender que el valor “Hola” no tiene sentido en ese atributo. Técnicamente se dice que Hola no pertenece al dominio de las fechas. Sí pertenece el valor: 3/9/1982. Una expresión como 34/3/1982 tampoco pertenece al dominio, no es válida (no hay meses de 34 días). Es decir, un dominio expresa de forma inequívoca los valores posibles dentro de un atributo.

Se confunde la idea entre tipo de datos y dominio. Lo cierto es que son conceptos semejantes, pero no iguales. La diferencia es que el dominio impone más restricciones que los tipos de datos.

Por ejemplo, el texto Hola, está claro que no puede ser un valor para el atributo fecha_nac, porque no es una fecha. Sin embargo si tuviéramos un atributo llamado país el texto Hola tampoco forma parte de los valores posibles para ese atributo, porque Hola no es un país; y, sin embargo, tanto la expresión Hola como el nombre de los países pertenecen al mismo tipo de datos (son textos).

Evidentemente ,el ejemplo del dominio para el atributo país es más complejo. No solo almacena textos sino que sólo valen textos concretos, los que representan uno de los países existentes en el planeta: lógicamente este dominio es mucho más difícil de definir.

Otro ejemplo de dominio: el que hace que un valor para el atributo dni sólo se considere perteneciente a su dominio si tiene ocho números, una letra y además la letra cumple una regla matemática concreta sobre los números.

La forma de indicar un dominio se puede hacer utilizando dos posibles técnicas:

• Intensión. Se define el nomino indicando la definición exacta de sus posibles valores. Por intensión se puede definir el dominio de edades de los trabajadores como: números enteros entre el 16 y el 65 (un trabajador sólo podría tener una edad entre 16 y 65 años).
• Extensión. Se indican algunos valores y se sobreentiende el resto gracias a que se autodefinen con los anteriores. Por ejemplo el dominio localidad se podría definir por extensión así: Palencia, Valladolid, Villamuriel de Cerrato,...

Además pueden ser:

• Generales. Los valores están comprendidos entre un máximo y un mínimo y pueden tomar cualquier valor intermedio.
• Restringidos. Solo pueden tomar un conjunto de valores.

[3.2.4]grado

Indica el tamaño de una relación en base al número de columnas (atributos) de la misma. Lógicamente cuanto mayor es el grado de una relación o tabla, mayor es su complejidad de manejo.

[3.2.5]cardinalidad

Número de tuplas de una relación, o número de filas de una tabla. Hay tablas que pueden tener una enorme cardinalidad: cientos, miles e incluso millones de filas.

[3.2.6]sinónimos

Los términos vistos anteriormente tienen distintos sinónimos según la nomenclatura utilizada. A ese respecto se utilizan tres nomenclaturas:

Términos 1 (nomenclatura relacional)		Términos 2 (nomenclatura visual o de tabla)		Términos 3 (nomenclatura ficheros)
relación	=	tabla	=	fichero
tupla	=	fila	=	registro
atributo	=	columna	=	campo
grado	=	nº de columnas	=	nº de campos
cardinalidad	=	nº de filas	=	nº de registros

Se han subrayado en la tabla los términos que se usan más frecuentemente.

[3.2.7]propiedades de las tablas

• Cada tabla debe tener un nombre distinto
• Cada atributo de la tabla solo puede tener un valor en cada tupla
• Cada atributo tiene un nombre distinto en cada tabla (aunque puede coincidir en tablas distintas)
• Cada tupla es única (no hay tuplas duplicadas)
• El orden de los atributos no importa
• El orden de las tuplas no importa

  [3.2.8]tipos de tablas

• Persistentes. Son las tablas que crean los usuarios (normalmente los administradores). Sólo pueden ser borradas por los usuarios Se dividen en tres tipos:
  • Bases. Son tablas independientes. Se crean indicando su estructura y después se les añaden los datos. Cuando alguien habla de tablas, se refiere a este tipo de tablas.

    Las tablas base contienen tanto datos como metadatos. Por ello (debido a los datos) pueden ocupar mucho espacio en disco. Son el fundamento del modelo relacional

  • Vistas. Contienen una instrucción (normalmente en lenguaje SQL) la cual provoca una consulta sobre los datos de las tablas base, haciendo que se muestren los datos que cumplen las condiciones especificadas en dicha instrucción.

    No ocupan mucho espacio en disco (ya que no almacenan datos). Si los datos de las tablas base cambian, los de las vistas que utilizan esos datos también cambian.

    Las vistas permiten una visión de los datos más cómoda para los usuarios.

  • Instantáneas o vistas materializadas. Son vistas (es decir, consultas) que además de almacenar la instrucción SQL, almacenan una copia de los datos que muestra. De modo que la siguiente vez que usemos la instantánea, utilizará la copia de los datos (no leerá los datos originales). Las instantáneas, a diferencia de las vistas, no siempre muestran los datos actualizados.

    Las instantáneas actualizan los datos, refrescando el resultado cada cierto tiempo. La ventaja es que son más veloces que las vistas al no tener que acudir a los datos base; la parte mala, es que los datos que muestran pueden ser obsoletos (ya que pueden haber variado en las tablas base originales).

• Temporales. Son tablas que se eliminan automáticamente por el sistema. Las utiliza el SGBD como almacén intermedio de datos (resultados de consultas, por ejemplo) para acelerar la ejecución del sistema o como almacén auxiliar para instrucciones complejas.

Hay tablas temporales de tipo base, vista o instantáneas; al igual que ocurre con las persistentes.

[3.2.9]claves

4clave candidata

Conjunto de atributos que identifican inequívocamente cada tupla de la relación. Es decir columnas cuyos valores no se repiten en ninguna otra fila de esa tabla. Toda tabla, en el modelo relacional, debe tener al menos una clave candidata, pero puede haber muchas más.

5clave primaria

Clave candidata que se escoge como identificador de la tabla (para identificar cada fila de la misma). Se elige como primaria la candidata que identifique mejor a cada tupla en el contexto de la base de datos. Además se debe dar prioridad a atributos cuyos dominios sean más eficientes de cara al tamaño que ocupan en disco y a la facilidad de proceso por parte de la máquina.

Por ejemplo, en una base de datos de una empresa de venta de productos, un campo con el DNI sería clave candidata de una tabla de clientes; si esa tabla tiene un campo de código de cliente, éste sería mejor candidato (y por lo tanto clave principal) porque es mejor identificador para ese contexto.

Las claves primarias son los únicos datos en el modelo relacional que provocan redundancia ya que se duplican en las claves secundarias para establecer las relaciones entre las tablas. Por ello hay que intentar que las claves primarias contengan datos pequeños, nunca textos largos y de tamaño variable (como nombres, títulos,…).

Buenos tipos de datos para claves primarias son las fechas, números enteros y textos, si son cortos y de tamaño fijo.

6clave alternativa

Cualquier clave candidata que no es elegida como primaria. Hay que tenerlas en cuenta para, al menos, aplicar las restricciones correspondientes (se explican más adelante).

7clave externa, ajena o secundaria

Son los datos de atributos de una tabla cuyos valores están relacionados con atributos de otra tabla. Por ejemplo en la tabla equipos tenemos estos datos:

Equipo	Nº Equipo
Real Madrid	1
F.C. Barcelona	2
Athletic Bilbao	3

En la tabla anterior la clave principal es el atributo nº equipo. En otra tabla tenemos:

Nº Jugador	Jugador	Nº Equipo
1	Muniain	3
2	Messi	2
3	Cristiano Ronaldo	1
4	Bale	1

El atributo Nº Equipo sirve para relacionar el Jugador con el equipo al que pertenece. Ese campo en la tabla de jugadores es una clave secundaria. En el detalle siguiente se resalta la relación entre las claves primarias (en la base de las flechas) y las claves secundarias (en la punta de las flechas):

[3.2.10]nulos

En los lenguajes de programación se utiliza el valor nulo para reflejar que un identificador (una variable, un objeto,..) no tiene ningún contenido. Por ejemplo, cuando un puntero (elemento del lenguaje que sirve para señalar a datos) en lenguaje C señala a null, se entiende que no está señalando a nadie.

Ese significado también se usa en las bases de datos pero, en este caso, para indicar la ausencia de valor en un atributo. Un atributo null, es un atributo vacío. Para Codd el nulo era un valor fundamental ya que otorga de significado al atributo tanto como si tuviera un valor numérico o textual.

Por ejemplo, un valor null puesto en una clave secundaria, indica que la fila que donde se ha puesto ese valor, no tiende ninguna clave principal asociada. En un atributo para indicar el teléfono de una persona, significaría que esa persona no tiene teléfono.

Es importante indicar que el texto vacío ‘ ’, no significa lo mismo que el valor nulo. Tampoco el valor numérico cero (0) significa nulo.

Puesto que los nulos se utilizan continuamente, resulta imprescindible saber cómo actúa cuando se emplean operaciones lógicas sobre ellos. Eso significa definir un tercer valor en la lógica booleana, además de los clásicos verdadero y falso. Un valor nulo no es ni verdadero ni falso (se suele interpretar como un quizás, o usando la aritmética clásica en valores lógicos, el 1 es verdadero, el 0 falso y el 0,5 nulo).

El uso de operadores lógicos con el nulo da lugar a que:

• verdadero Y (AND) nulo da como resultado, nulo. Siguiendo la aritmética planteada antes: 1·0,5=0,5
• falso Y (AND) nulo da como resultado, falso (0·0,5=0)
• verdadero O (OR) nulo da como resultado, verdadero (1+0,5>1)
• falso O nulo da como resultado nulo (0+0,5=0,5)
• la negación de nulo, da como resultado nulo

Se utiliza un operador en todas las bases relacionales llamado es nulo (is null) que devuelve verdadero si el atributo con el que se compara tiene valor nulo.

[3.3] restricciones

Se trata condiciones de obligado cumplimiento para que un dato forme parte de una tabla

[3.3.1]inherentes

Son aquellas que no requieren que se establezcan de forma explícita, sino que son definidas por el propio hecho de que la base de datos sea relacional. Las más importantes son:

• No puede haber dos filas iguales
• El orden de las filas no es significativo
• El orden de las columnas no es significativo
• Cada atributo sólo puede tomar un valor en la intersección entre fila y columna

  [3.3.2]semánticas

El modelo relacional permite incorporar restricciones personales a las tablas. Son las más importantes y son fundamentales para que la información de la base de datos sea coherente y eficiente. Se comentan a continuación las principales restricciones semánticas:

8restricción de clave principal (primary key)

También llamada restricción de clave primaria. Marca uno o más atributos (una o más columnas) como identificadores de la tabla. En el modelo relacional, toda tabla requiere de un identificador o clave principal para asegurar que todas las filas son diferentes en cada tabla.

Esta restricción (además de marcar los datos identificativos de una tabla) prohíbe que las columnas que forman la clave primaria puedan contener valores repetidos en distintas filas o que queden vacías (nulos) en alguna fila. Es decir el contenido de las claves primarias es único y distinto de nulo.

9restricción de unicidad (unique)

Impide que los valores de los atributos marcados de esa forma, puedan repetirse en distintas filas. Es decir, en esa columna los valores deben ser distintos para cada fila, o bien quedar vacíos.

10obligatoriedad (not null)

Prohíbe que el atributo marcado de esta forma quede vacío (es decir impide que pueda contener el valor nulo, null) en alguna fila. También se debe de indicar en las columnas que son clave alternativa.

11clave alternativa (alternate key)

Como ya se ha explicado antes, las claves candidatas que no se eligen para ser claves principales se marcan como clave alternativa. En casi todos los sistemas gestores de bases de datos no es posible marcar claves alternativas de forma explícita.

Sin embargo, si una columna es una clave alternativa, no podrá repetir valores ni quedar vacía. Es decir, las claves alternativas se marcan con restricciones de unicidad (unique) y de obligatoriedad (not null). Esto significa que si detectamos claves alternativas habrá que marcar estas dos restricciones sobre ellas.

12integridad referencial (foreign key)

Las claves externas o secundarias es el mecanismo del modelo relacional para poder asociar datos de diferentes tablas (véase página 76).

La restricción de integridad referencial esta ligada a las claves secundarias y lo que implica es que las columnas marcadas como claves secundarias (foreign keys) no puedan contener valores que no se puedan relacionar con las clave principal de la tabla que relacionan (llamada tabla principal). Sin embargo, sí se permite dejar nulas estas columnas.

Por ejemplo si tenemos esta tabla de clientes:

Clientes
Nombre	Apellidos	Cod_cliente
Arturo	Crespo	97
Sara	Álvarez	113
Josu	Lopetegi	121
Alba	Pereira	123
Gonzalo	Pérez	129

Y tenemos una tabla con los alquileres que hacen estos clientes:

Alquileres
Cod_alquiler	Fecha	cod_cliente
1	12/9/2017	121
2	12/9/2017	121
3	15/9/2017	97
4	16/9/2017	113
5	16/9/2017	129
6	17/9/2017	135

En la última fila observamos que es imposible que ese alquiler sea cierto, puesto que no existe el cliente con código 135. Si la columna está marcada con una restricción de integridad o foreign key no se permite esta situación, solo se podrán utilizar códigos de clientes que existan en la tabla de clientes.

Es muy importante esta restricción porque genera bases de datos muy coherentes. Bien es cierto que, a veces, incomoda porque obliga a una forma muy rígida de trabajar y, además, con relaciones muy complejas el relleno es francamente difícil. Pero, es muy conveniente y, de hecho, obligatoria en el modelo relacional.

1políticas de actualización y eliminación

La restricción de integridad referencial causa problemas en las operaciones de borrado y modificación de registros, ya que si se ejecutan esas operaciones sobre la tabla principal quedarán filas en la tabla secundaria con la clave externa haciendo referencia a un valor que ya no existe, y eso la propia restricción no lo permite.

Es decir no podemos cambiar la clave o eliminar clientes que tengan alquileres relacionados. Es decir si en el ejemplo anterior, borramos la fila en clientes que hace referencia al cliente que se llama Josu, la base de datos reaccionará prohibiendo esta operación ya que hay dos alquileres relacionados con ese cliente. Lo mismo ocurre si intentamos cambiar el código de cliente de Josu.

Para solventar esta situación se utilizar políticas especiales cuando creemos la restricción en la clave secundaria.

• Prohibir la operación (no action). Esto no permitiría hacer en las claves principales ninguna operación si hay claves secundarias relacionadas con ellas. Suele ser la opción por defecto. Es muy rígida.
• Transmitir la operación en cascada (cascade). Es decir si se modifica o borra un cliente, también se modificarán o borrarán los alquileres relacionados con él.
• Colocar nulos (set null). Si modificamos o borramos un cliente, sus alquileres marcarán el antiguo código de ese cliente como nulo. Por ejemplo si borramos al cliente que se llama Josu los alquileres 1 y 2 indicaran como código de cliente el valor null.
• Usar el valor por defecto (default). Se colocan un valor por defecto en las claves externas relacionadas cuando se borre o modifique la clave principal relacionada. Este valor por defecto se indica al crear la tabla (opción default).

No todas las bases de datos admiten todas estas posibles políticas a aplicar en operaciones de actualizar o eliminar. Además, podemos indicar una política al actualizar y otra al eliminar. Es decir podremos, por ejemplo, indicar nulos ante cambios en las claves principales y actuar en cascada ante eliminaciones en las claves.

13regla de validación (check)

Es una restricción que impone una condición lógica que deberá de cumplir una o más columnas cuando se la añadan o modifiquen los datos. Por ejemplo, podríamos restringir la columna llamada sueldo para que siempre acepte valores mayores de 1000; no se permitiría entonces indicar sueldos menores de 1000 en dicha columna.

A veces las reglas implican a varias columnas, como por ejemplo que la fecha de inicio sea mayor que la fecha final.

14disparadores o triggers

Son restricciones más complejas, presentes en sistemas avanzados de bases de datos. Se trata de código almacenado en la base de datos, cuyas instrucciones se ejecutan automáticamente cuando ocurre un determinado evento (añadir una fila, modificar filas, iniciar sesión por parte del usuario,...).

Las instrucciones pueden realizar cualquier operación permitida. Por ejemplo, podemos hacer que ningún usuario pueda añadir datos de 12 de la noche a 5 de la mañana, o que no podamos añadir una cuenta bancaria si sus dígitos de control no cumplen la compleja regla que se les aplica.

Los triggers permiten realizar restricciones muy potentes, pero son las restricciones más complejas de definir ya que implican conocimientos de programación.

[3.4] las 12 reglas de Codd

Preocupado por los productos que decían ser sistemas gestores de bases de datos relacionales (RDBMS) sin serlo, Codd publica 12 reglas que debe cumplir todo Sistema Gestor de Bases de Datos para ser considerado relacional ; lo hace en el año 1985.

Las doce reglas en la práctica las cumplen pocos sistemas relacionales, pero sí los mejores. El interés actual de estas reglas, cuando el propio modelo relacional se está revisando, es que permiten detallar la manera de funcionar de un sistema de bases de datos relacional.

Las reglas son:

[1]Información. Toda la información de la base de datos (metadatos) debe estar almacenada explícitamente en el esquema lógico. Es decir, todos los datos se almacenan en las tablas base del sistema. Dicho de otro modo: no pueden existir datos a los que tengamos que acceder por una vía diferente a la de las tablas del modelo relacional.

[2]Acceso garantizado. Todo dato en la base de datos es accesible sabiendo el valor de su clave principal y el nombre de la columna o atributo que contiene el dato. No hace falta saber, por ejemplo, ni el número de fila ni el de columna. Esto implica que todas las tablas tienen que tener identificador y eso nos permite acceder a una fila concreta; la columna es accesible por su nombre y no por el orden que tiene.

[3]Tratamiento sistemático de los valores nulos. El DBMS (Sistema Gestor de bases de datos) debe permitir el tratamiento adecuado de estos valores. Esto significa que los valores nulos se manejan como una información más de la base de datos; se podrá utilizar como información en sí y por lo tanto operar con estos valores no producirá error alguno. Se permitirá realizar operaciones lógicas y de todo tipo con ellos, haciendo que el resultado sea coherente.

[4]Catálogo en línea basado en el modelo relacional. El catálogo en línea es otro nombre para el diccionario de datos. Esta regla indica que los metadatos deben de ser accesibles usando un esquema relacional. Es decir la forma de acceder a los metadatos es la misma que la forma de acceder a los datos. Dicho de otra forma, también los metadatos se almacenan en tablas.

[5]Sublenguaje de datos completo. Al menos, debe de existir un lenguaje que permita el manejo completo de la base de datos. Mediante este lenguaje podremos realizar cualquier operación sobre la base de datos, sea del tipo que sea.

[6]Actualización de vistas. El SGBD debe encargarse de que las vistas muestren la última información. En ningún caso las vistas mostrarán información obsoleta. Esto implica una enorme potencia por parte del Sistema Gestor de Bases de Datos.

[7]Inserciones, modificaciones y eliminaciones de dato nivel. Cualquier operación de modificación debe actuar sobre conjuntos de filas o registros, nunca deben actuar registro a registro. Por lo tanto los lenguajes que realizan estas tareas (DML) son de cuarta generación y no pueden ser lenguajes como C o Java por ejemplo (de tercera generación) que normalmente utilizarían recorridos fila a fila y bucles para modificar los datos, provocando un manejo menos humano de la base de datos.

[8]Independencia física. El esquema lógico y los externos (las aplicaciones de usuario) no se deben modificar por los cambios que se realicen en la base de datos física. Es decir aunque, por ejemplo, cambiemos el nombre de un fichero de la base de datos, por ejemplo, no tendremos que modificar ni los programas de los usuarios ni siquiera la lógica (las tablas) de la base de datos.

[9]Independencia lógica. Los cambios en la lógica de la base de datos (en las tablas), no afectan a la forma en la que el usuario accede a la base de datos. Es decir, las aplicaciones de usuario son independientes de la propia lógica. Esta independencia en la práctica no se consigue tan fácilmente como la anterior.

[10]Independencia de integridad. Las reglas de integridad deben almacenarse en la base de datos (en el diccionario de datos), no en los programas de aplicación. Eso permite que dichas reglas sobre los datos se cumplan siempre independientemente de la forma de acceder a los mismos.

[11]Independencia de la distribución. El sublenguaje de manipulación de datos (DML) debe permitir que sus instrucciones funcionen igualmente en una base de datos distribuida que en una que no lo es. Los programas y aplicaciones de usuarios se crean de la misma forma. Es decir las bases de datos distribuidas permiten trabajar en ellas como si fueran una base de datos normal y local.

[12]No subversión. Si el SGBD dispone de un lenguaje de bajo nivel (normalmente será un lenguaje de tipo procedimental) para trabajar en la base de datos (como por ejemplo el PL/SQL de Oracle), este lenguaje no se puede saltar ninguna regla de las anteriores. Puede que facilite la realización de tareas este tipo de lenguaje, pero en ningún caso podrá trabajar con los datos de forma incompatible con el modelo relacional.