Universidad Nacional Autonoma de Honduras

Facultad de Ciencias Economicas

Departamento de Informática
Material para la clase de Base de Datos I (Introducción)
Lic. Eduardo Santos

1
1. GESTION DE LOS DATOS

A finales de los años sesenta y principios de los setenta los sistemas informáticos comerciales
pasaron del procesamiento de los datos al procesamiento de la información. Este cambio reflejó
el hecho de que la información es algo más que simples registros relacionados con el negocio.
Poco a poco se empezó a considerar el valor de la información y el enorme potencial que los
sistemas informáticos suponían para organizar y administrar este recurso, que acababa de ser
reconocido como tal. A finales de los años sesenta, esto se tradujo en la instalación de muchos
sistemas de información para la gestión. Estos sistemas utilizarían los datos ya existentes para
resolver muchas y variadas cuestiones de gestión o administración.
Es necesario por tanto, establecer una distinción entre datos e información.
Los datos son considerados como hechos aislados y habitualmente se encuentran en los archivos
del sistema. Por otra parte, el procesamiento de los datos da lugar a la información.
En la actualidad se considera que la información es uno de los recursos más importantes
con que cuenta la empresa debido a la influencia que tiene en la planificación y la toma de
decisiones en las organizaciones.

1.1 Evolución

Al principio los datos estaban integrados en los programas, pero evidentemente ésta no era la
mejor forma de almacenarlos.
La aparición de los ficheros cambia radicalmente la situación anterior y da lugar a que
los datos aparezcan como una colección homogénea. Esto es así porque los ficheros aparecen
como un conjunto de elementos estructurados, en los que cada elemento contiene el mismo tipo
de información y la almacena en un determinado soporte informático. La arquitectura de los
ficheros presenta dos tipos de estructuras la estructura lógica, que representa el punto de vista
del usuario, y la estructura física de los datos, que se corresponde con su almacenamiento en el
soporte físico.
Las aplicaciones construidas con los diferentes lenguajes de programación permitirán el
acceso y actualización de los datos de los ficheros, dando lugar así a verdaderos programas de
gestión.
La diferenciación entre las estructuras lógica y física alcanzada por los ficheros no
consigue evitar la dependencia casi total de los datos respecto a los programas y viceversa, y de
ambos respecto a la máquina. Debido a esto, a este tipo de sistemas se les considera como
orientados hacia los procesos, y son poco adecuados para la gestión empresarial y la toma de
decisiones.
Con objeto de evitar la dependencia entre los datos y las aplicaciones, aparecen en la
década de los sesenta las primeras bases de datos. Estos sistemas dejan de estar orientados al
proceso y se orientan hacia los datos, por lo cual se dice que las bases de datos son sistemas
orientados a los datos. En estos sistemas se diferencia claramente entre la estructura lógica de
los datos y su estructura física, siendo necesario un proceso de transformación de una en otra.

1.2 Sistemas orientados a los procesos. Los ficheros (Archivos Planos)

Los ficheros dan lugar a los primeros sistemas de información. En ellos los datos se organizan
de tal manera que si dos o más aplicaciones tienen una parte de sus datos en común, lo normal
es que dichos datos se encuentren repetidos en tantos ficheros como aplicaciones haya, es decir,
2
existe un fichero por aplicación. Además del mal uso que se hace de los sistemas informáticos
por la duplicidad de almacenamiento y gasto de recursos del sistema nos encontramos con el
problema de las inconsistencias que se producen cuando se almacenan los cambios en los datos
de alguno de los ficheros sin hacerlo en los demás.
Estos sistemas se llamaron sistemas de procesamiento de datos debido a que
ejecutaban las funciones habituales de tratamiento de los registros. Los programadores y los
analistas que diseñaron estos sistemas se dejaron influir durante su programación por la
inclinación natural de imitar los procedimientos manuales existentes. Así, los ficheros en el
ordenador se correspondían con los ficheros de papel y los registros en los ficheros del
ordenador contenían la información que podía almacenar una carpeta individual de un archivo
en un sistema manual.
Inicialmente el tratamiento de los ficheros era únicamente secuencial. Esto suponía que
para leer o procesar un determinado registro previamente había que leer todos los registros que
le precedían en el archivo (ficheros de organización secuencial). En esa época la mayoría de los
archivos se almacenaban en cinta magnética, ya que el almacenamiento en disco era todavía
relativamente caro. En general, estos ficheros se procesaban en lotes, al final de la jornada
laboral, después del cierre del negocio.
Los ficheros eran utilizados para varias aplicaciones diferentes. Por lo general, la
primera operación debía de ser la ordenación de los registros con respecto a algún campo. A
continuación se procedía al tratamiento de los datos, que en la mayoría de las ocasiones pasaba
por comparaciones con los datos de otro u otros ficheros, para proceder a modificaciones,
cálculos, así como diferentes fusiones con otros datos para dar lugar a la información impresa.
Todas estas operaciones consumían mucho tiempo y recursos.
Además de los problemas mencionados, la organización secuencial impedía el borrado o
la intersección de nuevos registros. Operaciones que sólo se podían realizar volcando los datos
del fichero en cuestión en otro en el que se añadirían los nuevos registros y no se considerarían
aquellos que se vayan a eliminar.
No obstante sus limitaciones, estos sistemas orientados a archivos puramente
secuenciales fueron muy utilizados para producir pagos, facturas y otros informes una o dos
veces al mes. Sin embargo, para ejecutar muchas tareas rutinarias en los negocios era necesario
el acceso directo a los datos. Este tipo de organización permite tener acceso y procesar
directamente un registro dado sin necesidad de ordenar primero el archivo o leer los registros en
secuencia (ficheros de organización directa). Esto resolvía muchos de los problemas anteriores
y permitía el tratamiento on-line de los datos.
Estos ficheros utilizan una clave formada por uno o más campos de datos para
identificar precisamente qué registro se recuperará. Los archivos de acceso directo permiten la
recuperación de los registros aleatoriamente, por lo que el registro deseado en un archivo de
acceso directo puede ser recuperado inmediatamente.
Además de los ficheros directos, también los ficheros de organización secuencial
indexada fueron muy utilizados en los años sesenta. Este tipo de archivos consta de dos partes,
en muchos casos son dos ficheros diferenciados, en la primera se guardan los datos de una
determinada forma, mientras que en la segunda se almacena un índice que permite acceder de
forma directa a los datos de la primera parte.
Tanto los ficheros directos, como los indexados fueron muy utilizados en las
aplicaciones comerciales. No obstante, estos ficheros no proporcionaron una solución completa,
ya que seguían existiendo algunas deficiencias como: redundancia de datos, poco control sobre
los datos, problemas en la manipulación de datos y necesidad de grandes conocimientos de
programación. Para dar solución a estos problemas fue necesario introducir los sistemas de
gestión de bases de datos.
3
1.3 Sistemas orientados a los datos. Bases de datos

A fin de conseguir una mejor y más consistente gestión de los datos aparece un nuevo sistema
en el que los datos se integran en un depósito común que evita duplicaciones y redundancias y
da lugar a una mejor utilización de los recursos informáticos. Estos son los sistemas de bases de
datos. Estos sistemas son orientados hacia los datos de tal manera que éstos se encuentran
organizados para dar una mejor respuesta a las necesidades de información de la
correspondiente organización.
Una base de datos es una colección de datos interrelacionados que pueden ser
procesados por uno o más sistemas de aplicación, Un sistema de base de datos está formado
por una base de datos, por un software de propósito general, llamado sistema de gestión de
bases de datos (en adelante SGBD), que manipula la base de datos, así como por el hardware y
el personal apropiados.
Un sistema de base de datos, adecuadamente diseñado, integra los datos comunes de
varias unidades funcionales de la compañía y facilita su manipulación. Además de simplificar la
inserción, la eliminación y la modificación cotidianas de los registros, los sistemas de base de
datos facilitan la identificación y la cuantificación de las relaciones derivadas entre los
elementos de los datos, la recopilación de la información en resúmenes estadísticos, la
inferencia sobre las posibles tendencias del negocio y otras operaciones. Mediante tales
facilidades, el sistema de base de datos transforma los datos puros en información.

Concepto de Base de Datos

En primera instancia una BD aparece como una colección de datos interrelacionados,
almacenados en un soporte físico de gran capacidad al que pueden acceder muchos usuarios.

2 MODELOS DE BASES DE DATOS

En la actualidad se llevan varias décadas de largo esfuerzo por desarrollar sistemas de gestión
de bases de datos cada vez más potentes. Este proceso ha sido testigo del desarrollo evolutivo
de los sistemas basados en tres modelos de datos fundamentales, y que no son más que métodos
conceptuales para estructurar los datos. Estos tres modelos de datos son: el jerárquico, en red y
el relacional.

2.1 El modelo jerárquico

Este modelo surge a principios de los sesenta y es soportado por algunos SGBD. En este
modelo el esquema es una estructura arborescente compuesta de nodos, que representan
entidades, enlazados por líneas que representan las interrelaciones entre dichas entidades.
Para ilustrar este modelo, en el siguiente ejemplo se tienen las facturas que a su vez
contienen las líneas de factura. Cada cliente tiene varias facturas y cada factura tiene varias
líneas. Cada línea registra la venta de un producto único. La Figura 4.16 muestra algunos
ejemplos.

4
 CLIENTE

FACTURA 1 FACTURA 2 FACTURA 3

LINEA 1 LINEA 2 LINEA N

Figura 4.16

Así, se puede construir una jerarquía que muestre las interrelaciones entre los clientes,
las facturas y las líneas de factura. Se considera que un cliente es el “propietario” de las
facturas, las que a su vez son “propietarias” de las líneas de factura. En un sistema jerárquico de
base de datos, estos tres archivos se conectan entre sí mediante punteros físicos o campos de
datos añadidos a los registros individuales. Un puntero (apuntador) es una dirección física que
identifica dónde puede encontrarse un registro sobre el disco. Cada registro de cliente
contendría un apuntador al primer registro de factura correspondiente a ese registro de cliente.
Los registros de factura contendrían a la vez punteros a otros registros de factura y a los
registros de línea de factura. De esta manera., el sistema sería capaz de recuperar fácilmente
todas las facturas y las líneas de factura que se aplican al cliente determinado.
Cada elemento puede tener varios elementos que le siguen (hijos), pero sólo puede tener
uno que le precede (padre). Hay un único elemento al que no le precede ningún otro elemento:
la raíz de la jerarquía. Los elementos de una jerarquía pueden ser de uno de dos tipos:

Rama: cuando tiene varios elementos que le siguen (hijos)

Hoja: cuando es un elemento terminal, sin hijos.

Una estructura jerárquica tendrá varios niveles. Al número de niveles se le llama grado
de la jerarquía. Cada estructura jerárquica en el SGBD va a ser una parte de una base de datos
distinta.
Para representar una base de datos de forma completa pueden ser necesarias varias jerarquías.

Sus ventajas son las siguientes:

• Estructura simple. La jerarquía de la base de datos se asemeja al diagrama de

organización de una empresa o a un árbol familiar.
• Organización padre/hijo. Representa de forma excelente las relaciones
padre/hijo.

5
 • Rendimiento. El almacenamiento de las relaciones padre/hijo como punteros
físicos desde un registro de datos a otro hace que el movimiento a través de la BD
sea rápido.

Ejemplo de Modelo Jerarquico:

Shiver North Bronx

Lowery Maple Queens ………

Hodges Sidehill Brooklyn

………

556 100 000 647 105 366

900 55
647 105 366 801 10 533

2.2 El modelo en red

Surge, al igual que el modelo jerárquico, en los años sesenta. El modelo CODASYL es
un caso particular de modelo de red, donde se introduce un conjunto de restricciones que
facilitan su instrumentación. Es un modelo que cubre las deficiencias planteadas por el
jerárquico cuando la estructura de datos es más compleja.
Pronto se comprobó que el modelo jerárquico tenía algunas limitaciones
importantes, ya que no todas las interrelaciones podrían expresarse fácilmente en una
estructura jerárquica. Por ejemplo, observando el caso de la Figura 4.17, es obvio el
interés no solamente por la relación entre los clientes y las facturas, sino que también
interesa la relación entre las facturas y los productos.
Sin embargo, este diagrama no es una jerarquía. En una jerarquía, un hijo puede
tener solamente un padre. No obstante, en la Figura 4.17 cada línea de detalle de una
factura (línea X) tiene dos padres: factura y artículo. A causa de la necesidad obvia de
manipular tales interrelaciones, a finales de los años sesenta se desarrollaron los sistemas
de base de datos en red. Al igual que los sistemas, de base de datos en red emplearon
punteros físicos para enlazar entre sí los registros de diferentes archivos.
Las ventajas de este modelo son:

• Flexibilidad. Las múltiples relaciones padre/hijo permiten a una BD en red

representar datos que no tengan estructura jerárquica sencilla.
• Normalización. El estándar CODASYL reforzó la popularidad del modelo
de red, y muchos vendedores de mini computadoras implementaron bases de
datos en red.
• Rendimiento. A pesar de su superior complejidad, el rendimiento de estas
BD alcanzó al de las BD jerárquicas.

6
 El SGBD jerárquico dominante es el IMS de IBM, desarrollado a
mediados de los sesenta. Entre mediados de los sesenta y principios de los setenta se
desarrollaron y se comercializaron exitosamente varios SGBD en redes y este modelo de
datos se normalizó, eventualmente, como el modelo CODASYL.

CLIENTE 1 CLIENTE ARTICULO 1 ARTICULO 1

N

FACTURA FACTURA N
1

LINEA 1 LINEA N LINEA 1 LINEA N

Figura 4.17

2.3 El modelo relacional

La utilización de punteros físicos suponía ventajas y desventajas para los sistemas de bases de
datos jerárquicos y en red. La ventaja estaba en que los punteros permitían la recuperación
rápida de los datos que tuvieran interrelaciones predeterminadas. La desventaja estaba en el
hecho de que estas interrelaciones tenían que definirse antes de que el sistema fuera puesto en
explotación. Era difícil, si no imposible, recuperar datos basados en otras interrelaciones. En la
medida en que los usuarios se familiarizaron con los sistemas de base de datos y con su potencia
para manipular los datos, rápidamente encontraron estas limitaciones inaceptables.
En 1970, E.F. Codd publicó un artículo revolucionario (Codd, 1970) que cambió la
filosofía de las bases de datos. Codd argumentó que los datos deberían relacionarse mediante
interrelaciones naturales, lógicas, inherentes a los datos, y no mediante punteros físicos. Es
decir. debía, de existir la posibilidad de combinar los datos de fuentes diferentes, siempre que la
información lógica necesaria para efectuar dicha combinación estuviera presente en los datos.
Esto abrió una nueva perspectiva para los sistemas de gestión de información, ya que las
consultas a las bases de datos no necesitarían, en adelante, limitarse a las interrelaciones
indicadas por los punteros físicos.
En su artículo, Codd propuso un modelo simple de datos en el que todos ellos se
representarían en tablas constituidas por filas y columnas. A estas tablas se les dio el nombre
matemático de relaciones, y por eso el modelo se denominó modelo relacional. Codd también
propuso dos lenguajes para manipular los datos en las tablas: el álgebra relacional y el cálculo

7
 relacional. Ambos lenguajes soportan la manipulación de los datos sobre la base de operadores
lógicos en lugar de los punteros físicos utilizados en los modelos jerárquico y en red.
Al manipular los datos sobre una base conceptual en vez de una base física, Codd
introdujo otra innovación revolucionaria. En los sistemas de base de datos relacionales los
archivos completos de datos se pueden procesar con instrucciones sencillas. Sin embargo, los
sistemas tradicionales requieren que los datos se procesen de registro en registro. El enfoque de
Codd mejoró enormemente la eficiencia conceptual de la programación de la base de datos.
La manipulación lógica de los datos también hace factible la creación de lenguajes de
interrogración más accesibles al usuario no especialista en computación. Aunque es bastante
difícil crear un lenguaje que pueda ser utilizado por todas las personas sin considerar su
experiencia previa en computación, los lenguajes relacionales de consulta hacen posible el
acceso a las bases de datos para un grupo de usuarios cada vez mayor.
La publicación de los artículos de Codd, a principios de los años setenta, provocó una
conmoción en la actividad de las comunidades de desarrollo de sistemas de investigación y de
sistemas comerciales, en la medida en que trabajaban para producir un sistema de gestión de
bases de datos relacional. El resultado fue la aparición de sistemas relacionales durante la última
mitad de los setenta que soportaban lenguajes como el Structured Query Language (SQL), el
Query Language (QUEL) y el Query-by-Example (QBE). A medida que los ordenadores
personales se hicieron populares durante los años ochenta, los sistemas relacionales para ellos
también estuvieron disponibles. En 1986, el SQL se adoptó como la norma ANSI para los
lenguajes relacionales de bases de datos. Esta norma se actualizó en 1989 y en 1992.
Todos estos desarrollos hicieron avanzar enormemente los sistemas de gestión de bases
de datos y aumentaron la disponibilidad de información en las bases de datos colectivas. El
enfoque relacional ha resultado bastante ventajoso.
Actualmente, los sistemas relacionales son un estándar en el mercado, especialmente en
operaciones comerciales. Naturalmente, tanto los sistemas orientados a archivos, como también
los sistemas de base de datos jerárquicos y en redes, son todavía abundantes y, para ciertas
aplicaciones constituyen la solución más eficiente en función de los costos. Sin embargo,
durante algún tiempo, la tendencia clara de las compañías ha sido migrar a los sistemas
relacionales siempre que fuera posible.

Los objetivos del modelo relacional son:

• Independencia física/lógica.
• Eliminación de redundancias.
• Flexibilidad.
• Uniformidad.
• Sencillez.
• Sólido fundamento teórico.

Los problemas más destacables son:

• Dificultades de instrumentación inicialmente.

• Escaso rendimiento en sus primeras versiones.
• Poca capacidad semántica.

Para ilustrar el modelo relacional se inserta el siguiente ejemplo.

8
 CLIENTE
BALANCE
ID-CLIENTE CLIENTE DIRECCION PROVINCIA INICIAL
12500 Hnos. López Marina,41, Vigo Pontevedra 75351
12501 Martín Ayala,14 Toledo 57819
12505 Ramos Mayor,6 Segovia 94333
12510 Sánchez Santiago La Coruña 67070
*** *** *** *** ***

FACTURA
N- FACTURA FECHA ID-CLIENTE ID-REP
1012 02/06 12500 39
1015 03/06 12510 37
1020 12/06 12500 14
*** *** *** ***

LINEA DE FACTURA
N-FACTURA N-LINEA ID-PRODUCTO CANTIDAD PRECIO TOTAL
1012 01 1035 100 4500
1012 02 2241 200 5000
1012 03 2518 300 4500
1015 01 1035 150 7650
1015 02 2518 200 9000
1020 01 2241 100 2500
1020 02 2518 150 2250
*** *** *** *** ***

Figura 4.18. Modelo relacional.

Las líneas terminadas en flecha muestran las relaciones entre las diferentes tablas, debidas a la
existencia de campos comunes en las tablas.

9
3. INSTANCIAS Y ESQUEMAS

Las bases de datos cambian a lo largo del tiempo según se añade y se suprime información. La
colección de información almacenada en la base de datos, en un determinado momento en el tiempo, se
llama una instancia de la base de datos. El diseño global de la base de datos se llama esquema de la
base de datos. Los esquemas se cambian muy raras veces, o nunca.
Aquí resulta útil una analogía con los conceptos de tipos de datos, variables y valores en los
lenguajes de programación. Volviendo a la definición del tipo de registro cliente de la Sección 1.2,
obsérvese que al declarar el tipo cliente no hemos declarado ninguna variable. Para declarar tales
variables en un lenguaje como Pascal, escribimos:

Var cliente 1: cliente;

La variable cliente1 corresponde ahora a un área de almacenamiento que contiene un registro de tipo
cliente.
El concepto de esquema de base de datos corresponde a la noción de definición de tipo en el
lenguaje de programación. Una variable de un tipo dado tiene un valor determinado en un instante de
tiempo dado.
Así, el concepto del valor de una variable en los lenguajes de programación corresponde al concepto de
una instancia de un esquema de la base de datos.
Los sistemas de bases de datos tienen varios esquemas, divididos de acuerdo con los niveles de
abstracción tratados en la Sección 1.2. En el nivel más bajo está el esquema físico; en el nivel
intermedio, el esquema conceptual; en el nivel más alto, un subesquema. En general, los sistemas de
bases de datos soportan un esquema físico, un esquema conceptual y varios subesquemas.

3.1 INDEPENDENCIA DE DATOS

En la Sección 1.2. definimos tres niveles de abstracción en los que puede verse la base de datos. La
capacidad de modificar una definición de un esquema en un nivel sin afectar la definición de un
esquema en un nivel superior siguiente se llama independencia de datos. Hay dos niveles de
independencia de datos:
• Independencia física de datos es la capacidad de modificar el esquema físico sin provocar
que se vuelvan a escribir los programas de aplicación. En algunas ocasiones son necesaritas
las modificaciones en el nivel físico para mejorar el funcionamiento.

• Independencia lógica de datos es la capacidad de modificar el esquema conceptual sin

provocar que se vuelvan a escribir los programas de aplicación. Las modificaciones en el
nivel conceptual son necesarias siempre que se altera la estructura lógica de la base de datos
(por ejemplo, el añadir cuentas de mercado de valores en un sistema bancario).

La independencia lógica de datos es más dificil de lograr que la independencia física de datos,
ya que los programas de aplicación son fuertemente dependientes de la estructura lógica de los
datos a los que acceden.
El concepto de independencia de datos es similar en muchos aspectos al concepto de tipos
abstractos de datos en los lenguajes de programación modernos. Ambos ocultan detalles de
implementación a los usuarios. Esto permite a los usuarios que se concentren en la estructura
general en vez de en los detalles de implementación de bajo nivel.

10
3.2 GESTOR DE BASE DE DATOS

Generalmente, las bases de datos requieren una gran cantidad de espacio de almacenamiento. Las bases
de datos de las empresas comúnmente se miden en términos de gigabytes o, para las bases de datos más
grandes, terabytes de datos. Un gigabyte es 1000 megabytes (un billón de bytes), y un terabyte es un
millón de megabytes (un trillón de bytes). Puesto que la memoria principal de los computadores no
puede almacenar esta información, se almacena en discos. Los datos se transfieren entre el
almacenamiento en disco y la memoria principal según se necesiten. Ya que el movimiento de los datos
y del disco es lento comparado con la velocidad de la unidad central de procesamiento, es imperativo
que el sistema de la base de datos estructure los datos de forma que minimice la necesidad de mover los
datos entre el disco y la memoria principal.
El objetivo de un sistema de bases de datos es simplificar y facilitar el acceso a los datos. Las
vistas de alto nivel ayudan a lograrlo. No se debería cargar innecesariamente a los usuarios del sistema
con los detalles físicos de la implementación del sistema. Sin embargo, un factor importante para la
satisfacción o insatisfacción del usuario con un sistema de bases de datos es su funcionamiento. Si el
tiempo de respuesta para una solicitud es demasiado largo, el valor del sistema se reduce. El
funcionamiento de un sistema depende de la eficiencia de las estructuras de datos usadas para
representar los datos en la base de datos y de la capacidad de eficiencia de operar sobre esas estructuras
de datos que el sistema tiene. Como es el caso de muchos otros aspectos de sistemas informáticos, se
debe llegar a un compromiso no sólo entre espacio y tiempo sino también entre la eficiencia de un tipo
de operación y la de otro.
Un gestor de base de datos es un módulo de programa que proporciona el interfaz entre los
datos de bajo nivel almacenados en la base de datos y los programas de aplicación y consultas hechos
al sistema. El gestor de base de datos es responsable de las siguientes tareas:

• Interacción con el gestor de archivos. Los datos sin procesar se almacenan en el disco
usando el sistema de archivos que normalmente es proporcionado por un sistema operativo
convencional.
El gestor de base de datos traduce las distintas sentencias DML a comandos del sistema de
archivos de bajo nivel. Así, el gestor de base de datos es responsable del verdadero
almacenamiento, recuperación y actualización de los datos en la base de datos.
• Implantación de la integridad. Los valores de los datos que se almacenan en la base de
datos deben satisfacer ciertos tipos de restricciones de consistencia. Por ejemplo, el número
de horas que un empleado puede trabajar en una semana no puede exceder un límite
específico (digamos 80 horas). El administrador de la base de datos debe especificar
explícitamente estas restricciones (ver Sección 1.9). El gestor de la base de datos entonces
puede determinar si las actualizaciones a la base de datos dan como resultado la violación de
la restricción; si así es, se debe tomar la acción apropiada.
• Implantación de la seguridad. Como se discutió anteriormente, no todos los usuarios de la
base de datos necesitan tener acceso a todo su contenido. Es trabajo del gestor de la base de
datos hacer que se cumplan estos requisitos de seguridad.
• Copia de seguridad y recuperación. Un sistema informático, como cualquier otro
dispositivo mecánico o eléctrico, está sujeto a fallos. Las causas de los fallos incluyen rotura
de disco, problemas del suministro de energía y errores software. En cada uno de estos
casos, se pierde la información referente a la base de datos. Es responsabilidad del gestor de
la base de datos detectar tales fallos y restaurar la base de datos al estado que existía antes
de ocurrir el fallo. Esto se lleva a cabo normalmente a través de la iniciación de varios
procedimientos de copias de seguridad y recuperación.

11
 • Control de concurrencia. Cuando varios usuarios actualizan la base de datos
concurrentemente, es posible que no se conserve la consistencia de los datos. Controlar la
interacción entre los usuarios concurrentes es otra responsabilidad del gestor de la base de
datos.

Los sistemas de bases de datos diseñados para utilizarse en computadores personales pequeños pueden
no tener todas las características apuntadas arriba. Por ejemplo, muchos sistemas pequeños imponen la
restricción de que sólo se permita acceder a la base de datos a un usuario en cada momento. Otros dejan
las tareas de copia de seguridad, recuperación e implantación de la seguridad al usuario. Esto permite
un gestor de datos más pequeño, con menos requisitos para los recursos físicos, especialmente memoria
principal. Aunque este enfoque de bajo coste y bajas características es suficiente para bases de datos
personales pequeñas, no es adecuado para cumplir las necesidades de una empresa de media a gran
escala.

3.3 ADMINISTRADOR DE BASE DE DATOS

Una de las razones principales para tener sistemas de gestión de bases de datos es tener control central
de los datos y de los programas que acceden a esos datos. La persona que tiene dicho control central
sobre el sistema se llama administrador de la base de datos (database administrator (DBA). Las
funciones del administrador de base de datos incluyen:

• Definición de esquema. El esquema original de la base de datos se crea escríbiendo un

conjunto de definiciones que son traducidas por el compilador de DDL a un conjunto de
tablas que son almacenadas permanentemente en el diccionario de datos.
• Definición de la estructura de almacenamiento y del método de acceso. Estructuras de
almacenamiento y métodos de acceso adecuados se crean escribiendo un conjunto de
definiciones que son traducidas por el compilador del lenguaje de almacenamiento y
definición de datos.
• Modificación del esquema y de la organización física. Las modificaciones, tanto al
esquema de la base de datos como a la descripción de la organización física de
almacenamiento, aunque relativamente poco comunes, se logran escribiendo un conjunto de
definiciones que son usadas bien por el compilador de DDL o bien por el compilador del
lenguaje de almacenamiento y definición de datos para generar modificaciones a las tablas
internas apropiadas del sistema (por ejemplo, el diccionario de datos).
• Concesión de autorización para el acceso a los datos. La concesión de diferentes tipos de
autorización permite al administrador de la base de datos regular que partes de la base de
datos van a poder ser accedidas por varios usuarios.
• Especificación de las restricciones de integridad. Las restricciones de integridad se
mantienen en una estructura especial del sistema que consulta el gestor de la base de datos
cada vez que tiene lugar una actualización en el sistema.

12