Bases De
Datos Distribuidas
Unidad 1
Fundamentos de bases de datos distribuidas.
1.1 Conceptos
básicos.
Historia
La necesidad de almacenar datos de
forma masiva dio paso a la creación de los sistemas de bases de datos. En 1970
Edgar Frank Codd escribió un artículo con nombre: "A Relational Model of
Data for Large Shared Data Banks" ("Un modelo relacional para grandes
bancos de datos compartidos"). Con este artículo y otras publicaciones,
definió el modelo de bases de datos relacionales y reglas para poder evaluar un
administrador de bases de datos relacionales. El cuadrado.
Inicio de las bases de datos distribuidas
Originalmente se almacenaba la
información de manera centralizada, pero con el paso del tiempo las necesidades
aumentaron y esto produjo ciertos inconvenientes que no era posible
solucionarlos o volverlos eficientes de la forma centralizada. Estos problemas
impulsaron la creación de almacenamiento distribuido, los cuales hoy en día
proveen características indispensables en el manejo de información; es decir,
la combinación de las redes de comunicación y las bases de datos.
Evolución
Hay varios factores que han hecho que las bases de datos evolucionen a bases de datos distribuidas. En el mundo de los negocios se ha dado una globalización y a la vez las operaciones de las empresas son cada vez más descentralizadas geográficamente. También el poder de las computadoras personales aumentó y el costo de los Mainframes ya no tenía sentido. Además la necesidad de compartir datos ha hecho que crezca el mercado de las bases de datos distribuidas.
Una base de datos distribuida
(BDD) es un conjunto de múltiples bases de datos lógicamente relacionadas las
cuales se encuentran distribuidas en diferentes espacios lógicos (pej. un
servidor corriendo 2 máquinas virtuales) e interconectados por una red de
comunicaciones. Dichas BDD tienen la capacidad de realizar procesamiento
autónomo, esto permite realizar operaciones locales o distribuidas. Un sistema
de Bases de Datos Distribuida (SBDD) es un sistema en el cual múltiples sitios
de bases de datos están ligados por un sistema de comunicaciones de tal forma
que, un usuario en cualquier sitio puede acceder los datos en cualquier parte
de la red exactamente como si estos fueran accedidos de forma local.
Un sistema distribuido de bases de
datos se almacenan en varias computadoras. Los principales factores que
distinguen un SBDD de un sistema centralizado son los siguientes:
- Hay múltiples computadores, llamados sitios o nodos.
- Estos sitios deben de estar comunicados por medio de algún tipo de red de comunicaciones para transmitir datos y órdenes entre los sitios.
1.2
Objetivos de las B.D.D.
1.2 Disciplinas
de estudio.
En la medida en
que los sistemas computacionales de procesamiento de datos se hicieron más importantes,
las empresas comenzaron a reconocer que la información era un recurso
corporativo de valor considerable. Estas percibieron más y más que los datos
necesarios para contestar numerosas preguntas estaban disponibles en sus
archivos de procesamiento de datos. Como consecuencia, comenzaron a presionar a
los sistemas de información para la gestión en cuanto a la utilización de la
potencia del computador para producir información a partir de los datos corporativos.
Esto inició la demanda de los sistemas de bases de datos, los que garantizarían
más efectivamente el acceso a los datos y su manipulación.
En años
recientes han proliferado los computadores personales en los puestos de
trabajo, por lo que se han desarrollado las redes de computadores, permitiendo
a los usuarios de estos computadores compartir recursos. Un computador, que
funciona como servidor de una red, garantiza el acceso a la base de datos desde
las estaciones de trabajo en estos puestos, permitiendo una división poderosa y
eficiente de la tarea: El servidor recupera los datos, los que la máquina
cliente solicitante procesa y presenta en pantalla para su manipulación por
parte del usuario final. Las redes de computadores en ambiente cliente/servidor
han desarrollado un grado alto de sofisticación y se encuentran cada vez con
más frecuencia en las empresas comerciales.
Desde el punto
de vista conceptual, un sistema de base de datos en una organización grande
está formado por el hardware, el software, los datos y las personas. La
configuración del hardware comprende uno o más computadores, unidades de disco,
terminales, impresoras, unidades de cinta magnética, conexiones de red y otros
dispositivos físicos. El software incluye un sistema de gestión de bases de
datos 2 (SGBD) y los programas de aplicación
utilizan el SGBD para tener acceso y manipular la base de datos. Los datos, que
representan los hechos importantes para la organización, radican físicamente en
el disco, pero se estructuran lógicamente de forma que se logre un acceso fácil
y eficiente
1.3
Arquitectura de bases de datos distribuidas.
El
estándar ANSI/SPARC.
El objetivo
principal de la arquitectura ANSI/SPARC es definir un SGBD con el máximo grado
de independen cia, separando las aplicaciones de usuario y la base de datos
física. Para ello se utilizan tres niveles de abstracción conocidos como
interno, conceptual y externo.
1. El nivel
interno es el más
cercano a la máquina. Es una representación a bajo nivel de la BD en la que se
define la forma en la que los datos se almacenan físicamente en la máquina. Se
definen características como los dispositivos en donde se almacenan los datos,
el espacio que se reserva, las estrategias de acceso, la creación de ficheros
de índices, etc. Es dependiente de la máquina en que se vaya a instalar la BD,
del sistema operativo que exista, etc.
2. El nivel conceptual tiene un esquema conceptual, que
describe la estructura de los datos que van a ser almacenados en la base de
datos. El esquema conceptual esconde los detalles del almacenamiento físico y
se concentra en describir entidades, tipos de datos, relaciones, operaciones de
usuario y restricciones.
3. El nivel
externo o nivel de
vista incluye varios
esquemas externos o vistas de usuario. Cada esquema externo describe la parte
de la base de datos en la que está interesado un grupo de usuarios en
particular y esconde el resto de la base de datos para esos usuarios. La
información se manipula sin saber cómo está almacenada internamente (nivel interno)
ni su organización nivel conceptual).
Existirán muchas
vistas externas distintas, cada una formada por una representación más o menos abstracta
(registros y campos lógicos) de alguna parte de la base de datos total, y
existirá sólo una vista conceptual formada por una representación igualmente
abstracta de la base de datos en su totalidad (hay que recordar que a la
mayoría de los usuarios no les interesará toda la base de datos, sino sólo una
porción limitada de ella). De manera similar, habrá sólo una vista interna, la
cual representará a toda la base de datos tal como está almacenada físicamente.
El
Nivel Externo
El nivel externo
es el más cercano a los usuarios, es decir, es el que se ocupa de la forma en
la que los usuarios perciben los datos. El nivel externo es del usuario
individual. Estos usuarios pueden ser o bien programadores de aplicaciones o
usuarios finales con conocimientos muy variables de informática. El administrador
de la base de datos es un caso especial (también debe interesarse por los demás
niveles de la arquitectura).
Cada usuario
dispone de un lenguaje:
En el caso del
programador de aplicaciones, dicho lenguaje será o bien un lenguaje de
programación convencional, o bien un lenguaje de cuarta generación (4GL)
específico para el sistema en cuestión.
Para el usuario
final será o bien un lenguaje de consulta, o algún lenguaje de aplicación
especial, quizá manejado mediante formas o menús, adaptado a los requerimientos
de ese usuario y apoyado por algún programa de aplicación en línea (cuya
función es servir a un usuario final que tiene acceso a la base de datos desde
una terminal en línea).
El aspecto
importante de todos estos lenguajes es que deben incluir un sublenguaje de
datos, es decir, un subconjunto del lenguaje total que se ocupe de manera
específica de los objetos y operaciones de la base de datos. Se dice que el
sublenguaje de datos (DSL ‘data sublanguage’) está embebido (o inmerso) dentro
del lenguaje anfitrión correspondiente. Este último se encarga de varios
aspectos no relacionados con la base de datos, como por ejemplo variables
locales (temporales), operaciones de cálculo, lógica condicional, etc. Un
sistema dado puede permitir el empleo de varios lenguajes anfitriones y varios sublenguajes
de datos. Un sublenguaje de datos en particular cuyo uso es posible en casi
todos los sistemas relacionales actuales es el lenguaje SQL.
En principio,
cualquier sublenguaje de datos es en realidad una combinación de por lo menos
dos lenguajes subordinados: un lenguaje de definición de datos (DDL ‘data
definition language’), con el cual es posible definir o declarar los objetos de
la base de datos, y un lenguaje de manipulación de datos (DML, ‘data
manipulation language’) con el que es posible manipular o procesar dichos
objetos.
Como ya se ha
dicho, al usuario individual (en general), sólo le interesará una porción de la
base de datos total; por añadidura, la forma como ese usuario percibe dicha
porción casi siempre será un tanto abstracta comparada con el almacenamiento
físico de los datos. El término ANSI/SPARC para la vista individual de un
usuario es vista externa. Así, una vista externa es el contenido de la base de
datos tal como lo percibe algún usuario determinado (es decir, para ese usuario
la vista externa es la base de datos). Por ejemplo, un usuario del departamento
de personal podría contemplar la base de datos como un conjunto de ocurrencias
de registros de departamento unido a un conjunto de ocurrencias de registros de
proveedor y de parte vistas por los usuarios del departamento de compras).
Toda vista
externa se define mediante un esquema externo, que consiste básicamente en
definiciones de cada uno de los diversos tipos de registros externos en esa
vista externa. El esquema externo se escribe con la porción DDL del sublenguaje
de datos del usuario (por ello se le denomina a ese DDL en ocasiones como DDL
externo). Por ejemplo, el tipo de registro externo de empleado puede definirse
como un campo de número de empleado de seis caracteres unido a un campo de
salario de cinco dígitos, etc. Además, debe haber una definición de la
correspondencia entre el esquema externo y el esquema conceptual subyacente.
El
Nivel Conceptual
El nivel
conceptual es un nivel de mediación entre el nivel interno y externo. La vista
conceptual es una representación de toda la información contenida en la base de
datos, también (como en el caso de una vista externa) en una forma un tanto
abstracta si se compara con el almacenamiento físico de los datos.
Además, puede
ser muy diferente de la forma como percibe los datos cualquier usuario
individual. A grandes rasgos, la vista conceptual debe ser un panorama de los
datos “tal como son”, y no como por fuerza los perciben los usuarios debido a
las limitaciones del lenguaje o el equipo específicos utilizados, por ejemplo.
La vista
conceptual se compone de varias ocurrencias de varios tipos de registro
conceptual. Por ejemplo, puede estar formada por un conjunto de ocurrencias de
registros de departamento unido un conjunto de ocurrencias de registro de
empleado y a un conjunto de ocurrencias de registros de proveedor y a un
conjunto de ocurrencia de registros de parte... Un registro conceptual no es
por necesidad idéntico a un registro externo, por un lado, ni a un registro
almacenado, por el otro.
La vista conceptual
se define mediante un esquema conceptual, el cual incluye definiciones de cada uno
de los tipos de registro conceptual. El esquema conceptual se escribe
utilizando otro lenguaje de definición de datos, el DDL conceptual. Si ha de
lograrse la independencia de los datos, esas definiciones en DDL conceptual no
deberán implicar consideraciones de estructura de almacenamiento o de técnica
de acceso. Si el esquema conceptual se hace en verdad independiente de los
datos de esta manera, entonces los esquemas externos, definidos en términos del
esquema conceptual, serán por fuerza también independientes de los datos.
Así pues, la
vista conceptual es una vista del contenido total de la base de datos, y el
esquema conceptual es una definición de esa vista. No obstante, sería engañoso
sugerir que el esquema conceptual es sólo un conjunto de definiciones similar a
las sencillas definiciones de registros encontradas por ejemplo en un programa
en Cobol. Es de esperar que las definiciones en el esquema conceptual incluyan
muchas características más, como son las verificaciones de seguridad y de
integridad. Algunos expertos podrían llegar a sugerir que el objetivo
primordial del esquema conceptual es describir la empresa en su totalidad (no sólo
los datos en sí, sino también la forma como se utilizan: cómo fluyen de un
punto a otro dentro de la empresa, qué se hace con ellos en cada punto, qué
controles de auditoría o de otro tipo deben aplicarse en cada punto, etc. Debe
hacerse hincapié en que en ningún sistema actual es posible mantener realmente
un nivel conceptual que se aproxime siquiera a ese grado de complejidad; en
casi todos los sistemas existentes el esquema conceptual no es mucho más que
una simple unión de todos los esquemas externos individuales, con la posible
adición de algunas verificaciones sencillas de integridad y seguridad. Con
todo, parece evidente que los sistemas del futuro llegarán a mantener niveles
conceptuales mucho más complejos.
El
Nivel Interno
El tercer nivel
de la arquitectura es el nivel interno. La vista interna es una representación
de bajo nivel de toda la base de datos; se compone de varias ocurrencias de
varios tipos de registro interno. Este último término es el que utiliza
ANSI/SPARC para referirse a la construcción que hemos estado llamando registro
almacenado. La vista interna, por tanto, todavía está a un paso del nivel
físico, ya que no manejo registros físicos (llamados también páginas o
bloques), ni otras consideraciones específicas de los dispositivos como son los
tamaños de cilindros o de pistas.
La vista interna
se define mediante el esquema interno, el cual no sólo define los diversos
tipos de registros almacenados sino también especifica que índices hay, cómo se
representan los campos almacenados, en qué secuencia física se encuentran los
registros almacenados, etc. El esquema interno se escribe con otro lenguaje más
de definición de datos, el DDL interno.
En algunas
situaciones excepcionales podría permitirse a los programas de aplicación
operar directamente en el nivel interno en vez de hacerlo en el nivel externo. Esta
práctica no es recomendable ya que representa un riesgo para la seguridad (ya
que pasan por alto las verificaciones de seguridad) y para la integridad (hace
lo mismo), y el programa será en extremo dependiente de los datos; sin embargo,
en ciertos casos puede ser la única forma de obtener la función o desempeño
deseados, del mismo modo como el usuario de un lenguaje de programación de alto
nivel puede verse obligado en ocasiones a descender al lenguaje ensamblador
para satisfacer ciertos objetivos.
Correspondencias,
asociaciones o ligaduras (mappings) Para describir un mismo grupo de datos, un sistema
puede gestionar varios niveles de esquemas, para lo cual el DBMS debe poder
garantizar la transferencia de los datos desde el formato correspondiente de un
nivel al formato correspondiente a otro nivel; este proceso se denomina
transformación de datos o mapping.
Hay dos niveles
de correspondencia en la arquitectura ANSI/SPARC: uno entre los niveles externo
y conceptual del sistema, y otro entre los niveles conceptual e interno. La
correspondencia conceptual/interna es la que existe entre las vista conceptual
y la base de datos almacenada; especifica cómo se representan los registros y
campos conceptuales en el nivel interno. Si se modifica la estructura de la
base de datos almacenada (es decir, si se altera la definición de la estructura
de almacenamiento), la correspondencia conceptual/interna deberá modificarse
también de acuerdo con ello, para que no varíe el esquema conceptual (el
administrador de la base de datos se debe encargar de controlar tales
modificaciones). Dicho de otra manera, los efectos de las alteraciones deberán
aislarse por debajo del nivel conceptual, a fin de conservar la independencia
de los datos.
La
correspondencia externa/conceptual es la que existe entre una determinada vista
externa y la vista conceptual. Las diferencias que pueden existir entre estos
dos niveles son similares a las que pueden existir entre la vista conceptual y
la base de datos almacenada. Por ejemplo, los campos pueden tener distintos
tipos de datos, los nombres de los campos y los registros pueden diferir,
pueden combinarse varios campos conceptuales para formar un solo campo externo
(virtual), etc. Puede existir cualquier cantidad de vistas externas; cualquier
número de usuarios puede compartir una determinada vista externa.
Algunos sistemas
permiten expresar la definición de una vista externa en términos de otras (de
hecho, a través
de una correspondencia externa/externa), en vez de requerir siempre una
definición explícita de la correspondencia respecto al nivel conceptual, cosa
que resulta útil si existe una relación muy grande entre varias vistas
externas. Los sistemas relacionales en particular casi siempre permiten hacer
esto.
El
sistema de gestión de bases de datos.
Un Sistema de
Gestión de Bases de Datos (SGBD) es el conjunto de programas que permiten
definir,
manipular y utilizar la información que contienen las bases de datos, realizar
todas las tareas de administración necesarias para mantenerlas operativas,
mantener su integridad, confidencialidad y seguridad. Una BD nunca se accede o
manipula directamente sino a través del SGBD. Se puede considerar al SGBD como
el interfaz entre el usuario y la BD.
El
funcionamiento del SGBD está muy interrelacionado con el del Sistema Operativo,
especialmente con el sistema de comunicaciones. El SGBD utilizará las
facilidades del sistema de comunicaciones para recibir las peticiones del
usuario (que puede estar utilizando un terminal físicamente remoto) y para devolverle
los resultados. Conceptualmente, lo que ocurre es lo siguiente:
1. Un usuario
hace una petición de acceso, usando algún lenguaje en particular (normalmente
SQL).
2. El SGBD
intercepta esa petición y la analiza.
3. El SGBD
inspecciona el esquema externo de ese usuario, la correspondencia
externa/conceptual, el esquema conceptual, la correspondencia
conceptual/interna, y la definición de la estructura de almacenamiento.
4. El SGBD
ejecuta las operaciones necesarias en la base de datos almacenada.
El SGBD tiene
las siguientes funciones:
Definición
de datos
El SGBD debe ser
capaz de aceptar definiciones de datos (esquemas externos, el esquema
conceptual, el
esquema interno, y todas las correspondencias asociadas) en versión fuente y
convertirlas en la versión objeto apropiada. Dicho de otro modo, el SGBD debe
incluir componentes procesadores de lenguajes para cada uno de los diversos
lenguajes de definición de datos (DDL). El SGBD también debe entender las
definiciones en DDL, en el sentido en que, por ejemplo, entiende que los
registros externos ‘Empleado’ contienen un campo ‘Salario’; y debe poder
utilizar estos conocimientos para interpretar y responder las solicitudes de
los usuarios (por ejemplo una consulta de todos los empleados cuyo salario sea inferior
a 100.000 pts).
Manipulación
de datos
El SGBD debe ser
capaz de atender las solicitudes del usuario para extraer, y quizá actualizar,
datos que ya existen en la base de datos, o para agregar en ella datos nuevos.
Dicho de otro modo, el SGBD debe incluir un componente procesador de lenguaje
de manipulación de datos (DML).
Seguridad
e integridad de los datos
El SGBD debe
supervisar las solicitudes de los usuarios y rechazar los intentos de violar
las medidas de seguridad e integridad definidas por el administrador de la base
de datos.
Recuperación
y concurrencia de los datos
El SGBD (o en su
defecto algún componente de software relacionado con él, al que normalmente se le
denomina administrados de transacciones) debe cuidar del cumplimiento de
ciertos controles de recuperación y concurrencia.
Diccionario
de datos.
El SGBD debe
incluir una función de diccionario de datos. Puede decirse que el diccionario
de datos es una base de datos (del sistema, no del usuario). El contenido del
diccionario puede considerarse como “datos acerca de los datos” (metadatos), es
decir, definiciones de otros objetos en el sistema, y no sólo datos en bruto.
En particular, en el diccionario de datos se almacenarán físicamente todos los
diversos esquemas y correspondencias (externos, conceptuales,etc.) tanto en sus
versiones fuente como en las versiones objeto.
Un diccionario
completo incluirá también referencias cruzadas para indicar, por ejemplo, qué
bases de datos utilizan los programas, que informes requieren los usuarios, qué
terminales están conectadas al sistema... Es más, el diccionario podría (y
quizá debería) estar integrado a la base de datos a la cual define, e incluir
por tanto su propia definición. Deberá ser posible consultar el diccionario igual que cualquier otra base de
datos de modo que se puede saber, por ejemplo, qué programas o usuarios podrían
verse afectados por alguna modificación propuesta para el sistema.
Como conclusión,
podemos decir que el SGBD constituye la interfaz entre el usuario y el sistema
de bases de datos. La interfaz del usuario puede definirse como una frontera
del sistema, más allá de la cual todo resulta invisible para el usuario. Por
definición, entonces, la interfaz del usuario está en el nivel externo.
Características
de extensibilidad de los SGBD
Los SGBD deben
reunir una serie de características que contemplen las nuevas funcionalidades
que deben proporcionar en estos momentos. Dichas características son:
Soporte
ODBC
ODBC (siglas que
significan Open DataBase Conectivity, Conectividad Abierta de Bases de Datos) se
define como un método común de acceso a bases de datos, diseñado por Microsoft
para simplificar la comunicación en Bases de Datos Cliente/Servidor. ODBC
consiste en un conjunto de llamadas de bajo nivel que permite a las
aplicaciones en el cliente intercambiar instrucciones con las aplicaciones del
servidor y compartir datos, sin necesidad de conocer nada unas respecto a las
otras. Las aplicaciones emplean módulos, llamados controladores de bases de
datos, que unen la aplicación con el SGBD concreto elegido. Se emplea el SQL
como lenguaje de acceso a los datos. El SGBD debe proporcionar los
controladores adecuados para poder ser empleados por los distintos lenguajes de
programación que soporten ODBC.
Orientación
a objetos
Los SGDB
relacionales tradicionales sólo pueden almacenar y tratar con números y cadenas
de
caracteres. Las
mejoras en el terreno de la multimedia obligan a que las aplicaciones
desarrolladas actualmente precisen cada vez más almacenar, junto con la
información numérica y de caracteres, tipos de datos más complejos que permitan
gestionar objetos de sonido, imágenes, vídeos, etc. Algunos SGBD relacionales
avanzaron en este sentido dando cabida en sus BD a tipos de datos binarios
(donde se puede guardar código binario, que es el que forma los objetos de
sonido, imágenes, programas ejecutables, etc.), pero esto no es suficiente. La
aparición de SGBD relacionales Orientados a Objetos (SGBDROO) proporcionan toda
la potencia y robustez de los SGBD relacionales, y al mismo tiempo, permiten
gestionar objetos de un modo nativo, así como los campos numéricos y de
caracteres que se han visto recogidos tradicionalmente. Los SGBDROO cuentan con
todas las posibilidades de un motor de consultas SQL clásico, pero el lenguaje
puede manipular tipos definidos por el usuario, de la misma manera que gestiona
los tipos predefinidos de los sistemas más antiguos. Por lo tanto, se trata de
un SGBD relacional, pero extendido y ampliado de manera que soporte la gestión
de objetos. Por otra parte, la tendencia a la generación de aplicaciones
distribuidas, donde los usuarios, datos y componentes de la aplicación están físicamente
separados, facilita e impulsa el uso de SGDROO, pues los objetos y las
aplicaciones distribuidas están "hechos el uno para el otro".
Conectividad
en Internet
Los distintos
SGDB existentes incorporan en sus últimas versiones software de tipo middleware
(capa de
software que se sitúa sobre el SGBD) para añadir conectividad a la base de
datos a través de Internet. Microsoft ha desarrollado los ADO (Access Database
Object, Objetos de Acceso a Bases de Datos) que, incorporados en scripts dentro
de páginas Web en HTML, proporcionan conexión con Bases de Datos, tanto locales
como remotas, empleando ODBC. Los middleware desarrollados en los distintos
SGBDs suelen emplear ODBC ( o JDBC, conectividad abierta de bases de datos
preparada para el lenguaje Java) para conectar con la BD, junto con diversos
conjuntos de herramientas para facilitar al usuario la implementación de la
comunicación con la BD a través de Internet.
Soporte
de estándares objetuales
Hay varios
estándares de objetos diseñados para proporcionar una guía en el diseño y
desarrollo de aplicaciones distribuidas que trabajen con BD relaciones con
orientación a objetos. Los SGBDs actuales hacen uso de software del tipo
middleware que asumen las tareas de servicio de transacciones de objeto siguiendo
alguno de los estándares de objetos existentes. Los principales estándares de
objeto son:
- CORBA (Common
Object Broker Architecture, o Arquitectura común de gestores de solicitudes de objetos),
del Object Management Group (OMG).
- DCOM
(Distributed Component Model) de Microsoft.
- Java Remote Method Invocation de Sun.
Los actuales
SGBD proporcionan soporte, como mínimo, a CORBA y DCOM.
Data
Mining, Data Warehousing, OLAP Los SGBD deben incorporar una serie de herramientas
que permitan, de forma cómoda, sencilla e intuitiva, la extracción y
disección-minería de datos (Data Mining), y soporte para OLAP (OnLine Analytical
Processing, Procesamiento Análitico de Datos En Vivo), que se trata de una
categoría de las nuevas tecnologías del software que permite obtener y extraer
información mediante un complejo análisis y procesamiento del contenido de una
Base de Datos, todo ello en tiempo real.
También deben
proporcionar una estabilidad y robustez cada vez mejores, que permitan mejorar
los almacenes de datos (Data Warehousing), mercados de datos (Data Marts) y
Webs de datos, procesos de transacciones y otras aplicaciones de misión
crítica.
ARQUITECTURAS
DE SISTEMAS DE BASES DE DATOS.
Anteriormente se
ha analizado con cierto detalle la arquitectura ANSI/SPARC para sistemas de bases
de datos. En esta sección vamos a examinar los sistemas de bases de datos desde
un punto de vista diferente.
La arquitectura
de un sistema de base de datos está influenciada en gran medida por el sistema informático
subyacente en el que se ejecuta el sistema de base de datos. En la arquitectura
de un sistema de base de datos se reflejan aspectos como la conexión en red, el
paralelismo y la distribución:
- La
arquitectura centralizada es la más clásica. En ella, el SGBD está implantado
en una sola plataforma u ordenador desde donde se gestiona directamente, de
modo centralizado, la totalidad de los recursos. Es la arquitectura de los
centros de proceso de datos tradicionales. Se basa en tecnologías sencillas, muy
experimentadas y de gran robustez.
- La conexión en
red de varias computadoras permite que algunas tareas se ejecuten en un sistema
servidor y que otras se ejecuten en los sistemas clientes. Esta división de
trabajo ha conducido al desarrollo de sistemas de bases de datos
cliente-servidor.
- La
distribución de datos a través de las distintas sedes o departamentos de una
organización permite que estos datos residan donde han sido generados o donde
son más necesarios, pero continuar siendo accesibles desde otros lugares o
departamentos diferentes. El hecho de guardar varias copias de la base de datos
en diferentes sitios permite que puedan continuar las operaciones sobre la base
de datos aunque algún sitio se vea afectado por algún desastre natural, como
una inundación, un incendio o un terremoto. Se han desarrollado los sistemas de
bases de datos distribuidos para manejar datos distribuidos geográfica o administrativamente
a lo largo de múltiples sistemas de bases de datos.
- El
procesamiento paralelo dentro de una computadora permite acelerar las
actividades del sistema de base de datos, proporcionando a las transacciones
unas respuestas más rápidas, así como la capacidad de ejecutar más
transacciones por segundo. Las consultas pueden procesarse de manera que se
explote el paralelismo ofrecido por el sistema informático subyacente. La necesidad
del procesamiento paralelo de consultas ha conducido al desarrollo de los
sistemas de bases de datos paralelos.
No debe
confundirse el SGBD con la arquitectura que se elige para implantarlo. Algunos
SGBD sólo se pueden implantar en una de las arquitecturas y otros en todas
ellas.
Arquitectura
centralizada
Los sistemas de
bases de datos centralizados son aquellos que se ejecutan en un único sistema informático
sin interaccionar con ninguna otra computadora. Tales sistemas comprenden el
rango desde los sistemas de bases de datos monousuario ejecutándose en
computadoras personales hasta los sistemas de bases de datos de alto
rendimiento ejecutándose en grandes sistemas.
Una computadora
moderna de propósito general consiste en una o unas pocas CPU’s y un número determinado
de controladores para los dispositivos que se encuentren conectados a través de
un bus común, el cual proporciona acceso a la memoria compartida. Las CPU’s
poseen memorias caché locales donde se almacenan copias de ciertas partes de la
memoria para acelerar el acceso a los datos. Cada controlador de dispositivo se
encarga de un tipo específico de dispositivos (por ejemplo, una unidad de
disco, una tarjeta de sonido o un monitor). La CPU y los controladores de
dispositivo pueden ejecutarse concurrentemente, compitiendo así por el acceso a
la memoria. La memoria caché reduce la disputa por el acceso a la memoria, ya
que la CPU necesita acceder a la memoria compartida un número de veces menor.
Se distinguen
dos formas de utilizar las computadoras: como sistemas monousuario o como sistemas multiusuario. En la primera categoría están las
computadoras personales y las estaciones de trabajo. Un sistema monousuario
típico es una unidad de sobremesa utilizada por una única persona que dispone de
una sola CPU, de uno o dos discos fijos y que trabaja con un sistema operativo
que sólo permite un único usuario. Por el contrario, un sistema multiusuario
típico tiene más discos y más memoria, puede disponer de varias CPU y trabaja
con un sistema operativo multiusuario. Se encarga de dar servicio a un gran
número de usuarios que están conectados al sistema a través de terminales.
Estos sistemas se denominan con frecuencia sistemas servidores.
Normalmente, los
sistemas de bases de datos diseñados para funcionar sobre sistemas monousuario,
como las computadoras personales, no suelen proporcionar muchas de las
facilidades que ofrecen los sistemas multiusuario. En particular, no tienen
control de concurrencia, que no es necesario cuando solamente un usuario puede
generar modificaciones. Las facilidades de recuperación en estos sistemas, o no
existen o son primitivas; por ejemplo, realizar una copia de seguridad de la
base de datos antes de cualquier modificación. La mayoría de estos sistemas no
admiten SQL y proporcionan un lenguaje de consulta muy simple, que en algunos
casos es una variante de QBE (Query By Example).
Aunque hoy en
día las computadoras de propósito general tienen varios procesadores, utilizan paralelismo
de grano grueso, disponiendo de unos pocos procesadores (normalmente dos o
cuatro) que comparten la misma memoria principal. Las bases de datos que se
ejecutan en tales máquinas habitualmente no intentan dividir una consulta
simple entre los distintos procesadores, sino que ejecutan cada consulta en un
único procesador, posibilitando la concurrencia de varias consultas. Así, estos
sistemas soportan una mayor productividad, es decir, permiten ejecutar un mayor
número de transacciones por segundo, a pesar de que cada transacción
individualmente no se ejecuta más rápido.
Las bases de
datos diseñadas para las máquinas monoprocesador ya disponen de multitarea, permitiendo
que varios procesos se ejecuten a la vez en el mismo procesador, usando tiempo
compartido, mientras que de cara al usuario parece que los procesos se están
ejecutando en paralelo. De esta manera, desde un punto de vista lógico, las
máquinas paralelas de grano grueso parecen ser idénticas a las máquinas monoprocesador,
y pueden adaptarse fácilmente los sistemas de bases de datos diseñados para
máquinas de tiempo compartido para que puedan ejecutarse sobre máquinas
paralelas de grano grueso.
Por el
contrario, las máquinas paralelas de grano fino tienen un gran número de
procesadores y los sistemas de bases de datos que se ejecutan sobre ellas
intentan paralelizar las tareas simples (consultas, por ejemplo) que solicitan
los usuarios.
