Unidad 1Introduccin a las bases de datos

IntroduccinEn esta unidad se hablar de cuales son los objetivos de los sistemas de gestin de las bases de datos (SGBD) y, a continuacin, daremos una visin general de la arquitectura, el funcionamiento y el entorno de estos sistemas.

ObjetivosEncontraremos las herramientas para adquirir una visin global del mundo de las BD y de los SGBD, as como para alcanzar los siguientes objetivos:

1. Conocer a grandes rasgos la evolucin de los SGBD desde los aos sesenta hasta la actualidad.

2. Distinguir los principales objetivos de los SGBD actuales y contrastarlos con los sistemas de ficheros tradicionales.

3. Saber explicar mediante ejemplos los problemas que intenta resolver el concepto de transaccin.

4. Relacionar la idea de flexibilidad en los cambios con la independencia lgica y fsica de los datos, as como con la arquitectura de tres niveles.

5. Distinguir los principales modelos de BD.

6. Conocer a grandes rasgos el funcionamiento de un SGBD.

7. Saber relacionar los diferentes tipos de lenguajes con los diferentes tipos de usuarios.

1. Concepto y origen de las BD y de los SGBDLas aplicaciones informticas de los aos sesenta acostumbraban a darse totalmente por lotes (batch) y estaban pensadas para una tarea muy especfica relacionada con muy pocas entidades tipo.

Cada aplicacin (una o varias cadenas de programas) utilizaba ficheros de movimientos para actualizar (creando una copia nueva) y/o para consultar uno o dos ficheros maestros o, excepcionalmente, ms de dos. Cada programa trataba como mximo un fichero maestro, que sola estar sobre cinta magntica y, en consecuencia, se trabajaba con acceso secuencial. Cada vez que se le quera aadir una aplicacin que requera el uso de algunos de los datos que ya existan y de otros nuevos, se diseaba un fichero nuevo con todos los datos necesarios (algo que provocaba redundancia) para evitar que los programas tuviesen que leer muchos ficheros.

A medida que se fueron introduciendo las lneas de comunicacin, los terminales y los discos, se fueron escribiendo programas que permitan a varios usuarios consultar los mismos ficheros on-line y de forma simultnea. Ms adelante fue surgiendo la necesidad de hacer las actualizaciones tambin on-line.

A medida que se integraban las aplicaciones, se tuvieron que interrelacionar sus ficheros y fue necesario eliminar la redundancia. El nuevo conjunto de ficheros se deba disear de modo que estuviesen interrelacionados; al mismo tiempo, las informaciones redundantes (como por ejemplo, el nombre y la direccin de los clientes o el nombre y el precio de los productos), que figuraban en los ficheros de ms de una de las aplicaciones, deban estar ahora en un solo lugar.

El acceso on-line y la utilizacin eficiente de las interrelaciones exigan estructuras fsicas que diesen un acceso rpido, como por ejemplo los ndices, las multilistas, las tcnicas de hashing, etc.

Estos conjuntos de ficheros interrelacionados, con estructuras complejas y compartidos por varios procesos de forma simultnea (unos on-line y otros por lotes), recibieron al principio el nombre de Data Banks, y despus, a inicios de los aos setenta, el de Data Bases. Aqu los denominamos bases de datos (BD).

El software de gestin de ficheros era demasiado elemental para dar satisfaccin a todas estas necesidades. Por ejemplo, el tratamiento de las interrelaciones no estaba previsto, no era posible que varios usuarios actualizaran datos simultneamente, etc. La utilizacin de estos conjuntos de ficheros por parte de los programas de aplicacin era excesivamente compleja, de modo que, especialmente durante la segunda mitad de los aos setenta, fue saliendo al mercado software ms sofisticado: los Data Base Management Systems, que aqu denominamos sistemas de gestin de BD (SGBD).

En otras palabras, una base de datos es un conjunto estructurado de datos que representa entidades y sus interrelaciones. La representacin ser nica e integrada, a pesar de que debe permitir utilizaciones varias y simultneas.

Los ficheros tradicionales y las BD Aunque de forma muy simplificada, podramos enumerar las principales diferencias entre los ficheros tradicionales y las BD tal y como se indica a continuacin:1) Entidades tipos: Ficheros: tienen registros de una sola entidad tipo. BD: tienen datos de varias entidades tipo.

2) Interrelaciones: Ficheros: el sistema no interrelaciona ficheros. BD: el sistema tiene previstas herramientas para interrelacionar entidades.

3) Redundancia: Ficheros: se crean ficheros a la medida de cada aplicacin, con todos los datos necesarios aunque algunos sean redundantes respecto de otros ficheros. BD: todas las aplicaciones trabajan con la misma BD y la integracin de los datos es bsica, de modo que se evita la redundancia.

4) Usuarios Ficheros: sirven para un solo usuario o una sola aplicacin. Dan una sola visin del mundo real. BD: es compartida por muchos usuarios de distintos tipos. Ofrece varias visiones del mundo real.

2. Evolucin de los SGBDPara entender mejor qu son los SGBD, haremos un repaso de su evolucin desde los aos sesenta hasta nuestros das.

2.1. Los aos sesenta y setenta: sistemas centralizados

Los primeros SGBD en los aos sesenta todava no se les denominaba as estaban orientados a facilitar la utilizacin de grandes conjuntos de datos en los que las interrelaciones eran complejas. El arquetipo de aplicacin era el Bill of materials o Parts explosion, tpica en las industrias del automvil, en la construccin de naves espaciales y en campos similares. Estos sistemas trabajaban exclusivamente por lotes (batch).Al aparecer los terminales de teclado, conectados al ordenador central medianteuna lnea telefnica, se empiezan a construir grandes aplicaciones on-line transaccionales (OLTP). Los SGBD estaban ntimamente ligados al software de comunicaciones y de gestin de transacciones.Aunque para escribir los programas de aplicacin se utilizaban lenguajes de alto nivel como Cobol o PL/I, se dispona tambin de instrucciones y de subrutinas especializadas para tratar las BD que requeran que el programador conociese muchos detalles del diseo fsico, y que hacan que la programacin fuese muy compleja.Puesto que los programas estaban relacionados con el nivel fsico, se deban modificar continuamente cuando se hacan cambios en el diseo y la organizacin de la BD. La preocupacin bsica era maximizar el rendimiento: el tiempo de respuesta y las transacciones por segundo.

2.2. Los aos ochenta: SGBD relacionalesLos ordenadores minis, en primer lugar, y despus los ordenadores micros, extendieron la informtica a prcticamente todas las empresas e instituciones.Esto exiga que el desarrollo de aplicaciones fuese ms sencillo. Los SGBD de los aos setenta eran demasiado complejos e inflexibles, y slo los poda utilizar un personal muy cualificado.

Todos estos factores hacen que se extienda el uso de los SGBD. La estandarizacin, en el ao 1986, del lenguaje SQL produjo una autntica explosin de los SGBD relacionales.2.3. Los aos noventa: distribucin, C/S y 4GLAl acabar la dcada de los ochenta, los SGBD relacionales ya se utilizaban prcticamente en todas las empresas. A pesar de todo, hasta la mitad de los noventa, cuando se ha necesitado un rendimiento elevado se han seguido utilizando los SGBD prerrelacionales.A finales de los ochenta y principios de los noventa, las empresas se han encontrado con el hecho de que sus departamentos han ido comprando ordenadores departamentales y personales, y han ido haciendo aplicaciones con BD. El resultado ha sido que en el seno de la empresa hay numerosas BD y varios SGBD de diferentes tipos o proveedores. Este fenmeno de multiplicacin de las BD y de los SGBD se ha visto incrementado por la fiebre de las fusiones de empresas.

Esta distribucin ideal se consigue cuando las diferentes BD son soportadas por una misma marca de SGBD, es decir, cuando hay homogeneidad. Sin embargo, esto no es tan sencillo si los SGBD son heterogneos. En la actualidad, gracias principalmente a la estandarizacin del lenguaje SQL, los SGBD de marcas diferentes pueden darse servicio unos a otros y colaborar para dar servicio a un programa de aplicacin. No obstante, en general, en los casos de heterogeneidad no se llega a poder dar en el programa que los utiliza la apariencia de que se trata de una nica BD.

Adems de esta distribucin impuesta, al querer tratar de forma integrada distintas BD preexistentes, tambin se puede hacer una distribucin deseada, diseando una BD distribuida fsicamente, y con ciertas partes replicadas en diferentes sistemas. Las razones bsicas por las que interesa esta distribucin son las siguientes:1) Disponibilidad. La disponibilidad de un sistema con una BD distribuida puede ser ms alta, porque si queda fuera de servicio uno de los sistemas, los de ms seguirn funcionando. Si los datos residentes en el sistema no disponible estn replicados en otro sistema, continuarn estando disponibles. En caso contrario, slo estarn disponibles los datos de los dems sistemas.2) Costo. Una BD distribuida puede reducir el coste. En el caso de un sistema centralizado, todos los equipos usuarios, que pueden estar distribuidos por distintas y lejanas reas geogrficas, estn conectados al sistema central por medio de lneas de comunicacin. El coste total de las comunicaciones se puede reducir haciendo que un usuario tenga ms cerca los datos que utiliza con mayor frecuencia; por ejemplo, en un ordenador de su propia oficina o, incluso, en su ordenador personal.

Por ejemplo, un programa de aplicacin que un usuario ejecuta en su PC (que est conectado a una red) pide ciertos datos de una BD que reside en un equipo UNIX donde, a su vez, se ejecuta el SGBD relacional que la gestiona. El programa de aplicacin es el cliente y el SGBD es el servidor.Un proceso cliente puede pedir servicios a varios servidores. Un servidor puede recibir peticiones de muchos clientes. En general, un proceso A que hace de cliente, pidiendo un servicio a otro proceso B puede hacer tambin de servidor de un servicio que le pida otro proceso C (o incluso el B, que en esta peticin sera el cliente). Incluso el cliente y el servidor pueden residir en un mismo sistema.

La facilidad para disponer de distribucin de datos no es la nica razn, ni siquiera la bsica, del gran xito de los entornos C/S en los aos noventa. Tal vez el motivo fundamental ha sido la flexibilidad para construir y hacer crecer la configuracin informtica global de la empresa, as como de hacer modificaciones en ella, mediante hardware y software muy estndar y barato. El xito de las BD, incluso en sistemas personales, ha llevado a la aparicin de los Fourth Generation Languages (4GL), lenguajes muy fciles y potentes, especializados en el desarrollo de aplicaciones fundamentadas en BD. Proporcionan muchas facilidades en el momento de definir, generalmente de forma visual, dilogos para introducir, modificar y consultar datos en entornos C/S.

2.4. Tendencias actuales

Los tipos de datos que se pueden definir en los SGBD relacionales de los aos ochenta y noventa son muy limitados. La incorporacin de tecnologas multimedia imagen y sonido en los SI hace necesario que los SGBD relacionales acepten atributos de estos tipos.Sin embargo, algunas aplicaciones no tienen suficiente con la incorporacin de tipos especializados en multimedia. Necesitan tipos complejos que el desarrollador pueda definir a medida de la aplicacin. En definitiva, se necesitan tipos abstractos de datos: TAD. Los SGBD ms recientes ya incorporaban esta posibilidad, y abren un amplio mercado de TAD predefinidos o libreras de clases.Esto nos lleva a la orientacin a objetos (OO). El xito de la OO al final de los aos ochenta, en el desarrollo de software bsico, en las aplicaciones de ingeniera industrial y en la construccin de interfaces grficas con los usuarios, ha hecho que durante la dcada de los noventa se extendiese en prcticamente todos los campos de la informtica.En los SI se inicia tambin la adopcin, tmida de momento, de la OO. La utilizacin de lenguajes como C++ o Java requiere que los SGBD relacionales se adapten a ellos con interfaces adecuadas.La rpida adopcin de la web a los SI hace que los SGBD incorporen recursos para ser servidores de pginas web, como por ejemplo la inclusin de SQL en guiones HTML, SQL incorporado en Java, etc. Notad que en el mundo de la web son habituales los datos multimedia y la OO.Durante estos ltimos aos se ha empezado a extender un tipo de aplicacin de las BD denominado Data Warehouse, o almacn de datos, que tambin produce algunos cambios en los SGBD relacionales del mercado.A lo largo de los aos que han trabajado con BD de distintas aplicaciones, las empresas han ido acumulando gran cantidad de datos de todo tipo. Si estos datos se analizan convenientemente pueden dar informacin valiosa*.Por lo tanto, se trata de mantener una gran BD con informacin proveniente de toda clase de aplicaciones de la empresa (e, incluso, de fuera). Los datos de este gran almacn, el Data Warehouse, se obtienen por una replicacin ms o menos elaborada de las que hay en las BD que se utilizan en el trabajo cotidiano de la empresa. Estos almacenes de datos se utilizan exclusivamente para hacer consultas, de forma especial para que lleven a cabo estudios* los analistas financieros, los analistas de mercado, etc.Actualmente, los SGBD se adaptan a este tipo de aplicacin, incorporando, por ejemplo, herramientas como las siguientes:a) La creacin y el mantenimiento de rplicas, con una cierta elaboracin de los datos.b) La consolidacin de datos de orgenes diferentes.c) La creacin de estructuras fsicas que soporten eficientemente el anlisis multidimensional.

3. Objetivos y servicios de los SGBDLos SGBD que actualmente estn en el mercado pretenden satisfacer un conjunto de objetivos directamente deducibles de lo que hemos explicado hasta ahora. A continuacin los comentaremos, pero sin entrar en detalles que ya se vern ms adelante en otras asignaturas.3.1. Consultas no predefinidas y complejasEl objetivo fundamental de los SGBD es permitir que se hagan consultas no predefinidas (ad hoc) y complejas.Consultas que afectan a ms de una entidad tipo Se quiere conocer el nmero de alumnos de ms de veinticinco aos y con nota media superior a siete que estn matriculados actualmente en la asignatura Bases de datos I. De cada alumno matriculado en menos de tres asignaturas, se quiere obtener el nombre, el nmero de matrcula, el nombre de las asignaturas y el nombre de profesores de estas asignaturas.

El usuario debe formular la consulta con un lenguaje sencillo (que se quede, obviamente, en el nivel lgico), que el sistema debe interpretar directamente.Sin embargo, esto no significa que no se puedan escribir programas con consultas incorporadas (por ejemplo, para procesos repetitivos).La solucin estndar para alcanzar este doble objetivo (consultas no predefinidas y complejas) es el lenguaje SQL, que explicaremos en otro mdulo didctico.3.2. Flexibilidad e independenciaLa complejidad de las BD y la necesidad de irlas adaptando a la evolucin del SI hacen que un objetivo bsico de los SGBD sea dar flexibilidad a los cambios.Interesa obtener la mxima independencia posible entre los datos y los procesos usuarios para que se pueda llevar a cabo todo tipo de cambios tecnolgicos y variaciones en la descripcin de la BD, sin que se deban modificar los programas de aplicacin ya escritos ni cambiar la forma de escribir las consultas (o actualizaciones) directas.

En el mundo de los ficheros ya haba independencia fsica en un cierto grado, pero en el mundo de las BD acostumbra a ser mucho mayor.

3.3. Problemas de la redundanciaEn el mundo de los ficheros tradicionales, cada aplicacin utilizaba su fichero.Sin embargo, puesto que se daba mucha coincidencia de datos entre aplicaciones, se produca tambin mucha redundancia entre los ficheros. Ya hemos dicho que uno de los objetivos de los SGBD es facilitar la eliminacin de la redundancia.Seguramente pensis que el problema de la redundancia es el espacio perdido.Antiguamente, cuando el precio del byte de disco era muy elevado, esto era un problema grave, pero actualmente prcticamente nunca lo es. Qu problema hay, entonces? Simplemente, lo que todos hemos sufrido ms de una vez; si tenemos algo apuntado en dos lugares diferentes no pasar demasiado tiempo hasta que las dos anotaciones dejen de ser coherentes, porque habremos modificado la anotacin en uno de los lugares y nos habremos olvidado de hacerlo en el otro.As pues, el verdadero problema es el grave riesgo de inconsistencia o incoherencia de los datos; es decir, la prdida de integridad que las actualizaciones pueden provocar cuando existe redundancia.Por lo tanto, convendra evitar la redundancia. En principio, nos conviene hacer que un dato slo figure una vez en la BD. Sin embargo, esto no siempre ser cierto.Por ejemplo, para representar una interrelacin entre dos entidades, se suele repetir un mismo atributo en las dos, para que una haga referencia a la otra.Otro ejemplo podra ser el disponer de rplicas de los datos por razones de fiabilidad, disponibilidad o costes de comunicaciones.

La duplicacin de datos es el tipo de redundancia ms habitual, pero tambin tenemos redundancia cuando guardamos en la BD datos derivados (o calculados) a partir de otros datos de la misma BD. De este modo podemos responder rpidamente a consultas globales, ya que nos ahorramos la lectura de gran cantidad de registros.En los casos de datos derivados, para que el resultado del clculo se mantenga consistente con los datos elementales, es necesario rehacer el clculo cada vez que stos se modifican. El usuario (ya sea programador o no) puede olvidarse de hacer el nuevo clculo; por ello convendr que el mismo SGBD lo haga automticamente.3.4. Integridad de los datosNos interesar que los SGBD aseguren el mantenimiento de la calidad de los datos en cualquier circunstancia. Acabamos de ver que la redundancia puede provocar prdida de integridad de los datos, pero no es la nica causa posible.Se podra perder la correccin o la consistencia de los datos por muchas otras razones: errores de programas, errores de operacin humana, avera de disco, transacciones incompletas por corte de alimentacin elctrica, etc.En el subapartado anterior hemos visto que podremos decir al SGBD que nos lleve el control de las actualizaciones en el caso de las redundancias, para garantizar la integridad. Del mismo modo, podremos darle otras reglas de integridad o restricciones para que asegure que los programas las cumplen cuando efectan las actualizaciones.

Aparte de las reglas de integridad que el diseador de la BD puede definir y que el SGBD entender y har cumplir, el mismo SGBD tiene reglas de integridad inherentes al modelo de datos que utiliza y que siempre se cumplirn. Son las denominadas reglas de integridad del modelo. Las reglas definibles por parte del usuario son las reglas de integridad del usuario. El concepto de integridad de los datos va ms all de prevenir que los programas usuarios almacenen datos incorrectos. En casos de errores o desastres, tambin podramos perder la integridad de los datos. El SGBD nos debe dar las herramientas para reconstruir o restaurar los datos estropeados.