You are on page 1of 6

Instituto Tecnolgico de Morelia

Jos Mara Morelos y


Pavn

ITICs | Bases de datos distribuidas

Arquitectura de las bases de


datos distribuidas
Arquitectura de las bases de datos
Arquitectura ANSI
La arquitectura de sistemas de bases de datos de tres esquemas fue
aprobado por la ANSI-SPARC (American National Standard Institute Standards Planning and Requirements Committee) en 1975 como ayuda
para conseguir la separacin entre los programas de aplicacin y los
datos, el manejo de mltiples vistas por parte de los usuarios y el uso de
un catlogo para almacenar el esquema de la base de datos.

Nivel interno: Tiene un esquema interno que describe la estructura


fsica de almacenamiento de base de datos. Emplea un modelo
fsico de datos y los nicos datos que existen estn realmente en
este nivel.
Nivel conceptual: tiene esquema conceptual. Describe la
estructura de toda la base de datos para una comunidad de
usuarios. Oculta los detalles fsicos de almacenamiento y trabaja
con elementos lgicos como entidades, atributos y relaciones.
Nivel externo o de vistas: tiene varios esquemas externos o vistas
de usuario. Cada esquema describe la visin que tiene de la base
de datos a un grupo de usuarios, ocultando el resto.

El objetivo de la arquitectura de tres niveles es el de separar los


programas de aplicacin de la base de datos fsica.
Una base de datos especfica tiene un nico nivel interno y un nico
nivel conceptual pero puede tener varios niveles externos.

Tipos de independencia de datos:

La independencia lgica es la capacidad de modificar el esquema


conceptual sin tener que alterar los esquemas externos ni los programas
de aplicacin. Se puede modificar el esquema conceptual para ampliar la
base de datos o para reducirla. Si, por ejemplo, se reduce la base de
datos eliminando una entidad, los esquemas externos que no se refieran
a ella no debern verse afectados.
La independencia fsica es la capacidad de modificar el esquema
interno sin tener que alterar el esquema conceptual (o los externos). Por
ejemplo, puede ser necesario reorganizar ciertos ficheros fsicos con el
fin de mejorar el rendimiento de las operaciones de consulta o de
actualizacin de datos. Dado que la independencia fsica se refiere slo a
la separacin entre las aplicaciones y las estructuras fsicas de
almacenamiento, es ms fcil de conseguir que la independencia lgica.

Arquitectura de una base de datos distribuida


Una vez conocida la estructura de una base de datos convencional, podemos
partir de ah para conocer y entender de una mejor manera la arquitectura de
una base de datos distribuida.

Tipos de arquitecturas
En un sistema de bases de datos distribuidas, existen varios factores que
deben tomar en consideracin que definen la arquitectura del sistema:

Distribucin: Los componentes del sistema estn localizados en la


misma computadora o no.

Heterogeneidad: Un sistema es heterogneo cuando existen en l


componentes que se ejecutan en diversos sistemas operativos, de
diferentes fuentes, etc.

Autonoma: Se puede presentar en diferentes niveles, los cuales se


describen a continuacin:
o

Autonoma de diseo: Habilidad de un componente del sistema


para decidir cuestiones relacionadas a su propio diseo.

Autonoma de comunicacin: Habilidad de un componente del


sistema para decidir cmo y cundo comunicarse con otros SGBD
(Sistema Gestor de Bases de Datos).

Autonoma de ejecucin: Habilidad de un componente del sistema


para ejecutar operaciones locales como quiera.

Multi base de datos distribuida


Cuando una base de datos distribuida es muy homognea se dice que es multi
base de datos distribuida.
Base de datos Federada
Cuando una base de datos distribuida tiene mucha autonoma local se dice que
es federada.

Objetivos de implementacin
Al implementar una base de datos distribuida se tienen ciertos objetivos
comunes:

Transparencia de ubicacin. Permite a los usuarios tener acceso a los


datos sin que tenga conocimiento de la ubicacin de stos. Se puede
conseguir este nivel de transparencia al utilizar los administradores de
transacciones distribuidas, los cuales son capaces de determinar la
localizacin de los datos y de emitir acciones a los calendarizadores
apropiados, lo cual puede ejecutarse cuando los administradores de

transacciones distribuidas
localizaciones de los datos.

poseen

acceso

los

directorios

de

Transparencia de duplicacin. Para que la transparencia de


duplicacin sea posible, los administradores de transacciones deben
traducir las solicitudes de procesamiento de transaccin en acciones
para el administrador de datos. Para las lecturas el administrador de
transacciones selecciona uno de los nodos que almacena los datos y
ejecuta la lectura. Para optimizar el proceso, el administrador de
transacciones necesita informacin sobre el rendimiento de varios nodos
respecto al sitio de consulta, as podr seleccionar el nodo de mejor
rendimiento. La actualizacin y escritura de datos duplicados suelen ser
ms complicadas, ya que el manejador de transacciones debe emitir una
accin de escritura para cada uno de los calendarizadores que almacena
una copia de los datos.

Transparencia de concurrencia. Cuando varias transacciones se


ejecuten al mismo tiempo, los resultados de las transacciones no
debern afectarse. La transparencia de concurrencia se logra si los
resultados de todas las transacciones concurrentes son consistentes de
manera lgica con los resultados que se habran obtenido si las
transacciones se hubieran ejecutado una por una, en cualquier orden
secuencial.

Transparencia de fallas. Significa que a pesar de fallas las


transacciones sean procesadas de un modo correcto. Frente a una falla,
las transacciones deben ser atmicas, significa que se procesen todas o
ninguna de ellas. Para este tipo de problemas es importante tener
resguardo de la base de datos, y as poder restaurarla cuando sea
conveniente. El sistema debe detectar cundo falla una localidad y
tomar las medidas necesarias para recuperarse del fallo. El sistema no
debe seguir utilizando la localidad que fall. Por ltimo, cuando se
recupere o repare esta localidad, debe contarse con mecanismos para
reintegrarla al sistema con el mnimo de complicaciones.

Localidad del procesamiento. Los datos se deben distribuir lo ms


cerca posible de las aplicaciones que los usan para maximizar la
localidad del procesamiento, este principio responde a minimizar el
acceso remoto a los datos. Disear una distribucin que maximice
localidad del procesamiento puede hacerse aadiendo la cantidad de
referencias locales y remotas correspondientes a cada fragmentacin
candidata y asignar la fragmentacin eligiendo la mejor solucin.
Independencia de configuracin. La independencia de configuracin
permite aadir o reemplazar hardware sin tener que cambiar
componentes de software existentes en el sistema de base de datos
distribuida.

Particionado de la Base de Datos. La base de datos se distribuye de


modo que no haya solapamiento o duplicacin de los datos mantenidos

en las diferentes localidades, como no hay duplicaciones de los datos, se


evitan los costos asociados con el almacenamiento y mantenimiento de
datos redundantes. Si un mismo segmento de datos se usa en ms de
una localidad se ve limitada la disponibilidad de los datos. La fiabilidad
tambin puede verse limitada cuando se produce un fallo en el sistema
de clculo de una localidad se afecta la disponibilidad de los datos de
esa localidad no estn disponible para los usuarios en cualquier parte del
sistema.

Fragmentacin de datos. Consiste en subdividir las relaciones y


distribuirlas entre los sitios de la red, tiene como objetivo buscar formas
alternativas de dividir una las instancias (tablas) de relaciones en otras
ms pequeas. La fragmentacin se puede realizar por tablas
individuales (fragmentacin horizontal), por atributos individuales
fragmentacin vertical) o una combinacin de ambas (fragmentacin
hbrida). El principal problema de la fragmentacin radica en encontrar
la unidad apropiada de distribucin. Una relacin no es una buena
unidad por muchas razones. Normalmente las vistas de una relacin
estn formadas por subconjuntos de relaciones. Adems, las
aplicaciones acceden localmente a subconjuntos de relaciones. Por ello,
es necesario considerar a los subconjuntos de relaciones como unidad
de distribucin. Al descomponer de una relacin en fragmentos, tratados
cada uno de ellos como una unidad de distribucin, permite el proceso
concurrente de las transacciones. El conjunto de estas relaciones,
provocar la ejecucin paralela de una consulta al ser dividida en una
serie de subconsultas que operar sobre los fragmentos. Cuando las
vistas definidas sobre una relacin son consideradas como unidad de
distribucin que se ubican en diferentes sitios de la red, podemos optar
por dos alternativas diferentes: La relacin no estar replicada y se
almacena en un nico sitio, o existe rplica en todos o algunos de los
sitios en los cuales reside la aplicacin. Las consecuencias de esta
estrategia son la generacin de un volumen de accesos remotos que
pueden ser innecesarios con un mal manejo de estas replicas. Adems,
las rplicas innecesarias pueden causar problemas en la ejecucin de las
actualizaciones y puede no ser deseable si el espacio de
almacenamiento est limitado. Los inconvenientes de la fragmentacin
estn dados en que si las pueden estar definidas por fragmentos
mutuamente exclusivos y al recuperar los datos de dos fragmentos
situados en sitios diferentes es necesario trasmitir los datos de un sitio a
otro y realizar sobre ellos la operacin de unin (Join), lo cual puede ser
costoso. El control semntico cuando los atributos implicados en una
dependencia una relacin se descompone en diferentes fragmentos y
estos se ubican en sitios diferentes puede ser muy costos porque es
necesario hacer bsquedas en un gran nmero de sitios.

You might also like