Bases de Datos Unidad 4

UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO

FACULTAD DE CONTADURÍA Y ADMINISTRACIÓN

Licenciatura En Informática

Bases de Datos

Autor: L.I. María de Lourdes Isabel Ponce Vásquez

AGOSTO - DICIEMBRE 2008

Contenido

UNIDAD 4. MODELO ORIENTADO A OBJETOS................................................................................................3 Objetivos Específicos ....................................................................................................................... 3 4.1. Introducción .............................................................................................................................. 3

4.1.1. Retos Actuales de los DBMSs ............................................................................................ 3 4.1.2. Tendencias Actuales en la Tecnología de BD .................................................................... 4

4.1.1.1. Rendimiento.................................................................................................................54.1.1.2. Distribución/Integración................................................................................................54.1.1.3. Funcionalidad/Inteligencia............................................................................................5

4.1.3. Orientación a Objetos ......................................................................................................... 5 4.1.1.4. Principios Fundamentales de la POO...........................................................................64.1.1.5. Modularidad.................................................................................................................64.1.1.6. Abstracción..................................................................................................................74.1.1.7. Objetos.........................................................................................................................74.1.1.8. Clases..........................................................................................................................84.1.1.9. Encapsulamiento..........................................................................................................84.1.1.10. Interrelaciones............................................................................................................84.1.1.11. Polimorfismo...............................................................................................................9

4.1.4. Persistencia ........................................................................................................................ 9 4.2. Sistemas de Administración de BDOO .................................................................................... 10

4.2.1. Antecedentes ................................................................................................................... 10 4.2.2. Primera Generación ......................................................................................................... 10 4.2.3. Segunda Generación ....................................................................................................... 11 4.2.4. Tercera Generación ......................................................................................................... 12 4.2.5. Definición ......................................................................................................................... 12 4.2.6. Características ................................................................................................................. 13

4.1.1.12. Persistencia..............................................................................................................134.1.1.13. Modelo de objetos....................................................................................................144.1.1.14. Lenguaje de Datos...................................................................................................144.1.1.15. Arquitectura de tres niveles......................................................................................144.1.1.16. Optimizador..............................................................................................................144.1.1.17. Seguridad.................................................................................................................144.1.1.18. Interfaces para Programas de Aplicación (API)........................................................14Diccionarios de datos..............................................................................................................154.1.1.19. Herramientas para desarrollo de aplicaciones..........................................................154.1.1.20. Herramientas para la transformación de datos.........................................................154.1.1.21. Utilidades para mantenimiento y mejora del rendimiento de la BD...........................154.1.1.22. Soporte de datos multimedia....................................................................................154.1.1.23. Herramientas y Facilidades de Usuario....................................................................154.1.1.24. Distribución...............................................................................................................154.1.1.25. Control de versiones y configuraciones....................................................................16

4.3. Estándar ODMG ..................................................................................................................... 16 4.3.1. Ejemplos .......................................................................................................................... 17

Unidad 4. Modelo Orientado a Objetos Página 2

UNIDAD 4. MODELO ORIENTADO A OBJETOSUNIDAD 4. MODELO ORIENTADO A OBJETOS

Objetivos Específicos

Describir los retos y tendencias actuales de los DBMS Comprender el paradigma orientado a objetos Conocer los orígenes de las bases de datos orientadas a objetos Definir y describir las características del modelo orientado a objetos Describir y comprender el estándar ODMG

4.1. Introducción

En la unidad anterior se revisó el modelo relacional para almacenar los datos en una base de datos, en esta unidad se revisará el modelo orientado a objetos y el modelo objeto relacional que ha ganado terreno en el entorno de bases de datos.

Como se mencionó, los OODBMS (Administradores de Bases de Datos Orientadas a Objetos) surgieron por la falta de capacidad semántica del modelo relacional para soportar aplicaciones complejas, como CAD/CAM, CASE, sistemas basados en conocimiento, tratamiento de documentos, multimedia y gestión de redes, etc., que necesitan modelación directa de objetos e interrelaciones complejas, el almacenamiento de información no estructurada, gestión de diversos tipos de transacciones, control exhaustivo de componentes y estructuras, además de manejar diversas versiones y configuraciones.

Los OODBMS eliminan las barreras entre los datos y procesos encapsulando datos y las operaciones sobre ellos. Esta tendencia ya aparecía en versiones de productos relacionales que permiten desde los 90s, almacenar disparadores (triggers), reglas (restricciones) y procedimientos almacenados.

Otra ventaja de los OODBMS es la reducción de la distancia en el desarrollo entre el modelo conceptual (E/R ó UML) y el modelo lógico, ya que el paradigma de la orientación a objetos (PaOO) proporciona un único modelo implementado en el OODBMS, al que acceden directamente las aplicaciones.

4.1.1. Retos Actuales de los DBMSs

La última generación de BD ha demostrado que aún no se pueden resolver todos los problemas de almacenamiento que teóricamente debían resolverse con el uso de las BD, algunos de estos problemas son:

Los DBMS actuales son monolíticos; ofrecen todo tipo de servicios y funcionalidades en un solo paquete, sin considerar las necesidades específicas de los usuarios, esto provoca un alto costo y pérdida de eficiencia.

A la fecha siguen existiendo más datos en hojas de cálculo que en DBMSs por la facilidad y simpleza que estos sistemas ofrecen en comparación con los DBMSs.

Se cree que cerca del 50% de los datos de producción se encuentran todavía en sistemas heredados (sin DBMSs) sin poder llevar toda la información a un DBMS.


Los sistemas de gestión de flujos de trabajo (workflow) y muchos otros no están basados en tecnología de BD, simplemente acceden a la BD a través de Interfaces de Programas de Aplicación (APIs).

Los servicios de replicación están limitados por lo que no se extienden a más de 10,000 nodos.

Es difícil combinar datos estructurados y no estructurados en una BD (por ejemplo provenientes de correos electrónicos).

Las BD son el núcleo de los SI y por tanto se ven influenciadas por los cambios que sufren las empresas, por lo que deben ofrecer a las organizaciones flexibilidad, tiempos bajos de respuesta, robustez, extensibilidad, gestión de la incertidumbre, etc. La integración de datos estructurados y no estructurados es muy importante y los DBMS deben ofrecer este servicio. La globalización y competitividad internacional influyen en la tecnología, la cual debe proporcionar conectividad entre las BD distribuidas geográficamente, siendo capaces de integrar rápidamente BD separadas (protocolos, distribución de datos, federaciones, etc.) y ofrecer disponibilidad 100% (las 24 horas del día durante los 365 días del año). Los nuevos productos de BD deben ayudar al usuario a la localización de los datos distribuidos y a la conexión de las aplicaciones en las PC con las BD locales y remotas.

4.1.2. Tendencias Actuales en la Tecnología de BD

Los avances en hardware tienen gran impacto en el desarrollo actual de las BD. La reducción de precio de RAM y disco han proporcionado equipos con más potencia a precios más bajos. Este factor ha afectado algunos algoritmos de los DBMS, permitiendo que grandes volúmenes de datos sean almacenados RAM. También, la arquitectura paralela (Multiprocesadores Simétricos – SMP - Symmetryc Multi-Processing y Procesadores Masivamente Paralelos – MPP Massively Parallel Processing) ofrece la posibilidad de ejecutar los DBMS en varios procesadores.

Otras tecnologías que también están influyendo a los cambios son: técnicas de compresión/descompresión, digitalizadores de audio y video, medios de almacenamiento óptico, discos magnéticos, medios de almacenamiento jerárquico, etc.

Las computadoras asistentes personales, PDA (Personal Digital Assistant), palmtops, laptops, etc., permiten acceder a la información en cualquier sitio y momento. Eso plantea problemas de conectividad y afecta la distribución de las BD.

El modelo C/S con la introducción de la arquitectura de dos capas se ha transformado con los monitores Middleware y TP (Procesamiento de Transacciones – Transaction Processing).

Las redes de alta velocidad (Ethernet rápida, AnyLan, FDDI – Interfaz de Datos Distribuidos en Fibra, DQDB – Bus Dual de Colas Distribuidas-, Frame Relay, etc.) han cambiado también la capa de comunicación donde se sitúan las BD.

Recientemente, la aparición de la tecnología GRID, que pretende conectar computadoras con el fin de proporcionar una potencia de cálculo mayor y usar los ciclos de procesador desperdiciados, también plantea interesantes desafíos de metadatos, seguridad, interoperabilidad, rendimiento, etc. a las BD.

Las DB han evolucionado en tres aspectos: rendimiento, distribución/integración y funcionalidad.


4.1.1.1. Rendimiento

Las BDs han evolucionado implementando BD paralelas con memoria compartidas, disco compartido o nada compartido, explotando tanto el paralelismo en las inter-consultas, que realizan diversas consultas en varios procesadores independientemente; como en la intra-consulta, que realizan fragmentos de una misma consulta en diferentes procesadores. Y en estos últimos años han aparecido BD que explotan las ventajas del gris.

En aplicaciones de respuesta crítica el rendimiento se mejora fijando prioridad para las transacciones en tiempo real.

También para mejorar el rendimiento, las BD en memoria principal cambian algunos conceptos de estructuras de índices, agrupaciones, bloqueos, transacciones, etc.

4.1.1.2. Distribución/Integración

La distribución de BD se ha ampliado a BD Móviles que son sistemas distribuidos en los que los enlaces entre los nodos cambian dinámicamente.

Se ha ampliado la integración en Internet. La Web agrega nuevos componentes incluyendo las IGUs, un nuevo modelo C/S (protocolo http) y un mecanismo de hiperenlace entre BD.

4.1.1.3. Funcionalidad/Inteligencia

En este punto, cada vez más, la semántica y funcionalidad se ha migrado a los DD, almacenándose junto con los datos, de modo que se libere a las aplicaciones de comprobar restricciones de integridad y duplicándose en todos los programas, y convirtiéndose en BD semánticas. A principios de los 90 aparecieron las bases de datos activas, donde la descripción de los datos y las restricciones, se almacenan en la BD y pueden ejecutar aplicaciones sin la intervención del usuario soportando disparadores, reglas, alertas, demonios, etc.

Las OODB y ORDD permiten la definición y gestión de los objetos, donde los objetos pueden ser de cualquier tipo: imágenes, audio, video, etc. (BD multimedia) o datos geográficos (BD espaciales).

Recientemente han aparecido las BD semiestructuradas, adecuadas para gestión de documentos XML, que aportan un nuevo modelo de datos.

4.1.3. Orientación a Objetos

La Orientación a Objetos se puede definir como "una disciplina de ingeniería de desarrollo y modelado de software que permite construir más fácilmente sistemas complejos a partir de componentes individuales".

La Orientación a Objetos permite una representación más directa del mundo real, reduciendo fuertemente la transformación radical normal desde los requerimientos del sistema, definidos en términos del usuario, a las especificaciones del sistema, definidas en términos de la computadora. En vez de tratar de modelar un problema en algo familiar a la computadora se trata de acercar la computadora al problema, es decir, modelar el problema mediante entidades independientes que


interactúan y cuyas fronteras no están determinadas por su instrumentación computacional sino por la naturaleza del problema.

4.1.1.4. Principios Fundamentales de la POO

Algunos autores centran los principios fundamentales que configuran el paradigma orientado a objetos, en tres características:

Abstracción Herencia Identidad de los Objetos

Otros más estiman que la OO se basa sólo en: Herencia Encapsulamiento o encapsulación Polimorfismo

Mientras que otros señalan siete u ocho de los siguientes aspectos como básicos a considerar para una verdadera orientación al objeto:

Modularidad Abstracción Objetos Clases Encapsulamiento Herencia Polimorfismo y enlace dinámico Persistencia

4.1.1.5. Modularidad

La modularidad consiste en dividir un programa en partes llamadas módulos, los cuales pueden trabajarse por separado. En términos de programación, los módulos pueden compilarse por separado y la división no depende de cierto número de líneas sino es una división en términos de integrar en un módulo un conjunto de procedimientos relacionados entre sí, junto con los datos que son manipulados por tales procedimientos.

El objetivo de la modularidad es reducir el costo de elaboración de programas al poder dividir el trabajo entre varios programadores y aumentar la productividad.

Por ejemplo, un automóvil está constituido por un conjunto de módulos tales como un sistema eléctrico, uno mecánico y uno de frenado. Cada módulo se trabaja por separado y el especialista sólo conoce la forma en que se relaciona el módulo con los otros, pero no tiene por qué saber los detalles de funcionamiento de otros módulos o sistema.

Estos conceptos no son exclusivos de la OO, pues se han desarrollado desde la programación estructurada, sólo que en ésta se pueden omitir (desde luego bajo responsabilidad del programador), pues hacerlo, lleva a tener grandes programas en un solo archivo y sin estructura alguna, lo cual causa grandes pérdidas de tiempo al desear modificar tal programa.


La OO no puede lograrse sin hacer uso de los mecanismos antes mencionados y para ello, proporciona los medios para ir creando módulos llamados clases. En las clases, cada tipo no simple es un módulo, y cada módulo de alto nivel es un tipo.

4.1.1.6. Abstracción

La abstracción es una descripción o especificación simplificada de un sistema que hace énfasis en algunos detalles significativos y suprime los irrelevantes.

La abstracción es esencial para construir cualquier sistema, sea o no orientado a objetos y debe enfocarse más en qué es un objeto y qué hace, antes de pensar en la implementación.

Por ejemplo, un automóvil puede abstraerse como un objeto que sirve para desplazarse a mayor velocidad, sin importar cómo lo haga.

Una característica de la abstracción es que un objeto puede abstraerse de diversas formas, dependiendo del observador. Así, el automóvil que se mencionaba puede ser visto como un objeto de colección por un coleccionista, una herramienta de trabajo por un corredor profesional, una mercancía por un vendedor, etc.

4.1.1.7. Objetos

A pesar de que el punto central en esta nueva metodología de programación es el concepto de objeto. En términos de programación, un objeto es: “un concepto, abstracción o cosa con límites bien definidos y significado para una aplicación”. Lo que sí puede decirse de todo objeto es que tiene estado, comportamiento e identidad.

El estado de un objeto abarca todas las propiedades o características distintivas del mismo y los valores de cada una de estas propiedades. En términos de programación, puede decirse que las propiedades son las variables que sirven para describir tal objeto.

El comportamiento es la forma como actúa o reacciona un objeto en términos de cambio de estado, envío y recepción de mensajes. Está formado por la definición de las operaciones (funciones y procedimientos) que puede realizar este objeto. Los tipos más comunes de operaciones, o en POO métodos, son: modificar, seleccionar, iterar, construir y destruir. El conjunto de operaciones que un objeto puede realizar sobre otro, se conoce como protocolo.

Identidad (OID – object identifier) es la propiedad de un objeto que lo distingue de todos los demás. Un objeto conserva su identidad aún cuando algunos o todos los valores de los atributos o las definiciones de los métodos cambien con el tiempo, este concepto de identidad no se aplica a las tuplas de una BD relacional, en estos sistemas, las tuplas se distinguen por los valores que contienen.

La identidad de un objeto es una noción más fuere que la que se encuentra normalmente en los lenguajes de programación o en los modelos de datos no OO. Algunas formas de identidad son:

Valor. Se usa un valor de dato por identidad. Esta es la forma usada en los sistemas relacionales.

Nombre. Se usa un nombre dado por el usuario. Esta es la forma usada en los lenguajes de programación para identificar a cada variable dentro de un programa.


Incorporación. Se incorpora en el modelo de datos el lenguaje de programación y no se requiere que el usuario proporcione algún identificador. Esta es la forma que se usa en las BD orientadas a objetos.

Por ejemplo, un automóvil puede tener diversos estados, puede estar estacionado o en circulación. Un comportamiento asociado con el auto pueden incluir encenderlo, lo cual modifica su estado, y generalmente tiene una identidad marca, modelo, número de serie del motor y placa.

4.1.1.8. Clases

Una clase es un módulo y un tipo de datos abstracto que define un grupo de objetos que comparten características comunes.

Por ejemplo, se puede hablar de autos como una clase y mencionar propiedades compartidas tales como los asientos o parabrisas, pero también se pueden emplear los valores de los atributos para distinguir a un miembro de la clase de otro (un auto de carreras corre a una mayor velocidad). Así, una clase describe un conjunto de objetos que comparten una estructura común y tienen comportamientos comunes, pero los valores de los atributos permiten distinguir a unos de los otros.

4.1.1.9. Encapsulamiento

El encapsulamiento es una técnica para empaquetar la información, envolviendo los atributos y métodos de los objetos en clases, de tal forma que se oculte lo que debe ocultarse y haga visible lo que está pensado para serlo.

Con esto se trata de lograr que al tener algún cambio en la implementación de un objeto no se tengan que modificar los programas que utilizan tal objeto.

Siguiendo con el ejemplo del automóvil, se sabe que existen diversos mecanismos para que funcione éste, en particular se tiene el sistema de frenado que todo mundo sabe que sirve para detener el auto al pisar el pedal de freno, pero sólo el mecánico sabe los detalles de la implementación. Por otro lado, si en algún momento se cambia, para el conductor es transparente.

4.1.1.10. Interrelaciones

La herencia que es la una relación entre clases donde las características y el comportamiento general de una superclase puede compartirse con sus subclases, permite que una clase sea definida como una extensión o restricción de otra y es la contribución más importante de la POO, pues mediante este mecanismo es posible lograr la principal meta de la OO que es la reutilización de código.

La herencia permite definir una jerarquía de clases. En tal jerarquía, algunas clases son subordinadas a otras llamadas subclases.

Una subclase define el comportamiento de un conjunto de objetos que heredan algunas de las características de la clase padre, pero adquieren características especiales no compartidas por el padre, en este sentido se dice que la subclase es una especialización de la clase padre.


La herencia múltiple y repetida permite que se pueda declarar una clase como heredera de varias, e incluso de ella misma.

La herencia simple permite heredar sólo de una clase padre. En estos casos, se implementan las llamadas interfaces que permiten simular la herencia múltiple.

Otro tipo de interrelación muy importante en este modelo es la agregación, que permite construir objetos complejos o compuestos a partir de otros, correspondiendo a la noción “parte-de” ó “tiene un”. Por ejemplo un auto tiene un motor.

La genericidad es otra forma de interrelación que es la capacidad de definir clases parametrizadas (genéricos), creando una plantilla que permite construir tipos. Por ejemplo, se puede definir un vector de elementos de tipo “X”, siendo “X” el parámetro formal que se sustituye por el parámetro real cuando se requiere construir el tipo concreto, por ejemplo un vector de números enteros, de personas, de vectores, etc.

4.1.1.11. Polimorfismo

El polimorfismo es la capacidad de tener métodos con el mismo nombre pero con una implementación diferente o que un método sea aplicable a diferentes tipos de argumento.

Por ejemplo, al tratar de frenar un auto siempre se debe oprimir el pedal del freno y el vehículo se detendrá sin importar si los frenos son de tambor o de disco.

Una implementación específica de un comportamiento para una cierta clase se denomina método. En un sistema polimórfico, un comportamiento puede tener más de un método que lo implemente. Por ejemplo, existirá un método frenar cuando se trata de frenos de disco y otro cuando son de tambor pero el método sigue siendo frenar.

Las dos principales formas de polimorfismo son:

Sobrecarga. Se utiliza el mismo nombre para diferentes servicios, que se distinguen por la cantidad y tipos de parámetros, éstos no requieren herencia.

Sobrescritura. Cuando una subclase redefine un servicio manteniendo el mismo nombre.

Un lenguaje de programación OO se diseña para seleccionar automáticamente el método correcto para implementar la operación, a partir de los datos asociados con la operación como parámetros, y el nombre de la clase de objeto, esto es llamado enlace dinámico (dinamic binding). El enlace dinámico, permite que las entidades del programa puedan referenciar en tiempo de ejecución a objetos de diferentes clases y está íntimamente relacionado con el concepto de herencia. En el ejemplo del frenado, el objeto seleccionará el método de frenado apropiado, basado en los parámetros que describen el tipo de frenos.

4.1.4. Persistencia

La última propiedad asociada con sistemas OO es la persistencia, que es la capacidad del nombre, estado y comportamiento de un objeto para trascender el espacio o el tiempo. En otras palabras, el nombre, estado y comportamiento de un objeto se pueden conservar aún cuando el objeto es transformado o destruido.


Una vez almacenado en memoria secundaria, se puede reconstruir para usarlo durante la ejecución (materialización del objeto).

Por ejemplo, se puede desear guardar información del mantenimiento de un auto, para poder comparar los ajustes y modificaciones que se le han realizado. En este caso, el objeto persiste aun cuando sus atributos se transformen.

4.2. Sistemas de Administración de BDOO

4.2.1. Antecedentes

La historia de las BD se extiende desde mediados de los 60s y se ha caracterizado por su excepcional productividad e impresionante impacto económico. A continuación se muestra un resumen de las últimas décadas de evolución.

4.2.2. Primera Generación

Desde que empezaron a usarse las computadoras para automatizar la administración de las empresas, la evolución de los sistemas de información ha tenido impacto en la gestión de los datos, al exigir cada vez más prestaciones de la información almacenada en los sistemas. Gradualmente, el enfoque de la informática, inicialmente concentrado en el proceso donde los datos se almacenaban en archivos específicos para cada aplicación, se fue desplazando hacia sistemas orientados a los datos, en los que los datos se almacenan en BD y representan un papel fundamental para los ingenieros de sw. Actualmente, muchos de los problemas del diseño de los sistemas de información se centran en el modelo y estructuración de los datos.

Tras los complejos sistemas de archivos de las primeras etapas de la informática, en las décadas 60 y 70 nació la primera generación de productos de BD. Los primeros DBMS que se basaron en los modelos jerárquicos y en red, proporcionaban una organización lógica de los datos en árboles y grafos. Si bien eran sistemas bastante eficientes, este tipo de productos usaba lenguajes procedimentales, no poseían la suficiente independencia físico/lógica y su flexibilidad era muy limitada. Sin embargo, lograron varios avances comparados con los sistemas de archivos.

La incorporación a los DBMS de facilidades de comunicación de los datos con IMS de IBM, dio lugar al primer sistema BD/DC (Data Base/Data Communication) a gran escala, en el que muchos usuarios accedían a la BD a través de una red de comunicación. Desde entonces, los DBMS comerciales ofrecen acceso a BDs en red, siendo esta la forma habitual de uso de BD.

Bachean fue pionero en el desarrollo de los sistemas de BD en red. En su artículo “El Programador como Navegador”, describe el proceso de navegar a través de una BD, en el que el programador tiene que seguir un camino explícito, registro a registro, en la búsqueda de un conjunto de datos. En sus especificaciones de 1978, Codasyl propuso un Lenguaje de Definición de Datos (DDL) en tres niveles (Schema DDL, Subesquema DDL e Internal DDL) y una normativa para poder manipular los datos en el DML de tipo procedimental.

Los enlaces jerárquicos y los conjuntos Codasyl se implementaron físicamente mediante apuntadores. Esta implementación, junto a las restricciones funcionales de estos enlaces y conjuntos, son las causas de los puntos débiles de los sistemas basados en estos modelos (poca


flexibilidad en las estructuras físicas, dependencia datos/aplicaciones, y complejidad de los lenguajes de navegación). Sin embargo, estos mismos apuntadores son precisamente la razón de su eficiencia, uno de los puntos fuertes de este tipo de productos. Esta generación está orientada principalmente al procesamiento por lotes.

4.2.3. Segunda Generación

Los productos relacionales se consideran la segunda generación de BD; productos como Oracle, DB2, etc., proporcionan mayor independencia física/lógica, mayor flexibilidad y lenguajes de consulta declarativos, en los que los usuarios indican qué quieren obtener sin describir cómo hacerlo. Con los RDBMSs, las organizaciones también tienen más facilidad para distribuir sus datos. Además los RDBMSs proporcionan una base teórica más sólida. A diferencia de los modelos anteriores, el modelo relacional está orientado a valores y no soportan la identidad de los objetos.

A finales de los 70 y durante los 80s, los trabajos se centraron en la optimización de las consultas, lenguajes de alto nivel, teoría de la normalización, organizaciones físicas para el almacenamiento de las relaciones, algoritmos para la gestión de memorias intermedias (buffers), técnicas de indexación (variaciones de los árboles B), sistemas distribuidos, dd, gestión de transacciones, etc. Estas investigaciones tuvieron como consecuencia un aumento de la eficiencia y la seguridad de los entornos transaccionales en línea (OLTP); tema fundamental en la 2ª generación de BD.

En los 80s se estandarizó SQL, con la mayoría de los productos ofreciendo una interfaz SQL, aún los no relacionales.

Muchos avances en la tecnología de BD se basaron en dos elementos base: la arquitectura y los modelos de datos. Respecto a la arquitectura, las propuestas de ISO y ANSI sobre los modelos de referencia, influyeron positivamente no sólo en las investigaciones teóricas, sino también en las aplicaciones prácticas. En la mayoría de los modelos de referencia se pueden encontrar dos conceptos principales: la arquitectura de tres niveles (externo, lógico e interno), también propuesta por Codasyl en el 78, y la descripción recursiva de los datos. La separación entre la apariencia lógica de los datos y su implementación física ha sido siempre un objetivo importante en la evolución de las BD, y la arquitectura de tres niveles, junto con el modelo relacional, ha sido uno de los principales avances en este sentido.

En cuanto a los modelos de datos, el modelo relacional fue el que marco las líneas de investigación en las décadas de los 70 y 80, siendo soportado por la mayoría de los productos actuales. En los 90 surgieron otros DBMS basados principalmente en modelos de objetos. En los últimos años, con el auge del lenguaje XML, los DBMS están soportando la gestión de este tipo de información con modelos XML puros o implantándolos como una capa sobre el modelo relacional.

Pueden citarse tres factores clave en la evolución de las BD: los fundamentos teóricos, los productos y las aplicaciones prácticas. Estos factores han estado siempre presentes a lo largo de la historia de las BDs, pero el equilibrio entre ellos ha cambiado. Las BDs empezaron en los 60 como un producto tecnológico demandado por las necesidades de los usuarios, y pasaron a convertirse durante los 70 y 80s en una gran industria y un mercado importante. Aunque las necesidades de los usuarios han influido en esta evolución, fue hasta los 90 que la tecnología ha sido guiada por las demandas de los usuarios.

En los últimos años la tecnología de BD ha obtenido grandes avances, temas que parecían al principio exclusivos de laboratorios y centros de investigación, han aparecido en las últimas versiones comerciales: multimedia, orientación a objetos, seguridad, temporalidad (incorporan el tiempo), paralelismo, BD multidimensionales, semiestructuradas, gril, etc.


4.2.4. Tercera Generación

Muchas aplicaciones no tradicionales no usaban tecnología de BD por que sus necesidades especiales. Los DBMS han puesto atención a estas aplicaciones para proporcionar respuestas a estas necesidades, por lo que casi todos los proveedores comenzaron a incorporar nuevas funcionalidades a sus productos para proporcionar soluciones a estos problemas. Al mismo tiempo, los avances en hw y sw y los cambios en la organización de las empresas también obligaron el nacimiento de una nueva generación de BD.

Esta generación se caracteriza por “proporcionar capacidades de gestión de datos igual que las anteriores, permitiendo que grandes cantidades de datos persistentes sean compartidos por muchos usuarios. También proporcionan gestión de objetos, permitiendo tipos de datos mucho 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 también para mantener las restricciones de integridad entre datos”.

4.2.5. Definición

Existen dos enfoques principales de implementación de BD de objetos. El primero, extiende los RDBMS para que soporten los conceptos de orientación a objetos creando las BD Objeto-Relacionales. Por otro lado, están las BD Orientadas a Objetos que soportan un modelo de objetos puro y no son extensiones de otros modelos, como O2, Objectivity, ObjectStore, Ontos, Itasca, Versant, Jasmine, Fast Objects, etc.

Las BD Objeto-Relacionales tienen una serie de reglas descritas en el “Manifiesto de los Sistemas de BD de Tercera Generación” de Stonebraker (1990), y son cumplidas por la mayoría de los proveedores relacionales actuales:

1er. Principio: “Además de los servicios tradicionales de gestión de datos, los DBMS de tercera generación proporcionarán gestión de objetos y reglas más amplio”:o Un DBMS debe tener un sistema de tipos amplio.o Debe manejar herencia.o Debe permitir definir métodos y encapsulamiento.o Debería asignar OID para las tuplas sólo si no está disponible una llave primaria.

2º. Principio: “Los DBMS de tercera generación deben incluir a los DBMS de segunda generación”:o Deben tener un lenguaje de acceso declarativo y de alto nivel.o Deben existir dos formas de especificar las colecciones: por enumeración de

miembros o mediante un lenguaje de consultas.o Las vistas deben ser actualizables.o Los indicadores de resultado no deben aparecer en los datos.

3er. Principio: “Los DBMS de tercera generación deben ser abiertos a otros subsistemas”:o Debe ser accesible desde múltiples lenguajes de alto nivel.o Deben soportar persistencia de variables.o SQL debe ampliarse para la expresión de datos.o Las consultas y sus respuestas deben ser el nivel más bajo de comunicación C/S.


Por su parte, las BD Orientadas a Objetos son más completas y describen sus características en el “Manifiesto de Sistemas de BD Orientadas a Objetos” de Atkinson (1989), estas reglas se cumplen por los OODBMS y se refieren al soporte de:

Objetos complejosIdentidad del objetoEncapsulamientoTipos y clasesJerarquías de tipos o clasesPolimorfismo, sobrecarga y enlace dinámicoCompleción de cálculosExtensibilidadPersistenciaGestión del almacenamiento secundarioConcurrenciaRecuperaciónFacilidad de consulta

Junto con cinco características opcionales que serían convenientes presentar:

Herencia múltipleVerificación de inferencia del tipoDistribuciónTransacciones de diseñoVersiones

Este manifiesto fue el primero que se elaboró, se presentó como una propuesta ante la falta de acuerdos en las características de los OODBMS y, por ello, los autores aconsejan “cuestionar las reglas”.

4.2.6. Características

Las características de estos sistemas provienen de la unión de BD y OO. Las características que indica el ANSI (1990b) son consideradas como modelo de referencia abstracto, y que, no indica una especificación implementable, sino una exposición general y un punto de comparación.

4.1.1.12. Persistencia

En los OODBMS los objetos son permanentes almacenados en la BD hasta borrarlos de modo explícito, a diferencia de los objetos en los LP. Existiendo distintas posibilidades:

Todos los objetos son persistentes.La persistencia es una propiedad del tipo de objeto, generalmente definida como subtipos

de un tipo persistente.El objeto se designa persistente al crearse.Existe alguna operación que hace a un objeto persistente.


4.1.1.13. Modelo de objetos

A diferencia del modelo relacional, el modelo de objetos es más realista, ya que los objetos representan entidades del mundo real dando una sensación mucho mejor del problema que un conjunto de tablas. Además, es más potente, ya que es mucho más flexible y posee características como polimorfismo. Por último, el modelo relacional se basa en el valor, mientras que el modelo de objetos se basa en el principio de identidad.

4.1.1.14. Lenguaje de Datos

Los DBMS tradicionales existe un problema de concordancia entre los lenguajes de datos y anfitriones, este problema se produce por diferencias en el paradigma de programación (Imperativo-Java/ Declarativo-SQL) y de los tipos de datos. Los OODBMS han adoptado extensiones de LOO, tanto para describir, como para manipular datos, esto a llevado a crear lenguajes “estilo SQL”.

El encapsulamiento es difícil de respetar en los OODBMS, considerándose los objetos como “cajas grises” (ni negras, ni blancas).

En ocasiones, el lenguaje de datos se usa junto con el LP, por ejemplo, para la definición de los servicios.

4.1.1.15. Arquitectura de tres niveles

En los OODBMS los esquemas externos (vistas) deben ocultar (o exponer) tanto los atributos como los servicios, sin embargo, la mayoría de los productos no conceden a la arquitectura de tres niveles gran importancia, descuidando sobre todo la definición de vistas.

4.1.1.16. Optimizador

En el caso de los OODBMS, sus lenguajes son navegacionales, por lo que la optimización resulta difícil al ser el programador el que indica los caminos a seguir. A pesar de ello, en general, el rendimiento de un OODBMS puede ser superior cuando se trata de navegar a través de objetos ya cargados en memoria, siempre que se puede convertir fácilmente los IDO de los objetos a posiciones de memoria.

El optimizador estará condicionado a las características que posean los lenguajes del OODBMS, aunque la mayoría poseen optimizadotes rudimentarios, sin estadísticas en el DD que permitan una mejor optimización.

4.1.1.17. Seguridad

Los OODBMS deben proporcionar todos los mecanismos necesarios para asegurar el control de la confidencialidad, integridad y disponibilidad de la base de objetos.

4.1.1.18. Interfaces para Programas de Aplicación (API)


Se deben ofrecer las interfaces necesarias para que programas escritos en distintos lenguajes puedan acceder a los objetos de la base.

No es conveniente que esté estrechamente relacionado a un LP particular, aunque en la realidad, la mayoría están muy unidos a un lenguaje específico, particularmente C++, Smalltalk y Java.

Diccionarios de datos

El OODBMS debe manipular metadatos sobre objetos, clases, jerarquías, colecciones, etc. con lo que se obtiene mayor riqueza semántica que la de los DD relacionales.

4.1.1.19. Herramientas para desarrollo de aplicaciones

Es fundamental que posean distintos tipos de herramientas para desarrollo de aplicaciones, que van desde lenguajes de desarrollo hasta navegadores que permiten una mejor manipulación de las bibliotecas de clases. Esto todavía no se logra al nivel de los RDBMS.

4.1.1.20. Herramientas para la transformación de datos

Deben proporcionar herramientas que permitan transferir datos entre distintos DBMS, pudiéndose volcar datos de un OODBMS a un RDBMS, o viceversa. Este tema es muy activo en este campo.

4.1.1.21. Utilidades para mantenimiento y mejora del rendimiento de la BD

También deben tener utilidades que permitan monitorizar el uso de recursos con el fin de aumentar el rendimiento de los sistemas y realizar ajustes (tunning).

Actualmente, la mayoría ofrecen una capacidad limitada para ajustes de rendimiento parametrizado.

4.1.1.22. Soporte de datos multimedia

Deben soportar distintos tipos de datos, además de los formateados, como texto, imagen, voz, video. En algunos OODBMS estos objetos se almacenan en BLOBs (Binary Large Objects), objetos de almacenamiento masivo, que son colecciones de bits sin estructura interna.

4.1.1.23. Herramientas y Facilidades de Usuario

Deben proporcionar distintas interfaces a los usuarios, según sea la función que desempeñan en cada momento (DBA, Programador, diseñador de clases, usuario final, etc.).

Las IGU también siguen el PaOO, facilitando la interacción del usuario con el sistema.

4.1.1.24. Distribución

Al igual que los RDBMS, cualquier elemento debe poder distribuirse en diferentes equipos de forma transparente. El mayor problema es hacer coexistir los OODBMS y los RDBMS.


4.1.1.25. Control de versiones y configuraciones

El control de versiones es una característica fundamental, debido a su uso en entornos de diseño CAD/CAM y sistemas de información de oficinas, de modo que:

Todos los objetos persistentes tengan versiones y no exista un límite en el número de versiones que puede tener.

Las aplicaciones deben poder acceder a la versión actual de un objeto o a cualquier otra.Debe atenderse en especial a la eficiencia de las versiones actuales.

También es importante agrupar versiones compatibles de diversos objetos y tratarlos como una unidad de más alto nivel.

Existen diversos enfoques para soportar versiones:

En el modelo de datos se incluyen una serie de primitiva que permiten tratar las versiones como componentes fundamentales del propio modelo.

Las versiones no se consideran parte del modelo da datos en sí, pero se proporciona un servicio de gestión de versiones mediante un nivel de software implementado sobre el modelo básico.

Se considera la versión como una cuestión de las aplicaciones.

4.3. Estándar ODMG

En verano de 1991 Rick Cattell, de SunSoft, reunió a un grupo de expertos que trabajaban en distintas empresas de OODBMS, y les propuso elaborar un estándar “de facto”, basado en las características que presentaban los productos existentes y que se pudiera publicar en un breve plazo de tiempo. Así nació el ODMG (Object Data Management Group) que reunía a los principales vendedores de OODBMS: Object Design, Ontos, O2 Technology, Versant, Objectivity, POET Software y Servio Corporation; y que contaba también con diversos revisores tanto de empresas, como de universidades.

A mediados del 93 ya se había finalizado la primera versión de este estándar, determinando también un conjunto de características a incluir en la segunda versión. Además ODMG propuso su estándar a los organismos oficiales de normalización ANSI e ISO, así como al OMG (Object Management Group).

La primera versión se publicó en 93, y se revisó en la edición 1.1 y 1.2. Las principales mejoras de la versión 1.2 se referían al lenguaje de consulta de objetos (OQL, Object Query Language). La versión 2.0, además de algunas mejoras como la incorporación de nuevos tipos de colecciones, como el tipo diccionario (dictionary type), introdujo la parte de la vinculación con el lenguaje Java. La versión ODMG 3.0 incluye algunas mejoras de vinculación con Java, mejoras al modelo de objetos y algunas correcciones y mejoras en las especificaciones del estándar.

Los principales componentes del estándar ODMG 3.0 son:

Modelo de objetos. El modelo de objetos está basado en el modelo de objetos de OMG y se extiende, agregando componentes para soportar las necesidades específicas de las BD.

Lenguaje de Especificación de Objetos. El modelo de objetos ODMG soporta dos lenguajes de especificación de objetos:


o ODL lenguaje de definición de objetos (Object Definition Language), que no es un lenguaje de programación completo, aunque es un lenguaje de definición independiente. Su sintaxis extiende al IDL, lenguaje de definición de interfaces (Interface Definition Language) desarrollado por OMG.

o OIF. Una mejora que introdujo la versión 2.0 del estándar es la definición de otro lenguaje de especificación, el formato de intercambio de objetos (OIF, Object Interchange Format), que se puede usar para intercambiar objetos entre BD, proporcionar documentación de BD o guiar un conjunto de pruebas de BD.

Lenguaje de Consulta de Objetos. Es un lenguaje declarativo (OQL, Object Query Language) para consultar la BD, También proporciona algunos constructores para actualizar los objetos de la BD. Aunque está basado en SQL, su semántica no es la misma. OQL soporta capacidades más potentes con respecto al resultado de la consulta, permitiendo obtener el mismo resultado en tipos de colecciones diferentes. Sin embargo, el resultado de una consulta SQL siempre es una tabla.

Vinculación con Lenguajes de Programación. La versión 3.0 tiene enlaces con C++, Java y Smalltalk. Estos enlaces definen la correspondencia entre ODL y los LP correspondientes. También incluye una correspondencia del lenguaje de manipulación de objetos (OML, Object Manipulation Language) para cada uno de los LP, para escribir código portable que permita manipular los objetos persistentes usando uno de esos lenguajes. Además incluye un mecanismo para invocar OQL y procedimientos para realizar operaciones y transacciones sobre las BD de objetos.

4.3.1. EjemplosDeclaración de clases (ODL)

class Persona //nombre de la clase (intención)(extent gente key idP) { //nombre del archivo que contiene los datos (extensión)

//si no se indica extent es interface//y opcional llave candidata del objeto(OID es automático)

attribute idP int; //atributo atómico (int, real, char, string, boolean, enum)attribute nombre string;attribute Struct Direc(string calle, string ciudad, dtring estado, string cp) direccion;

//atributo tipo estructurado (struct, set, list, array, bag, // dictionary), se puede usar después como // Persona::Direc

attribute telefono string;string getNombre(); //método, sólo la firma, implementación en LP anfitrión,

//los parámetros pueden ser IN, OUT ó IN/OUT//puede usar self//pueden sobrecargarse y sobrescribirse

void setNombre(string nuevoNombre); }; class Estudiante extends Persona //nombre de clase que hereda de Persona

(extent estudiantes) {attribute creditos int;int getCreditos();void addCreditos(int numCreditos);relationship Set(<Grupo> tomaClase Inverse Grupo::tieneEstudiantes;

//relación Estudiante toma un conjunto de clases en unGrupo//y su inversa Grupo tieneEstudiantse Estudiante (M:M)

} class Profesor extends Persona (extent prof) {

attribute enum NivelProf {instructor, asistente, asociado, académico} nivel;//atributo enumerado


attribute salario real(8,2);string getNivel();real getSalario();relationship Departamento perteneceA Inverse Departamento::tieneProfesor;

//relación bidireccional Profesor perteneceA un Depto/y su /inversa Departamento tieneProfesor Profesor (1:M)

relationship Set<Grupo> daClaseEn Inverse Grupo::tieneProfesor;//relación Profesor daClase en un conjunto de Grupo//y su inversa Grupo tieneProfesor profesor

} class Grupo (extent grupos) {

attribute grupo string;relationship Set<Estudiante> tieneEstudiantes Inverse Estudiante::tomaClase;relationship Profesor tieneProfesor Inverse Profesor::daClaseEn;

}

Consultas (OQL)Select e.idP, e.creditos //muestra todos los id y créditos en el archivo(extent) estudiantesFrom estudiantes e;

Select g.getNombre() //muestra los nombres de todas las personas en extent genteFrom g in gente; //otra forma de alias

Select e.idP, e.tomaClase //obtiene el conjunto de objetos relacionados al objetoFrom estudiantes as e //mediante la relación e.tomaclase, muestra todas lasWhere e.idP = ‘E999’; //clases que toma el estudiante E999

Select p.nombre //encuentra registros por su referencia (d–var iterador) From departamentos as d, d.tieneProfesor as p //muestra los profesores del Where d.nomDepto = ‘Biología’ //departamento de Biología Order By p.nombre; //ordenador por nombre

Select p.nombre //misma consulta, usando subquery, obtiene todos los From (Select d //departamentos referenciados por el iterador b y

From d in departamentos //por cada b obtiene un iterador p Where d.nomDepto = ‘Biología’) as b, b.tieneProfesor as p

Order By p.nombre;

Avg(Select p.salario //obtiene el promedio de salarios de profesores queFrom prof as p //pertenecen al departamento de historiaWhere p.perteneceA = ‘Historia’);

Select g //encuentra los grupos que tengan más de 30 estudiantes From grupos as g Where count(g.tieneEstudiantes > 30);

Tarea.a. Leer al menos 2 fuentes adicionales sobre los temas vistos en esta unidad y hacer un resumen

de la unidad (máximo 1 cuartilla). No olvidar conclusiones y bibliografía.b. Explicar cuáles son las diferencias entre una DBMS y un OODBMS, entre OID y llave primaria,

entre BDOR y BDOO, entre SQL y OQL.


Documents

Bases de Datos Unidad 4