String Operation Instructions 4-

Una vez más, considere la siguiente definición de tipo: TYPE V# POSSREP ( CHAR ) ;

De manera predeterminada, en este caso la representación posible tiene el nombre heredado V#, de ahí que el operador selector correspondiente también tenga el mismo nombre. Por lo tanto, la siguiente es una invocación de selector válida:

V# ( ' V1' )

(la cual regresa cierto número de proveedor). Por lo tanto, observe que el selector V# podría ser considerado, a grandes rasgos, como un operador de conversión de tipo que convierte cadenas de caracteres a números de proveedor. En forma similar, el selector P# podría ser considerado como un operador de conversión de cadenas de caracteres en números de parte; el selector CANT podría ser considerado como un operador de conversión que convierte enteros en canti- dades, y así sucesivamente.

Ahora bien, en el capítulo 3 dimos varios ejemplos en los que se realizaba una comparación entre (por ejemplo) un número de parte y una cadena de caracteres. Por ejemplo, el ejercicio 3.4 incluyó la siguiente cláusula WHERE:

.. . WHERE P# = ' P2 '

En este caso, el operando de la izquierda es de tipo P# y el de la derecha es de tipo CHAR; por lo tanto, frente a esto, la comparación debe fallar dando un error de tipo (de hecho, un error de

122 Parte II / El modelo relational

tipo en tiempo de compilación). Sin embargo, de manera conceptual, lo que sucede es que el sistema se da cuenta de que puede usar el "operador de conversión" P# para convertir el ope: CHAR al tipo P#, de modo que en efecto reescriba la comparación como sigue:

... WHERE P# = P# ( 'P2' ) La comparación ahora es válida.

A la acción de invocar implícitamente a un operador de conversión (de esta manera), se le conoce como coacción; y la utilizamos mucho, aunque de manera tácita, a lo largo del capí-j tulo 3. Sin embargo, es bien sabido en la práctica que la coacción puede ocasionar errores de pro- grama. Por este motivo, a partir de este momento, adoptaremos la postura conservadora de no permitir coacciones; los operandos deberán ser siempre del tipo apropiado, no simplemente con- vertibles a ese tipo. En particular, insistiremos en que:

■ Los operandos para "=", "<" y ">" deben ser del mismo tipo;

■ Las partes a la izquierda y a la derecha de una asignación (":=") deben ser del mismo tipo. Por supuesto, sí permitimos la definición de lo que por lo regular se conoce como opera- dores "CAST" (de conversión) y su invocación explícita para convertir entre tipos, donde se necesario; por ejemplo:

CAST_AS_RATIONAL ( 5 )

Como ya señalamos, también es posible pensar en los selectores —por lo menos en aquellos c sólo toman un argumento— como en operadores de conversión explícitos (de una clase).

Conclusiones

El soporte completo para los tipos comprendidos en la presente sección tiene varias imp ciones importantes, las cuales resumimos aquí brevemente:

■ La primera y más importante indica que el sistema sabrá (a) exactamente qué expresio son válidas y (b) el tipo del resultado de cada una de estas expresiones válidas. ■ También significa que el conjunto total de tipos para una base de datos dada será un <

junto cerrado; es decir, que el tipo del resultado de toda instrucción válida será un tipo conocido por el sistema. En particular, observe que para que las comparaciones sean ex presiones válidas, este conjunto cerrado de tipos debe incluir el tipo boolean o valor de verdad.

■ En particular, el hecho de que el sistema conozca el tipo de resultado de toda expresión vá- lida significa que sabe qué asignaciones y qué comparaciones son válidas.

Cerramos esta sección con una referencia adelantada importante. Hemos afirmado que los dominios son tipos de datos —definidos por el sistema o por el usuario— de una complejidad interna arbitraria, cuyos valores son manipulables exclusivamente por medio de los operadores definidos para el tipo en cuestión (y cuya representación interna está, por lo tanto, oculta para el usuario). Ahora bien, si enfocamos nuestra atención por un momento en los sistemas de obje-tos. encontramos que el concepto más fundamental de objeto, la clase objeto, es un tipo de datos — definido por el sistema o por el usuario— de una complejidad interna arbitraria, cuyos va- lores son manipulables exclusivamente por medio de los operadores definidos para el tipo en

cuestión (y cuya representación interna está, por lo tanto, oculta para el usuario)... En otras pa- labras, ¡los dominios y las clases objeto son lo mismo!; de modo que aquí tenemos la clave para hacer compatibles las dos tecnologías (relaciones y objetos). En el capítulo 25 abundaremos sobre este importante asunto.

5.3 VALORES DE RELACIÓN

Del capítulo 3 recuerde que es necesario distinguir cuidadosamente, por una parte, entre las rela- ciones por sí mismas (es decir, entre los valores de relación) y las variables de relación (es decir, las variables cuyos valores son valores de relación), por la otra. En esta sección explicaré los va- lores de relación (relaciones, para abreviar) y en la siguiente, las variables de relación. Entonces, antes que nada, he aquí una definición precisa del término relación:

■ Dado un conjunto de n tipos o dominios Ti (i = 1,2,..., n), que no son necesariamente todos distintos, r es una relación sobre esos tipos si consta de dos partes: un encabezado y un cuerpo;* donde:

a. El encabezado es un conjunto de n atributos de la forma Ai: Ti, donde los Ai (que deben ser todos distintos) son los nombres de atributo de r y los Ti son los nombres de tipo co rrespondientes (i= 1, 2, ...,n);

b. El cuerpo es un conjunto de m tupias t, en donde t es a su vez un conjunto de compo nentes de la forma Ai:vi en la cual vi es un valor de tipo Ti; es decir, el valor de atributo para el atributo Ai de la tupia t (i = 1, 2, ..., «).

A los valores m y n se les denomina cardinalidad y grado, respectivamente, de la re- lación r.

Los puntos que se desprenden de esta definición son:

Por supuesto, en términos de la representación tabular de una relación, el encabezado es la fila de nombres de columna y de nombres de tipo correspondientes; el cuerpo es el conjunto de filas de datos (vea más adelante una explicación mejor). 1

Decimos que el atributo Ai es de tipo Ti o (en ocasiones) que está definido sobre el tipo Ti. Observe que cualquier número de atributos —en la misma relación, en relaciones distintas, o en ambos casos— puede ser del mismo tipo (para comprender mejor este punto, vea la figura 3.8 del capítulo 3; además de las figuras 4.5 y 4.6 del capítulo 4).

3. En un momento dado, existirán comúnmente valores de un tipo determinado que no aparez can actualmente en la base de datos como un valor de alguno de los atributos existentes de ese tipo. Por ejemplo, P8 podría ser un número de parte válido aunque no exista una "parte P8" en la figura 3.8.

4. Como establecí en la definición, al valor n —el número de atributos en la relación— se le llama grado (en ocasiones, aridad). Se dice que una relación de grado uno es unaría, una relación de grado dos binaria, una de grado tres ternaria, ...y una relación de grado n n-aria.

* En la literatura también se hace referencia al encabezado como un esquema (de relación) o, en ocasiones, sólo como un esquema. También se le conoce como la intensión (nótese la ortografía), en cuyo caso al cuerpo se le denomina la extensión.

124 Parte II / El modelo relacional

En general, el modelo relacional se ocupa entonces de las relaciones n-arias para un entero

n cualquiera no negativo.

5. El término n-tupla se usa en ocasiones en lugar de tupia (y así hablamos de, por ejemplo, 4-tuplas, 5-tuplas, etcétera). Sin embargo, es común omitir el prefijo "n-".

6. Decir que la relación r tiene el encabezado H quiere decir precisamente que la relación r es del tipo RELATION{H} (y el nombre de ese tipo es precisamente RELATION{H}). Para una mejor explicación, vea la sección 5.4.

A manera de ejemplo, examinemos la tabla de la figura 5.1 (deliberadamente no la lla- maremos relación por el momento) para ver cómo se ajusta a la definición anterior.

■ Primero, esa tabla tiene cuatro tipos subyacentes; para ser específicos, números de provee dor (V#), nombres (NOMBRE), valores de status (STATUS) y nombres de ciudades (CIU DAD). Nota: Es cierto que cuando plasmamos una relación como una tabla sobre papel a menudo no nos molestamos en mencionar los tipos subyacentes (como vimos en el capí tulo 3); pero debemos entender que, por lo menos conceptualmente, siempre están ahí. ■ A continuación, la tabla tiene en realidad dos partes: una fila de nombres de columna y un

conjunto de filas de datos. Consideremos primero la fila de nombres de columna: ( V#, PROVEEDOR, STATUS, CIUDAD )

Lo que en realidad representa esta fila es el siguiente conjunto de pares ordenados: { V# : V#

PROVEEDOR : NOMBRE , STATUS : STATUS , CIUDAD : CIUDAD }

El primer componente de cada par es un nombre de atributo, el segundo es el nombre deli tipo correspondiente. Por lo tanto, podemos acordar que la fila de encabezados de columna sí representa un encabezado en el sentido de la definición. Nota: Como ya indiqué, en la práctica es común pensar que un encabezado sólo consiste en un conjunto de nombres de atributo (es decir, a menudo se omiten los nombres de tipo), salvo cuando la precisión es en particular importante. La práctica es imprecisa pero cómoda y con frecuencia la adoptaremos en los capítulos siguientes.

■ Por lo que toca al resto de la tabla, ciertamente sí consiste en un conjunto; es decir, un con junto de filas de datos. Concentrémonos en una sola fila de ese conjunto, digamos la fila

( V1, Smith, 20, Londres )

Lo que en realidad representa esta fila es el siguiente conjunto de pares ordenados: { V# : V# ( ' V1 ' ) ,

PROVEEDOR : NOMBRE ( 'Smith' ) , STATUS : 20

CIUDAD : 'Londres' }

El primer componente en cada par es un nombre de atributo, el segundo es el valor de atri- buto correspondiente. Ahora bien, por lo regular en contextos informales omitimos los nombres de atributo, debido a que tenemos una convención que dice que cada valor indi-

vidual de la tabla es en realidad un valor del atributo cuyo nombre aparece en la parte su- perior de la columna relevante; además, ese valor es de hecho un valor del tipo subyacente relevante; es decir, el tipo del atributo en cuestión. Por ejemplo, el valor V1 —de manera más adecuada, V#('V1')— es un valor del atributo V# y es de hecho un valor del tipo re- levante; es decir, el tipo "números de proveedor" (al que también se le conoce como V#). De modo que podemos acordar que cada fila representa de hecho a una tupia, en el sentido de la definición.

De todo lo anterior podemos acordar que la tabla de la figura 5.1 en realidad puede con- siderarse como una imagen de una relación, en el sentido de la definición —siempre y cuando podamos acordar cómo "leer" dicha imagen (es decir, siempre y cuando podamos acordar cier- tas reglas de interpretación para dichas imágenes). En otras palabras, tenemos que acordar que sí existe" algunos tipos subyacentes; que cada columna sí corresponde exactamente a uno de esos tipos; que cada fila sí representa una tupia; que cada valor de atributo sí es un valor del tipo relevante; y así sucesivamente. Si podemos estar de acuerdo en todas estas "reglas de inter- pretación", entonces —y sólo entonces— podemos acordar que una "tabla" es una imagen ra- zonable de una relación.

Entonces, ahora podemos ver que una tabla y una relación no son exactamente lo mismo (aunque en capítulos anteriores hayamos pretendido que lo eran). Más bien, una relación es lo que la definición dice que es (es decir, una clase de objeto más bien abstracto) y una tabla es una imagen concreta (generalmente sobre papel) de dicho objeto abstracto. De nuevo, una relación y una tabla no son exactamente lo mismo. Por supuesto, son muy parecidas... y por lo menos en contextos informales es usual y perfectamente aceptable decir que sí lo son. Pero cuando intentamos ser más precisos (y, desde luego, en este momento estamos inten- tando serlo), entonces tenemos que reconocer que los dos conceptos no son exactamente idénticos.

Nota: Si tiene problemas con la idea de que existen algunas diferencias entre una relación y una tabla, tal vez le ayude lo siguiente. Primero, es innegable que una gran ventaja del modelo relacional es que su objeto abstracto básico, la relación, tiene una representación muy sencilla sobre el papel; es esa representación la que hace que los sistemas relacionales sean fáciles de usar y entender, y facilita el razonamiento sobre la forma en que los sistemas relacionales se com- portan. Sin embargo, también es desafortunado el hecho de que la representación tabular su- giere algunas cosas que no son ciertas. Por ejemplo, claramente sugiere que las filas de la tabla —es decir, las tupias de la relación— están en un cierto orden de arriba hacia abajo, aunque en realidad no lo están (vea la siguiente subsección).