Como primera introducción
a la asignatura Bases de Datos I, se pretende
efectuar un somero
recorrido por los conceptos e ideas a tratar en ella, dando
una visión superficial de
las técnicas de bases de datos. Se expone, de una
manera informal y no
estructurada, el contexto y los contenidos de la
asignatura.
I1. Introducción intuitiva
La
necesidad de manejar información
Pongamos como ejemplo un
caso sencillo: queremos mantener de forma electrónica una lista con los discos
que hemos comprado a lo largo de estos años. Tenemos un ordenador y un programa
que nos permite almacenar la lista como se presenta a continuación.
La lista es muy sencilla,
y está detallada por autor del volumen, título, año de
publicación, formato en
que lo tenemos disponible en nuestra discoteca (CD
es disco compacto, CS es
cassette, y LP es disco en vinilo), y una
clasificación propia del
estilo de música que contiene.
¿Para qué necesitamos
almacenar los datos de esta manera? A lo largo del
tiempo hemos ido
adquiriendo más y más discos, y nos gusta intercambiar
música con nuestros amigos
(como se hacía antes, de forma inocente y legal,
según lo que se entiende
por legal hoy en día). Es más práctico dar una lista
en papel, o enviarla por
correo electrónico para que éste elija lo que más le
guste, en vez de invitarle
a casa y que él se lleve los discos viéndolos
directamente en el
estante; nuestro amigo también nos proporcionaría su
propia lista para hacer
nosotros lo propio.
Precisamente en este punto,
cuando la cantidad de discos es grande, hacer
dicha lista no es tan
fácil. Podemos pensar que lo normal es comenzar a
confeccionarla un día y
anotar en ella las nuevas adquisiciones a medida que
van llegando. Más tarde,
si alguien nos la pide, podemos fotocopiarla y
proporcionársela.
Sin embargo, es evidente
que la lista no está ordenada bajo ningún criterio,
salvo si nos hemos tomado
la molestia de, cuando creamos la lista, anotar la
información ordenada por
autor, por ejemplo. No obstante, las nuevas
entradas de la lista
estarán desordenadas puesto que las anotamos al final de
esa lista. Además, con la
cantidad de discos que manejamos, es fácil que
tengamos descripciones de
discos repetidas, o mal catalogadas, o con el año
equivocado; ¿qué hacemos?:
¿un borrón, escribir encima, escribirla a lápiz
para poder borrar y
rectificar?
Un día, un amigo nos pide
una lista de los discos que tenemos, pero sabemos
que lo que le gusta es el
guitarreo y el ruido, lo que nosotros catalogamos como rock, duro,
o independiente.
La única posibilidad es
darle la lista y queél mismo se busque lo que le interesa.
Cansados de estas
limitaciones decidimos utilizar el ordenador. Lo hacemos
porque nos permite obtener
listados ordenados por cualquier criterio,
mantener la información
actualizada, y corregir los errores fácilmente.
Figura 1.1. Ejemplo de
bases de datos de discos
Además, esta información
la podemos suministrar de cualquier forma: en papel mediante la salida por
impresora, por correo electrónico, en un fichero
de texto en un dispositivo
de almacenamiento portátil o, en definitiva, en
cualquier formato de
intercambio. Podemos tener copias de seguridad por si
se nos pierde la lista
principal. Además, si queremos dar más datos
descriptivos de nuestros
discos, el ordenador nos da facilidades para hacerlo
sin alterar la información
anterior: sólo la definición de los listados se alterará
para poder imprimir, a
partir de entonces, los nuevos datos.
Herramientas
para manejar la información
Ya hemos dicho que vamos a
utilizar un ordenador y un programa para
almacenar los datos y
manejarlos. La primera opción en la que podemos
pensar es un procesador de
textos o una hoja de cálculo, donde la
información es fácilmente
accesible y modificable. Simplemente se trata de
escribir la lista y
guardarla en el disco duro. No obstante, el programa
diseñado desde un
principio para hacer lo que nosotros pretendemos es un
programa de creación y
manejo de bases de datos, un sistema de gestión
de bases
de datos (SGBD). Una base de datos (BD)1 es un conjunto de
datos estructurados
apropiadamente y relacionados entre sí (como, por
ejemplo, nuestra lista de
discos). Podemos tener tantas bases de datos
almacenadas en nuestro
disco duro como permita la capacidad del disco
duro: la lista de discos,
la agenda de teléfonos y direcciones de nuestros
amigos, etc., son todas
bases de datos diferentes; o podríamos tener
relacionada los discos con
la agenda de tal forma que sepamos en todo momento a quien le prestamos los
discos, con lo que todo sería una única
base de datos.
El SGBD nos facilita un
interfaz para introducir nuestra información desde
teclado o cualquier otro
periférico que lo permita, y procesar después esa
información para obtener
informes de cualquier tipo. Por ejemplo nos puede
interesar tener un listado
ordenado por autor y otro por tipo de música. Otro
informe puede que sólo
tenga la información del autor, título y año de
publicación del disco.
La ventaja estriba en que
la información sólo la hemos introducido una vez, y
es el propio sistema de
gestión de base de datos el que, según nuestras
necesidades, se encarga de
clasificar esa información cada vez que le
pedimos un listado.
Además, si nos hemos equivocado en el año de
publicación de un disco,
simplemente lo modificamos y en los siguientes
listados ya saldrá
corregido. Si quisiéramos borrar un disco, porque se nos
haya perdido o roto,
tampoco es un problema: simplemente, cuando el SGBD
vaya a realizar un nuevo
listado no se encontrará con ese disco entre los
datps que maneja.
Figura 1.2. Ejemplo de
consulta a la base de datos mediante una sentencia
SQL.
Diseño
del almacenamiento de la información
El fundamento de toda BD
se encuentra en el análisis y el diseño. Al SGBD se
le han de proporcionar dos
cosas: los datos y la forma en que los vamos a
almacenar. Es decir, un
disco musical, para nosotros, es un objeto que tiene
como características que
lo diferencian de otro disco conceptos tales como la
información del autor, el
título, el año de publicación, el formato del disco y el
tipo de música que
contiene. Debemos, antes de nada, darle al SGBD estos
conceptos con su
correspondiente tipo de datos: si es un número, si es una
cadena de caracteres, si
es una fecha, etc. Una vez hecho esto, ya podemos
introducir los datos de
nuestros discos. De la misma forma, una vez que se
han introducido los
mismos, podemos realizar consultas sobre los datos
almacenados basándonos en
los objetos definidos.
I1.1. Sistema de Gestión de Base de Datos
Un SGBD es un programa de
ordenador que facilita una serie de
herramientas para manejar
bases de datos y obtener resultados (información)
de ellas. Además de
almacenar la información, se le pueden hacer preguntas
sobre esos datos, obtener
listados impresos, generar pequeños programas de
mantenimiento de la BD, o
ser utilizado como servidor de datos para
programas más complejos
realizados en cualquier lenguaje de programación.
Además, ofrece otras
herramientas más propias de la gestión de BD como
sistemas de permisos para
autorización de accesos, volcados de seguridad,
transferencia de ficheros,
recuperación de información dañada, indización,
etc.
En general, un SGBD es un
software de BD que
• centraliza2 los datos
en un único “lugar” lógico al que acceden
todos los usuarios y
aplicaciones.
• es utilizable por
múltiples usuarios y aplicaciones
concurrentemente.
• ofrece visiones parciales
del conjunto total de información, según
las necesidades de un
usuario en particular.
• posee herramientas para
asegurar:
la independencia de
datos: a varios niveles, permitiendo
la modificación de las
definiciones de datos sin afectar a
las aplicaciones o
esquemas que no utilizan esos datos.
la integridad de
los datos: que los datos sean correctos
en todo momento, de
acuerdo con las especificaciones o
reglas impuestas al
sistema
la seguridad de los
datos: que sólo las personas
autorizadas puedan acceder
a determinados datos y que
sólo puedan efectuar las
operaciones para las que han
sido autorizados.
Hay muchos tipos de SGBD,
pero la mayor parte de los utilizados
comercialmente en la
actualidad son relacionales, es decir, se basan en una
cierta teoría o forma de
representar los datos para implementar sus
herramientas e interfaces,
en este caso el modelo relacional. Entendemos
por representación de
los datos como la forma en que se presentan al usuario
y que permiten ciertas
operaciones para poder manejarlos.
De hecho, en estos SGBD,
la información se presenta en forma de tablas
(“relación” es el término
formal), con columnas para las características de los
objetos o conceptos que
pretende representar la tabla, y filas para cada caso
concreto o instancia de
objeto. Existe un lenguaje considerado como estándar
para manejar esas tablas,
el SQL, que permite crear y modificar tablas, y
consultarlas, introducir
nuevos datos, modificar los ya almacenados, o
borrarlos.
Al decir que un SGBD es
relacional, estamos hablando de que, como mínimo,
sigue todas las reglas y
conceptos propuestos por el modelo relacional. El
modelo relacional se basa
en la teoría de conjuntos y es, por tanto, un modelo
con un fundamento
matemático. Este modelo maneja una estructura de datos,
la relación (concepto
matemático que se representa “físicamente” como una
tabla), y unos
operadores definidos sobre ella.
Estos operadores se
agrupan en lenguajes de especificación y manipulación,
que nos proporcionan una
sintaxis para poder dar ordenes al SGBD. A nivel
teórico se proponen tres
lenguajes equivalentes en cuanto a las cosas que
pueden hacer: el Álgebra
Relacional, el Cálculo Relacional orientado a
Tuplas y el Cálculo
Relacional orientado a Dominios. El álgebra está
basado en el álgebra de
conjuntos, mientras que los dos cálculos se basan en
el cálculo de predicados
de primer orden.
El SQL, que podemos decir
que es el lenguaje “real” utilizado, tiene su origen
formal en los anteriores.
Además, aporta más operadores, necesarios para
manejar eficazmente una BD
relacional.
Como procedimiento de
comprobación de la calidad de nuestros esquemas
de base de datos
relacionales veremos la teoría de la normalización. Ésta
nos dice cuando una tabla
es correcta: no contiene redundancia innecesaria,
teniendo en cuenta las
dependencias que existen entre las columnas de la
tabla, y proporciona los
métodos para corregir las deficiencias detectadas
No debemos olvidar que
para almacenar datos en una BD primero debemos
diseñarla, decir cuáles y
cómo son las tablas (si hablamos exclusivamente de
los sistemas
relacionales). Para tal diseño se suelen utilizar otros modelos de
datos más intuitivos y
expresivos. Uno muy cercano al modelo relacional, el
Entidad-Relación
Extendido3 (EER) se utiliza para definir la BD sobre papel.
Una vez que ya sabemos
cómo representar la información nos queda,
simplemente, crear las
tablas e introducir la información.
Hemos hablado de dos de
los muchos modelos de datos que existen.
Brevemente, un modelo
de datos es un conjunto de reglas y conceptos que
sirve para describir un
conjunto de información. Estos modelos de datos
pueden ser de tipo gráfico
(p.ej. el Entidad-Relación) o no, e incluir más o
menos formas de
representar hechos y objetos de la vida real. Al modelar un
conjunto de datos, un
sistema de información, lo que estamos haciendo es
desechar la información no
útil quedándonos únicamente con la que nos
interesa, y representando lo
más fielmente posible las interrelaciones entre
los datos de ese sistema.
Pero, ¿qué había antes de
las BD y los SGBD, y por qué nacen éstos? Los
comienzos gestión
administrativa ayudada por ordenador fueron fruto del
desarrollo de los
lenguajes de programación normales de aquella época,
como COBOL, FORTRAN,
BASIC, etc., y la información se manejaba
mediante ficheros
convencionales de registros. Los avances en hardware
y software generaron un
incrementó exponencial del volumen de dato
manejado, y el rendimiento
de estos programas bajó al tiempo que los costes
de mantenimiento crecieron
de forma alarmante. Los datos se duplicaban
innecesariamente, no había
suficientes controles de seguridad frente a
accesos no autorizados a
la información, ni controles de calidad de los datos.
Alterar las estructuras de
datos, los ficheros, llevaba aparejado una ingente
cantidad de trabajo para
modificar todos los programas afectados. Como
solución a estos y otros
problemas se desarrollaron las técnicas de Bases
de Datos.
I2. Evolución de las técnicas de procesamiento
electrónico de la información
I2.1. sistemas de información mecanizados
tradicionales.
Veamos ahora, de una forma
muy sucinta, cuales fueron los inicios de los
sistemas de información
mecanizados. Éstos han ido evolucionando hasta el
presente al ritmo de las
innovaciones tecnológicas tanto en hardware como
en software. El hecho de
disponer de una determinada tecnología siempre
conlleva ciertas ventajas
sobre los sistemas anteriores, y una serie de
limitaciones impuestas por
las posibilidades de la técnica de ese momento.
Todo se traduce en una
carrera en la que se solucionan problemas y
carencias para mejorar la
calidad, prestaciones, flexibilidad y seguridad de
nuestro sistema de
información, a la vez que la mayor exigencia y las nuevas
necesidades de los
usuarios plantea nuevos problemas no previstos o no
abordables en un momento
dado.
Los sistemas de
información basados en archivo convencional se apoyan
en las distintas
organizaciones de fichero: secuenciales, directos
(direccionamiento directo,
calculado), indexados, invertidos... Estas
organizaciones llevan
aparejados unos métodos de acceso a los registros
particulares: el acceso
secuencial recorre todos los registros hasta encontrar
el buscado; el indexado puede
acceder en un solo paso al registro si estamos
buscando por un campo
clave. Para el manejo de estos ficheros los sistemas
operativos llevan
integradas rutinas que facilitan las operaciones básicas:
inserción, borrado,
modificación y recuperación.
Para entender mejor el
origen y necesidad de las bases de datos es
interesante analizar las
características del sistema tradicional. La
característica básica de
estos sistemas es que los ficheros se diseñaban para
un programa concreto. Esto
los hace muy eficientes en principio, pero los
problemas aparecen cuando
hay que ampliar o modificar el sistema inicial.
Puesto que la definición
de los datos está dentro de cada programa de
aplicación, cualquier
alteración de la estructura de los ficheros que manejan
nos obliga a recompilar
todos los programas que utilicen esos ficheros, o bien
construir nuevos programas
que utilicen nuevos ficheros con información
replicada o calculada en
base a los antiguos.
La solución más rápida y
fácil suele ser construir nuevos programas y ficheros
con información
redundante, más si se piensa en sistemas grandes donde
cada departamento
representa un conjunto de usuarios con una visión parcial
de la Organización (la que
es necesaria para su propio cometido), y por lo
tanto, con un conocimiento
parcial del sistema global.
Por ejemplo, en una
Universidad, la sección de Personal, la secretaría del
Centro y el Departamento
tienen una visión distinta de los datos almacenados
sobre un empleado docente,
algunos comunes a todos (nombre, dirección,
categoría, ...), pero
otros únicamente útiles para una de ellos. La información
sobre cuenta bancaria,
estado civil o número de hijos es necesaria para
Personal, pero no las
asignaturas impartidas por el profesor o su horario. Esta
distinta perspectiva de la
organización es la que conduce en muchos casos a
desarrollar aplicaciones
separadas con ficheros propios.
En definitiva, todos ellos
manejan información que pertenece a la
organización, pero el
desarrollo de los tratamientos de esos datos se realiza
independientemente de los
otros usuarios, de tal forma que cada aplicación
es un objeto autónomo.
Puestas así las cosas, es
fácil que nos encontremos, en un sistema de
información mecanizado
basado en archivo convencional, con los siguientes
problemas:
• Redundancia de datos.
• Dependencia de los
programas respecto de los datos.
• Insuficientes medidas de
seguridad en tres aspectos:
control de accesos
simultáneos
recuperación de ficheros
control de autorizaciones
Pasamos ahora a describir
cada uno de estos puntos.
I2.2. deficiencias de los sistemas basados en
archivo convencional
Redundancia
de datos.
El desarrollo de las
aplicaciones no termina nunca. Las necesidades de la
organización son
cambiantes y evolucionan con el tiempo. Esto quiere decir
que siempre se están
creando nuevas aplicaciones y modificando las
existentes. En un sistema
de ficheros tradicional, cada programa lleva su
propia definición de datos
y maneja sus propios ficheros. Además, suelen ser
varios los programadores
que las realizan, bien en el mismo período de
tiempo, o porque se van
sustituyendo unos a otros.
El resultado fue,
habitualmente, que muchos ficheros utilizados por diversos
programas almacenaban la
misma información. Y no solo eso, sino que la
mayoría de las veces no
recibían el mismo nombre ni coincidían los tipos de
datos. Por ejemplo, un
campo ciudad (cadena de 20 caracteres de longitud)
en un fichero, se llamaba localidad
en otro y podía tener una longitud mayor
que la primera.
Evidentemente, es la falta
de control sobre los datos que generaba la
empresa lo que llevaba a
estas situaciones. Una persona o equipo que se
dedicara a supervisar
todas las aplicaciones podría intentar mejorar este
problema. En realidad,
estos sistemas no son los adecuados para la tarea por
lo costoso que resultaría
tal control (y así aparecerán las técnicas bases de
datos).
Aunque cada aplicación
gestiona información propia, siempre hay datos
comunes a varias
aplicaciones. Al estar estos datos almacenados en ficheros
independientes se produce
redundancia dentro del sistema de información, lo
que genera situaciones
indeseables:
• inconsistencia: al
tener almacenada la misma información en
varios sitios, es difícil
mantenerlos en el mismo estado de
actualización (que en todo
lugar tenga el mismo valor), pudiendo
producir información
incorrecta.
• laboriosos programas de
actualización: no es lo mismo modificar
el valor de un dato una
sóla vez que tantas veces como se halle
duplicado.
• mayor ocupación de memoria.
Dependencia
de los programas respecto de los datos.
En los sistemas clásicos
la descripción de los ficheros usados por un
programa, con información
sobre formato de los registros, organización y
modo de acceso,
localización del fichero, etc., forma parte del código del
programa.
Esto significa que
cualquier cambio realizado en alguno de estos tres
aspectos obliga a
reescribir y recompilar todos los programas que utilicen el
fichero modificado.
Piénsese, por ejemplo, si se cambiara la organización de
un fichero de secuencial a
indexado, o que se añadiera un campo a un
registro para una
aplicación nueva, hecho éste que, en teoría, no tendría que
afectar a las antiguas.
Podemos decir que los
programas son completamente dependientes de los
datos, lo que provoca:
• poca flexibilidad del
sistema de información frente a futuras
variaciones en los
requerimientos de información.
• alto coste de
mantenimiento del software.
Insuficientes
medidas de seguridad:
• control de accesos
simultáneos
El acceso simultáneo de
dos o más programas a unos mismos datos
puede conducir a errores
en la información almacenada.
Supongamos dos procesos
que deben acceder al mismo dato, que en
ese instante vale 100, y
lo hacen concurrentemente, de tal forma que el
primero suma al valor
leído 200 y el segundo 500, por lo que finalmente
deberíamos obtener un
valor de 800 y almacenarlo.
Supongamos que el primer
proceso llega antes que el segundo. Las
respectivas transacciones
comprenden una operación de lectura del
dato almacenado y la
posterior escritura del dato incrementado (la
transacción está formada
por dos operaciones atómicas).
Cuando el primero ha
terminado de leer (y obtiene el valor 100) y antes
de actualizar el dato
(sumándole 100), el segundo proceso también
efectúa una operación de
lectura recuperando el mismo valor. Debido a
la secuencia de
operaciones en el tiempo, la actualización del proceso
1 se pierde puesto que,
inmediatamente después, el proceso 2 modifica
el mismo dato pero con una
suma errónea. Es como si el proceso 1
nunca se hubiera
ejecutado.
• recuperación de ficheros
En el caso de procesos de
actualización incompletos o erróneos hace
falta devolver los
ficheros a un estado anterior correcto a partir del cual
se puedan repetir, ahora
correctamente, los procesos de actualización
rechazados. Tradicionalmente
se recurre a copias de seguridad de los
ficheros afectados.
• Control de autorizaciones
No todos los usuarios
deben poder acceder a los mismos datos, por
motivos de privacidad de
la información, ni pueden acceder de la
misma forma, por permisos
a la hora de realizar recuperaciones,
actualizaciones, etc. En
los sistemas clásicos, al tener aplicaciones
independientes, el volumen
de información y el número de usuarios de
cada una era reducido,
pudiendo aplicarse estas medidas de seguridad
a nivel humano.
A medida que fueron
creciendo los sistemas se vio la necesidad de que
el software dispusiese de
mecanismos de seguridad adecuados a estos
niveles.
En resumen, las
características de los sistemas basados en archivo
convencional adolecen de
los siguientes problemas al incrementarse las
exigencias y el volumen de
datos:
• Pobre control de los datos: los
datos pueden estar replicados
innecesariamente, llamarse
de distinta forma y tener distintas
definiciones en diferentes
ficheros.
• Capacidades de manipulación
de los datos inadecuadas: las
organizaciones de ficheros
no son adecuadas para cierto tipo de
operaciones que impliquen
acceder a los datos para obtener
información elaborada (o
simplemente, en el mejor de los casos,
que el criterio de
búsqueda no está indexado).
• Excesivo esfuerzo de
programación: en entornos de este tipo, la
programación de nuevas
aplicaciones obligaba a construir de
nuevo las definiciones de
fichero y rutinas de acceso en la
mayoría de los casos.
Podemos decir que esta
situación es la que “obliga” a replantear la forma de
gestionar grandes
volúmenes de datos, buscando principalmente la
independencia de las
aplicaciones respecto de la representación física de los
datos almacenados. Nacen
entonces las técnicas de bases de datos, que
se abordan en el siguiente
tema.
Visión diacrónica de la
evolución de la tecnología de las bases de datos
CONCLUSIONES
Toda organización, sea
pequeña o grande, tiene unas necesidades de
información, bien en la
forma tradicional de datos administrativos, bien en
sistemas avanzados de
tratamiento de información de todo tipo. De todos los
datos que entran y salen
de esa organización, en el formato que sea, unos
son importantes y otros no
tanto.
El objetivo de un analista
es identificar la información importante y
estructurarla de forma que
sea útil para todos los miembros de la
organización. Ese sistema
de información puede ser mecanizado mediante
herramientas informáticas
y servir así a la productividad de la entidad.
En un principio, los sistemas
de información a mecanizar eran sencillos y
reflejaban más o menos
exactamente el flujo administrativo de papel del
exterior hacia la empresa,
dentro de la misma empresa, y de la empresa hacia
el exterior nuevamente.
Para ello se utilizaban los lenguajes de programación
disponibles, más o menos
adecuados para la tarea, que manejaban ficheros
organizados según lo
permitía la tecnología del momento.
Pero pronto nuevas
necesidades y expectativas hicieron que el
mantenimiento y creación
de aplicaciones informáticas, junto con el
incremento masivo de la
cantidad de datos a almacenar y tratar, se convirtiera
en un cuello de botella
debido a problemas de redundancia (e inconsistencia)
de datos, deficientes
medidas de seguridad, baja calidad de la información
almacenada, y pérdidas de
información por diversas causas. La tecnología
del momento no era
adecuada para sistemas de información en constante
evolución y con unos
requerimientos de rendimiento y fiabilidad cada vez más
exigentes.
La aparición de las técnicas
de bases de datos vino a solucionar gran parte
de estos problemas.
