MODELOS AVANZADOS DE BASE DE DATOS 1
BASES DE DATOS XML
En la actualidad, existen diferentes soluciones para el almacenamiento de documentos XML que según WESTERMAN WESTERMAN Y KLAS (2003), se pueden clasificar en dos conjuntos: las bases de datos nativas como Tamino (SOFTWARE AG, 2001) o ToX (BARBOSA, ( BARBOSA, 2001); y extensiones XML a las bases de datos, que permiten permiten el almacenamiento de documentos documentos XML en SGBD convencionales, normalmente relacionales u objeto-relacionales.
1.1
Bases de datos XML nativas
Las bases de datos XML surgen por la necesidad de una gestión eficiente de grandes cantidades de documentos XML, argumentando que los documentos XML no se pueden almacenar en SGBD convencionales debido a su naturaleza jerárquica y semi estructurada. Los productos de bases de datos XML nativas, están centrados en el almacenamiento y gestión de documentos XML. Este tipo de gestores tienen las siguientes características: Definen un modelo para estructura de los documentos XML (por ejemplo un DTD). Corresponde al modelo relacional de las l as BD clásicas.
Almacenan y recuperan documentos de acuerdo a ese modelo. Los documentos XML son, por tanto, la unidad de almacenamiento. almacenamiento. Corresponden a las tuplas del del modelo relacional. Para el almacenamiento final, el gestor puede tener su propio modelo de almacenamiento, es decir, no se requiere un modelo subyacente concreto (puede ser una base de datos relacional, OO o jerárquica; o un formato de almacenamiento propietario).
1.2
Extensiones XML a las bases de datos
Las extensiones XML a las bases de datos permiten el almacenamiento y la gestión de documentos XML en SGBD convencionales, habitualmente relacionales u objeto-relaciones (OR). Existen diferentes aproximaciones para el almacenamiento:
Almacenamiento no estructurado: los documentos XML se almacenan directamente en formato de texto en un atributo de tipo fichero, como por ejemplo, CLOB (Carácter ). Large Object Object ).
Almacenamiento estructurado: se usa un metamodelo de documentos XML capaz de representar árboles de nodos de documentos XML, que se construye c onstruye utilizando primitivas de modelado del SGBD convencional que hay por debajo. La estructura de los documentos XML se convierte en el esquema de base de datos. El contenido de los documentos XML se puede consultar utilizando las facilidades proporcionadas proporcionadas por el SGBD.
Las bases de datos XML están orientadas a definir un estándar de consulta para integrar información de varias aplicaciones. Las bases de datos XML utilizan un lenguaje de marcado común a todas las aplicaciones que operan con ellas. Las bases de datos XML utilizan un sistema persistente más parecido a las bases de datos tradicionales, cualquier modificación sobre los datos sobreescriben los anteriores si no se tiene
XML no es en sí un lenguaje de base de datos, debido a la alta redundancia que presenta, al tener que repetir etiquetas para todas las ocurrencias de un mismo campo. Las bases de datos XML están muy ligadas a un entorno web.
1.3
EJEMPLO
Una gran parte de usos necesita encontrar documentos enteros. Por ejemplo, un portal Web podría permitir a usuarios buscar todos los documentos sobre una empresa particular y un sistema de dirección podría permitir a usuarios encontrar todos los documentos que se relacionen con una cierta parte. El modo menos complejo de buscar documentos es con búsquedas texto completas. En bases de datos natales XML, estos son XML-aware. Es decir esto distingue entre el contenido (que es buscado) y el margen (que no es).
2. BASE DE DATOS ACTIVAS El paradigma de bases de datos activas planteado por Morgenstern en 1983, describe la noción de una base de datos activa, como una metáfora de su comportamiento, el cual se concentra” en la dinámica
de la interacción con los usuarios unido a la “inteligencia” de la base de datos ” . Una base de datos activa, son aquellas bases de datos capaz de detectar situaciones de interés y de actuar en consecuencia. (Mota Noviembre 2005). El mecanismo que se utiliza se parece a las reglas de producción utilizadas en el área de inteligencia artificial.
2.1 REPRESENTACIÓN DE UNA BASE DE DATOS ACTIVA El poder especificar reglas con una serie de acciones que se ejecutan automáticamente cuando se producen ciertos eventos, es una de las mejoras de los sistemas de gestión de bases de datos que se consideran de gran importancia desde hace algún tiempo. Mediante estas reglas se puede hacer respetar reglas de integridad, generar datos derivados, controlar la seguridad o implementar reglas de negocio. De hecho, la mayoría de los sistemas relacionales comerciales disponen de disparadores (triggers). Se han realizado mucha investigación sobre lo que debería ser un modelo general de bases de datos activas desde que empezaron a aparecer los primeros disparadores. El modelo que se viene utilizando para especificar bases de datos activas es el modelo evento – condición – acción (ECA).
2.2 VENTAJAS * Mayor productividad. * Mejor rendimiento. * Reutilización del código. * Reducción de tráfico de datos. * Posibilidad de optimización. * Facilitar el acceso de la BD a usuarios finales.
* Un SGBDA tiene un modelo de reglas ECA. * Un SGBDA debe so portar la gestión de reglas y la evolución de la base de reglas
2.4 CARACTERISTICAS DE LA EJECUCION DE LAS REGLAS * Un SGBDA no tiene un modelo de ejecución. * un SGBDA debe ofrecer diferente modelos de acoplamiento. * un SGBDA debe implementar modos de consumo. * un SGBDA debe gestionar la historia de eventos. * un SGBDA debe implementar la resolución de conflictos.
2.5 REGLAS ACTIVAS las reglas que siguen el modelo ECA: Cada regla reacciona ante un determinado evento, evalúa una condición y, si esta es cierta se ejecuta una acción. Se encarga de detectar los eventos que vas sucediendo y de planificar las reglas que se ejecuten.
2.6 TRIGGER Un trigger (Disparador) es un procedimiento que el SGBD invoca automáticamente en respuesta a cambios concretos de la BD. Generalmente un Trigger es invocado por el DBA(Administrador la Base de Datos). Las BD que tienen un conjunto de triggers asociados se denominan Base de Datos Activas. Un Trigger está compuesto por tres partes:
Evento: Una modificación en la BD que activa el trigger. Las operaciones que pueden activar un trigger son: DELETE, UPDATE, INSERT, etc.
Condición: una consulta o prueba se ejecuta cuando se activa un trigger. Acción: un procedimiento que se ejecuta cuando se activa el trigger y su condicon es verdadera.
3. BASE DE DATOS DEDUCTIVAS Un Sistema de Bases de Datos que tenga la capacidad de definir reglas con las cuales deducir o inferir información adicional a partir de los hechos almacenados en las bases de datos se llama Sistema de Bases de Datos Deductivas . Puesto que parte de los fundamentos teóricos de algunos sistemas de ésta especie es la lógica matemática, a menudo se les denominaBases de Datos
Un sistema de base de datos deductiva, es un sistema de base de datos pero con la diferencia de que permite hacer deducciones a través de inferencias. Se basa principalmente en reglas y hechos que son almacenados en la base de datos. Las bases de datos deductivas son también llamadas bases de datos lógicas, a raíz de que se basa en lógica matemática. Este tipo de base de datos surge debido a las limitaciones de la Base de Datos Relacional de responder a consultas recursivas y de deducir relaciones indirectas de los datos almacenados en la base de datos. 3.1 Lengu aje Utiliza un subconjunto del lenguaje Prolog llamado Datalog el cual es declarativo y permite al ordenador hacer deducciones para contestar a consultas basándose en los hechos y reglas almacenados.
3.2 Vent ajas
Uso de reglas lógicas para expresar las consultas.
Permite responder consultas recursivas.
Cuenta con negaciones estratificadas
Capacidad de obtener nueva información a través de la ya almacenada en la base de datos mediante inferencia.
Uso de algoritmos de optimización de consultas.
Soporta objetos y conjuntos complejos.
3.3 Desven tajas
Crear procedimientos eficaces de deducción para evitar caer en bucles infinitos.
Encontrar criterios que decidan la utilización de una ley como regla de deducción.
Replantear las convenciones habituales de la base de datos.
3.4 Fases
Fase de Interrogación: se encarga de buscar en la base de datos informaciones deducibles implícitas. Las reglas de esta fase se denominan reglas de derivación.
Fase de Modificación: se encarga de añadir a la base de datos nuevas informaciones deducibles. Las reglas de esta fase se denominan reglas de generación.
3.5 Interpr etación Encontramos dos teorías de interpretación de las bases de datos deductiva consideramos las reglas y los hechos como axiomas. Los hechos son axiomas base que se consideran como verdaderos y no contienen variables. Las reglas son axiomas deductivos ya que se utilizan para deducir nuevos hechos.
Teoría de Modelos: una interpretación es llamada modelo cuando para un conjunto específico de reglas, éstas se cumplen siempre para esa interpretación. Consiste en asignar a un predicado todas las combinaciones de valores y argumentos de un dominio de valores constantes dado. A continuación se debe verificar si ese predicado es verdadero o falso.
3.6 ] M e c a n i s m o s
Ascendente: donde se parte de los hechos y se obtiene nuevos aplicando reglas de inferencia.
Descendente: donde se parte del predicado (objetivo de la consulta realizada) e intenta encontrar similitudes entre las variables que nos lleven a hechos correctos almacenados en la base de datos.
4. BASE DE DATOS DIFUSAS Las bases de datos difusas nacen de unir la teoría de base de datos ,principalmente con el modelo relacional con la teoría de conjuntos difusos para permitir: el almacenamiento de infromacion difusa, y el tratamiento y consulta de esta información de forma difusa o flexible.
4.1 Modelos de Implementación El problema de la implementación de los sistemas gestores de bases de datos difusas ha sido tratado en dos vertientes principales: •
Iniciar con un sistema gestor de bases de datos relacionales (SGBDR) con información precisa y desarrollar una sintaxis que permita formular consultas imprecisas, lo cual da origen a extensiones SQL, como Fuzzy SQL, con capacidades de manejar la imprecisión.
•
Construir un gestor de bases de datos relacionales difusas (SGBDRD) prototipo que implemente un modelo concreto de base de datos relacional difusa en el que la información imprecisa pueda ser almacenada. Dentro de esta vertiente existen dos grandes ramas: Los modelos a través de unificación por relaciones de similitud y los modelos relacionales basados en distribuciones de probabilidades.
Particularmente me enfocaré a los trabajos desarrollados en la Universidad de Granada, España por un grupo de investigadores que se encuentran trabajando en esta rama actualmente. Los elementos relacionados con la manipulación de información difusa pueden tener representaciones diferentes. Por ejemplo, una distribución normalizada de probabilidades puede ser representada por diferentes tipos de funciones (trapezoidal, triangular, intervalar, etc.). Lo más usual, es que se usen funciones de tipo trapezoidal. Lo mismo puede decirse de la forma en la que se modelan los operadores relacionales difusos así como los demás elementos difusos que aparezcan en el sistema. El criterio empleado para seleccionar la forma de representación de los múltiples elementos difusos del sistema manejador de base de datos, puede afectar de manera determinante la funcionalidad y desempeño de la base de datos, por lo que debería ser uno de los puntos centrales en los que el experto ajuste la arquitectura del FRDBMS al problema específico a tratar mediante el mismo. Puede decirse entonces que este criterio de selección y ajuste constituye un paso entre la formulación de una base de datos relacional difusa y la implementación de un sistema basado en la misma.
Datos Precisos : Manejados usualmente mediante la representación provista por la base de datos relaci
Datos Imprecisos Los modelos usualmente consideran dos tipos de representación para los datos imprec isos. además de la información desconocida o indeterminada que se maneja mediante lo ti pos unknown, undefined y null:
4.2 Manejo de las BDRD Para el manejo de las bases de datos relacionales difusas (BDRD) se utiliza el lenguaje Fu zzy SQL (FSQL) que es un lenguaje que deriva de SQL, incorporando las siguientes novedades.
Etiquetas Lingüísticas :En las sentencias FSQL las etiquetas van precedidasdel símbolo $, para poder distinguirlas fácilmente. Comparadores Difusos: Permiten comparar dos atributos o un atributo con una const
ante.
Conectivas Lógicas:Pueden usarse NOT, AND y OR, para enlazar condiciones difus as simples. Umbral de Cumplimiento (threshold) :Tras cada condición simple puede imponerse un umbral de cumplimiento mínimo (por defecto es 1), con el siguiente formato:
THOLD La palabra reservada THOLD es opcional y puede sustituirse por un compa rador tradicional (=, <, <=...) modificando el sentido de la consulta. Por defecto es equival ente al comparador >=. Constantes Difusas:
Pueden usarse en el SELECT todas las constantes difusas ya definidas: UNKNO WN,UNDEFINED y NULL, $[a,b,c,d] (Distrib. de posibilidad Trapezoidal ), $label (Etiquetas), [n,m] (Intervalo) y #n (valores aproximados).
Función CDEG():
Usada en la lista de selección, la función CDEG calcula, para cada tupla, el grado de cumplimiento del atributo del argumento en la condición de la cláusula WHERE.
Función CDEG(*):
Calcula el grado de cumplimiento de cada tupla en la condición de forma global, para todos sus atributos y no sólo para uno de ellos en particular La función CDEG usa, por defecto, los operadores típicos para la negación (1 – x), conjunción (t-norma del mínimo) y disyunción (s-norma del máximo), pero pueden usarse otros (si se definen).
Carácter Comodín %:
Similar al carácter comodín * de SQL, pero este incluye además la funciónCDEG aplicada a todos los atributos de la condición. No incluye CDEG(*).
Cuantificadores Difusos :
Tiene dos modalidades que se aplican como condición en la cláusula HAVING que sigue a una cláusula GROUP BY: o “Q elementos de X cumplen A”: $Cuantificador FUZZY[r] (condición_difusa) THOLD γ Ejemplos
•
“Dame todas las personas cuya edad es aproximadamente 20 años”: (con grado mínimo 0.6):
SELECT * FROM Personas WHERE Edad FEQ #20 THOLD 0.6; •
“Dame todas las personas más o menos Rubias (con grado mínimo 0.5) cuya edad es posiblemente superior a Joven (con grado mínimo 0.8)”:
SELECT * FROM Personas WHERE Pelo FEQ $Rubio THOLD 0.5 AND Edad FGT $Joven THOLD 0.8; •
“Equipos que tienen muchos más de 3 (con grado mínimo 0.5) jugadores Altos” (con grado mínimo 0.75)”:
SELECT Equipo, CDEG(*) FROM Personas GROUP BY Equipo HAVING $Muchos_Mas_Que[3] (Altura FEQ $Alto 0.75) 0.5;
5. BASE DE DATOS DISTRIBUIDAS 6. BASE DE DATOS FEDERADAS 7. BASE DE DATOS MOVILES
Base de Datos Móviles.
1.1. Introducción. La computación móvil introduce el concepto de base de datos móvil. Una base de dato móvil
es una base de datos portable, físicamente independiente del servidor corporativo de base
de datos y capaz de comunicarse con ese servidor desde sitios remotos para compartir datos corporativos. Utilizando bases de datos móviles, los trabajadores pueden acceder a los datos corporativos desde cualquier dispositivo que disponga de conexión a Internet.
1.2. Arquitectura.
móviles. Las estaciones base disponen de enlaces inalámbricos para conectar con las unidades móviles; son máquinas que actúan de intermediarios entre las unidades móviles y los computadores fijos. Los computadores fijos y las estaciones base están interconectados por medio de una red fija (cableada) de alta velocidad. Las unidades móviles se conectan a las estaciones base mediante enlaces inalámbricos; los enlaces má s comunes son el estándar 802.11 (Wi-Fi), el servicio GPRS y la tecnología Bluetooth.
rquitectu r a gener al de un a platafo r ma móv il (Dunh am y H el al, 1995)
A
Las uni dades móviles se pue den mo ver libr emente por un espacio conocido como dominio de movilidad geográfica, cuyo alcance está determinado por la cobertura de los enlaces inalámbricos. Este dominio se divide en dominios más pequeños llamados celdas. Cada celda es controlada por una estación base. El movimiento de las unidades móviles dentro del dominio de movilidad geográfica no debe estar restringido, es decir, se debe garantizar el acceso
Estos SGBD móviles están adaptados a los recursos limitados de las unidades móviles y proporcionan una serie de funcionalidades adicionales:
Comunicación con el servidor centralizado de base de datos mediante técnicas de comunicación inalámbrica.
Replicación de datos en el servidor centralizado de base de datos y en el dispositivo móvil.
Sincronización de datos entre el servidor centralizado de base de datos y el dispositivo móvil.
Gestión de datos en el dispositivo móvil.
Análisis de los datos almacenados en el dispositivo móvil
1.4. Aplicaciones móviles y tipos de datos.
Las aplicaciones móviles se clasifican en las dos siguientes categorías: aplicaciones verticales y aplicaciones horizontales En las aplicacionesverticales,los usuarios acceden a los dato s en una celda específica; fuera de la celda los datos noestán disponibles. Un ejemplo de aplicación v ertical es la obtención de información sobre lasplazas libres de un determinado parking. En las aplicaciones horizontales, los datos estándistribuidos por todo el sistema, y los usuarios pueden acc eder a ellos desde cualquier celda. Laaplicación horizontal más común es el acceso al correo electróni co. Los datos se clasifican en tres categorías: Datos privados: pertenecen a un usuario y sólo él puede acceder a ellos y
manejarlos. Por ejemplo, los datos del perfil de un usuario de cualquier aplicación que gestione datos personales. Datos públicos: pueden ser consultados por cualquier usuario, pero sólo pueden
ser modificados por una única fuente. Por ejemplo, los datos de las cotizaciones de la bolsa. Datos compartidos: pueden ser accedidos por un grupo determinado de
usuarios, quienes tienen permisos para leerlos y para escribirlos. Por ejemplo,
Ejemplos de bases de datos móviles.
iAnywhere Solutions, empresa filial de Sybase, lidera el ranking del mercado de bases de datos móviles gracias a SQL Anywhere. Este paquete proporciona bases de datos que pueden utilizarse tanto a nivel de servidor (soporta máquinas de hasta 64bits) como a nivel de dispositivo móvil. SQL Anywhere se compone de las siguientes tecnologías: SQL Anywhere Server : sistema gestor de bases de datos relacionales para los
sistemas de bases de datos móviles. Ultralite: sistema gestor de bases de datos que puede embeberse en dispositivos
móviles. Mobilink tecnología de sincronización
el intercambio de datos entre bases
SQL Remote: permite a los usuarios de dispositivos móviles sincronizar sus datos con otras bases de datos SQL Anywhere.
DB2 Everyplace de IBM ,esta base de datos puede integrarse en dispositivos como PDAs y teléfonos móviles. Microsoft también incluye Tablet PCs, Pocket PCs, S mart Phones y equipos de escritorio. Oracle Database Lite 10g es la solución de Oracle para desarrollar aplicaciones en entornos móviles. Proporciona un cliente que permite la realización de consultas SQL para acceder a los datos locales del dispositivo y un servidor para gestionar los datos de forma centralizada.
Caso de estudio: Oracle Database Lite 10g.
Oracle Database Lite 10g es una solución integrada para el desarrollo de aplicaciones en entornos móviles. Para evitar que l os dispositivos móviles estén continuamente conectados al servidor, Oracle Database Lite 10g proporciona una pequeña base de datos para gestionar los datos empesariales de forma local en el dispositivo móvi
Arquitectura de las aplicaciones Oracle Database Lite 10g
La figura anterior muestra la arquitectura de las aplicaciones Oracle Database Lite 10g. Esta arquitectura contiene los siguientes componentes:
Mobile Sync Module: aplicación instalada en el dispositivo móvil que permite la
sincronización de datos con el servidor empresarial. Oracle Lite RDBMS : sistema gestor de bases de datos relacionales creado
específicamente para dispositivos móviles. Proporciona interfaces ODBC, JDBC, SODA y ADO para permitir la utilización de aplicaciones desarrolladas en lenguajes como Java, C/C++ y Visual Basic.
Oracle Lite database: base de datos instalada en el dispositivo móvil. Mobile Server : servidor intermedio entre los dispositivos móviles y el servidor
empresarial. Permite la instalación y actualización de aplicaciones en los dispositivos móviles y se comunica con el módulo Mobile Sync para sincronizar los datos entre el dispositivo móvil y el servidor empresarial. Message
Generator and Processor (MGP):
módulo
utilizado
en
la
sincronización de datos para detectar y solucionar cualquier conflicto que pueda
producirse en la actualización de los datos del servidor. Mobile Server Repository: repositorio que contiene información necesaria para
que el Mobile Server pueda ejecutarse. Esta información se almacena junto a los datos del negocio, en la misma base de datos.
8. BASE DE DATOS GRID 9. BASE DE DATOS PARALELAS 10. BASE DE DATOS MULTIMEDIA 11. BADE DE DATOS WEB 12. BASE DE DATOS ORIENTADO A OBJETOSÇ 13. BASE DE DATOS OBJETOS-RELACIONALES
