Resumen de conceptos_final

“Escuela Militar de Ingeniería”
Mcal. Antonio José de Sucre
Base de Datos II Ing. Osamu Yokosaki
Análisis de Sistema
Resumen de Conceptos Examen Final (Especial)

BASES DE DATOS DISTRIBUIDAS

Definición:

Es una colección de datos (base de datos) construida sobre una red y que pertenecen,
lógicamente, a un solo sistema distribuido, la cual cumple las siguientes condiciones:
• La información de la base de datos esta almacenada físicamente en diferentes sitios de la red.
• En cada sitio de la red, la parte de la información, se constituye como una base de datos en sí misma.
• Las bases de datos locales tienen sus propios usuarios locales, sus propios DBMS y programas para la
administración de transacciones, y su propio administrador local de comunicación de datos.
• Estas base de datos locales deben de tener una extensión, que gestione las funciones de sociedad
necesarias; la combinación de estos componentes con los sistemas de administración de base de
datos locales, es lo que se conoce como Sistema Administrador de Base de Datos Distribuidas.
• Este gestor global permite que usuarios puedan acceder a los datos desde cualquier punto de la red,
como si lo hicieran con los datos de su base de datos local, es decir, para el usuario, no debe existir
diferencia en trabajar con datos locales o datos de otros sitios de la red.
En consecuencia, la base de datos distribuida, es como una unidad virtual, cuyas partes se almacenan
físicamente en varias bases de datos “reales” distintas, ubicadas en diferentes sitios.

En un sistema de base de datos distribuida, los datos se almacenan en varios computadores. Los
computadores de un sistema distribuido se comunican entre sí a través de diversos medios de
comunicación, tales como cables de alta velocidad o líneas telefónicas. No comparten la memoria principal
ni el reloj.

Los procesadores de un sistema distribuido pueden variar en cuanto su tamaño y función. Pueden incluir
microcomputadores pequeños, estaciones de trabajo y sistemas de computadores grandes de aplicación
general. Estos procesadores reciben diferentes nombres, tales como localidades, nodos o computadores.

Un sistema distribuido de bases de datos consiste en un conjunto de localidades, cada uno de las cuales
puede participar en la ejecución de transacciones que accedan a datos de una o varias localidades. La
diferencia principal entre los sistemas de base de datos centralizados y distribuidos es que, en los primeros,
los datos residen en una sola localidad, mientras que, en los últimos, se encuentran en varias localidades.

Ejemplo de base de datos distribuida:

Considere un banco que tiene tres sucursales, en cada sucursal, un ordenador controla las terminales de
la misma y el sistema de cuentas. Cada computador con su sistema de cuentas local en cada sucursal
constituye un "sitio" de la BDD; las computadoras están conectadas por la red. Durante las operaciones
normales, las aplicaciones en las terminales de la sucursal necesitan sólo acceder la base de datos de la
misma. Como sólo acceden a la misma red local, se les llaman aplicaciones locales.

Desde el punto de vista tecnológico, aparentemente lo importante es la existencia de algunas
transacciones que acceden a información en más de una sucursal. Estas transacciones son llamadas
transacciones globales o transacciones distribuidas.

1


La existencia de transacciones globales será considerada como una característica que nos ayude a
discriminar entre las BDD y un conjunto de base de datos locales.

Una típica transacción global sería una transferencia de fondos de una sucursal a otra. Esta aplicación
requiere de actualizar datos en dos diferentes sucursales y asegurarse de la real actualización en ambos
sitios o en ninguno. Asegurar el buen funcionamiento de aplicaciones globales es una tarea difícil.

Ventajas de las Base de Datos Distribuidas

• Descentralización.- En un sistema centralizado/distribuido, existe un administrador que controla
toda la base de datos, por el contrario en un sistema distribuido existe un administrador global que
lleva una política general y delega algunas funciones a administradores de cada localidad para que
establezcan políticas locales y así un trabajo eficiente.

• Economía: Existen dos aspectos a tener en cuenta.
o El primero son los costes de comunicación; si las bases de datos están muy dispersas y las
aplicaciones hacen amplio uso de los datos puede resultar más económico dividir la aplicación y
realizarla localmente.
o El segundo aspecto es que cuesta menos crear un sistema de pequeños ordenadores con la
misma potencia que un único ordenador.
• Mejora de rendimiento: Pues los datos serán almacenados y usados donde son generados, lo cual
permitirá distribuir la complejidad del sistema en los diferentes sitios de la red, optimizando la labor.

• Mejora de fiabilidad y disponibilidad: La falla de uno o varios lugares o el de un enlace de
comunicación no implica la inoperatividad total del sistema, incluso si tenemos datos duplicados
puede que exista una disponibilidad total de los servicios.

• Crecimiento: Es más fácil acomodar el incremento del tamaño en un sistema distribuido, por que la
expansión se lleva a cabo añadiendo poder de procesamiento y almacenamiento en la red, al añadir
un nuevo nodo.

• Flexibilidad: Permite acceso local y remoto de forma transparente.

• Disponibilidad: Pueden estar los datos duplicados con lo que varias personas pueden acceder
simultáneamente de forma eficiente. El inconveniente, el sistema administrador de base de datos
debe preocuparse de la consistencia de los mismos.

• Control de Concurrencia: El sistema administrador de base de datos local se encarga de manejar
la concurrencia de manera eficiente.

Inconvenientes de las base de datos distribuidas.

• El rendimiento que es una ventaja podría verse contradicho, por la naturaleza de la carga de trabajo,
pues un nodo puede verse abrumado, por las estrategias utilizadas de concurrencia y de fallos, y el
acceso local a los datos. Se puede dar esta situación cuando la carga de trabajo requiere un gran
número de actualizaciones concurrentes sobre datos duplicados y que deben estar distribuidos.

2


• La confiabilidad de los sistemas distribuidos, esta entre dicha, puesto que, en este tipo de base de
datos existen muchos factores a tomar en cuanta como: La confiabilidad de los ordenadores, de la red,
del sistema de gestión de base de datos distribuida, de las transacciones y de las tazas de error de la
carga de trabajo.

• La mayor complejidad, juega en contra de este tipo de sistemas, pues muchas veces se traduce en
altos gastos de construcción y mantenimiento. Esto se da por la gran cantidad de componentes
Hardware, muchas cosas que aprender, y muchas aplicaciones susceptibles de fallar. Por ejemplo, el
control de concurrencia y recuperación de fallos, requiere de personal muy especializado y por tal
costoso.
• El procesamiento de base de datos distribuida es difícil de controlar, pues estos procesos muchas
veces se llevan a cabo en las áreas de trabajo de los usuarios, e incluso el acceso físico no es
controlado, lo que genera una falta de seguridad de los datos.

Desarrollo WEB

Caso particular de los sistemas Cliente-Servidor con representación remota. En donde se dispone
de un protocolo estándar: HTTP y un Middleware denominado WebServer. En la actualidad la aplicación de
sistemas informáticos basados en Internet, es una herramienta fundamental para las organizaciones que
desean tener cierta presencia competitiva.

Tecnologías de la lógica de la aplicación en el servidor web:
a. CGI: Common Gateware Interface..- Son programas que se ejecutan en el servidor, pueden
servir como pasarela con una aplicación o base de datos o para generar documentos html de
forma automática. Cada petición http ejecuta un proceso, el cual analiza la solicitud y genera un
resultado. Son independientes del SO, y presentan la ventaja de que, dado un programa escrito
en un lenguaje cualquiera, es fácil adaptarlo a un CGI. Entre los lenguajes que se usan para CGIs,
el más popular es el Perl.
b. Servlets: Pequeños programas en Java que se ejecutan de forma persistente en el servidor, y
que, por lo tanto, tienen una activación muy rápida, y una forma más simple de hacerlo. Estos
programas procesan una petición y generan la página de respuesta.
c. ASP (Active Server Pages): Una página ASP es un fichero de sólo texto que contiene las
secuencias de comandos, junto con el HTML necesario, y que se guarda con la extensión “.asp”.
Al ser llamado por el navegador, el motor ASP del IIS (Internet Information Server) se
encarga automáticamente de ejecutarlo como se suele hacer con un programa cualquiera, pero
cuya salida siempre será a través del navegador que le invoca. Es un entorno propietario de
Microsoft y el lenguaje de secuencia de comandos predeterminado del IIS es el VBScript, aunque
puede cambiarse.
d. JSP (Java Server Pages), que consisten en pequeños trozos de código en Java que se insertan
dentro de páginas web, de forma análoga a los ASPs. Ambas opciones, hoy en día, son muy
populares en sitios de comercio electrónico. Frente a los ASPs, la ventaja que presentan es que
son independientes del sistema operativo y del procesador de la máquina.
e. PHP es un lenguaje cuyos programas se insertan también dentro de las páginas web, al igual
que los ASPs y JSPs; es mucho más simple de usar, y el acceso a bases de datos desde él es

3


muy simple. Es tremendamente popular en sitios de comercio electrónico con poco tráfico, por su
facilidad de desarrollo y rapidez de implantación.
Consideraciones a tomar en el desarrollo de un sistema WEB
a. Separar la lógica de la aplicación de la interfase de usuario.
b. Utilizar métodos estándar de comunicación entre la lógica de aplicación y la interfase de usuario.
c. Herramientas que permitan una fácil adaptación de las aplicaciones a los nuevos dispositivos que
irán apareciendo.
d. Definir el coste en comunicaciones que debe asumir la organización.
e. Tener en cuenta los procesos de réplica, periodicidad y el ancho de banda que consuman.
f. Replantear la idoneidad de la ubicación de cada proceso.
g. Extremar las pruebas al diseñar e implementar los protocolos de comunicación.
Tendencias Actuales de las arquitecturas de sistemas WEB:

Variante de los fabricantes de Base de Datos

Variante de los fabricantes de pasarelas:

4


Estructura de Base de Datos Distribuidas

Un sistema distribuido de base de datos consiste en un conjunto de localidades, cada una de las cuales
mantiene un sistema de base de datos local. Cada localidad puede procesar transacciones locales, o bien
transacciones globales entre varias localidades, requiriendo para ello comunicación entre ellas.

Las localidades pueden conectarse físicamente de diversas formas, las principales son:
• Red totalmente conectada
• Red prácticamente conectada
• Red con estructura de árbol
• Red de estrella
• Red de anillo

Las diferencias principales entre estas configuraciones son:
• Coste de instalación: El coste de conectar físicamente las localidades del sistema
• Coste de comunicación: El coste en tiempo y dinero que implica enviar un mensaje desde la
localidad A a la B.
• Fiabilidad: La frecuencia con que falla una línea de comunicación o una localidad.
• Disponibilidad: La posibilidad de acceder a información a pesar de fallos en algunas localidades o
líneas de comunicación.

Las localidades pueden estar dispersas, ya sea por un área geográfica extensa (a lo largo de un país),
llamadas redes de larga distancia; o en un área reducida (en un mismo edificio), llamadas redes de área
local. Para las primeras se utilizan en la comunicación líneas telefónicas, conexiones de microondas y
canales de satélites; mientras que para las segundas se utiliza cables coaxiales de banda base o banda
ancha y fibra óptica.

Diseño de la distribución:

5


Introducción

El diseño de un sistema de base de datos distribuido implica la toma de decisiones sobre la ubicación de
los programas que accederán a la base de datos y sobre los propios datos que constituyen esta última, a
lo largo de los diferentes puestos que configuren una red de ordenadores. La ubicación de los programas,
a priori, no debería suponer un excesivo problema dado que se puede tener una copia de ellos en cada
máquina de la red (de hecho, en este documento se asumirá que así es). Sin embargo, cuál es la mejor
opción para colocar los datos: en una gran máquina que albergue a todos ellos, encargada de responder a
todas las peticiones del resto de las estaciones − sistema de base de datos centralizado −, o podríamos
pensar en repartir las relaciones, las tablas, por toda la red. En el supuesto que nos decantásemos por
esta segunda opción, ¿qué criterios se deberían seguir para llevar a cabo tal distribución? ¿Realmente este
enfoque ofrecerá un mayor rendimiento que el caso centralizado? ¿Podría optarse por alguna otra
alternativa? En los párrafos sucesivos se tratará de responder a estas cuestiones.
Tradicionalmente se ha clasificado la organización de los sistemas de bases de datos distribuidos sobre
tres dimensiones: el nivel de compartición, las características de acceso a los datos y el nivel de
conocimiento de esas características de acceso (vea la figura 1). El nivel de compartición presenta tres
alternativas: inexistencia, es decir, cada aplicación y sus datos se ejecutan en un ordenador con ausencia
total de comunicación con otros programas u otros datos; se comparten sólo los datos y no los programas,
en tal caso existe una réplica de las aplicaciones en cada máquina y los datos viajan por la red; y, se
reparten datos y programas, dado un programa ubicado en un determinado sitio, éste puede solicitar un
servicio a otro programa localizado en un segundo lugar, el cual podrá acceder a los datos situados en un
tercer emplazamiento. Como se comentó líneas atrás, en este caso se optará por el punto intermedio de
compartición.

Respecto a las características de acceso a los datos existen dos alternativas principalmente: el modo de
acceso a los datos que solicitan los usuarios puede ser estático, es decir, no cambiará a lo largo del tiempo,
o bien, dinámico. El lector podrá comprender fácilmente la dificultad de encontrar sistemas distribuidos
reales que puedan clasificarse como estáticos. Sin embargo, lo realmente importante radica, estableciendo
el dinamismo como base, cómo de dinámico es, cuántas variaciones sufre a lo largo del tiempo. Esta
dimensión establece la relación entre el diseño de bases de datos distribuidas y el procesamiento de
consultas.

La tercera clasificación es el nivel de conocimiento de las características de acceso. Una posibilidad es,
evidentemente, que los diseñadores carezcan de información alguna sobre cómo los usuarios acceden a la
base de datos. Es una posibilidad teórica, pero sería muy laborioso abordar el diseño de la base de datos
con tal ausencia de información. Lo más práctico sería conocer con detenimiento la forma de acceso de los
usuarios o, en el caso de su imposibilidad, conformarnos con una información parcial de ésta.

El problema del diseño de bases de datos distribuidas podría enfocarse a través de esta trama de opciones.
En todos los casos, excepto aquel en el que no existe compartición, aparecerán una serie de nuevos
problemas que son irrelevantes en el caso centralizado.

A la hora de abordar el diseño de una base de datos distribuida podremos optar principalmente por dos
tipos de estrategias: la estrategia ascendente y la estrategia descendente. Ambos tipos no son excluyentes,
y no resultaría extraño a la hora de abordar un trabajo real de diseño de una base de datos que se
pudiesen emplear en diferentes etapas del proyecto una u otra estrategia. La estrategia ascendente podría

6


aplicarse en aquel caso donde haya que proceder a un diseño a partir de un número de pequeñas bases
de datos existentes, con el fin de integrarlas en una sola. En este caso se partiría de los esquemas
conceptuales locales y se trabajaría para llegar a conseguir el esquema conceptual global. Aunque este
caso se pueda presentar con facilidad en la vida real, se prefiere pensar en el caso donde se parte de cero
y se avanza en el desarrollo del trabajo siguiendo la estrategia descendente. La estrategia descendente
(vea la figura 2) debería resultar familiar a la persona que posea conocimientos sobre el diseño de bases
de datos, exceptuando la fase del diseño de la distribución. Pese a todo, se resumirán brevemente las
etapas por las que se transcurre.

Todo comienza con un análisis de los requisitos que definirán el entorno del sistema en aras a obtener
tanto los datos como las necesidades de procesamiento de todos los posibles usuarios del banco de datos.
Igualmente, se deberán fijar los requisitos del sistema, los objetivos que debe cumplir respecto a unos
grados de rendimiento, seguridad, disponibilidad y flexibilidad, sin olvidar el importante aspecto económico.
Como puede observarse, los resultados de este último paso sirven de entrada para dos actividades que se
realizan de forma paralela. El diseño de las vistas trata de definir las interfaces para el usuario final y, por
otro lado, el diseño conceptual se encarga de examinar la empresa para determinar los tipos de entidades
y establecer la relación entre ellas. Existe un vínculo entre el diseño de las vistas y el diseño conceptual. El
diseño conceptual puede interpretarse como la integración de las vistas del usuario, este aspecto es de
vital importancia ya que el modelo conceptual debería soportar no sólo las aplicaciones existentes, sino
que debería estar preparado para futuras aplicaciones. En el diseño conceptual y de las vistas del usuario
se especificarán las entidades de datos y se determinarán las aplicaciones que funcionarán sobre la base
de datos, así mismo, se recopilarán datos estadísticos o estimaciones sobre la actividad de estas
aplicaciones. Dichas estimaciones deberían girar en torno a la frecuencia de acceso, por parte de una
aplicación, a las distintas relaciones de las que hace uso, podría afinarse más anotando los atributos de la
relación a la que accede. Desarrollado el trabajo hasta aquí, se puede abordar la confección del esquema
conceptual global. Este esquema y la información relativa al acceso a los datos sirven de entrada al paso
distintivo: el diseño de la distribución. El objetivo de esta etapa consiste en diseñar los esquemas
conceptuales locales que se distribuirán a lo largo de todos los puestos del sistema distribuido. Sería
posible tratar cada entidad como una unidad de distribución; en el caso del modelo relacional, cada
entidad se corresponde con una relación. Resulta bastante frecuente dividir cada relación en subrelaciones
menores denominadas fragmentos que luego se ubican en uno u otro sitio. De ahí, que el proceso del
diseño de la distribución conste de dos actividades fundamentales: la fragmentación y la asignación. El
último paso del diseño de la distribución es el diseño físico, el cual proyecta los esquemas conceptuales
locales sobre los dispositivos de almacenamiento físico disponibles en los distintos sitios. Las entradas para
este paso son los esquemas conceptuales locales y la información de acceso a los fragmentos.

Por último, se sabe que la actividad de desarrollo y diseño es un tipo de proceso que necesita de una
monitorización y un ajuste periódicos, para que si se llegan a producir desviaciones, se pueda retornar a
alguna de las fases anteriores.

Diseño

Existen diversas formas de afrontar el problema del diseño de la distribución. Las más usuales se
muestran en la figura 3. 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

7


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.

Transparencia y Autonomía

En la sección anterior se vio que una relación r puede almacenarse de varias formas en un sistema de
base de datos distribuida. Es esencial que el sistema reduzca al mínimo la necesidad de que el usuario se
dé cuenta de cómo está almacenada una relación. Como veremos. un sistema puede ocultar los detalles
de la distribución de la información en la red. Esto se denomina transparencia de la red. La transparencia
de la red se relaciona, en algún modo, a la autonomía local. La transparencia de la red es el grado hasta el
cual los usuarios del sistema pueden ignorar los detalles del diseño distribuido. La autonomía local es el
grado hasta el cual el diseñador o administrador de una localidad pueden ser independientes del resto del

8


sistema distribuido. Los temas de transparencia y autonomía serán considerados desde los siguientes
puntos de vista:

• Nombre de los datos.
• Repetición de los datos.
• Fragmentación de los datos.
• Localización de los fragmentos y copias.

Asignación de nombres y autonomía local

Todo elemento de información de una base de datos debe tener un nombre único. Esta propiedad se
asegura fácilmente en una base de datos que no esté distribuida. Sin embargo, en una base de dalos
distribuida, las distintas localidades deben asegurarse no utilizar el mismo nombre para dos datos
diferentes.

Una solución para este problema es requerir que se registren todos los nombres en un asignador central
de nombres. Sin embargo, este enfoque tiene varias desventajas:

• Es posible que el asignador de nombres se convierta en un cuello de botella..
• Si el asignador de nombres se cae, es posible que ninguna de las localidades del sistema
distribuido pueda seguir trabajando.
• Se reduce la autonomía local, ya que la asignación de nombres se controla de forma centralizada.

Un enfoque diferente que origina una mayor autonomía local es exigir que cada localidad ponga como
prefijo un identificador de localidad a cualquier nombre que genere. Esto garantiza que dos localidades
nunca generarán el mismo nombre (ya que cada localidad tiene un identificador único). Además, no se
requiere un control central.

Esta solución al problema de asignación de nombres, logra autonomía local, pero no transparencia de la
red, ya que se agregan identificadores de localidad a los nombres. Así, la relación depósito podría llamarse
localidad17.depósito en vez de depósito simplemente.

Cada copia y fragmento de un elemento de información deben tener un nombre único. Es importante que
el sistema pueda determinar qué copias son copias del mismo elemento de información y qué fragmentos
son fragmentos del mismo elemento de información.

Transparencia de la repetición y la fragmentación

No es conveniente requerir que los usuarios hagan referencia a una copia específica de un elemento de
información. El sistema debe ser el que determine a qué copia debe acceder cuando se le solicite su
lectura, y Cuando se solicita un dato, no es necesario especificar la copia. El sistema utiliza una
tabla−catálogo para determinar cuáles son todas las copias de ese dato.

De manera similar, no debe exigirse a los usuarios que sepan cómo está fragmentado un elemento de
información. Es posible que los fragmentos verticales contengan id−tuplas, que representan direcciones
de tuplas. Los fragmentos horizontales pueden haberse obtenido por predicados de selección complejos.

9


Por tanto, un sistema de bases de datos distribuido debe permitir las consultas que se hagan en términos
de elementos de información sin fragmentar. Esto no presenta problemas graves, ya que siempre es
posible reconstruir el elemento de información original a partir de sus fragmentos. Sin embargo, este
proceso puede ser ineficiente.

Transparencia de localización

Si el sistema es transparente en cuanto a repetición y fragmentación, se ocultará al usuario gran parte del
esquema de la base de datos distribuida. Sin embargo, el componente de los nombres que identifican a la
localidad obliga al usuario a darse cuenta del hecho de que cl sistema está distribuido.

La transparencia de localización se logra creando un conjunto de seudónimos o alias para cada usuario.
Así, el usuario puede referirse a los datos usando nombres sencillos que el sistema traduce a nombres
completos.

Con el uso de seudónimos, no será necesario que el usuario conozca la localización física de un dato.
Además, el administrador de la base de datos puede cambiar un dato de una localidad a otra sin afectar a
los usuarios.

Esquema completo de asignación de nombres

Ya vimos que un nombre proporcionado por el usuario debe pasar por varios pasos de traducción antes de
que pueda servir como referencia a una copia específica de un fragmento determinado en una localidad
específica.

Para ilustrar cómo funciona el esquema, consideramos un usuario que se encuentra en la sucursal 1 (L1).
Este usuario emplea el seudónimo depósito−local para el fragmento local depósito−F1 de la relación
deposito.

Cuando este usuario hace referencia a depósito−local, el subsistema de procesamiento de consultas busca
depósito−local en la tabla de seudónimos y la sustituye por Ll.depósito.F1. Es posible que L1.depósito.Fl
esté repetido. Si es así, debe consultarse la tabla de copias para elegir una copia. Esta copia podría
también estar fragmentada, lo que haría necesario consultar la tabla de fragmentación. En la mayor parte
de los casos, sólo es preciso consultar una o dos tablas.

Transparencia y actualizaciones

De alguna forma es más difícil hacer transparente la base de datos para usuarios que la actualizan que
para aquellos que sólo leen datos. El problema principal es asegurarse de que se actualizan todas las
copias de un dato y también los fragmentos afectados. En el caso más general, el problema de
actualización de información repetida y fragmentada está relacionado con el problema de actualización de
vistas.

10


BASES DE DATOS ORIENTADAS A OBJETOS

INTRODUCCION

La mayoría de las aplicaciones actuales de bases de datos están basadas en tradicionales sistemas
manejadores de bases de datos (SMBD). Con la madurez que han cobrado los sistemas orientados a
objetos en el mercado y la creciente popularidad del modelo Entidad Vínculo Extendido (EVE), es
necesario encontrar respuesta a las siguientes preguntas:

• ¿Cómo mapear un esquema EVE a su esquema correspondiente orientado a objetos?
• ¿Cómo hacer la reingeniería de anteriores aplicaciones convencionales para producir bases de
datos orientadas a objetos?

Muchas organizaciones que actualmente usan tecnología orientada a objetos también desean los
beneficios de los OODBMS (Object Oriented DataBase Management System). En otras palabras, se desea
la migración de bases de datos y aplicaciones de bases de datos relacionales a orientadas a objetos. La
migración a la tecnología de objetos consiste de la ingeniería reversa de los programas de aplicación y la
migración de la base de datos.

El objetivo de la migración de la base de datos es tener un esquema equivalente y la base de datos
disponibles bajo los nuevos OODBMS. Esto desde luego puede ser logrado por medio de la transformación
manual del código de los programas lo cual resulta demasiado complicado. Para esto existen tres enfoque
que hacen uso de la tecnología de objetos para bases de datos relacionales.

• Construir una interfase orientada a objetos sobre el sistema de base de datos relacional.
• La migración a un sistema de base de datos relacional/objetos.
• Conversión del esquema de base de datos relacional a uno orientado a objetos.

El primer enfoque retiene la base de datos relacional y crea una interfase orientada a objetos encima de
ésta. Este enfoque es el mas fácil; no existe interrupción del sistema para la migración de datos y no
existe perdida semántica de la información. Por otro lado el rendimiento disminuye debido que no existe
un buen acoplamiento entre los dos paradigmas en el tiempo de ejecución.

En el segundo enfoque, los datos deben ser migrados de acuerdo con el DBMS (por ejemplo Oracle 7 a 8),
y las características orientadas a objetos solo pueden ser explotadas con la modificación o extensión del
esquema.

El tercer enfoque es la migración de la base de datos en donde un nuevo esquema bajo el OODBMS es
creado y los datos son migrados de la base de datos relacional a la orientada a objetos.

Cada uno de los tres enfoques anteriores tiene sus ventajas y desventajas. Especialmente el tercero, una
metodología y herramientas de soporte son críticas para una migración exitosa.

11


TRANSFORMACIÓN DE ESQUEMAS RELACIONALES A OBJETOS

Formación de Tipos de Entidades Complejas

Consiste en agrupar recursivamente entidades y vínculos de un esquema EVE, usando abstracciones
semánticas como la agregación, generalización y asociación. Algunas variaciones a la técnica de formación
de clusters es útil no solo para mejorar el entendimiento del esquema conceptual de la base de datos y su
complejidad asociada, también contribuye a la formación de entidades complejas, y por lo tanto puede ser
usada como paso importante en el proceso de mapeo de un diagrama inicial EVE a un esquema orientado
a objetos.

La Técnica de Formación de Clusters

El procedimiento consiste en realizar iterativamente de forma arriba-abajo y empezando de entidades
atómicas en el esquema EVE y construir entidades mas complejas (clusters de entidades) hasta que el
nivel de abstracción n sea alcanzado, o hasta que no existan mas operaciones de clusters por realizar. El
nivel n de clusters representa la profundidad deseable de jerarquías de agregación en el esquema de
objetos complejos.

Para asegurar una alta cohesión semántica de las entidades complejas, las operaciones de agrupación se
realizan con un orden de prioridad (precedencia). Este orden es definido en términos del concepto de
cohesión, para representar el grado de importancia de los vínculos entre las entidades en una entidad
cluster.

Operaciones de Agrupamiento y Orden de Prioridad

El orden de prioridad se aplica como se especifica a continuación: Cuando una entidad E tiene vínculos
con ordenes de prioridad k y k+1, entonces el agrupamiento de orden k es el seleccionado. Cuando una
entidad E es candidato a dos agrupamientos de la misma prioridad (excepto para la absorción de entidad
débil), entonces se tomarán en cuenta las reglas adicionales que se detallan posteriormente.

Absorción de Entidad Débil

Una entidad fuerte E es colapsada con todas sus entidades dependientes directas para formar una entidad
compleja única y cuya etiqueta corresponde al nombre de la entidad débil. Los vínculos débiles así como
los vínculos uno-a-muchos y sus correspondientes entidades asociadas a E son también absorbidas en la
entidad compleja. En la presencia de una secuencia de entidades y vínculos débiles, el agrupamiento
empieza con la entidad mas dependiente y ensambla entidades en cascada.

Agrupación Dominante

Definimos como entidad dominante a aquella entidad que se encuentra en asociación binaria con al menos
dos entidades por un vínculo uno-a-muchos. La agrupación dominante consiste en ensamblar una entidad
dominante con sus vínculos y entidades relacionadas. El nombre de la entidad cluster es idéntico al
nombre de la entidad dominante.

12


Agrupación por Generalización y Categorización

La agrupación por generalización/categorización consiste en crear entidades complejas cuyo nombre es
idéntico al nombre del supertipo/categoría y cuyos componentes son los subtipos/supertipos inmediatos
de la entidad generalizada o categoría. Una categoría es definida como un subconjunto de la unión de
algunas clases.

Agrupación de Vínculos

Los vínculos n-arios de cualquier grado pueden ser agrupados en entidades cluster, reflejando la
semántica de los vínculos como un todo. El nombre de la entidad cluster no es necesariamente idéntico al
nombre del vínculo. Este último corresponde al nombre del vínculo especialmente cuando la asociación es
un vínculo binario muchos-a-muchos o un vínculo n-ario. En el proceso de mapeo, la traslación de una
entidad cluster obtenida por la formación de clusters de vínculos toma en cuenta la naturaleza de las
entidades en relación: entidades llave, participación mandatoria/opcional, y el número de asociaciones en
la cual la entidad está involucrada.

Reglas Adicionales

Se definen a continuación cuatro reglas adicionales las cuales auxilian para preservar la secuencia lógica y
natural de visualizar la base de datos a diferentes niveles de abstracción, para mantener toda la semántica
de los datos, y para manejar algunas situaciones de conflicto.
Agrupamiento Paso a Paso
- Cuando se está formando un nuevo grupo en el esquema Ci (esquema con nivel de cluster i), el
resultado es un esquema Ci+1 debido a que por lo menos una operación de agrupamiento es realizada en
Ci. Al esquema inicial se le asigna en nivel 0.

- Si la operación de formación de clusters n-esima en el nivel i es realizada alrededor de la entidad E,
entonces esto conduce a una entidad cluster con una etiqueta, y un nivel expresado por <i.n>. La
etiqueta de la entidad compleja depende del tipo de cluster: es el nombre de la entidad dominante ( o
fuerte, generalizada o categoría), o el nombre del vínculo si es un vínculo binario muchos-a-muchos o un
vínculo ternario.

- Una operación de agrupamiento no puede ser realizara en el nivel i si involucra entidades complejas
recientemente formadas en el mismo nivel, por lo tanto debe ser pospuesta hasta el siguiente nivel.

Consistencia
Para evitar la posibilidad de pérdida de la semántica asociada con los datos, y para preservar los vínculos
iniciales dentro y fuera de las entidades complejas, se realiza lo siguiente: cuando un componente (o
subcomponente) Ei de una entidad compleja Ej tiene vínculo (ISA-A o asociación) con otra entidad, el lado
apropiado de este vínculo será etiquetado por Ej-1...Ei representando la trayectoria necesaria para
alcanzar el componente Ei dentro de Ej.
Cascadeo
Si una entidad Ei es candidato tanto para la operación de formación de un cluster de cualquier tipo
(absorción de entidad débil, agrupación dominante, generalización/categorización o por vínculos) como
una entidad esclavo (i.e. componente de una entidad compleja potencial E); así como también candidato

13


para la operación de formación de cluster como una entidad maestro (i.e. una entidad cuyo nombre es
idéntico al nombre del cluster potencial como son entidades dominantes/fuertes, entidades generalizadas
y entidades del lado uno en un vínculo uno-a-muchos) entonces la operación de formación de cluster
interna (i.e.la que involucra Ei como maestro) es aplicada antes del agrupamiento que involucra Ei como
esclavo. Un caso especial, en la presencia de secuencias de entidades débiles con sus correspondientes
vínculos, el agrupamiento de absorción empieza de la entidad y vínculo mas dependientes, y formando
iterativamente entidades complejas hasta que la entidad fuerte sea encontrada.
Visibilidad/Invisibilidad de Entidades
En todos los sistemas de información, existen entidades que son relevante a muchos procedimientos y
necesidades de usuarios. En general estas entidades en cierta forma deben ser visibles en cualquier nivel
de abstracción del esquema inicial, y no deben ser escondidas dentro de alguna entidad compleja. Por lo
tanto, cualquier operación de agrupamiento que encapsule una entidad llave está prohibida.

Mapeo del Esquema EVE con Clusters a un Esquema Orientado a Objetos

La etapa de mapeo de un esquema EVE con clusters a un esquema orientado a objetos maneja la
descripción de objetos complejos y toma en cuenta los vínculos y restricciones semánticas

Definición 1. Definimos un esquema de base de datos orientado a objetos estructuradamente como un par
(S,Sigma) que consiste de una colección de tipos de entidades E1 ,..., Em cerrados bajo referencias y
supertipos, y un conjunto Sigma de restricciones de integridad inter-entidades. Un tipo de entidad Ei
puede ser descrito por las siguientes propiedades:

- Supertipos: conjunto de supertipos de Ei .

- Estructura: agregación de atributos (atómicos o complejos) Aj relacionados con los tipos propios o
definidos por el usuario.

- Vínculos: conjunto de asociaciones en las cuales Ei participa.

- Especializaciones: conjunto de especializaciones <Sub,CD,Herencia>, donde Ei es la entidad
generalizada.

- Categoría: descripción de los supertipos que participan en la unión (si es aplicable).

- Restricciones: conjunto de restricciones inter-entidad.

Las entidades generalizadas son definidas por la tripleta <Sub,CD,Herencia>, donde:

* Sub representa las entidades que especializan el supertipo.

* CD es un par de dos valores booleanos que indican si la generalización es completa o no y si las
instancias de subtipos se traslapan o no.

* Herencia indica como los subtipos son formados.

14


Debido a que una misma entidad puede ser una generalización para mas de un criterio de especialización,
existen tantas tripletas como tipos de especialización para esa entidad.

La extensión de Ei es el conjunto de objetos Oi1 ,..., Oip cuyo tipo es Ei . Una extensión D de la base de
datos de un esquema Ses el conjunto de todas las instancias de las entidades en S las cuales verifican
todo el conjunto de restricciones de integridad intra e inter-entidades.

Reglas de Transformación

Una vez que el diagrama de objetos complejos es producido, la descripción del esquema OO entonces
puede ser producida. Existen al menos dos tipos de mapeos para un diagrama entidad-vínculo a un
esquema OO: el primer tipo, llamado traducción estable consiste en convertir cada entidad y cada vínculo
en un objeto, mientras que el segundo, llamado traducción mapeada, consiste en integrar un vínculo en
una clase de objeto usando referencias, y creando una clase de objeto para cada vínculo ternario.

Definimos una entidad Ej en el esquema inicial (es decir que no este en clusters) como un candidato
potencial para absorción por otra entidad Ei cuando ocurre uno de los siguientes casos:

- Ej es solamente un vínculo 1:1 o uno 1:N o solamente un vínculo ternario que involucra Ei , y Ej no tiene
otra asociación en el esquema bajo consideración.

- Ej es una entidad débil con respecto a Ei y participa solo a vínculos débiles (si existe alguno) como una
entidad fuerte.

El proceso de traducción es el siguiente:

- Cada entidad del diagrama EVE con clusters es mapeado a un tipo de objeto. La estructura del tipo de
objeto complejo depende de las operaciones de agrupamiento usadas para la formación de la entidad
compleja. Excepto para entidades que son candidatos para absorción, cada componente del objeto
complejo es recursivamente mapeado a un tipo de objeto. Los atributos multivaluados son expresados
usando el conjunto o lista de constructores. Los atributos agregados son expresados usando el constructor
de tuplas.

- Dependiendo de la paridad del vínculo y de las cardinalidades (mimimal y maximal) de las asociaciones,
cada vínculo es mapeado ya sea a un nuevo atributo (tanto referencias a tipos de objetos o atributos
actuales) agregadas a las entidades apropiadas; o nuevas entidades haciendo referencia a las entidades
concernientes.

Es importante notar que durante el proceso de traducción e independientemente de la forma en que
fueron formadas las entidades complejas Ei , la referencia a una entidad Ej dentro de una entidad Ei
puede tomar una de las siguientes formas:

- la estructura actual (atributos) de Ej cuando Ej es candidato a absorción por Ei

- un atributo referencia (apuntador) en cualquier otro caso.

15


Absorción de entidad débil y agrupación dominante.

Para este tipo de agrupación, es creado un tipo complejo como una agregación de la entidad
fuerte/dominante y las entidades débil/relacionadas. Cada vínculo dentro de la agrupación es mapeado a
una atributo referencia cuyo nombre es la etiqueta del vínculo, y cuyos tipos conforman el tipo de entidad
débil/relacionadas.

Agrupamiento de Vínculos

Existen dos enfoques para la traducción de vínculos: uno que describe explícitamente los vínculos como
una estructura clase. El segundo enfoque mapea los vínculos en un par de referencias directa e inversa.
En este último caso, los atributos referencia son usados para expresar los vínculos entre objetos y
asegurar la navegación en una o ambas direcciones. Para describir los vínculos inversos, son usados
atributos referencia inversos.

• Traducción de Vínculos uno-a-uno

La traducción de vínculos uno-a-uno depende del tipo de las dos entidades (entidades llave o
entidades no llave) y sus cardinalidades minimales en el vínculo (participación opcional vs.
mandatoria), y sobre el número de otras asociaciones en la cual cada una de las dos entidades se
encuentra involucrada).

• Traducción de direcciones uno-a-muchos

Para agrupamiento de vínculos binarios uno-a-muchos, tenemos que agregar la entidad en la
parte del lado "uno" con la parte del lado "muchos" que corresponde a las múltiples ocurrencias
de las entidades débil/relacionadas por una ocurrencia de la entidad fuerte, seguida por los
atributos conectados al vínculo si existe alguno.

• Traducción de vínculos muchos-a-muchos y ternarios

Para vínculos muchos-a-muchos y ternarios, una nueva estructura es creada por medio de la
agregación de referencias a las entidades participantes así como los atributos asociados con los
vínculos.

Generalización/Categorización

La definición de una entidad generalizada incluye la especificación del vínculo generalizado descrito por la
tripleta <Sub,CD,Herencia> así como su estructura. El mapeo de una entidad generalizada y sus entidades
especializadas puede ser percibida como una traducción de vínculos 1:1 entre la entidad generalizada y
cada uno de sus subtipos.

Una categoría es descrita en un esquema OO principalmente por el significado de dos de sus propiedades:
su estructura y sus superclases. La estructura es la agregación del nombre de la superclase apropiada
junto con un atributo referencia a la instancia de esa superclase. La segunda propiedad enumera las
superclases participantes.

16


La elección de un mapeo dado depende también de:

- El patrón de uso esperado.

- La evolución esperada del esquema de base de datos.

- Las peculiaridades de los OODBMS que se encuentran aún en consideración.

GEMSTONE

GemStone fue originalmente creado específicamente como un DBMS Smalltalk. La mayoría de los ODBMS
han usado C++. En 1987, Smalltalk era de muy poco interés. Curiosamente, Smalltalk por si mismo
provee un tipo de funcionalidad de base de datos: es un ambiente de programación en el cual clases
predefinidas son almacenadas en una imagen de sistema. Desafortunadamente, la imagen Smalltalk es
estrictamente para usuario único y no ofrece soporte para acceso concurrente.

GemStone fue introducido en 1987 y es el ODBMS comercial con mas tiempo en el mercado. GemStone es
particularmente preferible para ser usado en aplicaciones cliente/servidor multiusuario y multiplataforma,
soporta acceso concurrente de múltiples lenguajes, incluyendo Smalltalk-80, Smalltalk/V, C++ y C.
GemStone también provee un dialecto de Smalltalk (Smalltalk DB, formalmente conocido como OPAL)
como DDL y DML internos, los cuales pueden ejecutar métodos o aplicaciones enteras en la base de datos.

Características Principales

Base de Datos Activa
GemStone permite a desarrolladores de aplicaciones escribir métodos los cuales son almacenados y
ejecutados directamente en la base de datos. Estos métodos pueden ser accesados ya sea internamente o
por aplicaciones cliente externas. Esto puede reducir significativamente el tráfico en la red y permitir a las
aplicaciones tomar ventaja del poder superior de cómputo de el servidor. También elimina la necesidad de
cambiar las aplicaciones cuando las condiciones de negocios cambian.
Soporte Concurrente para Múltiples Lenguajes
GemStone provee soporte concurrente para aplicaciones desarrolladas con Smalltalk, C++, C y con la
herramienta de desarrollo propia de GeODE. Todas las aplicaciones, independientemente del lenguaje en
que estén escritas, pueden tener acceso simultaneo a los mismos objetos de la base de datos.

La Interfase C de GemStone es una librería de funciones que pueden ser llamadas desde lenguajes que
permiten llamadas a funciones C, incluyendo Ada, COBOL, Pascal, FORTRAN, LISP, y C Objetivo.

La Interfase C++ de GemStone provee almacenamiento persistente para aplicaciones C++. Una vez
almacenados en GemStone, los objetos C++ toman una identidad propia y existen independientemente de
los programas que los crearon. Estos pueden ser usados por otros programas, incluso aquellos escritos en
otros lenguajes.

Control de Transacciones Multiusuario Flexibles

17


Usuarios múltiples pueden operar en la base de datos simultáneamente, con una variedad de modos para
el control de transacciones disponibles (como bloqueo optimista o pesimista).
Seguridad a Nivel de Objeto
El control de autorización puede ser aplicado a cualquier objeto en la base de datos, permitiendo una
refinación de la seguridad de objetos.
Esquema Dinámico y Evolución de Objetos
GemStone soporta la modificación de esquema través del versionamiento de clases y permite total
migración de objetos entre versiones de sus clases con un simple envío de mensajes. La migración es
totalmente personalizadle y puede ser revertida.
Servicios de Producción
GemStone incluye características requeridas por bases de datos de producción, incluyendo respaldo en
línea, recuperación por falla rápida, integridad referencial, señalización de eventos, notificadores y control
de concurrencia incluyendo control optimista, pesimista y basado en el comportamiento.
Escalabilidad
GemStone tiene la capacidad para soportar 1,000 logins y 100 usuarios activos concurrentemente en un
servidor SMP de tamaño mediano. Esta característica indica que GemStone es lo suficientemente poderoso
por lo menos para aplicaciones departamentales.
Gateways
GemStone incorpora gateways o bridges (puentes) de datos que permiten a aplicaciones de objetos
integrar datos válidos, en formatos SQL, IMS, VSAM y otros. El nivel de integración entre GemStone y
datos válidos y aplicaciones puede variar desde un simple query hasta intensiva interoperabilidad de
lectura/escritura. Esta nueva característica es particularmente útil en el papel que desempeña GemStone
como servidor de aplicaciones, como una de las principales tareas de este servidor para mapear peticiones
de clientes en una variedad de administradores de datos.
Arquitectura
GemStone fue diseñado como un sistema cliente-servidor y consiste de dos tipos de procesos: El Gem y el
Stone, y el GemStone Smalltalk Interfase (GSI).

* El Gem es el front-end, y puede correr ya sea en el cliente o en el servidor, esto dependiendo de las
consideraciones como el tráfico en la red y el rendimiento. Maneja la compilación Smalltalk y provee una
librería de clases predefinidas de cerca de 500 clases y 12,000 métodos. Cuando es remoto al Stone, el
Gem puede ser configurado para buscar, almacenar en cache o bloquear páginas, objetos, o segmentos
de datos completos. Cada Gem toma aproximadamente 1MB de RAM, y esto pone un límite práctico al
número de usuarios simultáneos soportados. Una máquina de 32 bits tiene un espacio de
direccionamiento virtual de 4GB, y puede tener hasta 1GB de RAM física. La mitad de la cual es asignada
al cache, y los restantes 500MB son suficientes para 500 usuarios.

* El Stone es el administrador de datos, el se ejecuta siempre en el servidor. Este ve después del núcleo
de la base de datos, funciones como E/S de disco, concurrencia, transacciones, recuperación y seguridad.
Existe un Stone por base de datos.

* El GSI siempre se ejecuta en el cliente. Traduce clases Smalltalk y mantiene la coherencia de cache, la
cual permite la ejecución de métodos en el servidor y asegura una vista consiste de la base de datos a
todos los clientes. Existen dos versiones de GSI disponibles: una versión enlazada, la cual comparte el
mismo espacio de direccionamiento con el Gem; y una versión RPC, la cual permite al GSI ser ejecutado
en una máquina remota.

18


Los son automáticamente recolectados a la basura cuando no son referenciados por ningún otro objeto.

Caso de Estudio

A continuación se realizará la transformación del caso de estudio de la base de datos académica
anteriormente analizada con el modelo EVE. Para esto partiremos del siguiente esquema de base de datos.

En este caso las reglas de agrupación de objetos complejos se aplican como sigue:

En primer lugar se aplica la regla de absorción de entidad débil en el recuadro marcado con 1.1.
Posteriormente se aplica la regla de agrupación dominante, en la cual la entidad dominante es
ALUMNO y las entidades absorbidas son: BECAS, DES_PROF y DISTINCIONES, ésta operación está
marcada en el recuadro 2.1.
En el mismo nivel de agrupación se realiza la operación de la generalización en la cual las entidades
subtipos ESPECIALES y BASICAS son agrupadas en una entidad compleja y la etiqueta correspondiente es
la del supertipo, que en este caso es FORMACION ACADEMICA. Esta operación de agrupamiento está
marcada con el recuadro 2.2.
Por último el nivel de agrupamiento más alto corresponde a la formación de la entidad compleja en la
cual la entidad compleja es absorbida por la entidad llave ALUMNO.

19


después de aplicar las reglas anteriores, el diagrama EVE se reduce únicamente a una sola entidad
compleja, la cual posteriormente será utilizada para su implantación haciendo uso de un OODBMS, como
es GemStone.

20

Resumen de conceptos_final

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Resumen de conceptos_final

Similar a Resumen de conceptos_final (20)

Resumen de conceptos_final