Clases y Arqutectura de Base de Datos

Estándar ANSI/X3/SPARC de los SGBDs Centralizados. 

En el tema I se ha descrito la arquitectura de los SGBD del ANSI/X3/SPARC (American National  Standards Institute), establecida como primer estándar en 1975.

Esta arquitectura define tres niveles de representación de la información de las bases de datos que gestiona.

Descritos desde el interior de la BD hacia afuera, los niveles son: Nivel Interno o Físico, -NF-; Nivel Conceptual, -NC-, y Nivel Externo o Lógico, -NL.

El Nivel Físico se encarga de "engranar" con el software más interno de cada máquina (Sistema Operativo, y Sistema de Gestión de Ficheros generalmente). Los SGBDs actuales funcionan sobre casi todas las máquinas y "corren" en casi todos los SOs del mercado.

El Nivel Conceptual define el resultado del diseño de la BD, para una parte del mundo real con interés informativo para ser formulada y registrada en un ordenador. El resultado del diseño de una BD establece la definición de un ESQUEMA CONCEPTUAL conforme a un modelo de datos, MD, que llamamos Esquema de la BD. El Nivel Conceptual de un SGBD mantiene, en cada momento, tantos Esquemas distintos cuantas Bases de Datos hayan sido diseñadas en ese SGBD.

El software, en esencia, es una forma de arte. Idealmente, el usuario debería percibir a los sistemas software en general como 'algo que le sitúa en su mundo', sin barreras artificiales de sistemas operativos, arquitecturas del hardware, plataformas, compatibilidad de redes, de aplicaciones o de servidores de información. En el ESPACIO DE DATOS del futuro, estas fronteras tecnológicas de hoy están llamadas a desaparecer.

Contextualización. Organización de las BDR Distribuidas, Homogéneas y

Altamente Integradas.

La figura VII.2 muestra un ejemplo de cómo se organizan las BD Relacionales Distribuidas, Homogéneas y altamente Integradas, en adelante BDDs. La figura representa dos Bases de Datos Distribuidas, -BDDs- a lo largo de tres nodos de una red. 

 

Arquitectura de los Sistemas de Bases de Datos Distribuidos.

Los Sistemas se construyen mediante Módulos con interfaces de flujos de control y datos: 

Implementar un módulo ---------------->Programming-in-the-small. 

Integrar los módulos-------------------->Programming-in-the-large 

Niveles de Transparencia de los aspectos de distribución.

Transparencia:

ocultar detalles de implementación al usuario o a los niveles altos del sistema.

Programming-in-the-small se oculta a Programming-in-the-large, conforme representa la figura

Alternativas de Implementación de los SGBD Distribuidos.

La figura VII.6 representa un esquema sobre las distintas formas de modelar e implementar los SGBD capaces, en distinto modo, de incorporar aspectos de Distribución, Autonomía y Heterogeneidad. 

Arquitectura ANSI/X3/SPARC de los SGBD Distribuidos.

La figura VII.7 representa el Modelo de Referencia de ANSI/X3/SPARC extendido. Refiere la arquitectura de los SBDD Integrados.

 

Arquitectura de los SGBD Multidatabase Distribuidos.

 

La figura VII.8 representa la arquitectura de los Sistemas ‘Multidatabase’ sin integración de Esquemas Conceptuales Locales en un Esquema Conceptual Global. En esta propuesta, sólo a través del Multi Lenguaje, las consultas interoperan con varias Bases de Datos independientes. Es una propuesta de W. Litwin, “MSQL Language”. 

Conclusiones a las Arquitecturas de los SBDD. 

1.Los Modelos de Arquitecturas son marcos abstractos que sirven para: ¾ describir los aspectos de las BDDs, ¾ para analizar y comparar los productos comerciales existentes.

2. El grado de Autonomía Local requerido es un ‘input’ importante para optar por un determinado modelo de Arquitectura del SBDD y elegir una solución de diseño para cada BDD. El SBDD es un software que incluye:

¾ Procesamiento de Consultas Distribuidas ¾ Adaptadores entre las BDs Locales y la BD Global (mappings) ¾ Protocolos de Comunicación ¾ Control de Concurrencia Distribuido, ¾ Gestión de Transacciones Distribuido ¾ Recuperación distribuida frente a fallos distribuidos.

3. Las BDD relacionales y altamente integradas (por diseño ‘top-down’) son una tecnología comercial de hoy, conocida como: “*** / STAR”.

4. Las Multidatabase son más nuevas, no están aún comercializadas, aunque existen prototipos.

 

Arquitecturas Cliente / Servidor, C/S 

2.1 Ubicación del SGBD en la Arquitectura Cliente/Servidor (2 capas)

El SGBD, una de las variedades más complejas del software actual, precisa utilizar el término

Arquitectura con diversas acepciones y puntos de vista.

La arquitectura del SGBD se describe ahora bajo el punto de vista de sus formas operativas (funcionales), como un ente que realiza las aplicaciones del usuario.

La arquitectura ANSI/X3/SPARC, descrita en el Tema I, explicó cómo se organiza la información de una BD. En el Tema VI (cap. 8 de [Cost99]) se ha descrito cómo se organizan varios SGBDs para la interoperabilidad (generalmente distribuida), allí vimos la arquitectura C/S con funcionalidad varios-a-varios (varios Clientes y varios -no muchos- Servidores). Finalmente, en el Tema XI (cap. 9 de [Cost99]) atenderemos a otro tipo de arquitectura. Llamada arquitectura revisitada, centrada en la descripción de los aspectos más internos del software que poseen los motores o Servidores de bases de datos. La arquitectura C/S surge a finales de los años 80’s, como una extensión del estándar RDA Remote database Access [ISO89] y tuvo gran difusión en la tecnología de bases de datos en la década de los 90’s, marcando importantes pautas en la concepción arquitectural de los SGBD, separando nítidamente las funciones del Servidor y las de los Clientes. La arquitectura para los SGBD es algo diferente a la organización del software genérico en Cliente/Servidor (entendido sólo mirando a los procesos que invocan y a los que sirven), ya que la interacción en los SGBD está más especializada. Como sabemos, la distribución es ingrediente común de los Sistemas de Información actuales. Ahora veremos la arquitectura del SGBD como un ente individual (sin cooperar con otros SGBD) para entender los bloques que posibilitan su funcionamiento. Y no entra

remos en detalles de cómo opera el motor o Servidor de Bases de Datos, descrito en Cap. 9 de [Cost99]. Nos bastará ahora con entender que dicho motor contiene el núcleo de las funciones de un SGBD y ha de ejecutarse en un ordenador dotado de recursos adecuados para la gestión de datos masivos.

Veremos cómo se organiza el SGBD en capas para –con ellas- llevar a cabo, en la capa Cliente, determinadas funciones de los aplicativos de usuario. Cada Cliente realiza una especie de pre-procesamiento de las aplicaciones que han de terminar ejecutándose en el Servidor de Bases de Datos. Además de esto, la funcionalidad de la capa del Cliente consiste en implementar funciones de usuario con interfaces amigables y ofrecer alta productividad para dichas funciones de usuario (entornos ofimáticos con: e-mail, procesadores de texto, hojas de cálculo, etc.).

Estudiaremos dos tipos de arquitecturas. La primera describe la arquitectura a dos capas, llamada también arquitectura Cliente/Servidor del SGBD. La segunda es la arquitectura a tres capas, dirigida hacia la World Wide Web y añade una nueva capa conocida como Servidor de Aplicaciones que incluye al Servidor Web (o Servidor HTTP).

Arquitectura Cliente-Servidor (dos capas). 

En el Tema VI (cap. 8 de [Cost99]) vimos el paradigma Cliente/Servidor como el más simple del amplio espectro de la interoperabilidad de los SGBDs distribuidos. Un SGBD con arquitectura

Cliente-Servidor funciona separando limpiamente el papel que juega el Servidor del que desempeña el Cliente. Esta arquitectura, pensada en la distribución, organiza la ejecución de aplicaciones entre diversas máquinas -conectadas por una red (generalmente LAN)- que suele alcanzar a distintas dependencias del edificio(s) donde ella opera, como muestra la figura 7.1.

En la tecnología relacional, la integración de esta arquitectura se basa principalmente en el protocolo Net (por ejemplo, Oracle lo llama SQL*Net). Usa un solo motor SGBD y todas las máquinas son de tipo Cliente salvo la que es Servidora (varios Clientes y un Servidor). Realmente no es preciso que Cliente y Servidor se ubiquen en distintas máquinas, pues el paradigma de esta arquitectura se fundamenta en construir el software con independencia de dónde residan los procesos. Sin embargo, en la gestión de datos, normalmente los procesos del Servidor se ubican en una sola máquina y las máquinas Clientes se esparcen por la red de la institución o empresa para la que se instala este tipo de arquitectura.

Diseño de bases de datos distribuidas

Existen diversas formas de afrontar el problema del diseño de la distribución. Las más usuales se muestran en la figura. En el primer caso, caso A, los dos procesos fundamentales, la fragmentación y la asignación, se abordan de forma simultánea. Esta metodología se encuentra en desuso, sustituida por el enfoque en dos fases, caso B: la realización primeramente de la partición para luego asignar los fragmentos generados. El resto de los casos se comentan en la sección referente a los distintos tipos de la fragmentación.

 

Antes de exponer las alternativas existentes de fragmentación, se desean presentar las ventajas e inconvenientes de esta técnica. Se ha comentado en la introducción la conveniencia de descomponer las relaciones de la base de datos en pequeños fragmentos, pero no se ha justificado el hecho ni se han aportado razones para efectuarlo. Por ello, desde este punto se va a intentar aportar las razones necesarias para llevar a cabo esa descomposición, esa fragmentación.
El principal problema de la fragmentación radica en encontrar la unidad apropiada de distribución. Una relación no es una buena unidad por muchas razones. Primero, las vistas de la aplicación normalmente son subconjuntos de relaciones. Además, la localidad de los accesos de las aplicaciones no está definida sobre relaciones enteras pero sí sobre subconjuntos de las mismas. Por ello, sería normal considerar como unidad de distribución a estos subconjuntos de relaciones.

Segundo, si las aplicaciones tienen vistas definidas sobre una determinada relación (considerándola ahora una unidad de distribución) que reside en varios sitios de la red, se puede optar por dos alternativas. Por un lado, la relación no estará replicada y se almacena en un único sitio, o existe réplica en todos o algunos de los sitios en los cuales reside la aplicación. Las consecuencias de esta estrategia son la generación de un volumen de accesos remotos innecesario. Además, se pueden realizar réplicas innecesarias que causen problemas en la ejecución de las actualizaciones y puede no ser deseable si el espacio de almacenamiento está limitado.
Tercero, la descomposición de una relación en fragmentos, tratados cada uno de ellos como una unidad de distribución, permite el proceso concurrente de las transacciones. También la relación de estas relaciones, normalmente, provocará la ejecución paralela de una consulta al dividirla en una serie de subconsultas que operará sobre los fragmentos.
Pero la fragmentación también acarrea inconvenientes. Si las aplicaciones tienen requisitos tales que prevengan la descomposición de la relación en fragmentos mutuamente exclusivos, estas aplicaciones cuyas vistas estén definidas sobre más de un fragmento pueden sufrir una degradación en el rendimiento. Por tanto, puede ser necesario recuperar los datos de dos fragmentos y llevar a cabo sobre ellos operación de unión y yunto , lo cual es costoso.
Un segundo problema se refiere al control semántico. Como resultado de la fragmentación los atributos implicados en una dependencia se descomponen en diferentes fragmentos los cuales pueden destinarse a sitios diferentes. En este caso, la sencilla tarea de verificar las dependencias puede resultar una tarea de búsqueda de los datos implicados en un gran número de sitios.

Esquemas de base de datos distribuidas

Tipos de Fragmentacion


Fragmentacion horizontal

 La fragmentación horizontal primaria de una relación se obtiene usando predicados que están definidos en esa relación. La fragmentación horizontal derivada, por otra parte, es el particionamiento de una relación como resultado de predicados que se definen en otra relación.
Para poder construir una fragmentación, es necesario proporcionar información acerca de la base de datos y acerca de las aplicaciones que las utilizan. En primer término, es necesario proporcionar la información acerca del esquema conceptual global. En este sentido es importante dar información acerca de las relaciones que componen a la base de datos, la cardinalidad de cada relación y las dependencias entre relaciones.
En segundo lugar se debe proporcionar información acerca de la aplicación que utiliza la base de datos. Este tipo de información es cuantitativa y consiste de los predicados usados en las consultas de usuario.

Frarmentacion Vertical


Una fragmentación vertical de una relación R produce fragmentos R1, R2, …, Rr, cada uno de los cuales contiene un subconjunto de los atributos de R así como la llave primaria de R. El objetivo de la fragmentación vertical es particionar una relación en un conjunto de relaciones más pequeñas de manera que varias de las aplicaciones de usuario se ejecutarán sobre un fragmento. En este contexto, una fragmentación “óptima” es aquella que produce un esquema de fragmentación que minimiza el tiempo de ejecución de las consultas de usuario.
La fragmentación vertical ha sido estudiada principalmente dentro del contexto de los sistemas de manejo de bases de datos centralizados como una herramienta de diseño, la cual permite que las consultas de usuario traten con relaciones más pequeñas haciendo, por tanto, un número menor de accesos a páginas.
La fragmentación vertical es inherentemente más complicada que particionamiento horizontal ya que existe un gran número de alternativas para realizarla. Por lo tanto, se utilizan heurísticas para hacer el particionamiento. Los dos enfoques básicos son:
Agrupamiento. Inicia asignando cada atributo a un fragmento, y en cada paso, algunos de los fragmentos satisfaciendo algún criterio se unen para formar un solo fragmento.
División. Inicia con una sola relación realizar un particionamiento basado en el comportamiento de acceso de las consultas sobre los atributos.

Fragmentaicon Hibrida


En muchos casos la fragmentación vertical u horizontal del esquema de la base de datos no será suficiente para satisfacer los requisitos de las aplicaciones. Como ya se citó al comienzo de este documento podemos combinar ambas, utilizando por ello la denominada fragmentación mixta. Cuando al proceso de fragmentación vertical le sigue una horizontal, es decir, se fragmentan horizontalmente los fragmentos verticales resultantes, se habla de la fragmentación mixta HV. En el caso contrario, estaremos ante una fragmentación VH. Una característica común a ambas es la generación de árboles que representan la estructura de fragmentación.
Considere, por ejemplo, la relación PROVINC. Recordará que se le aplicó una fragmentación horizontal de acuerdo al valor del atributo CCODZONA resultando cuatro fragmentos horizontales. Podríamos pensar en aplicarle una nueva fragmentación de carácter vertical. Entonces resultarían cuatro fragmentos horizontales divididos, por ejemplo, en dos fragmentos verticales. En este caso el número total de fragmentos ascendería, lógicamente, a ocho.