Bases de datos

Todos los conceptos referentes a las bases de datos están hoy muy claros y definidos
formalmente, al contrario que los de las bases de conocimiento. La tecnología de gestión de
bases de datos se halla en una etapa muy madura. Las bases de datos han evolucionado
durante los pasados 30 años desde sistemas de archivos rudimentarios hasta sistemas
gestores de complejas estructuras de datos que ofrecen un gran número de posibilidades. Los
principales objetivos de un DBMS son los siguientes:

1. Independencia lógica y física de los datos: se refiere a la capacidad de modificar una

definición de esquema en un nivel de la arquitectura sin que esta modificación afecte al
nivel inmediatamente superior. Para ello un registro externo en un esquema externo no
tiene por qué ser igual a su registro correspondiente en el esquema conceptual.
2. Redundancia mínima: se trata de usar la base de datos como repositorio común de
datos para distintas aplicaciones.
3. Acceso concurrente por parte de múltiples usuarios: control de concurrencia mediante
técnicas de bloqueo o cerrado de datos accedidos.
4. Distribución espacial de los datos: la independencia lógica y física facilita la posibilidad
de sistemas de bases de datos distribuidas. Los datos pueden encontrarse en otra
habitación, otro edificio e incluso otro país. El usuario no tiene por qué preocuparse de
la localización espacial de los datos a los que accede.
5. Integridad de los datos: se refiere a las medidas de seguridad que impiden que se
introduzcan datos erróneos. Esto puede suceder tanto por motivos físicos (defectos de
hardware, actualización incompleta debido a causas externas), como de operación
(introducción de datos incoherentes).
6. Consultas complejas optimizadas: la optimización de consultas permite la rápida
ejecución de las mismas.
7. Seguridad de acceso y auditoria: se refiere al derecho de acceso a los datos
contenidos en la base de datos por parte de personas y organismos. El sistema de
auditoria mantiene el control de acceso a la base de datos, con el objeto de saber qué
o quién realizó una determinada modificación y en qué momento.
8. Respaldo y recuperación: se refiere a la capacidad de un sistema de base de datos de
recuperar su estado en un momento previo a la pérdida de datos.
9. Acceso a través de lenguajes de programación estándar: se refiere a la posibilidad ya
mencionada de acceder a los datos de una base de datos mediante lenguajes de
programación ajenos al sistema de base de datos propiamente dicho.

Una base de datos típica conlleva la existencia de tres tipos de usuario con relación a su
diseño, desarrollo y uso:

1. El administrador de bases de datos (DBA: Database Administrator): diseña y mantiene

la DB.
2. El desarrollador de aplicaciones (programador): implementa las transacciones e
interfaces.
3. Los usuarios finales: consultan y editan los datos de la DB mediante un lenguaje de
consulta de alto nivel.

No cabe duda de que la parte más importante es la llevada a cabo por el DBA. A él le
corresponde la elección de un determinado modelo de datos y el diseño de la DB. La etapa de
diseño es la más importante, ya que es ahí donde se refleja la semántica de la información
contenida en la DB a través del denominado esquema conceptual. Nos detendremos sobre
este tema cuando estudiemos el modelado de datos.

En general, podemos decir que el propósito de una base de datos es doble:

a. responder a consultas sobre los datos que contiene, y

b. ejecutar transacciones

1
 Una consulta (query) se expresa como una expresión lógica sobre los objetos y relaciones
definidos en el esquema conceptual; el resultado es la identificación de un subconjunto lógico
de la base de datos. Una transacción consiste en un número de consultas y operaciones de
modificación o actualización sobre un subesquema. Las transacciones son atómicas 8 por
definición: todos los pasos de una transacción han de ser debidamente ejecutados y
confirmados como requisito previo para que la transacción pueda ser llevada a cabo en su
conjunto, en caso contrario ha de ser invalidada.

Para llevar a cabo estas tareas, el DBA tiene a su disposición la principal herramienta de
una base de datos, el sistema gestor de bases de datos (DBMS). A través de éste se realizan
todas las operaciones con los datos (consultas y transacciones), de forma que al DBA no le
atañe la manera en que los datos se encuentran almacenados físicamente, pudiéndose
concentrar en los aspectos conceptuales en cuanto a diseño, desarrollo y mantenimiento. Un
DBMS típico integra los siguientes componentes:

 Un lenguaje de definición de datos (DDL: Data Definition Language).

 Un lenguaje de manipulación de datos (DML: Data Manipulation Language)
 Un lenguaje de consulta (QL: Query Language).
 De forma accesoria, pero ya casi obligada, los DBMS modernos añaden un interfaz de
usuario gráfico (GUI: Graphical User Interface).
 consultas mediante ejemplo (posiblemente gráficas) ((G)QBE: (Graphical) Query By
Example)

El QL por excelencia es el llamado Structured Query Language (SQL), que, aun con
muchas modificaciones y adiciones, es un estándar de las DBMS relacionales (RDBMS:
Relational Database Management System). Hoy en día, sin embargo, con la llegada de las
DBMS orientadas a objetos (ODBMS: Object Database Management System), otros estándar
de consulta se han hecho necesarios; así ha nacido otro estándar, OQL (Object Query
Language), como resultado de una de las primeras implementaciones de ODBMSs (O 2, de O2
Technologies). Además, una base de datos puede ser consultada y modificada mediante
técnicas "externas", es decir, mediante lenguajes de programación de propósito general,
típicamente de tercera generación (3GL). Hoy en día, estas técnicas se hallan muy avanzadas,
existiendo estándares que simplifican el acceso a diferentes DBMSs de forma transparente,
tales como ODBC (Open Database Connectivity), que garantizan el acceso a los datos de
bases, posiblemente remotas, de distintas compañías.

En general, las bases de datos no fueron pensadas para almacenar información compleja,
sino grandes cantidades de información relativamente simple. Como ya hemos mencionado, los
datos contenidos en una DB han de ser por definición atómicos. Esto es necesario para un
correcto tratamiento de los mismos, pero por otra parte entorpece la visión de conjunto, esto es,
dificulta el tratamiento "inteligente" de entidades complejas.

Este gran inconveniente se hizo evidente una vez superada la fase de dificultades
puramente técnicas. Cuando las bases de datos comenzaron a ser utilizadas para otras tareas
que no fuesen el guardar los datos correspondientes a una compañía de seguros o una entidad
bancaria. Entonces se planteó la necesidad de prestar mayor atención al diseño lógico de la
DB, en vez de al nivel físico.

Definiciones formales y arquitecturas

La definición de un sistema de información es la descripción detallada de la arquitectura del

sistema. Las arquitecturas de bases de datos han evolucionado mucho desde sus comienzos,
aunque la considerada estándar hoy en día es la descrita por el comité ANSI/X3/SPARC
(Standard Planning and Requirements Committee of the American National Standards Institute
on Computers and Information Processing), que data de finales de los años setenta. Este
comité propuso una arquitectura general para DBMSs basada en tres niveles o esquemas: el
nivel físico, o de máquina, el nivel externo, o de usuario, y el nivel conceptual. Así mismo

2
describió las interacciones entre estos tres niveles y todos los elementos que conforman cada
uno de ellos.

La arquitectura que vamos a describir brevemente corresponde a un sistema centralizado;

no consideramos relevante en el marco de este trabajo la descripción de los sistemas
distribuidos. Esta arquitectura tiene dos partes fundamentales: la de descripción de datos y la
de manipulación de datos, organizadas en torno al diccionario de datos. A su vez, cada una de
estas dos partes se organiza en torno a tres niveles: externo, conceptual e interno. En la Figura
un hexágono representa el papel del DBA y un rectángulo representa un procesador. En
realidad, la figura del DBA agrupa los papeles de administrador de sistema, administrador de
empresa y administrador de aplicaciones en lo que se refiere a la base de datos. El papel del
administrador de empresa es definir el esquema conceptual usando el interfaz 1. El procesador
de esquema conceptual compila este esquema y si es correcto se almacena en el diccionario
de datos, que contiene todos los esquemas y reglas de proyección. Los administradores de
aplicaciones se encargan de definir los esquemas externos, usando lenguajes específicos de
descripción de esquemas externos (interfaz 2), según las necesidades de los usuarios y las
posibilidades del sistema. Para especificar las reglas de proyección entre un esquema externo
y el esquema conceptual, el administrador de aplicaciones puede consultar el esquema
conceptual mediante el interfaz 3. Cuando se define correctamente un esquema externo con
sus reglas de proyección asociadas, es compilado por el procesador de esquema externo y
almacenado en el diccionario de datos. Por último el administrador del sistema, mediante un
lenguaje de descripción interno (interfaz 6) completa la descripción de la base de datos
definiendo su esquema interno y las reglas que lo proyectan sobre el esquema conceptual.
Estos diferentes lenguajes se agrupan en los dos tipos generales que antes mencionamos:
lenguajes de descripción de datos (DDL) y lenguajes de manipulación de datos (DML).

3
 Arquitectura funcional ANSI/X3/SPARC

El nivel clave en esta arquitectura, como se puede adivinar, es el conceptual. Éste contiene
la descripción de las entidades, relaciones y propiedades de interés para la empresa (UoD), y
constituye una plataforma estable desde la que proyectar los distintos esquemas externos, que
describen los datos según los programadores, sobre el esquema interno, que describe los
datos según el sistema físico. Las posibles proyecciones de datos quedan resumidas en la
figura.

4
 Posibles proyecciones de datos

Como cabría esperar, en la práctica cotidiana de implementación de bases de datos, esta

arquitectura no es seguida al cien por cien por los DBMSs comerciales. Existen muy pocos
productos que contengan aplicaciones para facilitar la fase de análisis. Por lo general, el nivel
conceptual se obvia en los productos comerciales, salvo honrosas excepciones. Lo habitual es
que el DBA realice el modelado conceptual usando sus propios recursos, o tal vez asistido por
alguna aplicación de análisis, ya sea general o específica. El procesador del esquema
conceptual, es por tanto el propio DBA. Los DBMSs sí suelen ofrecer facilidades para la
creación de esquemas externos, pero sin pasar por el nivel conceptual. Por supuesto, un
DBMS comercial no está obligado a seguir las recomendaciones de estandarización de
arquitecturas del comité ANSI/X3/SPARC. Por lo que respecta al modelo relacional de bases
de datos, que ya existía antes del informe de este comité, los fabricantes de RDBMSs se
ajustan en mayor o menor medida al modelo teórico y, en cuanto a la arquitectura, han
intentado seguir las recomendaciones del grupo RDBTG (Relational Data Base Task Group),
parte del comité ANSI/X3/SPARC.

El resultado de este grupo fue restar importancia a las arquitecturas y realzar la de los
lenguajes e interfaces. Como consecuencia, el lenguaje SQL, está hoy en día totalmente
estandarizado, y en cambio encontramos distintas arquitecturas de RDBMS. Sin embargo se
pueden distinguir dos tipos generales de arquitecturas para estos sistemas de bases de datos,
que mostramos gráficamente respectivamente en las figuras anteriores.

Bases de datos: Modelos de datos

Los modelos de datos aportan la base conceptual para diseñar aplicaciones que hacen un uso
intensivo de datos, así como la base formal para las herramientas y técnicas empleadas en el
desarrollo y uso de sistemas de información. Con respecto al diseño de bases de datos, el
modelado de datos puede ser descrito así (Brodie): "dados los requerimientos de información y
proceso de una aplicación de uso intensivo de datos (por ejemplo, un sistema de información),
construir una representación de la aplicación que capture las propiedades estáticas y dinámicas
requeridas para dar soporte a los procesos deseados (por ejemplo, transacciones y consultas).
Además de capturar las necesidades dadas en el momento de la etapa de diseño, la
representación debe ser capaz de dar cabida a eventuales futuros requerimientos".

Un modelo de datos es por tanto una colección de conceptos bien definidos

matemáticamente que ayudan a expresar las propiedades estáticas y dinámicas de una
aplicación con un uso de datos intensivo. Conceptualmente, una aplicación puede ser
caracterizada por:

 Propiedades estáticas: entidades (u objetos), propiedades (o atributos) de esas

entidades, y relaciones entre esas entidades.

5
  Propiedades dinámicas: operaciones sobre entidades, sobre propiedades o relaciones
entre operaciones.
 Reglas de integridad sobre las entidades y las operaciones (por ejemplo,
transacciones).

Así, un modelo de datos se distingue de otro por el tratamiento que da a estas tres
categorías. El resultado de un modelado de datos es una representación que tiene dos
componentes: las propiedades estáticas se definen en un esquema y las propiedades
dinámicas se definen como especificaciones de transacciones, consultas e informes. Un
esquema consiste en una definición de todos los tipos de objetos de la aplicación, incluyendo
sus atributos, relaciones y restricciones estáticas. Correspondientemente, existirá un repositorio
de información, la base de datos, que es una instancia del esquema. Un determinado tipo de
procesos sólo necesita acceder a un subconjunto predeterminado de entidades definidas en un
esquema, por lo que este tipo de procesos puede requerir sólo un subconjunto de las
propiedades estáticas del esquema general. A este subconjunto de propiedades estáticas se le
denomina subesquema. Una transacción consiste en diversas operaciones o acciones sobre
las entidades de esquema o subesquema. Una consulta se puede expresar como una
expresión lógica sobre los objetos y relaciones definidos en el esquema; una consulta identifica
un subconjunto de la base de datos. Las herramientas que se usan para realizar las
operaciones de definición de las propiedades estáticas y dinámicas de la base de datos son los
lenguajes de definición y manipulación de datos (DDL, DML), junto con los lenguajes de
consulta (QL) que ya hemos mencionado.

La investigación moderna sobre modelos de datos se ha centrado en los aspectos lógicos

de las bases de datos y sobre los conceptos, herramientas y técnicas para el diseño de las
mismas (Brodie). Aspectos relativos a la implementación de los modelos, tales como velocidad
de ejecución, concurrencia, integridad física y arquitecturas no son factores relevantes en el
estadio de análisis de modelos de datos. La investigación más temprana sobre modelos de
datos sí estaba más centrada en los aspectos de representación física. Cuando hablamos de
modelos de datos clásicos, nos estamos refiriendo a la segunda de las generaciones de
modelos de datos. Brodie distingue cuatro generaciones:

 Modelos de datos primitivos (orientados al fichero).

 Modelos de datos clásicos.
 Modelos de datos semánticos.
 Modelos de datos de propósito específico (orientados a la aplicación).

Los modelos de datos primitivos estaban absolutamente orientados al fichero: las entidades
se representan en registros (divididos en campos, que representan sus propiedades), que se
agrupan en ficheros. Las relaciones entre entidades son únicamente aquellas que pueden ser
representadas usando directorios, por ejemplo índices y listas invertidas. Un ejemplo de DBMS
comercial de fichero, concretamente del tipo "lista invertida", es el CA-DATACOMB de
Computer Associates International.

Los modelos de datos clásicos son tres: el jerárquico, el de red y el relacional.

6
 Arquitectura separada de RDBMS

Arquitectura integrada de RDBMS

El tipo de arquitectura integrada es en general preferible a la arquitectura separada y el más

común entre los RDBMSs comerciales. De todos modos, la consecuencia de una integración
de los lenguajes de definición de datos (DDL) y los de manipulación de datos (DML) en un sólo
lenguaje (DMDL: Data Manipulation and Description Language), son a nuestro parecer
positivas y negativas. Por un lado, esta integración resulta muy cómoda para el DBA, puesto
que le basta con aprender un solo lenguaje formal para realizar todas las tareas de creación y
mantenimiento de la base de datos. Pero por otro lado, estos sistemas (tanto los separados
como los uniformes) fuerzan una proyección directa desde el nivel externo al interno, haciendo
que el nivel conceptual, el fundamental según la arquitectura ANSI/X3/SPARC, desaparezca o
se implemente en el nivel externo como una vista global externa. Por esta razón algunos DBAs
inexpertos tienden a obviar la fase de análisis, cuando de hecho es la vital para la correcta
implementación de la base de datos. Insistimos en que un buen modelado conceptual es una
condición indispensable para el correcto desarrollo de una base de datos. Pensamos que lo
ideal es usar un DBMS que nos permita desarrollar todas las tareas (de descripción y de
manipulación) lo más fácilmente posible, pero no sin antes disponer de todas las herramientas
necesarias para un correcto modelado conceptual, estén estas o no incluidas en el DBMS.

7
El enfoque jerárquico

Un DBMS jerárquico utiliza jerarquías o árboles para la representación lógica de los datos.
Los archivos son organizados en jerarquías, y normalmente cada uno de ellos se corresponde
con una de las entidades de la base de datos. Los árboles jerárquicos se representan de forma
invertida, con la raíz hacia arriba y las hojas hacia abajo

Estructura de un árbol jerárquico

Un DBMS jerárquico recorre los distintos nodos de un árbol en un preorden que requiere
tres pasos:

1. Visitar la raíz.
2. Visitar el hijo más a la izquierda, si lo hubiera, que no haya sido visitado.
3. Si todos los descendientes del segmento considerado se han visitado, volver a su
padre e ir al punto 1.

Cada nodo del árbol representa un tipo de registro conceptual, es decir, una entidad. A su
vez, cada registro o segmento está constituido por un número de campos que los describen –
las propiedades o atributos de las entidades. Las relaciones entre entidades están
representadas por las ramas. En la figura siguiente cada departamento es una entidad que
mantiene una relación de uno a muchos con los profesores, que a su vez mantienen una
relación de uno a muchos con los cursos que imparten.

Base de datos jerárquica. Estructura lógica y ejemplo

A modo de resumen, enumeramos las siguientes características de las bases de datos

jerárquicas:

8
 1. Los segmentos de un archivo jerárquico están dispuestos en forma de árbol.
2. Los segmentos están enlazados mediante relaciones uno a muchos.
3. Cada nodo consta de uno o más campos.
4. Cada ocurrencia de un registro padre puede tener distinto número de ocurrencias de
registros hijos.
5. Cuando se elimina un registro padre se deben eliminar todos los registros hijos
(integridad de los datos).
6. Todo registro hijo debe tener un único registro padre excepto la raíz.

Las reglas de integridad en el modelo jerárquico prácticamente se reducen a la ya

mencionada de eliminación en cadena de arriba a abajo. Las relaciones muchos a muchos no
pueden ser implementadas de forma directa. Este modelo no es más que una extensión del
modelo de ficheros.

Como ejemplos de DBMSs basados en este enfoque podemos citar el IMS de IBM
Corporation y el SYSTEM 2000 de Intel Corporation

El enfoque de red.

Este modelo fue el resultado de estandarización del comité CODASYL. Aunque existen algunos
DBMSs de red que no siguen las especificaciones CODASYL, en general, una base de datos
CODASYL es sinónimo de base de datos de red. El modelo de red intenta superar las
deficiencias del enfoque jerárquico, permitiendo el tipo de relaciones de muchos a muchos.

Una estructura de datos en red, o estructura plex, es muy similar a una estructura
jerárquica, de hecho no es más que un superconjunto de ésta. Al igual que en la estructura
jerárquica, cada nodo puede tener varios hijos pero, a diferencia de ésta, también puede tener
varios padres. La figura siguiente se muestra una disposición plex. En esta representación, los
nodos C y F tienen dos padres, mientras que los nodos D, E, G y H tienen sólo uno.

Estructura de datos de red

El concepto básico en el enfoque de red es el conjunto (‘set’), definido por el comité

CODASYL. Un conjunto está constituido por dos tipos de registros que mantienen una relación
de muchos a muchos. Para conseguir representar este tipo de relación es necesario que los
dos tipos de registros estén interconectados por medio de un registro conector llamado
conjunto conector. Los conjuntos poseen las siguientes características:

 El registro padre se denomina propietario del conjunto, mientras que el registro hijo se
denomina miembro.
 Un conjunto está formado en un solo registro propietario y uno o más registros
miembros.
 Una ocurrencia de conjuntos es una colección de registros, uno de ellos es el
propietario y los otros los miembros.

9
  Todos los registros propietarios de ocurrencias del mismo tipo de conjunto deben ser
del mismo tipo de registro.
 El tipo de registro propietario de un tipo de conjunto debe ser distinto de los tipos de los
registros miembro.
 Sólo se permite que un registro miembro aparezca una vez en las ocurrencias de
conjuntos del mismo tipo.
 Un registro miembro puede asociarse con más de un propietario, es decir, puede
pertenecer al mismo tiempo a dos o más tipos de conjuntos distintos. Esta situación se
puede representar por medio de una estructura multianillo.
 Se pueden definir niveles múltiples de jerarquías donde un tipo de registro puede ser
miembro en un conjunto y al mismo tiempo propietario en otro conjunto diferente.

Como ejemplos de DBMSs comerciales basados en el modelo de red cabe citar el DMS
1100 de UNIVAC; el IDMS, de Cullinane; el TOTAL, de Cincom; el EDMS, de Xerox; el
PHOLAS, de Philips; el DBOMP, de IBM, y el IDS, de Honeywell. Tanto el modelo jerárquico de
datos como el de red permiten únicamente operaciones y facilidades navegacionales primitivas.
Los tipos de relaciones permitidas vienen dadas con el modelo.

El enfoque relacional

El modelo relacional de datos supuso un gran avance con respecto a los modelos anteriores.
Este modelo está basado en el concepto de relación. Una relación es un conjunto de n-tuplas.
Una tupla, al contrario que un segmento, puede representar tanto entidades como
interrelaciones N:M. Los lenguajes matemáticos sobre los que se asienta el modelo relacional,
el álgebra y el cálculo relacionales, aportan un sistema de acceso y consultas orientado al
conjunto. La repercusión del modelo en los DBMSs comerciales actuales ha sido enorme,
estando hoy en día la gran mayoría de los gestores de bases de datos basados en mayor o
menor medida en el modelo relacional.

El concepto de modelo de datos en sí surgió al mismo tiempo que el modelo relacional de

datos fuera propuesto por su creador, Ted Codd, después de que los modelos jerárquico y de
red estuvieran en uso. Posteriormente, estos dos modelos fueron definidos
independientemente de los lenguajes y sistemas usados para implementarlos. Con anterioridad
no eran más que colecciones de estructuras de datos y lenguajes sin una teoría subyacente
definida. En cuanto al modelo relacional, no se puede decir que sea en sí un modelo semántico
de datos. Su enorme éxito no se debe a que permite de forma implícita operaciones
conceptualmente abstractas sobre los datos, sino a los altos niveles de fiabilidad e integridad
que aporta en el manejo de grandes cantidades de datos.

Desde su comienzo en 1970 y durante mucho tiempo después, los sistemas gestores de
bases de datos relacionales (RDBMS : Relational Database Management System) estuvieron
restringidos al ámbito de los mainframes y mini-ordenadores. Con la irrupción masiva en el
mercado de los micro-ordenadores, aparecieron algunas implementaciones de RDBMSs que
intentaban emular las propiedades de los grandes sistemas, aunque no contaban con la mayor
parte de las características necesarias para ser denominados "relacionales", especialmente en
lo que se refiere al cumplimiento de las reglas de integridad relacional.

Hoy en día contamos con RDBMSs para micro-ordenadores que sí pueden ser
considerados plenamente relacionales y que, si bien no llegan alcanzar las prestaciones de los
grandes sistemas en cuanto a velocidad de ejecución, seguridad, integridad de datos,
recuperación y estabilidad, no tienen nada que envidiar a éstos cualitativamente, y sus
deficiencias se deben sobre todo al tipo de máquina en el que funcionan y a los sistemas
operativos que estas máquinas utilizan.

Lo que realmente marca la diferencia entre los sistemas relacionales y los sistemas
anteriores es el hecho de que su creador, Ted Codd, basó expresamente su funcionamiento
sobre un modelo matemático muy específico: el álgebra relacional y el cálculo relacional, así

10
como la progresiva adopción, por parte de su creador y algunos colaboradores, de un número
de Reglas de Integridad Relacional y de Formas Normales.

La definición formal y exhaustiva más actualizada del modelo se encuentra en (Codd).

Además existen un buen número de obras que tratan el modelo desde diversas perspectivas;
entre éstos destacamos la obra, ya clásica, de C. J. Date. En este apartado resumiremos los
conceptos más importantes del modelo relacional. Lo que exponemos a continuación es, en
esencia, un resumen de la obra de Codd.

Una base de datos relacional es una base de datos en donde todos los datos visibles al usuario
están organizados estrictamente como tablas de valores, y en donde todas las operaciones de
la base de datos operan sobre estas tablas.

Estas bases de datos son percibidas por los usuarios como una colección de relaciones
normalizadas de diversos grados que varían con el tiempo.

El modelo relacional representa un sistema de bases de datos en un nivel de abstracción un

tanto alejado de los detalles de la máquina subyacente, de la misma manera como, por
ejemplo, un lenguaje del tipo de PL/1 representa un sistema de programación con un nivel de
abstracción un tanto alejado de los detalles de la máquina subyacente. De hecho, el modelo
relacional puede considerarse como un lenguaje de programación mas bien abstracto,
orientado de manera específica hacia las aplicaciones de bases de datos.

En términos tradicionales una relación se asemeja a un archivo, una tupla a un registro, y un

atributo a un campo. Pero estas correspondencias son aproximadas, en el mejor de los casos.
Una relación no debe considerarase como ``solo un archivo'', sino mas bien como un archivo
disciplinado, siendo el resultado de esta disciplina una simplificación considerable de las
estructuras de datos con las cuales debe interactuar el usuario, lo cual a su vez simplifca los
operadores requeridos para manejar esas estructuras.

Características principales de los ``archivos'' relacionales:

 Cada ``archivo'' contiene solo un tipo de registros

 Los campos no tienen un orden específico, de izquierda a derecha
 Los registros no tienen un orden específico, de arriba hacia abajo
 Cada campo tiene un solo valor
 Los registros poseen un campo identificador único (o combinación de campos) llamado
clave primaria

Así, todos los datos en una base de datos relacional se representan de una y solo una manera,
a saber, por su valor explícito (esta se denomina en ocasiones ``principio básico del modelo
relacional''). En particular, las conexiones lógicas dentro de una relación y entre las relaciones
se representan mediante esos valores; no existen ``ligas'' o apuntadores visibles para el
usuario, ni ordenamientos visibles para el usuario, ni grupos repetitivos visibles para el usuario,
etc.

Actualmente algunos de los manejadores de bases de datos, utilizan un sistema de búsqueda

con algoritmos de árboles b. Pero las búsquedas que se pueden realizar con estos algoritmos
son sólo para memoria principal.

Los algoritmos implementados para realizar búsquedas con listas salteadas o por bloques ( skip
lists) son eficientes para realizar búsquedas en memoria secundaria. Como tienen varios
niveles en cada nodo de la lista, nos permite dar saltos mas largos al realizar las búsquedas,
esto provoca que las sean mas rápidas.

11
Conceptos básicos: tuplas, relaciones, atributos
Como ya hemos mencionado, el modelo relacional está basado en la teoría de conjuntos. En
este modelo, los datos se organizan en un tipo especial de conjunto denominado relación,
(relation) que se define de la siguiente manera: sean los conjuntos D1,..., Dn, denominados
dominios, que no tienen por qué ser distintos entre sí. Una relación definida sobre D1,...,Dn es
cualquier subconjunto R de D, donde n es el grado o aridad de R. Los dominios son en principio
conjuntos finitos de datos. Por tanto, a menos que se indique lo contrario, presumimos que las
relaciones son también finitas. Los elementos de una relación se denominan tuplas.
Formalmente, una tupla es:

< d1,..., dn>, donde d1 D1,..., dn Dn

El número de tuplas en una relación es la cardinalidad de la relación. Puesto que una

relación es un conjunto, los elementos de este conjunto, las tuplas, han de ser por fuerza
distintas. Esto también implica que el orden de las tuplas es irrelevante. El conjunto vacío es
una relación particular: la relación nula o vacía. Cada tupla de una relación, junto con el nombre
de la relación, representa una aserción (en el sentido lógico). Por ejemplo, cada tupla en la
relación PROFESORES, es una aserción de que la entidad (profesor) d x es miembro de la
institución Dx y tiene las propiedades atómicas <v1,..., vn>.

Las relaciones también pueden ser vistas como tablas, en las que cada tupla es una fila de
la tabla. Los nombres de las columnas de la tabla, por otra parte, son los atributos. El conjunto
(ordenado) de todos los atributos de una relación R es el esquema de R. Nos podemos referir a
los atributos de una relación mediante su nombre o por la posición (número de columna) que el
atributo ocupa en el esquema de la relación. Las tuplas, por tanto, pueden ser consideradas
como matrices de pares atributo:valor.

El dominio D de R es la colección de valores posibles para un determinado atributo. Por

ejemplo el dominio del atributo NOMBRE en la relación "Asignaturas" serían todas las
asignaturas que un centro educativo ofrece a sus alumnos. Cada atributo debe tomar los
valores de un dominio subyacente, y sólo uno. Una buena implementación de una base de
datos relacional debe poner en marcha los mecanismos necesarios (en términos de diseño
conceptual) para que este tipo de restricciones puedan ser impuestas. El concepto de
atomicidad es ciertamente relevante en el contexto de las tecnologías de la información y
especialmente en el campo de las bases de datos. Que un elemento sea atómico (también
llamado escalar) implica que no puede ser descompuesto en partes más pequeñas. Por
ejemplo, a la hora de codificar un número de teléfono, tenemos varias opciones. Podemos
guardar la información como un único valor, en cuyo caso, los prefijos interprovinciales y/o
internacionales formarían parte indivisible del número; también podemos optar por codificar la
información en tres valores separados, uno para el prefijo internacional, otro para el
interprovincial y un tercero para el número de abonado. La primera disposición, como un único
valor, aunque sirva al usuario de la base de datos para obtener la información precisa, presenta
la desventaja de que no podrá ser usado, por ejemplo, por un programa de comunicaciones
para marcar el número y efectuar una conexión (para voz, fax o datos) de forma automática.

Un dato, también puede ser compuesto, es decir puede ser descompuesto y hacerse uso de
los datos atómicos que contiene (por ejemplo el tipo de datos de estructura de rasgos que
mostramos cuyos valores podían ser, a su vez, otras estructuras de rasgos). Ya hemos
mencionado que en el modelo relacional todos los datos han de ser atómicos, aunque hay una
excepción muy particular a esta regla: la relación, que es considerada como un tipo de dato
compuesto. Sin embargo, la posibilidad de disponer de datos compuestos, sería muy deseable
en un sistema de base de datos. A nivel de diseño, tal característica simplificaría notablemente
la codificación de un esquema conceptual determinado.

Por otro lado, los lenguajes de programación de tercera generación (3GL) no estaban
preparados para manejar este tipo de datos complejos. Lo ideal para manejarlos sería poder
considerarlos tanto como un único objeto, como un número de individuos agrupados, de forma

12
que según la ocasión se pueda acceder a uno o varios de ellos por separado o bien a todos
ellos como un conjunto. La complejidad que implica manejar este tipo de datos mediante un
3GL es la causa de que el modelo relacional no implementase tipos de datos compuestos.

Los términos formales del modelo relacional a menudo son sustituidos por otros de
uso más común, debido a que estos términos son demasiado abstractos para ser usados
en la práctica. Así obtenemos las siguientes equivalencias (Date):

Término relacional formal Equivalente informal

Relación Tabla

Tupla Fila o registro

Cardinalidad Número de filas o registros

Atributo Columna o campo

Grado Número de columnas o campos

Clave primaria Identificador único

Dominio Fondos de valores legales

Términos relacionales y equivalentes informales

Aun así, deberíamos usar estos términos con gran cautela. Como Codd advierte (Codd), el
hecho de que las relaciones puedan ser percibidas como tablas, y puesto que una tabla es
parecida a un fichero plano, puede crear la falsa ilusión de que la misma libertad de acciones
permitida para las tablas o ficheros planos está permitida para la manipulación de relaciones.
Por ejemplo en una relación no pueden existir dos tuplas exactamente iguales. Sin embargo,
existen DBMS comerciales, supuestamente relacionales, tales como la familia dBase®, de
Ashton-Tate (hasta su versión IV), y en general los productos xBase, que permiten este tipo de
acciones no permitidas en enfoques relacionales puros.

En términos de representación tabular se dice que una relación consta de dos partes:
cabecera (heading) y cuerpo (body). La cabecera es el conjunto de atributos (columnas) y el
cuerpo es el conjunto de tuplas (filas). En la tabla , la primera línea (en negrita) es la
cabecera y el resto de las filas el cuerpo.

ID PROFESOR CURSO AÑO DEPARTAMENTO

1 Date Bases de datos 1991 Informática
2 Miller Intro Psicolingüística 1994 Psicolingüística
3 Booch Modelado semántico 1995 Informática
4 Sag HPSG 1994 Lingüística
5 Sinclair Lingüística de corpus 1990 Lexicografía

Tabla, cabecera, cuerpo

13
 En todo momento deberíamos ser conscientes de que los elementos de una relación, como
ya mencionamos, no tienen orden alguno, lo cual se desprende del hecho de que una relación
no es más que un conjunto matemático, con algunas diferencias que exponemos más abajo.
Así, la tupla con ID 1 no es la primera, ni la ID 5 la última, la numeración de identificación es
totalmente aleatoria, normalmente resultado de un campo contador. Del mismo modo, los
atributos tampoco tienen orden alguno; el hecho de que el atributo PROFESOR aparezca antes
que el de CURSO en la sucesión de columnas no tiene relevancia alguna para la relación.

Como hemos mencionado, el concepto matemático de relación, puede resultar muy poco
intuitivo y, como Codd recuerda, no se adapta a las definiciones de "relación" encontradas en
los diccionarios. Se refiere a la propiedad de que una relación unaria (de grado o aridad uno),
es una relación en sentido pleno. Así, una relación matemática de grado mayor que uno
interrelaciona dos o más objetos, mientras que una relación de grado uno no. El tratamiento de
una relación unaria es exactamente el mismo que el de una de mayor aridad.

Por otra parte, el concepto de relación en el modelo relacional presenta algunas diferencias
con respecto a su correspondiente matemático. La Tabla 4.3 presenta estas diferencias de
forma esquemática (Codd).

Matemáticas Modelo relacional

Sin restricciones en el tipo de

Valores atómicos
valores

Columnas sin nombre Columnas con nombre

Distinción de columnas individuales Distinción de columnas individuales por

por su posición dominios y por nombres

Normalmente constantes en el
Normalmente varía con el tiempo
tiempo

Relaciones en Matemáticas y en el Modelo Relacional

Además de la característica mencionada en cuanto a los tipos de valores, otra diferencia

destacable (la tercera de las listadas en la tabla), es que mientras que ninguno de los dos tipos
de relaciones está ordenado en cuanto a sus elementos (tuplas), una relación matemática está
ordenada en cuanto a sus atributos (columnas), ya que éstas se distinguen por su posición. En
el modelo relacional, al estar distinguidas por su nombre, su posición es totalmente irrelevante.
Esta característica no es casual, sino que su objetivo es facilitar las operaciones con los
atributos de las relaciones.

Finalmente, hemos de aclarar que relaciones no sólo son las "tablas" base de la base de
datos, sino que también son los distintos tipos de relaciones que se pueden generar mediante
consultas a las relaciones base. Podemos distinguir los siguientes tipos de relaciones:

1. Relaciones base o reales: es lo que corresponde al concepto de tabla. El conjunto de

éstas son las que componen la base de datos realmente.
2. Conjunto dinámico de datos: no poseen datos almacenados propios y están
representadas únicamente dentro del sistema mediante su definición en términos de
otras relaciones (es decir, mediante consultas). También conocidas como dynasets.
3. Instantáneas (snapshots): iguales que las anteriores, pero los datos que contienen no
son virtuales, sino que están realmente almacenados en la instantánea. Se utilizan
para manejar datos susceptibles de cambios.
4. Resultados de consultas: la relación resultante de consultar una o más relaciones base.

14
 5. Resultados intermedios: el resultado de una operación anidada en una consulta, estos
resultados son usados por la consulta externa para otra operación. La facilidad de
anidar consultas dota de gran potencia al lenguaje de consulta relacional (SQL).

Claves primarias
Puesto que las tuplas son irrepetibles, una relación necesita un identificador único para cada
una de las tuplas, esta es la clave (primaria) de la relación, que se define como un subconjunto
C de los atributos de R, cuyos valores no pueden ser repetidos. Una clave primaria debe ser
mínima, en el sentido de que en su composición no intervengan más que los atributos
estrictamente requeridos para identificar las tuplas de forma única. Puesto que una relación es
un conjunto de tuplas, se debe dar la condición de que toda relación deba tener una clave
primaria; al menos el conjunto de los atributos de una relación conforma la clave de esa
relación. Además, una clave primaria puede ser simple (formada por un solo atributo) o
compuesta (formada por más de uno). Las dos características definitorias son, por tanto, la
unicidad y la minimalidad (Date).

La cuestión de si una clave primaria debe ser semántica o no sigue siendo fuente de
discusiones. Una clave semántica, también llamada inteligente, es aquella que tiene significado
por sí misma, independientemente de que sea o no la clave, es decir que el o los atributos que
la conformen contengan valores que describan "realmente" a la entidad reflejada en la tupla
(por ejemplo, los apellidos o el DNI en una relación que denote personas). Lo contrario, es
decir, una clave arbitraria cuya única función es la de identificar la entidad designada por la
tupla, se denomina clave subrogada.

Muchos proponentes del modelo relacional, entre ellos (Date) opinan que usar una clave
inteligente puede llegar a desorganizar una base de datos si se producen cambios en los datos
y abogan por la utilización exclusiva de claves subrogadas; para estos autores este tipo de
claves tiene el beneficio de poder ser modificadas con más facilidad. Otros autores no menos
relevantes, como (Celko), miembro del ANSI X3H2 Database Standards Committee, esgrimen
sólidos argumentos a favor del uso de claves semánticas:

 Ahorro de espacio puesto que en cualquier caso la información en cuestión ha de ser

almacenada en algún lugar.
 Menor número de índices necesarios.
 Posibilidad de verificación de una clave inteligente.
 Son más intuitivas y pueden evitar muchas consultas.

Particularmente pensamos que usar una clave semántica es una buena idea siempre que
se tenga la absoluta certeza de que la situación generada por su utilización no es susceptible
de cambiar con el tiempo y que realmente facilite el manejo de las relaciones en lugar de
dificultarlo.

Sin embargo, nuestra experiencia particular nos lleva a pensar que el uso de claves
subrogadas conduce a implementaciones más eficientes en la mayoría de las ocasiones.
Creemos que la elección de una buena clave semántica conduce casi siempre a la utilización
de claves compuestas, cuya indexación ocupa más espacio físico y entorpecen, cuando no
imposibilitan, muchas operaciones. Por ejemplo, en la representación de un diccionario, una
buena clave primaria podría ser la conjunción de LEMMA+SENSE, o LEMMA+PoS+SENSE.
Habiendo probado esta disposición en implementaciones anteriores a la que vamos a mostrar
en este trabajo (Moreno Ortiz), esto ha demostrado ser una mala elección, ya que el lexicógrafo
no tenía la libertad de modificar el identificador de acepción, por lo que hemos optado por una
clave subrogada.

En otros casos no hay ningún atributo de la entidad que se pueda considerar como
realmente definitorio de la misma y es más cómodo optar por una clave subrogada. Por otra
parte, las claves subrogadas, al estar compuestas por un sólo número, ahorran espacio de
almacenamiento, lo que hay que tener en cuenta cuando el sistema es susceptible de crecer.

15
 En nuestra implementación la totalidad de las claves serán subrogadas, ya que la utilización
de las mismas ha demostrado permitir una mayor flexibilidad en cuanto a las tareas comunes
del usuario final y a las tareas de mantenimiento y modificaciones de esquema.

Interrelaciones. Claves ajenas

La polisemia del vocablo "relación" en español obliga a la utilización del término interrelación
(relationship) para distinguir los dos sentidos ("relation"/"relationship"). De hecho, este
problema semántico ha causado confusión en un buen número de estudiosos no especialistas
en el campo. Un RDBMS ofrece la posibilidad de interrelacionar dos o más relaciones
existentes en una base de datos. De hecho, es ésta la facultad que dota de mayor potencia al
modelo. Hay varios aspectos que conviene resaltar sobre el establecimiento de interrelaciones.

En primer lugar, la manera en que el modelo relacional interrelaciona las relaciones

existentes en una base de datos no es la que cabría esperar. Normalmente, cuando en una
aplicación informática deseamos referenciar dos elementos cuales sea, utilizamos los
denominados punteros (pointers), haciendo que un elemento apunte a la dirección de memoria
de otro y/o viceversa. Sin embargo el modelo relacional funciona de forma diferente.

En realidad, no existe ningún tipo de puntero o enlace que el usuario pueda percibir. Todas
las interrelaciones se realizan mediante la comparación de valores, ya sean éstos
identificadores de objetos (claves primarias de las relaciones) o atributos de estos objetos. Para
que esto sea posible, es condición indispensable que los valores a comparar pertenezcan al
mismo dominio (y por tanto contengan el mismo tipo de datos (numéricos, texto, booleanos,
etc.).

Por otra parte, algunos RDBMS comerciales, (por ejemplo Microsoft Access TM o ADABAS/D)
permiten al usuario definir interrelaciones, incluso de forma gráfica. Pero esto no significa
ningún cambio en cuanto a la estructura de la base de datos, sino que hace que el DBMS
ayude más al usuario a la hora de hacer consultas, interrelacionando automáticamente las
tablas incluidas en una consulta determinada y estableciendo las reglas de integridad
referencial.

Por ello, una interrelación puede ser considerada a todos los efectos como otra relación
(que normalmente se manifiesta como un conjunto dinámico de datos o una instantánea).

La mejor manera de comprender como funcionan las interrelaciones en una base de datos
relacional es mediante un ejemplo, que también nos ayudará a comprender la diferencia entre
una relación y una tabla plana.

Consideremos la relación de profesores expuesta anteriormente. Sería conveniente que la

base de datos a la que pertenece esta relación contuviese también información sobre los datos
personales de los profesores, descripción de los cursos ofrecidos y descripción de los distintos
departamentos. Pues bien si quisiéramos incluir toda esta información en una tabla plana, esta
debería contener, al menos, los siguientes atributos (columnas):

PROFESOR_COD
PROFESOR_NOMBRE
PROFESOR_DIRECCIÓN
PROFESOR_TELÉFONO
PROFESOR_DEPTO
DEPTO_COD
DEPTO_NOMBRE
DEPTO_DESC
CURSO_COD
CURSO_NOMBRE
CURSO_DESC
CURSO_NIVEL CURSO_AÑO

16
 La implicación directa de esta disposición es que el número de celdas que obtendríamos
sería el resultado de

donde Fi representa el número de filas de la tabla i, Cj representa el número de columnas de

la tabla j y n es el número de tablas que se obtendrían mediante un análisis relacional
apropiado. La cantidad de información redundante sería totalmente inaceptable para una base
de datos mediana. La información redundante no sólo implica mayor necesidad de
almacenamiento masivo, sino también una ralentización de todas las operaciones con los
datos. Imaginemos el resultado de una disposición como la anterior en bases de datos que
contienen relaciones con cardinalidades del orden de decenas de millones.

El modelo relacional ofrece una buena solución a este problema, que nos permite reducir la
redundancia de datos al mínimo y agilizar las operaciones de consulta y actualización. Lo que
deberíamos hacer es separar la información que se refiere a las tres entidades que tenemos
(profesores, cursos y departamentos) en tres relaciones independientes, y después
relacionarlas entre sí. De este modo obtendríamos una disposición parecida a la de la siguiente
figura. Los recuadros indican relaciones base, mientras que las flechas indican las
interrelaciones entre ellas. Repetimos que estas interrelaciones, en realidad, no existen a nivel
de la base de datos, se usan sólo a nivel de representación gráfica. Los nombres de algunos
atributos (Prof_ID, Depto_ID, Curso_ID) sugieren el tipo de claves que hemos usado: claves
subrogadas.

Ejemplo de disposición relacional

A partir de estas tres relaciones, y mediante el mecanismo de comparación de valores que

antes mencionamos, se tiene acceso a toda la información que deseamos sin redundancia
alguna. Los "1" y "M" que etiquetan las flechas hacen referencia al tipo de interrelación  "uno a
muchos": en la tabla PROFESOR no hay valores repetidos para el atributo Prof_ID (existe un
solo conjunto de atributos para describir un determinado profesor), pero encontraremos varios
de ellos en la tabla CURSO (un profesor puede dar varios cursos). Igualmente, un
departamento consta de varios profesores. Las interrelaciones que hemos mostrado en la
figura anterior son todas del mismo tipo: de uno a muchos (one-to-many). Ésta es la
interrelación más frecuente. Además tenemos las de:

17
  Muchos a muchos (many-to-many): en una relación de este tipo, la tabla A puede
tener más de un registro coincidente en la tabla B, y un registro en la tabla B puede
tener más de un registro coincidente en la tabla A. Par detectar las relaciones "muchos
a muchos" entre las tablas, es importante observar la relación en los dos sentidos. Este
tipo de relación requiere cambiar el diseño de la base de datos, ya que en realidad, es
decir, a nivel físico, esto no es factible. La forma de implementar este tipo de
interrelación, es mediante una tercera tabla que sirva de puente entre las dos. Esta
tercera tabla contendrá información procedente de las otras dos tablas
interrelacionando los registros pertinentes. Veremos algunas interrelaciones de este
tipo en nuestra implementación relacional del lexicón.
 Uno a uno (one-to-one): en una relación de este tipo, un registro en la tabla A no
puede tener más de un sólo registro coincidente en la tabla B, u viceversa. Este tipo de
interrelación es muy poco frecuente, ya que en la mayoría de los casos la información
de las dos tablas puede ser combinada en una sola tabla. Tan sólo es apropiado
cuando el número de campos de la tabla B es muy alto y concerniente a un
determinado tipo de información. En estos casos es aconsejable tener esa información
en una tabla separada.

Las interrelaciones de uno a muchos se implementan mediante el uso de claves ajenas,

también llamadas externas o foráneas (foreign keys). Una clave ajena es un atributo
(posiblemente indexado y posiblemente compuesto) de una relación R2, cuyos valores han de
concordar con los de alguna clave primaria en otra relación R1. R1 y R2 no han de ser
necesariamente distintas.

Los atributos Prof_ID, en la tabla PROFESOR , Curso_IDen la tabla CURSO y Depto_IDen

la tabla DEPTO, son claves primarias, mientras que los atributos Prof_ID en la tabla CURSO y
Depto_ID en la tabla PROFESOR, son claves externas.

Integridad Relacional
Ahora que ya conocemos el funcionamiento de las claves primarias y las claves ajenas
estamos en posición de estudiar las reglas de integridad. Con este nombre se designa aquellas
reglas que han de ser aplicadas a una base de datos para asegurar que los datos introducidos
sean consistentes con la realidad que pretenden modelar. Existen dos reglas generales que
aporta el modelo relacional. Estas dos reglas son muy simples, y son las siguientes:

1. Regla de integridad de las entidades: ningún componente de la clave primaria de una

relación base puede aceptar valores nulos.
2. Regla de integridad referencial: la base de datos no debe contener valores de clave
ajena sin concordancia.

La primera de estas reglas impide la existencia de una tupla sin identificador único. La
segunda impide que, por ejemplo, en nuestra base de datos académica, exista un profesor
adscrito a un departamento inexistente, o un curso impartido por un profesor inexistente.
Hemos de recordar que sólo los productos puramente relacionales implementan realmente
estas dos reglas generales de integridad relacional. En otros, destinados al mercado
doméstico, estas incongruencias son admitidas sin problemas.

Además, muchos RDBMSs añaden un buen número de características que ayudan al DBA
a mantener más fácilmente la integridad de los datos. Mediante estos mecanismos es posible
añadir reglas específicas para cada base de datos; éstas son las denominadas restricciones de
integridad definidas por el usuario (Codd). Por ejemplo, podríamos determinar que un profesor
no pueda ser menor de x años o que un curso sólo pueda pertenecer a los niveles 1, 2 ó 3. El
resultado sería que al intentar introducir un valor fuera de este rango, el DBMS rechazaría la
información introducida mostrando un mensaje de error.

18
Lenguajes relacionales. Consultas
Para crear las relaciones, modificarlas, eliminarlas, recuperar los datos almacenados en ellas, y
para manipularlas en general, necesitamos un lenguaje formal que nos facilite el acceso, de lo
contrario nos veríamos obligados a trabajar a bajo nivel, o nivel de máquina. Este lenguaje
debe ser lo suficientemente expresivo para permitirnos llevar a cabo todas estas operaciones, y
debe estar basado en formalismos que cumplan con todas las premisas expuestas en los
apartados anteriores respecto a reglas de integridad, formas normales, etc. Existen dos tipos
básicos de formalismos para expresar las consultas sobre las relaciones de una base de datos
relacional: el álgebra relacional y el cálculo relacional

El lenguaje de consulta de bases de datos relacionales por antonomasia, es, como ya

anticipábamos, el llamado SQL (Structured Query Language). Este lenguaje, basado en el
álgebra relacional y el cálculo relacional anteriormente descritos, actúa de interfaz entre el
usuario y la base de datos y facilita realizar todas las operaciones permitidas. El lenguaje fue
diseñado para que, mediante un número muy reducido de comandos y una sintaxis simple,
fuese capaz de realizar un gran número de operaciones. La curva de aprendizaje de SQL es
realmente rápida. Además, SQL es bastante flexible, en el sentido de que cláusulas SQL
pueden ser anidadas indefinidamente dentro de otras cláusulas SQL, facilitando así las
consultas que utilizan varias relaciones, vistas u otras consultas.

Además de poder ser usado directamente, es decir, en modo comando, desde el DBMS,
SQL puede ser usado desde otros lenguajes de programación de tercera generación, tales
como C, para poder acceder a los datos de la base de datos y usarlos para cualquier fin en el
programa. Cuando SQL es usado de este modo se le denomina SQL embebido (embedded).
Esta característica amplía enormemente las posibilidades del modelo relacional. A continuación
mostramos los conceptos fundamentales de SQL

Las consultas en SQL constan de uno o más bloques de recuperación SELECT-FROM-

WHERE. El resultado de una consulta es siempre una relación. La estructura es la siguiente:

SELECT atributos
FROM relaciones
[WHERE condiciones-lógicas]

SELECT corresponde a la operación de proyección del álgebra relacional. Especifica todos los
atributos que se desean recuperar.

FROM especifica una lista de relaciones de donde se escogerán los atributos de la cláusula
SELECT.

WHERE es opcional e incluye las condiciones que deben cumplir los atributos de las
relaciones.

Ejemplos:

SELECT direccion, telefono FROM profesor WHERE nombre = "Miller"

Devolvería la dirección y el teléfono del profesor Miller.

SELECT nombre, director, desc FROM depto WHERE profesor IN

(SELECT prof_ID       FROM professor       WHERE profesor = "Sinclair")

Devolvería el nombre, nombre del director y descripción del departamento al que pertenece el
profesor Sinclair.

19
 Además de estas cláusulas básicas, existen otros muchos operadores que modifican los
resultados, y que permiten acciones tales como mostrar valores no repetidos (DISTINCT), unir,
intersectar o restar filas en un resultado (UNION, INTERSECT, MINUS), contar valores,
sumarlos (SUM), agrupar por valores (GROUP BY, obtener máximos y mínimos (MAX, MIN ),
promedios (AVG), ordenaciones (ORDER BY), etc.

Finalmente, SQL incluye tres comandos de actualización de datos: UPDATE (modificar),

INSERT (insertar) y DELETE (eliminar).

Para concluir esta sección mencionaremos un sistema de consulta de bases de datos

relacionales relativamente nuevo, el QBE (Query By Example), desarrollado originalmente por
IBM bajo el sistema VM/CMS. El lenguaje QBE es un sistema relacional de manejo de datos
basado en el cálculo relacional de dominios. Posee dos características principales que le
distinguen:

1. No tiene una sintaxis lineal, sino bidimensional.

2. Las consultas se expresan "por ejemplo". En vez de expresar un procedimiento para
conseguir la respuesta deseada, el usuario da un ejemplo de lo que desea. El sistema
generaliza el ejemplo para obtener la respuesta deseada.

Las más modernas aplicaciones combinan esta metodología con la tecnología de los GUI
(Graphical User Interface) para ofrecer una evolución llamada GQBE (Graphical Query By
Example). Sistemas que ofrecen estas posibilidades son, por ejemplo, Microsoft Access TM,
Microsoft Visual FoxProTM, Corel Paradox®, Oracle8 de Oracle® Corporation, ADABAS D, de
Software AG o Sybase® SQL Anywhere. Además, algunos de estos sistemas, por ejemplo MS
Access o ADABAS D, permiten combinar el SQL standard con GQBE, aumentando así la
potencia y flexibilidad.

Ventajas e inconvenientes del modelo relacional

Durante la exposición en los apartados anteriores hemos comentado las características más
sobresalientes de este tipo de sistemas de información. Las ventajas de utilizar un RDBMS
podrían ser resumidas en las siguientes:

 Compatibilidad y estandarización.
 Fiabilidad.
 Garantía de independencia de los datos.
 Existencia de numerosos sistemas comerciales entre los que escoger y consiguiente
apoyo técnico.
 Conectividad garantizada con los lenguajes de programación estándar.

20