Está en la página 1de 32

BASE DE DATOS

Temario
1. Concepto de BD.

2. Evolucin de los SGBD.

3. Objetivos y servicios de los SGBD.

4. Arquitectura de los SGBD.

5. Modelos de BD.


1. Concepto de BD.
Una base de datos de un Sistema de Informacin es la
representacin integrada de los conjuntos de entidades instancia
correspondiente a las diferentes entidades tipo del SI y de sus
interrelaciones. Esta representacin informtica (o conjunto
estructurado de datos) debe poder ser utilizada de forma
compartida por muchos usuarios de distintos tipos.
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.

2. Evolucin de los SGBD
En los aos sesenta y setenta eran sistemas totalmente
centralizados. Aparecen los terminales de teclado, en donde se
empiezan a construir grandes aplicaciones on-line transaccionales
(OLTP). Los SGBD estaban ntimamente ligados al software de
comunicaciones y de gestin de transacciones. 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.
En los aos ochenta surgen los SGBD relacionales supone un
avance importante para facilitar la programacin de aplicaciones
con BD y para conseguir que los programas sean independientes
de los aspectos fsicos de la BD.
En el ao 1986 surge el lenguaje SQL que produjo una autntica
explosin de los SGBD relacionales.


2. Evolucin de los SGBD
En los aos noventa surgen las BD distribuidas en donde eran
varias BD intercomunicadas por una red y con esto se lograba que
pareciera que haba una sola BD.
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) La disponibilidad de un sistema con una BD distribuida puede
ser ms alta, porque si queda fuera de servicio uno de los
sistemas, los dems 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. Evolucin de los SGBD
2) 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.
La tecnologa que se utiliza habitualmente para distribuir datos es la
que se conoce como entorno (o arquitectura) cliente/servidor (C/S).
Todos los SGBD relacionales del mercado han sido adaptados a
este entorno.

2. Evolucin de los SGBD
La idea del C/S es sencilla. Dos procesos diferentes, que se
ejecutan en un mismo sistema o en sistemas separados, actan de
forma que uno tiene el papel de cliente o peticionario de un
servicio, y el otro el de servidor o proveedor del servicio.

2. Evolucin de los SGBD
El xito de las BD, incluso en sistemas personales, ha llevado a la
aparicin de la cuarta generacin de lenguajes (4GL), que son muy
fciles y potentes, especializados en el desarrollo de aplicaciones
fundamentadas en BD.
Las tendencias actuales de los SGBD relacionales estn en plena
transformacin para adaptarse a tres tecnologas fuertemente
relacionadas: la multimedia, la de orientacin a objetos (OO) e
Internet y la web.
Durante estos ltimos aos se ha empezado a extender un tipo de
aplicacin de las BD denominado Data Warehouse.
3. Objetivos y servicios de los
SGBD
Consultas no predefinidas y complejas.
El objetivo fundamental de los SGBD es permitir que los usuarios
hagan consultas no predefinidas y complejas. El SGBD tendr que
responder inmediatamente sin que estas consultas estn
preestablecidas; es decir, sin que se tenga que escribir, compilar y
ejecutar un programa especfico para cada consulta.
El usuario debe formular la consulta con un lenguaje sencillo, que
el sistema debe interpretar directamente.
La solucin estndar para alcanzar las consultas no predefinidas y
complejas es el lenguaje SQL.
Flexibilidad e independencia
La 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.

3. Objetivos y servicios de los
SGBD
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.
Para conseguir esta independencia, los usuarios deben poder
desconocer las caractersticas fsicas de la BD con que trabajan, ni
conocer qu SO se utiliza, qu ndices hay, la compresin o no
compresin de datos, etc. Esto se llama independencia fsica.
Tambin queremos que los usuarios no tengan que hacer cambios
cuando se modifica la descripcin lgica o el esquema de la BD.
Esto se denomina independencia lgica de los datos, y da
flexibilidad y elasticidad a los cambios lgicos.

3. Objetivos y servicios de los
SGBD
Problemas de la redundancia.
Uno de los objetivos de los SGBD es facilitar la eliminacin de la
redundancia ya que el 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.
Para evitar esto conviene hacer que un dato slo figure una vez en la
BD. Sin embargo, esto no siempre ser cierto*.
El SGBD debe permitir que el diseador defina datos redundantes,
pero entonces tendra que ser el mismo SGBD el que hiciese
automticamente la actualizacin de los datos en todos los lugares
donde estuviesen repetidos.
La duplicacin de datos es el tipo de redundancia ms habitual, pero
tambin tenemos redundancia cuando guardamos en la BD datos
derivados (o calculados) y para ello es necesario que el mismo SGBD
haga automticamente el calculo cuando se modifican los datos.




3. Objetivos y servicios de los
SGBD
Integridad de los datos.
Nos 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, rotura de disco,
transacciones incompletas por corte de luz, etc.
Para esto podemos darle al SGBD otras reglas de integridad o
restricciones para que asegure que los programas las cumplen
cuando efectan las actualizaciones.
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.




3. Objetivos y servicios de los
SGBD
Los procesos de restauracin (restore o recovery) de los que todo SGBD
dispone pueden reconstruir la BD y darle el estado consistente y correcto
anterior al incidente. Esto se acostumbra a hacer gracias a la obtencin
de copias peridicas de los datos (back-up) y mediante el mantenimiento
continuo de un diario (log) donde el SGBD va registrando todas las
escrituras que se hacen en la BD.
Concurrencia de usuarios
Un objetivo fundamental de los SGBD es permitir que varios usuarios
puedan acceder concurrentemente a la misma BD.
Cuando los accesos concurrentes son todos de lectura, el problema que
se produce es simplemente de rendimiento.
Cuando un usuario o ms de uno estn actualizando los datos, se
pueden producir problemas de interferencia que tengan como
consecuencia la obtencin de datos errneos y la prdida de integridad
de la BD.

3. Objetivos y servicios de los
SGBD
Para tratar los accesos concurrentes, los SGBD utilizan el concepto
de transaccin de BD*, concepto de especial utilidad para todo
aquello que hace referencia a la integridad de los datos.
Entre transacciones que se ejecutan concurrentemente se pueden
producir problemas de interferencia que hagan obtener resultados
errneos o que comporten la prdida de la integridad de los datos.
Para solucionar este problema se debe conseguir que las
transacciones se ejecuten como si estuviesen aisladas, los SGBD
utilizan distintas tcnicas. La ms conocida es el bloqueo (lock). El
bloqueo de unos datos en beneficio de una transaccin consiste en
poner limitaciones a los accesos que las dems transacciones
podrn hacer a estos datos.
Cuando se provocan bloqueos, se producen esperas, retenciones y,
en consecuencia, el sistema es ms lento. Los SGBD se esfuerzan
en minimizar estos efectos negativos.


3. Objetivos y servicios de los
SGBD
Seguridad.
Los SGBD permiten definir autorizaciones o derechos de acceso a
diferentes niveles: al nivel global de toda la BD, al nivel entidad y al nivel
atributo.
Nos permite almacenar informacin con tcnicas de encriptacin.
Prcticamente todos los SGBD del mercado dan una gran variedad de
herramientas para la vigilancia y la administracin de la seguridad.


4. Arquitectura de los SGBD
Esquemas y niveles
Para trabajar con nuestras BD, los SGBD necesitan conocer su
estructura (qu entidades tipo habr, qu atributos tendrn, etc.).
Los SGBD necesitan que les demos una descripcin o definicin de la
BD. Esta descripcin recibe el nombre de esquema de la BD. El
esquema de la BD es un elemento fundamental de la arquitectura de un
SGBD que permite independizar el SGBD de la BD; de este modo, se
puede cambiar el diseo de la BD sin tener que hacer ningn cambio en
el SGBD.
El comit conocido como ANSI/SPARC recomend que la arquitectura
de los SGBD previese tres niveles de descripcin de la BD:




4. Arquitectura de los SGBD
a) En el nivel externo se sitan las diferentes visiones lgicas que los
procesos usuarios (programas de aplicacin y usuarios directos) tendrn
de las partes de la BD que utilizarn. Estas visiones se denominan
esquemas externos.
b) En el nivel conceptual hay una sola descripcin lgica bsica, nica y
global, que denominamos esquema conceptual, y que sirve de referencia
para el resto de los esquemas.
c) En el nivel fsico hay una sola descripcin fsica, que denominamos
esquema interno.




4. Arquitectura de los SGBD




4. Arquitectura de los SGBD
En los SGBD relacionales no se separan de forma clara tres niveles de
descripcin. Se habla de un solo esquema, pero en su interior se
incluyen descripciones de los tres niveles.
Independencia de los datos
Ahora veremos cmo la arquitectura de tres niveles nos proporciona los
dos tipos de independencia de los datos: la fsica y la lgica.
Habr independencia fsica cuando los cambios en el esquema interno
no afecten al esquema conceptual ni a los esquemas externos. O sea si
cambiamos unos datos de un soporte a otro, o los cambiamos de lugar
dentro de un soporte, o si cambiamos el mtodo de acceso a unos
registros determinados, el formato o la codificacin, etc. Ninguno de
estos casos debera afectar al mundo exterior, sino slo a la BD fsica, el
esquema interno, etc.

4. Arquitectura de los SGBD
Hay independencia lgica cuando los usuarios no se ven afectados por
los cambios en el nivel lgico.
Se pueden dar dos tipos de cambios:
1) En el esquema conceptual. Un cambio de este tipo no afectar a los
esquemas externos que no hagan referencia a las entidades o a los
atributos modificados.
2) En los esquemas externos. Efectuar cambios en un esquema externo
afectar a los usuarios que utilicen los elementos modificados. Sin
embargo, no debera afectar a los dems usuarios ni al esquema
conceptual, y tampoco, en consecuencia, al esquema interno y a la BD
fsica.

4. Arquitectura de los SGBD
Flujo de datos y de control
El SGBD, con la ayuda del SO, lee pginas (bloques) de los soportes
donde est almacenada la BD fsica, y las lleva a un rea de buffers o
memorias cach en la memoria principal. El SGBD pasa registros desde
los buffers hacia el rea de trabajo del mismo programa.
Supongamos que la consulta pide los datos de un alumno que tiene un
determinado DNI. Por lo tanto, la respuesta que el programa obtendr
ser un solo registro y lo recibir dentro de un rea de trabajo propia.


4. Arquitectura de los SGBD
El proceso que se sigue es el siguiente:


4. Arquitectura de los SGBD
a) Empieza con una llamada (1) del programa al SGBD, en la que se le
enva la operacin de consulta. El SGBD debe verificar que la sintaxis de
la operacin recibida 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 esquema externo 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. El programa
usuario no dice nada respecto a cmo se debe hacer fsicamente la
consulta. Es el SGBD el que lo debe determinar. Casi siempre hay varias
formas y diferentes caminos para responder a una consulta.
Supongamos que ha elegido aplicar un hashing al valor del DNI, que es
el parmetro de la consulta, y el resultado es la direccin de la pgina
donde se encuentra (entre muchos otros) el registro del alumno buscado.

4. Arquitectura de los SGBD
c) Cuando ya se sabe cul es la pgina, el SGBD comprobar (4) si por
suerte esta pgina ya se encuentra en aquel momento en el rea de los
buffers (tal vez como 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). Si ya est, se ahorra el acceso a disco.
d) Ahora, la pgina deseada ya est en la memoria principal. El SGBD
extrae, de entre los distintos registros que la pgina puede contener, el
registro buscado, e interpreta la codificacin y el resultado segn lo que
diga el esquema interno.
e) El SGBD aplica a los datos las eventuales transformaciones lgicas
que implica el esquema externo (tal vez cortando la direccin por la
derecha) y las lleva al rea de trabajo del programa (6).
f) A continuacin, el SGBD retorna el control al programa (7) y da por
terminada la ejecucin de la consulta.

5. Modelos de BD
Una BD se puede considerar un modelo de la realidad. El componente
fundamental utilizado para modelar en un SGBD relacional son las
tablas.
El conjunto de componentes o herramientas conceptuales que un SGBD
proporciona para modelar recibe el nombre de modelo de BD. Los cuatro
modelos de BD ms utilizados en los SI son el modelo jerrquico, el
modelo en red, el modelo relacional, y el modelo relacional con objetos.
Todo modelo de BD nos proporciona tres tipos de herramientas:
a) Estructuras de datos con las que se puede construir la BD: tablas,
rboles, etc.
b) Diferentes tipos de restricciones (o reglas) de integridad que el SGBD
tendr que hacer cumplir a los datos: dominios, claves, etc.
c) Una serie de operaciones para trabajar con los datos.


5. Modelos de BD


5. Modelos de BD
De los cuatro modelos de BD que hemos citado, el que apareci primero,
a principios de los aos sesenta, fue el modelo jerrquico. Sus
estructuras son registros interrelacionados en forma de rboles.
En los setenta surgieron SGBD basados en un modelo en red. Como en
el modelo jerrquico, hay registros e interrelaciones, pero un registro ya
no est limitado a ser hijo de un solo registro tipo.
En los aos ochenta apareci una gran cantidad de SGBD basados en el
modelo relacional y prcticamente todos utilizaban como lenguaje nativo
el SQL. El modelo relacional se basa en el concepto matemtico de
relacin, que aqu podemos considerar de momento equivalente al
trmino tabla.
Estos ltimos aos se est extendiendo el modelo de BD relacional con
objetos. Se trata de ampliar el modelo relacional, aadindole la
posibilidad de que los tipos de datos sean tipos abstractos de datos.
5. Modelos de BD (Jerrquico - Ej.)
Un sistema de reservaciones de una lnea area nacional puede ser
representado mediante una organizacin jerrquica. El nodo padre es la
ciudad de salida (Caracas), este nodo puede tener nodos hijos
representando las ciudades destino. Uno de estos nodos hijos, Maracay
por ejemplo, tiene a su vez nodos hijos, que son el nmero de vuelo. El
nmero de vuelo tendr tambin nodos hijos, que son los pasajeros.
Entre las limitaciones de este tipo de base de datos se tiene que al borrar
un nodo padre, desaparecen tambin sus nodos subordinados. Slo
podr aadirse un nodo hijo, si existe el nodo padre. Pero lo ms
significativo es la rigidez de su estructura: slo un padre por hijo y
ausencia de relaciones entre los nodos hijos.
5. Modelos de BD (Red - Ejemplo)
Los vendedores destacados para distribuir determinados productos en
algunas ciudades pueden ilustrar este modelo. Cada producto puede ser
distribuido por ms de un vendedor, as mismo cada vendedor puede
encargarse de diferentes ciudades.
Usuarios
Usuarios informticos expertos

Usuarios finales no informticos ocasionales que hacen
consultas. Estos usuarios necesitarn un lenguaje muy
sencillo que d un rendimiento muy bajo en respuesta.

Puede haber usuarios no informticos, dedicados o
especializados. Son usuarios que trabajan cotidianamente
con la BD (Ej. Carga masiva de datos).

Lenguajes
DDL Data Definition Languaje



DML Data Manipulation Languaje

FIN