Asociación Profesional del Cuerpo Superior

de Sistemas y Tecnologías de la Información

de la Administración del Estado

Temas Específicos para la preparación de la Oposición al Cuerpo

Superior de Sistemas y Tecnologías de la Información de la
Administración del Estado.

TEMAS ESPECÍFICOS II: Tecnología Básica

Tema 57. Los sistemas de gestión de bases de datos SGBD.

El modelo de referencia de ANSI.

AUTOR: Juan Cantador Marina y Leonor Torres Moreno

Fecha: 2007
 II. Tecnología Básica

057. Los sistemas de gestión de bases de datos SGBD. El

modelo de referencia de ANSI.

Autores: Juan Cantador Marina y Leonor Torres Moreno

1. Introducción ................................................................................................................. 2
2. Bases de datos y SGBD ................................................................................................. 2
1.1 Definiciones ......................................................................................................... 2
1.2 Características ...................................................................................................... 4
1.3 Componentes ....................................................................................................... 5
3. Evolución hacia los SGBD .............................................................................................. 7
1.4 Primeros Sistemas de Base de Datos ..................................................................... 7
4. Ventajas e Inconvenientes. Sistemas de Ficheros vs. Base de Datos ................................ 9
5. Modelo De Datos ........................................................................................................ 10
1.5 Modelo de Datos en Red. Modelo CODASYL ......................................................... 10
1.5.1 Modelo CODASYL........................................................................................ 11
1.6 Modelo Jerárquico .............................................................................................. 12
1.7 Modelo Relacional ............................................................................................... 13
1.8 Modelo de Objetos .............................................................................................. 16
1.9 Tendencias ......................................................................................................... 19
1.9.1 Bases de Datos Paralelas y Distribuidas ............................................................ 19
1.9.2 Bases de Datos Multimedia .............................................................................. 20
6. SGDBR. Sistema de Gestión de Base de Datos Relacional .............................................. 21
1.10 Características SGBDR......................................................................................... 21
1.11 Componentes de un SGBDR ................................................................................ 22
1.11.1 Componentes de Proceso ............................................................................ 22
1.11.2 Componentes para el Almacenamiento ......................................................... 22
7. Arquitectura ANSI/X3/SPARC de BD ............................................................................. 22
1.12 Nivel Interno ..................................................................................................... 24
1.13 Nivel conceptual ................................................................................................. 24
1.14 Nivel externo ...................................................................................................... 25
1.15 Transformación de datos ..................................................................................... 25
1.16 Modelo de Referencia ......................................................................................... 27
8. Bibliografía ................................................................................................................. 31

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 1
 II. Tecnología Básica

1 INTRODUCCIÓN

Un sistema de gestión de base de datos (SGBD) proporciona el método de organización necesario para el
almacenamiento y recuperación flexible de grandes cantidades de datos. Además de un interfaz limpio a
las aplicaciones, ya que con ordenes sencillas una aplicación despacha objetos para que sean
almacenados en la base de datos, dejando al SGBD que encuentre el correcto almacenamiento físico, que
garantice el acceso futuro a través de varias rutas e integre los datos en relaciones apropiados con otros
elementos y pueda servir a muchas aplicaciones.

2 BASES DE DATOS Y SGBD

2.1 Definiciones
El término Base de Datos ha llegado a ser tan común que puede resultar vago. En algunos casos se usa
para designar al conjunto de datos de una organización, ya sean informatizados o no, y en otros casos
para referirse a los programas que gestionan los datos..
Algo en lo que coinciden todas las definiciones es que una base de datos es un conjunto, colección o
depósito de datos almacenados en un soporte informático no volatil, de acceso directo. Los datos deben
estar estructurados e interrelacionados de acuerdo con un modelo capaz de recoger en máximo contenido
semántico. Así pues, los datos de una base se hallan integrados, estructurados, relacionados y
compartidos.
Dada la importancia que tienen en el mundo real las interrelaciones entre los datos, es imprescindible que
la base de datos sea capaz de almacenarlas, al igual que hace con otros elementos, siendo esta diferencia
esencial respecto a los ficheros donde no se almacenan las interrelaciones. En el mundo real existen,
además, restricciones semánticas a las que se está concediendo una importancia creciente y que, en los
sistemas actuales, tienden a almacenarse junto con los datos, igual que las interrelaciones.
La redundancia de los datos debe ser controlada, de forma que no existan duplicidades perjudiciales ni
innecesarias, y que las redundancias físicas, en muchos casos convenientes, sean tratadas por el mismo
sistema, de modo que no puedan producirse incoherencias. Esto podría resumirse diciendo que en las
bases de datos no debe existir redundancia lógica, aunque sí se admite redundancia física por motivos de
eficiencia.
Las bases de datos han de atender a múltiples usuarios y diferentes aplicaciones, en contraposición a los
sistemas de ficheros, en los que cada fichero está diseñado para responder a las necesidades de una
determinada aplicación.
Otro aspecto importante de las bases de datos es la independencia, tanto física como lógica, entre datos y
tratamientos. Esta independencia, objetivo fundamental de las bases de datos, es una característica
esencial que distingue a las bases de datos de los ficheros.
La definición y la descripción del conjunto de datos contenidos en la base deben ser únicas y estar
integradas con los mismos datos. En los sistemas basados en ficheros, los datos se encuentran
almacenados en soporte magnético, mientras su descripción está separada de los mismos, formando parte
de los programas. Suele haber, además, una documentación adicional en soporte papel, en muchos casos
insuficiente y no actualizada. Este tipo de organización da lugar a infinidad de problemas. En las bases de
datos, la descripción y la definición y documentación completa se almacenan junto con los datos, de modo
que estos están autodocumentados, y cualquier cambio que se produzca en dicha documentación se ha de
reflejar y quedar recogido en el sistema con todas las ventajas que de ello se derivan.
La actualización y recuperación en las bases de datos se debe realizar mediante procesos bien
determinados, procedimientos que han de estar diseñados de modo que se mantenga la integridad,
seguridad y confidencialidad de la base de datos.
El concepto de base de datos ha ido cambiando y configurándose a lo largo del tiempo, y en la actualidad
podemos definir una base de datos como:
“Colección o depósito de datos integrados, con redundancia controlada y con una estructura que refleje
las interrelaciones y restricciones existentes en el mundo real; los datos, que han de ser compartidos por
diferentes usuarios y aplicaciones, deben mantenerse independientes de estas, y su definición y
descripción, únicas para cada tipo de datos, han de estar almacenadas junto con los mismos. Los
procedimientos de actualización y recuperación, comunes y bien determinados, habrán de ser capaces de
conservar la integridad, seguridad y confidencialidad del conjunto de los datos.”

Un Sistema Gestor de Base de Datos es un producto de software que presta soporte al

almacenamiento confiable de las bases de datos, pone en marcha estructuras para manejar relaciones y
restricciones, y ofrece servicios de almacenamiento. Otra definición sería Conjunto coordinado de
programas, procedimientos, lenguajes, etc. Que suministran a los diferentes tipos de usuarios medios
necesarios para describir y manipular los datos almacenados en la base, garantizando su seguridad. Los
datos están autodocumentados, y cualquier cambio que se produzca en dicha documentación se ha de
reflejar y quedar recogido en el sistema con todas las ventajas que de ello se derivan.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 2
 II. Tecnología Básica

Dicho con otras palabras, un SGBD es la herramienta que permite interactuar los datos con los usuarios de
los datos, de forma que se garanticen todas las propiedades definidas para una base de datos. En algunos
casos el SGBD trabajará directamente con los datos, y en otras ocasiones lo hará a través del Sistema
Operativo de la máquina donde resida el SGBD.

El propósito principal del SGBD es permitir al usuario almacenar, actualizar y consultar datos en
términos abstractos, de forma que sea relativamente fácil mantener y obtener información de una base
de datos. El SGBD libera al usuario de conocer exactam ente la organización física de los datos y
de crear algoritmos para almacenar, actualizar o consultar esa información. Se trata de un paquete de
programas que lleva a cabo diferentes tareas, incluyendo facilidades que permiten al usuario acceder o
modificar la información en la base de datos.

El Sistema Gestor es un enlace SGBD

intermedio entre la base de datos física,
el ordenador y el sistema operativo por S.O.
un lado, y por otro los usuarios.

Almacén
físico
Figura 1.Sistema Gestor de Base de Datos

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 3
 II. Tecnología Básica

2.2 Características

Algunas de las características que ha de satisfacer un Sistema Gestor de Base de Datos son las siguientes:

 Manejo de grandes volúmenes de datos: SGBD debe ser capaz de manejar estas cantidades
de datos sin que se resientan sus prestaciones, ya sea mediante el manejo de índices, la partición
de tablas, la utilización de procesos distribuidos o cualquier otra técnica que se verá más
adelante.

 Manejo de accesos concurrentes: El SGBD debe permitir esta simultaneidad de accesos

mediante un manejo eficiente de los bloqueos de la base de datos para que no se produzca
corrupción en los datos o interbloqueos. Un SGBD debe proporcionar un mecanismo que asegure
que la base de datos se actualice correctamente cuando varios usuarios la están actualizando
concurrentemente. Uno de los principales objetivos de los SGBD es el permitir que varios usuarios
tengan acceso concurrente a los datos que comparten. El acceso concurrente es relativamente
fácil de gestionar si todos los usuarios se dedican a leer datos, ya que no pueden interferir unos
con otros. Sin embargo, cuando dos o más usuarios están accediendo a la base de datos y al
menos uno de ellos está actualizando datos, pueden interferir de modo que se produzcan
inconsistencias en la base de datos. El SGBD se debe encargar de que estas interferencias no se
produzcan en el acceso simultáneo.

 Escalabilidad y elevada capacidad de proceso: necesaria para hacer frente a los dos puntos
anteriores.

 Alta Disponibilidad: la base de datos debe estar constantemente disponible para su acceso,
por lo que las tareas de administración, de mantenimiento y de gestión del día a día deben poder
realizarse sin detener el normal funcionamiento de la base.

 Seguridad y control de accesos: Un SGBD debe proporcionar un mecanismo que garantice

que sólo los usuarios autorizados pueden acceder a la base de datos. La protección debe ser
contra accesos no autorizados, tanto intencionados como accidentales.

 Integridad de los datos: el estado de la datos existentes en la base debe ser consistente en
todo momento con el esquema relacional en que se basa (no puede haber claves nulas, claves
ajenas que no hagan referencia a valores nulos o a los valores de la clave primaria (integridad
referencial), atributos con valores fuera de su dominio, etc.) La integridad de la base de datos
requiere la validez y consistencia de los datos almacenados (restricciones inherentes,
restricciones explícitas). Esto implica una protección frente a posibles caídas del sistema,
transacciones no finalizadas, etc. Un SGBD debe proporcionar un mecanismo que garantice que
todas las actualizaciones correspondientes a una determinada transacción se realicen, o que no
se realice ninguna. Un SGBD debe proporcionar un mecanismo capaz de recuperar la base de
datos en caso de que ocurra algún suceso que la dañe.

 Documentación de la base de datos al mismo tiempo que su desarrollo y construcción.

 Flexibilidad, que viene dada por la independencia física y lógica.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 4
 II. Tecnología Básica

Seguridad e Integridad de los Datos:

Un SGBD proporciona los siguientes mecanismos para garantizar la seguridad e integridad de los datos:

• Debe garantizar la protección de los datos contra accesos no autorizados, tanto intencionados como
accidentales.
• Debe implantar restricciones de integridad que protegerán la BD contra daños accidentales, pues los
valores de los datos que se quieren almacenar deberán satisfacer ciertos tipos de restricciones de
consistencia y reglas de integridad, especificadas por el administrador de la BD. El SGBD puede
determinar si se produce una violación de la restricción impuesta.
• Debe proporcionar herramientas y mecanismos para la planificación y realización de copias de
seguridad, y su posible posterior restauración tras un fallo del sistema.
• Debe ser capaz de recuperar la BD llevándola a un estado consistente en caso de ocurrir algún
suceso que la dañe.
• Debe asegurar el acceso concurrente y ofrecer mecanismos para conservar la consistencia de los
datos en el caso de que varios usuarios actualicen la BD de forma concurrente.

Usuarios de la BD:

En los SGBD existen distintos tipos de usuarios, cada tipo con unos permisos o privilegios diferentes sobre
los objetos que forman la BD. Por ejemplo, en los sistemas Oracle los tipos de usuarios más importantes
son:

1. Los usuarios de la categoría DBA (Database Administrador): Con el nivel más alto de privilegios,
pues son los administradores de la base de datos.
2. Los usuarios de la categoría RESOURCE: Pueden crear sus propios objetos y únicamente tienen
acceso a los objetos para los que se les ha dado permiso.
3. Los usuarios del tipo CONNECT: Únicamente pueden tener acceso a los objetos para los que se les
ha concedido permiso.

El Administrador de la Bases de Datos, DBA, tiene una gran responsabilidad al tener el máximo nivel
de privilegios. Hay que intentar que haya solo uno o muy pocos. Los DBA crearán los demás usuarios y les
asignarán sus tipos y permisos de acceso. Entre las tareas de un DBA están:

1. Instalar el SGBD en el sistema informático de la empresa.

2. Crear las BD que se vayan a gestionar.
3. Crear y mantener el esquema de la BD.
4. Crear y mantener las cuentas de usuario de la BD.
5. Arrancar y parar el SGBD, y cargar las BD con las que se ha de trabajar.
6. Colaborar con el Administrador del SO en las tareas de ubicación, dimensionado y control de los
archivos y espacios de disco ocupados por el SGBD.
7. Colaborar en las tareas de formación de los usuarios.
8. Establecer estándares de uso, políticas de acceso y protocolos de trabajo diario para los usuarios
de la BD.
9. Suministrar la información necesaria sobre la BD a los equipos de análisis y programación de
aplicaciones.
10. Efectuar tareas de explotación como:

10.1. Vigilar el trabajo diario colaborando en la información y resolución de las dudas de los
usuarios.
10.2. Controlar en tiempo real los accesos, tasas de uso, cargas en los servidores, anomalías, etc.
10.3. Llegado el caso, reorganizar la BD.
10.4. Efectuar las copias de seguridad periódicas de la BD.
10.5. Restaurar la BD después de un incidente material a partir de las copias de seguridad.
10.6. Estudiar las auditorías del sistema para detectar anomalías, intentos de violación de la
seguridad, etc.
10.7. Ajustar y optimizar la BD mediante el ajuste de sus parámetros, con ayuda de las
herramientas de monitorización y de las estadísticas del sistema.

2.3 Com ponentes

Para proporcionar a los usuarios las diferentes facilidades, el SGBD aporta uno o más lenguajes
especializados llamados Lenguajes de Base de Datos. Cada gestor ofrece uno diferente, aunque se
puede considerar al SQL (Structure Query Language) como el estándar en este área.
Los lenguajes de base de datos se dividen en dos clases:

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 5
 II. Tecnología Básica

• Lenguajes de Definición de Datos (LDD), orientados a la descripción de la base de datos dentro

del SGBD, así como a modificaciones de la base y cambios en su estructura física. Esto permite la
definición de las tablas (nombres, campos, dominios), atributos, interrelaciones, autorizaciones de
acceso, reglas de integridad, índices, así como todo lo necesario para asegurar la integración
referencial y validaciones. Uno de los LDD más extensamente utilizados es el Abstract Syntax Notation
1 (ASN.1), definido por ISO en 1988 como ISO 8824.
• Lenguajes de Manipulación de Datos (LMD), orientados al proceso y extracción de información
almacenada en el SGBD. Se usan para añadir, borrar o modificar registros de las distintas entidades.
Los objetos creados en la BD con un lenguaje de definición de datos se gestionan con un lenguaje de
manipulación de datos. Los usuarios lo utilizan para realizar consultas, inserciones, eliminaciones y
modificaciones sobre los datos de la BD. Las BD relacionales utilizan lenguajes como SQL (Structured
Query Language) o QBE (Query By Example).
• Lenguaje de control de datos (LCD): Permiten conceder o suprimir privilegios a los usuarios, es
decir, realiza el control del acceso a los datos. Con este lenguaje se establecen las vistas de los
usuarios, así a cada usuario se le permite manipular únicamente el conjunto de datos que le
interesan, y se le deniega el acceso a los datos que no necesita.
• Lenguajes de control de transacciones: Controlan los cambios realizados en los datos de la BD
mediante instrucciones de manipulación de datos (DML). Permiten agrupar varias instrucciones DML
como si fuesen una única instrucción lógica de manipulación, de forma que o se realiza el grupo de
instrucciones completo o se deshacen los cambios de todo el grupo (esto ocurriría en el caso de que
simplemente una de las instrucciones DML del grupo no pudiera realizarse o generara algún error en
su ejecución).
• Lenguajes de cuarta generación (4GL) o Herramientas de Desarrollo: La mayoría de los
SGBD comerciales los incluyen, y permiten al usuario crear aplicaciones de forma fácil y rápida para
acceder y manipular los datos de la BD. Por ejemplo, SQL Forms de Oracle, que permite crear
formularios para interactuar con los datos; SQL Reports de Oracle, para generar informes de los datos
contenidos en la BD; PL/SQL de Oracle, que es un lenguaje que permite crear procedimientos que
interactúen con los datos de la BD.

El Diccionario de Datos:

Es el lugar donde se guarda información acerca de todos los datos que forman la BD: su descripción y la
de los objetos que la forman. En una BD relacional, el diccionario de datos proporciona información acerca
de:
• La estructura lógica y física de la BD. Esquemas externo, conceptual e interno, y correspondencia
entre los esquemas.
o Las definiciones de todos los objetos de la BD: tablas, vistas, índices, disparadores,
procedimientos, funciones, etc.
o El espacio asignado y utilizado por los objetos.
• Los valores por defecto de las columnas de las tablas.
• Información acerca de las restricciones de integridad.
• Los privilegios y roles otorgados a los usuarios.
• Estadísticas de utilización, tales como la frecuencia de las transacciones y el número de accesos
realizados a los objetos de la base de datos.
• Se puede tener un historial de los cambios realizados sobre la base de datos.

Elementos de un SGBD

Un SGBD tiene varios módulos, cada uno de los cuales realiza una función específica. El sistema operativo
proporciona servicios básicos al SGBD, que es construido sobre él.

• El procesador de consultas es el componente principal de un SGBD. Transforma las consultas en un

conjunto de instrucciones de bajo nivel que se dirigen al gestor de la base de datos.
• El gestor de la base de datos es el interface con los programas de aplicación y las consultas de los
usuarios. El gestor de la base de datos acepta consultas y examina los esquemas externo y
conceptual para determinar qué registros se requieren para satisfacer la petición. Entonces el gestor
de la base de datos realiza una llamada al gestor de ficheros para ejecutar la petición.
• El gestor de ficheros maneja los ficheros en disco en donde se almacena la base de datos. Este gestor
establece y mantiene la lista de estructuras e índices definidos en el esquema interno. Si se utilizan
ficheros dispersos, llama a la función de dispersión para generar la dirección de los registros. Pero el
gestor de ficheros no realiza directamente la entrada y salida de datos. Lo que hace es pasar la
petición a los métodos de acceso del sistema operativo que se encargan de leer o escribir los datos en
el buffer del sistema.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 6
 II. Tecnología Básica

• El preprocesador del LMD convierte las sentencias del LMD embebidas en los programas de
aplicación, en llamadas a funciones estándar escritas en el lenguaje anfitrión. El preprocesador del
LMD debe trabajar con el procesador de consultas para generar el código apropiado.
• El compilador del LDD convierte las sentencias del LDD en un conjunto de tablas que contienen
metadatos. Estas tablas se almacenan en el diccionario de datos.
• El gestor del diccionario controla los accesos al diccionario de datos y se encarga de mantenerlo. La
mayoría de los componentes del SGBD acceden al diccionario de datos.
• Los principales componentes del gestor de la base de datos son los siguientes:
• Control de autorización. Este módulo comprueba que el usuario tiene los permisos necesarios para
llevar a cabo la operación que solicita.
• Procesador de comandos. Una vez que el sistema ha comprobado los permisos del usuario, se pasa el
control al procesador de comandos.
• Control de la integridad. Cuando una operación cambia los datos de la base de datos, este módulo
debe comprobar que la operación a realizar satisface todas las restricciones de integridad necesarias.
• Optimizador de consultas. Este módulo determina la estrategia óptima para la ejecución de las
consultas.
• Gestor de transacciones. Este módulo realiza el procesamiento de las transacciones.
• Planificador (scheduler). Este módulo es el responsable de asegurar que las operaciones que se
realizan concurrentemente sobre la base de datos tienen lugar sin conflictos.
• Gestor de recuperación. Este módulo garantiza que la base de datos permanece en un estado
consistente en caso de que se produzca algún fallo.
• Gestor de buffers. Este módulo es el responsable de transferir los datos entre memoria principal y los
dispositivos de almacenamiento secundario. A este módulo también se le denomina gestor de datos.

3 EVOLUCIÓN HACIA LOS SGBD

Los sistemas de información existen desde las primeras civilizaciones. El concepto más esencial de sistema
de información no ha variado desde los censos romanos, por poner un ejemplo. Los datos se recopilaban,
se estructuraban, se centralizaban y se almacenaban convenientemente. El objetivo inmediato de este
proceso era poder recuperar estos mismos datos u otros datos derivados de ellos en cualquier momento,
sin necesidad de volverlos a recopilar, paso que solía ser el más costoso o incluso irrepetible. El objetivo
de un sistema de información era proporcionar a los usuarios información fidedigna sobre el dominio que
representaban, con el objetivo de tomar decisiones y realizar acciones más pertinentes que las que se
realizarían sin dicha información. Llamamos base de datos justamente a esta colección de datos
recopilados y estructurados que existe durante un periodo de tiempo.
Generalmente, un sistema de información consta de una o más bases de datos, junto con los medios para
almacenarlas y gestionarlas, sus usuarios y sus administradores.
Hoy en día, sin embargo, solemos asociar las bases de datos con los ordenadores, y su gestión no suele
ser manual, sino altamente automatizada. Más concretamente, la tecnología actual insta a la delegación
de la gestión de una base de datos a unos tipos de aplicaciones software específicas denominadas
sistemas de gestión de bases de datos (SGBD) o, simplemente, sistemas de bases de datos. Por esta
razón, hablar de la tecnología de bases de datos es prácticamente lo mismo que hablar de la tecnología de
los sistemas de gestión de bases de datos.
Las funciones básicas de un sistema de gestión de base de datos son :

1. Permitir a los usuarios crear nuevas bases de datos y especificar su estructura, utilizando un
lenguaje o interfaz especializado, llamado lenguaje o interfaz de definición de datos.
2. Dar a los usuarios la posibilidad de consultar los datos (es decir, recuperarlos parcial o
totalmente) y modificarlos, utilizando un lenguaje o interfaz apropiado, generalmente llamado
lenguaje de consulta o lenguaje de manipulación de datos.
3. Permitir el almacenamiento de grandes cantidades de datos durante un largo periodo de tiempo,
manteniéndolos seguros de accidentes o uso no autorizado y permitiendo un acceso eficiente a
los datos para consultas y modificaciones.
4. Controlar el acceso a los datos de muchos usuarios a la vez, impidiendo que las acciones de un
usuario puedan afectar a las acciones de otro sobre datos diferentes y que el acceso simultáneo
no corrompa los datos.

3.1 Prim eros Sistem as de Base de Datos

Los primeros sistemas de bases de datos aparecieron a finales de los cincuenta. En este periodo, muchas
compañías se fueron dando cuenta de que los primeros sistemas informáticos brindaban la posibilidad de
aplicar soluciones mecánicas más baratas y eficientes. Los primeros sistemas evolucionaron de los

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 7
 II. Tecnología Básica

sistemas de ficheros que proporcionaban la función (3) comentada anteriormente: los sistemas de ficheros
almacenan datos durante un largo periodo de tiempo y permiten el almacenamiento de grandes
cantidades de datos. Sin embargo, los sistemas de ficheros no garantizaban generalmente que los datos
no se perdían ante fallos bastante triviales, y se basaban casi exclusivamente en recuperación por copia
de seguridad.
Además, los sistemas de ficheros proporcionaban de una manera limitada la función (2), es decir, un
lenguaje de consultas para los datos en los ficheros. El soporte de estos sistemas para la función (1) —un
esquema para los datos— también era limitada y de muy bajo nivel. Finalmente, los sistemas de ficheros
no satisfacen la función (4). Cuando permiten acceso concurrente a ficheros por parte de varios usuarios o
procesos, un sistema de ficheros no previene generalmente las situaciones en la que dos usuarios
modifican el mismo fichero al mismo tiempo, con lo que los cambios realizados por uno de ellos no llegan
aparecer definitivamente en el fichero.
Las primeras aplicaciones importantes de los sistemas de ficheros fueron aquellas en la que los datos
estaban compuestos de partes bien diferenciadas y la interrelación entre ellas era reducida. Algunos
ejemplos de estas aplicaciones eran los sistemas de reserva (p.ej. reserva e información de vuelos), los
sistemas bancarios donde se almacenaban las operaciones secuencialmente y luego se procesaban, y los
primeros sistemas de organización corporativos (ventas, facturación, nóminas, etc.).
Los primeros verdaderos SGBDs, evolucionados de los sistemas de ficheros, obligaban a que el usuario
visualizara los datos de manera muy parecida a como se almacenaban. Los primeros sistemas de ficheros
habían logrado pasar del código máquina a un lenguaje ensamblador con ciertas instrucciones de acceso a
disco, como la línea AS de IBM.
No es de extrañar que con este nivel de abstracción la manera de recuperar los datos estaba
estrechamente ligada al lenguaje de programación utilizado. Un avance importante lo constituyó el comité
formado en la Conference on DAta SYstems and Languages, CODASYL, en 1960 estableciendo el COmmon
Business-Oriented Language (COBOL) como un lenguaje estándar para interrelacionar con datos
almacenados en ficheros. Aunque hoy en día puede parecer un lenguaje “muy físico”, en aquella época
representó lo que se vinieron a llamar los lenguajes de programación de tercera generación. Las
instrucciones específicas de un programa Cobol para tratamiento de ficheros eran las de abrir un fichero,
leer un fichero y añadir un registro a un fichero. Lo típico en gestión de datos en esta época era un fichero
‘batch’ de transacciones que se aplicaba a un maestro viejo en cinta, produciendo como resultado un
nuevo maestro también en cinta y la impresión para el siguiente día de trabajo.
Pero pronto los discos magnéticos empezaron a sustituir a las cintas magnéticas, lo que supuso una
reconcepción del almacenamiento, al pasarse del acceso secuencial al acceso aleatorio (este paso es
el que se conoce como el paso de los sistemas de bases de datos de primera a segunda generación).
Durante los sesenta empezaron a aparecer distintos modelos de datos para describir la estructura de la
información en una base de datos, con el objetivo de conseguir una independencia un poco mayor entre
las aplicaciones y la organización física de los datos. Esto se consiguió inicialmente mediante la abstracción
entre varios (sub)esquemas externos para las aplicaciones frente a la organización física de los mismos.
Esta separación en dos niveles fue propuesta por el grupo Data Base Task Group (DBTG) del comité
CODASYL.
Los modelos más popularizados fueron el modelo jerárquico o basado en árboles, y el modelo en red o
basado en grafos. Los SGBD acordes con estos modelos se conocieron como SGBD de tercera generación.

Los modelos jerárquico y red, con el paso de los años, se pueden considerar como modelos puente hacia
el modelo relacional, ya que se incorporan en los primeros sistemas de gestión de bases de datos que
introducen un mayor nivel de independencia, respecto a la estructura interna, pero siguen teniendo una
estructura de cierto bajo nivel y de compleja manipulación.
Otro problema con estos modelos y sistemas iniciales era que no iban acompañados de lenguajes de
consulta de alto nivel. Por ejemplo, el lenguaje de consulta CODASYL tenía sentencias que permitían al
usuario saltar de un elemento de datos a otro a través de grafos de punteros entre estos elementos. Se
requería un gran esfuerzo para escribir estos programas, incluso para consultas muy sencillas.

Antes de pasar a ver los sistemas de base de datos relacionales, hay que destacar el nacimiento y
definición del concepto de transacción y sus propiedades asociadas, lo que se conoce como el “ACID test”.
Aunque el concepto de transacción evoluciona en las primeras décadas del desarrollo de las bases de
datos, se considera el trabajo de James Gray [Gray 1981] como el que le da su forma actual. Se dice que
un SGBD cumple el “ACID test” si observa las propiedades de (A)tomicidad, (C)onsistencia,
a(I)slamiento y (D)urabilidad. En concreto:

• Atom icidad : los resultados de una transacción o bien pasan a ser completados todos (commit)
o bien pasan a ser todos deshechos (rollback). Es decir, o todos los cambios incluidos en una
transacción tienen efecto o no lo tiene ninguno.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 8
 II. Tecnología Básica

• Consistencia : las bases de datos se transforman de estados íntegros a estados íntegros, es

decir, entre estados válidos. Una transacción sólo se puede completar si el estado final es
íntegro.
• Aislam iento : los resultados de una transacción son invisibles para el resto de transacciones de
otros procesos hasta que la transacción se ha completado.
• Durabilidad o perm anencia : una vez una transacción ha sido completada, los resultados
(cambios) de la transacción se hacen permanentes, incluso frente a fallos del sistema y de
medios de almacenamiento.

Sólo si estas propiedades de las transacciones se cumplen, podemos considerar que un SGBD cumple las
propiedades 3 y 4 comentadas al principio.

4 VENTAJAS E INCONVENIENTES. SISTEMAS DE FICHEROS VS. BASE DE DATOS

En los sistemas tradicionales de ficheros, los datos se recogen varias veces y se encuentran repetidos en
archivos específicos de cada aplicación. Esta redundancia origina a menudo divergencias de resultados y
malgastar recursos. Este tipo de sistemas se denominaban sistemas orientados hacia el proceso. Se
caracterizan por poner énfasis en los tratamientos que reciben los datos, los cuales se almacenan en
ficheros diseñados para cada aplicación. Las aplicaciones son independientes unas de otras y no suelen
transferir datos entre ellas.
Este tipo de sistemas tiene muchos problemas: ocupación inútil de memoria, aumento de tiempos de
proceso al repetirse los controles y operaciones en los distintos ficheros, pero mas graves todavía son las
inconsistencias de los datos que se encuentran repetidos en los distintos ficheros debido a la actualización
no se suele realizar de forma simultánea.

Estos problemas son mas acusados cuando se pretende un Sistema Orientado a la Toma de Decisiones. Se
necesita una gestión mas racional de los datos, surgiendo así un nuevo enfoque que se apoya sobre una
base de datos de la cual los datos son recogido y almacenados una sola vez. Se trata de sistemas
orientados a datos que sustituyen a los anteriores sistemas orientados a procesos debido a la falta de
adecuación a la realidad, porca fiabilidad y mal asegurada confidencialidad.

Las bases de datos presentan muchas ventajas con respecto a los sistemas de ficheros clásicos, mejoran
la calidad de las prestaciones de los sistemas informáticos y aumenta su redimiendo, sin embargo
depende del uso que se haga de ella y no resuelve todos los problemas de un negocio.

Las ventajas destacar en una bases de datos clasificados en tres grupos son las siguientes:

A. Referidas a los datos

• Independencia de los datos respecto a los tratamientos y viceversa.

• Mejor disponibilidad de los datos para el conjunto de los usuarios.
• Mayor eficiencia en la recogida, validación e introducción de los datos en el sistema.

B. Referidas a los resultados

• Coherencia de los resultados

• Mayor valor informativo
• Mejor y mas normalizada documentación de la información la cual está integrada con los datos

C. Referidas a los usuarios

• Acceso más rápido y sencillo de los usuarios finales

• Mas facilidades para compartir los datos por el conjunto de los usuarios
• Mayor flexibilidad para atender a demandas cambiantes.

Los inconvenientes que podemos destacar serían:

• Instalación costosa.
• Necesidad de personal especializado.
• Implantación puede ser una tarea larga y difícil.
• Falta de rentabilidad a largo plazo
• Escasa estandarización

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 9
 II. Tecnología Básica

• Desfase entre la teoría y la práctica.

5 MODELO DE DATOS
Un modelo de datos es un principio de organización que especifica mecanismos particulares para guardar
y recuperar datos. El modelo explica en termino de los servicios de que dispones para ninguna aplicación
con la que interactúa.

5.1 M odelo de Datos en Red. M odelo CODASYL

Los modelos en red representa las entidades en forma de nodos de un grafo, y las asociaciones o
interrelaciones entre ellos, mediante arcos que unen estos nodos. Esta representación permite el
modelado de estructuras de datos tan complejas como se desee por no imponer ninguna restricción al
número de arcos.

En el esquema se describen los aspectos estáticos:

• Entidades {E1, E2.....En } Serían los nodos.
• Interrelaciones { Ihj,k,...n} Se tratarían de los arcos.

Ambos con sus propiedades {Ai1, Ai2, ...Aik}

PROVEEDORES PEDIDOS ARTÍCULOS

PROV1 ART1

PROV2 ART2

Proveedor/Pedido
Articulo/pedido

Figura 2.Ejemplo Bases de datos en red

Restricciones. No existen restricciones inherentes , y las semánticas no están definidas al tratarse de un

modelo teórico.

En cuanto a la dinámica, los modelos en red se caracterizan por ser navegacionales, la recuperación y la
actualización de la base de datos se realiza registro a registro.

Manipulación de los datos.

• Localizar un registro.
• Pasar de una registro padre a su primer hijo.
• Moverse de un hijo a otro.
• Pasar de un hijo a su padre.

Otras características a destacar serían:

• La implementación se lleva a cabo por medio de punteros
• Es un modelo muy flexible, debido a que no existen restricciones inherentes, razón por la cual su
instrumentación física es difícil y poco eficiente.

Lo modelos Codasyl y Jerárquico corresponde a estas estructuras de tipo red pero con restricciones
bastantes fuertes.

Las ventajas de un modelo en red son:

• Se mantiene la integridad referencial.
• Las actualizaciones y borrados son en cascada.
El inconveniente es que un pequeño cambio en un programa puede suponer grandes modificaciones en el
sistema

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 10
 II. Tecnología Básica

5.1.1 Modelo CODASYL

El modelo Codasyl toma el nombre del comité que propuso sus especificaciones (COnference on DAta
SYstems and Languages) Data Base Task Group (DBTG) [CODASYL 1968]. Por eso, a veces se le conoce
como el modelo DBTG o el modelo CODASYL. Supone una simplificación del modelo en red debido a que
se admiten sólo determinados tipos de interrelaciones y se incluyen algunas restricciones adicionales que
no limitan en exceso la flexibilidad por la que se caracteriza el modelo de red. El modelo en red se
estandarizó a finales de los sesenta mediante un informe de CODASYL
El primer informe de CODASYL ya incluía la sintaxis y semántica de un lenguaje de definición de datos
(DDL, Data Definition Language) y de un lenguaje de manipulación de datos (DML, Data Manipulation
Language). Siguiendo muchos comentarios y revisiones de expertos y usuarios se realizó un nuevo
informe[CODASYL 1971], en el que ya se incluía la posibilidad de definir vistas para los distintos grupos de
usuarios. El término base de datos en red no se refería (al contrario de lo que se entendería hoy en día) a
que la base de datos estuviera almacenada en una red de ordenadores, sino por la manera en la que los
datos se enlazaban con otros datos. Se llama, por tanto, modelo en red porque representa los datos que
contiene en la forma de una red de registros y conjuntos (en realidad listas circulares llamadas sets) que
se relacionan entre sí, formando una red de enlaces. Para hacer esto utiliza registros, tipos de registro y
tipos de conjunto. Aunque este modelo permite más flexibilidad que el modelo jerárquico, y en algunos
casos se adapta muy bien a algunos tipos de transacciones, se considera superado por otros modelos,
como el relacional, o subsumido en parte por modelos más modernos, como el objetual.

El grupo Codasyl no se limitó a proponer un modelo de datos, sino que especificó la sintaxis de sus
diferentes lenguajes:
• Lenguaje de definición de datos del esquema (LDDDE) Permite describir la estructura de la totalidad
de elementos de la Base de datos.
• Lenguaje de definición de datos del Subesquemas (LDDS) Permiten la descripción de subconjuntos
del esquema para diferentes usuarios.
• Lenguaje de manipulación de datos (LDM)
• Lenguaje de Control de Dispositivos /soporte (LcDS)
• Lenguaje de definición del esquema de almacenamiento(LDEA)

Arquitectura
La arquitectura de las especificaciones CODASYL de 1971 pasó de ser una arquitectura a dos niveles
(esquema y subesquema) a transformarse en 1978 en una descripción totalmente lógica de la base de
datos al eliminarse los aspectos físicos que pasa al esquema de almacenamiento. Existen tres niveles, ya
que se separan los aspectos físicos en un nuevo esquema llamado de almacenamiento, mientras que las
características de tipo lógico siguen formando parte del esquema

Subesquema Subesquema

Esquema

Esquema de
almacenamiento

Figura 3 Arquitectura Codasyl

Elementos básicos del modelo:

• Campos o elementos de datos(data item): Unidad de datos mas pequeñas a la que se puede hacer
referencia.
• Agregado de datos (data aggregate) Puede ser un vector o bien un grupo repetitivo. Se corresponde
con los campos del fichero clásico y con los atributos de otros modelos, como el relacional
• Registro (record): Colección nominada de elementos de datos. Es la unidad básica de acceso y
manipulación de la base de datos y se corresponde con el concepto de registro y de entidad.
• Conjunto (SET o COSET): es una colección nominada de dos o mas tipos de registros que establece
una vinculación entre ellos.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 11
 II. Tecnología Básica

• Área (area o realm): Es una subdivisión nominada del espacio de almacenamiento direccionable de la
base de datos que contiene ocurrencias de registros. En 1981 paso a ser del esquema de
almacenamiento.
• Clave de la base de datos (database-Key): identificador interno único para cada ocurrencia del
registro que proporciona su dirección en la base de datos en principio, la clave de la bases de datos
era permanente y se podía utilizar para acceder rápidamente a un registro de forma permanente

5.2 M odelo Jerárquico

El modelo jerárquico no tiene una historia demasiado bien documentada. Se deriva de los sistemas de
gestión de información de los cincuenta y los sesenta. En 1968, IBM introdujo el sistema IMS, derivado del
programa Apolo de la NASA sobre sus System/360, basado en el modelo jerárquico. Este modelo fue
adoptado por muchos bancos y compañías de seguros.
No tiene una base teórica. Lo que se explique se extrae de la observación de un producto comercial como
es IMS (Informatión Management System) de IBM con el lenguaje de datos DL/I.

El modelo jerárquico se trata de un caso particular de los modelos en red. Y están organizados en
estructuras de árbol, compuestas de nodos, que representan las entidades, enlazados por arcos, que
representan las asociaciones o interrelaciones entre dichas entidades.

El modelo jerárquico se basa en almacenar los datos en una serie de registros, los cuales tienen campos
asociados a ellos. Para crear enlaces entre los tipos de registros, el modelo jerárquico utiliza las relaciones
padre-hijo, correspondencias 1:N entre tipos de registro. Esto se realiza mediante el uso de árboles. A
diferencia de otros modelos, el modelo jerárquico representa precisamente eso, todas las relaciones están
jerarquizadas en un árbol, por lo que no es capaz de establecer enlaces entre hijos o entre capas, si no es
padre-hijo. La ventaja del modelo jerárquico es su gran estructuración, que en aquel tiempo se veía como
una gran ventaja para mejorar el rendimiento de las transacciones (inserción, modificación y borrado de
registros), así como para simplificar la interfaz para los usuarios.

La implementación del modelo jerárquico se lleva a base de punteros. La estructura física, organización y
tipos de punteros, que varía según los productos, e incluso el mismo producto proporciona diferentes
organizaciones físicas con el fin de conseguir una mayor eficiencia en el diseño del modelo físico.
La estructura del modelo jerárquico es un caso particular del modelo de red, tiene fuertes restricciones
adicionales derivadas de las asociaciones deben formar un árbol en el que el orden de los nodos es
importante.

Características de la estructura jerárquica:

• El árbol se organiza en un conjunto de niveles.

• El nodo raíz, el mas alto de la jerarquía se corresponde con el nivel 0.
• Los arcos representan las asociaciones jerárquicas entre dos entidades y no tienen nombre, ya que no
es necesario porque entre dos conjuntos de datos sólo puede haber una interrelación.
• Un nodo de nivel superior (padre) puede tener un número ilimitado nodos de nivel inferior (hijos), al
nivel inferior en cambio solo le puede corresponder un único nodo de nivel superior. Es decir, un
registros padre puede tener un número indeterminado de hijos pero un hijo no puede tener más de
un padre.
• Todo nodo a Excepción del nodo raíz deben tener obligatoriamente un padre. Se llaman hojas los
nodos que no tienen descendientes
• Se llama altura a l número de niveles de la estructura jerárquicas.
• Se denomina momento al número de nodos.
• Solo se permiten interrelaciones 1:1 o 1:n

Ejemplo de una estructura de base de datos de una escuela que imparte cursos

Curso

Ofertas

Profesores matriculas

Alumnos

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 12
 II. Tecnología Básica

F i gu r a 4 : ej em p lo d e es t r u c t u r a j er ár qu ic a.

Forma de guardar la información.

La información se guarda árbol a árbol y de izquierda a derecha y de arriba a abajo.

Manipulación de los datos.

• Seleccionar un árbol determinado.
• Pasar de un árbol a otro.
• Pasar de un padre a su primer hijo.
• Pasar de un registro a otro dentro de un mismo nivel.
• Insertar/borrar registros de un nivel.

Mantenimiento de la integridad.
Referencial: No se puede tener un hijo sin su padre.
Permite borrados y actualizaciones en cascada.

El modelo jerárquico es muy eficiente en accesos asociados con la jerarquía del árbol, en cambio presenta
importantes inconvenientes como:

• Su rigidez e incapacidad de representar sin redundancias ciertas estructuras muy difundidas

como las relaciones reflexivas y N:M, las redes Tec.
• Poca flexibilidad de este modelo puede obligar a la introducción de redundancias
• Un pequeño cambio en el programa puede suponer grandes modificaciones en el sistema.
• Las actualizaciones pueden originar problemas, toda alta que no se corresponda a un nodo raíz
debe tener un padres y la baja de un registro supone que desaparezca todo el subarbol que tiene
dicho registro como nodo raíz.
•
Los SGBD basado en modelo jerárquicos suelen facilitar instrumentos que los dotan de mayor flexibilidad
para representar estructuras no jerárquicas.

5.3 M odelo Relacional

Edgar F. (Ted) Codd, un matemático formado en Oxford, que había entrado en IBM en 1949, no estaba
satisfecho ni con los productos Codasyl, ni con los sistemas jerárquicos de la propia IBM por los que
empezó a trabajar en una serie de informes técnicos acerca de una manera ‘nueva’ de organizar y acceder
a los datos. A partir de estos trabajos publicó el artículo “A Relational Model of Data for Large Shared Data
Banks” en 1970 [Codd 1970]. Codd propuso que los sistemas de bases de datos deberían presentarse a
los usuarios con una visión de los datos organizados en estructuras llamadas relaciones. Las relaciones se
definen como conjuntos de tuplas, no como series o secuencias de objetos, con lo que el orden no es
importante. Por tanto, detrás de una relación puede haber cualquier estructura de datos compleja que
permita una respuesta rápida a una variedad de consultas. Además, aunque no es un aspecto intrínseco
del modelo relacional, según la propuesta de Codd, el usuario de un sistema relacional no tenía que
preocuparse de la estructura de almacenamiento, sólo debía preocuparse por el qué consultar y no el
cómo. Hoy en día es válido todavía el resumen de su artículo [Codd 1970], especialmente la siguiente
parte:
“Future users of large data banks must be protected from having to know how the data is organized in the
machine (the internal representation). [...] Activities of users at terminals and most application programs
should remain unaffected when the internal representation of data is changed and even when some
aspects of the external representation are changed. Changes in data representation will often be needed
as a result of changes in query, update, and report traffic and natural growth in the types of stored
information.”
Además, las consultas podían expresarse en un lenguaje de muy alto nivel, lo que incrementaba en gran
medida la eficiencia de los programadores sobre bases de datos. En resumen, Codd concibió un sistema
donde el usuario sería capaz de acceder a la información con comandos parecidos al lenguaje natural y
donde la información estuviera almacenada en ‘tablas’.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 13
 II. Tecnología Básica

Pese a sus virtudes, la aceptación del modelo relacional no fue inmediata, debido en parte a la naturaleza
técnica del artículo y a su base matemática que, aunque muy simple, no era común para la industria de
bases de datos de la época. Además, se dudaba de la eficiencia del modelo. Más aún, dentro de IBM, la
reticencia fue muy grande, ya que IBM había invertido una gran cantidad de esfuerzo y dinero en el
producto ya existente IMS y líder del mercado. La nueva tecnología relacional debía demostrar que era
mucho mejor que la existente para cambiar la situación. De hecho, Codd publicó el artículo en una revista
de ámbito científico y abierto porque nadie en IBM (ni siquiera él mismo) reconoció en su momento el
impacto que tendría después. Todos se sorprendieron pronto de que la respuesta externa al artículo fuera
muy positiva. Incluso se acogió la idea con todo su potencial comercial. La reacción inicial de IBM fue
tajante: declaró IMS su producto estratégico con exclusividad y consideró el modelo relacional como
contrario a sus intereses. Codd, por su parte, no cedió en su defensa pública de las ventajas de su
propuesta e incluso mantuvo un debate público con Charles Bachman, el mayor defensor del estándar
Codasyl, ignorando del debate al modelo jerárquico, en el cual se basaba el IMS.

Esto dejaba al modelo jerárquico del IMS en una situación incómoda. Afortunadamente, y en parte debido
a esta publicidad, desde fuera, la Universidad de California en Berkeley creyó en la idea del modelo
relacional y obtuvo financiación militar y de la NSF (National Science Foundation) para desarrollar un
sistema relacional, el Ingres.

Codd Introdujo la teoría matemática de las relaciones de el campo de las bases de datos, lo que supuso
un sólido fundamento teórico para el desarrollo, dentro del enfoque relacional de los nuevos sistemas. El
modelo que CODD propone en su documento esta basado en la teoría de las relaciones en donde los
datos se estructuran lógicamente en forma de relaciones o tablas, siendo objetivo fundamental la
independencia de la estructura lógica respecto al almacenamiento y otras características físicas.
(independencia de ordenación, independencia de indización e independencia de los caminos de acceso)

Los objetivos de este modelo son:

• Independencia física: el modo en el que se almacenan los datos no influyen en su manipulación

lógica.
• Independencia lógica: la modificación de cualquier elemento de la base de datos no debe influir
en los programas y/o usuarios que accede a subconjuntos parciales de los mismos.
• Flexibilidad: de forma que ofrezca a cada usuario los datos de la forma mas adecuada a la
correspondiente aplicación
• Uniformidad: Las estructuras lógicas de los datos presentan un aspecto uniforma tablas, lo que
facialita la concepción y manipulación.
• Sencillez: El modelo debe resultar fácil de comprender y utilizar por parte del usuario.

Estructura del modelo relacional.

El elemento básico del modelo relacional es la relación y se representa en forma de tabla.

Las tablas están formadas por:

• Atributos: Conjunto de columnas que representan las propiedades de las tablas.

• Tuplas: Conjunto de filas que contienes los valores de cada uno de los atributos para cada elemento
de la relación.
• El dominio serian el conjunto de calores homogéneos y atómicos caracterizado por un nombre
donde los atributos pueden tomar sus valores.Los dominios pueden definirse por intención o por
extensión.
• Dominio compuesto combinación de dominios simples a la que se pueden aplicar ciertas
restricciones de integridad por ejemplo. Existen también atributos compuestos
• Grado: Número de atributos.
• Cardinalidad : número de tuplas.

La definición formal de relación definida sobre n dominios, no necesariamente distintos, es un subconjunto

del producto cartesiano de esos dominios, donde cada elemento de la relación tupla es una serie de
valores ordenados.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 14
 II. Tecnología Básica

Las clases de relación se pueden dividirse en nominadas y sin nombre:

• Las nominadas pueden ser:

• Persistentes: Son las relaciones cuya definición permanece en la base de datos, borrándose
solamente por una acción explicita de un usuario. A su vez se dividen en:
•
o Relaciones de base: Existen por si mismas y no en función de otras relaciones, Se
crean explícitamente su esquema de relación y sin extensiones y definición
o Vistas: Son relaciones derivadas que se definen dando nombre a una expresión de
consulta. Son relaciones virtuales.
o Instantáneas. Son relaciones derivadas al igual que las vistas pero con datos
propios almacenados, que son resultado de ejecutar la consulta especificada o de
guardar una relación base. No se actualizan cada bez que cambian los datos pero
se refrescan cada cierto tiempo.
o
• Temporales: desaparecen de la base de datos en un cierto tímelo sin una acción especifica del
usuario.

• Relaciones sin nombre: son los resultados de las consultas que no se materializan sino que se
entregan al usuario que ha realizado la consulta, y pueen ser tanta resultados intermedios como
finales. Son siempre relaciones temporales

Claves

• Una clave candidata de una relación es un conjunto de atributos que identifican unívoca y
minimamente cada tupla. En toda relación siempre hay al menos una clave candidata, pueden tener
mas de una las cuales se deben distinguir:
• Clave primaria: Identifica a las tuplas de la relación, la escoge el usuario por consideraciones ajenas
al modelo relacional
• El resto de las claves candidatos que no se han elegido como clave primaria se llaman Clave
alternativas.
• Clave ajena de una relación R2 es un conjunto no vacio de atributos cuyos valores han de coincidir
con los valores de la clave de candidata o primaria de una relación R1. R1 y R2 no son
necesariamente distintas.

Vamos a diferenciar las Restricciones inherentes y semánticas:

• Restricciones inherentes:
•
No hay dos tuplas iguales, por lo que se deduce la obligatoriedad de la clave.
La orden de las tuplas no es significativo
El orden de los atributos no es significativo.
Cada atributo sólo puede tomar un único valor del dominio sobre el que está definido, no
admitiéndose los grupos repetitivos. Entonces se dice que la tabla que cumple esta condición
normalizada(1ª forma normal)

Regla de integridad de entidad: Ningún atributo que forme parte de la clave primaria de una
relación puede tomar un valor nulo.

• Restricciones semánticas, las principales son las siguientes:

• Clave primaria: Permite declara a uin atributo p conjunto de atributos como clave primaria de
una relación, por los que su calores no se pueden repetir ni se nulos
• Unicidad
• Obligatoriedad
• Integridad referencial

La dinámica del modelo relacional, como todos

 Inserción de tuplas.
 Borrado de tuplas.
 Modificación de tuplas.
 Consultas.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 15
 II. Tecnología Básica

5.4 M odelo de Objetos

Los Sistemas de gestión de Bases de Objetos surgen debido a la falta de capacidad semántica del modelo
relacional para atender a las aplicaciones como sistemas basados en el conocimientos, bases de datos
médicas, multimedia tratamiento de documento, gestión de redes etc, que requieren modelar objetos e
interrelaciones complejos, almacenar información no estructurada, gestionar diferentes tipos de
transacciones y controlar de forma exhaustiva componentes y estructuras, además de manejar versiones y
configuraciones.

Coincidiendo con la entrada de los lenguajes orientados a objetos como Smalltalk o C++ en el ámbito
industrial, los investigadores se plantearon transportar estas ideas a las bases de datos y permitir que el
tipo de datos marcara cómo se representaba y se manipulaba dependiendo de los métodos que se
definían para dicho tipo o clase.

Desafortunadamente los SGBDO no implementan un modelo de objetos, cada fabricante ha adoptado un

modelo diferente. A pesar de no existir acuerdo universal, en lo que coinciden varios autores es en la
integración de los dos aspectos de información que se venían analizando tradicionalmente de forma
separada: datos y procesos.

En el paradigma de la orientación a objetos un sistema se concibe como un conjunto de objetos que se

comunica entre sí mediante mensajes. A nivel conceptual un objeto es una entidad percibida en el
sistema que se está desarrollando, mientras que a nivel de implementación un objeto se corresponde con
un encapsulamiento de un conjunto de operaciones que pueden ser invocadas externamente y de un
estado que recuerda el efecto de los servicios. El encapsulamiento es un principio de abstracción que
agrupa datos y procesos permitiendo ocultar a los usuarios de un objeto los aspectos de implementación,
ofreciéndoles una interfaz externa para interactuar con el objeto. El principio de ocultación es importante
permite modificar los aspectos privados de un objeto sin que se vean afectados el resto de objetos que
interactúan con este, siempre que se conserve la misma interfaz.

Un objeto se distingue por sus propiedades llamados atributos y por los servicios que puede proporcionar.

Todo objeto tiene una característica que lo identifica es el identificador del Objetos (IDO). Así mismo los
objetos se pueden clasificar en tipos de objetos. Los objetos se distinguen por:

- Poseer un estado que puede cambiar.

- Tener una identidad única.
- Soportar interrelaciones con otros objetos.
- Poseer un comportamiento.
- Poder recibir y emitir mensajes.

Se denomina Clase a la implementación de un objeto. Las interacciones entre objetos pueden ser
estáticas o dinámicas. En la primeras destacan la:

- Generalización, por la cual los tipos y clases se organizan en jerarquías que representan herencias y
que responde el concepto de “es-un”.
- Agregación que permite construir objetos complejos o compuestos que corresponde a la noción de
“parte-de”.
-
Las interacciones dinámicas consisten en mensajes, por medio de los cuales los objetos solicitan la
prestación de un servicio y entregan, en su caso, los resultados que se obtienen cuando se lleva a cabo un
cierto servicio.

Otra característica del paradigma de orientación a objetos es el polimorfismo, se trata de la capacidad

de que un mensaje sea interpretado de maneras distintas según el objeto que lo recibe.

SGBD relacionales “Extendido” VS SGBO “puros”

Existen dos enfoques a la hora de implementar los SGBD orientados a objetos. El primero sería extender
los SGBDR para que sean capaces de soportar los conceptos de orientación a objeto y por otra parte,
existen expertos mas puristas que sostienen que los SGBD orientados a objetos deben soportar un modelo
de objetos puros y no estar basado en extensiones. Ambos enfoques se describen a continuación.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 16
 II. Tecnología Básica

Bases de datos orientadas a objetos

La idea de una base de datos orientada a objetos se articuló por primera vez por [Copeland & Maier
1984], con el sistema prototipo GemStone. Uno de los sistemas más famosos de los finales de los
ochenta y principios de los noventa fue el sistema ObjectStore [Lamb et al. 1991]. Al principio de los
noventa, los primeros Sistemas de Gestión de Bases de Datos Orientados a Objetos (SGBDOO, o
simplemente, SGBDO) empezaron a aparecer en el mercado, a partir de compañías como Objectivity.
En este modelo la información sobre una entidad se almacena como un objeto persistente y no como una
fila en una tabla. Esto, en principio, lo hace más eficiente en términos de requerimientos de espacio y
asegura que los usuarios puedan manipular los datos sólo de las maneras en las que el programador haya
especificado. También es más eficiente en el uso de espacio de disco requerido para las consultas, ya que
en vez de almacenar la consulta, simplemente se construye una serie de índices (punteros) a los objetos
seleccionados. A esto hay que sumar las ventajas derivadas del modelo orientado a objetos, ya explotadas
en sus lenguajes de programación, la mayor expresividad y su adecuación para almacenar muchos tipos
de datos diferentes.

Los SGBO incorporan los conceptos básicos del paradigma de la orientación a objetos además de las
siguientes:

- Extensibilidad, ya que permiten al usuarios definir nuevas clases y modificar las existentes de
manera dinámica.
- Biblioteca de clases, que definen elementos con una alto nivel de funcionalidad que se pueden
integrar en la base de datos.

Otras características generales son:

- La persistencia ha de ser ortogonal con respecto al tipo de datos.

- El modelo de objetos está basado en el principio de identidad.
- Lenguaje de datos: Los fabricantes han desarrollado lenguajes parecidos al SQL con una semántica
distinta, se denominan “OSQL” u “object SQL”
- Los lenguajes son navegacionales por lo que la optimización resulta más difícil. EN cambio el
rendimiento de un SGBD es superior a un SGBDR cuando navega a través de objetos ya cargados en
memoria.

Alguien podría pensar, por tanto, que las bases de datos orientadas a objetos deberían de haber superado
en la práctica a las relacionales. De hecho, a veces se denominan postrelacionales. No obstante, en el
mercado de las bases de datos orientadas a objetos no supone más de un 5% del mercado de las
relacionales.

Hay varias razones para explicar este hecho. En primer lugar, las bases de datos objetuales acarrean
consigo algunas de las propiedades no deseables de los modelos pre-relacionales. El programador tiene
que tener mucha información sobre la estructura de los datos. Si se conocen las propiedades de los
objetos, la consulta es rápida y simple. Pero la realidad es que en muchos casos se desconocen las
identidades de los objetos. Lo que preocupa o interesa es almacenar los atributos de los objetos y
relacionar los valores de estos atributos, aspecto en el que el modelo relacional es más sencillo.
En segundo lugar, el hecho de que las organizaciones sean capaces de alterar los métodos de bajo nivel
utilizados en los SGBDO, hace que sea más difícil para terceros el hacer productos añadidos. Mientras que
las bases de datos relacionales se pueden beneficiar del software realizado por otras firmas, los usuarios
de SGBDO tienen que producir el software en casa para adaptarse a sus propias particularidades, parte de
ellas incorporadas al comportamiento de los objetos.

En tercer lugar y quizás más importante es el hecho que las organizaciones tiendan a ser conservadoras
en relación con las bases de datos, uno de sus activos más valiosos. El hecho es que no acaban de
decidirse por embarcarse en un SGBDO y siguen aferrados al SQL para realizar sus informes y al SQL
embebido para interrelacionar las aplicaciones con el SGBD, manteniendo una separación que consideran
imprescindible.

Del mismo modo que evolucionaba el modelo objetual para el nivel lógico y el nivel físico, debían también
evolucionar o desarrollarse nuevos modelos conceptuales y metodologías orientadas a objetos. El modelo
entidad relación (extendido) se mostró insuficiente para la etapa de diseño conceptual de bases de datos
orientadas a objetos. Para ello se importaron o adaptaron lenguajes de modelado e incluso gran parte de
las metodologías utilizadas en ingeniería del software orientada a objetos. Por ejemplo, la metodología
Object Modeling Technique (OMT) desarrollada a principios de los noventa en General Electric [Rumbaugh
et al. 1996], la metodología (análisis y diseño O-O) de Booch [Booch 1991, 1994] o posteriormente el

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 17
 II. Tecnología Básica

lenguaje de modelado ‘unificado’ UML [Booch et al. 1997] [Booch et al. 1999], aunque pensadas para el
desarrollo de software orientado a objetos, se han ido adaptando o importando al campo de las bases de
datos como herramienta de modelado conceptual de bases de datos orientadas a objetos.
El estándar UML y su integración en metodologías de diseño y modelado de bases de datos supuso un
gran impulso a este modelo de datos desde su introducción en los ochenta. El cuerpo principal del
lenguaje de modelado unificado UML se desarrolló principalmente a principio de los noventa, por un grupo
de ‘gurús’ de la ingeniería de software orientada a objetos: Booch, Jacobson y Rumbaugh. Cuestiones
comerciales aparte, el UML fue aceptado como estándar por el ODMG (del que hablaremos más abajo) y el
hecho de haberse estandarizado un lenguaje de modelado orientado a objetos y que éste esté basado en
lo “mejor” de otras metodologías anteriores, hace que la adaptación de profesionales y su movilidad entre
distintas organizaciones sea más sencilla.

UML puede utilizarse para cualquier sistema orientado a objetos, lo que le hace también apropiado para el
diseño de bases de datos orientadas a objetos. Especialmente lo hace apropiado para que los especialistas
en bases de datos y analistas especifiquen lo que quieren que los programadores realicen, en términos del
SGBDO y de los programas que interaccionan con él. Finalmente hay que recordar que UML es sólo un
lenguaje y no una metodología, con lo que también es posible utilizar UML como notación para expresar el
modelo entidad-relación.

El ODMG (Object Database Management Group) es un grupo de vendedores y usuarios de bases de datos
que desarrollan estándares para los SGBDO (www.odmg.org). El primer documento fue el ODMG 1.0 in
1993, que incluía el OQL (Object Query Language), un lenguaje de consultas orientado a objetos muy
inspirado en el SQL.

Aunque durante los principios de los noventa tuvo bastante fuerza, hoy su importancia es menor debido a
que SQL incluye muchas características orientadas a objetos.

Además del OQL, el ODMG v.3.0 incluye un modelo de objetos estándar y enlaces para los tres lenguajes
orientados a objetos más populares: C++, Smalltalk y Java. La especificación del ODMG 3.0 se puede
encontrar en (www.odmg.org), en [ODMG 2000] o en [Cattell & Bary 2000]. Ahora se está encargando
de desarrollar la cuarta generación.

El modelo relacional extendido

El modelo objeto-relacional es un desarrollo más reciente y parece haber tenido bastante efecto. No es
una tecnología en sí, sino una aglutinación de los modelos relacional y orientado a objetos. De hecho,
algunas extensiones objetuales a los sistemas relacionales se pueden datar en los principios de los
ochenta [Zaniolo 1983]. Como hemos dicho antes, existía la necesidad imperiosa de la industria y de sus
clientes de tratar con nuevos tipos de datos: audio, imágenes y vídeo, además de tipos definidos por el
usuario con sus propias propiedades.

Por otra parte, hemos visto que las organizaciones eran reticentes a migrar de un SGBDR a un SGBDO por
diversos motivos.

Además, el mantenimiento de los SGBDR empezaba a crear desajustes con un cada día más generalizado
uso de los lenguajes orientados a objetos. Los programadores en estos lenguajes tenían que realizar una
serie de pasos de traducción de la estructura objetual del programa y de los datos en memoria principal a
la estructura relacional de los datos.

Aquí es donde el modelo objeto-relacional puede demostrar su valor. El modelo objeto-relacional se define
como una extensión objetual del modelo relacional, permitiendo la definición de nuevos tipos y de
relaciones de herencia, entre otras cosas. Permite a las organizaciones continuar usando sus sistemas
existentes y sus datos, sin realizar prácticamente cambios y les permiten empezar a utilizar gradualmente
características orientadas a objetos, especialmente si se hace en conjunción con aplicaciones desarrolladas
en entornos también orientados a objetos.

Uno de los ejemplos de este mestizaje es, por ejemplo, JDBC (Java DataBase Connectivity). Aunque
pensado para interrelacionar bases de datos relacionales con Java, va incorporando algunos detalles
objeto-relacionales.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 18
 II. Tecnología Básica

De una manera más precisa, JDBC es una API (Applications Programming Interface) desarrollada por Sun
Microsystems (http://java.sun.com/products/jdbc/index.html) para conectar Java con las bases de datos,
con una filosofía inspirada en ODBC. De hecho es usual conectar un programa Java con una base de datos
directamente o a través de ODBC, dependiendo de si el fabricante de la base de datos ha creado los
drivers necesarios para Java.

Otro ejemplo de mestizaje a un nivel diferente es el SQL3 [ANSI/ISO/IEC 1999]. SQL3 es la nueva versión
desarrollada por los comités ANSI X3H2 e ISO DBL para extender SQL2 con el tratamiento de datos
orientados a objetos (entre otras cosas). Hablamos de mestizaje porque esta extensión se ha hecho de tal
manera que el SQL3 es compatible hacia adelante con el SQL-2.

Las facilidades orientadas a objetos del SQL3 se centran en extensiones de los tipos y las tablas en SQL.
Las partes del SQL3 que proporcionan la base para trabajar con estructuras orientadas a objetos son:
tipos definidos por el usuario (user-defined types, UDTs), constructores de tipo para tipos de fila y tipos
referencia, tipos constructores para colecciones (conjuntos, listas, ...) y funciones y procedimientos
definidos por el usuario.

Una de las ideas básicas detrás de estas extensiones es que, además de los tipos predefinidos (built-in) de
SQL, el usuario puede definir otros tipos que pueden ser utilizados después como los tipos predefinidos.
Siguiendo el paradigma orientado a objetos, una definición de UDT encapsula los atributos y las
operaciones en una única entidad o clase, que en SQL3 se llama tipo. En concreto en SQL3 se define un
UDT declarando los atributos que almacenan el valor y estado del UDT, definiendo las operaciones de
igualdad y de orden para el tipo, y, finalmente, definiendo las operaciones que determinan el
comportamiento específico del UDT. Las operaciones (lo que en el paradigma orientado a objetos se
suelen llamar métodos) se implementan mediante procedimientos llamados rutinas. Las operaciones
pueden incluir comandos de manipulación SQL embebidas
(SELECT, INSERT, UPDATE, DELETE).

El SQL3 también está provisto de herencia y delegación. Mediante la especificación de “UNDER <nombre
del UDT >” en la parte de subtipo de una definición UDT, se puede definir un UDT como un subtipo (lo
que se conoce normalmente como especialización, clase derivada o subclase) de un UDT existente. Un
subtipo hereda todos los atributos y el comportamiento de sus supertipos y se pueden extender con más
atributos y variar su comportamiento. Una instancia de un subtipo se puede utilizar en cualquier lugar
donde una de las instancias de sus supertipos se pueda utilizar. De momento, SQ3 no soporta la herencia
múltiple, con lo que un UDT puede tener como mucho un supertipo.

A pesar de todas estas extensiones, la estructura principal de representación lógica del SQL3 sigue siendo
la tabla, con lo que el modelo subyacente del SQL3 se puede considerar objeto-relacional. Las siguientes
especificaciones SQL:2003 y SQL:2006 añaden nuevas extensiones orientadas a objetos.

5.5 Tendencias

5.5.1 Bases de Datos Paralelas y Distribuidas

Las bases de datos paralelas se empezaron a desarrollar alrededor de 1980, especialmente con el proyecto
Gamma [DeWitt et al. 1990], un sistema de base de datos sobre una serie de procesadores de propósito
general funcionando en paralelo. Este sistema es en el que se inspiran la mayoría de sistemas paralelos de
IBM, Tandem, Oracle, Informix, Sybase y AT&T. Además, el uso de sistemas paralelos para la minería de
datos es uno de los campos de investigación más activos actualmente. Los sistemas de bases de datos
paralelos, como casi toda la tecnología paralela, fue acuñada como la tecnología del futuro en cuanto a
altas prestaciones. Hoy en día la postura es más realista y se reconoce su uso en sistemas de muy altas
prestaciones, aunque para sistemas de uso corriente, incluso grandes empresas, su uso es más limitado.
No obstante, por muy paralelo que fuera el sistema, todo ordenador tiene su límite. Aunque la capacidad
de proceso aumentara, existían limitaciones en la cantidad de memoria que el sistema direccionaba, el
número de discos duros que podían conectarse a un mismo procesador y el número de procesadores que
podían correr en paralelo. En la práctica, esto significa que, a medida que la cantidad de información de
una gran base de datos aumenta, un único sistema, aunque sea paralelo, deja de poder dar abasto con
toda la información que tiene que almacenarse, ordenarse y consultarse.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 19
 II. Tecnología Básica

Aunque es posible comprar sistemas cada día más grandes y rápidos, a veces no es económico sustituir el
hardware cada pocos años o incluso meses, periodo en el que se suele duplicar la información de una
organización. En cambio, es mucho más realista tener varios servidores de bases de datos e ir añadiendo
a medida que la organización necesita más capacidad. Esto se debe hacer de manera que los usuarios
crean que siguen trabajando con un único sistema, el sistema integrado de la organización. Mediante esta
filosofía, la organización tiene más flexibilidad en sus ampliaciones, se realizan de una manera menos
traumática y con ordenadores de talla media, que suelen ser mucho más baratos que uno grande
equivalente en potencia.

Este concepto lleva al paradigma de las bases de datos distribuidas, y tienen las características comunes
de que los datos se almacenan en dos o más ordenadores, llamados nodos, y que estos nodos están
conectados en una red. Hoy en día, con el aumento de la descentralización, debido al abaratamiento,
ancho de banda y flexibilidad de las redes de computadores, ha hecho que el uso de las bases de datos
distribuidas haya aumentado considerablemente.

Si hablamos de un único sistema de gestión de bases de datos que actúa sobre distintos ordenadores
distribuidos y gestionando la misma base de datos, hablamos propiamente de bases de datos distribuidas.

En el caso que cada sistema esté formado por varios SGBD, se suele hablar de Sistemas de Múltiples
Bases de Datos, que pueden estar fuertemente acoplados o débilmente acoplados, llamándose estos
últimos sistemas interoperantes de bases de datos [Litwin & Chien 1994].

Sin entrar en demasiadas distinciones terminológicas entre los sistemas de bases de datos distribuidos y
los sistemas de múltiples bases de datos, o si los datos pueden o no estar replicados, el punto
fundamental de todos estos sistemas es que los usuarios no deben percatarse de esta dispersión espacial
de los datos, es decir, los usuarios deben percibir lo mismo que si trabajaran con un único sistema
centralizado.

En general, se suele realizar la siguiente clasificación habitual entre sistemas de bases de datos
homogéneos y heterogéneos

• Las bases de datos distribuidas homogéneas usan el mismo software de SGBD y tienen las mismas
aplicaciones en cada nodo. Tienen un esquema común y pueden tener grados diversos de autonomía
local. Pueden estar basadas en cualquier SGBD que soporte estas características, pero no puede
haber más de un SGBD en el sistema. La autonomía local especifica cómo el sistema funciona desde
la perspectiva de los usuarios y programadores. Por ejemplo, podemos tener un sistema con poca o
sin autonomía local, donde todas las peticiones se envían a un nodo central, llamado gateway. Desde
aquí se asigna al nodo que contiene esa información o aplicación requerida. Esto es lo típico que se ve
con los mirrors de sitios web muy populares a los cuales una página central deriva las peticiones de
sus usuarios dependiendo de su origen geográfico.
• En e l otro la do de la e sca la , se e ncue ntra n la s ba se s de da
éntos
e a shecon
te rog
un a lto gra do de
autonomía local. Cada nodo en el sistema tiene sus propios usuarios, aplicaciones y datos locales y es
el sistema el que trata con ellos directamente y sólo conecta con otros nodos en busca de información
que no tiene. Este tipo de base de datos se suele llamar sistema federado o federación. Se ha hecho
cada día más popular en las organizaciones, tanto por su escalabilidad, su capacidad de mezclar
distintos paquetes software y su reducido coste al añadir nuevos nodos cuando es necesario. A
diferencia de los sistemas homogéneos, los sistemas heterogéneos pueden incluir diferentes SGBD en
los nodos. Esto los hace atractivos en grandes corporaciones, ya que pueden mantener sus sistemas
heredados antiguos (legacy systems) junto con los nuevos sistemas.

Uno de los primeros sistemas distribuidos fue R*, desarrollado en IBM [Williams et al. 1998] a principios
de los ochenta. Últimamente el área de las bases de datos distribuidas está cada vez más en relación con
Internet y la tecnología web, hablándose de bases de datos distribuidas de área global

5.5.2 Bases de Datos Multimedia

Las bases de datos multimedia almacenan una gran variedad de tipos de datos. Estos tipos incluyen texto,
imágenes, audio y vídeo. Hasta hace unos años estas bases de datos eran difíciles de implementar, debido
al tamaño de los objetos y la complejidad de los datos. El añadir metadatos a los ficheros multimedia
(p.ej. el formato WAV) resolvía parcialmente el problema. Esta cabecera incluye datos del formato, el
creador, el contenido, la longitud del stream de datos, etc. El problema es que está información no suele
estar indizada conveniente y no se puede utilizar para realizar consultas.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 20
 II. Tecnología Básica

Imaginemos una base de datos que contiene clases grabadas en vídeo. La metainformación que nos
puede interesar de cada vídeo puede ser: compañía/universidad donde se dio la clase, quién la dio,
cuándo se dio, de qué va, cuánto duró, etc. Esta información es la que se utilizará cuando los usuarios
busquen clases en la base de datos.

Debido al avance en las redes de computadores la división entre bases de datos paralelas y bases de
datos distribuidas es cada día más sutil, y existen muchos sistemas híbridos.

Hay dos métodos principales para incluir metadatos en una base de datos multimedia: mediante análisis
automático o mediante análisis manual:

• Aunque el análisis manual es más efectivo, porque permite anotar aquellas características del objeto
multimedia que son importantes, requiere mucho tiempo y por tanto es muy costoso. Además es
difícil conseguir homogeneidad en los criterios que se utilizan para agregar estos metadatos.
• El análisis automático es mucho más rápido, pero las técnicas todavía son limitadas en algunos casos
(especialmente en imagen y sonido). Su mayor ventaja es que proporciona una descripción
consistente de los datos y no se ve afectada por estilos individuales.

Si hace pocos años, las bases de datos multimedia no eran asequibles para los usuarios de ordenadores
personales, el abaratamiento de discos con gran capacidad de almacenamiento, hace que cualquier
ordenador personal pueda contener una biblioteca de imágenes y piezas musicales, y en breve, de
películas. Otro problema es el uso de estas bases de datos para distribución por Internet (especialmente
VoD, Video on Demand), para el cual el ancho de banda todavía tiene que crecer enormemente.

6 SGDBR. SISTEMA DE GESTIÓN DE BASE DE DATOS RELACIONAL

6.1 Características SGBDR

Las principales características de un SGBR son las siguientes:

1. Proporciona el entorno del Diccionario o Meta Base de Datos o Catálogo de la BD:

Se trata del conjunto de tablas y datos que permite explicar el contenido de la BD.
El mantenimiento del Diccionario lo gestiona de forma íntegra el gestor. Se puede permitir cierta
intervención al DBA para realizar ciertas mejoras.
2. Suministro del Entorno de Comunicaciones. Proporciona todos los protocolos que permiten
entrada al gestor.
a. Modelo Cliente/Servidor
b. Puede incorporar Servidor de Aplicaciones
c. También protocolos nativos.
d. Puede operar desde el propio Nivel 1.
e. p.e. SQL*NET (Oracle) sobre (IP / NETUI / MAC)
3. Manejo de grandes volúmenes de datos.
a. Acceso a formas de almacenamiento masivo (RAID, SAN, NAS…)
b. Acceso raw a dispositivos físicos.
4. Imprescindible el manejo de concurrencia en los accesos.
5. Incorpora técnicas que mejora la escalabilidad y la capacidad de cómputo :
a. Grid Computing
b. Cluster
c. p.e. (DB2 o Oracle 10g)
Alta Disponibilidad : Con técnicas de balanceo también dado por solución de tipo gris o cluster.
6. Incorpora técnicas de seguridad, certificación, confidencialidad y autenciación de acceso a los
datos.
7. Integridad de los Datos.
8. Independencia Física o Lógica.
9. Debe proporcionar las herramientas de Administración de la BD (DBA).
a. Herramientas de Tunning de BD.
b. Herramientas de Performance (estudios de carga).
c. Herramientas de Gestión de Usuarios, de Discos y de Servidor.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 21
 II. Tecnología Básica

6.2 Com ponentes de un SGBDR

6.2.1 Componentes de Proceso

Los componentes de procesamiento de sentencias DML/DDL son:

 Compilador DML: traduce las sentencias DML en instrucciones de bajo nivel para
ser ejecutadas por el motor de ejecución del SGBD. El SGBD suele incorporar un
módulo optimizador de consultas que determina la estrategia óptima para la
ejecución de consultas
 Precompilador DML: traduce las sentencias DML incrustadas en un programa
escrito en un lenguaje externo al SGBD (SQl embebido) en llamadas a funciones
estándar escritas en el lenguaje anfitrión.
 Intérprete DDL: interpreta las instrucciones DDL y genera los metadatos
necesarios en el diccionario de datos
 Motor de ejecución: encargado de que se ejecuten las sentencias ya compiladas
utilizando los componentes de gestión de almacenamiento.

6.2.2 Componentes para el Almacenamiento

Componentes de gestión del almacenamiento: se encargan del acceso directo a los

datos solicitados por el motor de ejecución

o Gestor de ficheros: gestiona los ficheros en disco en donde se almacena la

base de datos. El gestor establece y mantiene la lista de estructuras e índices
definidos en el esquema interno. Pero el gestor de ficheros no realiza
directamente la entrada y salida de datos. Lo que hace es pasar la petición a
los métodos de acceso del sistema operativo que se encargan de leer o escribir
los datos en el buffer del sistema.
o Gestor de memoria intermedia o gestor de buffers: Este módulo es el
responsable de transferir los datos entre memoria principal y los dispositivos
de almacenamiento secundario
o Gestor de autorización e integridad: comprueba que el usuario tiene los
permisos pertinentes y que satisfacen las restricciones de integridad necesarias
o Gestor de transacciones: se encarga del procesamiento transaccional,
asegurando un estado consistente de BD aunque se produzcan fallos del
sistema (gestor de recuperación) o existan transacciones concurrentes
(planificador o scheluder y gestor de bloqueos).

6.2.3 Estructuras de datos

Serían ficheros de datos, diccionario de datos (metadatos: sintetizan la información que el
gestor almacena sobre él mismo y las bases de datos que tiene almacenadas), índices, datos
estadísticos, etc.

7 ARQUITECTURA ANSI/X3/SPARC DE BD
Uno de los objetivos de un sistema de bases de datos es proporcionar a los usuarios una visión abstracta
de la información, ocultando ciertos detalles acerca de cómo se almacenan los datos, pero permitiendo
una recuperación eficaz de la información.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 22
 II. Tecnología Básica

Figura 5: Relación de los organismos de normalización.

Una de las arquitecturas más estandarizada es la especificada por la normativa ANSI/X3/SPARC es un

grupo dentro del Standard Planning and Requirements Committee of the American National Standards
Institute – Comité de Planificación y Requerimientos de estándares del Instituto Nacional de Estándares de
Estados Unidos, dentro de la división X3 se ocupa de ordenadores u informática. En 1972 estableció un
grupo de estudio ad hoc para estudiar los aspectos de un SGBD que en aquel momento eran candidatos a
estandarización asi como emitir un conjunto de recomendaciones de acción en tales áreas. Produjo una
serie de informes parciales hasta que en 1975 publicó el informe provisional (interim report) en el que se
presentaba una arquitectura de un sistema de gestión de bases de datos que incluía la identificación y
descripción de sus interfaces.Según esta norma la arquitectura de una base de datos debe tener tres
niveles: externo, conceptual e interno. En la siguiente figura se muestra la organización de esta
arquitectura.

Figura 6: Arquitectura a tres niveles ANSI/X3/SPARC.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 23
 II. Tecnología Básica

La arquitectura a tres niveles del grupo Ansi ha marcado una línea de investigación diferente en las Bases
de datos con su esquema conceptual.

El esquema conceptual o descripción global de los datos se deriva una colección de esquemas externos
que son la visión que tienen de las bases de datos de las diferentes aplicaciones; el esquema interno es la
descripción de los datos de cara a la máquina.

El SGBD es el que se encarga de la transformación o correspondencia entre unos esquemas y otros.

7.1 N ivel I nterno

Es el más cercano al almacenamiento físico. Se ocupa de cómo los datos se almacenan en el
soporte:
• La estructura de almacenamiento físico de los datos.
• La organización de los ficheros.
• Los modos de acceso.
• Los índices y apuntadores.
• El bloqueo de registros.
• Rendimiento esperado.

El nivel interno se describe por medio de un esquem a interno o vista interna. Si el nivel interno y
conceptual estuviesen totalmente separados, no se necesitaría de este esquema, ya que podría diseñarlo
automáticamente el propio sistema a partir del esquema conceptual. Como no suele ser así, el
administrador deberá comunicar al sistema gestor de la base de datos ciertas características respecto a la
estructura interna que tiendan a conseguir una mayor eficiencia en el almacenamiento y recuperación de
la base de datos.

El administrador es el único que trabaja a nivel interno. Al diseñar el esquema interno se intenta conseguir
los siguientes objetivos:

• Disminuir al máximo el tiempo de respuesta del sistema.

• Minimizar el espacio de almacenamiento.
• Evitar en lo posible la redundancia de información.
• Optimización de los recursos de los que se disponen.

En este nivel se pueden distinguir dos partes claramente separadas que hacen referencia a dos aspectos
clave en cualquier implementación de una solución informática:

1. en primer lugar cómo se pasa del modelo lógico del problema a unas estructuras (tablas del
modelo relacional) y procedimientos informáticos comprensibles por el ordenador
2. en segundo lugar, qué herramienta (léase sistema gestor de bases de datos) se va a utilizar para
implementar dichas estructuras y procedimientos. Esta elección del gestor debe ir acompañada
por un diseño específico de la forma en que se va a distribuir el espacio disponible para
almacenamiento, la creación de índices, el establecimiento de mecanismos de seguridad, la
posibilidad de ofrecer accesos concurrentes, el equilibrado de la carga de proceso, etc. Esta
faceta del nivel físico depende en gran medida del sistema hardware/software disponible

7.2 N ivel conceptual

Es el modelo de información de la empresa, es la definición abstracta de la base de datos que contiene la
visión desde el punto de vista de la empresa sin tener en cuenta la implementación física. Esta visión es
más estable que los otros dos niveles.

Se puede considerar como un modelo teórico de la base de datos sobre el cual estarán asentados los
submodelos externos. Se trata de tener una visión global de los datos “como realmente son”, sin estar
forzados a definirlos por medio de las restricciones de un lenguaje de programación o un dispositivo
hardware concreto.

El administrador es el único que trabaja a nivel conceptual, ya que los usuarios trabajan a nivel externo
utilizando subconjuntos de la estructura conceptual.

El objetivo de este nivel es proporcionar una descripción real de la organización independiente de la

estructura física de los datos. El nivel conceptual se describe por medio de un esquem a o vista
conceptual de la base de datos. El esquema conceptual podría contener:

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 24
 II. Tecnología Básica

- Las entidades del mundo real (Por ejemplo: empleados, departamentos, componentes, etc. ...)
- Los atributos de las distintas entidades (Por ejemplo para la entidad empleado: Nº personal,
nombre, dirección, DNI, nº hijos, sueldo etc. ...)
- Relaciones entre las distintas entidades (Por ejemplo: Un empleado pertenece a un departamento,
un departamento contiene varios empleados, etc. ...)
- Podrían incluirse verificaciones de seguridad e integridad (Por ejemplo: un empleado no podría
pertenecer a un departamento que no existe).

El Modelo Conceptual de Datos se corresponde con este nivel y se obtiene aplicando el Modelo E/R de
Peter Chen.

7.3 N ivel externo

Es el nivel superior que representa las vistas externas personalizadas que varían de acuerdo a la aplicación
de diferentes usuarios. ·Es la visión desde el punto de vista del usuario individual, es decir el subconjunto
de datos y relaciones entre ellos que él ve. Esta es a menudo una visión restringida de la base de datos,
de forma que la misma base puede tener diferentes puntos de vista para usuarios distintos. No todos los
programas ni los usuarios que acceden a la BD necesitan tener una visión total de la información
almacenada. Diferentes vistas externas pueden usar la misma descripción conceptual para satisfacer
expectativas distintas. En el nivel externo se describe de forma individual un subconjunto de datos para un
usuario o conjunto de usuarios. Los usuarios pueden trabajar con los archivos externos como si existiesen
físicamente, aunque éstos en realidad no existen tal como son vistos por el usuario. Por cada tipo de
usuario es necesario especificar un esquema externo, subesquem a o vista externa, que describe un
subconjunto de datos de la base de datos. Por lo tanto, existirán tantos subesquemas como tipos de
usuarios tenga la base de datos (uno por cada uno de ellos). Habrá usuarios que podrán acceder a más de
un esquema externo, y un esquema externo podrá ser compartido por varios usuarios.

Por ejemplo, un departamento financiero no necesita la información académica de los alumnos, o al revés
el personal académico no está interesado en información económica. Por tanto, se puede decir que el nivel
externo está orientado hacia el usuario y comprende las características lógicas de los datos para los
programas de aplicación. La existencia de este nivel aísla a los usuarios no sólo del aspecto físico de la BD
sino también de cualquier parte de la misma que no esté relacionada con la tarea que deben desempeñar,
aumentando la seguridad, ya que al crearse vistas parciales de la BD los usuarios sólo tienen acceso a las
partes seleccionadas de la misma.

Al haber diferentes usuarios con distintas necesidades (aplicaciones informáticas), existirán distintos
esquemas lógicos externos para un mismo esquema conceptual. El Modelo de Datos Lógico (que no es
único para el SI y depende del tipo de SGBD, normalmente Relacional de Codd) se corresponde con este
nivel y se representará mediante la técnica del DED.

7.4 Transform ación de datos

El SGBD debe poder garantizar la transferencia de los datos desde el nivel interno al nivel externo, a este
proceso se llama transformación de datos o mapeo (data mapping). Para ello existen dos niveles de
correspondencia:
• Correspondencia conceptual/interna: Permite el paso de la vista conceptual a la vista interna, y
viceversa. Especifica cómo se representan los registros y campos conceptuales en el nivel interno. Si se
modifica la estructura interna de la base de datos, la correspondencia conceptual/interna deberá
modificarse, para que no varíe el esquema conceptual. De este modo se conserva la independencia de los
datos.
• Correspondencia externa/conceptual: Permite el paso de una vista externa específica a la vista
conceptual, y viceversa.

Los subesquemas, el esquema conceptual, el esquema interno y las correspondencias conceptual/interna y

externa/conceptual, las describe el administrador de la base de datos y quedan almacenados dentro
del diccionario de la base de datos para futuras consultas del SGBD. Cuando un usuario desea acceder a
la base de datos, el SGBD examina el diccionario de datos para comprobar si la solicitud puede ser
realizada y el modo de realizar las transformaciones pertinentes de los datos.

En la página siguiente vemos un ejemplo de una pequeña base de datos. Se puede observar que se han
obtenido dos subesquemas (esquemas externos) a partir del único esquema conceptual formado por las
entidades: VENDEDORES, VENTAS y ARTICULOS. La estructura de cada subesquema obedece a las
necesidades concretas del tipo de usuario que lo va a utilizar.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 25
 II. Tecnología Básica

Por ejemplo:

a) Uno de los subesquemas será utilizado por un programa que totalizará ventas por departamento, por lo
tanto la visión que le interesa tener de la base de datos es una relación de ventas ordenadas por
departamentos.
b) El otro subesquema lo utilizará un programa que listará una relación de empleados por departamento,
por lo que sólo necesita conocer los nombres de todos los empleados y el departamento al que
pertenecen.

El paso de un esquema a otro se realiza utilizando un interfaz o función de traducción. En su modelo, la

ANSI no indica cómo se debe realizar esta función, sólo que debe existir.

7.5 Definición y m anipulación de la base de datos

En la arquitectura propuesta (veáse la figura 7) se distinguen dos partes, la superior para la definición de
datos y la inferior para su manipulación. Se describen distintas funciones, Humanas, representadas por
hexágonos, funciones representadas por rectángulos, interfaces mediante líneas y para cuya
instrumentación no figura ninguna norma, pudiendo ser interfaces físicas, lógicas, micorprogramadas, etc
y metadatos o diccionarios de datos que desempeñan un papel fundamental en esta arquitectura y que se
representan mediante triángulos,

En la fase de definición, una serie de interfaces permiten la creación de los metadatos que se
convierten en el eje de esta arquitectura. La creación de la base de datos comienza con la elaboración del
esquema conceptual realizándola el administrador de la empresa (actualmente es el diseñador, pero ANSI
no lo llamó así).

Ese esquema se procesa utilizando un procesador del esquema conceptual(normalmente una herramienta
CASE, interfaz 1 del dibujo) que lo convierte en los metadatos (interfaz 2 ).

La interfaz 3 permite mostrar los datos del esquema conceptual a los otros dos administradores: el
administrador de la base de datos y el de aplicaciones (el desarrollador). Mediante esta información
construyen los esquemas internos y externos mediante las interfaces 4 y 5 respectivamente, los
procesadores de estos esquemas almacenan la información correspondiente a estos esquemas en los
metadatos (interfaces 6 y 7 ).

En la fase de manipulación el usuario puede realizar operaciones sobre la base de datos usando la
interfaz 8 (normalmente una aplicación) esta petición es transformada por el transformador
externo/conceptual que obtiene el esquema correspondiente ayudándose también de los metadatos
(interfaz 9 ). El resultado lo convierte otro transformador en el esquema interno (interfaz 10 ) usando
también la información de los metadatos (interfaz 11 ). Finalmente del esquema interno se pasa a los
datos usando el último transformador (interfaz 12 ) que también accede a los metadatos (interfaz 13 )
y de ahí se accede a los datos (interfaz 14 ). Para que los datos se devuelvan al usuario en formato
adecuado para él se tiene que hacer el proceso contrario.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 26
 II. Tecnología Básica

Figura 7: Arquitectura Ansi completa

7.6 M odelo de Referencia

La organización ANSI/X3/SPARC sacó a la luz en mayo de 1985 un informe del DBSG (DataBase System
Study Group) en donde se presentaba un modelo de referencia (MR) para la estandarización de los SGBD
que fue publicado en Sigmod Record, VoL 15, No 1; marzo, 1986.

Se entiende por MR, según dicho informe, una estructura conceptual que facilita el trabajo de
estandarización, identificando una serie de componentes y viendo cómo se interrelacionan.

El informe comienza exponiendo un conjunto de objetivos que el MR pretende alcanzar, entre los cuales
queremos destacar el de formación: el MR, al presentar un marco común para la descripción de los SGBD,
facilita su estudio y análisis de forma sistemática.

La organización ANSI/X3/SPARC sacó a la luz en mayo de 1985 un informe del DBSG (DataBase System
Study Group) en donde se presentaba un modelo de referencia (MR) para la estandarización de los SGBD
que fue publicado en Sigmod Record, VoL 15, No 1; marzo, 1986.

Se entiende por MR, según dicho informe, una estructura conceptual que facilita el trabajo de
estandarización, identificando una serie de componentes y viendo cómo se interrelacionan.

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 27
 II. Tecnología Básica

El informe comienza exponiendo un conjunto de objetivos que el MR pretende alcanzar, entre los cuales
queremos destacar el de formación: el MR, al presentar un marco común para la descripción de los SGBD,
facilita su estudio y análisis de forma sistemática.

Además de este objetivo el MR se propone ayudar en la labor de estandarización, para impulsar la

compatibilidad de los distintos componentes de los SGBD, para facilitar la comparación y evaluación de
sistemas de gestión de bases de datos, etc.

Para alcanzar estos objetivos de manera eficaz, el MR debe cumplir unos requisitos, como son: la
adaptación al desarrollo tecnológico (micro SGBD, Bases de Datos Distribuidas (BDD), nuevas
arquitecturas), la unificación de los modelos de datos, la compatibilidad con otro modelos de referencia y
estándares, simplificación de la arquitectura ANSI/SPARC, etc. Como resultado de estos objetivos y
requisitos, el MR proporciona una serie de beneficios, tanto en la portabilidad de las aplicaciones como en
la productividad de la empresas.

El MR, que no es por si mismo un estándar pero sienta las bases para futuras estandarizaciones, se
contempla, en el informe desde tres puntos de vista distintos: el de los componentes que integran un
SGBD, el de las funciones que se deben especificar y el de los datos que se deben describir y utilizar.

El enfoque de los componentes consiste en dividir el SGBD en piezas que, al tener interfaces, podrían ser
adquiridas a distintos suministradores buscando un objetivo de compatibilidad entre los varios módulos de
un SGBD, y de compatibilidad en el mercado (estrategia de sistemas abiertos). Este es el enfoque que
habría de aplicarse en el diseño de un SGBD, mientras que el de funciones es más apropiado cuando se
trata de analizar un SGBD.

El MR está basado en la arquitectura ANSI/SPARC pero dado el elevado número de interfaces de la

primitiva arquitectura y su excesiva complejidad, en el MR se revisa este aspecto con fines de
simplificación, ocupándose del qué, por qué y para qué, pero nunca del cómo, es decir, el objetivo es
describir las interrelaciones del SGBD, pero no indicar nada acerca de su instrumentación. También el MR
intenta contestar algunas de las preguntas acerca de los metadatos y de su naturaleza.

El MR, en el que se distingue el sistema de control de transformación de datos (SCTD), que es el núcleo
(kernef) del SGBD y que provee operadores para la descripción y manipulación de datos. También se
distinguen dos tipos de interfaces:

— el interfaz de lenguaje de datos (LD), que permite a los usuarios y a los procesadores especificar
sus peticiones para la recuperación de los datos por el SGBD.

— el interfaz de lenguaje de datos interno (LD-i), que permite el uso de los servicios de los
procesadores que soportan el funcionamiento de los SGBD, en especial los del SO.

En el entorno del SGBD destacan las herramientas de gestión de datos (HGD), que son componentes de
soporte lógico, como los lenguajes de cuarta generación (L4G), soporte para ayuda a la decisión,
facilidades para realizar el ajuste (tuning), utilidades para el volcado de ficheros, sistemas de diccionario
de datos, etc.

El informe llama la atención sobre la necesidad de que el SGBD facilite a cada tipo de usuario los
instrumentos precisos para que pueda realizar su trabajo.

Se destaca en el informe el conflicto entre las facilidades para los usuarios y la eficiencia de los
procesadores, recomendando para resolverlo un único interfaz eficiente para los procesadores e
instrumentar sobre él una serie de interfaces amistosos destinados a los usuarios finales.

Otra recomendación importante que es preciso destacar es la que aconseja que todos los datos
relacionados con el control centralizado de la BD (reglas de integridad y de seguridad) deben encontrarse
en la metabase y no se deben dejar en manos de los usuarios (sean éstos finales o programadores).

Respecto al núcleo (kernel) del SGBD, está soportado en un modelo de datos (sin especificar ninguno en
concreto). El MR presenta un análisis bidimensional de los datos atendiendo a dos aspectos:

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 28
 II. Tecnología Básica

- dimensión del punto de vista: Constituye la arquitectura a tres niveles que se ha tratado
anteriormente, pero bastante simplificada.
- dimensión intensión/extensión: Presenta cuatro niveles para la descripción de los datos, donde
cada nivel es la extensión (datos) del nivel superior y, al mismo tiempo, la intensión (esquema) del
nivel inferior.

Esta dimensión de intensión/extensión, que en nuestra opinión es posiblemente la parte más original del
informe, considera que cualquier metadato o esquema, es a su vez (en su extensión), un conjunto de
datos que puede ser considerado como una BD, con su correspondiente descripción.
Esta descripción recursiva nos lleva a una jerarquía de niveles de esquemas, el más alto de los cuales ha
de quedar embebido en el equipo lógico. La autodescripción, resultado de extender la arquitectura
ANSI/SPARC, es uno de los conceptos clave del MR.

Termina el informe con unas conclusiones que más bien podrían considerarse como un resumen y con dos
recomendaciones referidas a la estandarización de cada uno de los dos interfaces, LD y LD-i, a fin de
conseguir así una clara separación entre las herramientas de gestión de datos (HGD) y el núcleo del
SGBD, y entre éste y el sistema operativo (SO). Todo ello con objeto de proporcionar al usuario una mayor
libertad e independencia frente a los suministradores.

Asimismo, se realiza en el informe un análisis de las funciones de un SGBD a los cuatro niveles de la
descripción recursiva. Las funciones se considera que pueden ser de tres tipos distintos.
Se describe también un conjunto de herramientas para la administración, así como la interacción con el
SO. Se llama la atención sobre las duplicidades que existen en la actualidad entre los SGBD y los SO,
expresándose el deseo de que los diseñadores del futuro sean más sensibles respecto a este problema y
traten de evitar esta duplicación de funciones que tan perjudicial resulta.

Posteriormente, en junio de 1988, otro subgrupo del DBSSG, el UFTG (User Facility Task Group) ha
propuesto un modelo de referencia para facilidades de usuario (MRFU) que puede considerarse como una
prolongación del modelo de referencia descrito anteriormente, y que fue publicado en Sigmod Record, Vol.
17, Nº 2; junio, 1988. Basándose en modelos gráficos, de psicología cognitiva, tecnología de las bases de
datos, de informática teórica y otros, el UFTG ha elaborado un modelo de referencia en el cual el usuario
es el elemento más importante. En este informe se deja de considerar a los usuarios como
administradores, programadores o usuarios finales y se examinan atendiendo al papel que en un momento
determinado pueden desempeñar, y al interfaz que cada uno de estos papeles requiere.

Para aislar al usuario de detalles concretos sobre las herramientas de gestión de Datos (HGD), el MRFU
propone interponer entre el SGBD y el usuario unas componentes, denominadas Facilidades de Usuario,
que serían las encargadas de transformar una demanda de usuario, para obtener información de la base
de datos en una petición funcional a las HGD, y transformar la salida de éstas en un formato de
presentación al usuario. En el modelo se introducen además dos nuevos interfaces, LDU (Lenguajes de
Datos de Usuario) y LDU-i (Lenguaje interno de Datos de Usuario), que, como sus homólogos LD y LD-i,
son candidatos a una posible estandarización.

LD LD-i

SCTD SO

SCTD : Sistema de Control de Transformación de Datos.

LD: Lenguaje de Datos.
LD-i: Lenguaje de Datos Interno.
HGD: Herramienta de gestión de Datos.
HGD

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 29
 II. Tecnología Básica

Figura 8: Interfaces entre el SGBD y su entorno.

Un SGBD está en realidad formado por varias capas que actúan como interfaces entre el usuario y los
datos. El propio ANSI/X3/SPARC introdujo una mejora de su modelo en 1988 a través de un grupo de
trabajo llamado UFTG (User Facilities Task Group, grupo de trabajo para las facilidades de usuario).

Este modelo toma como objeto principal, al usuario habitual de la base de datos y orienta el
funcionamiento de la base de datos de modo que este usuario ignora el funcionamiento externo.
Desde esta óptica para llegar a los datos hay que pasar una serie de capas que poco a poco van entrando
más en la realidad física de la base de datos. Esa estructura se muestra en la siguiente figura:

Figura 9. Modelo de referencia de las facilidades de usuario

Núcleo
El núcleo de la base de datos es el encargado de traducir las operaciones que le llegan a instrucciones
ejecutables por el sistema operativo en el lenguaje que éste último requiera.
Diccionario de datos
Se trata del elemento que posee todos los metadatos. Gracias a esta capa las solicitudes de los clientes se
traducen en instrucciones que hacen referencia al esquema interno de la base de datos. La capa de
acceso a datos es la que permite comunicar a las aplicaciones de usuario con el diccionario de datos a
través de las herramientas de gestión de datos que incorpore el SGBD.
Facilidades de usuario
Son las herramientas que proporciona el SGBD a los usuarios para permitir un acceso
más sencillo a los datos. Actúan de interfaz entre el usuario y la base de datos, y son el único elemento
que maneja el usuario

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 30
 II. Tecnología Básica

8 BIBLIOGRAFÍA

- Bases de datos, Modelos, lenguajes, diseño. Johnson. Oxford 2000

- Diseño de bases de datos relacionales. Adoración de Miguel, Mario Piattini, Esperanza Marcos. Ra-ma
1999
- Fundamentos y modelos de bases de datos. Adoración de Miguel y Mario Piattini. Ra-ma 1997
- http://www.sigmod.org/sigmod/record/issues/0403/E.JimAndrew-standard.pdf

057. Los Sistemas de Gestión de Bases de datos SGBD. El modelo de referencia ANSI. 31