Introducción a los sistemas

de Bases de Datos
C. J. Date

Extracto del libro:

“Introducción a los sistemas de Bases de Datos”
Séptima Edición, Editorial Pearson, 2001
C. J. Date
 CAPITULO 3
Una introducción a las bases
de datos relacionales

3.1 INTRODUCCIÓN
Como expliqué en el capítulo 1, en este libro hago énfasis en gran medida en las bases de datos
relacionales. En particular, la parte II cubre los fundamentos teóricos de dichos sistemas (el mo-
delo relacional) con una profundidad considerable. La finalidad del presente capítulo consiste
simplemente en dar una introducción preliminar, intuitiva y muy informal para el material que
abordaremos en la parte II (y hasta cierto punto, también en las secciones subsiguientes), con el
fin de allanar el camino para una mejor comprensión de las secciones posteriores del libro. En
los capítulos posteriores explicaremos la mayoría de los temas mencionados de manera más for-
mal y con mayor detalle.

3.2 UNA MIRADA INFORMAL AL MODELO RELACIONAL

Hemos mencionado en varias ocasiones que los sistemas relacionales se basan en un fundamento
formal, o teoría, denominado el modelo relacional de datos. De manera intuitiva, lo que esta afir-
mación significa (entre otras cosas) es que en dichos sistemas:
1. Aspecto estructural: El usuario percibe la información de la base de datos como tablas
y nada más que tablas;
2. Aspecto de integridad: Estas tablas satisfacen ciertas restricciones de integridad (que
explicaremos hacia el final de esta sección);
3. Aspecto de manipulación: Los operadores disponibles para que el usuario manipule
estas tablas —por ejemplo, para fines de recuperación de datos— son operadores que de
rivan tablas a partir de tablas. En particular, tres de estos operadores son importantes:
restringir, proyectar y juntar (este último operador también es conocido como combinar
o reunir).
La figura 3.1 muestra una base de datos relacional muy sencilla, la base de datos de depar-
tamentos y empleados. Como puede ver, la base de datos es en efecto "percibida como tablas"
(y los significados de dichas tablas pretenden ser evidentes pos sí mismos).

58
 Capítulo 3 / Una introducción a las bases de datos relacionales 59

DEPTO DEPTO# NOMDEPTO PRESUPUESTO

D1 Comercialización 10M
D2 Desarrollo 12M
D3 Investigación 5M

EMP EMP# NOMEMP DEPTO# SALARIO

E1 López Cheng D1 40K

E2 Pérez D1 42K
E3 Hernández D2 30K
E4 D2 35K

Figura 3.1 La base de datos de departamentos y empleados (valores de ejemplo).

La figura 3.2 muestra algunos ejemplos de las operaciones restringir, proyectar y juntar apli-
cadas a la base de datos de la figura 3.1. Las siguientes son (de manera muy vaga) las defini-
ciones de dichas operaciones:
■ La operación restringir (también conocida como seleccionar) extrae las filas especificadas
de una tabla.
■ La operación proyectar extrae las columnas especificadas de una tabla.
■ La operación juntar reúne dos tablas con base en valores comunes de una columna común.

Restringir:
Resultado: DEPTO# NOMDEPTO PRESUPUESTO

DEPTOs donde PRESUPUESTO > 8M D1 Comercialización 10M

D2 Desarrollo 12M

Proyectar: Resultado:
DEPTO# PRESUPUESTO

DEPTOs sobre DEPTO#, PRESUPUESTO D1 10M

D2 12M
D3 5M

Juntar:
DEPTOs y EMP; sobre DEPTO#

Resultado: DEPTO# NOMDEPTO PRESUPUESTO EMP# NOMEMP SALARIO

D1 Comercialización 10M E1 López 40K

D1 Comercialización 10M E2 Cheng 42K
D2 Desarrollo 12M E3 Pérez 30K
D2 Desarrollo 12M E4 Hernández 35K

Figura 3.2 Operaciones restringir, proyectar y juntar (ejemplos).

60 Parte I / Preliminares

De los tres ejemplos, el único que puede necesitar de una mayor explicación es el ú el
ejemplo de juntar. Observe primero que, en efecto, las dos tablas DEPTO y EMP tienen de
hecho una columna en común, DEPTO#; de modo que pueden ser juntadas con base en los \ alo
res comunes de esa columna. Una fila dada de la tabla DEPTO será combinada con una fila dad;
de la tabla EMP (para producir una fila de la tabla de resultado) únicamente si las dos filas
cuestión tienen un valor común para DEPTO#. Por ejemplo, las filas DEPTO y EMP
DEPTO# NOMDEPTO PRESUPUESTO EMP# NOMEMP DEPTO# SALARIO

D1 Comercialización 10M E1 López D1 40K

(los nombres de columna son mostrados por claridad) se combinan para producir la fila re
sultante

DEPTO# NOMDEPTO PRESUPUESTO EMP# NOMEMP SALARIO

D1 Comercialización 10M E1 López 40K

ya que tienen el mismo valor, D1, en la columna común. Observe que el valor común ap¡
una sola vez y no dos, en la fila resultante. El resultado global de la junta contiene todas las fil
posibles que pueden ser obtenidas de esta manera (y ninguna otra fila). En particular, ob¡
que debido a que ninguna fila de EMP tiene un valor D3 en DEPTO# (es decir, ningún empleado
está actualmente asignado a ese departamento), no aparece en el resultado una fila para D3. aun
cuando sí existe una fila para D3 en la tabla DEPTO.
Ahora bien, una idea que la figura 3.2 muestra claramente es que el resultado de cada una
de las tres operaciones es otra tabla (en otras palabras, los operadores son en efecto "operadores
que derivan tablas a partir de tablas", como mencioné anteriormente). Ésta es la propiedad de
cierre de los sistemas relacionales y es muy importante. Básicamente, debido a que la salid
de cualquier operación es el mismo tipo de objeto que la entrada —todas son tablas— entonces
la salida de una operación puede convertirse en la entrada de otra. Por lo tanto es posible, por
ejemplo, tomar una proyección de una junta, o una junta de dos restricciones, o una restricción
de una proyección, y así sucesivamente. En otras palabras, es posible escribir
expresiones anidadas; es decir, expresiones en las que los propios operandos están
representados por expresiones generales, en vez de simples nombres de tablas. Este hecho tiene a
su vez numerosas consecuencias importantes, como veremos más adelante (tanto en este
capítulo como en otros subsiguientes).
Por cierto, cuando decimos que la salida de cada operación es otra tabla, es importante en-
tender que estamos hablando desde un punto de vista conceptual. No pretendemos decir que e
sistema realmente tenga que materializar el resultado de cada operación individual en su totali-
dad. Por ejemplo, suponga que intentamos calcular una restricción de una junta. Entonces, tan
pronto como se forma una fila dada de la junta, el sistema puede confrontar de inmediato esa fila
con la condición de restricción especificada para ver si pertenece al resultado final, y descartarla
de inmediato de no ser así. En otras palabras, el resultado intermedio, que es la salida de la junta.
no podría existir como una tabla completamente materializada. De hecho, como regla general.
el sistema procura en gran medida no materializar en su totalidad los resultados intermedios por
razones obvias de rendimiento. Nota: Si los resultados intermedios son materializados en su to-
talidad, a la estrategia de evaluación general de la expresión se le denomina (en forma nada sor
 Capítulo 3 / Una introducción a las bases de datos relacionales 61

prendente) evaluación materializada; si los resultados intermedios son cedidos poco a poco a
las operaciones subsiguientes, se le llama evaluación canalizada.
Otra idea ilustrada claramente por la figura 3.2 es que todas las operaciones se realizan un
conjunto a la vez, no una fila a la vez; esto significa que los operandos y resultados son tablas
completas en vez de sólo filas individuales, y que las tablas contienen conjuntos de filas. (Por
supuesto, una tabla que contiene un conjunto de una sola fila es legal, como lo es también una
tabla vacía, es decir, una tabla que no contiene fila alguna.) Por ejemplo, la junta de la figura 3.2
opera sobre dos tablas de tres y cuatro filas respectivamente, y devuelve una tabla resultante de
cuatro filas. En contraste, las operaciones en los sistemas no relacionales se encuentran gene-
ralmente en el nivel de una fila a la vez o un registro a la vez; de ahí que esta capacidad de proce-
samiento de conjuntos sea una de las principales características distintivas de los sistemas
relacionales (en la sección 3.5 a continuación, encontrará una explicación más amplia).
Regresemos por un momento a la figura 3.1. Hay un par de puntos adicionales con relación
a la base de datos de ejemplo de esa figura:
■ Primero, observe que los sistemas relacionales sólo requieren que la base de datos sea
percibida por el usuario en forma de tablas. Las tablas son la estructura lógica en un sis
tema relacional, no la estructura física. De hecho, en el nivel físico el sistema es libre de
almacenar los datos en cualquier forma en que desee —utilizando archivos secuenciales,
indexación, dispersión, cadenas de apuntadores, compresión, etcétera— con tal de que
pueda asociar la representación almacenada con tablas en el nivel lógico. En otras pala
bras, las tablas representan una abstracción de la forma en que los datos están almace
nados físicamente; una abstracción en la cual se ocultan al usuario diversos detalles del
nivel de almacenamiento, como la ubicación de los registros almacenados, la secuencia
de los registros almacenados, las representaciones de los valores de los datos almacenados,
los prefijos de registros almacenados, las estructuras de acceso almacenadas (como los
índices), etcétera.
Por cierto, el término "estructura lógica" en el párrafo anterior pretende abarcar los
niveles tanto conceptual como externo, en términos de ANSI/SPARC. La idea es que —co-
mo expliqué en el capítulo 2— en un sistema relacional los niveles conceptual y externo
serán relacionales, pero el nivel físico o interno no lo será. De hecho, la teoría relacional
como tal no tiene absolutamente nada que decir acerca del nivel interno; de nuevo, se ocupa
de cómo luce la base de datos ante el usuario. * El único requerimiento es que cualquiera
que sea la estructura elegida, deberá implementar por completo la estructura lógica.
■ Segundo, las bases de datos relacionales acatan un principio interesante, denominado Prin
cipio de Información: Todo el contenido de información de la base de datos está repre
sentado en una y sólo una forma; es decir, como valores explícitos dentro de posiciones de
columnas dentro de filas dentro de tablas. Este método de representación es el único método
disponible (por supuesto, en el nivel lógico) en un sistema relacional. En particular, no hay

* Es un hecho desafortunado que la mayoría de los productos SQL actuales no manejen en forma adecuada
este aspecto de la teoría. Para ser más específicos, por lo regular sólo manejan transformaciones concep-
tuales/internas más bien restrictivas (por lo regular transforman directamente una tabla lógica en un archivo
almacenado). Como consecuencia, no proporcionan tanta independencia física de datos como la que en
teoría es capaz de proporcionar la tecnología relacional.
62 Parte I / Preliminares

apuntadores que conecten una tabla con otra. Por ejemplo, en la figura 3.1 hay una cone-
xión entre la fila D1 de la tabla DEPTO y la fila El de la tabla EMP, ya que el empleado
El trabaja en el departamento D1; pero esa conexión no está representada por un apunta
dor, sino por la aparición del valor D1 en la posición DEPTO# de la fila de EMP para E
En contraste, en los sistemas no relacionales (por ejemplo IMS o IDMS), dicha informa-
ción se representa por lo regular —como mencioné en el capítulo 1— por medio de
algún tipo de apuntador que sea visible de manera explícita para el usuario.
Nota: Cuando decimos que no hay apuntadores en una base de datos relacional no
queremos decir que no pueda haber apuntadores en el nivel físico; al contrario, en realidad 3.3 R
puede haberlos y de hecho casi es seguro que los haya. Aunque, nuevamente, en un sistema
relacional todos estos detalles de almacenamiento físico quedan ocultos ante el usuario.

Es suficiente por lo que respecta a los aspectos estructural y de manipulación del modelo
relacional; ahora pasaremos al aspecto de la integridad. Considere una vez más la base de datos
de departamentos y empleados de la figura 3.1. En la práctica podría requerirse que esa base de
datos cumpliera cualquier cantidad de restricciones de integridad; por ejemplo, que los salario
de los empleados tuvieran que estar (digamos) en un rango de 25K a 95K, los presupuestos de
los departamentos tuvieran que estar (por decir algo) en el rango de 1M a 15M, etcétera. Sil
bargo, algunas de estas restricciones son de una importancia pragmática tal, que gozan de una
nomenclatura especial. Para ser más específicos:
1. Cada fila de la tabla DEPTO debe incluir un valor DEPTO# único; en forma similar, cada
fila de la tabla EMP debe incluir un valor de EMP# único. En términos generales, decimos
que las columnas DEPTO# de la tabla DEPTO y EMP# de la tabla EMP son las claves pr
marias de sus respectivas tablas. (Recuerde que en las figuras del capítulo 1 señalamos las
claves primarias mediante un doble subrayado.)
2. Cada valor DEPTO# de la tabla EMP debe existir como un valor DEPTO# en la tabla
DEPTO, para reflejar el hecho de que cada empleado debe estar asignado a un departamento
existente. En términos generales, decimos que la columna DEPTO# de la tabla EMP es una
clave externa que hace referencia a la clave primaria de la tabla DEPTO.
Cerramos esta sección con una definición del modelo relacional para fines de futuras re
ferencias (no obstante que la definición es bastante abstracta y no será muy comprensible en es
etapa). Para ser breves, el modelo relacional consta de los siguientes cinco componentes:

1. Un conjunto abierto de tipos escalares (incluyendo en particular el tipo lógico o valor

verdadero);
2. Un generador de tipos de relación y una interpretación propuesta de dichos tipos;
3. Herramientas para definir variables de relación de dichos tipos de relación generados;
4. Una operación asignación relacional para asignar valores de relación a las variables de
relación mencionadas;
5. Un conjunto abierto de operadores relacionales genéricos para derivar valores de relación
de otros valores de relación.

Como puede ver, el modelo relacional es mucho más que sólo "tablas con restringir, proyectar
y juntar", aunque a menudo se le caracteriza informalmente de esa manera.
 Capítulo 3 / Una introducción a las bases de datos relacionales 63

Nota: Tal vez le sorprendió que no mencionáramos explícitamente a las restricciones de in-
tegridad en la definición anterior. Sin embargo, el hecho es que dichas restricciones representan
sólo una aplicación (aunque una muy importante) de los operadores relacionales; esto es, que
dichas restricciones se formulan —en todos los casos de manera conceptual— en términos de di-
chos operadores, como veremos en el capítulo 8.

3.3 RELACIONES Y VARIABLES DE RELACIÓN

Si es cierto que una base de datos relacional es en esencia sólo una base de datos en la que los
datos son percibidos como tablas —y, por supuesto, esto es cierto—, entonces una buena pre-
gunta es: ¿exactamente por qué llamamos relacional a dicha base de datos? La respuesta es sen-
cilla (de hecho, la mencionamos en el capítulo 1): "Relación" es sólo un término matemático
para una tabla; para ser precisos, una tabla de cierto tipo específico (los detalles se expondrán
en el capítulo 5). De ahí que, por ejemplo, podamos decir que la base de datos de departamen-
tos y empleados de la figura 3.1 contiene dos relaciones.
Ahora, en contextos informales es común tratar los términos "relación" y "tabla" como si
fueran sinónimos; de hecho, el término "tabla" se usa informalmente con mucha más frecuen-
cia que el término "relación". Pero vale la pena dedicar un momento a comprender por qué se
introdujo en primer lugar el término "relación". En resumen, la explicación es la siguiente:
■ Como hemos visto, los sistemas relacionales se basan en el modelo relacional. A su vez, este
modelo es una teoría abstracta de datos que está basada en ciertos aspectos de las matemáti
cas (principalmente en la teoría de conjuntos y la lógica de predicados).
■ Los principios del modelo relacional fueron establecidos originalmente en 1969-70 por E.
F. Codd (en ese entonces, investigador de IBM). Fue a fines de 1968 que Codd, matemático
de formación, descubrió por primera vez que la disciplina de las matemáticas podía ser
usada para dar ciertos principios sólidos y cierto rigor a un campo —la administración de
base de datos— que hasta ese momento era muy deficiente en cualquiera de estas cuali
dades. En un principio, las ideas de Codd se difundieron ampliamente en un artículo que
hoy en día es clásico: "A Relational Model of Data for Large Shared Data Banks" (vea la
referencia [5.1] del capítulo 5).
■ Desde entonces, esas ideas —ahora aceptadas casi en forma universal— han tenido gran in
fluencia en prácticamente cada uno de los aspectos de la tecnología de base de datos; y de
hecho también en otros campos, como los de la inteligencia artificial, el procesamiento del
lenguaje natural y el diseño de sistemas de hardware.
Ahora bien, el modelo relacional como lo formuló originalmente Codd hizo utilizó deli-
beradamente ciertos términos (como el propio término "relación") que en ese momento no eran
familiares en los círculos de tecnología de la información (aunque en algunos casos los concep-
tos sí lo eran). El problema fue que muchos de los términos más conocidos eran muy confusos,
carecían de la precisión necesaria para una teoría formal como la que Codd proponía. Por ejem-
plo, considere el término "registro". En diferentes momentos y en distintos contextos este tér-
mino puede significar ya sea la ocurrencia de un registro o un tipo de registro; un registro lógico
o un registro físico; un registro almacenado o un registro virtual, y quizás también otras cosas.
Por lo tanto, el modelo relacional no emplea en absoluto el término "registro"; en su lugar usa
64 Parte I / Preliminares

el término "tupia", al que es posible asignar una definición muy precisa. Aquí no damos esa
definición ya que para los fines actuales, es suficiente decir que el término "tupia" corresponde
aproximadamente a la noción de una fila (tal como el término "relación" corresponde aproxi-
madamente a la noción de una tabla). Cuando comencemos a estudiar los aspectos más formales
de los sistemas relacionales (en la parte II), haremos uso de la terminología formal, pero en este
capítulo no pretendemos ser tan formales (al menos no en su mayoría) y nos apegaremos prin
cipalmente a términos como "fila" y "columna" que son razonablemente familiares. Sin em-
bargo, un término formal que sí usaremos mucho a partir de este punto es el término "relación"
Regresemos una vez más a la base de datos de departamentos y empleados de la figura 3.1 para
hacer otro señalamiento importante. El hecho es que DEPTO y EMP en esa base de datos son en
realidad variables de relación; es decir, variables cuyos valores son valores de relación
(diferentes valores de relación en diferentes momentos). Por ejemplo, suponga que EMP tiene
actualmente el valor —es decir, el valor de relación— que se muestra en la figura 3.1 y suponga
que eliminamos la fila de Hernández (el empleado número E4):

DELETE EMP WHERE EMP# = 'E4' ;

El resultado aparece en la figura 3.3.

EMP EMP# NOMEMP DEPTO# SALARIO

E1 López D1 40K
E2 Cheng D1 42K
E3 Pérez D2 30K

Figura 3.3 La variable de relación EMP después de eliminar la fila E4.

De manera conceptual, lo que sucedió aquí es que el valor de relación anterior de EMP fue
reemplazado en bloque por un valor de relación completamente nuevo. Desde luego, el valor
anterior (con cuatro filas) y el nuevo (con tres) son muy similares, pero de manera conceptual
son valores diferentes. De hecho la operación de eliminación en cuestión es básicamente una
forma abreviada de una cierta operación de asignación relacional que podría ser como la si-
guiente:
EMP := EMP MINUS ( EMP WHERE EMP# • ' E4' ) ;

{Nota: Tanto el DELETE original como la instrucción de asignación equivalente están expre-
sadas en un lenguaje denominado Tutorial D [3.3]. MINUS es la palabra reservada de Tuto-
rial D para la operación de diferencia relacional; vea el capítulo 6). Como en todas las
asignaciones, lo que sucede aquí, hablando en forma conceptual, es que (a) se evalúa la expre-
sión de la derecha y luego (b) el resultado de la evaluación se asigna a la variable de la izquierda
(por supuesto, la parte izquierda debe por definición identificar específicamente a una variable).
Por lo tanto, como ya mencionamos, el efecto neto es reemplazar el valor "anterior" de EMP por
uno "nuevo".
 Capítulo 3 / Una introducción a las bases de datos relacionales 65

Desde luego, las operaciones relacionales INSERT y UPDATE también son en esencia for-
mas abreviadas de ciertas asignaciones relacionales.
Ahora bien, desgraciadamente gran parte de la literatura usa el término relación cuando en
realidad se refiere a una variable de relación (al igual que cuando se refiere a una relación como
tal; es decir, a un valor de relación). Sin embargo, esta práctica ha llevado ciertamente a una con-
fusión. Por lo tanto, a lo largo de este libro, haremos una cuidadosa distinción entre las variables
de relación y las relaciones como tales; de hecho, de acuerdo con la referencia [3.3], usaremos
el término varrel como una abreviatura conveniente de variable de relación (o variable rela-
cional) y tendremos cuidado de enunciar nuestras observaciones en términos de varrels (y no de
relaciones) cuando realmente nos refiramos a las variables relacionales.
Nota: Debo advertirle que el término varrel no es de uso común; aunque debería serlo.
En realidad creemos que es importante aclarar la diferencia entre las relaciones como tales
(es decir, los valores de relación) y las variables de relación, aunque en ediciones previas de
este libro no se haya hecho y aunque la mayoría de la literatura actual de base de datos siga
sin hacerlo.

QUE SIGNIFICAN LAS RELACIONES

En el capítulo 1, mencioné el hecho de que, en las relaciones, las columnas tienen tipos de datos
asociados.* Y al final de la sección 3.2, dije que el modelo relacional incluye un "conjunto
abierto de tipos [de datos]". Lo que esto significa (entre otras cosas) es que los usuarios podrán
definir sus propios tipos y desde luego, también usar los tipos definidos por el sistema (o inte-
grados). Por ejemplo, podríamos definir los tipos de la siguiente manera (de nuevo la sintaxis
de Tutorial D; los puntos suspensivos "..." representan parte de las definiciones que no son
aplicables a la explicación actual):
TYPE EMP# ... ;
TYPE NOMBRE . . . ;
TYPE DEPTO# ... ;
TYPE DINERO ... ;

Por ejemplo, el tipo EMP# puede ser visto como el conjunto de todos los números de empleado
posibles; el tipo NOMBRE como el conjunto de todos los nombres posibles; y así sucesiva-
mente.
Ahora considere la figura 3.4, que es básicamente la parte EMP de la figura 3.1, ampliada
para mostrar los tipos de datos de las columnas. Como la figura indica, cada relación —para ser
más precisos, cada valor de relación— tiene dos partes, un conjunto de parejas nombre-de-co-
lumna:nombre-de-tipo (el encabezado) y un conjunto de filas que se apegan a ese encabezado
(el cuerpo). Nota: En la práctica, a menudo ignoramos los componentes del encabezado nom-
bre-de-tipo (como en efecto lo hemos hecho en ejemplos anteriores), pero debe entenderse que
siempre están ahí conceptualmente.
Ahora bien, existe una forma de pensar muy importante (aunque tal vez no muy común)
acerca de las relaciones, y es como sigue:

*E1 término relacional más usual para los tipos de datos es dominios, como veremos en el capítulo 5.
66 Parte I / Preliminares

EMP

EMP# : EMP# NOMEMP : NOMBRE DEPTO# : DEPTO# SALARIO : DINERO |

|
E1 López Cheng D1 40K
E2 Pérez D1 42K
E3 Hernández D2 30K
E4 D2 35K

Figura 3.4 Ejemplo del valor de relación EMP, que muestra los tipos de columnas.

■ Primero, dada una relación r, el encabezado de r denota un cierto predicado o función va-
luada como verdadera;
■ Segundo, como mencioné brevemente en el capítulo 1, cada fila en el cuerpo de r denota
una cierta proposición verdadera, obtenida del predicado por medio de la sustitucic
ciertos valores de argumento del tipo apropiado en los indicadores de posición o
paráme-
tros de ese predicado ("creando un ejemplar del predicado").
Por ejemplo, en el caso de la figura 3.4, el predicado luce como lo siguiente:
El empleado EMP# se llama NOMEMP, trabaja en el departamento DEPTO# y gana
salario de SALARIO
(los parámetros son EMP#, NOMEMP, DEPTO# y SALARIO, que corresponden por sup a
las cuatro columnas de EMP). Y las proposiciones verdaderas correspondientes son:
El empleado El se llama López, trabaja en el departamento D1 y gana el salario 40K
(proposición que se obtuvo al sustituir los parámetros correspondientes por el valor El, de tipo 3.5
EMP#; el valor López, de tipo NOMBRE; el valor DI, de tipo DEPTO#; y el valor 40K.
de tipo DINERO);
El empleado E2 se llama Cheng, trabaja en el departamento DI y gana el salario 42K
(proposición que se obtuvo al sustituir los parámetros correspondientes por el valor E2. de t
EMP#; el valor Cheng, de tipo NOMBRE; el valor D1, de tipo DEPTO# y el valor 42K. de
tipo DINERO); y así sucesivamente. Por lo tanto, resumiendo:

■ Los tipos son (conjuntos de) cosas de las que podemos hablar;
■ Las relaciones son (conjuntos de) cosas que decimos acerca de las cosas de las que
podemos hablar.
(Hay una analogía que podría ayudarle a apreciar y recordar estos puntos importantes: Los tipo
son a las relaciones lo que los sustantivos son a las oraciones.) Por lo tanto, en el ejemplo, las
cosas de las que podemos hablar son los números de empleado, los nombres, los números de
de-parlamento y los valores de dinero, mientras que las cosas que decimos son expresiones
ver-daderas de la forma "El empleado con el número de empleado especificado tiene el n
especificado, trabaja en el departamento especificado y gana el salario especificado".
 Capítulo 3 / Una introducción a las bases de datos relacionales 67

De lo anterior se desprende que:

■ Primero, tanto los tipos como las relaciones son necesarios (sin tipos, no tenemos nada de
qué hablar; sin relaciones, no podemos decir nada).
■ Segundo, los tipos y las relaciones son suficientes, así como necesarios; es decir, no nece
sitamos nada más, hablando de manera lógica.
Nota: También se desprende que los tipos y las relaciones no son la misma cosa. Desafor-
tunadamente, ciertos productos comerciales —¡por definición, no los relacionales!— están con-
fundidos en este punto. Abordaremos esta confusión en el capítulo 25 (sección 25.2).
Por cierto, es importante entender que toda relación tiene un predicado asociado; inclu-
yendo las relaciones que se derivan de otras mediante operadores relaciónales como el de juntar.
Por ejemplo, la relación DEPTO de la figura 3.1 y las tres relaciones resultantes de la figura 3.2
tienen los siguientes predicados:
■ DEPTO: "El departamento DEPTO# se llama NOMDEPTO y tiene un presupuesto PRE
SUPUESTO".
■ Restricción de DEPTO donde PRESUPUESTO > 8M: "El departamento DEPTO# se llama
NOMDEPTO y tiene un presupuesto PRESUPUESTO, el cual es mayor a ocho millones
de dólares".
■ Proyección de DEPTO sobre DEPTO# y PRESUPUESTO: "El departamento DEPTO#
tiene algún nombre y tiene un presupuesto PRESUPUESTO".
■ Junta de DEPTO y EMP sobre DEPTO#: "El departamento DEPTO# se llama NOMDEPTO
y tiene un presupuesto PRESUPUESTO y el empleado EMP# se llama NOMEMP, trabaja en
el departamento DEPTO# y gana un salario de SALARIO". Observe que este predicado tiene
seis parámetros, no siete; las dos referencias a DEPTO# denotan el mismo parámetro.

3.5 OPTIMIZACION
Como expliqué en la sección 3.2, todas las operaciones relacionales tales como restringir,
proyectar y juntar son operaciones en el nivel de conjunto. Como consecuencia, se dice a menudo
que los lenguajes relacionales no son de procedimientos, en el sentido de que los usuarios es-
pecifican el qué, no el cómo; es decir, dicen lo que desean sin especificar un procedimiento para
obtenerlo. El proceso de "navegar" por los datos a fin de satisfacer la petición del usuario es rea-
lizado automáticamente por el sistema, en vez de ser realizado en forma manual por el usuario.
Por esta razón, en ocasiones se dice que los sistemas relacionales realizan una navegación au-
tomática. En contraste, en los sistemas no relacionales la navegación es generalmente respon-
sabilidad del usuario. La figura 3.5 muestra una ilustración impactante de los beneficios de la
navegación automática y compara una instrucción INSERT de SQL con el código de "navega-
ción manual" que tendría que escribir el usuario para lograr el efecto equivalente en un sistema
no relacional (de hecho un sistema de red CODASYL; el ejemplo se tomó de la referencia [1.5]
del capítulo sobre bases de datos de red). Nota: La base de datos es la base de datos de proveedo-
res y partes que ya conocemos. Para una mayor explicación, consulte la sección 3.9.
A pesar de las observaciones del párrafo anterior, debemos decir que, aunque sea común,
el término no procedimientos no es muy satisfactorio, ya que las categorías de procedimientos