Bases_de_Datos_II.pdf

ESCUELA DE CIENCIAS BÁSICAS E INGENIERÍA

Ingeniería de Sistemas

ASIGNATURA: Bases de Datos II

CORPORACIÓN UNIVERSITARIA REMINGTON

DIRECCIÓN PEDAGÓGICA

Este material es propiedad de la Corporación Universitaria Remington (CUR), para los estudiantes de la CUR

en todo el país.

2011

Corporación Universitaria Remington – Dirección Pedagógica

Bases de Datos II Pág. 5

Corporación Universitaria Remington - Calle 51 51-27 Conmutador 5111000 Ext. 2701 Fax: 5137892. Edificio Remington

Página Web: www.remington.edu.co - Medellín - Colombia

CRÉDITOS

El módulo de estudio de la asignatura Bases de Datos II del Programa Ingeniería de Sistemas es propiedad de la Corporación Universitaria Remington. Las imágenes fueron tomadas de diferentes fuentes que se relacionan en los derechos de autor y las citas en la bibliografía. El contenido del módulo está protegido por las leyes de derechos de autor que rigen al país. Este material tiene fines educativos y no puede usarse con propósitos económicos o comerciales. El autor es Tutor del CAT de la ciudad de Armenia y el trabajo se desarrollo con el apoyo del Operador Logístico FUNEC

AUTOR

Carolina Henao Murillo Especialista En Gerencia Informática Terminación: Cursando Actualmente Segundo Semestre, Ingeniera De Sistemas, Curso: Diplomado En Docencia

Universitaria, Curso: Fortalecimiento De La Tecnología En La Educación

Curso: Asesoría Para La Aprehensión de Procesos Tecnológicos Instructora Sena, Tutora CUR

[email protected] Nota: el autor certificó (de manera verbal o escrita) No haber incurrido en fraude científico, plagio o vicios de autoría; en caso contrario eximió de toda responsabilidad a la Corporación Universitaria Remington, y se declaró como el único responsable.

RESPONSABLES

Escuela de Ciencias Básicas e Ingeniera Director Dr. Mauricio Sepúlveda Director Pedagógico Octavio Toro Chica [email protected] Coordinadora de Medios y Mediaciones Angélica Ricaurte Avendaño [email protected]

GRUPO DE APOYO

Personal de la Unidad de Medios y Mediaciones EDICIÓN Y MONTAJE Primera versión. Febrero de 2011.

mailto:[email protected]







Derechos Reservados

Esta obra es publicada bajo la licencia CreativeCommons. Reconocimiento-No Comercial-Compartir Igual 2.5 Colombia.





TABLA DE CONTENIDO

1. MAPA DE LA ASIGNATURA ............................................................................................. 8

2. INTRODUCCIÓN ............................................................................................................. 9

2.1. Futuro de las Bases de Datos .................................................................................................. 9

2.2. Bases de Datos Activas .......................................................................................................... 14

3. FUNCIONALIDAD ......................................................................................................... 22

3.1. Bases de Datos Orientadas a Objetos (BDOO) y Bases de Datos Objeto Relacionales (BDOR)

22

3.2. Bases de Datos Deductivas y Difusas .................................................................................... 33

3.3. Bases de Datos Multimedia y Web ....................................................................................... 43

3.4. Almacenes de Datos y Bases de Datos XML .......................................................................... 60

4. DISTRIBUCIÓN ............................................................................................................. 70

4.1. Bases de Datos Distribuidas .................................................................................................. 71

4.2. Bases de Datos Federadas y Móviles .................................................................................... 83

5. RENDIMIENTO ............................................................................................................. 99

5.1. Bases de Datos Grid y Paralelas ............................................................................................ 99

6. PISTAS DE APRENDIZAJE ............................................................................................ 117

7. GLOSARIO ................................................................................................................. 118

8. BIBLIOGRAFÍA ............................................................................................................ 119





1. MAPA DE LA ASIGNATURA

BASES DE DATOS II

PROPÓSITO GENERAL DEL MÓDULO

Lograr una perspectiva global de las diversas tecnologías de bases de datos avanzadas y

su importancia en el mundo informático.

OBJETIVO GENERAL

Proponer un modelo avanzado de bases de datos que administre la información de una

manera óptima, utilizando las herramientas tecnológicas adecuadas.

OBJETIVOS ESPECÍFICOS

Conocer las principales tendencias en el área de sistemas de bases de datos.

Determinar el tipo de base de datos que se requiere en una organización.

Diseñar el modelo avanzado de la base de datos basado en modelos que extienden

o sustituyen al modelo relacional.

Implementar la base de datos utilizando las tecnologías de bases de datos

avanzadas.

UNIDAD 1

Fundamentación

conceptual en el

futuro de las bases

de datos y bases

de datos activas.

UNIDAD 2

Fundamentación

procedimental y

competencias

interpretativas y

propositivas en el

manejo de BDOO,

bases de datos

deductivos y

difusos. Al igual

que bases de

datos multimedia

y web, y almacén

de datos y XML.

UNIDAD 3

Capacidad para

representar y

recordar

objetos y sus

propiedades en

bases de datos

distribuidas,

federadas y

móviles.

UNIDAD 4

Habilidad y

destreza para

usar equipos,

procedimientos

de rutina y

complejos en el

rendimiento de

las bases de

datos GRID y

paralelas.





2. INTRODUCCIÓN

Se busca dar una visión general del futuro de la información, para ello se deben conocer los

antecedentes, evolución y actualidad de las bases de datos, con el fin de enmarcar la importancia

del manejo de la información por medio de las tecnologías aplicadas para esta tarea.

OBJETIVO GENERAL

Conocer las principales tendencias en el área de sistemas de bases de datos.


Conocer los antecedentes, evolución y actualidad de las bases de datos, enmarcando la

importancia del manejo de la información por medio de las tecnologías aplicadas.

Conceptualizar que por medio de los sistemas de bases de datos activas se logra un nuevo

nivel de independencia de datos.

Prueba Inicial

1. Sabe usted que es una base de datos.

2. Identifica usted la importancia del manejo de la información en nuestro entorno.

3. Describa mínimo tres características que se debe tener en cuenta para el manejo de la

información.

4. Reconoce el valor del manejo de los datos haciendo uso de las tecnologías de la

información y las comunicaciones.

2.1. Futuro de las Bases de Datos

Introducción: Las bases de datos como producto estratégico de primer orden como apoyo en la

gestión de la información en las organizaciones.





http://alarcos.inf-cr.uclm.es/doc/bbddavanzadas/07-08/futuro.pdf

Evolución de la Gestión de Datos: Generaciones de las bases de datos, tercera generación, su

definición y características principales.

Gestión de las empresas con cobol

Procesos datos

Generaciones de bases de datos

1ª SGBD en red

2ª SGBD relacionales

3ª SGBD inteligentes, activos

Orientados a objetos

3ª GENERACIÓN DE BASES DE DATOS

“Proporciona capacidades de gestión de datos al igual que sus predecesoras, permitiendo que

grandes cantidades de datos persistentes sean compartidos por muchos usuarios. También

proporcionan gestión de objetos, permitiendo tipos de datos muchos más complejos, objetos

multimedia, datos derivados, encapsulamiento de la semántica de los datos, así como otras

nuevas capacidades. Algunos proporcionan incluso gestión de conocimiento, soportando un gran

número de reglas complejas para inferencia automática de información y mantener las

restricciones de integridad entre datos”.

Cattell (1991)

“Gestiona información de una manera natural, haciendo esta información fácil de almacenar,

acceder y utilizar. Es necesario:

- Un fuerte soporte para texto, imagen, voz, animación y vídeo

- Un modelo de bases de datos orientado al objeto

Un soporte de reglas declarativas para expresar las interrelaciones semánticas entre objetos”.





Khoshafian et al. (1990)

Nuevos Retos:

Señales de preocupación Buchmann (1996)

Los SGBD son monolíticos

Existen más datos en hojas de cálculo que en SGBD

El 50% de los datos en producción están en sistemas heredados (legacy systems)

Muchas aplicaciones no necesitan más que ficheros

Los servicios de réplica no escalan por encima de los 10.000 nodos

No se puede combinar datos estructurados y no estructurados

Cambios en el entorno empresarial Keen (1985)

Flexibilidad organizacional

Adaptación al cambio

Cobertura

Extensiones inter-empresa

Cooperaciones y alianzas

Procesos integrados

Gestión integrada y consistente

EMPRESA ABIERTA

Datos mal gestionados Zachman (1996)

El 70% de los informes se utilizan para volver a introducir datos en bases de datos

80/90% del tiempo se dedica al mantenimiento

60/70% se dedica a mantener interfaces y transformar datos de una base a otra

100M$ a “parchear” programas por errores al pasar datos

70% de las líneas de código sólo mueven datos

20/40% de toda la mano de obra de EEUU se dedica a recoger, almacenar y recuperar información

Avances en el hardware y las comunicaciones

Leyes de la evolución del hardware:

Ley de Moore

Ley de Hoagland

Ley de Joy

Predicción de gray





Máquinas paralelas

Técnicas de compresión

Dispositivos de almacenamiento óptico

Digitalizadores de audio y vídeo

Factores y Líneas de Evolución:



Funcionabilidad – Inteligencia







Rendimiento

BD paralelas

BD en tiempo real

BD en memoria principal

Distribución

BD distribuidas

BD federadas

Multibases de datos

BD móviles

BD y “web”

Inteligencia

BD activas

BD deductivas

BD orientadas a objetos

BD seguras

BD difusas

Almacenes de datos

BD multimedia





Madurez de las Nuevas Tecnologías


Ejercicio Tema 1

Según el planteamiento de esta unidad, y desde su punto de vista como aspirante al título de

Ingeniero de Sistemas, cree un ensayo en el cual plasme su punto de vista prospectivo sobre el

futuro de la información y su manejo haciendo uso de las tecnologías aplicadas para esta tarea.

2.2. Bases de Datos Activas

Introducción: Definiciones de SGBD ACTIVO, PASIVO Y DEDUCTIVO, Ventajas y utilidades en SGBD.

SGBD ACTIVO:

Cuando se producen ciertas condiciones ejecuta de forma automática ciertas acciones.





Debe ser capaz de monitorizar y reaccionar ante eventos de manera oportuna y eficiente.

http://alarcos.inf-cr.uclm.es/doc/bbddavanzadas/07-08/activas.pdf

SGBD DEDUCTIVO:

Capaz de deducir hechos adicionales a partir de la base de datos extensional aplicando axiomas

deductivos y reglas de inferencia.

SGBD PASIVO:


VENTAJAS

Mayor productividad

Mejor mantenimiento

Reutilización de código

Reducción del tráfico de mensajes

UTILIDAD EN SGBD

Instantáneas

Datos derivados

Reglas de integridad

Seguridad y auditoría






Posibilidad de optimización

semántica Facilitar el acceso a la

BD a usuarios finales

Gestión de versiones

Componentes: Paton y Díaz (1998)

Modelo de Conocimiento: Eventos, condición, acción

Describe la situación y la reacción correspondiente

EVENTO

FUENTE (operación, envío de mensajes, gestión de transacciones, excepciones, reloj, aplicación...)

GRANULARIDAD (registro, conjunto)

TIPO DE EVENTO (primitivo, compuesto)

PAPEL (obligatorio, opcional, ninguno)

EVENTOS COMPUESTOS

DISYUNCIÓN

CONJUNCIÓN

SECUENCIA

NEGACIÓN

REPETICIÓN

MODELO DE CONOCIMIENTO

CONDICIÓN

PAPEL (obligatorio, opcional, ninguno)

AMBITO

Sobre parámetros del evento

Sobre estado de la BD

Al comienzo de la transacción (BDT)

Cuando ocurrió el evento (BDE)

Cuando se evalúa la condición (BDc)

ACCIÓN

OPCIONES (operación, envío de mensajes, actualización de reglas, abortar transacción, hacer en

lugar de, externo)

AMBITO

Al comienzo de la transacción (BDT)





Cuando ocurrió el evento (BDE)

Cuando se evalúa la condición (BDc)

Modelo de Ejecución: Modos de acoplamiento

Realiza un seguimiento de la situación y gestiona el comportamiento activo









Productos: Interbase, Postgres, SQL






Manifiesto de SGBDA: ACTNET (1996) Características de los SGBDA

Un SGBDA es un SGBD

Un SGBDA tiene un modelo de reglas ECA

Un SGBDA debe soportar la gestión de reglas y la evolución de la base de reglas

Características de ejecución de reglas ECA

Un SGBDA tiene un modelo de ejecución

Un SGBDA debe ofrecer diferentes modelos de acoplamiento

Un SGBDA debe implementar modos de consumo

Un SGBDA debe gestionar la historia de eventos

Un SGBDA debe implementar resolución de conflictos

Características de aplicación y usabilidad

Un SGBDA debería poseer un entorno de programación

Un SGBD A debería ser ajustable

Ejercicio Tema 2

Con el objetivo de conceptualizar el Tema Bases de Datos Activas, de respuesta clara y precisa a

los siguientes interrogantes:

1. ¿Cuáles son los Componentes de las Bases de Datos Activas?

2. Enumere los Productos y sus características más relevantes.

3. Según su concepto ¿cuál es la importancia del manifiesto de SGBDA?





3. FUNCIONALIDAD

Conocer que antes de la llegada de las Bases de Datos Orientadas a Objetos, las Bases de Datos

tradicionales no estaban diseñadas para almacenar objetos, por ende al guardar los datos de un

programa con el enfoque Orientado a Objeto aumentaba de modo significativo su complejidad,

dando espacio a más código y más esfuerzos de programación, así como la dificultad de la

diferencia de esquemas.

OBJETIVO GENERAL

Determinar el tipo de base de datos que se requiere en una organización. OBJETIVOS ESPECÍFICOS

Conocer que antes de la llegada de las Bases de Datos Orientadas a Objetos, las Bases de

Datos tradicionales no estaban diseñadas para almacenar objetos.

Comprender que surgen recientes aplicaciones que consisten en ofrecer recursos para

definir Reglas Deductivas que permiten concluir, inferir u obtener información nueva a

partir de los datos almacenados o sucesos condicionados.

Prueba Inicial

1. Sabe usted que es un objeto.

2. Identifica usted los objetos que componen una base de datos.

3. Normaliza usted una base de datos.

3.1. Bases de Datos Orientadas a Objetos (BDOO) y Bases de Datos Objeto

Relacionales (BDOR)

Bases de datos orientadas a objetos:

Introducción: Las bases de datos orientadas a objetos (BDOO) son aquellas cuyo modelo de datos

está orientado a objetos y almacenan y recuperan objetos en los que se almacena estado y

comportamiento. Su origen se debe a que en los modelos clásicos de datos existen problemas para

representar cierta información, puesto que aunque permiten representar gran cantidad de datos,

las operaciones que se pueden realizar con ellos son bastante simples.

Las clases utilizadas en un determinado lenguaje de programación orientado a objetos son las

mismas clases que serán utilizadas en una BDOO; de tal manera, que no es necesaria una

transformación del modelo de objetos para ser utilizado por un SGBDOO. De forma contraria, el





modelo relacional requiere abstraerse lo suficiente como para adaptar los objetos del mundo real

a tablas.

Las bases de datos orientadas a objetos surgen para evitar los problemas que surgen al tratar de

representar cierta información, aprovechar las ventajas del paradigma orientado a objetos en el

campo de las bases de datos y para evitar transformaciones entre modelos de datos (usar el

mismo modelo de objetos).

1. Conceptos relacionados con las bases de datos orientadas a objetos: En este apartado se

explican los conceptos relacionados con las BDOO:

Base de datos orientada a objetos (BDOO): una colección persistente y compatible de objetos

definida por un modelo de datos orientado a objetos.

Modelo de datos orientado a objetos: Un modelo de datos que captura la semántica de los

objetos soportados en la programación orientada a objetos.

Sistema Gestor de Bases de Datos Orientadas a Objetos (SGBDOO): El gestor de una base de

datos orientada a objetos.

2. Origen de las Bases de Datos Orientadas a Objetos: El origen de las BDOO se encuentra

básicamente en las siguientes razones:

La existencia de problemas para representar cierta información y modelar ciertos aspectos

del ‘mundo real’, puesto que los modelos clásicos permiten representar gran cantidad de

datos, pero las operaciones y representaciones que se pueden realizar sobre ellos son

bastante simples.

El paso del modelo de objetos al modelo relacional genera dificultades que en el caso de

las BDOO no surgen ya que el modelo es el mismo.

Por lo tanto, las bases de datos orientadas a objetos surgen básicamente para tratar de paliar las deficiencias de los modelos anteriores y para proporcionar eficiencia y sencillez a las aplicaciones.

Las debilidades y limitaciones de los SGBDR son:

Pobre representación de las entidades del ‘mundo real’.

Sobrecarga y poca riqueza semánticas.

Soporte inadecuado para las restricciones de integridad y empresariales

Estructura de datos homogénea

Operaciones limitadas





Dificultades para gestionar las consultas recursivas

Desadaptación de impedancias

Problemas asociados a la concurrencia, cambios en los esquemas y el inadecuado acceso

navegacional.

No ofrecen soporte para tipos definidos por el usuario (sólo dominios)

Mientras que las necesidades de las aplicaciones actuales con respecto a las bases de datos son:

Soporte para objetos complejos y datos multimedia

Identificadores únicos

Soporte a referencias e interrelaciones

Manipulación navegacional y de conjunto de registros

Jerarquías de objetos o tipos y herencia

Integración de los datos con sus procedimientos asociados

Modelos extensibles mediante tipos de datos definidos por el usuario

Gestión de versiones

Facilidades de evolución

Transacciones de larga duración

Interconexión e interoperabilidad

Debido a las limitaciones anteriormente expuestas, el uso de BDOO es más ventajoso si se

presenta en alguno de los siguientes escenarios:

Un gran número de tipos de datos diferentes

Un gran número de relaciones entre los objetos

Objetos con comportamientos complejos

Se puede encontrar este tipo de complejidad acerca de tipos de datos, relaciones entre objetos y

comportamiento de los objetos principalmente en aplicaciones de ingeniería, manufacturación,

simulaciones, automatización de oficina y en numerosos sistemas de información. No obstante, las

BDOO no están restringidas a estas áreas. Ya que al ofrecer la misma funcionalidad que su

precursoras relacionales, el resto de campos de aplicación tiene la posibilidad de aprovechar

completamente la potencia que las BDOO ofrecen para modelar situaciones del mundo real.

3. Características de las Bases de Datos Orientadas a Objetos y diferencias de éstas con respecto

a las relacionales:

Mientras que en una BDR los datos a almacenar se almacenan representados en tablas en un

BDOO los datos se almacenan como objetos. Un objeto en BDOO como en POO es una entidad

identificable unívocamente que describe tanto el estado como el comportamiento de una entidad





del ‘mundo real’. El estado de un objeto es descrito mediante atributos mientras que su

comportamiento es definido mediante métodos.

Las características asociadas a las BDOO son:

Objetos: cada entidad del mundo real se modela como un objeto.

La forma de identificar objetos es mediante un identificador de objetos (OID, Object

Identifier), único para cada objeto. Generalmente este identificador no es accesible ni

modificable para el usuario (modo de aumentar la integridad de entidades y la integridad

referencial). Los OID son independientes del contenido. Es decir, si un objeto cambia los

valores de atributos, sigue siendo el mismo objeto con el mismo OID. Si dos objetos tienen

el mismo estado pero diferentes OID, son equivalentes pero tienen identidades diferentes.

Encapsulamiento: cada objeto contiene y define procedimientos (métodos) y la interfaz

mediante la cual se puede acceder a él y otros objetos pueden manipularlo. La mayoría de

los SGBDOO permite el acceso directo a los atributos incluyendo operaciones definidas por

el propio SGBDOO las cuales leen y modifican los atributos para evitar que el usuario

tenga que implementar una cantidad considerable de métodos cuyo único propósito sea el

de leer y escribir los atributos de un objeto. Generalmente, los SGBDOO permiten al

usuario especificar qué atributos y métodos son visibles en la interfaz del objeto y pueden

invocarse desde afuera.

Otros conceptos utilizados de la misma manera que en la POO son:

Clases

Herencia simple, múltiple y repetida.

Polimorfismo de operación, de inclusión y paramétrico; ligadura tardía (late binding); sobrecarga

(overloading) y suplantación o anulación (overriding).

Objetos complejos

4. Manifiesto Malcolm Atkinson: Características de un BDOO: En 1989 se hizo el Manifiesto de los

sistemas de base de datos orientados a objetos el cual propuso trece características obligatorias

para un SGBDOO y cuatro opcionales. Las trece características obligatorias estaban basadas en dos

criterios: debía tratarse de un sistema orientado a objetos y un SGBD.

Características obligatorias de orientación a objetos:

1. Deben soportarse objetos complejos

2. Deben soportarse mecanismos de identidad de los objetos

3. Debe soportarse la encapsulación

4. Deben soportarse los tipos o clases





5. Los tipos o clases deben ser capaces de heredar de sus ancestros

6. Debe soportarse el enlace dinámico

7. El DML debe ser computacionalmente complejo

8. El conjunto de todos los tipos de datos debe ser ampliable

Características obligatorias de SGBD:

1. Debe proporcionarse persistencia a los datos

2. El SGBD debe ser capaz de gestionar bases de datos de muy gran tamaño

3. El SGBD debe soportar a usuarios concurrentes

4. El SGBD debe ser capaz de recuperarse de fallos hardware y software

5. El SGBD debe proporcionar una forma simple de consultar los datos.

Características opcionales:

1. Herencia múltiple

2. Comprobación de tipos e inferencia de tipos

3. Sistema de base de datos distribuido

4. Soporte de versiones

5. Ventajas e inconvenientes de las BDOO: Aunque los SGBDOO pueden proporcionar soluciones

apropiadas para muchos tipos de aplicaciones avanzadas de bases de datos, también tienen sus

desventajas.

Las ventajas de un SGBDOO son:

Mayor capacidad de modelado: El modelado de datos orientado a objetos permite

modelar el ‘mundo real’ de una manera mucho más fiel. Esto se debe a:

Un objeto permite encapsular tanto un estado como un comportamiento

Un objeto puede almacenar todas las relaciones que tenga con otros objetos

Los objetos pueden agruparse para formar objetos complejos (herencia).

Ampliabilidad: Esto se debe a:

Se pueden construir nuevos tipos de datos a partir de los ya existentes.

Agrupación de propiedades comunes de diversas clases e incluirlas en una superclase, lo que

reduce la redundancia.

Reusabilidad de clases, lo que repercute en una mayor facilidad de mantenimiento y un menor

tiempo de desarrollo.

Lenguaje de consulta más expresivo: El acceso navegacional desde un objeto al siguiente

es la forma más común de acceso a datos en un SGBDOO. Mientras que SQL utiliza el





acceso asociativo. El acceso navegacional es más adecuado para gestionar operaciones

como los despieces, consultas recursivas, etc.

Adecuación a las aplicaciones avanzadas de base de datos: Hay muchas áreas en las que

los SGBD tradicionales no han tenido excesivo éxito como el CAD, CASE, OIS, sistemas

multimedia, etc. en los que las capacidades de modelado de los SGBDOO han hecho que

esos sistemas sí resulten efectivos para este tipo de aplicaciones.

Mayores prestaciones: Los SGBDOO proporcionan mejoras significativas de rendimiento

con respecto a los SGBD relacionales. Aunque hay autores que han argumentado que los

bancos de prueba usados están dirigidos a aplicaciones de ingeniería donde los SGBDOO

son más adecuados. También está demostrado que los SGBDR tienen un rendimiento

mejor que los SGBDOO en las aplicaciones tradicionales de bases de datos como el

procesamiento de transacciones en línea (OLTP).

Los inconvenientes de un SGBDOO son: Carencia de un modelo de datos universal. No hay ningún

modelo de datos que esté universalmente aceptado para los SGBDOO y la mayoría de los modelos

carecen una base teórica.

Carencia de experiencia: Todavía no se dispone del nivel de experiencia del que se

dispone para los sistemas tradicionales.

Carencia de estándares: Existe una carencia de estándares general para los SGBDOO.

Competencia: Con respecto a los SGBDR y los SGBDOR. Estos productos tienen una

experiencia de uso considerable. SQL es un estándar aprobado y ODBC es un estándar de

facto. Además, el modelo relacional tiene una sólida base teórica y los productos

relacionales disponen de muchas herramientas de soporte que sirven tanto para

desarrolladores como para usuarios finales.

La optimización de consultas compromete la encapsulación: La optimización de consultas

requiere una compresión de la implementación de los objetos, para poder acceder a la

base de datos de manera eficiente. Sin embargo, esto compromete el concepto de

encapsulación.

El modelo de objetos aún no tiene una teoría matemática coherente que le sirva de base.

6. ODMG: el estándar de facto para modelos de objetos: ODMG es un grupo de representantes de

la industria de bases de datos el cual fue concebido en el verano de 1991 con el objetivo de definir

estándares para los SGBDOO. Uno de sus estándares, el cual lleva el mismo nombre del grupo

(ODMG), es el del modelo para la semántica de los objetos de una base de datos. El modelo de

objetos ODMG es un superconjunto del modelo de objetos de OMG, que permite portar tanto los

diseños como las implementaciones entre diversos sistemas compatibles.





La última versión del estándar, ODMG 3.0, propone los siguientes componentes principales de la

arquitectura ODMG para un SGBDOO:

Modelo de objetos

Lenguaje de definición de objetos (ODL, Object Definition Language)

Lenguaje de consulta de objetos (OQL, Object Query Language)

Conexión con los lenguajes C++, Smalltalk y Java (al menos)

El modelo de objetos ODMG permite que tanto los diseños como las implementaciones, sean

portables entre los sistemas que lo soportan.

ODL es un lenguaje para definir la especificación de los tipos de objetos para sistemas compatibles

con ODMG. ODL es el equivalente de DDL (Data Definition Language o lenguaje de definición de

datos) de los SGBD tradicionales. Define los atributos y las relaciones entre tipos y especifica la

signatura de las operaciones. Su principal objetivo es el de facilitar la portabilidad de los esquemas

entre sistemas compatibles al mismo tiempo que proporciona interoperabilidad entre distintos

SGBD. La sintaxis de ODL extiende el lenguaje de definición de interfaces (IDL) de la arquitectura

CORBA (Common Object Request Broker Architecture).

OQL es un lenguaje declarativo del tipo de SQL que permite realizar consultas sobre bases de

datos orientadas a objetos, incluyendo primitivas de alto nivel para conjuntos de objetos y

estructuras. Está basado en SQL-92, proporcionando un superconjunto de la sentencia SELECT.

OQL no posee primitivas para modificar el estado de los objetos, ya que éstas se deben realizar a

través de los métodos que dichos objetos poseen. La sintaxis básica de OQL es una estructura

SELECT...FROM...WHERE..., como en SQL.

7. Bases de Datos Objeto - Relacionales:

Introducción a las Bases de datos Objeto-Relacionales: Una Base de Datos Objeto Relacional

(BDOR) es una base de datos que desde el modelo relacional evoluciona hacia una base de datos

más extensa y compleja incorporando para obtener este fin, conceptos del modelo orientado a

objetos. Podemos decir que un Sistema de Gestión Objeto-Relacional (SGBDOR) contiene dos

tecnologías; la tecnología relacional y la tecnología de objetos.

En una base de datos objeto-relacional se siguen almacenando tuplas, aunque la estructura de las

tuplas no está restringida a contener escalares (tipos compuestos como vectores, conjuntos, etc.)

sino que las relaciones pueden ser definidas en función de otras, que es lo que denominamos

herencia directa.





8. Características de las Bases de datos Objeto-Relacionales: Con las Bases de Datos Objeto-

Relacional, se pueden crear nuevos tipos de datos, que permiten gestionar aplicaciones más

complejas con una gran riqueza de dominios. Estos pueden ser tipos compuestos, lo que implica

que se debe definir al menos dos métodos transformadores:

Uno para convertir el tipo nuevo a ASCII

Otro que convierte de ASCII al nuevo tipo.

Se soportan tipos complejos como: registros, conjuntos, referencias, listas, pilas, colas y arreglos.

Se pueden crear funciones que tengan un código en algún lenguaje de programación como por

ejemplo: SQL, Java, C, etc.

Existe una mayor capacidad expresiva para los conceptos y asociaciones.

Se pueden crear operadores asignándole un nombre y existencia de nuevas consultas con mayor

capacidad consultiva.

Se soporta el encadenamiento dinámico y herencia en los tipos tupla o registro.

Se pueden compartir varias bibliotecas de clases ya existentes, esto es lo que conocemos como

reusabilidad.

Posibilidad de incluir el chequeo de las reglas de integridad referencial a través de los triggers.

Soporte adicional para seguridad y activación de la versión cliente-servidor.

Anotar como punto final de este apartado, el inconveniente que tienen las BDOR, y es que

aumenta la complejidad del sistema y por tanto se ocasiona un aumento del costo asociado.

9. Tipos de Datos definidos por el Usuario: Los usuarios pueden definir sus propios tipos de datos,

a partir de los tipos básicos provistos por el sistema o por otros tipos de datos predefinidos

anteriormente por el usuario. Estos tipos de datos pueden pertenecer a dos categorías distintas:

Los tipos de objetos (object types)

Los tipos para colecciones (collection types).

10. Tipos de Objetos: Un tipo de objetos define a lo que conocemos como una entidad del mundo

real. Se los pueden interpretar como una plantilla de objetos de ese tipo. Está compuesto por los

siguientes elementos:





Para identificar el tipo de objetos se utiliza un nombre.

Unos atributos que pueden ser de un tipo de datos básico o de un tipo definido por el

usuario, que representan la estructura y los valores de los datos de ese tipo.

Unos métodos que son procedimientos o funciones escritos en el lenguaje PL/SQL

almacenándose de esta forma en la base de datos, o escritos en C almacenándose

externamente.

11. Métodos: A la vez que creamos un tipo de objeto, realizamos la especificación de los métodos.

Los métodos se pueden ejecutar sobre los objetos de su mismo tipo. A continuación mostramos

un ejemplo: si x es una variable PL/SQL que almacena objetos del tipo Alumnos_T, entonces

x.FechaNacimiento () calcula la fecha de nacimiento del alumno almacenado en x.

Métodos Constructores de Tipo: Todos los tipos de objetos tienen asociado por defecto un

método que se encarga de construir nuevos objetos de ese. El nombre del método es el

mismo que el nombre del tipo, y sus parámetros que tenemos en dicho método son los

atributos del tipo de objetos.

Métodos de Comparación: Estos métodos son utilizados para que se pueda comparar los

objetos de un cierto tipo. Esta acción se lleva a cabo indicando cuál es el criterio de

comparación. Para poder hacer posible la realización de una comparación es necesario

escoger entre un método MAP o un método ORDER:

Un método de MAP es utilizado para indicar cuál de los atributos del tipo se va a utilizar para

ordenar los objetos del tipo.

Un método ORDER utiliza los atributos del objeto sobre el que se ejecuta para realizar un cálculo y

compararlo con otro objeto del mismo tipo que toma como argumento de entrada. Este método

debe devolver un valor negativo si el primero es mayor que el segundo, un valor positivo si ocurre

lo contrario y un cero si ambos son iguales.

Tablas de Objetos: Tras definir los tipos de objetos, éstos pueden utilizarse para definir

otros tipos, tablas que almacenen objetos de esos tipos, o para definir el tipo de los

atributos de una tabla. Por ejemplo podemos definir una tabla que utiliza un tipo de datos

complejo para una de sus columnas. Una tabla de objetos es una clase especial de tabla

que almacena un objeto en cada fila.

Referencias entre Objetos: Los identificadores únicos, permiten que puedan ser

referenciados desde los atributos de otros objetos o desde las columnas de tablas. El tipo

de datos proporcionado por Oracle para soportar esta facilidad se denomina REF. Un





atributo de tipo REF almacena una referencia a un objeto del tipo definido, e implementa

una relación de asociación entre los dos tipos de objetos.

Tipos para Colecciones: Los tipos para colecciones se definen para poder implementar

relaciones 1:N. Un dato de tipo colección está formado por un número indefinido de

elementos, todos del mismo tipo. Así es posible almacenar un conjunto de tuplas en un

único atributo, en forma de array o de tabla anidada.

Los tipos para colecciones también tienen por defecto unas funciones constructoras de

colecciones cuyo nombre coincide con el del tipo. Los argumentos de entrada de estas funciones

son el conjunto de elementos que forman la colección separados por paréntesis.

12. El Tipo VARRAY: Un array es un conjunto ordenado de elementos del mismo tipo. Cada

elemento tiene asociado un índice que indica su posición dentro del array. Un tipo VARRAY se

puede utilizar para:

Definir el tipo de datos de una columna de una tabla relacional.

Definir el tipo de datos de un atributo de un tipo de objetos.

Para definir una variable PL/SQL, un parámetro, o el tipo que devuelve una función.

No se produce ninguna reserva de espacio al declarar un tipo VARRAY. Se almacenará con

el resto de columnas de su tabla, si el espacio que requiere lo permite. En caso contrario,

se almacenará aparte de la tabla como un BLOB.

Es imposible poner condiciones sobre los elementos almacenados dentro de un VARRAY,

en las consultas. Esta es la principal limitación que tiene este tipo de dato.

Tablas Anidadas: Una tabla anidada es un conjunto de elementos del mismo tipo en el que

no existe un orden predefinido. Estas tablas solamente pueden tener una columna que

puede ser de un tipo de datos básico, o de un tipo de objetos definido por el usuario.

13. Herencia de tipos: La herencia de tipos surge por la posibilidad de definir tipos que sean

subtipos de otros supertipos. Aparte de que los subtipos definen sus propios atributos y sus

métodos, los subtipos heredan los atributos y los métodos definidos para sus supertipos. Los

subtipos son capaces de redefinir los métodos que heredan, que es lo que conocemos como

polimorfismo.

Por ejemplo, desde el objeto general supertipo TIPO_PERSONA podemos definir el subtipo

TIPO_EMPLEADO que heredarán las características de su supertipo TIPO_PERSONA. El tipo objeto





especializado TIPO_EMPLEADO pueden tener atributos adicionales o pueden redefinir métodos

del objeto padre TIPO_PERSONA extendiendo la funcionalidad de sus tipos objeto.

CREATE TYPE TIPO_PERSONA AS Object

(nombre varchar2(25), fecha_nac date

member function EDAD( ) return number,

member function PRINTME( ) return varchar2) not final;

CREATE TYPE TIPO_EMPLEADO UNDER TIPO_PERSONA

(sueldo number,

member function PAGA ( ) return number,

overriding member function PRINTME( ) return varchar2);

1. POSTGRES: Comenzó como un proyecto denominado Ingres en la Universidad Berkeley de

California. En 1986 se continuó con el desarrollo del código de Ingres para crear el primer

SGBD objeto-relacional. En este sistema se mejora el modelo relacional a partir de que los

usuarios pueden crear sus propios tipos. El usuario puede introducir en las relaciones

atributos de tipo básico o predefinidos por el mismo.

POSTGRES también mantiene la propiedad de herencia entre tipos de objetos de las bases de

datos objeto-relacionales. Desarrollando de una manera más rápida y compleja estos tipos para su

desarrollo.

2. SQL: Se trata de un SGBD objeto-relacional. SQL: 99 permite crear los tipos estructurados

definidos por el usuario; Estos tipos estructurados tienen un número de características:

Pueden ser definidos para tener uno o más atributos, los cuales pueden ser:

Tipos empotrados como INTEGER

Tipos de colección como ARRAY, u otro tipo de estructuras.

Todos los aspectos de su comportamiento son provistos mediante métodos, funciones y

procedimientos.

Sus atributos son encapsulados mediante el uso del sistema generador observador y

mutador de funciones (funciones get y set)

Las comparaciones de sus valores son únicamente realizadas mediante funciones definidas

por el usuario.

Existe las jerarquías de tipo, en las cuales más tipos especializados (subtipos) tienen todos

sus atributos y todos los métodos de los tipos generalizados (supertipos), pero pueden

agregar nuevos atributos y métodos particulares.





Ejercicio Tema 1

1. Defina: Base de datos orientada a objetos (BDOO), Modelo de datos orientado a objetos y

Sistema Gestor de Bases de Datos Orientadas a Objetos (SGBDOO).

2. Mencione y explique las características asociadas a las BDOO.

3. Explique las características obligatorias de orientación a objetos y SGBD, según el

Manifiesto Malcolm Atkinson.

4. Cite las ventajas e inconvenientes de las BDOO.

5. Qué es y que componentes posee el ODMG: el estándar de facto para modelos de

objetos.

6. ¿Cuáles son las características de las Bases de datos Objeto-Relacionales?

7. ¿Cuáles son los Tipos de Datos definidos por el Usuario?. Menciónelos y ejemplifíquelos.

8. ¿En qué consiste la herencia de tipos?

3.2. Bases de Datos Deductivas y Difusas

1. Bases de Datos Deductivas:

Introducción: En el afán de ofrecer una respuesta a las necesidades planteadas por los usuarios y

por las aplicaciones avanzadas, en donde se necesitan herramientas semánticamente más ricas

que las provistas por las Bases de Datos Relacionales, aparecen recientes aplicaciones de los

sistemas de bases de datos que consiste en ofrecer recursos para definir Reglas Deductivas que

permitan deducir, inferir u obtener información nueva a partir de los datos almacenados.

La meta de estas aplicaciones es incorporar a las Bases de Datos Relacionales los beneficios de la

lógica como instrumento para la formalización integrada de los aspectos estáticos y dinámicos del

modelado de aplicaciones.





http://alarcos.inf-cr.uclm.es/doc/bbddavanzadas/08-09/Funcionalidad2.pdf

Existen diversas clases de BDDs y para cada una de ellas existe una semántica bien definida. Las

BDDs son muy usadas en las áreas de: inteligencia artificial, sistemas expertos, representación del

conocimiento, tecnología de agentes, sistemas de información, integración de datos, por nombrar

algunas.

Existe una importante relación entre BDDs y programación lógica. Una BDD es, en esencia, un

programa lógico; mapeo de relaciones base hacia hechos, y reglas que son usadas para definir

nuevas relaciones en términos de las relaciones base y el procesamiento de consultas.

2. Representación de la información: Las BDDs se representan mediante:

Conjunto de aserciones, o hechos, conocidos como la base de datos extensional (EDB): Los

hechos se especifican de manera similar a como se especifican las relaciones, excepto que no es

necesario incluir los nombres de los atributos. Recordemos que una tupla en una relación describe

algún hecho del mundo real cuyo significado queda determinado en parte por los nombres de los

atributos. En una Base de Datos Deductiva, el significado del valor del atributo en una tupla queda

determinado exclusivamente por su posición dentro de la tupla.

Conjunto de reglas (axiomas), referidos como la base de datos intencional (IDB): Las reglas se

parecen un poco a las vistas relacionales. Especifican relaciones virtuales que no están

almacenadas realmente, pero que se pueden formar a partir de los hechos aplicando mecanismos

de inferencia basados en las especificaciones de las reglas. La principal diferencia entre las reglas y

las vistas es que en las primeras puede haber recursión y por tanto pueden producir vistas que no

es posible definir en términos de las vistas relacionales estándar.


La EDB se encuentra generalmente almacenada en una base de datos relacional, y constituye el

conocimiento básico de las BDDs. Las reglas permiten obtener o deducir nuevo conocimiento a

partir de la EDB, conocimiento que no se encuentra almacenado directamente en la EDB. De esta

manera, las BDDs permiten inferir nuevo conocimiento, el cual puede ser usado para la toma de

decisiones importantes del negocio.





3. Manejo de las BDDs, Sintaxis y semántica de Datalog: En un sistema de BDDs por lo regular se

usa un lenguaje declarativo para especificar reglas. Con lenguaje declarativo se quiere decir un

lenguaje que define lo que un programa desea lograr, en vez de especificar los detalles de cómo

lograrlo.

Una máquina de inferencia (o mecanismo de deducción) dentro del sistema puede deducir hechos

nuevos a partir de la base de datos interpretando las reglas. El modelo empleado en las BDDs está

íntimamente relacionado con el modelo de datos relacional, y sobre todo con el formalismo del

cálculo relacional. También está relacionado con el campo de la programación lógica y el lenguaje

Prolog. Los trabajos sobre BDDs basados en lógica han utilizado Prolog como punto de partida.

Con un subconjunto de Prolog llamado Datalog se definen reglas declarativamente junto con un

conjunto de relaciones existentes que se tratan como literales en el lenguaje. Aunque la estructura

gramatical se parece a la de Prolog, su semántica operativa (esto es, la forma como debe

ejecutarse un programa en Datalog) queda abierta.

4. Sintaxis y semántica de Datalog: Las BDDs se componen de cláusulas de Horn que constituyen

reglas del tipo "modus ponendo ponens", es decir, "Si es verdad el antecedente, entonces es

verdad el consecuente". No obstante, la forma de escribir las cláusulas de Horn es al contrario de

lo habitual. Primero se escribe el consecuente y luego el antecedente.

%hechos

hombre(teraj).

hombre(abraham).

hombre(najor).

hombre(haran).

hombre(lot).

hombre(ismael).

hombre(isaac).

hombre(batuel).

hombre(laban).

hombre(esaud).

hombre(jacob).

mujer(sarai).

mujer(melca).

mujer(jesca).

mujer(agar).

mujer(rebeca).

padre(teraj,sarai).

padre(teraj,abraham).





padre(teraj,najor).

padre(teraj,haran).

padre(abraham,ismael).

padre(abraham,isaac).

padre(najor,batuel).

padre(haran,melca).

padre(haran,jesca).

padre(haran,lot).

padre(isaac,esaud).

padre(isaac,jacob).

padre(batuel,laban).

padre(batuel,rebeca).

madre(agar,ismael).

madre(sarai,isaac).

madre(melca,batuel).

madre(rebeca,esaud).

madre(rebeca,jacob).

casado(abraham,sarai).

casado(isaac,rebeca).

casado(najor,melca).

%reglas

hijo(X,Y) :- hombre(X),(padre(Y,X);madre(Y,X)).

hija(X,Y) :- mujer(X),(padre(Y,X);madre(Y,X)).

abuelo(X,Y) :- padre(X,Z),(padre(Z,Y);madre(Z,Y)).

abuela(X,Y) :- madre(X,Z),(padre(Z,Y);madre(Z,Y)).

hermano(X,Y) :- (X\==Y),hombre(X),hijo(X,Z),(hijo(Y,Z);hija(Y,Z)).

hermana(X,Y) :- (X\==Y),mujer(X),hija(X,Z),(hijo(Y,Z);hija(Y,Z)).

tio(X,Y) :- hermano(X,Z),(padre(Z,Y);madre(Z,Y)).

tia(X,Y) :- hermana(X,Z),(padre(Z,Y);madre(Z,Y)).

6

sobrino(X,Y) :- hombre(X),(tio(Y,X);tia(Y,X)).

sobrina(X,Y) :- mujer(X),(tio(Y,X);tia(Y,X)).

primo(X,Y) :- hombre(X),sobrino(X,Z),(padre(Z,Y);madre(Z,Y)).

prima(X,Y) :- mujer(X),sobrina(X,Z),(padre(Z,Y);madre(Z,Y)).

a_directo(X,Y) :- (hijo(Y,X);hija(Y,X)).

a_directo(X,Y) :- (hijo(Z,X);hija(Z,X)),a_directo(Z,Y).

a_indirecto(X,Y) :- not(a_directo(X,Y)),(sobrino(Y,X);sobrina(Y,X)).

a_indirecto(X,Y):-

not(a_directo(X,Z)),(sobrino(Z,X);sobrina(Z,X)),(a_indirecto(Z,Y);a_directo(Z,Y)).





ascendiente(X,Y) :- a_directo(X,Y);a_indirecto(X,Y).

d_directo(X,Y) :- (padre(Y,X);madre(Y,X)).

d_directo(X,Y) :- (padre(Z,X);madre(Z,X)),d_directo(Z,Y).

d_indirecto(X,Y) :- not(d_directo(X,Y)),(tio(Y,X);tia(Y,X)).

d_indirecto(X,Y):-

not(d_directo(Z,Y)),(d_directo(X,Z);d_indirecto(X,Z)),d_indirecto(Z,Y).

El antecedente puede ser una conjunción de condiciones que se denomina secuencia de objetivos.

Cada objetivo se separa con una coma y puede considerarse similar a una instrucción o llamada a

procedimiento de los lenguajes imperativos. Para representar la disyunción se utiliza punto y coma

en lugar de la coma, aunque, estrictamente no corresponde a una disyunción, sino que

internamente se transforma en disyunciones.

En Datalog los valores constantes son de tipo numérico o cadenas de caracteres que empiezan

exclusivamente con letras minúsculas y las variables siempre comienzan con una letra mayúscula.

Si los argumentos son constantes, el predicado se toma como verdadero, si los argumentos son

variables se le considera una consulta o bien parte de una regla o restricción.

Para hacer una consulta, utilizamos una cláusula de Horn con uno de los parámetros vacíos

(poniendo una variable en lugar donde queramos recibir los datos):

?- abuelo(X,isaac).

X = teraj

X = teraj

Yes.

En esta consulta preguntamos por los abuelos de Isaac. Tras utilizar las reglas que hemos

especificado, encontramos que los abuelos son Teraj, por parte de su madre Sarai, y Teraj por

parte de su padre, Abraham. Por último, devuelve verdadero cuando se llega al final del recorrido

del árbol de deducción. Puede ser, y de hecho es frecuente si no diseñamos bien las reglas, que

una consulta caiga en un bucle infinito al realizar la deducción.

5. Sistema de inferencia: En Datalog no existen instrucciones de control. Su ejecución se basa en

dos conceptos: la unificación y el backtracking.

Gracias a la unificación, cada objetivo determina un subconjunto de cláusulas susceptibles de ser

ejecutadas. Cada una de ellas se denomina punto de elección. Datalog selecciona el primer punto

de elección y sigue ejecutando el programa hasta determinar si el objetivo es verdadero o falso. En

caso de ser falso entra en juego el backtracking, que consiste en deshacer todo lo ejecutado

situando el programa en el mismo estado en el que estaba justo antes de llegar al punto de

elección. Entonces se toma el siguiente punto de elección que estaba pendiente y se repite de





nuevo el proceso. Todos los objetivos terminan su ejecución bien en éxito ("verdadero"), bien en

fracaso ("falso").

Existen principalmente dos tipos de inferencia computacional basados en la interpretación de las

reglas por la teoría de la demostración:

1. Mecanismo de Inferencia Ascendente: También llamado encadenamiento hacia delante o

resolución ascendente. La máquina de inferencia parte de los hechos y aplica las reglas

para generar hechos nuevos. Conviene usar una estrategia de búsqueda para generar sólo

los hechos que sean pertinentes a una consulta.

2. Mecanismo de Inferencia Descendente: También llamado encadenamiento hacia atrás o

resolución descendente. Parte del predicado que es el objetivo de la consulta e intenta

encontrar coincidencias con las variables que conduzcan a hechos válidos de la base de

datos. Retrocede desde el objetivo buscado para determinar hechos que lo satisfacen. Si

no existieran los hechos que buscamos, el sistema entonces buscará la primera regla cuya

cabeza (LHS) tenga el mismo nombre de predicado que la consulta.

3. Ventajas: Las principales ventajas al utilizar una BDD son las siguientes:

Tener la capacidad de expresar consultas por medio de reglas lógicas.

Permitir consultas recursivas y algoritmos eficientes para su evaluación.

Contar con negaciones estratificadas.

Soportar objetos y conjuntos complejos.

Contar con métodos de optimización que garanticen la traducción de especificaciones

dentro de planes eficientes de acceso.

Como característica fundamental de una Base de Datos Deductiva es la posibilidad de

inferir información a partir de los datos almacenados, es imperativo modelar la base de

datos como un conjunto de fórmulas lógicas, las cuales permiten inferir otras fórmulas

nuevas.

4. Inconvenientes: La explotación de las reglas de deducción en una BDD plantea algunos

problemas:

Encontrar criterios que permitan, para una ley dada; decidir su utilización como regla de

deducción o como regla de coherencia.

Replantear correctamente, en un contexto deductivo, las convenciones habituales en una

base de datos (representaciones de informaciones negativas, eficacia de las respuestas a

las interrogaciones, cierre del dominio).

Desarrollar procedimientos eficaces de deducción. La posibilidad de caer en bucles

infinitos es un problema muy importante.





5. Bases de Datos Difusas:

Introducción: Una de las características del lenguaje natural, que hace difícil su utilización en

sistemas computacionales es su imprecisión. Por ejemplo conceptos como pequeño o grande,

tienen significados diferentes de acuerdo al contexto en el que se estén utilizando, e incluso

dentro del mismo contexto, pueden significar cosas diferentes para diferentes individuos.

La teoría de los conjuntos difusos desarrollada por Zadeh, provee una poderosa herramienta para

la representación y manejo de la imprecisión por lo que actualmente está siendo utilizada en

varios campos para el diseño de sistemas basados en reglas difusas.

La teoría de conjuntos difusos, extiende la teoría clásica de conjuntos al permitir que el grado de

pertenencia de un objeto a un conjunto sea representada como un número real entre 0 y 1 en vez

del concepto clásico en el que solo se tiene la posibilidad de pertenecer a un conjunto o no

pertenecer al mismo; en otras palabras, el grado de pertenencia a un conjunto en la teoría clásica

tiene solo dos valores posibles: 0 y 1.

En el sentido más amplio, un sistema basado en reglas difusas es un sistema basado en reglas

donde la lógica difusa es utilizada como una herramienta para representar diferentes formas de

conocimiento acerca del problema a resolver, así como para modelar las interacciones y relaciones

que existen entre sus variables. Debido a estas propiedades, los sistemas basados en reglas difusas

han sido aplicados de forma exitosa en varios dominios en los que la información vaga o imprecisa

emerge en diferentes formas. Actualmente, el modelo relacional no permiten el procesamiento de

consultas del tipo “Encontrar a todos los gerentes cuyo sueldo no sea muy alto” dado que ni el

cálculo ni el álgebra relacional, que establecen el resultado de cualquier consulta como una nueva

relación, tienen la capacidad de permitir consultas de una manera difusa.

En los últimos años, algunos investigadores han lidiado con el problema de relajar el modelo

relacional para permitirle admitir algunas imprecisiones; esto conduce a sistemas de bases de

datos que encajan en el campo de la Inteligencia Artificial, ya que permiten el manejo de

información con una terminología que es muy similar a la del lenguaje natural. Una solución que

aparece recurrentemente en los trabajos de investigación actuales en esta área es la fusión de los

sistemas manejadores de bases de datos relacionales con la lógica difusa, lo que da lugar a lo que

se conoce como sistemas manejadores de bases de datos difusas o FRDBMS (por sus siglas en

inglés, Fuzzy Relational Database Management System).

6. 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.

7. Representación de la Información: 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.

La información que se puede manejar en una base de datos difusa puede dividirse en dos tipos

principales:

Datos Precisos: Manejados usualmente mediante la representación provista por la base de

datos relacional huésped.

Datos Imprecisos: Los modelos usualmente consideran dos tipos de representación para

los datos imprecisos además de la información desconocida o indeterminada que se

maneja mediante los tipos unknown, undefined y null:

Datos imprecisos sobre dominios ordenados: Este grupo de datos contiene distribuciones

de probabilidad definidas en dominios continuos o discretos, pero ordenados.






Datos con analogías sobre dominios discretos: Este grupo de datos se construye sobre

dominios discretos en los que existen definidas relaciones de proximidad entre sus

valores. En este caso se deberá almacenar la representación de los datos además de la

representación de las relaciones de proximidad definidas para los valores en el dominio.

Tipo de dato Indefinido (undefined): Cuando un atributo toma el valor undefined, esto

refleja el hecho de que ningún valor de su dominio es permitido. Por ejemplo: el número

de teléfono de alguien que no tiene teléfono.

Tipo de dato desconocido (unknown): Los datos de este tipo expresan nuestra ignorancia

sobre el valor que el atributo toma, sin embargo expresa también que puede tomar uno

de los valores del dominio. Por ejemplo la fecha de nacimiento de alguien, la

desconocemos pero tiene que tener alguna.

Tipo de dato nulo (null): Cuando un atributo toma el valor nulo, esto significa que no

tenemos información sobre él, ya sea porque no conocemos su valor o porque es

imposible asignarle un valor del dominio. Por ejemplo el email de alguien es null si

desconocemos su valor o si lo tiene o no.

8. Manejo de las BDRD: Para el manejo de las bases de datos relacionales difusas (BDRD) se

utiliza el lenguaje Fuzzy SQL (FSQL) que es un lenguaje que deriva de SQL, incorporando las

siguientes novedades.

Etiquetas Lingüísticas: En las sentencias FSQL las etiquetas van precedidas del símbolo $,

para poder distinguirlas fácilmente.

Comparadores Difusos: Permiten comparar dos atributos o un atributo con una constante.





Conectivas Lógicas: Pueden usarse NOT, AND y OR, para enlazar condiciones difusas

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:

<condición_simple> THOLD. La palabra reservada THOLD es opcional y puede sustituirse

por un comparador tradicional (=, <, <=...) modificando el sentido de la consulta. Por

defecto es equivalente al comparador >=.

Constantes Difusas: Pueden usarse en el SELECT todas las constantes difusas ya definidas:

UNKNOWN, UNDEFINED y NULL, $[a,b,c,d] (Distrib. de posibilidad Trapezoidal), $label

(Etiquetas), [n,m] (Intervalo) y #n (valores aproximados).

Función CDEG (<atributo>): 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 (*).

Condición con IS: También admite condiciones del tipo: <atributo_difuso> IS [NOT]

{UNKNOWN | UNDEFINED | NULL}.

Cuantificadores Difusos: Tiene dos modalidades que se aplican como condición en la

cláusula HAVING que sigue a una cláusula GROUP BY:

“Q elementos de X cumplen A”:

$Cuantificador FUZZY[r] (condición_difusa) THOLD

9. Ventajas:

Almacenar Imprecisión: la información que tengamos de un atributo particular de un

objeto, aunque esta información no sea el valor exacto. Suelen usar Etiquetas Lingüísticas

con alguna definición asociada (por ejemplo, un conjunto difuso visto como una

“Distribución de Posibilidad”), o sin ninguna definición asociada (“escalares” con una

relación de similitud definida entre ellos).





Operar con esa información de forma coherente: (especialmente en las operaciones de

consulta). Muchos autores estudian la consulta difusa en BD clásicas: (Tahani, 1977; Bosc

et al., 1988, 1994, 1995; Wong, 1990; Galindo et. al., 1998a).

10. Inconvenientes:

Lenguaje de consulta incómodo, debido al gran número de parámetros que deben

utilizarse.

Comparadores abstractos que hacen difícil la decisión de cuál debemos usar.

Falta de estandarización, derivado de la poca popularidad de este tipo de bases de datos.

Ejercicio Tema 2

1. ¿Cómo se representan las BDD (Bases de Datos Deductivas)?

2. ¿Cuál es la Sintaxis y semántica de Datalog?

3. Cite como mínimo tres ventajas e inconvenientes de las Bases de Datos Deductivas.

4. ¿Qué son las Bases de Datos Difusas?

5. Explique las dos vertientes principales sobre la problemática de la implementación de los

sistemas gestores de bases de datos difusas.

6. ¿Cuáles son los dos tipos principales con los que se puede manejar la información en una

base de datos difusa? Explíquelos.

7. ¿Cuáles son y en qué consisten las operaciones relacionales difusas?

8. Según su criterio, realice una comparativa entre las Bases de Datos Deductivas y las Bases

de Datos Difusas.

3.3. Bases de Datos Multimedia y Web

1. Bases De Datos Multimedia

Introducción: Este tipo de bases de datos tienen mucha relación con los SGBD objeto relacionales

(SGBDOR) y los orientados a objetos (SGBDOO) ya que pueden almacenar tipos de datos

multimedia:





http://alarcos.inf-cr.uclm.es/doc/bbddavanzadas/07-08/funcionalidad%203.pdf

Podemos distinguir dos tipos de bases de datos multimedia fundamentales:

Bases de datos referenciales: son bancos de datos sobre material como películas, series

de televisión o música. En la mayoría de los casos, la información que se almacena hace

referencia a cuestiones descriptivas (autor, título, duración, productor, etc.) o a cuestiones

técnicas (formato, duración, etc.).

Bases de datos descriptivas: se trata de sistemas de análisis de contenido que, más allá de

los datos técnicos o generales que contiene la mayoría de bases de datos referenciales,

aportan información específica sobre el contenido. Estos bancos de datos no resultan tan

habituales y de hecho se encuentran en un estado de desarrollo embrionario, ya que el

análisis de la imagen y del sonido no se halla tan automatizado como el del texto.

Existe, sin embargo, un número importante de bases de datos referenciales que actualmente se

emplean tanto en entornos cerrados (por ejemplo, las bases de datos que gestionan las

plataformas de televisión) como en redes abiertas del tipo Internet, que permiten una consulta en

muchos casos gratuita y libre por parte de los usuarios.

2. Integración Multimedia En Las Bases De Datos: El nacimiento de la multimedia ha

renovado por completo la idea de base de datos. Si bien desde siempre se han visto

como almacenes de información (textual y numérica), regidos por un conjunto de





normas que le aportaban semántica. Con la llegada de la Multimedia el abanico se

amplía con la posibilidad de completar los objetos a los que representan. El ambiente de

un sistema de gestión de bases de datos multimedia integra texto, datos, video, imagen

(estática y dinámica) y sonido.

Las bases de datos multimedia están en un marco que además de los datos se le incluye la nueva

característica de que pueden tener variabilidad espacial y temporal. Por lo tanto, un documento

introducido en una base de datos multimedia es una composición temporal, en la cual hay que

introducir los diferentes tipos de datos, tanto como las relaciones de configuración y temporales

existentes entre ellos. Los datos deben estar sincronizados, controlando tanto su estado como su

comportamiento.

Los documentos multimedia se forman mediante la agregación de objetos de diferentes tipos,

objetos que pueden ser de gran tamaño, y llegan a mostrar gran variedad en lo referido a

estructura y representación. La representación del documento multimedia busca comunicar de

forma efectiva no sólo el documento y su contenido, sino también la semántica, los conceptos

subyacentes y la relación entre ellos. Uno de los enfoques básicos es el análisis de las

características de los usuarios humanos del sistema, para lo cual es indispensable conocer los

patrones de comportamiento del usuario en el acceso y comprensión de las estructuras

informativas.

En el momento en el que se comienza a diseñar e implantar una base de datos multimedia, el

objeto de trabajo ya no resulta ser el registro tradicional: el usuario está tratando con un

documento electrónico con todo lo que ello conlleva (texto, gráficos, imágenes, datos, imágenes

animadas, sonidos). Además a esto hay que sumarle los grandes volúmenes de información

almacenadas en diferentes plataformas y aplicaciones, distribuidas en diferentes localizaciones

geográficas... Todo esto condiciona a que las Bases de Datos Multimedia tengan dos características

principales: a) La disponibilidad de bases de datos avanzadas, en un entorno de fácil utilización por

parte del usuario. b) El establecimiento de redes de telecomunicaciones de alta velocidad.

3. Sistemas De Bases De Datos Multimedia: También llamadas "gestores de información

hipermedial" los Sistemas gestores de bases de datos se diferencia de a otros SGBD

tradicionales (que ofrecían limitaciones en aspectos como el acceso complejo a datos, la

transferencia de datos con otros sistemas, o la inexistencia de adecuados interfaces de

usuario) en intentar diseñar e implementar Sistemas que sean capaces de utilizar

"inteligentemente" los datos disponibles, e integrar las viejas y las antiguas aplicaciones

de forma conjunta y sin problemas.

Una base de información hipermedial tiene varios componentes:





1. Base de presentación: parámetros a aplicar para mostrar la información al usuario.

2. Base de estructura: visión lógica del hiperdocumento, según un modelo.

3. Base de contenido: conjunto de documentos que se integran en el hiperdocumento.

4. Base de utilización: información sobre hábitos y comportamiento de cada usuario.

En su modelaje conceptual (correspondiente al esquema conceptual definido por ANSI/X3/SPARC),

las bases de datos multimedia debe cumplir dos fases:

1. Cognición, centrado en cómo reconocer el mundo real, sus entidades y relaciones.

2. Modelización, centrado en cómo representar los conocimientos obtenidos en la fase

anterior, de manera que sean manipulables por la máquina.

A pesar de ser la integración de bases de datos heterogéneas una de las razones del desarrollo de

sistemas de gestión de bases de datos multimedia, la industria todavía no ha establecido todavía

estándares de formato entre ellas, por lo que se repite la misma situación que en momentos

anteriores, entre ficheros de base de datos correspondientes a aplicaciones como dBASE, Paradox,

etc. Aunque las aplicaciones tradicionales ya ofrecen "puentes" para compartir sus bases de datos,

por el momento esto no es posible en lo que respecta a las bases de datos multimedia. Sin

embargo, están comenzando a aparecer en el mercado nuevas aplicaciones que, sin cumplir los

requerimientos clásicos de un SGBD, pueden generar documentos multimedia, tomando como

base información y datos contenidos en otros tipos de fichero. Los límites entre la base de datos

"real", y el documento multimedia resultante "virtual", son difíciles de establecer en el estado

actual de la tecnología. Si puede decirse que es posible establecerse un algoritmo que define el

proceso de formateo y composición del documento, en dos niveles:

1. Jerarquía lógica del contenido del documento.

2. Jerarquía física del documento formateado.

Requisitos De Bases De Datos Multimedia: Un adecuado SGBD Multimedia debería

ofrecer herramientas para buscar, recuperar, manipular, ordenar y organizar los textos,

imágenes, vídeos en un entorno de formato libre, de tal forma que pueda utilizar

documentos de muy diverso formato, tamaño y disposición. El SGBD de datos multimedia

debería ofrecer lenguajes de descripción de documentos avanzados, permitir el diseño de

estructuras de datos muy flexibles, y ofrecer mecanismos de búsqueda altamente

efectivos.

Como resumen, un sistema de base de datos multimedia debería:

Encontrar rápidamente la información multimedia, buscando cualquier número de

objetos referidos a un contenido de información.

Conectar documentos según su contenido informativo, relacionando extractos de

información relacionada, de varios documentos, en un documento nuevo.





Facilitar el acceso instantáneo a los ficheros pertinentes, incluyendo los mecanismos

necesarios de compresión y descompresión para la manipulación de aquellos.

Conocer y manipular, por parte del usuario, la estructura misma de la información.

Crear relaciones entre grupos de elementos informativos.

La implantación y explotación de Bases de datos Multimedia exige dos elementos

importantes:

Disponibilidad de Bases de Datos Avanzadas, en un entorno de fácil utilización por parte

del usuario.

Establecimiento de redes de telecomunicaciones de alta velocidad.

Metodología De Una Base De Datos Multimedia: La creación e implantación de un

sistema de bases de datos multimedia no puede separarse de la adopción de una

metodología adecuada para ello. De la misma forma que en los sistemas "tradicionales" de

bases de datos, el enfoque a utilizar es el basado en un sistema integrado de información:

1. Definición de las tareas y objetivos a cumplir por la unidad informativa.

2. Desarrollo de un metamodelo y de una metodología para el desarrollo de un sistema de

información estratégica.

3. Inventario de los elementos de tecnologías de la información disponibles.

4. Inventario de las herramientas y de los repositorios de información existentes.

5. Creación de un diccionario de metadatos y de su metodología.

6. Consolidación de las conclusiones obtenidas, a través de metamodelos.

Los tres niveles de un sistema de bases de datos multimedia


La utilización de este tipo de bases de datos, en lo que se incluyen representaciones complejas de

la realidad, hace necesario la utilización de dos niveles de organización y de descripción. En

primer lugar, una nivel de conocimiento, de metadatos, conceptual y difuso. En segundo lugar, un






nivel de datos, concreto y analítico. El concepto clave de las nuevas bases de datos, a partir de la

presente década, será "significado", superando el clásico "dato" o "información".

4. Cuestiones de La Base de Datos Multimedia: Estos son algunos de las cuestiones que

aún quedan por discutir a la hora de tratar con bases de Datos Multimedia:

Modelado: Dado que se va a trabajar con objetos complejos, que van desde simples textos

hasta videos, pasando por imágenes y sonido, el objetivo es encontrar un modelo que

permita describir la estructura de los objetos, y sobre el que pueda definirse lenguajes de

acceso especializados. Si queremos almacenar datos de texto, la mejor opción es una Base

de Datos Relacional, pero para almacenar objetos de video, por ejemplo, una mejor

opción sería una base de Datos Orientada a Objetos. Elegir una u otra a sabiendas de que

habrá ambos tipos de datos es algo sobre lo que se debe seguir investigando. Y es que en

un objeto multimedia que represente el parte de una compañía de seguros en un

accidente, por ejemplo, este podría tener imágenes del accidente, formularios de los

implicados, grabaciones de audio de ambas partes, informe sobre los hechos… decidir que

modelado es más conveniente constituye una cuestión compleja sobre la que aún se

debate.

Indexación de imágenes: A la hora de indexar la información de una imagen, la cuestión es

optar por técnicas de reconocimiento y procesamiento de imágenes o bien por la

asignación manual de frases y términos. La primera de estas técnicas sufre un problema de

escalabilidad, ya que no es capaz de manejar el crecimiento continuo de trabajo, debido

en gran parte a que es una técnica a la que le queda mucho por avanzar. La asignación

manual de términos está actualmente más acogida por su sencillez de adaptación, aunque

resolver sus problemas de ambigüedad de términos requiere técnicas más complejas.

Por ejemplo, si decidiéramos buscar “Calatrava” podríamos encontrarnos con obras del famoso

arquitecto, con poblaciones con ese nombre o con personas con ese apellido. Una solución a esto

es relacionar el término con su contexto. Es decir, diferenciar las imágenes con Calatrava que

estén junto a “Venecia” o “Puente” no trataran sobre lo mismo que si acompaña a “Ciudad Real” o

“Población”.

Recuperación de textos: Un problema que también está relacionado con la recuperación

de la información. Por un lado, y similar a lo expuesto con las imágenes, hay problemas a

la hora de indexar correctamente frases. En contraposición a la utilización de términos

unitarios, parece que añadir descriptores supone una mejora sustancial, estos deben ser

buenos indicadores del contenido. Por otro lado, el vocabulario del usuario es usualmente

diferente del usado a la hora de indexar el documento, por lo que sería ideal el uso de un

diccionario de sinónimos para ampliar la consulta del usuario. El problema de esto es, una





vez más, la ambigüedad del lenguaje. La solución, de nuevo, puede solucionarse

relacionando el término con el contexto.

5. Técnicas De Recuperación De La Información: Los nuevos elementos que se presentan en los

documentos (audio, video, imágenes fijas o dinámicas) han hecho que se investigue sobre nuevas

técnicas para la recuperación de los mismos. Cabe citar:

Recuperación de Audio: este problema se divide en varios niveles.

Primitivas básicas: se asignan identificadores textuales a los archivos y el sistema se

encarga de recuperarlos con ese identificador.

Primitivas a nivel sintáctico: amplían las posibilidades de recuperación de sonidos

teniendo en cuenta aspectos como la frecuencia a la que se muestreo el archivo de audio,

cuantificación, tamaño de archivo, formato de compresión utilizado, y otras relacionadas

fuertemente con la acústica como niveles de agudos, grabes, dB, etc.

Primitivas a nivel semántico: tienen en cuenta el contexto en el que se genera el audio,

permitiendo diferenciar entre una conversación o una pieza de música.

Recuperación de Vídeo al igual que en audio podemos dividirlo en:

Primitivas básicas: tienen la capacidad de detectar planos, pudiendo detectar el encuadre

de escenas.

Primitivas a nivel sintáctico en ella se tratan características propias de la imagen como

pueden ser brillo, luminosidad,...

Primitivas a nivel semántico al igual que en del sonido nos permite recuperar películas por

aspectos característicos de ésta como tipo de película.

Con todo esto llegamos a la conclusión de que el problema de recuperaciónes tan complejo

debido a que el usuario espera del sistema que encuentre elementos relevantes basados en

semánticas personales o culturales. La representación de informaciones de carácter semántico es

muy compleja y requiere de técnicas que implican a ciencias como la Inteligencia Artificial.

6. Ventajas E Inconvenientes de una Base de Datos Multimedia:

Ventajas:

La posibilidad de integrar en un único sistema una gran diversidad de formatos (imágenes,

texto, video, sonido, etc).

Ofrecen mayor variedad a la hora de representar la información.

Un gran, y creciente, mercado potencial que augura que se siga investigando activamente

en el futuro.

Inconvenientes

Necesita grandes espacios para almacenar toda la información que queremos.





Este tipo de bases de datos necesitan grandes anchos de banda para obtener un

rendimiento óptimo.

Complejidad en cuanto a programar operaciones, o incluso la interfaz, debido a la alta

cantidad de formatos que hay que manejar, lo que puede repercutir en su rendimiento.

7. Bases De Datos Web

Introducción: La utilización de la World Wide Web (www) para presentar y acumular datos se ha

desarrollado mucho más allá de la sencilla presentación de páginas, ya no se hacen los antiguos

diseños web en los que los diseñadores creaban una página independiente para cada elemento de

la colección que querían mostrar, esas páginas eran difíciles de mantener y de organizar.

Cabe hacer mención especial al gran número de aplicaciones a las que da soporte Internet, así

como a la naturaleza de las mismas, ya que no son aplicaciones estáticas sino que están en

constante renovación (esto hace que sea especialmente importante separar los datos con los que

se trabaja de la aplicación que los gestiona). Todo ello influye en la forma de almacenar y organizar

la información, debiendo de tener en cuenta todos estos factores a la hora de crear una BBDD

para la web.

Cualquier sitio web que presente información sobre un conjunto de elementos similares es

candidato para la utilización de una base de datos web.

La solución general consiste en definir una base de datos, añadir un registro para cada elemento

(directamente en la base de datos o dinámicamente por la web) y después consultar dicha base de

datos para generar páginas web sobre la marcha. Una página de menú codificada en HyperText

Markup Language (HTML) convierte en una consulta a una base de datos de varios registros. Esto

supone una increíble ventaja sobre todo a la hora del mantenimiento ya que es más fácil tratar

una base de datos que muchas páginas individuales. También un aumento de las capacidades del

HTML ya que éste tiene muchas limitaciones. Las tecnologías web están reemplazando

arquitecturas como la terminal o cliente-servidor, incluyendo servicios y servidores web y de base

de datos entre ellos.

El funcionamiento de un navegador web es el siguiente:

1. El usuario haciendo uso del navegador web (sistema cliente) solicita visualizar una página

web.

2. El navegador solicita esta página (que está codificada en lenguaje HTML, el lenguaje que

puede interpretar) al servidor web (sistema servidor).

3. El servidor web envía la información que le han pedido, en HTML, al navegador del

usuario.

4. El navegador muestra la página web en la pantalla del usuario.





El servidor debe devolver la información solicitada en HTML, así la información puede estar

almacenada en el servidor de forma estática (un fichero .html) o ser generada de forma dinámica y

codificada en HTML.


8. Integración Web – BBDD: Tras observar la necesidad de que los servidores contacten

con las bases de datos se necesitan mecanismos para conseguir esta comunicación; éstos

mecanismos son conocidos cómo middleware web a bases de datos. Como hemos visto en

el primer apartado, es necesario integrar la web con Bases de Datos; para conseguir esta

integración necesitamos una extensión que nos permite la comunicación entre el servidor

web y la base de datos. Esta extensión se conoce como middleware web a Bases de Datos.

Nuestro servidor web se puede comunicar con este middleware a través de dos interfaces:

CGI (Common Gateway Interface): Interfaz de entrada común (en castellano) es

tecnología web que permite a un cliente (explorador web) solicitar datos de un programa

ejecutado en un servidor web. CGI especifica un estándar para transferir datos entre el

cliente y el programa. Es un mecanismo de comunicación entre el servidor web y una

aplicación externa cuyo resultado final de la ejecución son objetos MIME. En una

aplicación CGI, el servidor web pasa las solicitudes del cliente a un programa externo. Este

programa puede estar hecho en cualquier lenguaje que soporte el servidor, aunque por

razones de portabilidad se suelen usar lenguajes de script (PHP, Perl, Python, ASP..), y

puede realizar multitud de operaciones incluyendo el acceso a la base de datos. La salida

de dicho programa es enviada al cliente en lugar del archivo estático tradicional. El CGI

tiene una gran desventaja y es que al utilizar scripts que son programas externos, estos

deben de ejecutarse con cada solicitud lo que disminuye mucho la eficiencia del sistema

servidor; sin embargo las tecnologías web están ampliando horizontes y pasando parte de

la carga que antes soportaba el servidor al cliente por medio de tecnologías como AJAX

(Javascript asíncrono y XML).






API (Application Programming Interface): Interfaz de Programa de Aplicación (en

castellano). Proporcionan unas funciones que suelen permitir entre otras cosas el acceso a

BBDD y la gestión de sesiones de usuario. Tiene la ventaja de que se ejecutan cómo parte

del servidor, ganando con ello tiempo ya que no se tienen que ejecutar cada vez que se

solicite una página, además permite conexiones compartidas. La mayor desventaja que

presenta es que es dependiente del servidor que utilicemos, decrementando de ese modo

la portabilidad del sistema.

9. Características De BBDD WEB: Los distintos Sistemas Gestores de Bases de Datos (SGBD)

existentes incorporan en sus últimas versiones software de tipo middleware (capa de

software que se sitúa sobre el SGBD) para añadir conectividad a la base de datos a través

de Internet, por lo que realmente las bases de datos web no son más que SGBD utilizados

y orientados con vistas a la web. Los middleware desarrollados en los distintos SGBD

suelen emplear ODBC (traduce las consultas de datos de la aplicación en comandos que el

SGBD entienda) para conectar con la BD, junto con diversos conjuntos de herramientas

para facilitar al usuario la implementación de la comunicación con la BD a través de

Internet.

Las principales características que debe cumplir un SGBD utilizado en tecnología web son las

siguientes:

1. Permitir acceso concurrente a los datos.

2. Ofrecer mecanismos de seguridad.

3. Soportar transacciones.

4. Permitir almacenar grandes volúmenes de datos, y almacenamiento de diferentes

archivos.

10. Datos Semiestructurados: Los datos semiestructurados son datos que pueden ser irregulares o

incompletos y cuya estructura puede cambiar de forma rápida o impredecible. Debido a esto, a

este tipo de datos no se les puede fijar un esquema fijo de antemano. La información asociada a

dicho esquema normalmente está contenida dentro de los propios datos. La diferencia entre los

SGBD semiestructurados con los relacionales o los orientados a objetos es que estos últimos

deben seguir un esquema predefinido, como es el caso de los relacionales, cuyo esquema está

orientado a tablas, o los orientados a objetos, que ofrecen la posibilidad de crear estructuras más

ricas pero aun así los datos deben estar fijados a un esquema predefinido. Es por eso que estos

SGBD tienen problemas a la hora de manejar datos semiestructurados.

Soluciones para el tratamiento de los datos semiestructurados: Existen una serie de

modelos y SGBD que permiten tratar con datos semiestructurados:





1. Modelos de Intercambio de Objetos (OEM, Object Exchange Model): Es un modelo de

objetos anidados que fue diseñado originalmente para el proyecto TSIMMIS (The

Standford-IBM Manager of Multiple Information Sources) para soportar la integración de

datos de diferentes origines de datos. Los datos OEM son carentes de esquema y auto-

descriptivos y puede considerarse como un grafo dirigido etiquetado, donde los nodos son

objetos


Como se puede observar en la figura, un objeto OEM está compuesto por un identificador único

de objeto, por ejemplo &9, una etiqueta textual descriptiva, name, un tipo, string, y un valor, Ann

Beech. Estos objetos pueden clasificarse como atómicos o complejos. Los atómicos son objetos

que contienen un valor para el tipo base (entero, cadena de caracteres,…) y pueden reconocerse

en el diagrama porque no tienen ninguna arista saliente. Todos los demás son objetos complejos,

cuyo tipo es un conjunto de identificadores de objetos. Los objetos complejos pueden ser padres

de múltiples objetos o hijos de múltiples padres.

Este tipo de objetos se puede considerar como una cuádrupla (label,oid, type, value).

Por ejemplo:

{Staff, &4, set, (&9, &10)}

{name, &9, string, “Ann Beech”}

{salary, &10, decimal, 12000}





2. Lore (Lightweight Object Repository): Lore es un SGBD para datos semiestructurados que

utiliza el modelo OEM. Tiene un lenguaje de consulta propio, Lorel, que es una extensión

del lenguaje OQL (Object Query Lenguaje). Las características más notables de este SGBD

son:

Tiene una sintaxis similar a SQL.

Obtiene resultados significativos aún en ausencia de algunos datos.

Opera uniformemente con datos de diferentes tipos.

Devuelve información heterogénea.

Resúmenes de datos que se generan y mantienen dinámicamente que permiten realizar

consultas significativas y son utilizados por el procesador de consultas para aumentar la

eficiencia de cada consulta.

Un ejemplo de consulta Lorel sería:

SELECT s.Oversees

FROM DreamHome.Staff s

WHERE s.name = “Ann Beech”

Cuyo resultado sería:

Answer

PropertyForRent &5

street &11 “2 Manor Rd”

type &12 “Flat”

monthlyRent &13 375

OverseenBy &4

PropertyForRent &6

Street &14 “18 Dale Rd”

type &15 1

annualRent &16 7200

OverseenBt &4

3. XML (eXtensible Markup Lenguage): XML es un metalenguaje (un lenguaje para describir

otros lenguajes) que permite a los diseñadores crear sus propias etiquetas personalizadas

para proporcionar funcionalidad no disponible en HTML.

Fue en 1998 cuando la W3C (World Wide Web Consortium) ratifico formalmente la primera

versión de XML como un estándar de intercambio de datos. Existen dos modelos de datos

principales a la hora de trabajar con XML.





Estos son el modelo centrado en los datos y el modelo centrado en los documentos. En un modelo

centrado en los documentos, XML se utiliza como formato de almacenamiento e intercambio para

datos que están estructurados.

En este caso, los datos podrían almacenarse en un SGBD relacional, objeto-relacional u orientado a

objetos. Por tanto, para poder almacenar datos XML en SGBD tradicionales es necesario

transformar las colecciones XML en esquemas compatibles con los SGBD tradicionales. Por

ejemplo, XML ha sido completamente integrado en los sistemas Oracle9i, Oracle10g y Oracle11g a

través de una extensión llamada Oracle XML DB. En el caso de las consultas SQL, en el estándar

SQL: 2003 hay definidas una serie de extensiones a SQL que permiten la publicación de código

XML. Estas extensiones son conocidas como SQL/XML.

En el caso de que XML se use para codificar datos semiestructurados, los SGBD tradicionales no

podrán gestionarlos correctamente. Para realizar esto se necesitara un modelo centrado en los

documentos. Para estos sistemas se usa una base de datos XML nativa (NXD, Native XML

Database). Las NXD Definen un modelo de datos (lógico) para un documento XML (para el

documento, no para los datos contenidos en el) y almacena y extrae documentos de acuerdo con

dicho modelo. Ejemplos de estos modelos son el modelo de los datos de XPath, los XML Infoset, y

los modelos explicitados por el DOM y los eventos en SAX 1.0.Se pueden distinguir dos tipos de

NXD según su almacenamiento:

Basados en texto: almacenan el código XML como texto, por ejemplo como un archivo de

un sistema de archivos o como un dato de tipo CLOB en un SGBD relacional.

Basados en modelo: almacenan el código XML en alguna representación interna en forma

de árbol.

4. Tecnologías Web Dinámicas:

CGI (COMMON GATEWAY INTERFACE) La interfaz de pasarela común (Common Gateway

Interface, CGI) es un protocolo estándar que permite extender las capacidades de HTTP,

permitiendo interactuar una aplicación con un servidor web. Ésta aplicación puede estar

escrita en varios lenguajes como C, C++, Java, Perl, Python… La tarea de un servidor es

responder las peticiones (en el caso de un servidor web, de navegadores web) devolviendo

una salida. Cada vez que llega una petición, el servidor analiza que se está pidiendo y

devuelve la respuesta apropiada.

A continuación se describe la forma de actuación de un CGI de forma esquemática:

1. En primera instancia, el servidor recibe una petición (el cliente ha activado un URL que

contiene el CGI), y comprueba si se trata de una invocación de un CGI.

2. Posteriormente, el servidor prepara el entorno para ejecutar la aplicación. Esta información

procede mayoritariamente del cliente.





3. Seguidamente, el servidor ejecuta la aplicación, capturando su salida estándar.

4. A continuación, la aplicación realiza su función: como consecuencia de su actividad se va

generando un objeto MIME que la aplicación escribe en su salida estándar.

5. Finalmente, cuando la aplicación finaliza, el servidor envía la información producida, junto

con información propia, al cliente, que se encontraba en estado de espera. Es

responsabilidad de la aplicación anunciar el tipo de objeto MIME que se genera (campo

CONTENT_TYPE), pero el servidor calculará el tamaño del objeto producido.

Ejemplo de cómo conectarse a una Base de Datos ODBC usando PERL:

Paso 1. Conectarse a la Base de Datos:

$dbName = "BaseDatos";

$dbDriver = "ODBC";

$dbUserName = "Usuario";

$dbPassword = "Password";

$sql = “SELECT * FROM USUARIOS;”;

$dbh = DBI->connect($dbName, $dbUserName, $dbPassword, $dbDriver);

Paso 2. Realizar Consulta y traer registros a un array:

$dataObject = $dbh->prepare($sql);

$dataObject->execute();

@dbRows = $dataObject->fetchall_arrayref();

Paso 3. Cerrar Result y Conexion

$dbh->disconnect(); PHP (

PHP (Hypertext Pre-Processor): PHP es un lenguaje de programación interpretado usado

normalmente para la creación de páginas web dinámicas. PHP es un acrónimo recursivo

que significa "PHP Hypertext Pre-processor" (inicialmente PHP Tools, o, Personal Home

Page Tools). Cuando el cliente hace una petición al servidor para que le envíe una página

web, el servidor ejecuta el intérprete de PHP.

Éste procesa el script solicitado que generará el contenido de manera dinámica (por ejemplo

obteniendo información de una base de datos). El resultado es enviado por el intérprete al

servidor, quien a su vez se lo envía al cliente. Permite la conexión a diferentes tipos de servidores

de bases de datos tales como MySQL, Oracle, ODBC o Microsoft SQL Server. Tal vez la mayor

ventaja de PHP sobre sus competidores es la integración con los sistemas de bases de datos y el

soporte nativo a las distintas bases de datos existentes, libres y comerciales.

Ejemplo de cómo conectarse a una Base de Datos MySQL.





Paso 1. Conectarse a la Base de Datos:

$link=mysql_connect("localhost","usuario","Password")

Paso 2. Seleccionar Base de Datos y Realizar Consulta:

mysql_select_db("base_datos",$link)

$result=mysql_query("select * from prueba",$link);

Paso 3. Recoger registros del resultado de la consulta:

while($row = mysql_fetch_array($result)) {

printf("Nombre: %s – Apellidos: %s", $row["Nombre"],$row["Apellidos"]);

}

Paso 4. Cerrar Result y Conexión:

mysql_free_result($result);

mysql_close($link);

ASP.NET Herramienta de desarrollo web comercializado por Microsoft. Es usado por

programadores para construir sitios web, aplicaciones web y servicios XML. Forma parte

de la plataforma .NET de Microsoft y es la tecnología sucesora de la tecnología Active

Server Pages (ASP). ASP.net ofrece dos maneras de conectarse a una base de datos web:

Controles de Origen de Datos: Permiten encapsular el acceso a los datos en un control

que se puede configurar con información sobre la conexión y la consulta. Estos controles

serán utilizados por otros controles para mostrar resultados de consultas en la Base de

Datos. Para conectarse a una base de datos mediante un control de origen de datos,

deberá realizar las operaciones siguientes:

1. Determinar el tipo de control de origen de datos que necesita, dependiendo del tipo

elegido puede necesitar seleccionar un proveedor, como System.Data.SqlClient para

SQLServer, System.Data.OleDb para OleDb, System.Data.Odbc para conexiones mediante

Odbc o System.Data.OracleClient para bases de datos Oracle.

2. Agregar el control de origen de datos a la página y establecer sus propiedades para el

acceso a datos.

Codificación mediante clases de ADO.net: Esta práctica es aconsejable si sus requisitos

son demasiado complejos para utilizar los controles de origen de datos o si desea crear un

componente independiente que realice el acceso a los datos fuera de sus páginas Web.

ADO.net, el cual es un conjunto de los componentes del software que pueden ser usados

por los programadores para accesar a datos y a servicios de datos, el cual proporciona

objetos Connection, Reader, DataSet…, para conectarse a una Base de Datos realizaríamos

lo siguiente:





Paso 1. Creamos un objeto SqlConnection:

Dim myConnection As New SqlConnection

("server=(local)\NetSDK;database=pubs;Trusted_Connection=yes")

Paso 2. Crear un Adaptador de Objetos SqlDataAdapter:

Dim myCommand As New SqlDataAdapter("select * from Authors", myConnection)

Paso 3. Crear un DataSet y ejecutar la consulta:

Dim ds As New DataSet()

myCommand.Fill(ds, "Authors")

Paso 4. Cerrar DataSet y Conexión:

ds.close()

myConnection.close()

JSP (JavaServer Pages): JavaServer Pages (JSP) es una tecnología Java que permite generar

contenido dinámico para web, en forma de documentos HTML, XML o de otro tipo. El

funcionamiento general de la tecnología JSP es que el Servidor de Aplicaciones interpreta

y compila el código contenido en la página JSP para construir el código Java del servlet a

generar. Este servlet será el que genere el documento (típicamente HTML) que se

presentará en la pantalla del Navegador del usuario.

JDBC es una API pura de Java que se usa para ejecutar comandos de SQL. Suministra una serie de

clases e interfaces que permiten al desarrollador de web escribir aplicaciones que gestionen Bases

de Datos.

La interacción típica con una base de datos consta de los siguientes cuatro pasos básicos:

Paso 1. Abrir la conexión a la base de datos:

Connection conexion =

DriverManager.getConnection ("jdbc:odbc:Nombre_ODBC","usuario","password");

Paso 2. Ejecutar consultas a la base de datos:

Statement consulta = conexion.createStatement();

ResultSet rs = consulta.executeQuery("select dni,nombre,apellidos,edad from agenda");

Paso 3. Procesar los resultados. En este caso los muestra en pantalla:

while (rs.next()) {

out.println("DNI ->"+ rs.getString("dni"));

out.println("NOMBRE ->"+ rs.getString("nombre"));

out.println("APELLIDOS ->"+ rs.getString("apellidos"));





out.println("EDAD ->"+ rs.getInt("edad"));

}

Paso 4. Cerrar la conexión a la base de datos:

rs.close (); consulta.close (); conexion.close();

5. Ventajas E Inconvenientes de La BBDD – Web: Las principales ventajas e inconvenientes que

proporciona el uso de un SGBD en la web se mencionan a continuación:

Ventajas:

1. Independencia del Hardware y el Software.

2. Independencia de la ubicación.

3. Facilita el mantenimiento de las aplicaciones web, materializando la separación entre la

persistencia de datos y las capas de presentación y dominio de la aplicación.

4. Facilita la portabilidad del sistema.

5. Independencia de la plataforma.

Inconvenientes:

1. Decremento de la seguridad al estar accesible desde cualquier ubicación.

2. Incremento de la complejidad de diseño de la aplicación web.

3. Fiabilidad dependiente de la disponibilidad de red del servidor y/o servidores donde se

aloja la Base de Datos.

Ejercicio Tema 3

1. ¿Qué es Middleware Web a Bases de Datos?

2. ¿Cuáles son las principales características que debe cumplir un SGBD utilizado en

tecnología web?

3. ¿Cuál es la diferencia entre los SGBD semiestructurados con los relacionales o los

orientados a objetos?

4. Defina: CGI (COMMON GATEWAY INTERFACE).

5. ¿Qué es PHP (Hypertext Pre-Processor)?

6. ¿Cuáles son las dos maneras de conectarse a una base de datos web ASP.net?. Explique

su respuesta.

7. Cite un ejemplo de BBDD-WEB.

8. ¿Qué son las Bases de Datos Multimedia?

9. ¿Cuáles son los componentes de una base de información hipermedial?

10. ¿Cuáles son los requisitos de una Base de Datos Multimedia?





3.4. Almacenes de Datos y Bases de Datos XML

1. Almacenes de Datos Introducción: Los almacenes de datos, también llamados Data Warehouse, son almacenes de información temática, orientadas a cubrir las necesidades a las organizaciones con el fin de obtener un sistema de soporte para la gestión, control y apoyo de la toma de decisiones y así una ventaja comercial. Es considerado como la solución para acceder a los datos almacenados en sistemas no relacionales.

Conceptos: Debido a la complejidad y rendimiento, los almacenes de datos han sido

rechazados, sin embargo, actualmente ha surgido un defensor, Hill Inmon, que es

considerado como “el padre de los almacenes de datos” y los define los datos como:

Clasificados por temas, ya que están organizados de manera que todos los elementos de

datos relativos al mismo evento u objeto del mundo real queden unidos entre sí.

Integrados, ya que las bases de datos contienen datos de todos los sistemas operacionales

de la organización y deben ser consistentes.

Variables en el tiempo, los cambios producidos en los datos a lo largo del tiempo quedan

registrados para que los informes que se puedan generar reflejen esas variaciones.

No Volátil, ya que los datos no se modifican ni se elimina, una vez almacenado un dato,

éste se convierte en información de solo lectura y se mantiene para futuras consultas, en

lugar de sustituir la información ya existente.

Por tanto el objetivo de los almacenes de datos es integrar todos los datos en un único almacén en

el cual los usuarios puedan ejecutar consultas con facilidad, generar informes y realizar análisis,

por tanto es una tecnología de gestión y de análisis de datos.

2. Arquitectura: A partir de la Figura 1 donde se muestran cada una de las partes que forman

un almacén de datos, se definen de forma aclaratoria a continuación.





http://alarcos.inf-cr.uclm.es/doc/bbddavanzadas/08-09/FUNCIONALIDAD%204.pdf

Repositorio de Datos Operacionales: El repositorio de datos operacionales es la fuente

donde se encuentran los datos primitivos, actuales e integrados, por lo tanto es el

encargado de suministrar datos al sistema, estos datos operacionales pueden ser:

Mayoritariamente precedentes de sistemas mainframe.

Datos de estaciones de trabajo o servidores privados.

Sistemas externos como las bases de datos comerciales, de proveedores o clientes, o

incluso de Internet.

Datos departamentales almacenados en Sistemas Propietario.

Gestor de Carga: Es el encargado de la extracción y carga de los datos del repositorio de

datos, además de realizar algunas transformaciones simples a los datos con el fin de que

estén adaptados a las necesidades del almacén de datos.

Gestor del Almacén de Datos: Realiza las operaciones relacionadas con la gestión de los datos

dentro del almacén utilizando herramientas específicas que realizan operaciones como la

transformación de datos para la incorporación de éstos en las tablas del almacén de datos, la

creación de índices y vistas de las tablas base, creación de copias de seguridad y archivado de

datos, además del análisis de los datos para garantizar la coherencia de los mismos.





Tipos de Datos: En esta área del almacén de datos es donde se encuentran todos los datos

contenidos en la base de datos.

Datos Detallados: Son los que se obtienen directamente del procesado de los datos, no se

encuentran almacenados en línea, sino que se puede acceder a ellos con un nivel más bajo

de detalle. Se almacenan de disco ocupando mucho espacio, sin embargo así se facilita el

acceso.

Datos Poco Resumidos y Muy Resumidos: Contienen los datos que el gestor del Almacén

de datos ha establecido como resúmenes predefinidos, con el propósito de acelerar las

consultas. Pueden verse modificados constantemente con el fin de responder a las

variaciones de las consultas. Los datos poco resumidos corresponden al primer nivel de

agregación de los datos detallados actualmente, o lo que es lo mismo a las consultas que

se realizan habitualmente, siendo estos almacenados en disco. Mientras que los muy

resumidos corresponden con el nivel más alto de agregación, o lo que es lo mismo a las

consultas que se realizan muy a menudo y que se deben obtener muy rápidamente.

Datos de Archivo/ Copia de seguridad: Es el área donde se guardan los datos detallados y

resumidos con el fin de mantener un archivo y copias de seguridad de los datos.

Metadatos: Describen la estructura de los datos que se contienen en el almacén y pueden

ser utilizados por los gestores de carga, del almacén de datos y de consultas.

El Sistema Gestor de Base de Datos (SGBD): El principal problema que se encuentra al

utilizar almacenes de datos es el tamaño del mismo, por tanto es de gran importancia una

buena elección de un SGBD que debe cumplir con unos requisitos tales como:

Una buena velocidad de carga.

El Procesamiento de carga.

La gestión de la calidad de los datos.

La velocidad de las consultas.

Escalabilidad en el número de usuarios.

Administración del almacén.

Análisis dimensional integrado.

La funcionalidad avanzada de consultas.

Gestor de Consultas: Es el encargado en gestionar las operaciones asociadas a las

consultas que realizan los usuarios, dirigiendo las consultas a las tablas apropiadas y

planificar la ejecución de las mismas. La complejidad del gestor viene determinada por la

funcionalidad de la base de datos y las herramientas de acceso de los usuarios finales.





Herramientas de Acceso Para Usuarios: El objetivo es proporcionar una herramienta de

acceso para los usuarios en la cual se puedan tomar decisiones estratégicas. Por tanto la

comunicación entre el almacén de datos y la herramienta será mediante consultas de tipo

ad-hoc. En el mercado podemos encontrar herramientas que pueden ser clasificadas en

los cinco grupos siguientes:

Herramientas de consulta y generación de informes, soportan instrucciones SQL, con la

facilidad de que el usuario no tiene por qué saber cómo es la estructura de éstas

instrucciones ni de la estructura de la base de datos, además, se utilizan para generar

informes periódicos de carácter operacional o para soportar altos volúmenes de tareas.

Herramientas de desarrollo de aplicaciones personalizadas utilizando herramientas

gráficas de acceso a los datos en entornos cliente-servidor.

Sistemas de información ejecutiva, que dan soporte a todos los niveles de gestión de una

organización, proporcionando una visión de los datos que contiene y un acceso a fuentes

de datos externa.

Herramientas de Procesamiento analítico en línea (OLAP), agilita las consultas de grandes

cantidades de datos utilizando bases de datos multidimensionales. Se utilizan en

generación de informes de ventas, marketing, etc.

3. Mercados De Datos: Es un subconjunto de datos de un almacén relativos a los requisitos

de un departamento o área de negocio concretos. Este subconjunto de datos puede funcionar de forma autónoma, o bien enlazado al almacén de datos. El motivo por el cual se crean mercados de datos es el crecimiento que tiene el almacén y así facilitar su construcción y utilización. Las características de los mercados de datos son:

Se centra en los requisitos de los usuarios asociados a un departamento o área de negocio

concretos.

Como diferencia con los almacenes de datos, los mercados no contiene datos

operacionales detallados.

Son más sencillos a la hora de utilizarlos y comprender sus datos, debido a que la cantidad

de información que contienen es mucho menor que en los almacenes de datos.

4. Flujos de Datos: Los siguientes flujos de datos corresponden con el procesamiento de datos en

un almacén, siguiendo la figura.






Flujo de Entrada: Es el proceso de extracción y carga de los sistemas de origen de datos al

almacén a través del repositorio de datos, aunque es necesario reconstruir los datos antes

de introducirlos en el almacén, realizando la limpieza, la reestructuración para conseguir

los requisitos del almacén y conseguir la coherencia entre sí y los ya existentes.

Flujo Ascendente: Es el proceso de resumen, empaquetamiento y distribución con el fin

de añadir valor a los datos. Donde el resumen agrupa los datos con el fin de hacerlos más

cómodos y útiles para el usuario final. El empaquetamiento convirtiendo los datos de

detalle o resumen a otros formatos más útiles. La distribución de los datos a los usuarios

apropiados.

Flujo Descendente: Es el proceso de archivado y creación de copias de seguridad de los

datos, donde el archivado es importante para el mantenimiento, efectividad y las

prestaciones del almacén, ya que los datos antiguos con menor valor son transferidos a un

archivo permanente. Otro de los fines es garantizar la reconstrucción del almacén en el

estado actual en caso de producirse una pérdida de datos o fallo.

Flujo de Salida: Es el proceso de disponibilidad de los datos a los usuarios finales a través

de las herramientas. Es el flujo que más influye en cuestión de obtener una ventaja

competitiva, o lo que es lo mismo obtener el máximo beneficio al almacén mediante la

actividad de Acceso, la solicitud del usuario en obtener los datos intentando que la





herramienta de consulta para acceder al origen de datos sea la más apropiada y efectiva. Y

la actividad de Suministro que intenta suministrar información a las estaciones de trabajo

de los usuarios.

Metaflujo: Es el proceso de gestión de transferencia de los metadatos. Debido a los

constantes cambios producidos en el entorno de la organización, los metadatos deben

actualizarse continuamente que reflejen estos cambios.

5. Ventajas E Inconvenientes: La implantación de un almacén de datos puede beneficiar a una

organización en:

La inversión que realiza una organización para una correcta implantación de un sistema de

almacén de datos conlleva un costo muy elevado, sin embargo el retorno de la inversión

es garantizado en gran medida.

Como consecuencia de la ventaja anterior se pueden conseguir una ventaja competitiva

debido a una buena toma de decisiones gracias al almacén de datos implantado.

Mejoran la productividad de los responsables en la toma de decisiones de la organización

debido a:

Los almacenes de datos hacen más fácil el acceso a una gran variedad de datos.

Se obtiene una base de datos clasificada por temas e histórica.

Integración de información procedente de múltiples sistemas eternos.

Sin embargo, utilizar almacenes de datos también plantea algunos problemas como:

La subestimación del tiempo requerido para extraer, limpiar y cargar los datos en el

almacén.

Problemas con los sistemas de origen de los datos.

Los datos obtenidos no son suficientes.

Pueden suponer altos gastos. Además de los gastos de mantenimiento que son muy

elevados.

6. Bases de Datos XML:

Introducción: XML se ha convertido en el lenguaje más ampliamente utilizado para la

representación de datos semi-estructurados. Su utilización como lenguaje de formateo de

documentos se ha extendido a otros campos, siendo actualmente el lenguaje estándar para el

intercambio de información, integración de datos y de aplicaciones, etc.

XML es un lenguaje de marcado que deriva de SGML (Standard Generalized Markup Language).

Las principales aplicaciones de XML relacionadas con el tratamiento de datos son la

representación de datos estructurados (bases de datos) o semi-estructurados (aplicaciones de

negocios). También es de mucha utilidad su función como lenguaje de formato de datos a la hora

de comunicar aplicaciones, facilitando la integración de información procedente de varias





aplicaciones. XML se ha consolidado como uno de los principales lenguajes para el intercambio de

información.

XML no es un lenguaje que haya sido diseñado para el almacenamiento de datos. El tener que

repetir etiquetas en todo el documento añade una redundancia que hace que XML no sea un

lenguaje eficiente a la hora de representar datos. Aun así podemos destacar una serie de ventajas:

Las etiquetas hacen que los datos estén autodocumentados.

Su capacidad de extensión hace adaptable al lenguaje al ámbito en el que se esté

aplicando.

Permite representar estructuras de datos anidados.

Los documentos XML tienen un formato no rígido, lo que quiere decir que se puede añadir

más información o simplemente ignorarla.

7. Lenguaje De Definición De Datos XML: Aunque el lenguaje XML no aparece como un lenguaje

específico para diseñar bases de datos, posteriormente sus ventajas para el intercambio de información han hecho que cada vez sea más ampliamente utilizado como lenguaje para la descripción de datos.

Los lenguajes de definición son aquellos que nos permiten, al igual que en bases de datos

relaciones, describir la estructura que van a tener los datos (es decir, los documentos XML). Al

igual que SQL (en bases de datos relacionales) proporciona una sintaxis para describir la estructura

de los datos en base al modelo relacional, el lenguaje de definición de datos XML puede tener un

modelo de datos subyacente y una sintaxis para describirlo. El modelo subyacente al que se tiene

que ajustar un documento XML, viene determinado, o bien por una DTD (Document Type

Definition) o bien por un XML Schema, que además es en sí un fichero XML.

A continuación se muestra una tabla donde se comparan las bases de datos relacionales, las

orientadas a objetos y los datos XML:






8. Almacenamiento de Datos XML: Debido a la aceptación que ha tenido XML se hace necesario

mecanismos para el almacenamiento y gestión de datos XML. Una solución natural son los ficheros

de texto plano, pero debido a los diversos problemas que estos conllevan se utilizan soluciones

basadas en la tecnología de bases de datos. Estas son las diferentes alternativas para el

almacenamiento de datos XML:

Almacenamiento en ficheros planos.

Almacenamiento en BD.

En BD relacionales

Almacenamiento como cadenas de caracteres

Representación en árbol

Asignación a relaciones

En BD como ficheros planos: atributo de tipo XML en una columna

Almacenamiento en BD XML Nativas

Bases de datos Relaciones y XML: Existen diferentes mecanismos para almacenar la

información de los documentos XML en bases de datos relacionales:

Almacenamiento como cadenas de caracteres: esta solución trata de almacenar todo el

documento XML en un campo de una tabla. El inconveniente que tiene esta solución es

que el SGBD no puede conocer la estructura del documento XML.

Representación en árbol: los datos son representados como un árbol y se almacenan en

dos tablas:

Nodos(id, tipo, etiqueta, valor)

Hijos(id-hijo, id-padre)

La tabla hijo establece la relación entre cada elemento y atributo y su elemento padre.

Se puede añadir un atributo más (posición) a hijo, que guarda el orden de los hijos. Esta

aproximación tiene la ventaja de que permite almacenar cualquier dato XML, aunque éste no

tenga una estructura conocida (DTD o esquema XML) en formato relacional.

Asignación a relaciones: se trata de un enfoque híbrido en el que los elementos XML, cuyo

esquema es conocido, se asignan a relaciones y atributos. Para cada tipo de elemento

cuyo esquema es conocido, se crea una relación del modo siguiente:

Se crea un atributo id para almacenar una identificación única para cada elemento.

Todos los atributos de elemento se convierten en atributos de la relación.

Todos los subelementos que se producen una sola vez se convierten en atributos.

Si el valor del subelemento es texto, el atributo almacena el texto como valor.

Para subelementos complejos, la relación correspondiente al subelemento almacena el

contenido del subelemento junto al id del padre y el atributo almacena el id del

subelemento.





Si el subelemento puede aparecer varias veces en el elemento, se representa en una tabla

separada, similar a la relación hijo para identificar el subelemento y su padre.

Bases de datos XML: En la actualidad, existen diferentes soluciones para el

almacenamiento de documentos XML que según WESTERMAN Y KLAS (2003), se pueden

clasificar en dos conjuntos: las bases de datos nativas como Tamino (SOFTWARE AG, 2001)

o ToX (BARBOSA, 2001); y extensiones XML a las bases de datos, que permiten el

almacenamiento de documentos XML en SGBD convencionales, normalmente relacionales

u objeto-relacionales.

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 semiestructurada. 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 BD clásicas.

Almacenan y recuperan documentos de acuerdo a ese modelo. Los documentos XML son,

por tanto, la unidad de almacenamiento. Corresponden a las tuplas 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).

Dependiendo del modelo de almacenamiento, este tipo de gestores se pueden clasificar de la siguiente forma:

Almacenamiento basado en texto (ficheros de texto):

Aplican técnicas de compresión para reducir el espacio de almacenamiento.

Mantienen índices adicionales para aumentar la eficiencia en el acceso a la información.

Pueden definirse sobre bases de datos o sobre sistemas de ficheros.

Almacenamiento basado en modelo:

Definen un modelo de datos lógico (como DOM) para la estructura jerárquica de los

documentos XML.

Almacenan los documentos de acuerdo con este modelo usando el modelo de

almacenamiento que se desee (transformación a base de datos relacional, Persistent

DOM, etc.).





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).

Almacenamiento estructurado: se usa un metamodelo de documentos XML capaz de

representar árboles de nodos de documentos XML, que se construye 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 por el SGBD.

Ejercicio de autoevaluacón

¿Cuál es el objetivo de los almacenes de datos?

¿Qué es el repositorio de datos operacionales?

¿Cuáles son los requisitos que debe cumplir el SGBD?

¿Cuáles son los cinco grupos en que pueden clasificarse las herramientas de acceso para los

usuarios?

Enumere las características de los mercados de datos.

Describa los diferentes flujos de datos que pueden darse en un almacén de datos.

¿Qué es Lenguaje De Definición De Datos XML?

¿Cuáles son las diferentes alternativas para el almacenamiento de datos XML?





4. DISTRIBUCIÓN

Conocer que las bases de datos distribuidas son un grupo de información que corresponde a un sistema que se encuentra repartido entre computadores de una misma red, ya sea a nivel local o global, cada sitio en la red es independiente tanto en sus capacidades de procesamiento, como en la realización de operaciones locales; en cada uno de estos equipos debe ejecutarse un programa a nivel global que admita la consulta de toda la información como si se tratase de uno solo.

OBJETIVO GENERAL

Diseñar el modelo avanzado de la base de datos basado en modelos que extienden o

sustituyen al modelo relacional.


Conocer que las bases de datos distribuidas son un grupo de información que corresponde

a un sistema que se encuentra repartido entre computadores de una misma red, ya sea a

nivel local o global.

Comprender que un sistema de bases de datos federadas es una colección de sistemas de

bases de datos cooperativos y autónomos.

Prueba Inicial

1. Sabe usted ¿Qué son Bases de Datos Distribuidas?

2. Identifica usted los tipos de almacenamiento en una base de datos distribuida.

3. Identifique mínimo tres ventajas y tres desventajas de la implementación de las bases de

datos distribuidas.

4. Sabe usted ¿Qué son Bases de Datos Federadas y Móviles?

5. Enumere 3 características principales de los Sistemas Gestores de Bases de Datos

Federadas.

6. Defina que son las bases de datos móviles.

7. Identifique cuales con las aplicaciones móviles y los tipos de datos.





4.1. Bases de Datos Distribuidas

1. ¿Qué son Bases de Datos Distribuidas?

Son un grupo de datos que pertenecen a un sistema pero a su vez está repartido entre

ordenadores de una misma red, ya sea a nivel local o cada uno en una diferente localización

geográfica, cada sitio en la red es autónomo en sus capacidades de procesamiento y es capaz de

realizar operaciones locales y en cada uno de estos ordenadores debe estar ejecutándose una

aplicación a nivel global que permita la consulta de todos los datos como si se tratase de uno solo.

Comparación:

http://www.iessanvicente.com/colaboraciones/BBDDdistribuidas.pdf

Para tener una base de datos distribuida debe cumplirse las condiciones de una Red

Computacional. Una red de comunicación provee las capacidades para que un proceso

ejecutándose en un sitio de la red envíe y reciba mensajes de otro proceso ejecutándose en un

sitio distinto. Parámetros a considerar incluyen: Retraso en la entrega de mensajes, Costo de

transmisión de un mensaje y Confiabilidad de la red. Diferentes tipos de redes: POINT-TO-POINT,

BROADCAST, LAN, WAN.





2. Arquitectura de las Bases de Datos:

Integración lógica por medio de diseño TOP-DOWN (DISTDB)






Integración lógica por medio de bottom-up (Multidatabase)


Global Schema: Define todos los datos que están incluidos en la bd distribuida tal como si

la bd no fuera distribuida. Consiste de una definición de relaciones globales.

Fragmentation Schema: Traducción entre relaciones globales y fragmentos. (Una relación

global puede consistir de varios fragmentos pero un fragmento está asociado con sólo una

relación global).

Allocation Schema: Define el sitio (o sitios) en el cual un fragmento está localizado.

Local Maping Schema: Traduce los fragmentos locales a los objetos que son manejados

por el SMBD local

Separación entre fragmentación y localización.

Transparencia de Fragmentación

Transparencia de Localización





Control explícito de redundancia

Independencia de BD locales

Ejemplo de una Base de Datos Distribuidas:



3. Tipos de almacenamiento:

Replica: El sistema conserva varias copias o réplicas idénticas de una tabla. Cada réplica se

almacena en un nodo diferente.

Ventajas:

Disponibilidad: El sistema sigue funcionando aún en caso de caída de uno de los nodos.

Aumento del paralelismo: Varios nodos pueden realizar consultas en paralelo sobre la

misma tabla. Cuantas más réplicas existan de la tabla, mayor será la posibilidad de que el

dato buscado se encuentre en el nodo desde el que se realiza la consulta, minimizando

con ello el tráfico de datos entre nodos.





Inconveniente:

Aumento de la sobrecarga en las actualizaciones: El sistema debe asegurar que todas las réplicas

de la tabla sean consistentes. Cuando se realiza una actualización sobre una de las réplicas, los

cambios deben propagarse a todas las réplicas de dicha tabla a lo largo del sistema distribuido.

Fragmentación: Existen tres tipos de fragmentación la horizontal, la vertical y la mixta.

Fragmentación Horizontal: Una tabla T se divide en subconjuntos, T1, T2, ...Tn. Los fragmentos se

definen a través de una operación de selección y su reconstrucción se realizará con una operación

de unión de los fragmentos componentes. Cada fragmento se sitúa en un nodo.

Pueden existir fragmentos no disjuntos: combinación de fragmentación y replicación.

Ejemplo:

Tabla inicial de alumnos






Tabla de alumnos fragmentada


Fragmentación Vertical: Una tabla T se divide en subconjuntos, T1, T2, ...Tn. Los fragmentos se

definen a través de una operación de proyección.

Cada fragmento debe incluir la clave primaria de la tabla. Su reconstrucción se realizará con una

operación de join de los fragmentos componentes, pueden existir fragmentos no disjuntos:

combinación de fragmentación y replicación.

Ejemplo:







Fragmentación Mixta: Como el mismo nombre indica es una combinación de las dos anteriores

vistas he aquí un ejemplo a partir de una tabla fragmentada horizontalmente.




Replica y Fragmentación: Las técnicas de réplica y fragmentación se pueden aplicar sucesivamente

a la misma relación de partida. Un fragmento se puede replicar y a su vez esa réplica ser

fragmentada, para luego replicar alguno de esos fragmentos.

4. Niveles de Transparencia en una Base de Datos Distribuida: El propósito de establecer

una arquitectura de un sistema de bases de datos distribuidas es ofrecer un nivel de

transparencia adecuado para el manejo de la información.





La transparencia se define como la separación de la semántica de alto nivel de un sistema de los

aspectos de bajo nivel relacionados a la implementación del mismo. Un nivel de transparencia

adecuado permite ocultar los detalles de implementación a las capas de alto nivel de un sistema y

a otros usuarios.

El sistema de bases de datos distribuido permite proporcionar independencia de los datos.

La independencia de datos se puede dar en dos aspectos: lógica y física.

Independencia lógica de datos. Se refiere a la inmunidad de las aplicaciones de usuario a

los cambios en la estructura lógica de la base de datos. Esto permite que un cambio en la

definición de un esquema no debe afectar a las aplicaciones de usuario. Por ejemplo, el

agregar un nuevo atributo a una relación, la creación de una nueva relación, el

reordenamiento lógico de algunos atributos.

Independencia física de datos. Se refiere al ocultamiento de los detalles sobre las

estructuras de almacenamiento a las aplicaciones de usuario. la descripción física de datos

puede cambiar sin afectar a las aplicaciones de usuario. Por ejemplo, los datos pueden ser

movidos de un disco a otro, o la organización de los datos puede cambiar.

La transparencia al nivel de red se refiere a que los datos en un SBDD se accedan sobre una red de

computadoras, sin embargo, las aplicaciones no deben notar su existencia. La transparencia al

nivel de red conlleva a dos cosas:

Transparencia sobre la localización de datos. el comando que se usa es independiente de

la ubicación de los datos en la red y del lugar en donde la operación se lleve a cabo. Por

ejemplo, en Unix existen dos comandos para hacer una copia de archivo. Cp se utiliza para

copias locales y rcp se utiliza para copias remotas. En este caso no existe transparencia

sobre la localización.

Transparencia sobre el esquema de nombramiento. Lo anterior se logra proporcionando

un nombre único a cada objeto en el sistema distribuido. Así, no se debe mezclar la

información de la localización con en el nombre de un objeto.

La transparencia sobre replicación de datos se refiere a que si existen réplicas de objetos de la

base de datos, su existencia debe ser controlada por el sistema no por el usuario. Se debe tener en

cuenta que cuando el usuario se encarga de manejar las réplicas en un sistema, el trabajo de éste

es mínimo por lo que se puede obtener una eficiencia mayor. Sin embargo, el usuario puede

olvidarse de mantener la consistencia de las réplicas teniendo así datos diferentes. La

transparencia a nivel de fragmentación de datos permite que cuando los objetos de la bases de

datos están fragmentados, el sistema tiene que manejar la conversión de consultas de usuario





definidas sobre relaciones globales a consultas definidas sobre fragmentos. Así también, será

necesario mezclar las respuestas a consultas fragmentadas para obtener una sola respuesta a una

consulta global. El acceso a una base de datos distribuida debe hacerse en forma transparente. En

resumen, la transparencia tiene como punto central la independencia de datos.

La responsabilidad sobre el manejo de transparencia debe estar compartida tanto por el sistema

operativo, el sistema de manejo de bases de datos y el lenguaje de acceso a la base de datos

distribuida. Entre estos tres módulos se deben resolver los aspectos sobre el procesamiento

distribuido de consultas y sobre el manejo de nombres de objetos distribuidos.

5. Procesamiento Distribuido de Consultas: El procesamiento de consultas es de suma

importancia en bases de datos centralizadas. Sin embargo, en BDD éste adquiere una

relevancia mayor. El objetivo es convertir transacciones de usuario en instrucciones para

manipulación de datos. No obstante, el orden en que se realizan las transacciones afecta

grandemente la velocidad de respuesta del sistema. Así, el procesamiento de consultas

presenta un problema de optimización en el cual se determina el orden en el cual se hace

la menor cantidad de operaciones. En BDD se tiene que considerar el procesamiento local

de una consulta junto con el costo de transmisión de información al lugar en donde se

solicitó la consulta.

6. Recuperación: En los entornos distribuidos de datos podemos encontrar lo siguientes:

Fallo de los nodos: Cuando un nodo falla, el sistema deberá continuar trabajando con los

nodos que aún funcionan. Si el nodo a recuperar es una base de datos local, se deberán

separar los datos entre los nodos restantes antes de volver a unir de nuevo el sistema

Copias múltiples de fragmentos de datos: El subsistema encargado del control de

concurrencia es el responsable de mantener la consistencia en todas las copias que se

realicen y el subsistema que realiza la recuperación es el responsable de hacer copias

consistentes de los datos de los nodos que han fallado y que después se recuperarán.

Transacción distribuida correcta: Se pueden producir fallos durante la ejecución de una

transacción correcta si se plantea el caso de que al acceder a alguno de los nodos que

intervienen en la transacción, dicho nodo falla.

Fallo de las conexiones de comunicaciones: El sistema debe ser capaz de tratar los

posibles fallos que se produzcan en las comunicaciones entre nodos. El caso más extremo

es el que se produce cuando se divide la red. Esto puede producir la separación de dos o

más particiones donde las particiones de cada nodo pueden comunicarse entre sí pero no

con particiones de otros nodos.





Para implementar las soluciones a estos problemas, supondremos que los datos se encuentran almacenados en un único nodo sin repetición. De ésta manera sólo existirá un único catálogo y un único DM (Data Manager) encargados del control y acceso a las distintas partes de los datos. Para mantener la consistencia de los datos en el entorno distribuido contaremos con los siguientes elementos:

Catálogo: Programa o conjunto de programas encargados de controlar la ejecución

concurrente de las transacciones.

CM (Cache Manager): Subsistema que se encarga de mover los datos entre las memorias

volátiles y no volátiles, en respuesta a las peticiones de los niveles más altos del sistema de

bases de datos. Sus operaciones son Fetch(x) y Flush(x).

RM (Recovery Manager): Subsistema que asegura que la base de datos contenga los

efectos de la ejecución de transacciones correctas y ninguno de incorrectas. Sus

operaciones son Start, Commit, Abort, Read, Write, que utilizan a su vez los servicios del

CM.

DM (Data Manager): Unifica las llamadas a los servicios del CM y el RM.

TM (Transaction Manager): Subsistema encargado de determinar que nodo deberá

realizar cada operación a lo largo de una transacción.

Las operaciones de transacción que soporta una base de datos son: Start, Commit y Abort. Para

comenzar una nueva transacción se utiliza la operación Start. Si aparece una operación commit, el

sistema de gestión da por terminada la transacción con normalidad y sus efectos permanecen en

la base de datos. Si, por el contrario, aparece una operación abort, el sistema de gestión asume

que la transacción no termina de forma normal y todas las modificaciones

7. Ventajas y Desventajas:

Ventajas:

Los sistemas de bases de datos distribuidos tienen múltiples ventajas. En primer lugar los

datos son localizados en lugar más cercano, por tanto, el acceso es más rápido, el

procesamiento es rápido debido a que varios nodos intervienen en el procesamiento de

una carga de trabajo, nuevos nodos se pueden agregar fácil y rápidamente. La

comunicación entre nodos se mejora, los costos de operación se reducen, son amigables al

usuario, la probabilidad de que una falla en un solo nodo afecte al sistema es baja y existe

una autonomía e independencia entre los nodos.

Las razones por las que compañías y negocios migran hacia bases de datos distribuidas

incluyen razones organizacionales y económicas, para obtener una interconexión confiable





y flexible con las bases de datos existentes, y por un crecimiento futuro. El enfoque

distribuido de las bases de datos se adapta más naturalmente a la estructura de las

organizaciones. Además, la necesidad de desarrollar una aplicación global (que incluya a

toda la organización), se resuelva fácilmente con bases de datos distribuidas. Si una

organización crece por medio de la creación de unidades o departamentos nuevos,

entonces, el enfoque de bases de datos distribuidas permite un crecimiento suave.

Los datos se pueden colocar físicamente en el lugar donde se accedan más

frecuentemente, haciendo que los usuarios tengan control local de los datos con los que

interactúan. Esto resulta en una autonomía local de datos permitiendo a los usuarios

aplicar políticas locales respecto del tipo de accesos a sus datos.

Mediante la replicación de información, las bases de datos distribuidas pueden presentar

cierto grado de tolerancia a fallos haciendo que el funcionamiento del sistema no dependa

de un solo lugar como en el caso de las bases de datos centralizadas.


Desventajas:

Las razones por las que compañías y negocios migran hacia bases de datos distribuidas

incluyen razones organizacionales y económicas, para obtener una interconexión confiable

y flexible con las bases de datos existentes, y por un crecimiento futuro. El enfoque

distribuido de las bases de datos se adapta más naturalmente a la estructura de las

organizaciones. Además, la necesidad de desarrollar una aplicación global (que incluya a

toda la organización), se resuelva fácilmente con bases de datos distribuidas. Si una

organización crece por medio de la creación de unidades o departamentos nuevos,

entonces, el enfoque de bases de datos distribuidas permite un crecimiento suave.

Los datos se pueden colocar físicamente en el lugar donde se accedan más

frecuentemente, haciendo que los usuarios tengan control local de los datos con los que

interactúan. Esto resulta en una autonomía local de datos permitiendo a los usuarios

aplicar políticas locales respecto del tipo de accesos a sus datos.

Mediante la replicación de información, las bases de datos distribuidas pueden presentar

cierto grado de tolerancia a fallos haciendo que el funcionamiento del sistema no dependa

de un solo lugar como en el caso de las bases de datos centralizadas.






Ejercicio Tema 1

1. ¿Qué son Bases de Datos Distribuidas?

2. Explique los tipos de almacenamiento.

3. ¿Cuáles son los niveles de transparencia en una Base de Datos Distribuida?

4. Explique los aspectos lógicos y físicos de independencia de datos.

5. ¿En qué consiste el Procesamiento Distribuido de Consultas?





4.2. Bases de Datos Federadas y Móviles

1. Bases de Datos Federadas:

La definición de Base de Datos Federada ha sido realizada por varios autores. Así, Sheth A.P. and

Larson, J.A. definieron el concepto base de datos federada como “una colección de sistemas de

bases de datos independientes, cooperativos, posiblemente heterogéneos, que son autónomos y

que permiten compartir todos o algunos de sus datos”. Además, Larson amplió esta definición

diciendo que “en un sistema federado los usuarios tienen acceso a los datos, de los distintos

sistemas, a través de una interfaz común; sin embargo, no existe un esquema global que describa

a todos los datos de las distintas bases de datos, sino que en su lugar hay varios esquemas

unificados, cada uno describiendo porciones de bases de datos y archivos para el uso de cierta

clase de usuarios”.

La primera definición pone de manifiesto todas las propiedades que definen a una Base de Datos

Federada: heterogeneidad, autonomía y distribución. Una Base de Datos Federada se dice que es

heterogénea debido a que los sistemas de bases de datos que lo forman pueden tener cualquier

arquitectura. En cuanto a la autonomía, esta propiedad se cumple ya que cada sistema de bases

de datos funciona por sí mismo y de forma local. Por último, el concepto de distribución hace

referencia a que cada sistema de bases de datos puede estar localizado en cualquier punto.

En cuanto a la segunda definición, se explica que un sistema federado está compuesto por los

datos de las diferentes bases de datos que forman el esquema, pero que dichos datos no están

presentes en ningún esquema global. Además, no necesariamente todos los datos de una base de

datos son compartidos a los usuarios, sino que se tiene la posibilidad de compartir sólo una

porción de los datos.

2. Características de los SGBDF:

Un Sistema Gestor de Bases de Datos Federadas (SGBDF) es el responsable de proveer una vista de

datos transparente al usuario. Esto significa que el usuario percibe a la base de datos federada

como una única base de datos local, y no múltiples bases de datos que contienen diferentes datos,

que es como en realidad está configurado.

Un SGBDF no contiene ningún dato, sino que accede a los datos almacenados en las diferentes

bases de datos que forman el esquema. Para acceder a dichos datos es necesario establecer las

denominadas federaciones. Una federación es una vista que se establece en una base de datos en

particular para exteriorizar los datos que se desean mostrar.





A continuación se muestra una figura que ilustra la conexión entre los diferentes elementos que

forman una base de datos federada.

http://alarcos.inf-cr.uclm.es/doc/bbddavanzadas/08-09/Distribuidas2.pdf

Como se puede apreciar en la figura anterior, un SGBDF está formado por varios gestores de bases

de datos. Dichos gestores pueden ser tanto gestores de bases de datos centralizadas (SGBD) como

gestores de bases de datos distribuidas (SGBDD). Los SGBDD, además, pueden ser a su vez

sistemas de bases de datos federados. Tanto los sistemas gestores como las bases de datos que lo

forman son denominados componentes del SGBDF.

Los componentes de un SGBDF pueden ejecutar tanto sus operaciones locales como participar en

la ejecución de las consultas sobre los datos federados (operaciones globales). La autonomía de

cada componente es controlada por el administrador del sistema junto a cada administrador de

cada uno de los componentes. Esto es debido a que dicha autonomía difiere según la necesidad de

federación existente de cada base de datos con el esquema global. Todas las federaciones en

conjunto forman el sistema federado. En cualquier momento, según la necesidad, cualquiera de

ellas puede variar. Como se ha dicho antes, el usuario final es transparente a las uniones entre

componentes que haya por debajo, por lo que el único cambio que un usuario puede percibir es

que tenga acceso a diferentes datos en el esquema global.

3. Tipos de SGBDF: Los SGBDF se pueden clasificar en 2 grandes categorías: fuertemente acoplados y débilmente acoplados. Antes de detallar ambas categorías, se muestra un esquema que específica los diferentes tipos de bases de datos federadas.





Taxonomía de los SGBDF


Como se puede apreciar, vuelve a aparecer el concepto de autonomía como elemento

diferenciador entre sistemas federados y sistemas que no lo son. En cuanto a los otros 2

conceptos, heterogeneidad y distribución, ambos se cumplen debido a que la propia definición de

sistema federado lo hace posible, al estar compuesto éste de varios SGBD separados en

localizaciones diferentes y con distinta arquitectura.

SGBDF fuertemente acoplados: Este tipo de sistema federado posee un esquema

conceptual global que está formado por un subconjunto de los esquemas conceptuales

locales, compuesto de los datos que cada sistema local decide compartir. El esquema

conceptual global en un sistema fuertemente acoplado implica la integración de partes de

los esquemas conceptuales locales o de los esquemas externos locales.

En la siguiente figura se ilustra una arquitectura de referencia para un sistema gestor de

base de datos federado estrechamente acoplado, es decir, que tiene un esquema

conceptual global.





Arquitectura de referencia para un SGBDF fuertemente acoplado


Las características de un SGBDF fuertemente acoplado son las siguientes:

El administrador global del sistema federado tiene todo el control sobre la creación y el

acceso a los sistemas de bases de datos componente.

Soporta uno o más esquemas federados.

La utilización de un SGBDF de este tipo concierne una serie de ventajas:





Capacidad de soportar actualizaciones.

La interpretación de la semántica de los múltiples datos integrados en el sistema federado

es uniforme.

Aun así, este tipo de sistema federado posee las siguientes desventajas:

Debido a la libertad que disfrutan los administradores globales se puede llegar a violar la

autonomía que poseen los sistemas componente.

No soporta la evolución dinámica de los esquemas de exportación o componentes.

SGBDF débilmente acoplados: Existe otro tipo de sistema federado, débilmente acoplado,

que se basa en no tener un esquema conceptual global. En este caso, los esquemas

externos están compuestos por uno o más esquemas conceptuales locales.

Este otro tipo de sistema federado posee las siguientes características:

Los usuarios son los responsables de la creación y el mantenimiento de las federaciones

mediante la utilización de vistas.

Soporta sistemas de bases de datos altamente autónomos, los cuales los usuarios deben

tratar.

En cuanto a las ventajas de utilizar este tipo de SGBDF:

Dispone de gran flexibilidad para mapear diferentes semánticas de los mismos objetos en

distintos esquemas de exportación.

Se tiene mayor facilidad para soportar la evolución de los componentes.

Y las desventajas de los SGBDF débilmente acoplados son las siguientes:

Resulta de gran dificultad la comprensión de grandes cantidades de esquemas de

exportación.

Los esfuerzos para gestionar este tipo de sistema se duplican.

Existen problemas para actualizar las vistas que utilizan los usuarios.

4. Tipos de Arquitectura para un SGBDF: A continuación se van a detallar dos tipos de

arquitecturas para el manejo de bases de datos federadas. Hay otras muchas, pero en este

documento nos vamos a centrar en la arquitectura de Sheth A.P. and Larson, J.A. y la

arquitectura propuesta por ANSI/SPARC.

Arquitectura de 5 niveles (Sheth y Larson): Sheth y Larson propusieron una arquitectura compuesta por 5 niveles de esquemas, los cuales son los siguientes:

Esquema Local: Se trata del esquema conceptual de las bases de datos componente.

Esquema Componente: Se obtiene tras transformar el esquema local en un Modelo de

Datos Común.





Esquema de Exportación: Representa un subconjunto de la totalidad de los datos que

contiene el esquema componente. Este subconjunto de datos es el que se quiere

compartir en la base de datos federada.

Esquema Federado: Está formado por la integración de todos los esquemas de exportación

de cada base de datos componente.

Esquema Externo: Representa una vista hacia un usuario o conjunto de usuarios

determinado. No necesariamente este esquema contiene todos los datos que forman el

esquema federado, sino que puede ser un subconjunto de estos.

En la siguiente figura se muestra un ejemplo de este tipo de arquitectura que muestra todo lo

explicado anteriormente.


5. Arquitectura de 3 niveles (ANSI/SPARC): Este tipo de arquitectura es muy utilizada en el

diseño de bases de datos relacionales. Está formada por los siguientes niveles:

Nivel Físico: Está compuesto por el esquema interno. Dicho esquema contiene las

diferentes bases de datos componente que forman la base de datos federada.

Nivel Lógico: Corresponde al esquema conceptual. Este nivel contiene el modelo global de

datos, es decir, el conjunto de datos compartido por todas las bases de datos

componente.





Nivel Externo: Está representado por el esquema externo. Este esquema está compuesto

por las diferentes vistas que poseen los usuarios a los datos compartidos.

Para mostrar de forma más clara esta arquitectura se sugiere la siguiente figura:

Arquitectura de 3 niveles (ANSI/SPARC)


6. Problemas de Implementación: La implementación de este tipo de base de datos

concierne una serie de problemas que se citan a continuación:

Incompatibilidad entre los sistemas de consulta de los diferentes fabricantes.

Diferente codificación utilizada por las bases de datos componente.

Generación de códigos de error incompatibles por los diferentes fabricantes.

Dificultades para establecer un control de la concurrencia en las distintas transacciones.

Las transacciones son heterogéneas debido a que cada SGBD mantiene su autonomía.

7. Aplicaciones Comerciales: Existen multitud de aplicaciones comerciales que soportan

bases de datos federadas. Todos los sistemas gestores de bases de datos conocidos

poseen la posibilidad de crear este tipo de bases de datos. Por ejemplo, IBM, ORACLE,

MySQL, SQL Server, etc., permiten la creación de bases de datos federadas. El problema

que surge es cuando se desea realizar una base de datos federada que consulta los datos





de otra base de datos con una tecnología diferente, es decir, de otro fabricante. En este

caso las posibilidades se reducen, y es necesaria la incorporación de algún componente

extra que incrementa el costo considerablemente.

8. Caso de Uso: MySQL: A continuación se va a realizar un ejemplo sencillo de base de datos

federada. Para ello se va a utilizar el SGBD MySQL, que dispone de una versión gratuita

que permite crear bases de datos federadas.

En primer lugar se va a definir la tabla cliente que será consultada por la tabla federada. Notar que

pertenece a la base de datos bbdd1.


Ahora, nuestra base de datos federada va a contener otra tabla que va a tener una federación a

esta primera tabla definida.

CREATE DATABASE IF NOT EXISTS bbdd1;

USE bbdd1;

DROP TABLE IF EXISTS `cliente`;

CREATE TABLE `cliente` (

ìdCliente` int(10) unsigned NOT NULL auto_increment,

`Nombre` varchar(45) NOT NULL,

Àpellidos` varchar(45) NOT NULL,

PRIMARY KEY (ìdCliente`)

) ENGINE=MyISAM DEFAULT CHARSET=utf8;






La tabla federada que se acaba de crear muestra los mismos datos que la tabla remota a la que

consulta. Notar que con referencia a la definición de la primera tabla existen 2 diferencias:

El motor de consulta cambia de MyISAM a FEDERATED.

Se añade el atributo COMMENT donde se especifica la dirección de la tabla remota a la

que tiene que consultar.

9. Base de Datos Móviles:

Introducción: En los últimos años se han producido grandes avances en las tecnologías de comunicación inalámbricas. Estos avances, junto al uso cada vez más extendido de los dispositivos móviles, han causado la aparición de una nueva disciplina: la computación móvil. Gracias a la computación móvil, los usuarios pueden acceder a una base de datos remota en cualquier momento y en cualquier lugar. Los empleados de una empresa pueden trabajar desde su casa, desde las instalaciones del cliente o mientras están de viaje, de la misma forma que si estuvieran en la oficina. La computación móvil introduce el concepto de base de datos móvil. Una base de datos 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.

Arquitectura: La arquitectura general de una plataforma móvil es un modelo distribuido

formado por computadores fijos, estaciones base y unidades móviles. Los computadores fijos son computadores de uso general que no disponen de medios para comunicarse con las unidades móviles. Las estaciones base disponen de enlaces inalámbricos para conectar

CREATE DATABASE IF NOT EXISTS bbdd_federada;

USE bbdd_federada;

DROP TABLE IF EXISTS `cliente_federada`;

CREATE TABLE `cliente_federada` (

ìdCliente` int(10) unsigned NOT NULL auto_increment,

`Nombre` varchar(45) NOT NULL,

Àpellidos` varchar(45) NOT NULL,

PRIMARY KEY (ìdCliente`)

) ENGINE=FEDERATED DEFAULT CHARSET=utf8

COMMENT:’mysql://root@remote_host:9306/bbdd1/cliente’;





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.

Arquitectura general de una plataforma móvil (Dunham y Helal, 1995)


Las unidades móviles se pueden mover libremente 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 a la información

aunque las unidades móviles se muevan entre las celdas.

Modos de funcionamiento: Hay dos modos de funcionamiento para trabajar con los

datos:

El usuario de un dispositivo móvil se conecta al servidor de base de datos corporativo y

trabaja directamente con los datos.






El usuario descarga una copia de los datos y trabaja con ellos de forma local.

Posteriormente, se conectará al servidor de base de datos corporativo para actualizar la

base de datos.

La adopción del modo funcionamiento depende fundamentalmente de los requisitos de cada

aplicación. Otro factor importante a la hora de elegir el modo de funcionamiento es la tecnología

de comunicación utilizada para conectar a las estaciones base; el costo puede ser elevado si la

conexión con el servidor es permanente y se utiliza una comunicación de pago como GPRS.

6. Sistemas Gestores de Bases de Datos móviles: Muchos fabricantes ofrecen SGBD móviles

capaces de comunicarse con los principales SGBD relacionales. 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.

7. Aplicaciones móviles y tipos de datos: Las aplicaciones móviles se clasifican en las dos siguientes categorías: aplicaciones verticales y aplicaciones horizontales (Imielinski y Badrinath, 1994).

En las aplicaciones verticales, los usuarios acceden a los datos en una celda específica; fuera de la

celda los datos no están disponibles. Un ejemplo de aplicación vertical es la obtención de

información sobre las plazas libres de un determinado parking. En las aplicaciones horizontales, los

datos están distribuidos por todo el sistema, y los usuarios pueden acceder a ellos desde cualquier

celda. La aplicación horizontal más común es el acceso al correo electrónico.

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, los datos de seguros de una

compañía aseguradora que vende productos utilizando agentes comerciales.

Las aplicaciones horizontales utilizan, principalmente, datos públicos, mientras que las

aplicaciones horizontales suelen utilizar más los datos compartidos.

8. 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 para el intercambio de datos entre bases de datos

relacionales y bases de datos no relacionales.

QAnywhere: facilita el desarrollo de aplicaciones móviles robustas y seguras.

SQL Remote: permite a los usuarios de dispositivos móviles sincronizar sus datos con otras

bases de datos SQL Anywhere.

DB2 Everyplace de IBM es una base de datos relacional y un servidor de sincronización que

permite extender las aplicaciones y los datos empresariales a dispositivos móviles. Gracias a un

consumo de recursos reducido, esta base de datos puede integrarse en dispositivos como PDAs y

teléfonos móviles.

Microsoft también ofrece una base de datos para dispositivos móviles. Se trata de Microsoft SQL

Server Compact 3.5, un motor de bases de datos que permite desarrollar aplicaciones en cualquier

plataforma Windows incluyendo Tablet PCs, Pocket PCs, Smart 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.

Otros productos menos utilizados son Borland’s JDataStore, una base de datos Java para

dispositivos móviles y aplicaciones Web, o MobiSnap, un proyecto de investigación cuyo objetivo

es soportar el desarrollo de aplicaciones con bases de datos relacionales en entornos móviles.





9. 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 los dispositivos móviles estén continuamente conectados al servidor, Oracle Database Lite 10g proporciona una pequeña base de datos para gestionar los datos empresariales de forma local en el dispositivo móvil.

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.

Los pasos para poner en funcionamiento una aplicación con Oracle Database Lite 10g son los

siguientes:

1. Instalar y configurar la base de datos Oracle en el servidor.

2. Instalar y configurar el Mobile Server en el equipo que hará de intermediario entre los

dispositivos móviles y el servidor.

3. Instalar y configurar el Mobile Server Repository en el servidor.

4. Instalar Oracle Lite RDBMS y Mobile Sync en los dispositivos móviles; para facilitar esta

tarea, Oracle ofrece un producto llamado Mobile Development Kit, que instala

rápidamente todos los componentes en los dispositivos móviles.

Una base de datos local Oracle Lite contiene un subconjunto de los datos almacenados en la base

de datos Oracle. Los cambios realizados en el dispositivo móvil deben sincronizarse con los datos

del servidor. De esta tarea se encarga el módulo Mobile Sync; primero envía los cambios al Mobile

Server, y después descarga los nuevos cambios y los aplica en la base de datos local Oracle Lite.

Sincronización de datos entre la base de datos local y la base de datos remota






5. Similitudes entre Bases de Datos Móviles y Bases de Datos Federadas:

Las dos bases de datos son modelos distribuidos de bases de datos a los cuáles se accede

de forma remota, ya sea desde un equipo fijo o un equipo móvil.

Los dos sistemas tienen mecanismos de privilegios de usuarios. Dependiendo de los

privilegios que tenga el usuario que accede al sistema, dicho usuario podrá acceder a una

parte del esquema u a otra.

En estos sistemas el usuario no es consciente de la disposición geográfica en la que se

encuentra el servidor o servidores de bases de datos. Esta característica también da al

usuario un gran nivel de movilidad y de acceso a los datos desde cualquier punto.

Son sistemas complejos que necesitan una gran infraestructura que dé soporte a este tipo

de bases de datos.

Necesitan tener definidos mecanismos de concurrencia de los datos para que no se vea

dañada la integridad de los mismos en el caso de que varios usuarios accedan a los

mismos datos a la vez.

Al tener la parte de almacenamiento de datos, y el acceso a los mismos, distribuida, se

libera de una gran carga computacional a los equipos implicados en el sistema.

Para acceder a dichos sistemas se necesita una interfaz, adaptada al dispositivo desde el

cual se va a acceder, que dé soporte y acceso a las funcionalidades disponibles al usuario

por parte del sistema.

6. Diferencias entre Bases de Datos Móviles y Bases de Datos Federadas:

A los sistemas de bases de datos móviles se accede por medio de dispositivos móviles.

Éstos, a su vez, acceden por medio de estaciones base y están comunicados directamente

con la base de datos, aunque también se puede acceder desde equipos fijos. Las bases de

datos federadas sólo son accesibles desde equipos fijos conectados a la infraestructura del

sistema de bases de datos.

Los sistemas de bases de datos móviles están formados por un sólo tipo gestor de bases de

datos, y todos los equipos conectados al sistema atacan al mismo gestor de base de datos.

A diferencia de éstos, las bases de datos federadas permiten conectar diferentes sistemas

gestores de bases de datos, que conforman una sola base de datos.

Los sistemas de bases de datos móviles permiten a los usuarios trabajar de forma

desconectada con los datos, y una vez que éstos han sido modificados, los usuarios

sincronizan dichos datos con el sistema. Esto evita que los dispositivos móviles tengan que

estar siempre conectados al sistema para interactuar y acceder a la base de datos.

En el caso de las bases de datos móviles, el sistema se puede reducir sólo al dispositivo

móvil que lo ejecuta, ya que éste es el único que contiene la base de datos y accede a





ellos. Este tipo de sistemas son sistemas gestores de bases de datos embebidos en el

mismo dispositivo.

Las bases de datos federadas son un conjunto de esquemas unificados, a diferencia de las

bases de datos móviles, que sólo disponen de un esquema global.

Los sistemas de bases de datos federados permiten dar acceso a una gran cantidad de

datos que los demás sistemas no podrían permitir ni soportar.

7. ¿En qué casos es más recomendable usar un sistema u otro?: Las bases de datos móviles

son recomendadas en los casos en los que los usuarios deben estar moviéndose de un lugar para otro para realizar las funciones y cuando la información que deben tratar se puede mostrar y tratar en un dispositivo móvil. Este tipo de base de datos también permite a los dispositivos móviles y a las aplicaciones que corren en ellos almacenar datos, con todas las ventajas que ofrece un gestor de base de datos. Los sistemas de bases de datos federados son usados cuando la cantidad de datos es muy grande y, además, cuando los mismos se encuentren en diferentes sistemas. Estos sistemas permiten unificar las bases de datos para permitir al usuario acceder a los datos de forma transparente, sin que sea consciente de la modularidad de la base de datos, y así poder acceder a diferentes datos de diferentes bases de datos a la vez.

EJERCICIO DE AUTOEVALUACIÓN

1. Defina en sus propias palabras que es una Base de Datos Federada.

2. ¿Cuáles son las principales características de los SGBDF?

3. ¿En qué consiste el SGBDF fuertemente acoplados?

4. ¿En qué consisten los dos tipos de arquitecturas para el manejo de bases de datos

federadas?

5. La implementación de este tipo de base de datos concierne una serie de problemas que

se cite algunos de ellos.

6. ¿Qué son las Bases de Datos Móviles?

7. ¿Cuál es la arquitectura general de una plataforma móvil?

8. Hay dos modos de funcionamiento para trabajar con los datos. Explíquelos.

9. ¿Cuáles son las tres categorías de en qué se clasifican los datos?

10. Cite tres ejemplos de Bases de Datos Móviles.





5. RENDIMIENTO

Identificar de forma general el concepto de paralelismo en las bases de datos, el cual se puede

definir como la partición de la base de datos (normalmente a nivel de relaciones) para procesar de

manera paralela en diferentes discos y con distintos procesadores una sola operación sobre la

base de datos.

OBJETIVO GENERAL

Implementar la base de datos utilizando las tecnologías de bases de datos avanzadas.


Identificar de forma general el concepto de paralelismo en las bases de datos y

reconocerla como una tecnología innovadora para manejar ordenadamente todo tipo de

recursos, entre ellos equipos de cómputo, almacenamiento y aplicaciones definidas.

Prueba Inicial

1. Defina que son las Bases de Datos Paralelas.

2. ¿Qué es paralelismo E/S?

3. ¿Qué es paralelismo entre consultas?

4. Enumere 5 características de las Bases de Datos GRID.

5. Identifique 5 ventajas e inconvenientes de las Bases de Datos en un Sistema GRID.

6. ¿Qué son los metadatos en Bases de Datos en un Sistema GRID.

5.1. Bases de Datos Grid y Paralelas

1. Bases de Datos Paralelas:

Introducción: De forma general el concepto de paralelismo en las bases de datos lo podríamos

definir como la partición de la base de datos (normalmente a nivel de relaciones) para poder

procesar de forma paralela en distintos discos y con distintos procesadores una sola operación

sobre la base de datos. Hace unos años este tipo de bases de datos estaban casi descartadas pero

actualmente casi todas las marcas de bases de datos venden este producto con éxito. Esto se ha

debido ha:

Los requisitos transaccionales que tienen las empresas han aumentado al mismo tiempo

que ha crecido el empleo de computadoras. Además los sitios web tienen millones de

visitantes para los que se requieren bases de datos enormes.





Las empresas utilizan cada vez mayores volúmenes de datos para planificar sus

actividades. Las consultas usadas para estos fines son de ayuda a la toma de decisiones y

pueden necesitar hasta varios terabytes de datos que no se pueden manejar con un único

procesador en el tiempo necesario.

La naturaleza orientada a conjuntos de las consultas se presta a la paralelización.

Las máquinas paralelas con varios procesadores son relativamente baratas.

El paralelismo se usa para mejorar la velocidad en la ejecución de consultas. Además el

paralelismo se usa para proporcionar dimensionabilidad ya que la creciente carga de trabajo se

trata sin incrementar el tiempo de respuesta pero incrementando el grado de paralelismo. Existen

cuatro arquitecturas de sistemas paralelos:

De memoria compartida: Todos los procesadores comparten una memoria común.

De discos compartidos: Todos los procesadores comparten un conjunto de discos común.

Sin compartimiento: Los procesadores no comparten ni memoria ni disco.

Jerárquica: Este modelo es un híbrido de las arquitecturas anteriores.

Paralelismo de E/S: De forma general podemos hablar de paralelismo de E/S cuando

hablamos de divisiones en las relaciones entre varios discos para reducir el tiempo

necesario de su recuperación. Normalmente la división más común en un entorno de

bases de datos paralelas es la división horizontal. En este tipo de división las tuplas de

cada relación se dividen entre varios discos de modo que cada tupla resida en un disco

distinto. Suponiendo que tenemos n discos (D0,D1,…,Dn-1) entre los que se van a dividir

los datos, existen varias estrategias de división:

Turno rotatorio: Se recorre la relación y la i-ésima tupla se envía al disco Di mod n quedando una

distribución homogénea de las tuplas en los discos.

División por asociación: Se escogen varios atributos del esquema de la relación y se designan

como atributos de división. Se escoge una función de asociación cuyo rango es

{0,1,…,n-1}. Cada tupla de la relación original se asocia en términos de los atributos de división. Si

la función de asociación devuelve i, la tupla de ubica en el disco DI.

División por rangos: Se distribuye rangos contiguos de valores de los atributos a cada disco. Para

ello se escoge un atributo de división, AD, como vector de división y la relación se divide de la

siguiente manera:

Sea *vo, v1, …, vn-2] el vector de división con i<j y vi<vj. Considérese una tupla t tal que t[A]=x.

Si x< vo entonces t se ubica en el disco Do.

Si x≥vn-2 entonces t se ubica en el disco Dn-1.

Si vi≤x < vi+1 entonces t se ubica en el disco DI+1





Comparativa entre técnicas de división: Cuando ya hemos dividido una relación en varios

discos se puede recuperar en paralelo utilizándolos todos de la misma manera que se

puede escribir en paralelo cuando se está dividiendo una relación. Por lo tanto, cuando se

quiera leer (o escribir) la relación completa ganaremos tiempo gracias al paralelismo.

Además de leer de forma completa una relación existen otro tipo de lecturas o consultas:

Exploración de la relación completa: Ya mencionada

Consultas concretas: Buscan tuplas con un determinado valor para un atributo concreto.

Consultas de rango: Buscan tuplas con un valor que esté dentro de un rango para un

atributo concreto.

Las técnicas de división explicadas permiten estos tipos de acceso pero con diferentes niveles de

eficacia:

Turno rotatorio: Se adapta bien a la exploración completa pero no es eficiente para

consultas concretas y de rango ya que tiene que buscar en todos los discos.

División por asociación: Este esquema se adapta bien a las consultas concretas basadas en

el atributo de división ya que dirigimos la consulta al disco que se nos indica la función de

asociación para el atributo y el valor del mismo. También se adapta bien a una exploración

completa si la función de asociación reparte bien las tuplas en los discos. Sin embargo no

es adecuada esta técnica para consultas concretas cuando el atributo de búsqueda no

coincide con el atributo de división.

División por rangos: Se adapta bien a las consultas concretas y de rango basadas en el

atributo de división. Para consultas concretas se debe analizar el vector de división para

ver en que disco está la tupla al igual que para una consulta de rango se consulta el vector

de división para ver en que rango de discos están las tuplas.

Resumiendo, la elección de la técnica depende de las operaciones que se vayan a ejecutar.

En general se prefiere división por asociación o por rangos a turno rotatorio. En la siguiente tabla

se resume la comparativa:





http://alarcos.inf-cr.uclm.es/doc/bbddavanzadas/07-08/Rendimiento.pdf

El problema de las divisiones por asociación es que tienden a almacenar un alto porcentaje de

tuplas en algunos discos específicos, situación que no se da con el turno rotatorio. Esto se debe a

que muchas tuplas contiene valores similares en sus atributos. Para minimizar este problema se

debe de elegir un vector de división equilibrado.

Si una relación contiene un número pequeño de tuplas ésta no debe ser dividida y debe

almacenarse en un solo disco.

2. Paralelismo entre consultas: Los sistemas de bases de datos con arquitectura paralela

deben asegurar de que dos procesadores no actualicen simultáneamente los mismos datos de manera independiente. Cuando un procesador accede a los datos o los actualiza, el sistema de bases de datos debe garantizar que tenga su última versión en la memoria intermedia. El problema de asegurar que la versión sea la última disponible se denomina problema de coherencia de cache. Existen una serie de protocolos para garantizar la coherencia de cache, que normalmente se integran con los de control de concurrencia para reducir la sobrecarga.

Los protocolos de este tipo de sistemas de disco compartido son los siguientes:

Antes de cualquier acceso de lectura o escritura de una página, la transacción la bloquea

en modo compartido o excluso, según corresponda. Inmediatamente después de obtener

el bloqueo compartido o exclusivo de la página, la transacción lee también su copia más

reciente del disco compartido.

Antes de que una transacción libere el bloqueo exclusivo de una página, la traslada al disco

compartido, posteriormente libera el bloqueo.





Con este protocolo se garantiza que cuando una transacción establece un bloqueo

compartido o exclusivo sobre una página, obtenga la copia correcta de la página.

3. Paralelismo en consultas: Es la ejecución en paralelo de una única consulta entre varios

procesadores y discos, cuyo objetivo es acelerar las consultas de ejecución prologada. Por

tanto se puede hacer paralelas las consultas haciendo paralelas las operaciones que las

forman.

Existen dos maneras de ejecutar en paralelo una sola consulta:

Paralelismo en operaciones. Se puede acelerar el procesamiento de las consulta haciendo

paralela la ejecución de cada una de sus operaciones individuales ordenación, selección,

proyección y reunión.

Paralelismo entre Operaciones. Se puede acelerar el procesamiento de la consulta

ejecutando en paralelo las diferentes operaciones de las expresiones de las consultas.

Por lo tanto el objetivo que se persigue es dividir la relación que interviene en la consulta por

medio de técnicas de división de relaciones, guardar dichas relaciones en discos que van a ser

gestionados cada uno de ellos por un procesador, a su vez, cada procesador ejecuta su consulta

local y cada uno de estos resultados parciales se unen para formar la respuesta a la consulta.

Paralelismo en operaciones: Ya que las operaciones relacionales trabajan con relaciones

que contienen grandes conjuntos de tuplas, las operaciones se pueden paralelizar

ejecutándolas sobre subconjuntos diferentes de las relaciones en paralelo. Según el tipo

de operación se siguen distintos criterios en el tratamiento que son:

Ordenación Paralela

Reunión Paralela.

Ordenación paralela: Dependiendo del criterio en la división de la relación se pueden

distinguir dos tipos de ordenación:

Ordenación división de Rangos: Esta forma de división por rangos posee dos etapas

diferenciadas:

Redistribuir las tuplas de la relación utilizando una estrategia de división por rangos, de

manera que todas las tuplas que se hallen dentro del rango i-ésimo se envíen al

procesador Pi, que almacena temporalmente la relación en el disco Di. Para implementar

en paralelo la división por rangos cada procesador lee las tuplas de su disco y las envía al

procesador de destino. Cada procesador P0,P1…Pn también recibe las tuplas

correspondientes a su partición y las almacena localmente.





Cada uno de los procesadores ordena localmente su partición de la relación sin interactuar con los

demás. La operación final de mezcla es trivial ya que la división por rangos de la primera etapa

asegura que los valores de la clave del procesador Pi sean menores que los procesador Pj

Ordenación y mezcla externa paralela: Este tipo de ordenación es una alternativa a la efectuada

por la división por rangos. Las etapas que se definen una vez que la relación se ha divida entre los

diferentes discos D1,D2…Dn-a son las siguientes:

1. Cada procesador Pi ordena localmente los datos del disco Di

2. El sistema mezcla las partes ordenadas por cada procesador para obtener el resultado

ordenado final.

A su vez el paso en el que el sistema realiza la mezcla puede ser también paralelizado mediante la

siguiente secuencia de acciones.

1. El sistema divide en rangos las particiones ordenadas encada procesador Pi entre los

procesadores P0,P1…Pn-1. Envía las tuplas de acuerdo con el orden establecido por lo que

cada procesador recibe las tuplas en corrientes ordenadas.

2. Cada procesador Pi, realiza una mezcla de las corrientes según las recibe para obtener una

sola parte ordenada.

3. Las partes ordenadas de los procesadores P0,P1… Pn-1 se concatenan para obtener el

resultado final.

Reunión paralela: La operación reunión exige que el sistema compare pares de tuplas

para ver si satisface la condición de reunión, si la cumple añade el par al resultado de la

reunión. Los algoritmos de reunión paralela intentan repartir entre varios procesadores los

pares que hay que comparar. Cada procesador procesa luego localmente parte de la

reunión. Después, el sistema reúne los resultados de cada procesador para producir el

resultado final. Existe un problema por el cual no todas los tipos de reuniones pueden ser

divididas por lo que existen distintas formas de proceder que son:

Reunión por División: Válida para reuniones de tipo equirreuniones y reuniones naturales, en la

cual existen n procesadores y las relaciones que hay que reunir son r y s. La reunión por división

funciona de esta forma:

El sistema divide las relaciones r y s en n particiones r0,r1,…rn-1 y s0,s1,…sn-1

Envía las particiones ri y si al procesador Pi, donde la reunión se procesa localmente.

Existen dos maneras diferentes de dividir las relaciones r y s y son:

División por rangos de los atributos de reunión, en el que se debe usar el mismo vector de

división.





División por asociación de los atributos de reunión, se debe usar la misma función de

asociación.

Una vez divididas las relaciones se pueden utilizar localmente cualquier técnica de reunión en cada

procesador Pi para calcular la reunión de ri y sí.

Reunión con fragmentos y replicas: Proporcionan una alternativa para las reuniones que no puede

ser procesada por la técnica de reunión por división, como por ejemplo si la condición de reunión

es una desigualdad. En este tipo de reuniones pueden paralelizarse utilizando una técnica

denominada fragmentos y replicas, cuyo funcionamiento es el siguiente.

1. El sistema divide una de las relaciones (por ejemplo s) mediante cualquier técnica de

división, incluida por turno rotatorio.

2. El sistema replica la otra relación r en todos los procesadores

3. El procesador Pi procesa localmente la reunión de ri con todos, utilizando cualquier técnica

de reunión.

Reunión por asociación dividida en paralelo. La reunión por asociación realizada en cada

procesador es independiente de las realizadas en otros procesadores, y recibir las tuplas de ri y de

si es parecido a leerlas del disco. En concreto, se puede utilizar el algoritmo híbrido de reunión por

asociación para guardar en caché algunas de las tuplas de entrada, y evitar así los costos de

escribirlas y volver a leerlas.

http://alarcos.inf-cr.uclm.es/doc/bbddavanzadas/07-08/Rendimiento.pdf





Otras operaciones relacionales: También se puede realizar en paralelo la evaluación de

otras operaciones relacionales:

Selección: Sea la selección me(r). Considérese primero el caso en el que e es de la forma ai = v,

donde ai es un atributo y v es un valor. Si la relación r se divide basándose en ai la selección se

lleva a cabo en un solo procesador. Si e es de la forma l ) ai ) u (es decir, que e es una selección de

rango) y la relación se ha dividido por rangos basándose en ai, entonces la selección se lleva a cabo

en cada procesador cuya partición se solape con el rango de valores especificado. En el resto de

los casos la selección se lleva a cabo en todos los procesadores en paralelo.

Eliminación de duplicados: La eliminación de duplicados puede llevarse a cabo por ordenación;

puede utilizarse cualquiera de las técnicas de ordenación en paralelo, con la optimización de

eliminar los duplicados durante la ordenación tan pronto como se encuentren. También se puede

realizar la eliminación de duplicados en paralelo dividiendo las tuplas (mediante división por

rangos o por asociación) y llevando a cabo localmente en cada procesador la eliminación de

duplicados.

Proyección: Se puede llevar a cabo la proyección sin eliminación de duplicados según se leen en

paralelo las tuplas del disco. Si se va a llevar a cabo la eliminación de duplicados se puede utilizar

las técnicas que se acaban de describir.

Agregación: La agregación puede considerarse una operación. Se puede paralelizar la operación

dividiendo la relación basándose en los atributos de agrupación y procesando luego localmente los

valores de agregación en cada procesador. Se puede utilizar división por rangos o por asociación.

Si la relación ya está dividida basándose en los atributos de agrupación se puede omitir el primer

paso.

Costo de la evaluación en paralelo de las operaciones: Se puede obtener el paralelismo

dividiendo la E/S entre varios discos y el trabajo de la UCP entre varios procesadores. Si se

logra un reparto así sin sobrecarga y no hay sesgo en el reparto del trabajo, las

operaciones en paralelo que utilicen n procesadores tardarán 1/n lo que tardarían en un

solo procesador. Ya se sabe cómo estimar el costo de operaciones como la reunión o la

selección. El costo en tiempo del procesamiento paralelo sería entonces 1/n el del

procesamiento secuencial de la operación.

También hay que tener en cuenta los costos siguientes:

Los costos de iniciar la operación en varios procesadores.

El sesgo en la distribución de trabajo entre los procesadores, con algunos procesadores

con mayor número de tuplas que otros.





La contención de recursos como la memoria, los discos y la red de comunicaciones— que

dan lugar a retrasos.

El costo de construir el resultado final transmitiendo los resultados parciales desde cada

procesador.

Aunque dividir una sola consulta en varios pasos en paralelo reduce el tamaño del paso medio, es

el tiempo de procesamiento del paso más lento el que determina el tiempo empleado en procesar

la consulta en su conjunto. Una evaluación en paralelo de las particiones, por ejemplo, sólo es tan

rápida como la más lenta de sus ejecuciones en paralelo. Por tanto, el rendimiento se ve muy

afectado por cualquier sesgo en la distribución del trabajo entre los procesadores. El problema del

sesgo de la división está íntimamente relacionado con el del desbordamiento de particiones en las

reuniones por asociación secuenciales.

Se puede utilizar la resolución del desbordamiento y las técnicas de evitación desarrolladas para

las reuniones por asociación para tratar el sesgo cuando se utilice la división por asociación.

4. Paralelismo entre operaciones: Hay dos formas de paralelismo entre operaciones: el

paralelismo de encauzamiento y el paralelismo independiente.

Paralelismo de encauzamiento: El encauzamiento supone una importante fuente de economía de

procesamiento para el procesamiento de consultas de bases de datos. La ventaja principal de la

ejecución encauzada de las evaluaciones secuenciales es que se puede ejecutar una secuencia de

operaciones de ese tipo sin escribir en el disco ninguno de los resultados intermedios.

En los sistemas paralelos el encauzamiento se utiliza principalmente por la misma razón que en los

sistemas secuenciales. Sin embargo, el encauzamiento puede utilizarse también como fuente de

paralelismo, del mismo modo que el encauzamiento de instrucciones se utiliza como fuente de

paralelismo en el diseño de hardware. Esta forma de paralelismo se denomina paralelismo de

encauzamiento.

El paralelismo encauzado resulta útil con un número pequeño de procesadores, pero no puede

extenderse bien:

1. En primer lugar, las cadenas del cauce no suelen lograr la longitud suficiente para

proporcionar un alto grado de paralelismo.

2. En segundo lugar, no es posible encauzar los operadores de relación que no producen

resultados hasta que se ha tenido acceso a todas las entradas, como la operación

diferencia de conjuntos.

3. En tercer lugar, sólo se obtiene una aceleración marginal en los casos frecuentes en que el

costo de ejecución de un operador es mucho mayor que los de los demás operadores.





Por consiguiente, cuando el grado de paralelismo es elevado, la importancia del encauzamiento

como fuente de paralelismo es secundaria respecto de la del paralelismo de particiones. La razón

fundamental para utilizar el encauzamiento es que las ejecuciones encauzadas pueden evitar

escribir en el disco los resultados intermedios.

Paralelismo independiente: Las operaciones en las expresiones de las consultas que son

independientes entre sí pueden ejecutarse en paralelo. Esta forma de paralelismo se denomina

paralelismo independiente.

Al igual que el paralelismo encauzado, el paralelismo independiente no proporciona un alto grado

de paralelismo y es menos útil en sistemas con un elevado nivel de paralelismo, aunque resulta

útil con un grado menor de paralelismo.

4. Optimización de consultas: Un factor importante en el éxito de la tecnología relacional ha

sido el diseño con éxito de optimizadores de consultas. Los optimizadores de consultas

para la evaluación de consultas en paralelo son más complicados que los optimizadores de

consultas para la evaluación secuencial de consultas. En primer lugar, los modelos de

costos son más complicados dado que hay que tener en cuenta los costos de división, y

deben tenerse en consideración aspectos como el sesgo y la contención de recursos.

Resulta de mayor importancia el asunto de la paralelización de las consultas. Supóngase

que de algún modo se ha escogido una expresión (de entre las equivalentes a la consulta)

para utilizarla para evaluar la consulta.

El modo en que se paralelice cada operación y el número de procesadores que se utilizará

para ello.

Las operaciones que se encauzan entre los diferentes procesadores, las operaciones que

se ejecuten independientemente en paralelo y las que se ejecuten secuencialmente, una

tras otra.

5. Diseño de sistemas paralelos: La carga de datos en paralelo desde fuentes externas es un

requisito importante si se van a tratar grandes volúmenes de datos entrantes.

Un gran sistema paralelo de bases de datos debe abordar también los siguientes aspectos de

disponibilidad:

El poder de recuperación frente al fallo de algunos procesadores o discos.

La reorganización interactiva de los datos y los cambios de los esquemas.





Con un gran número de procesadores y de discos la probabilidad de que al menos un procesador o

un disco funcionen mal es significativamente mayor que en sistema con un único procesador y un

solo disco. Un sistema paralelo mal diseñado dejará de funcionar si cualquier componente

(procesador o disco) falla. Suponiendo que la probabilidad de fallo de cada procesador o disco es

pequeña, la probabilidad de fallo del sistema asciende.

Por tanto, los sistemas paralelos de bases de datos de gran escala se diseñan para operar incluso si

falla un procesador o un disco. Los datos se replican en al menos dos procesadores. Si falla un

procesador se puede seguir teniendo acceso desde los demás procesadores a los datos que

guarda. El sistema hace un seguimiento de los procesadores con fallos y distribuye el trabajo entre

los que funcionan. Las peticiones de los datos guardados en el emplazamiento con fallo se desvían

automáticamente a los emplazamientos de las copias de seguridad que guardan una réplica de los

datos.

Cuando se manejan grandes volúmenes de datos (del orden de terabytes), las operaciones

sencillas, como la creación de índices, y los cambios en los esquemas, como añadir una columna a

una relación, pueden tardar mucho tiempo (quizás horas o incluso días). Por tanto, es inaceptable

que los sistemas de bases de datos no estén disponibles mientras se llevan a cabo tales

operaciones. Los sistemas paralelos de bases de datos permiten que tales operaciones se lleven a

cabo interactivamente, es decir, mientras el sistema ejecuta otras transacciones.

6. Bases de Datos Grid:

Introducción: Grid es una tecnología que surgió como una nueva forma de computación

distribuida. Ian Foster y Carl Kesselman son considerados los padres de esta tecnología,

introducida por ellos en los años 90. Esta tecnología se basa en la utilización de recursos externos

además de los locales, logrando con ello una mayor disponibilidad de recursos para la realización

de una tarea.

La tecnología estándar, o una de las más utilizadas en su comienzo al menos, es el Globus Toolkit.

El objetivo es permitir el uso de recursos libres de otras computadoras localizadas en otro lugar

geográfico y que no estén utilizando toda su potencia. De este modo alguien que no disponga de la

suficiente potencia o recursos en su lugar de trabajo, no se verá imposibilitado para realizar la

tarea deseada ya que podrá hacer uso de recursos ajenos.

Como consecuencia del uso de una red Grid, un usuario puede hacer uso de recursos libres

situados en los computadores que se encuentren dentro de esta red Grid, sin importar la

localización del mismo. De este modo, el usuario dispone de un computador ficticio con la

potencia, disco duro o memoria RAM necesitada.





Por otro lado, podemos decir que con Grid, no ponemos atención en los datos que se transmiten

en sí, como es el caso de los sistemas Cliente-Servidor sino que el punto de interés y estudio son

los recursos computacionales y el uso que se hace de ellos.

Otro avance de Grid es que genera un incremento de las posibilidades del uso de internet ya que

proporciona un incremento de su usabilidad. De este modo se obtiene una mayor velocidad de

procesamiento así como la facilidad de tener bases de datos de mayor tamaño.

Una definición de computación Grid encontrada en wikipedia es la siguiente:

GRID COMPUTING: Es una tecnología innovadora que permite utilizar de forma coordinada todo

tipo de recursos (entre ellos cómputo, almacenamiento y aplicaciones específicas) que no están

sujetos a un control centralizado. En este sentido es una nueva forma de computación distribuida,

en la cual los recursos pueden ser heterogéneos (diferentes arquitecturas, supercomputadores,

clusters...) y se encuentran conectados mediante redes de área extensa (por ejemplo Internet).

Desarrollado en ámbitos científicos a principios de los años 90 su entrada al mercado comercial

siguiendo la idea de la llamada Utility Computing supone una revolución que dará mucho que

hablar. Las características de esta arquitectura serían:

Capacidad de balanceo de sistemas: no habría necesidad de calcular la capacidad de los

sistemas en función de los picos de trabajo, ya que la capacidad se puede reasignar desde

la granja de recursos a donde se necesite;

Alta disponibilidad. Con la nueva funcionalidad, si un servidor falla, se reasignan los

servicios en los servidores restantes;

Reducción de costos: Con esta arquitectura los servicios son gestionados por "granjas de

recursos". Ya no es necesario disponer de "grandes servidores" y podremos hacer uso de

componentes de bajo costo.

7. Grid middleware: En las tecnologías Grid, además de tenerse en cuenta el hardware como

son los recursos, los dispositivos de almacenamiento y por supuesto la propia red Grid, es necesario un soporte software que gestione todas las transferencias y el modo en que se realizan, así como la seguridad, todo esto resulta una tarea complicada y no exenta de posibles errores. Esto no implica que la aparición de un error en un equipo y en una localización determinada, provoque el error en toda la red.

8. Bases de datos GRID: Las Bases de Datos Grid nos proporcionan una visión uniforme de

bases de datos heterogéneas en los entornos Grid. Es decir, puesto que existen diversos

tipos de bases de datos, refiriéndonos con ellos a que éstas pueden ser relacionales,

orientadas a objetos, en XML, etcétera, nuestro sistema nos tiene que proporcionar la

abstracción necesaria de los datos para que el usuario no distinga entre sí está accediendo

a una relacional o a una orientada a objetos, ya que el usuario no le importa cómo se





realice el trabajo, solo necesita que se haga y debe ser el Grid middleware quien se ocupe

de que se efectúe correctamente.

Por otro lado la especificación de los servicios de bases de datos deben ser ortogonales a los

mecanismos de autentificación y autorización de los sistemas Grid, lo que significa que las bases

de datos deben poseer sistemas de seguridad que identifiquen a un usuario del Grid y que por

tanto permitan o no su acceso. Las propias bases de datos deben de ser transparentes al usuario,

logrando así que este se abstraiga de todo lo relacionado con el cómo se hace, donde o incluso

que recursos o almacenamiento está siendo utilizado. Del mismo modo, no deberá preocuparse

por la administración de los recursos.

9. Requisitos para la utilización de BBDD en Grid: Para utilizar Base de Datos en el GRID,

estas primeramente deben de cumplir una serie de condiciones previas, como son las

normas de seguridad en un GRID.

Algunos aspectos claves de la seguridad en el GRID son:

Autentificación: Verificación de la validez de la identidad de un usuario, recurso, servicio,..

Autorización: Cada recurso o usuario solo debe usar los servicios para los que está

permitido (control de acceso).

Integridad: Asegura que los datos no han sido alterados fraudulentamente.

Confidencialidad: Información sensible como puede ser información de carácter. personal,

orientación sexual, datos médicos o bancarios, no puede ser observada por terceros.

Gestión de claves: Hace referencia a la gestión de seguridad, proceso de distribución,

generación y almacenamiento de claves.

Encriptación:

Simétrica: El proceso de encriptación se realiza usando la misma clave privada.

Inconvenientes: El emisor y el receptor deben intercambiar la clave.

Asimétrica: Se utilizan dos claves diferentes para encriptar y desencriptar datos.

Criptografía de clave pública.

Lentitud considerable en mensajes grandes.

Aparición de patrones que puede simplificar su criptoanálisis.

Secure Socket Layer/ Transport Layer Security (SSL/ TLS): Protocolo de comunicación

segura.

Autentificación Mutua: Dos entidades que quieren comunicarse usan su clave pública

almacenada en un certificado digital para autentificarse.

Estos servicios fundamentales se garantizan mediante:

GRID Security Infrastructure (GSI)





Public Key Infrastructure (PKI)

10. Integración de Bases de datos en un sistema Grid: En los sistemas de bases de datos Grid los servicios ofrecidos deben estar, en la medida de lo posible estandarizados, y decimos en la medida de lo posible ya que resulta imposible que todos los servicios se estandaricen debido a la existencia de distintos tipos de bases de datos que pueden existir en el sistema y que pueden estar usando lenguajes diferentes que no pueden ser integrados en un único lenguaje debido a su naturaleza. De esta forma podemos aumentar la portabilidad de dichos sistemas. Otra de las ventajas de estandarizar siempre es reducir el esfuerzo de construcción del sistema.

Con lo mencionado anteriormente se hace imprescindible la presencia de los metadatos en este

tipo de sistemas. Con los metadatos lo que conseguimos es que cada sistema que se conecta al

Grid pueda comunicar al resto los servicios que ofrece. Del mismo modo podremos saber las

operaciones que soporta cada uno. El sistema gestor de bases de datos (SGBD) va a ser el

encargado de saber qué servicios ofrece cada una de las bases de datos, que operaciones se

pueden realizar sobre ellas y de gestionar los permisos de acceso a cada una.

Los servicios que cada sistema debe tener disponibles dentro del Grid son los siguientes:

Metadatos: Nos dan la información sobre los servicios que ofrece el sistema. Además,

cuando los usuarios del sistema soliciten un servicio no saben en qué sistema está y

mediante los metadatos él se pueden construir dinámicamente las interfaces para acceder

a los distintos sistemas de bases de datos que forman parte del Grid.

Manejo de consultas: Como hemos comentado más arriba los lenguajes pueden ser

diferentes. Por eso en los metadatos se proporciona la información necesaria sobre el

lenguaje de consulta que soporta cada base de datos. También es importante que los

resultados de una consulta se puedan enviar a distintos destinos y que sean comprensibles

por éstos para poder construir sistemas más amplios y complejos.

Transacciones: Estas operaciones son en las que interviene un único sistema de base de

datos y a su vez que cada sistema individual tome parte en las transacciones distribuidas.

La gran variedad de tipos de transacciones que maneja el sistema gestor de base de datos

de un sistema Grid, debido sobre todo a la heterogeneidad de los sistemas individuales

que lo componen, hace que el servicio deba poner claramente en conocimiento del resto

cual es el tipo de transacciones que soporta el sistema individual de base de datos.

Carga del sistema o carga de datos: Cuando tenemos grandes cantidades de taos este tipo

de servicio debe ser capaz de acceder a los protocolos de comunicación del sistema Grid

para llevar a cabo la transferencia de esos datos.





Notificación: Sirve para notificar los cambios que se producen a los clientes que deseen

recibir esa información. Los clientes deben poder expresar si están interesados en recibir

las notificaciones cuando se inserten o se borren datos o cuando se realicen

actualizaciones o en caso de varias acciones como insertar y actualizar. La forma más

sencilla de que este servicio se ponga en funcionamiento es que el sistema gestor de base

de datos subyacente proporcione la ayuda necesaria, por ejemplo mediante disparadores.

Planificación: Se debe permitir por ejemplo que cuando un superordenador conecte con

un DBS, la información recuperada del DBS se pueda procesar por el superordenador.

El ancho de banda en la red que los conecta necesita ser reservada. Como el acceso exclusivo a un

DBS no es práctico, se requieren mecanismos con suficientes recursos (discos, CPUs, memoria,

red).

11. Ventajas e Inconvenientes de las BBDD en un Sistema GRID: Las bases de datos alojadas

en un sistema GRID van a heredar todas las características: ventajas e inconvenientes del

sistema al que pertenecen. La Computación GRID está creada con el fin de ofrecer una

solución a determinadas cuestiones, como problemas que requieren de:

Un gran número de ciclos de procesamiento o un acceso a una gran cantidad de datos.

Las principales ventajas de un sistema GRID son:

Nunca queda obsoleta, ya que se integran diferentes tipos de máquinas y de recursos y

todos los recursos se aprovechan. Si se renuevan todas las PCs de una oficina, se pueden

incorporar las antiguas y las nuevas.

Facilita la posibilidad de compartir, acceder y gestionar información, mediante la

colaboración y la flexibilidad operacional, aunando no sólo recursos tecnológicos dispares,

sino también personas y aptitudes diversas.

Permite a las empresas acceder y compartir bases de datos remotas. Esto es de gran

importancia en las empresas que se dedican a la investigación, en donde enormes

cantidades de información son generadas y analizadas casi a diario.

Las empresas pueden mejorar la calidad y el tiempo de entrega de los productos y

servicios que ofrecen, a la vez que reducen costos de TI al permitir la colaboración

transparente y la compartición de recursos.

Tiende a incrementar la productividad otorgando a los usuarios finales acceso a los

recursos de computación, datos y almacenamiento que necesiten, cuando los necesiten.





Se aprovechan los ciclos de procesamiento inutilizados de ordenadores que se encuentran

en diversas zonas geográficas.

Ejemplo: ordenadores que normalmente se encuentran inutilizados por la noche en una

compañía en Europa, podrían ser utilizados en el día por una sede de operaciones en

América.

El paralelismo puede estar visto como un problema, ya que una máquina paralela es muy

costosa. Pero, si tenemos disponibilidad de un conjunto de máquinas heterogéneas de

pequeño o mediano porte, cuya potencia computacional sumada sea considerable, eso

permitiría generar sistemas distribuidos de muy bajo costo y gran potencia

computacional.

La tolerancia a fallos significa que si una de las máquinas que forman parte del GRID

colapsa, el sistema lo reconoce y la tarea se reenvía a otra máquina, con lo cual se cumple

el objetivo de crear infraestructuras operativas flexibles y resistentes. Así se obtiene una

tecnología más robusta y resistente, capaz de responder a desastres.

Por tanto se puede decir que un sistema GRID proporciona:

Una forma transparente de ejecutar el trabajo que se desea:

Encuentra los recursos (maquinas) disponibles.

Asegura un acceso optimizado a los datos (incluyendo copias locales/ cache…).

Comprueba la autorización del usuario.

Monitoriza la ejecución.

Además, si es posible monitoriza el trabajo

Los principales inconvenientes de un sistema GRID son:

Necesita para mantener su estructura, de diferentes servicios como Internet, conexiones

de 24 horas, los 365 días, con banda ancha, servidores de capacidad, seguridad

informática, VPN, firewalls, encriptación, comunicaciones seguras, políticas de seguridad,

normas ISO, y algunas características más…

12. Metadatos en Bases de Datos en un Sistema GRID: ¿Por qué son necesarios los metadatos?: En los sistemas de bases de datos GRID los

servicios ofrecidos deben estar, en la medida de lo posible estandarizados ya que resulta

imposible que todos los servicios se estandaricen debido a la existencia de distintos tipos

de bases de datos en el sistema GRID y que pueden estar usando lenguajes diferentes que

no pueden ser integrados en un único lenguaje. De esta forma podemos aumentar la

portabilidad de dichos sistemas. Otra de las ventajas de estandarizar es reducir el esfuerzo

de construcción del sistema.

Con lo mencionado anteriormente se hace imprescindible la presencia de los metadatos

en este tipo de sistemas. Con los metadatos lo que conseguimos es que cada sistema que





se conecta al GRID pueda comunicar al resto los servicios que ofrece. Del mismo modo

podremos saber las operaciones que soporta cada uno.

El sistema gestor de bases de datos (SGBD) va a ser el encargado de saber qué servicios ofrece

cada una de las bases de datos, que operaciones se pueden realizar sobre ellas y de gestionar los

permisos de acceso a cada una.

Servicios que describen los metadatos: Los servicios que cada sistema debe tener

disponibles dentro del GRID son los siguientes:

Metadatos: Nos dan la información sobre los servicios que ofrece el sistema. Además,

cuando los usuarios del sistema soliciten un servicio no saben en qué sistema está y

mediante los metadatos se pueden construir dinámicamente las interfaces para acceder a

los distintos sistemas de bases de datos que forman parte del GRID.

Manejo de consultas: Como hemos comentado más arriba los lenguajes pueden ser

diferentes. Por eso en los metadatos se proporciona la información necesaria sobre el

lenguaje de consulta que soporta cada base de datos. También es importante que los

resultados de una consulta se puedan enviar a distintos destinos y que sean comprensibles

por éstos para poder construir sistemas más amplios y complejos.

Transacciones: Estas operaciones son en las que interviene un único sistema de base de

datos y a su vez que cada sistema individual tome parte en las transacciones distribuidas.

La gran variedad de tipos de transacciones que maneja el sistema gestor de base de datos

de un sistema GRID, debido sobre todo a la heterogeneidad de los sistemas individuales

que lo componen, hace que el servicio deba poner claramente en conocimiento del resto

cual es el tipo de transacciones que soporta el sistema individual de base de datos.

Carga del sistema o carga de datos. Cuando tenemos grandes cantidades de taos este tipo

de servicio debe ser capaz de acceder a los protocolos de comunicación del sistema GRID

para llevar a cabo la transferencia de esos datos.

Notificación. Sirve para notificar los cambios que se producen a los clientes que deseen

recibir esa información. Los clientes deben poder expresar si están interesados en recibir

las notificaciones cuando se inserten o se borren datos o cuando se realicen

actualizaciones o en caso de varias acciones como insertar y actualizar. La forma más

sencilla de que este servicio se ponga en funcionamiento es que el sistema gestor de base

de datos subyacente proporcione la ayuda necesaria, por ejemplo mediante disparadores.

Planificación: Se debe permitir por ejemplo que cuando un superordenador conecte con

un sistema de base de datos, la información recuperada de ese sistema pueda ser





procesada por el superordenador. El ancho de banda en la red que los conecta necesita

ser reservada. Como el acceso exclusivo a un sistema de base de datos no es práctico, se

requieren mecanismos con suficientes recursos (discos, CPUs, memoria, red).

EJERCICIO DE AUTOEVALUACIÓN

1. Defina el concepto de Paralelismo en las Bases de Datos.

2. ¿Cuáles con las técnicas de división?. Realice una comparativa entre ellas.

3. ¿Cuáles son las dos maneras de ejecutar en paralelo una sola consulta?

4. Dependiendo del criterio en la división de la relación se pueden distinguir dos tipos

de ordenación. Explique cada uno de ellos.

5. Existe un problema por el cual no todas los tipos de reuniones pueden ser divididas

por lo que existen distintas formas de proceder. ¿Cuáles son?. Explíquelas.

6. ¿Qué son los Optimizadores de consultas?

7. Un gran sistema paralelo de bases de datos debe abordar aspectos de

disponibilidad. ¿Cuáles son?

8. Defina: Bases de Datos GRID.

9. Mencione algunos aspectos claves de la seguridad en el GRID.

10. ¿Cuáles son los servicios que cada sistema debe tener disponibles dentro del Grid?

11. Mencione algunas Ventajas e Inconvenientes de las BBDD en un Sistema GRID.

12. ¿Por qué son necesarios los metadatos?

13. ¿Cuáles son los servicios que describen los metadatos?





6. PISTAS DE APRENDIZAJE

Recuerde: Las bases de datos tradicionales, son llamadas también pasivas.

Tenga en Cuenta: Cualquier modificación sobre el comportamiento reactivo se puede llevar a cabo

cambiando solamente las reglas activas, sin necesidad de variar las aplicaciones.

Tener Presente: Para definir Reglas Deductivas que permiten concluir, inferir u obtener

información nueva a partir de los datos almacenados o sucesos condicionados.

Recuerde: Una base de datos multimedia es un conjunto de información combinada, la cual puede

ser texto, arte gráfico, sonido, animación y vídeo.

Tenga en Cuenta: El Almacén de Datos permite recopilar la información de una forma confiable,

segura y de calidad.

Tenga Presente: Las bases de datos distribuidas son un grupo de información que corresponde a

un sistema que se encuentra repartido entre computadores de una misma red.

Recuerde: Una red de comunicación suministra las capacidades para que un proceso en ejecución

en un sitio de la red envíe y reciba mensajes de otro que se encuentra ejecutándose en un sitio

distinto.

Acuérdese: En un sistema federado los usuarios tienen acceso a la información, de los distintos

sistemas, a través de una interfaz común.

Tenga en Cuenta: Las propiedades de una base de datos federada son: heterogeneidad,

autonomía y distribución.

Recuerde: Gracias a esta computación, los usuarios logran acceder a una base de datos remota en

cualquier momento y en cualquier lugar.

Tener Presente: Una base de datos paralela es una tecnología innovadora que maneja

ordenadamente todo tipo de recursos, entre ellos equipos de cómputo, almacenamiento y

aplicaciones definidas.





7. GLOSARIO

Bases de Datos Activas: Un sistema de bases de datos activas es un sistema de gestión de bases

de datos (SGBD) que contiene un subsistema que permite la definición y la gestión de reglas de

producción (reglas activas).

Datos: Conjunto de símbolos que representan una determinada información.

Distribución: Se denomina distribución al reparto de uno o varios elementos.

Evento: Un evento es una variante de las propiedades para los campos cuyos tipos sean

delegados. Es decir, permiten controlar la forman en que se accede a los campos delegados y dan

la posibilidad de asociar código a ejecutar cada vez que se añada o elimine un método de un

campo delegado.

Objeto: Un programa tradicional se compone de procedimientos y datos, un programa orientado a

objetos se compone solamente de objetos, que es una encapsulación general de datos y de los

procedimientos para manipularlo.

Orientado a Objetos: Orientación a Objeto En la programación tradicional, se distingue entre los

datos y los procedimientos. En la técnica de programación orientada a objeto no es así, puesto que

no existen.

Portabilidad: Se define como la característica que posee un software para ejecutarse en diferentes

plataformas, el código fuente del software es capaz de reutilizarse en vez de crearse un nuevo

código cuando el software pasa de una plataforma a otra. A mayor portabilidad menor es la

dependencia del software con respecto a la plataforma.

Red: Una red de computadoras, también llamada red de ordenadores o red informática, es un

conjunto de equipos informáticos conectados entre sí por medio de dispositivos físicos que envían

y reciben impulsos eléctricos, ondas electromagnéticas o cualquier otro medio para el transporte

de datos, con la finalidad de compartir información y recursos y ofrecer servicios. Este término

también engloba aquellos medios técnicos que permiten compartir la información.

Servidor: En informática, un servidor es una computadora que, formando parte de una red, provee servicios

a otras computadoras denominadas clientes.

XML: El XML es considerado como un metalenguaje de definición de documentos estructurados mediante

marcas o etiquetas. Se trata de un estándar del W3C cuyo objetivo es crear unas reglas básicas para permitir

el intercambio de información estructurada entre aplicaciones, y en particular, entre aplicaciones web.





8. BIBLIOGRAFÍA

Sistemas de bases de datos orientadas a objetos: Conceptos y arquitecturas. Editorial: Addison-

Wesley / Diaz de Santos. Autores: Elisa Bertino, Lorenzo Martino.

Sistemas de bases de datos: Un enfoque práctico para diseño, implementación y gestión. 4ª

Edición. Editorial: Pearson Addison- Wesley. Autores: Thomas M. Connolly, Carolyn E. Begg.

Fundamentos de Bases de datos. 5ª Edición. Editorial: McGraw Hill. Autores: Silberschatz, Korth,

Sudarshan

Bases de Datos Orientadas a Objeto y el estándar ODMG. Autores: Clara Martín Sastre y Enrique

Medarde Caballero.

http://tejo.usal.es/~fgarcia/docencia/poo/02-03/trabajos/S1T3.pdf

http://kybele.escet.urjc.es/documentos/BD/T3-ModeloOR.pdf

http://informatica.uv.es/iiguia/DBD/Practicas/boletin_1.pdf

http://informatica.uv.es/iiguia/DBD/Teoria/capitulo_4.pdf

L.Mota Herranz y M. Celma Giménez - Métodos para la comprobación de la integridad de en bases

de datos deductivas

González Alvarado, Carlos. Sistema de Bases de Datos. Editorial Tecnológica de Costa Rica, Primera

Edición, 1996.

Elmasri, Ramez. Sistemas de Bases de Datos. Editorial Addison –Wesley Iberoamericana S-A.

Segunda Edición, 1997.

I.C. Silvia Eloisa Carlín Salgado y M.Sc. Rosendo Moreno Rodríguez - Valorización de las bases de

datos deductivas y de las bases de datos activas

http://gpd.sip.ucm.es/ Rafael Caballero Roldán. Introducción a las bases de datos deductivas

P. Julián Iranzo. Apuntes de Programación Declarativa, 2002

http://sistemas.itlp.edu.mx/revistadsyc Marco Antonio Castro Liera - Bases de Datos Relacionales

Difusas

Grosky, William I. “Managing Multimedia Information in Database Systems”, University of Detroit,

1997

Connolly T., Begg C., “Sistemas de b ases de datos - Un enfoque practica para diseño,

implementación y gestión”. Ed PearsonAddison-Wesley.

http://tejo.usal.es/~fgarcia/docencia/poo/02-03/trabajos/S1T3.pdf

http://kybele.escet.urjc.es/documentos/BD/T3-ModeloOR.pdf

http://informatica.uv.es/iiguia/DBD/Practicas/boletin_1.pdf

http://informatica.uv.es/iiguia/DBD/Teoria/capitulo_4.pdf

http://gpd.sip.ucm.es/

http://sistemas.itlp.edu.mx/revistadsyc





Rob P., Coronel C., “Sistemas de bases de datos - Diseño Implementacion y Administracion”. Ed.

Thomson.

Atzeni P.,Stefano C., “Database Systems - Concepts, Languages and Architectures”. Ed. McGraw

Hill.

Introducción a la Documática http://tramullas.com/documatica/indice.html, Jesús Tramullas y

Kronos © 1997, 2000.

http://es.wikipedia.org/wiki/Common_Gateway_Interface.html

http://es.wikipedia.org/wiki/AJAX

http://es.wikipedia.org/wiki/P%C3%A1gina_web

http://es.wikipedia.org/wiki/Contenido_din%C3%A1mico

http://www.iec.csic.es/criptonomicon/bd/

http://msdn2.microsoft.com/es-es/library/ms178371(VS.80).aspx

“Tecnología y Diseño de Bases de Datos”, PIATTINI VELTHUIS, MARIO G / MARCOS MARTINEZ,

ESPERANZA / CALERO MUÑOZ, CORAL / VELA SÁNCHEZ, BELÉN

“Sistemas de Bases de Datos. Un enfoque práctico para diseño, implementación y gestión”,

THOMAS M. CONNOLLY/ CAROLYN E. BEGG

Oracle9i Data Warehousing Guide Release 2 (9.2):

http://www.mpiinf.mpg.de/departments/d5/teaching/ss05/is05/oracle/server.920/a96520/toc.ht

m

http://es.geocities.com/lenguajesde_recuperacion/xquery.htm

http://www.rhernando.net/modules/tutorials/doc/bd/dw.html

http://es.wikipedia.org/wiki/Almac%C3%A9n_de_datos

http://usuarios.lycos.es/jrodr35/

http://html.rincondelvago.com/bases-de-datos-distribuidas_1.html

http://sacbeob.8m.com/tutoriales/bddistribuidas/index.htm

http://www.cs.cinvestav.mx/SC/prof_personal/adiaz/Disdb/Cap_1.html

http://es.wikipedia.org/wiki/Common_Gateway_Interface.html

http://es.wikipedia.org/wiki/AJAX

http://es.wikipedia.org/wiki/P%C3%A1gina_web

http://es.wikipedia.org/wiki/Contenido_din%C3%A1mico

http://www.iec.csic.es/criptonomicon/bd/

http://msdn2.microsoft.com/es-es/library/ms178371(VS.80).aspx

http://www.mpiinf.mpg.de/departments/d5/teaching/ss05/is05/oracle/server.920/a96520/toc.htm

http://www.mpiinf.mpg.de/departments/d5/teaching/ss05/is05/oracle/server.920/a96520/toc.htm

http://es.geocities.com/lenguajesde_recuperacion/xquery.htm

http://www.rhernando.net/modules/tutorials/doc/bd/dw.html

http://es.wikipedia.org/wiki/Almac%C3%A9n_de_datos

http://usuarios.lycos.es/jrodr35/

http://html.rincondelvago.com/bases-de-datos-distribuidas_1.html

http://sacbeob.8m.com/tutoriales/bddistribuidas/index.htm

http://www.cs.cinvestav.mx/SC/prof_personal/adiaz/Disdb/Cap_1.html





http://es.wikipedia.org/wiki/Grid_computing

http://www.catedravodafone.etsit.upm.es/formacion/seminarios/grid.html

http://seti.astroseti.org/setiathome/que.php

http://ciencia.astroseti.org/planetary/articulo.php?num=320

http://es.wikipedia.org/wiki/Computaci%C3%B3n_distribuida#Grid

http://websearch.internet2.edu/query.html?Search.x=0&Search.y=0&qt=middleware&col=i2sites

&charset=iso-8859-1

http://wiki.dbgrid.org/index.php

http://www.gridpp.ac.uk/papers/DAISStatementSpec.pdf

SilBerschatz, Kort, Sudarshan Fundamentos de Base de Datos (4º y 5º Edición), España, Mc Graw

Hill, 2002 y 2007.

http://www.ayi-asociados.com/presentaciones/Grid_cast-B&N.pdf

(http://www.fdi.ucm.es/profesor/rubensm/Doctorado/Introduccion%20a%20la%20Seguridad%20

en%20un%20GRID.pdf)

http://www.gae.unican.es/Top/Presentaciones/SC06/SemanadelaCiencia_UNICAN_v1.ppt

http://indico.ifca.es/indico/getFile.py/access?contribId=9&resId=1&materialId=slides&confId=75

http://www.error500.net/garbagecollector/archives/categorias/bases_de_datos/sistema_gestor_

de_base_de_datos_sgbd.php

http://psicosix.iespana.es/bd2/trabajo01.pdf

http://eu-datagrid.web.cern.ch/eu-datagrid/

DATABASES AND THE GRID. Watson, P. University of Newcastle [2001] WHAT IS THE GRID? A

THREE POINT CHECKLIST. Foster, I., University of Chicago [2002]

ORACLE DATABASE 10G: THE DATABASE FOR THE GRID. An Oracle White Paper.Oracle [2003]

http://es.wikipedia.org/wiki/Grid_computing

http://www.catedravodafone.etsit.upm.es/formacion/seminarios/grid.html

http://seti.astroseti.org/setiathome/que.php

http://ciencia.astroseti.org/planetary/articulo.php?num=320

http://es.wikipedia.org/wiki/Computaci%C3%B3n_distribuida#Grid

http://websearch.internet2.edu/query.html?Search.x=0&Search.y=0&qt=middleware&col=i2sites&charset=iso-8859-1

http://websearch.internet2.edu/query.html?Search.x=0&Search.y=0&qt=middleware&col=i2sites&charset=iso-8859-1

http://wiki.dbgrid.org/index.php

http://www.gridpp.ac.uk/papers/DAISStatementSpec.pdf

http://www.ayi-asociados.com/presentaciones/Grid_cast-B&N.pdf

http://www.fdi.ucm.es/profesor/rubensm/Doctorado/Introduccion%20a%20la%20Seguridad%20en%20un%20GRID.pdf

http://www.fdi.ucm.es/profesor/rubensm/Doctorado/Introduccion%20a%20la%20Seguridad%20en%20un%20GRID.pdf

http://www.gae.unican.es/Top/Presentaciones/SC06/SemanadelaCiencia_UNICAN_v1.ppt

http://indico.ifca.es/indico/getFile.py/access?contribId=9&resId=1&materialId=slides&confId=75

http://www.error500.net/garbagecollector/archives/categorias/bases_de_datos/sistema_gestor_de_base_de_datos_sgbd.php

http://www.error500.net/garbagecollector/archives/categorias/bases_de_datos/sistema_gestor_de_base_de_datos_sgbd.php

http://psicosix.iespana.es/bd2/trabajo01.pdf

http://eu-datagrid.web.cern.ch/eu-datagrid/

Bases_de_Datos_II.pdf

Documents

Transcript of Bases_de_Datos_II.pdf