Las relaciones poseen ciertas propiedades, todas ellas consecuencias inmediatas de la definición de relación dada en la subsección anterior, y todas ellas muy importantes. Primero enunciare- mos brevemente las propiedades y luego las explicaremos en detalle. Las propiedades son como sigue. Dentro de cualquier relación dada:
■ No existen tupias duplicadas;
■ Las tupias están en desorden, de arriba hacia abajo; ■ Los atributos están en desorden, de izquierda a derecha;
126 Parte II / El modelo relational
■ Cada tupia contiene exactamente un valor para cada atributo. 1. No existen tupias duplicadas
Esta propiedad surge del hecho de que el cuerpo de la relación es un conjunto matemático (de tupias); los conjuntos en matemáticas no incluyen elementos duplicados.
Nota: De hecho, debe ser obvio que el concepto de "tupias duplicadas" no tiene sentido.
Considere una relación con los atributos V# y CIUDAD (que significan que "el proveedor V# está ubicado en la ciudad CIUDAD"). Suponga que la relación contiene una tupia que muestra que es un "hecho verdadero" que el proveedor V1 está ubicado en Londres. Entonces, si la relación contuviera un duplicado de esa tupia (si eso fuese posible), simplemente nos estaría di- ciendo, por segunda vez, el mismo "hecho verdadero". Pero si algo es cierto, ¡decirlo dos veces no lo hace más cierto!
A propósito, esta primera propiedad sirve para ilustrar el punto de que (en general) una relación y una tabla no son lo mismo; ya que (en general) una tabla puede contener filas dupli- cadas —en ausencia de cualquier disciplina que evite tal cosa—, mientras que una relación no
puede contener una tupia duplicada. (Ya que si una "relación" contiene tupias duplicadas, en-
tonces, por definición, ¡no es una relación!) Es muy desafortunado el caso de que SQL permita que las tablas contengan filas duplicadas. Éste no es el lugar apropiado para abordar todas las razones por las cuales tales duplicidades son un error (para una explicación amplia, vea las re- ferencias [5.3] y [5.6]); para los fines actuales, es suficiente señalar que el modelo relacionala) reconoce duplicados, y por lo tanto, en este libro nos aseguraremos que nunca ocurran. (Esta ob- servación se aplica principalmente a nuestras explicaciones de SQL. Por supuesto, en lo que res- pecta al modelo relacional en sí mismo, no es necesario tener un cuidado especial.)
2. Las tupias están en desorden, de arriba hacia abajo
Esta propiedad también surge del hecho de que el cuerpo de la relación es un conjunto ma- temático; en matemáticas, los conjuntos no están ordenados. Por ejemplo, en la figura 5.1 las tu- pias también podrían haber sido mostradas en secuencia inversa, y seguiría siendo la misma relación. Por lo tanto, no hay algo que se llame "la quinta tupia" o "la 97a tupia" o "la primen tupia" de una relación y tampoco hay algo como "la siguiente tupia"; en otras palabras, no existe el concepto de direccionamiento posicional y no existe el concepto de "la que sigue". La re- ferencia [5.6], mencionada anteriormente con relacion a la propiedad de que "no hay tupias duplicadas", muestra por qué también es tan importante la propiedad de "no ordenamiento de tupias" (de hecho, ambas propiedades están interrelacionadas).
Nota: Es cierto que se requiere algún concepto como el de "la que sigue" en una interíaz entre
la base de datos y un lenguaje anfitrión como C o COBOL (vea la explicación de cursores de SQL y la cláusula ORDER BY en el capítulo 4). Pero es el lenguaje anfitrión y no el modelo relacional el que impone ese requerimiento. En efecto, el lenguaje anfitrión requiere que conjuntos sin orden se conviertan en listas o arreglos (de tupias) ordenados, de modo que las operaciones como "ac-ceder a la siguiente tupia" puedan tener significado. Observe además que dichas características sólo forman parte de la interfaz del programa de aplicación; no están expuestas a los usuarios finales.
Como mencioné anteriormente en esta sección, esta segunda propiedad sirve también para ilustrar la idea de que una relación y una tabla no son lo mismo, ya que las filas de una tabla ob- viamente tienen un ordenamiento de arriba hacia abajo, mientras que las tupias de una relación no lo tienen.
3. Los atributos están en desorden, de izquierda a derecha
Esta propiedad surge del hecho de que el encabezado de una relación también es un conjunto (de atributos). Por ejemplo, en la figura 5.1 los atributos también podrían haber sido mostrados en el orden (por decir) PROVEEDOR, CIUDAD, STATUS, V#, y seguiría siendo la misma relación (por lo menos en lo que respecta al modelo relational).* Por lo tanto, no existe algo como "el primer atributo" o "el segundo atributo" (etcétera) y tampoco hay "el siguiente atri- buto" (de nuevo, no existe el concepto de "el siguiente"); en otras palabras, siempre se hace re- ferencia a los atributos por nombre, nunca por posición. Como resultado, se reduce el alcance de los errores y la programación confusa. Por ejemplo, no hay (o no debe haber) una forma de hacer que el sistema "se extienda" de algún modo de un atributo a otro. Esta situación contrasta con la que se encuentra en muchos sistemas de programación, donde a menudo es posible ex- plotar de muy diversas formas la adyacencia física de elementos lógicamente discretos, de ma- nera deliberada o no.
Observe que esta cuestión del ordenamiento de los atributos es otra área más en donde la representación concreta de una relación como una tabla, sugiere algo que no es cierto: las colum- nas de una tabla tienen obviamente un ordenamiento de izquierda a derecha, pero los atributos de una relación no lo tienen.
4. Cada tupia contiene exactamente un valor para cada atributo
Esta propiedad surge inmediatamente de la definición de una tupia: una tupia es un conjunto de n componentes o pares ordenados de la forma Ai:vi (i= 1,2,..., n). Se dice que una relación que satisface esta cuarta propiedad está normalizada o, lo que es equivalente, está en la primera
forma normal.
Nota: Esta propiedad en particular podría parecer muy obvia y de hecho lo es; en especial debido a que (como tal vez haya notado) todas las relaciones están normalizadas de acuerdo con la definición. Sin embargo, esta propiedad sí tiene algunas consecuencias importantes. Vea (a) la nota a la referencia [5.10], (b) el capítulo 18 sobre información faltante y (c) la subsección siguiente.
Atributos con valor de relación
En la sección 5.2, dijimos que los valores que conforman un tipo pueden ser de cualquier clase. Por lo tanto, podemos tener un tipo en particular cuyos valores sean relaciones y por lo tanto tener relaciones con atributos cuyos valores sean a su vez relaciones. En otras palabras, po- demos tener relaciones que tengan otras relaciones anidadas dentro de sí mismas. La figura 5.3 muestra un ejemplo: la relación V_VP; el atributo PC de esa relación tiene el valor de una relación. Observe en particular que el conjunto vacío de partes que suministra el proveedor V5 está representado por un conjunto vacío (para ser más precisos, por una relación vacía).
Aquí, el motivo principal para mencionar explícitamente la posibilidad de que los atributos tengan valores de relación es que, históricamente, la mayoría de las publicaciones de bases de datos relacionales —incluidas las primeras ediciones de este libro— han afirmado que dicha
* Las relaciones matemáticas, a diferencia de sus contrapartes en el modelo relacional, sí tienen un orden de izquierda a derecha para sus atributos.
128 Parte II / El modelo relational
V_VP
v#
PROVEEDOR STATUS CIUDAD PCV1 Smith 20 Londres P# CANT P1 300 P2 200 V2 Jones 10 París P6 100 P# CANT P1 300 V5 Adams 30 Atenas P2 400 P# CANT
Figura 5.3 Una relación con un atributo que tiene valor de relación.
posibilidad no es válida (y la mayoría aún lo afirman). Por ejemplo, el siguiente es un extracto ligeramente modificado de la edición anterior de este libro:
Observe que todos los valores de columnas son atómicos... Es decir, en cada posición de fila y columna de una tabla siempre hay exactamente un valor de datos, nunca un grupo de varios valores. Por lo tanto, tenemos (por ejemplo) en la tabla EMP
DEPTO# EMP# D1 D1 E1 E2 en lugar de DEPT0# EMP# D1 E1 , E2
En la segunda versión de esta tabla, la columna EMP# es un ejemplo de lo que por lo regular se denomina grupo de repetición. Un grupo de repetición es una columna... que contiene varios valores en cada fila (en general, diferente número de valores en diferentes filas). Las bases de datos relacionales no permiten los grupos de repetición; la segunda ver- sión de la tabla anterior no sería permitida en un sistema relacional.
Y más adelante, en el mismo libro:
[Los dominios] contienen sólo valores atómicos... [Por lo tanto,] las relaciones no contienen
grupos de repetición. Se dice que una relación que satisface esta condición está normalizada
o, lo que es equivalente, está en la primera forma normal... En el contexto del modelo rela- cional, el término relación siempre se utiliza para indicar una relación normalizada.
Sin embargo, estas observaciones no son correctas (por lo menos en su totalidad). Surgieron de una mala interpretación de mi parte sobre la verdadera naturaleza de los tipos y los predicados. Por razones que explicaré en el capítulo 11 (sección 11.6), no es probable que este error haya ocasionado errores serios en la práctica; sin embargo, sigo ofreciendo mis disculpas a cualquiera a quien esto haya causado confusión. Por lo menos la edición anterior estuvo correcta cuando dijo que en el modelo relacional las relaciones siempre estaban normalizadas. Consulte, una vez más, el capítulo 11 para una mayor explicación.
Las relaciones y su interpretación
Concluimos esta sección con un recordatorio de que —como expliqué en el capítulo 3, sección 3.4— (a) el encabezado de cualquier relación dada pueda ser considerado como un predicado y (b) las tupias de esa relación puedan ser consideradas como proposiciones verdaderas obtenidas del predicado mediante la sustitución de valores del tipo apropiado por los parámetros o indi-
cadores de posición de ese predicado ("lo que crea un ejemplar del predicado"). De hecho, la
Suposición del Mundo Cerrado (también conocida como la Interpretación del Mundo Cerra- do) dice que si una tupia válida —es decir, una que se apegue al encabezado de la relación— no aparece en el cuerpo de la relación, entonces podemos pensar que la proposición correspondiente es falsa. Esto es, el cuerpo de la relación contiene únicamente aquellas tupias que correspondan a proposiciones verdaderas.
5.4 VARIABLES DE RELACIÓN
Del capítulo 3, recuerde que las variables de relación —o variables relacionales o varrels, para abreviar— se presentan en dos variedades: las varrels base y las vistas (también denominadas varrels auténticas y virtuales, respectivamente). En esta sección consideraremos únicamente a las varrels base; explicaré las vistas en el capítulo 9.
Definición de varrel base
Aquí tenemos la sintaxis para definir una varrel base: VAR <nombre de varrel> BASE <tipo de relación>
<lista de definición de claves candidatas> [ <lista de definición de claves externas> J
El <tipo de relación> toma la forma
RELATION { <lista de atributos separados con comas> }
en donde cada <atributo> es a su vez un par ordenado de la forma <nombre de atributo> <nombre de tipo>
130 Parte II / El modelo relational
Con respecto a la <lista de definición de claves candidatas> y la opcional <lista de definición
de claves externas>, vea más adelante.
Nota: El término lista con comas lo definí en el capítulo 4 (sección 4.6). El término lisa lo
defino de manera análoga, por lo tanto: Sea <xyz> un elemento para denotar una categoría sin- táctica cualquiera (es decir, todo lo que aparezca a la izquierda de una regla de producción BNF).. Entonces la expresión <lista de xyz> denota una secuencia de cero o más elementos <.rv;>.a la cual un par de <xyz> adyacentes está separado por uno o más espacios en blanco.
Aquí tenemos, a manera de ejemplo, las definiciones de varrel base para la base de datos de proveedores y partes (retomada de la figura 3.9):