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)

1

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.




2

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.




3

• 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




4

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:




5

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:




6

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




7

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




8

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




9

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.




10

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.




11

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.




12

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.




13

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




14

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.




15

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.




16

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.




17

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




18

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.




19

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.




20

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.

resumen de conceptos_final

Documents