Mod2 Bases de datos

Introduccin a lasbases de datos

Rafael Camps Par

PID_00171667

FUOC PID_00171667 Introduccin a las bases de datos

Ninguna parte de esta publicacin, incluido el diseo general y la cubierta, puede ser copiada,reproducida, almacenada o transmitida de ninguna forma, ni por ningn medio, sea ste elctrico,qumico, mecnico, ptico, grabacin, fotocopia, o cualquier otro, sin la previa autorizacin escritade los titulares del copyright.

FUOC PID_00171667 Introduccin a las bases de datos

ndice

Introduccin............................................................................................... 5

Objetivos....................................................................................................... 6

1. Concepto y origen de las BD y de los SGBD................................ 7

2. Evolucin de los SGBD..................................................................... 92.1. Los aos sesenta y setenta: sistemas centralizados ..................... 92.2. Los aos ochenta: SGBD relacionales ......................................... 102.3. Los aos noventa: distribucin, C/S y 4GL ................................ 102.4. El nueno milenio ........................................................................ 14

3. Objetivos y servicios de los SGBD.................................................. 153.1. Consultas no predefinidas y complejas ...................................... 153.2. Flexibilidad e independencia ...................................................... 153.3. Problemas de la redundancia ...................................................... 163.4. Integridad de los datos ............................................................... 173.5. Concurrencia de usuarios ........................................................... 193.6. Seguridad ..................................................................................... 21

4. Arquitectura de los SGBD................................................................ 234.1. Esquemas y niveles ..................................................................... 234.2. Independencia de los datos ........................................................ 264.3. Flujo de datos y de control ......................................................... 28

5. Modelos de BD.................................................................................... 31

6. Lenguajes y usuarios......................................................................... 34

7. Administracin de BD...................................................................... 37

Resumen....................................................................................................... 39

Ejercicios de autoevaluacin.................................................................. 41

Solucionario................................................................................................ 42

Glosario........................................................................................................ 43

Bibliografa................................................................................................. 44

FUOC PID_00171667 5 Introduccin a las bases de datos

Introduccin

Empezaremos este mdulo didctico viendo cules son los objetivosdelossistemasdegestindelasbasesdedatos(SGBD) y, a continuacin, daremosuna visin general de la arquitectura, el funcionamiento y el entorno deestos sistemas.


Objetivos

En los materiales didcticos de este mdulo encontraris las herramientas paraadquirir una visin global del mundo de las BD y de los SGBD, as como paraalcanzar los siguientes objetivos:

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

2. Distinguir los principales objetivos de los SGBD actuales y contrastarloscon los sistemas tradicionales.

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

4. Relacionar la idea de flexibilidad en los cambios con la independencialgica 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 tiposde usuarios.


1. Concepto y origen de las BD y de los SGBD

El concepto de base de datos (BD) se puede entender como un conjunto deficheros entre los que se establecen vnculos o interrelaciones. Ahora introdu-ciremos el concepto de BD desde un punto de vista histrico.

Las aplicaciones informticas de los aos sesenta acostumbraban a darse to-talmente por lotes (batch) y estaban pensadas para una tarea muy especficarelacionada con muy pocas entidades tipo.

Cada aplicacin (una o varias cadenas de programas) utilizaba ficheros de mo-vimientos para actualizar (creando una copia nueva) y/o para consultar uno odos ficheros maestros o, excepcionalmente, ms de dos. Cada programa trata-ba como mximo un fichero maestro, que sola estar sobre cinta magntica y,en consecuencia, se trabajaba con acceso secuencial. Cada vez que se le que-ra aadir una aplicacin que requera el uso de algunos de los datos que yaexistan y de otros nuevos, se diseaba un fichero nuevo con todos los datosnecesarios (algo que provocaba redundancia) para evitar que los programastuviesen que leer muchos ficheros.

A medida que se fueron introduciendo las lneas de comunicacin, los ter-minales y los discos, se fueron escribiendo programas que permitan a variosusuarios consultar los mismos ficheros on-line y de forma simultnea. Ms ade-lante fue surgiendo la necesidad de hacer las actualizaciones tambin on-line.

Aplicaciones informticasde los aos sesenta

La emisin de facturas, el con-trol de pedidos pendientes deservir, el mantenimiento del fi-chero de productos o la nmi-na del personal eran algunasde las aplicaciones informti-cas habituales en los aos se-senta.

A medida que se integraban las aplicaciones, se tuvieron que interrelacionarsus ficheros y fue necesario eliminar la redundancia. El nuevo conjunto deficheros se deba disear de modo que estuviesen interrelacionados; al mismotiempo, las informaciones redundantes (como por ejemplo, el nombre y la di-reccin de los clientes o el nombre y el precio de los productos), que figurabanen los ficheros de ms de una de las aplicaciones, deban estar ahora en unsolo lugar.

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

Estos conjuntosdeficherosinterrelacionados, con estructuras complejas ycompartidos por varios procesos de forma simultnea (unos on-line y otros porlotes), recibieron al principio el nombre de Data Banks, y despus, a inicios delos aos setenta, el de Data Bases. Aqu los denominamos basesdedatos(BD).

Integracin deaplicaciones

Por ejemplo, se integra la apli-cacin de facturas, la de pedi-dos pendientes y la gestin delfichero de productos.


El softwaredegestindeficheros era demasiado elemental para dar satisfac-cin a todas estas necesidades. Por ejemplo, el tratamiento de las interrelacio-nes no estaba previsto, no era posible que varios usuarios actualizaran datossimultneamente, etc. La utilizacin de estos conjuntos de ficheros por par-te de los programas de aplicacin era excesivamente compleja, de modo que,especialmente durante la segunda mitad de los aos setenta, fue saliendo almercado software ms sofisticado: los Data Base Management Systems, que aqudenominamos sistemasdegestindeBD(SGBD).

Con todo lo que hemos dicho hasta ahora, podramos definir el trminoBD; una basededatosdeunSI es la representacin integrada de losconjuntos de entidades instancia correspondientes a las diferentes enti-dades tipo del SI y de sus interrelaciones. Esta representacin informti-ca (o conjunto estructurado de datos) debe poder ser utilizada de formacompartida por muchos usuarios de distintos tipos.

En otras palabras, una base de datos es un conjunto estructurado de datosque representa entidades y sus interrelaciones. La representacin ser nica eintegrada, 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 entrelos 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 nece-sarios aunque algunos sean redundantes respecto de otros ficheros.

BD: todas las aplicaciones trabajan con la misma BD y la integracin de los datos esbsica, de modo que se evita la redundancia.

4) Usuarios

Ficheros: sirven para un solo usuario o una sola aplicacin. Dan una sola visin delmundo real.

BD: es compartida por muchos usuarios de distintos tipos. Ofrece varias visiones delmundo real.


2. Evolucin de los SGBD

Para entender mejor qu son los SGBD, haremos un repaso de su evolucindesde los aos sesenta hasta nuestros das.

2.1. Los aos sesenta y setenta: sistemas centralizados

Los SGBD de los aos sesenta y setenta (IMS de IBM, IDS de Bull, DMSde Univac, etc.) eran sistemastotalmentecentralizados, como corres-ponde a los sistemas operativos de aquellos aos, y al hardware para elque estaban hechos: un gran ordenador para toda la empresa y una redde terminales sin inteligencia ni memoria.

Los primerosSGBD en los aos sesenta todava no se les denominaba asestaban orientados a facilitar la utilizacin de grandes conjuntos de datos enlos que las interrelaciones eran complejas. El arquetipo de aplicacin era el Billof materials o Parts explosion, tpica en las industrias del automvil, en la cons-truccin de naves espaciales y en campos similares. Estos sistemas trabajabanexclusivamente por lotes (batch).

Al aparecer los terminales de teclado, conectados al ordenador central median-te una lnea telefnica, se empiezan a construir grandes aplicacioneson-linetransaccionales(OLTP). Los SGBD estaban ntimamente ligados al softwarede comunicaciones y de gestin de transacciones.

Aunque para escribir los programasdeaplicacin se utilizaban lenguajes dealto nivel como Cobol o PL/I, se dispona tambin de instrucciones y de su-brutinas especializadas para tratar las BD que requeran que el programadorconociese muchos detalles del diseo fsico, y que hacan que la programacinfuese muy compleja.

Puesto que los programas estaban relacionados con el nivel fsico, se debanmodificar continuamente cuando se hacan cambios en el diseo y la orga-nizacin de la BD. La preocupacin bsica era maximizar el rendimiento: eltiempo de respuesta y las transacciones por segundo.

El Data Base / DataComunications

IBM denominaba Data Ba-se/Data Comunications (DB/DC) el software de comunica-ciones y de gestin de tran-sacciones y de datos. Las apli-caciones tpicas eran la reser-va/compra de billetes a lascompaas areas y de ferroca-rriles y, un poco ms tarde, lascuentas de clientes en el mun-do bancario.


2.2. Los aos ochenta: SGBD relacionales

Los ordenadoresminis, en primer lugar, y despus los ordenadoresmicros,extendieron la informtica a prcticamente todas las empresas e instituciones.Esto exiga que el desarrollo de aplicaciones fuese ms sencillo. Los SGBD de losaos setenta eran demasiado complejos e inflexibles, y slo los poda utilizarun personal muy cualificado.

La aparicin de los SGBD relacionales1 supone un avance importantepara facilitar la programacin de aplicaciones con BD y para conseguirque los programas sean independientes de los aspectos fsicos de la BD.

Todos estos factores hacen que se extienda el uso de los SGBD. La estandari-zacin, en el ao 1986, del lenguajeSQL produjo una autntica explosin delos SGBD relacionales.

Los ordenadores personales

Durante los aos ochenta aparecen y se extienden muy rpidamente los ordenadorespersonales. Tambin surge software para estos equipos monousuario (por ejemplo, dBasey sus derivados), con los cuales es muy fcil crear y utilizar conjuntos de datos, y que sedenominan personal data bases. Notad que el hecho de denominar SGBD estos primerossistemas para PC es un poco forzado, ya que no aceptaban estructuras complejas ni in-terrelaciones, ni podan ser utilizados en una red que sirviese simultneamente a muchosusuarios de diferentes tipos. Sin embargo, algunos, con el tiempo, se han ido convirtien-do en autnticos SGBD.

2.3. Los aos noventa: distribucin, C/S y 4GL

Al acabar la dcada de los ochenta, los SGBD relacionales ya se utilizaban prc-ticamente en todas las empresas. A pesar de todo, hasta la mitad de los no-venta, cuando se necesit un rendimiento elevado se siguieron utilizando losSGBD prerrelacionales.

A finales de los ochenta y principios de los noventa, las empresas se encontra-ron con el hecho de que sus departamentos fueron comprando ordenadoresdepartamentales y personales, y crearon aplicaciones con BD. El resultado fueque en el seno de la empresa haban numerosas BD y varios SGBD de diferen-tes tipos o proveedores. Este fenmeno de multiplicacindelasBDydelosSGBD se vi incrementado por la fiebre de las fusiones de empresas.

(1)Oracle aparece en el ao 1980.


La necesidad de tener una visin global de la empresa y de interrelacio-nar diferentes aplicaciones que utilizan BD diferentes, junto con la faci-lidad que dan las redes para la intercomunicacin entre ordenadores, haconducido a los SGBD actuales, que permiten que un programa puedatrabajar con diferentes BD como si se tratase de una sola. Es lo que seconoce como basededatosdistribuida.

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


Figura 1.

Adems de esta distribucin impuesta, al querer tratar de forma integradadistintas BD preexistentes, tambin se puede hacer una distribucin desea-da, diseando una BD distribuida fsicamente, y con ciertas partes reprodu-cidas en diferentes sistemas. Las razones bsicas por las que interesa esta dis-tribucin son las siguientes:


1)Disponibilidad. La disponibilidad de un sistema con una BD distribuidapuede ser ms alta, porque si queda fuera de servicio uno de los sistemas, losdems seguirn funcionando. Si los datos residentes en el sistema no disponi-ble estn reproduccin en otro sistema, continuarn estando disponibles. Encaso contrario, slo estarn disponibles los datos de los dems sistemas.

2)Coste. Una BD distribuida puede reducir el coste. En el caso de un siste-ma centralizado, todos los equipos usuarios, que pueden estar distribuidos pordistintas y lejanas reas geogrficas, estn conectados al sistema central pormedio de lneas de comunicacin. El coste total de las comunicaciones se pue-de reducir haciendo que un usuario tenga ms cerca los datos que utiliza conmayor frecuencia; por ejemplo, en un ordenador de su propia oficina o, inclu-so, en su ordenador personal.

La tecnologa que se utiliza habitualmente para distribuir datos es la quese conoce como entorno (o arquitectura) cliente/servidor(C/S). Todoslos SGBD relacionales del mercado han sido adaptados a este entorno.

La idea del C/S es sencilla. Dos procesos diferentes, que se ejecutan enun mismo sistema o en sistemas separados, actan de forma que unotiene el papel de cliente o peticionario de un servicio, y el otro el deservidor o proveedor del servicio.

Por ejemplo, un programa de aplicacin que un usuario ejecuta en su PC (queest conectado a una red) pide ciertos datos de una BD que reside en un equi-po UNIX donde, a su vez, se ejecuta el SGBD relacional que la gestiona. Elprograma de aplicacin es el cliente y el SGBD es el servidor.

Un proceso cliente puede pedir servicios a varios servidores. Un servidor puederecibir peticiones de muchos clientes. En general, un proceso A que hace decliente, pidiendo un servicio a otro proceso B puede hacer tambin de servidorde un servicio que le pida otro proceso C (o incluso el B, que en esta peticinsera el cliente). Incluso el cliente y el servidor pueden residir en un mismosistema.

Figura 2.

Otros servicios

Notad que el servicio que daun servidor de un sistema C/Sno tiene por qu estar relacio-nado con las BD; puede ser unservicio de impresin, de envode un fax, etc., pero aqu nosinteresan los servidores queson SGBD.


La facilidad para disponer de distribucin de datos no es la nica razn, nisiquiera 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 hacercrecer la configuracin informtica global de la empresa, as como de hacermodificaciones en ella, mediante hardware y software muy estndar y barato.

El xito de las BD, incluso en sistemas personales, ha llevado a la aparicinde los FourthGenerationLanguages(4GL), lenguajes muy fciles y potentes,especializados en el desarrollo de aplicaciones fundamentadas en BD. Propor-cionan muchas facilidades en el momento de definir, generalmente de formavisual, dilogos para introducir, modificar y consultar datos en entornos C/S.

2.4. El nueno milenio

Desde que irrumpieron en el mercado los sistemas de gestin de bases de da-tos relacionales, stos han sido los ms utilizados en la industria, posiblemen-te porque se acercaban a usuarios y aplicaciones y se alejaban del hardware.La prueba de ello es, an en la actualidad, que las bases de datos relacionalescontinan siendo las ms utilizadas, tanto con respecto a sistemas de gestinde bases de datos como a las aplicaciones que utilizan los sistemas de infor-macin.

No obstante, en el ltimo milenio, con la aparicin de Internet y los disposi-tivos mviles, la internalizacin y comparticin de la informacin, el panora-ma ha cambiado mucho y las bases de datos relacionales ya no dan solucina todos los problemas planteados, ni tan eficientes como sera de esperar. Pa-ra superar estas limitaciones y dar respuesta a las nuevas necesidades, ltima-mente han aparecido otros modelos de bases de datos y extensiones al modelorelacional, algunos de los cuales an son tendencias.

Ejemplo

C/S, SQL y 4GL son siglas demoda desde el principio de losaos noventa en el mundo delos sistemas de informacin.


3. Objetivos y servicios de los SGBD

Los SGBD que actualmente estn en el mercado pretenden satisfacer un con-junto de objetivos directamente deducibles de lo que hemos explicado hastaahora. A continuacin los comentaremos.

3.1. Consultas no predefinidas y complejas

El objetivo fundamental de los SGBD es permitir que se hagan consultasnopredefinidas (ad hoc) y complejas.

Consultas que afectan a ms de una entidad tipo

Se quiere conocer el nmero de estudiantes de ms de veinticinco aos y con notamedia superior a siete que estn matriculados actualmente en la asignatura de lgebra.

De cada estudiante matriculado en menos de tres asignaturas, se quiere obtener elnombre, el nmero de matrcula, el nombre de las asignaturas y el nombre de losprofesores de estas asignaturas.

Los usuarios podrn hacer consultas de cualquier tipo y complejidad di-rectamente al SGBD. El SGBD tendr que responder inmediatamente sinque estas consultas estn preestablecidas; es decir, sin que se tenga queescribir, compilar y ejecutar un programa especfico para cada consulta.

El usuario debe formular la consulta con un lenguajesencillo (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 con-sultas incorporadas (por ejemplo, para procesos repetitivos).

La solucin estndar para alcanzar este doble objetivo (consultas no predefi-nidas y complejas) es el lenguajeSQL.

3.2. Flexibilidad e independencia

La complejidad de las BD y la necesidad de irlas adaptando a la evolucin del SIhacen que un objetivo bsico de los SGBD sea dar flexibilidadaloscambios.

Interesa obtener la mximaindependencia posible entre los datos y los pro-cesos usuarios para que se pueda llevar a cabo todo tipo de cambios tecnol-gicos y variaciones en la descripcin de la BD, sin que se deban modificar losprogramas de aplicacin ya escritos ni cambiar la forma de escribir las consul-tas (o actualizaciones) directas.

Ficheros tradicionales

En los ficheros tradicionales,cada vez que se quera haceruna consulta se tena que es-cribir un programa a medida.


Para conseguir esta independencia, tanto los usuarios que hacen con-sultas (o actualizaciones) directas como los profesionales informticosque escriben programas que las llevan incorporadas, deben poder des-conocer las caractersticas fsicas de la BD con que trabajan. No necesi-tan saber nada sobre el soporte fsico, ni estar al corriente de qu SO seutiliza, qu ndices hay, la compresin o no compresin de datos, etc.

De este modo, se pueden hacer cambios de tecnologa y cambios fsicospara mejorar el rendimiento sin afectar a nadie. Este tipo de indepen-dencia recibe el nombre de independenciafsicadelosdatos.

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.

Sin embargo, con la independencia fsica no tenemos suficiente. Tam-bin queremos que los usuarios (los programadores de aplicaciones olos usuarios directos) no tengan que hacer cambios cuando se modificala descripcin lgica o el esquema de la BD (por ejemplo, cuando seaaden/suprimen entidades o interrelaciones, atributos, etc.

Y todava ms: queremos que diferentes procesos usuarios puedan te-ner diferentes visiones lgicas de una misma BD, y que estas visionesse puedan mantener lo ms independientes posibles de la BD, y entreellas mismas. Este tipo de independencia se denomina independencialgicadelosdatos, y da flexibilidad y elasticidad a los cambios lgicos.

Ejemplos de independencia lgica

1) El personal administrativo de secretara podra tener una visin de la entidad estudiantesin que fuese necesario que existiese el atributo nota. Sin embargo, los usuarios profesores(o los programas dirigidos a ellos) podran tener una visin en la que existiese el atributonota pero no el atributo fecha de pago.

2) Decidimos ampliar la longitud del atributo nombre y lo aumentamos de treinta a cin-cuenta caracteres, pero no sera necesario modificar los programas que ya tenemos escri-tos si no nos importa que los valores obtenidos tengan slo los primeros treinta caracte-res del nombre.

3.3. Problemas de la redundancia

En el mundo de los ficheros tradicionales, cada aplicacin utilizaba su fichero.Sin embargo, puesto que se daba mucha coincidencia de datos entre aplica-ciones, se produca tambin mucha redundancia entre los ficheros. Ya hemosdicho que uno de los objetivos de los SGBD es facilitarlaeliminacindelaredundancia.

Ved tambin

Las diferentes visiones lgicasde una BD se vern en el apar-tado 4 de este mdulo didcti-co.

Independencia lgica delos datos

Por ejemplo, el hecho de su-primir el atributo fecha de naci-miento de la entidad estudiantey aadir otra entidad aula nodebera afectar a ninguno delos programas existentes queno utilicen el atributo fecha denacimiento.

Independencia lgica

Los sistemas de gestin de fi-cheros tradicionales no danninguna independencia lgica.Los SGBD s que la dan; unode sus objetivos es conseguir lamxima posible, pero dan me-nos de lo que sera deseable.


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 unproblema grave, pero actualmente prcticamente nunca lo es. Qu problemahay, entonces? Simplemente, lo que todos hemos sufrido ms de una vez; sitenemos algo apuntado en dos lugares diferentes no pasar demasiado tiem-po hasta que las dos anotaciones dejen de ser coherentes, porque habremosmodificado la anotacin en uno de los lugares y nos habremos olvidado dehacerlo en el otro.

As pues, el verdadero problema es el grave riesgo de inconsistencia o incohe-rencia de los datos; es decir, la prdidadeintegridad que las actualizacionespueden provocar cuando existe redundancia.

Por lo tanto, convendra evitar la redundancia. En principio, nos convieneconseguir que un dato slo figure una vez en la BD. Sin embargo, esto nosiempre ser cierto. Por ejemplo, para representar una interrelacin entre dosentidades, se suele repetir un mismo atributo en las dos, para que una hagareferencia a la otra.

Actividad

Por qu queremos evitar laredundancia? Qu problemanos comporta?

Otro ejemplo podra ser el disponer de reproducciones de los datos por razonesde fiabilidad, disponibilidad o costes de comunicaciones.

El SGBD debe permitir que el diseador defina datos redundantes, peroentonces tendra que ser el mismo SGBD el que hiciese automticamen-te la actualizacindelosdatos en todos los lugares donde estuviesenrepetidos.

Ved tambin

Para recordar lo que se ha di-cho sobre datos reproducidosconsultad el subapartado 2.3de este mdulo didctico.

La duplicacin de datos es el tipo de redundancia ms habitual, pero tambintenemos redundancia cuando guardamos en la BD datos derivados (o calcula-dos) a partir de otros datos de la misma BD. De este modo podemos respon-der rpidamente a consultas globales, ya que nos ahorramos la lectura de grancantidad de registros.

En los casos de datos derivados, para que el resultado del clculo se mantengaconsistente con los datos elementales, es necesario rehacer el clculo cada vezque stos se modifican. El usuario (ya sea programador o no) puede olvidarsede hacer el nuevo clculo; por ello convendr que el mismo SGBD lo hagaautomticamente.

3.4. Integridad de los datos

Nos interesar que los SGBD aseguren el mantenimientodelacalidaddelosdatos en cualquier circunstancia. Acabamos de ver que la redundancia puedeprovocar prdida de integridad de los datos, pero no es la nica causa posible.

Datos derivados

Por ejemplo, podremos decla-rar que el atributo DNI debeser clave o que la fecha de na-cimiento debe ser una fechacorrecta y, adems, se debecumplir que el estudiante nopueda tener menos de dieci-ocho aos ni ms de noventa ynueve, o que el nmero de es-tudiantes matriculados de unaasignatura no sea superior aveintisiete, etc.


Se podra perder la correccin o la consistencia de los datos por muchas otrasrazones: 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 noslleve el control de las actualizaciones en el caso de las redundancias, para ga-rantizar la integridad. Del mismo modo, podremos darle otras reglasdein-tegridad o restricciones para que asegure que los programas las cumplencuando efectan las actualizaciones.

Cuando el SGBD detecte que un programa quiere hacer una operacinque va contra las reglas establecidas al definir la BD, no se lo deberpermitir, y le tendr que devolver un estado de error.

Al disear una BD para un SI concreto y escribir su esquema, no slodefiniremos los datos, sino tambin las reglas de integridad que quere-mos que el SGBD haga cumplir.

Aparte de las reglas de integridad que el diseador de la BD puede definir y queel SGBD entender y har cumplir, el mismo SGBD tiene reglas de integridadinherentes al modelo de datos que utiliza y que siempre se cumplirn. Son lasdenominadas reglasdeintegridaddelmodelo. Las reglas definibles por partedel usuario son las reglasdeintegridaddelusuario. El concepto de integridadde los datos va ms all de prevenir que los programas usuarios almacenendatos incorrectos. En casos de errores o desastres, tambin podramos perder laintegridad de los datos. El SGBD nos debe dar las herramientas para reconstruiro restaurar los datos estropeados.

Los procesosderestauracin (restore o recovery) de los que todo SGBDdispone pueden reconstruir la BD y darle el estado consistente y correctoanterior al incidente. Esto se acostumbra a hacer gracias a la obtencinde copias peridicas de los datos (se denominan copias de seguridad obackup) y mediante el mantenimiento continuo de un diario (log) dondeel SGBD va anotando todas las escrituras que se hacen en la BD.

Reglas de integridad

Por ejemplo, podremos decla-rar que el atributo DNI debeser clave o que la fecha de na-cimiento debe ser una fechacorrecta y, adems, se debecumplir que el estudiante nopueda tener menos de dieci-ocho aos ni ms de noventa ynueve, o que el nmero de es-tudiantes matriculados de unaasignatura no sea superior aveintisiete, etc.

Reglas de integridad delmodelo

Por ejemplo, un SGBD relacio-nal nunca aceptar que una ta-bla tenga filas duplicadas, unSGBD jerrquico nunca acep-tar que una entidad tipo estdefinida como hija de dos enti-dades tipo diferentes, etc.


3.5. Concurrencia de usuarios

Un objetivo fundamental de los SGBD es permitir que varios usuariospuedan acceder concurrentemente a la misma BD.

Cuando los accesos concurrentes son todos de lectura (es decir, cuando la BDslo se consulta), el problema que se produce es simplemente de rendimiento,causado por las limitaciones de los soportes de que se dispone: pocos meca-nismos de acceso independientes, movimiento del brazo y del giro del discodemasiado lentos, buffers locales demasiado pequeos, etc.

Cuando un usuario o ms de uno estn actualizando los datos, se pueden pro-ducir problemasdeinterferencia que tengan como consecuencia la obten-cin de datos errneos y la prdida de integridad de la BD.

Para tratar los accesos concurrentes, los SGBD utilizan el concepto de transac-cin de BD, concepto de especial utilidad para todo aquello que hace referen-cia a la integridad de los datos, como veremos a continuacin.

Denominamos transaccin de BD o, simplemente, transaccin unconjunto de operaciones simples que se ejecutan como una unidad. LosSGBD deben conseguir que el conjunto de operaciones de una transac-cin nunca se ejecute parcialmente. O se ejecutan todas, o no se ejecutaninguna.

Ejemplos de transacciones

1) Imaginemos un programa pensado para llevar a cabo la operacin de transferencia dedinero de una cuenta X a otra Y. Supongamos que la transferencia efecta dos operacio-nes: en primer lugar, el cargo a X y despus, el abono a Y. Este programa se debe ejecu-tar de forma que se hagan las dos operaciones o ninguna, ya que si por cualquier razn(por ejemplo, por interrupcin del flujo elctrico) el programa ejecutase slo el cargo dedinero a X sin abonarlos a Y, la BD quedara en un estado incorrecto. Queremos que laejecucin de este programa sea tratada por el SGBD como una transaccin de BD.

2) Otro ejemplo de programa que querramos que tuviera un comportamiento de transac-cin podra ser el que aumentara el 30% de la nota de todos los estudiantes. Si slo au-mentara la nota a unos cuantos estudiantes, la BD quedara incorrecta.

Para indicar al SGBD que damos por acabada la ejecucin de la transaccin,el programa utilizar la operacin de COMMIT. Si el programa no puede acabarnormalmente (es decir, si el conjunto de operaciones se ha hecho slo de for-ma parcial), el SGBD tendr que deshacer todo lo que la transaccin ya hayahecho. Esta operacin se denomina ROLLBACK.

Acabamos de observar la utilidad del concepto de transaccin para el mante-nimiento de la integridad de los datos en caso de interrupcin de un conjun-to de operaciones lgicamente unitario. Sin embargo, entre transacciones que

Usuarios concurrentes

Actualmente ya no son raroslos SI que tienen, en un instan-te determinado, miles de se-siones de usuario abiertas si-multneamente. No hace fal-ta pensar en los tpicos siste-mas de los consorcios de com-paas areas o casos similares,sino en los servidores de pgi-nas web.


se ejecutan concurrentemente se pueden producir problemas de interferenciaque hagan obtener resultados errneos o que comporten la prdida de la in-tegridad de los datos.

Consecuencias de la interferencia entre transacciones

1) Imaginemos que una transaccin que transfiere dinero de X a Y se ejecuta concurren-temente con una transaccin que observa el saldo de las cuentas Y y X, en este orden,y nos muestra su suma. Si la ejecucin de forma concurrente de las dos transaccionescasualmente es tal que la transferencia se ejecuta entre la ejecucin de las dos lecturasde la transaccin de suma, puede producir resultados incorrectos. Adems, si los decideescribir en la BD, sta quedar inconsistente (consultad la figura 3).

2) Si simultneamente con el generoso programa que aumenta la nota de los estudiantesen un 30%, se ejecuta un programa que determina la nota media de todos los estudiantesde una determinada asignatura, se podr encontrar a estudiantes ya gratificados y a otrosno gratificados, algo que producir resultados errneos.

Estos son slo dos ejemplos de las diferentes consecuencias negativas que puede tener lainterferencia entre transacciones en la integridad de la BD y en la correccin del resultadode las consultas.

Figura 3.


Nos interesar que el SGBD ejecute las transacciones de forma que no seinterfieran; es decir, que queden aisladas unas de otras. Para conseguirque las transacciones se ejecuten como si estuviesen aisladas, los SGBDutilizan distintas tcnicas. La ms conocida es el bloqueo (lock).

El bloqueo de unos datos en beneficio de una transaccin consiste enponer limitaciones a los accesos que las dems transacciones podrnhacer a estos datos.

Bloqueos en la transferencia de dinero

Por ejemplo, si la transaccin de transferencia de dinero modifica el saldo de la cuenta X,el SGBD bloquea esta cuenta de forma que, cuando la transaccin de suma quiera leerla,tenga que esperar a que la transaccin de transferencia acabe; esto se debe al hecho deque al acabar una transaccin, cuando se efectan las operaciones COMMIT o ROLLBACKse liberan los objetos que tena bloqueados.

Cuando se provocan bloqueos, se producen esperas, retenciones y, en conse-cuencia, el sistema es ms lento. Los SGBD se esfuerzan en minimizar estosefectos negativos.

3.6. Seguridad

El trmino seguridad se ha utilizado en diferentes sentidos a lo largo de la his-toria de la informtica.

Actualmente, en el campo de los SGBD, el trmino seguridad se sueleutilizar para hacer referencia a los temas relativos a la confidencialidad,las autorizaciones, los derechos de acceso, etc.

Estas cuestiones siempre han sido importantes en los SI militares, las agenciasde informacin y en mbitos similares, pero durante los aos noventa hanido adquiriendo importancia en cualquier SI donde se almacenen datos sobre

personas. Recordad que en el Estado espaol tenemos una ley2, que exige laproteccin de la confidencialidad de estos datos.

Los SGBD permiten definir autorizaciones o derechos de acceso a diferentesniveles: al nivel global de toda la BD, al nivel entidad y al nivel atributo.

Estos mecanismos de seguridad requieren que el usuario se pueda identificar.Se acostumbra a utilizar cdigos de usuarios (y grupos de usuarios) acompaa-dos de contraseas (passwords), pero tambin se utilizan tarjetas magnticas,identificacin por reconocimiento de la voz, etc.

(2)Ley Orgnica 15/1999, de 13de diciembre, de Proteccin deDatos de Carcter Personal. (BOEnm. 298, de 12/12/1999, pgs.43088-43099).

Derechos de acceso

Por ejemplo, el usuario SECRE3podra tener autorizacin pa-ra consultar y modificar todaslas entidades de la BD, excep-to el valor del atributo nota delos estudiantes, y no estar auto-rizado a hacer ningn tipo desupresin o insercin.


Nos puede interesar almacenar la informacin con una codificacin secreta;es decir, con tcnicasdeencriptacin (como mnimo se deberan encriptarlas contraseas). Muchos de los SGBD actuales tienen prevista la encriptacin.

Prcticamente todos los SGBD del mercado dan una gran variedad de herra-mientas para la vigilancia y la administracin de la seguridad. Los hay que,incluso, tienen opciones (con precio separado) para los SI con unas exigenciasaltsimas, como por ejemplo los militares.


4. Arquitectura de los SGBD

A continuacin veremos algunas nociones bsicas de la arquitectura de losSGBD.

4.1. Esquemas y niveles

Para trabajar con nuestras BD, los SGBD necesitan conocer su estructura (quentidades tipo habr, qu atributos tendrn, etc.).

Los SGBD necesitan que les demos una descripcin o definicin de laBD. Esta descripcin recibe el nombre de esquemadelaBD, y los SGBDla tendrn continuamente a su alcance.

El esquema de la BD es un elemento fundamental de la arquitectura de unSGBD que permite independizar el SGBD de la BD; de este modo, se puedecambiar el diseo de la BD (su esquema) sin tener que hacer ningn cambioen el SGBD.

Anteriormente, ya hemos hablado de la distincin entre dos niveles de repre-sentacin informtica: el nivel lgico y el fsico.

El nivellgico nos oculta los detalles de cmo se almacenan los datos, cmose mantienen y cmo se accede fsicamente a ellos. En este nivel slo se hablade entidades, atributos y reglas de integridad.

Por cuestiones de rendimiento, nos podr interesar describir elementos de ni-velfsico como, por ejemplo, qu ndices tendremos y qu caractersticas pre-sentarn, cmo y dnde (en qu espacio fsico) queremos que se agrupen fsi-camente los registros, de qu tamao deben ser las pginas, etc.

En el periodo 1975-1982, ANSI intentaba establecer las bases para crear estn-dares en el campo de las BD. El comit conocido como ANSI/SPARC recomen-d que la arquitectura de los SGBD previese tres niveles de descripcin de la

BD, no slo dos3.

(3)De hecho, en el ao 1971, el co-mit CODASYL ya haba propuestolos tres niveles de esquemas.


De acuerdo con la arquitectura ANSI/SPARC, deba haber tres niveles deesquemas (tres niveles de abstraccin). La idea bsica de ANSI/SPARCconsista en descomponer el nivel lgico en dos: el nivelexterno y elnivelconceptual. Denominbamos nivelinterno lo que aqu hemosdenominado nivel fsico.

De este modo, de acuerdo con ANSI/SPARC, habra los tres niveles de esquemasque mencionamos a continuacin:

a) En el nivel externo se sitan las diferentes visiones lgicas que los procesosusuarios (programas de aplicacin y usuarios directos) tendrn de las partes dela BD que utilizarn. Estas visiones se denominan esquemasexternos.

b) En el nivel conceptual hay una sola descripcin lgica bsica, nica y global,que denominamos esquemaconceptual, y que sirve de referencia para el restode los esquemas.

c) En el nivel fsico hay una sola descripcin fsica, que denominamos esque-mainterno.

Figura 4.

En el esquemaconceptual se describirn las entidades tipo, sus atribu-tos, las interrelaciones y las restricciones o reglas de integridad.

El esquema conceptual corresponde a las necesidades del conjunto de la em-presa o del SI, por lo que se escribir de forma centralizada durante el deno-minado diseo lgico de la BD.


Sin embargo, cada aplicacin podr tener su visin particular, y seguramenteparcial, del esquema conceptual. Los usuarios (programas o usuarios directos)vern la BD mediante esquemas externos apropiados a sus necesidades. Estosesquemas se pueden considerar redefiniciones del esquema conceptual, con laspartes y los trminos que convengan para las necesidades de las aplicaciones(o grupos de aplicaciones). Algunos sistemas los denominan subesquemas.

Al definir un esquema externo, se citarn slo aquellos atributos yaquellas entidades que interesen; los podremos renombrar, podremosdefinir datos derivados o redefinir una entidad para que las aplicacionesque utilizan este esquema externo crean que son dos, definir combina-ciones de entidades para que parezcan una sola, etc.

Ejemplo de esquema externo

Imaginemos una BD que en el esquema conceptual tiene definida, entre muchas otras,una entidad estudiante con los siguientes atributos: num_matri, nombre, apellido, num_DNI,direccion, fecha_nac, telefono. Sin embargo, nos puede interesar que unos determinadosprogramas o usuarios vean la BD formada de acuerdo con un esquema externo que tengadefinidas dos entidades, denominadas estudiante y persona.

a) La entidad estudiante podra tener definido el atributo numero_matricula (definido co-mo derivable directamente de num_matri), el atributo nombre_pila (de nombre), el atributoapellido y el atributo DNI (de num_DNI).

b) La entidad persona podra tener el atributo DNI (obtenido de num_DNI), el atributonombre (formado por la concatenacin de nombre y apellido), el atributo direccion y elatributo edad (que deriva automticamente de fecha_nac).

El esquemainterno o fsico contendr la descripcin de la organizacinfsica de la BD: caminos de acceso (ndices, hashing, apuntadores, etc.),codificacin de los datos, gestin del espacio, tamao de la pgina, etc.

El esquema de nivel interno responde a las cuestiones de rendimiento (espacio

y tiempo) planteadas al hacer el diseo fsico de la BD y al ajustarlo4 posterior-mente a las necesidades cambiantes.

De acuerdo con la arquitectura ANSI/SPARC, para crear una BD hace falta de-finir previamente su esquema conceptual, definir como mnimo un esquemaexterno y, de forma eventual, definir su esquema interno. Si este ltimo es-quema no se define, el mismo SGBD tendr que decidir los detalles de la orga-nizacin fsica. El SGBD se encargar de hacer las correspondencias (mappings)entre los tres niveles de esquemas.

(4)En ingls, el ajuste se conocecon el nombre de tuning.

Actividad

Qu hay que hacer para crearuna BD?


Esquemas y niveles en los SGBD relacionales

En los SGBD relacionales (es decir, en el mundo de SQL) se utiliza una terminologaligeramente diferente. No se separan de forma clara tres niveles de descripcin. Se hablade un solo esquema schema, pero en su interior se incluyen descripciones de los tresniveles. En el schema se describen los elementos de aquello que en la arquitectura ANSI/SPARC se denomina esquema conceptual (entidades tipo, atributos y restricciones) y lasvistas view, que corresponden aproximadamente a los esquemas externos.

El modelo relacional en que est inspirado SQL se limita al mundo lgico. Por ello, elestndar ANSI-ISO de SQL no habla en absoluto del mundo fsico o interno; lo deja enmanos de los SGBD relacionales del mercado. Sin embargo, estos SGBD proporcionanla posibilidad de incluir dentro del schema descripciones de estructuras y caractersticasfsicas (ndice, tablespace, cluster, espacios para excesos, etc.).

4.2. Independencia de los datos

En este subapartado veremos cmo la arquitectura de tres niveles que acaba-mos de presentar nos proporciona los dos tipos de independencia de los datos:la fsica y la lgica.

Hay independenciafsica cuando los cambios en la organizacin fsicade la BD no afectan al mundo exterior (es decir, los programas usuarioso los usuarios directos).

De acuerdo con la arquitectura ANSI/SPARC, habr independencia fsica cuan-do los cambios en el esquema interno no afecten al esquema conceptual ni alos esquemas externos.

Figura 5.

Ved tambin

Los dos tipos de independen-cia de los datos se han expli-cado en el subapartado 3.2 deeste mdulo didctico.


Es obvio que cuando cambiemos unos datos de un soporte a otro, o los cam-biemos de lugar dentro de un soporte, no se vern afectados ni los programasde aplicacin ni los usuarios directos, ya que no se modificar el esquema con-ceptual ni el externo. Sin embargo, tampoco tendran que verse afectados sicambisemos, por ejemplo, el mtodo de acceso a unos registros determina-

dos5, el formato o la codificacin, etc. Ninguno de estos casos debera afectaral mundo exterior, sino slo a la BD fsica; es decir, el esquema interno.

Si hay independencia fsica de los datos, lo nico que variar al cambiar elesquema interno son las correspondencias entre el esquema conceptual y elinterno. Obviamente, la mayora de los cambios del esquema interno obliga-rn a rehacer la BD real (la fsica).

(5)Por ejemplo, eliminando un ndi-ce o sustituyndolo por otro.

Hay independencialgica cuando los usuarios6 no se ven afectadospor los cambios en el nivel lgico.

Figura 6.

Dados los dos niveles lgicos de la arquitectura ANSI/SPARC, diferenciaremoslas dos situaciones siguientes:

(6)Programas de aplicacin o usua-rios directos.


1)Cambiosenelesquemaconceptual. Un cambio de este tipo no afectar alos esquemas externos que no hagan referencia a las entidades o a los atributosmodificados.

2)Cambiosenlosesquemasexternos. Efectuar cambios en un esquema ex-terno afectar a los usuarios que utilicen los elementos modificados. Sin em-bargo, no debera afectar a los dems usuarios ni al esquema conceptual, ytampoco, en consecuencia, al esquema interno.

Usuarios no afectados por los cambios

Notad que no todos los cambios de elementos de un esquema externo afectarn a sususuarios. Veamos un ejemplo de ello: antes hemos visto que cuando eliminbamos elatributo apellido del esquema conceptual, debamos modificar el esquema externo dondedefinamos nombre, porque all estaba definido como concatenacin de nombre y apellido.Pues bien, un programa que utilizase el atributo nombre no se vera afectado si modific-semos el esquema externo de modo que nombre fuese la concatenacin de nombre y unacadena constante (por ejemplo, toda en blanco). Como resultado, habra desaparecido elapellido de nombre, sin que hubiera sido necesario modificar el programa.

Los SGBD actuales proporcionan bastante independencia lgica, pero menosde la que hara falta, ya que las exigencias de cambios constantes en el SI pidengrados muy elevados de flexibilidad. Los sistemas de ficheros tradicionales, encambio, no ofrecen ninguna independencia lgica.

4.3. Flujo de datos y de control

Para entender el funcionamiento de un SGBD, a continuacin veremos losprincipales pasos de la ejecucin de una consulta enviada al SGBD por unprograma de aplicacin. Explicaremos las lneas generales del flujo de datos yde control entre el SGBD, los programas de usuario y la BD.

Recordad que el SGBD, con la ayuda del SO, lee pginas (bloques) de los so-portes donde est almacenada la BD fsica, y las lleva a un rea de buffers o me-morias cach en la memoria principal. El SGBD pasa registros desde los buffershacia el rea de trabajo del mismo programa.

Ejemplo

Si eliminamos el atributo ape-llido, por ejemplo, no se vernafectados los esquemas exter-nos (ni los usuarios) que nohagan referencia a este atri-buto. Si se alarga el atributodireccin al esquema concep-tual, no ser necesario modifi-car el esquema externo dondese ha definido la direccin y ob-viamente, tampoco resultarnafectados los programas y losusuarios que la utilicen.

Supongamos que la consulta pide los datos del estudiante que tiene un deter-minado DNI. Por lo tanto, la respuesta que el programa obtendr ser un solo

registro y lo recibir dentro de un rea de trabajo propia7.

(7)Por ejemplo, una variable conestructura de tupla.


Figura 7. Ejecucin de una consulta

En la figura vemos representada la BD, los tres niveles de esquemas, el rea de los buffers, el SGBD y el programa de aplicacinque le hace la consulta.

El proceso que se sigue es el siguiente:

a) Empieza con una llamada (1) del programa al SGBD, en la que se le enva laoperacin de consulta. El SGBD debe verificar que la sintaxis de la operacinrecibida sea correcta, que el usuario del programa est autorizado a hacerla,etc. Para poder llevar a cabo todo esto, el SGBD se basa (2) en el esquemaexterno con el que trabaja el programa y en el esquema conceptual.

b) Si la consulta es vlida, el SGBD determina, consultando el esquema interno(3), qu mecanismo debe seguir para responderla. Ya sabemos que el programausuario no dice nada respecto a cmo se debe resolver fsicamente la consulta.Es el SGBD el que lo debe determinar. Casi siempre hay varias formas y dife-

rentes caminos para responder a una consulta8. Supongamos que ha elegidoaplicar un hashing al valor del DNI, que es el parmetro de la consulta, y elresultado es la direccin de la pgina donde se encuentra (entre muchos otros)el registro del estudiante buscado.

(8)Por ejemplo, siempre tiene laposibilidad de hacer una bsquedasecuencial.


c) Cuando ya se sabe cul es la pgina, el SGBD comprobar (4) si por suerteesta pgina ya se encuentra en aquel momento en el rea de los buffers (tal vezcomo resultado de una consulta anterior de este usuario o de otro). Si no est,el SGBD, con la ayuda del SO, la busca en disco y la carga en los buffers (5). Siya est, se ahorra el acceso a disco.

d) Ahora, la pgina deseada ya est en la memoria principal. El SGBD extrae, deentre los distintos registros que la pgina puede contener, el registro buscado, einterpreta la codificacin y el resultado segn lo que diga el esquema interno.

e) El SGBD aplica a los datos las eventuales transformaciones lgicas que im-plica el esquema externo (tal vez cortando la direccin por la derecha) y laslleva al rea de trabajo del programa (6).

f)A continuacin, el SGBD retorna el control al programa (7) y da por termi-nada la ejecucin de la consulta.

Diferencias entre SGBD

Aunque entre diferentes SGBDpuede haber enormes diferen-cias de funcionamiento, suelenseguir el esquema general queacabamos de explicar.


5. Modelos de BD

Una BD es una representacin de la realidad (de la parte de la realidad quenos interesa en nuestro SI). Dicho de otro modo, una BD se puede considerarun modelo de la realidad. El componente fundamental utilizado para modelaren un SGBD relacional son las tablas (denominadas relaciones en el mundoterico). Sin embargo, en otros tipos de SGBD se utilizan otros componentes.

El conjunto de componentes o herramientas conceptuales que un SGBDproporciona para modelar recibe el nombre de modelodeBD. Algunosejemplos de modelos de BD son el modelorelacional, el modelojerr-quico, el modeloenred y el modelorelacionalconobjetos.

Todo modelo de BD nos proporciona tres tipos de herramientas:

a)Estructurasdedatos con las que se puede construir la BD: tablas, rboles,etc.

b) Diferentes tipos de restricciones(oreglas)deintegridad que el SGBD ten-dr que hacer cumplir a los datos: dominios, claves, etc.

c) Una serie de operaciones para trabajar con los datos. Un ejemplo de ello,en el modelo relacional, es la operacin SELECT, que sirve para seleccionar (oleer) las filas que cumplen alguna condicin. Un ejemplo de operacin tpicadel modelo jerrquico y del modelo en red podra ser la que nos dice si undeterminado registro tiene hijos o no.

EvolucindelosmodelosdeBD

De los cuatro modelos de BD que hemos citado, el que apareci primero, aprincipios de los aos sesenta, fue el modelojerrquico. Sus estructuras sonregistros interrelacionados en forma de rboles. El SGBD clsico de este modeloes el IMS/DL1 de IBM.

Cuidado con lasconfusiones!

Popularmente, en especial enel campo de la informticapersonal, se denomina BD a loque aqu denominamos SGBD.Tampoco se debe confundir laBD considerada como modelode la realidad con lo que aqudenominamos modelo de BD.El modelo de BD es el conjun-to de herramientas conceptua-les (piezas) que se utilizan paraconstruir el modelo de la reali-dad.

A principios de los setenta surgieron SGBD basados en un modeloenred.Como en el modelo jerrquico, hay registros e interrelaciones, pero un regis-tro ya no est limitado a ser hijo de un solo registro tipo. El comit CO-DASYL-DBTG propuso un estndar basado en este modelo, que fue adoptado

por muchos constructores de SGBD9. Sin embargo, encontr la oposicin deIBM, la empresa entonces dominante. La propuesta de CODASYL-DBTG yadefina tres niveles de esquemas.

(9)Por ejemplo, IDS de Bull, DMSde Univac y DBMS de Digital.


Desde los aos ochenta fueron apareciendo una gran cantidad de SGBD basa-dos en el modelorelacional propuesto en 1969 por E.F. Codd, de IBM, y prc-

ticamente todos utilizaban como lenguaje nativo el SQL10. El modelo relacio-nal se basa en el concepto matemtico de relacin, que aqu podemos conside-rar de momento equivalente al trmino tabla (formada por filas y columnas).La mayor parte de los SI que actualmente estn en funcionamiento utilizanSGBD relacionales.

Figura 8.

As como en los modelos prerrelacionales (jerrquico y en red), las estructurasde datos constan de dos elementos bsicos (los registros y las interrelaciones),en el modelo relacional constan de un solo elemento: la tabla, formada porfilas y columnas.

Otra diferencia importante entre los modelos prerrelacionales y el modelo re-lacional es que el modelo relacional se limita al nivel lgico (no hace absoluta-mente ninguna consideracin sobre las representaciones fsicas). Es decir, nosda una independencia fsica de datos total. Esto es as si hablamos del mode-lo terico, pero los SGBD del mercado nos proporcionan una independencialimitada.

El modelodeBDrelacionalconobjetos trata de ampliar el modelo relacio-nal, aadindole la posibilidad de que los tipos de datos sean tipos abstractosde datos, TAD. Esto acerca los sistemas relacionales al paradigma de la OO. Al-

(10)Por ejemplo, Oracle, DB2 deIBM, Informix, MySQL, PostgreSQLy SQL Server de Microsoft.

Ved tambin

El modelo relacional se estudiacon detalle en el mdulo Elmodelo relacional y el lgebrarelacional de esta asignatura.


gunos SGBD relacionales (por ejemplo, Oracle, DB2, PostgreSQL) han adopta-do ampliaciones de este estilo, pero no estn siendo demasiado utilizados. Ac-tualmente, la visin de las BD relacionales desde el paradigma OO se acostum-bra a realizar con herramientas especializadas, como, por ejemplo, los ORMframeworks (Java EE/EJB), Hibernate, NET-EF, etc.), que permiten trabajar conclases persistentes sin tener que tratar directamente con tablas relacionales.

Hablamos de modelos de BD, pero de hecho se acostumbran a denominar mo-delos de datos, ya que permiten modelar los datos. Sin embargo, hay modelosde datos que no son utilizados por los SGBD del mercado: slo se usan duranteel proceso de anlisis y diseo, pero no en las realizaciones.

Los ms conocidos de estos tipos de modelos son los modelossemnticosy los funcionales. stos nos proporcionan herramientas muy potentes paradescribir las estructuras de la informacin del mundo real, la semntica y lasinterrelaciones, pero normalmente no disponen de operaciones para tratarlas.Se limitan a ser herramientas de descripcin lgica. Son muy utilizados en laetapa del diseo de BD y en herramientas CASE. El ms extendido de estosmodelos de datos es el modelo ER (entity-relationship). En el mundo de la OO,es muy popular el diagrama de clases UML (unified modeling language). Desdeel mundo de las BD se acostumbra a considerar que las clases persistentes (ysus asociaciones) de un diagrama de clases UML representan lo mismo quelas entidades (e interrelaciones) de un modelo de datos ER. Existen algunasherramientas que permiten desarrollar BD a nivel ER y UML sin tener que bajara nivel de tabla. Esto es equivalente a lo que permiten realizar las herramientasORM anteriormente citadas.

En esta asignatura hablamos slo de BD con modelos de datos estructurados,que son los que normalmente se utilizan en los SI empresariales. Sin embargo,hay SGBD especializados en tipos de aplicaciones concretas que no siguenninguno de estos modelos.

Ms cerca del mundolgico

La evolucin de los modelos alo largo de los aos los ha idoalejando del mundo fsico y losha acercado al mundo lgico;es decir, se han alejado de lasmquinas y se han acercado alas aplicaciones.


6. Lenguajes y usuarios

Para comunicarse con el SGBD, el usuario, ya sea un programa de aplicacin oun usuario directo, se vale de un lenguaje. Hay muchos lenguajes diferentes,segn el tipo de usuarios para los que estn pensados y el tipo de cosas quelos usuarios deben poder expresar con ellos:

a) Habr usuarios informticos muy expertos que querrn escribir procesoscomplejos y que necesitarn lenguajes complejos.

b) Sin embargo, habr usuarios finales no informticos, ocasionales (espor-dicos), que slo harn consultas. Estos usuarios necesitarn un lenguaje muysencillo, aunque d un rendimiento bajo en tiempo de respuesta.

c) Tambin podr haber usuarios finales no informticos, dedicados o especia-lizados. Son usuarios cotidianos o, incluso, dedicados exclusivamente a traba-

jar con la BD.11 Estos usuarios necesitarn lenguajes muy eficientes y compac-tos, aunque no sea fcil aprenderlos. Tal vez sern lenguajes especializados entipos concretos de tareas.

Hay lenguajes especializados en la escritura de esquemas; es decir, enla descripcin de la BD. Se conocen genricamente como DDL o Da-ta Definition Language. Incluso hay lenguajes especficos para esquemasinternos, lenguajes para esquemas conceptuales y lenguajes para esque-mas externos.

Otros lenguajes estn especializados en la utilizacin de la BD (consul-tas y mantenimiento). Se conocen como DML o Data Management Lan-guage. Sin embargo, lo ms frecuente es que el mismo lenguaje dispongade construcciones para las dos funciones, DDL y DML.

El lenguajeSQL, que es el ms utilizado en las BD relacionales, tiene verbosinstrucciones de tres tipos diferentes:

1)VerbosdeltipoDML; por ejemplo, SELECT para hacer consultas, e INSERT,UPDATE y DELETE para hacer el mantenimiento de los datos.

2)VerbosdeltipoDDL; por ejemplo, CREATE TABLE para definir las tablas,sus columnas y las restricciones.

3) Adems, SQL tiene verbosdecontroldelentorno, como por ejemplo COM-MIT y ROLLBACK para delimitar transacciones.

Qu debera poder decirel usuario al SGBD?

Por un lado, la persona quehace el diseo debe tenerla posibilidad de describir alSGBD la BD que ha diseado.Por otro lado, debe ser posiblepedirle al sistema que relleney actualice la BD con los datosque se le den. Adems, y ob-viamente, el usuario debe dis-poner de medios para hacerleconsultas.

(11)Por ejemplo, personas dedica-das a introducir datos masivamen-te.


En cuanto a los aspectosDML, podemos diferenciar dos tipos de lenguajes:

a) Lenguajes muy declarativos (o implcitos), con los que se especifica qu sequiere hacer sin explicar cmo se debe hacer.

b) Lenguajes ms explcitos o procedimentales, que nos exigen conocer mscuestiones del funcionamiento del SGBD para detallar paso a paso cmo sedeben realizar las operaciones (lo que se denomina navegar por la BD).

Como es obvio, los aspectosDDL (las descripciones de los datos) son siempredeclarativos por su propia naturaleza.

Los lenguajes utilizados en los SGBD prerrelacionales eran procedimentales.SQL es bsicamente declarativo, pero tiene posibilidades procedimentales.

Aunque casi todos los SGBD del mercado tienen SQL como lenguaje na-tivo, ofrecen otras posibilidades, como por ejemplo 4GL y herramientasvisuales:

1)Lenguajes4GL (4th Generation Languages12) de muy alto nivel, quesuelen combinar elementos procedimentales con elementos declarati-vos. Pretenden facilitar no slo el tratamiento de la BD, sino tambinla definicin de mens, pantallas y dilogos.

2)Herramientasointerfacesvisuales13 muy fciles de utilizar, que per-miten usar las BD siguiendo el estilo de dilogos con ventanas, iconos yratn, puesto de moda por las aplicaciones Windows. No slo son tilesa los usuarios no informticos, sino que facilitan mucho el trabajo a losusuarios informticos: permiten consultar y actualizar la BD, as comodefinirla y actualizar su definicin con mucha facilidad y claridad.

(12)Proliferaron hacia los aos ochenta.

(13)Comenzaron a proliferar en los aos noventa; cada vez son ms potentes y sofistica-dos, y se pueden integrar con otras herramientas como, por ejemplo, las herramientasCASE.

Tanto los 4GL como las herramientas visuales (con frecuencia unidas en unasola herramienta) traducen lo que hace el usuario a instrucciones SQL pordistintas vas:

En el caso de los 4GL, la traduccin se suele hacer mediante la compila-cin.

En el caso de las herramientas visuales, se efecta por medio del intrpretede SQL integrado en el SGBD.

Lenguajes declarativos yprocedimentales

El aprendizaje y la utilizacinde los lenguajes procedimen-tales acostumbran a ser msdifciles que los declarativos, ypor ello slo los utilizan usua-rios informticos. Con los pro-cedimentales se pueden escri-bir procesos ms eficientes quecon los declarativos.


Si queremos escribir un programa de aplicacin que trabaje con BD, segura-

mente querremos utilizar nuestro lenguaje habitual de programacin14. Sinembargo, generalmente estos lenguajes no tienen instrucciones para realizarel acceso a las BD. Entonces tenemos las dos opciones siguientes:

1) Las llamadasafunciones: en el mercado hay libreras de funciones especia-lizadas en BD (por ejemplo, las libreras ODBC y JDBC). Slo es preciso incluirllamadas a las funciones deseadas dentro del programa escrito con el lenguajehabitual. Las funciones sern las que se encargarn de enviar las instrucciones(generalmente en SQL) en tiempo de ejecucin al SGBD.

2) El lenguajehospedado: otra posibilidad consiste en incluir directamentelas instrucciones del lenguaje de BD en nuestro programa. Sin embargo, es-to exige utilizar un precompilador especializado que acepte en el lenguaje deprogramacin las instrucciones del lenguaje de BD. Entonces se dice que estelenguaje (casi siempre SQL) es el lenguaje hospedado o incorporado (embed-ded), y el lenguaje de programacin (C, C++, C#, CoboL, Java, etc.) es el len-guaje anfitrin (host).

(14)C, C++, C#, CoboL, Java, etc


7. Administracin de BD

Hay un tipo de usuario especial: el que realiza tareas de administraciny control de la BD. Una empresa o institucin que tenga SI construidosen torno a BD necesita que alguien lleve a cabo una serie de funcionescentralizadas de gestin y administracin, para asegurar que la explota-cin de la BD es la correcta. Este conjunto de funciones se conoce conel nombre de administracindeBD, y los usuarios que hacen este tipoespecial de trabajo se denominan administradores de BD (ABD).

Los ABD son los responsables del correcto funcionamiento de la BD y velanpara que siempre se mantenga til. Intervienen en situaciones problemticaso de emergencia, pero su responsabilidad fundamental es velar para que nose produzcan incidentes.

A continuacin damos una lista de tareas tpicas del ABD:

1) Mantenimiento, administracin y control de los esquemas. Comunicacinde los cambios a los usuarios.

2) Asegurar la mxima disponibilidad de los datos; por ejemplo, haciendo co-pias (backups), administrando diarios (journals o logs), reconstruyendo la BD,etc.

3) Resolucin de emergencias.

4) Vigilancia de la integridad y de la calidad de los datos.

5) Diseo fsico, estrategia de caminos de acceso y reestructuraciones.

6) Control del rendimiento y decisiones relativas a las modificaciones en losesquemas y/o en los parmetros del SGBD y del SO, para mejorarlo.

7) Normativa y asesoramiento a los programadores y a los usuarios finalessobre la utilizacin de la BD.

8) Control y administracin de la seguridad: autorizaciones, restricciones, etc.


La tarea del ABD no es sencilla

Los SGBD del mercado procuran reducir al mnimo el volumen de estas tareas, pero ensistemas muy grandes y crticos se llega a tener grupos de ABD con varias personas. Buenaparte del software que acompaa el SGBD est orientado a facilitar la gran diversidad detareas controladas por el ABD: monitores del rendimiento, monitores de la seguridad,verificadores de la consistencia entre ndices y datos, reorganizadores, gestores de lascopias de seguridad, etc. La mayora de estas herramientas tienen interfaces visuales parafacilitar la tarea del ABD.


Resumen

En este mdulo hemos hecho una introduccin a los conceptos fundamenta-les del mundo de las BD y de los SGBD. Hemos explicado la evolucin de losSGBD, que ha conducido de una estructura centralizada y poco flexible a unadistribuida y flexible, y de una utilizacin procedimental que requera muchosconocimientos a un uso declarativo y sencillo.

Hemos revisado los objetivosdelosSGBDactuales y algunos de los serviciosque nos dan para conseguirlos. Es especialmente importante el concepto detransaccin y la forma en que se utiliza para velar por la integridad de losdatos.

La arquitecturadetresniveles aporta una gran flexibilidad a los cambios,tanto a los fsicos como a los lgicos. Hemos visto cmo un SGBD puede fun-cionar utilizando los tres esquemas propios de esta arquitectura.

Hemos explicado que los componentesdeunmodelodeBD son las estruc-turas, las restricciones y las operaciones. Los diferentes modelos de BD se dife-rencian bsicamente por sus estructuras. Hemos hablado de los modelos msconocidos, especialmente del modelo relacional, que est basado en tablas.

Cada tipo de usuario del SGBD puede utilizar un lenguaje apropiado para sutrabajo. Unos usuarios con una tarea importante y difcil son los administra-doresdelasBD.


Ejercicios de autoevaluacin

1. Qu ventajas aportaron los SGBD relacionales con respecto a los prerrelacionales?

2. De las siguientes afirmaciones, decid cules son ciertas y cules son falsas:a) El modelo ER es ms conocido como modelo relacional.b) Los SGBD no permiten la redundancia.c) El DML es un lenguaje declarativo.d) El DDL es un lenguaje pensado para escribir programas de consulta y actualizacin de BD.e) Cuando un programa quiere acceder a unos datos mediante un ndice, lo debe decir alSGBD.


Solucionario

1. Los SGBD relacionales aportaron una programacin ms sencilla: los lenguajes son mssencillos y no dependen tanto de las caractersticas fsicas de la BD. Se da ms flexibilidada los cambios (ms independencia fsica de los datos). El programador se debe preocuparmucho menos de las cuestiones de rendimiento, pues de ello ya se ocupa el SGBD. Incluyenlenguajes declarativos de consulta para usuarios no informticos.

2.a) Falsa, b) Falsa, c) Falsa, d) Falsa, e) Falsa.


Glosario

administrador de BD m Tipo de usuario especial que realiza funciones de administraciny control de la BD, que aseguran que la explotacin de la BD es correcta.

base de datos f Conjunto estructurado de datos que representa entidades y sus interrela-ciones. La representacin ser nica e integrada, a pesar de que debe permitir diversas utili-zaciones.

BD Ved: base de datos.

cliente/servidor m Tecnologa habitual para distribuir datos. La idea es que dos procesosdiferentes, que se pueden ejecutar en un mismo sistema o en sistemas separados, actande modo que uno acta de cliente o peticionario de un servicio y el otro, como servidor.Un proceso cliente puede pedir servicios a distintos servidores. Un servidor puede recibirpeticiones de muchos clientes. En general, un proceso A que acta como cliente pidiendoun servicio a otro proceso puede hacer tambin de servidor de un servicio que le pida otroproceso .

C/S m Ved: cliente/servidor.

data definition language mLenguaje especializado en la escritura de esquemas; es decir,en la descripcin de BD.Sigla: DDL

data manipulation language mLenguaje especializado en la utilizacin de BD (consul-tas y mantenimiento).Sigla: DDL

DDL Ved: data definition language.

DML Ved: data manipulation language.

esquema m Descripcin o definicin de la BD. Esta descripcin est separada de los pro-gramas y es utilizada por el SGBD para saber cmo es la BD con la que debe trabajar. La arqui-tectura ANSI/SPARC recomienda tres niveles de esquemas: el externo (visin de los usuarios),el conceptual (visin global) y el fsico (descripcin de caractersticas fsicas). Pero los SGBDhabitualmente no acostumbran a tener tres niveles de esquemas, lo tienen todo mezcladoen un nico esquema.

SGBD Ved: sistema de gestin de BD..

sistema de gestin de BD mque gestiona y controla BD. Sus principales funciones sonfacilitar la utilizacin de la BD a muchos usuarios simultneos y de tipos diferentes, inde-pendizar al usuario del mundo fsico y mantener la integridad de los datos.sigla: SGBD

SQL Ved: structured query language..

structured query language m Lenguaje especializado en la descripcin (DDL) y la utili-zacin (DML) de BD relacionales. Creado por IBM al final de los aos setenta y estandarizadopor ANSI-ISO en 1985 (el ltimo estndar de SQL es de 2008). En la actualidad lo utilizanprcticamente todos los SGBD del mercado. SQL

transaccin f Conjunto de operaciones (de BD) que queremos que se ejecuten como untodo (todas o ninguna) y de forma aislada (sin interferencias) de otros conjuntos de opera-ciones que se ejecuten concurrentemente.


Bibliografa

Bibliografa bsica

Date, C.J. (2001). Introduccin a los sistemas de bases de datos (7. ed.). Prentice Hall.

Silberschatz, A; Korth, H.F; Sudarshan, S. (2006). Fundamentos de bases de datos (5.ed.). Madrid: McGraw-Hill.

La introduccin de este libro es similar a la que hemos hecho aqu.

Ullman, J. D.; Widom, J. (2008). A fist course in database system (3. ed). Prentice Hall.

Bibliografa complementaria

Para actualizar vuestra visin global de los SGBD del mercado, podis consultar en Internet laspginas de diferentes SGBD, por ejemplo, Oracle, DB2, Informix, SQL Server, Sybase, MySQLo PostgreSQL.

Introduccin a las bases de datosIntroduccinObjetivosndice1. Concepto y origen de las BD y de los SGBD2. Evolucin de los SGBD2.1. Los aos sesenta y setenta: sistemas centralizados2.2. Los aos ochenta: SGBD relacionales2.3. Los aos noventa: distribucin, C/S y 4GL2.4. El nueno milenio

3. Objetivos y servicios de los SGBD3.1. Consultas no predefinidas y complejas3.2. Flexibilidad e independencia3.3. Problemas de la redundancia3.4. Integridad de los datos3.5. Concurrencia de usuarios3.6. Seguridad

4. Arquitectura de los SGBD4.1. Esquemas y niveles4.2. Independencia de los datos4.3. Flujo de datos y de control

5. Modelos de BD6. Lenguajes y usuarios7. Administracin de BDResumenEjercicios de autoevaluacinSolucionarioGlosarioBibliografa

Documents

Mod2 Bases de datos