El modelo relacional

El modelo relacional descansa sobre una base matemática, y la pieza de la que todo lo demás depende es la relación. Formalmente, una relación sobre los atributos A1, A2 hasta An es un conjunto de tuplas, y cada tupla asigna a cada atributo un valor de su dominio.

De una relación hay que distinguir dos cosas que se confunden constantemente. La intensión, también llamada esquema, es la parte estable: el nombre de la relación y el conjunto de sus atributos con sus dominios. Se escribe como ALUMNO(id_alumno, nombre, email) y no cambia salvo que se rediseñe la base de datos. La extensión es el conjunto de tuplas que la relación contiene en un instante dado, y cambia con cada inserción o borrado.

Sobre esas dos ideas se apoyan las dos medidas de una relación. El grado es el número de atributos, o sea una propiedad de la intensión. La cardinalidad es el número de tuplas, o sea una propiedad de la extensión. Conviene tener cuidado con la palabra cardinalidad, porque en el modelo entidad-relación significaba otra cosa: allí eran cuántas ocurrencias se asocian, y aquí es cuántas filas hay.

La intensión es la definición y no cambia; la extensión son los datos y cambia a cada rato. Grado cuenta atributos, cardinalidad cuenta tuplas.

Que la relación sea un conjunto matemático no es un adorno: de ahí salen cuatro propiedades que toda relación cumple por definición, y varias preguntas de examen se resuelven recordándolas.

• Cada atributo tiene un dominio, es decir, un conjunto de valores válidos del que no puede salir.
• Atomicidad. Los valores de los atributos son atómicos: no pueden ser multivalorados ni contener una estructura dentro. Esta propiedad es justamente lo que exige la primera forma normal.
• No hay tuplas repetidas. Como una relación es un conjunto, dos tuplas idénticas serían la misma. Esta es la razón última de que toda relación tenga clave.
• No hay orden establecido, ni entre las tuplas ni entre los atributos. Que una fila se vea la primera o que una columna se vea a la izquierda es un accidente de la presentación, no información.

La ausencia de orden tiene una consecuencia práctica que se olvida: una consulta sin cláusula de ordenación no garantiza en qué orden llegarán las filas, aunque hoy lleguen siempre igual. Si el orden importa, hay que pedirlo.

-- Sin ORDER BY el gestor no promete ningún orden:
SELECT titulo, nivel FROM tema;

-- Si el orden forma parte del resultado, se pide:
SELECT titulo, nivel
FROM   tema
ORDER  BY nivel, titulo;

Los mismos conceptos reciben tres nombres distintos según se hable en términos matemáticos, en términos de base de datos o en términos de ficheros tradicionales. Los enunciados de examen mezclan los tres a propósito.

Relación, tupla y atributo es el vocabulario formal; tabla, fila y columna el práctico; fichero, registro y campo el heredado. Cardinalidad va con las filas y grado con las columnas.

Una clave es lo que permite señalar una tupla sin ambigüedad. Hay varios tipos y se distinguen por dos criterios: si identifican de forma unívoca y si son mínimas, es decir, si al quitarles cualquier atributo dejan de identificar.

El razonamiento se ve mejor con un ejemplo. En una relación de alumnos con documento de identidad, número de seguridad social, color de ojos y fecha de nacimiento, son superclaves el documento solo, el número de seguridad social solo, el documento junto al color de ojos y el documento junto a la fecha de nacimiento: todas identifican. Pero solo dos son mínimas, el documento y el número de seguridad social, así que solo esas dos son claves candidatas. Si se elige el documento como clave primaria, el número de seguridad social queda como clave alternativa.

Toda clave candidata es una superclave; lo contrario no se cumple. Y toda clave primaria es una clave candidata elegida, de modo que la relación entre los tres conceptos es de inclusión, de la más amplia a la más restrictiva.

CREATE TABLE alumno (
  id_alumno   INTEGER      PRIMARY KEY,   -- clave primaria
  documento   VARCHAR(9)   NOT NULL UNIQUE, -- clave alternativa
  email       VARCHAR(120) NOT NULL UNIQUE  -- otra clave alternativa
);

CREATE TABLE intento (
  id_intento  INTEGER PRIMARY KEY,
  id_alumno   INTEGER NOT NULL,
  id_subtema  INTEGER NOT NULL,
  aciertos    INTEGER NOT NULL,
  CONSTRAINT fk_intento_alumno
    FOREIGN KEY (id_alumno) REFERENCES alumno (id_alumno)
);

Un valor nulo representa ausencia de valor. No es el cero, no es la cadena vacía y no es un espacio en blanco: significa que el dato no se conoce o no procede. Distinguirlo de esos tres es una pregunta clásica.

La regla de integridad de entidad exige que ningún atributo de la clave primaria pueda ser nulo. La razón es directa: si la clave sirve para identificar y parte de ella se desconoce, la tupla no queda identificada. Cuando la clave primaria es compuesta, la prohibición alcanza a todos y cada uno de sus atributos, no solo al conjunto.

La regla de integridad referencial exige que, si una relación tiene una clave ajena, el valor de esa clave ajena coincida con un valor existente de la clave primaria a la que referencia, o bien sea nulo. Es decir, no se puede apuntar a una fila que no existe.

Esa segunda posibilidad es la que más se pregunta: sí se admite que una clave ajena valga nulo, y eso significa que la tupla no está asociada a ninguna. Un intento de test sin tutor asignado tendría el identificador de tutor a nulo. Una clave primaria, en cambio, nunca puede serlo.

La clave primaria nunca admite nulos; la clave ajena sí. Cuando la primaria es compuesta, ninguno de sus atributos puede ser nulo por separado.

Codd formuló un conjunto de reglas para decidir si un sistema gestor merece llamarse relacional. Se conocen como «las 12 reglas de Codd», pero en realidad son trece, porque están numeradas de la 0 a la 12. Ese detalle aritmético es en sí mismo una pregunta de examen.

Merece la pena fijarse en el grupo de las independencias, que son cuatro seguidas (física, lógica, de la integridad y de la distribución) y en que la regla 10 es la que justifica que las restricciones vivan en la base de datos y no en el código de la aplicación: si viven en el catálogo se cumplen siempre, venga la operación de donde venga.