UNIVERSIDAD NACIONAL AUTNOMA DE MXICO

FACULTAD DE CONTADURA Y ADMINISTRACIN

Licenciatura En Informtica

Bases de Datos
Aut or : L.I. M ara de Lour de Isab el s Ponce Vsq u z e

AGOSTO - DICIEMBRE 200 8

Contenido
UNIDAD 4. MODELO ORIENTADO A OBJETOS................................................................................................3

Objetivos Especficos.......................................................................................................................3 4.1. Introduccin..............................................................................................................................3 4.1.1. Retos Actuales de los DBMSs............................................................................................3 4.1.2. Tendencias Actuales en la Tecnologa de BD....................................................................4 4.1.1.1. Rendimiento.................................................................................................................5 4.1.1.2. Distribucin/Integracin................................................................................................5 4.1.1.3. Funcionalidad/Inteligencia............................................................................................5 4.1.3. Orientacin a Objetos.........................................................................................................5 4.1.1.4. Principios Fundamentales de la POO...........................................................................6 4.1.1.5. Modularidad.................................................................................................................6 4.1.1.6. Abstraccin..................................................................................................................7 4.1.1.7. Objetos.........................................................................................................................7 4.1.1.8. Clases..........................................................................................................................8 4.1.1.9. Encapsulamiento..........................................................................................................8 4.1.1.10. Interrelaciones............................................................................................................8 4.1.1.11. Polimorfismo...............................................................................................................9 4.1.4. Persistencia........................................................................................................................9 4.2. Sistemas de Administracin de BDOO....................................................................................10 4.2.1. Antecedentes...................................................................................................................10 4.2.2. Primera Generacin.........................................................................................................10 4.2.3. Segunda Generacin.......................................................................................................11 4.2.4. Tercera Generacin.........................................................................................................12 4.2.5. Definicin.........................................................................................................................12 4.2.6. Caractersticas.................................................................................................................13 4.1.1.12. Persistencia..............................................................................................................13 4.1.1.13. Modelo de objetos....................................................................................................14 4.1.1.14. Lenguaje de Datos...................................................................................................14 4.1.1.15. Arquitectura de tres niveles......................................................................................14 4.1.1.16. Optimizador..............................................................................................................14 4.1.1.17. Seguridad.................................................................................................................14 4.1.1.18. Interfaces para Programas de Aplicacin (API)........................................................14 Diccionarios de datos..............................................................................................................15 4.1.1.19. Herramientas para desarrollo de aplicaciones..........................................................15 4.1.1.20. Herramientas para la transformacin de datos.........................................................15 4.1.1.21. Utilidades para mantenimiento y mejora del rendimiento de la BD...........................15 4.1.1.22. Soporte de datos multimedia....................................................................................15 4.1.1.23. Herramientas y Facilidades de Usuario....................................................................15 4.1.1.24. Distribucin...............................................................................................................15 4.1.1.25. Control de versiones y configuraciones....................................................................16 4.3. Estndar ODMG.....................................................................................................................16 4.3.1. Ejemplos..........................................................................................................................17

Unidad 4. Modelo Orientado a Objetos

Pgina 2

UNIDA D 4. MODELO ORIENTAD O A OBJETOS O bjeti vos Es p ficos ec

Describir los retos y tendencias actuales de los DBMS Comprender el paradigma orientado a objetos Conocer los orgenes de las bases de datos orientadas a objetos Definir y describir las caractersticas del modelo orientado a objetos Describir y comprender el estndar ODMG

4 . Intr oduccin .1
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 semntica del modelo relacional para soportar aplicaciones complejas, como CAD/CAM, CASE, sistemas basados en conocimiento, tratamiento de documentos, multimedia y gestin de redes, etc., que necesitan modelacin directa de objetos e interrelaciones complejas, el almacenamiento de informacin no estructurada, gestin de diversos tipos de transacciones, control exhaustivo de componentes y estructuras, adems 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 apareca 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 reduccin de la distancia en el desarrollo entre el modelo conceptual (E/R UML) y el modelo lgico, ya que el paradigma de la orientacin a objetos (PaOO) proporciona un nico modelo implementado en el OODBMS, al que acceden directamente las aplicaciones.

4.1.1. Retos Actuale de los DBMSs s

La ltima generacin de BD ha demostrado que an no se pueden resolver todos los problemas de almacenamiento que tericamente deban resolverse con el uso de las BD, algunos de estos problemas son: Los DBMS actuales son monolticos; ofrecen todo tipo de servicios y funcionalidades en un solo paquete, sin considerar las necesidades especficas de los usuarios, esto provoca un alto costo y prdida de eficiencia. A la fecha siguen existiendo ms datos en hojas de clculo que en DBMSs por la facilidad y simpleza que estos sistemas ofrecen en comparacin con los DBMSs. Se cree que cerca del 50% de los datos de produccin se encuentran todava en sistemas heredados (sin DBMSs) sin poder llevar toda la informacin a un DBMS.

Unidad 4. Modelo Orientado a Objetos

Pgina 3

 Los sistemas de gestin de flujos de trabajo (workflow) y muchos otros no tecnologa de BD, simplemente acceden a la BD a travs de Interfaces Aplicacin (APIs). Los servicios de replicacin estn limitados por lo que no se extienden nodos. Es difcil combinar datos estructurados y no estructurados en una provenientes de correos electrnicos).

estn basados en de Programas de a ms de 10,000 BD (por ejemplo

Las BD son el ncleo 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, gestin de la incertidumbre, etc. La integracin de datos estructurados y no estructurados es muy importante y los DBMS deben ofrecer este servicio. La globalizacin y competitividad internacional influyen en la tecnologa, la cual debe proporcionar conectividad entre las BD distribuidas geogrficamente, siendo capaces de integrar rpidamente BD separadas (protocolos, distribucin de datos, federaciones, etc.) y ofrecer disponibilidad 100% (las 24 horas del da durante los 365 das del ao). Los nuevos productos de BD deben ayudar al usuario a la localizacin de los datos distribuidos y a la conexin de las aplicaciones en las PC con las BD locales y remotas.

4.1.2. Tendencias Actuale en la Tecnologa de BD s

Los avances en hardware tienen gran impacto en el desarrollo actual de las BD. La reduccin de precio de RAM y disco han proporcionado equipos con ms potencia a precios ms bajos. Este factor ha afectado algunos algoritmos de los DBMS, permitiendo que grandes volmenes de datos sean almacenados RAM. Tambin, la arquitectura paralela (Multiprocesadores Simtricos SMP Symmetryc Multi-Processing y Procesadores Masivamente Paralelos MPP Massively Parallel Processing) ofrece la posibilidad de ejecutar los DBMS en varios procesadores. Otras tecnologas que tambin estn influyendo a los cambios son: tcnicas de compresin/descompresin, digitalizadores de audio y video, medios de almacenamiento ptico, discos magnticos, medios de almacenamiento jerrquico, etc. Las computadoras asistentes personales, PDA (Personal Digital Assistant), palmtops, laptops, etc., permiten acceder a la informacin en cualquier sitio y momento. Eso plantea problemas de conectividad y afecta la distribucin de las BD. El modelo C/S con la introduccin 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 rpida, AnyLan, FDDI Interfaz de Datos Distribuidos en Fibra, DQDB Bus Dual de Colas Distribuidas-, Frame Relay, etc.) han cambiado tambin la capa de comunicacin donde se sitan las BD. Recientemente, la aparicin de la tecnologa GRID, que pretende conectar computadoras con el fin de proporcionar una potencia de clculo mayor y usar los ciclos de procesador desperdiciados, tambin plantea interesantes desafos de metadatos, seguridad, interoperabilidad, rendimiento, etc. a las BD. Las DB han evolucionado en tres aspectos: rendimiento, distribucin/integracin y funcionalidad.

Unidad 4. Modelo Orientado a Objetos

Pgina 4

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 aos han aparecido BD que explotan las ventajas del gris. En aplicaciones de respuesta crtica el rendimiento se mejora fijando prioridad para las transacciones en tiempo real. Tambin para mejorar el rendimiento, las BD en memoria principal cambian algunos conceptos de estructuras de ndices, agrupaciones, bloqueos, transacciones, etc. 4.1.1.2. Distribucin/Integracin La distribucin de BD se ha ampliado a BD Mviles que son sistemas distribuidos en los que los enlaces entre los nodos cambian dinmicamente. Se ha ampliado la integracin 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 ms, la semntica y funcionalidad se ha migrado a los DD, almacenndose junto con los datos, de modo que se libere a las aplicaciones de comprobar restricciones de integridad y duplicndose en todos los programas, y convirtindose en BD semnticas. A principios de los 90 aparecieron las bases de datos activas, donde la descripcin de los datos y las restricciones, se almacenan en la BD y pueden ejecutar aplicaciones sin la intervencin del usuario soportando disparadores, reglas, alertas, demonios, etc. Las OODB y ORDD permiten la definicin y gestin de los objetos, donde los objetos pueden ser de cualquier tipo: imgenes, audio, video, etc. (BD multimedia) o datos geogrficos (BD espaciales). Recientemente han aparecido las BD semiestructuradas, adecuadas para gestin de documentos XML, que aportan un nuevo modelo de datos.

4.1.3. O entacin a Objetos ri

La Orientacin a Objetos se puede definir como "una disciplina de ingeniera de desarrollo y modelado de software que permite construir ms fcilmente sistemas complejos a partir de componentes individuales". La Orientacin a Objetos permite una representacin ms directa del mundo real, reduciendo fuertemente la transformacin radical normal desde los requerimientos del sistema, definidos en trminos del usuario, a las especificaciones del sistema, definidas en trminos 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

Unidad 4. Modelo Orientado a Objetos

Pgina 5

interactan y cuyas fronteras no estn determinadas por su instrumentacin 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 caractersticas: Abstraccin Herencia Identidad de los Objetos Otros ms estiman que la OO se basa slo en: Herencia Encapsulamiento o encapsulacin Polimorfismo Mientras que otros sealan siete u ocho de los siguientes aspectos como bsicos a considerar para una verdadera orientacin al objeto: Modularidad Abstraccin Objetos Clases Encapsulamiento Herencia Polimorfismo y enlace dinmico Persistencia

4.1.1.5. Modularidad La modularidad consiste en dividir un programa en partes llamadas mdulos, los cuales pueden trabajarse por separado. En trminos de programacin, los mdulos pueden compilarse por separado y la divisin no depende de cierto nmero de lneas sino es una divisin en trminos de integrar en un mdulo 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 elaboracin de programas al poder dividir el trabajo entre varios programadores y aumentar la productividad. Por ejemplo, un automvil est constituido por un conjunto de mdulos tales como un sistema elctrico, uno mecnico y uno de frenado. Cada mdulo se trabaja por separado y el especialista slo conoce la forma en que se relaciona el mdulo con los otros, pero no tiene por qu saber los detalles de funcionamiento de otros mdulos o sistema. Estos conceptos no son exclusivos de la OO, pues se han desarrollado desde la programacin estructurada, slo 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 prdidas de tiempo al desear modificar tal programa.

Unidad 4. Modelo Orientado a Objetos

Pgina 6

La OO no puede lograrse sin hacer uso de los mecanismos antes mencionados y para ello, proporciona los medios para ir creando mdulos llamados clases. En las clases, cada tipo no simple es un mdulo, y cada mdulo de alto nivel es un tipo. 4.1.1.6. Abstraccin La abstraccin es una descripcin o especificacin simplificada de un sistema que hace nfasis en algunos detalles significativos y suprime los irrelevantes. La abstraccin es esencial para construir cualquier sistema, sea o no orientado a objetos y debe enfocarse ms en qu es un objeto y qu hace, antes de pensar en la implementacin. Por ejemplo, un automvil puede abstraerse como un objeto que sirve para desplazarse a mayor velocidad, sin importar cmo lo haga. Una caracterstica de la abstraccin es que un objeto puede abstraerse de diversas formas, dependiendo del observador. As, el automvil que se mencionaba puede ser visto como un objeto de coleccin por un coleccionista, una herramienta de trabajo por un corredor profesional, una mercanca por un vendedor, etc. 4.1.1.7. Objetos A pesar de que el punto central en esta nueva metodologa de programacin es el concepto de objeto. En trminos de programacin, un objeto es: un concepto, abstraccin o cosa con lmites bien definidos y significado para una aplicacin. 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 caractersticas distintivas del mismo y los valores de cada una de estas propiedades. En trminos de programacin, puede decirse que las propiedades son las variables que sirven para describir tal objeto. El comportamiento es la forma como acta o reacciona un objeto en trminos de cambio de estado, envo y recepcin de mensajes. Est formado por la definicin de las operaciones (funciones y procedimientos) que puede realizar este objeto. Los tipos ms comunes de operaciones, o en POO mtodos, 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 dems. Un objeto conserva su identidad an cuando algunos o todos los valores de los atributos o las definiciones de los mtodos 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 nocin ms fuere que la que se encuentra normalmente en los lenguajes de programacin 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 programacin para identificar a cada variable dentro de un programa. Unidad 4. Modelo Orientado a Objetos Pgina 7

Incorporacin. Se incorpora en el modelo de datos el lenguaje de programacin y no se requiere que el usuario proporcione algn identificador. Esta es la forma que se usa en las BD orientadas a objetos. Por ejemplo, un automvil puede tener diversos estados, puede estar estacionado o en circulacin. Un comportamiento asociado con el auto pueden incluir encenderlo, lo cual modifica su estado, y generalmente tiene una identidad marca, modelo, nmero de serie del motor y placa. 4.1.1.8. Clases Una clase es un mdulo y un tipo de datos abstracto que define un grupo de objetos que comparten caractersticas comunes. Por ejemplo, se puede hablar de autos como una clase y mencionar propiedades compartidas tales como los asientos o parabrisas, pero tambin 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 comn 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 tcnica para empaquetar la informacin, envolviendo los atributos y mtodos 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 algn cambio en la implementacin de un objeto no se tengan que modificar los programas que utilizan tal objeto. Siguiendo con el ejemplo del automvil, 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 slo el mecnico sabe los detalles de la implementacin. Por otro lado, si en algn momento se cambia, para el conductor es transparente. 4.1.1.10. Interrelaciones La herencia que es la una relacin entre clases donde las caractersticas y el comportamiento general de una superclase puede compartirse con sus subclases, permite que una clase sea definida como una extensin o restriccin de otra y es la contribucin ms importante de la POO, pues mediante este mecanismo es posible lograr la principal meta de la OO que es la reutilizacin de cdigo. La herencia permite definir una jerarqua de clases. En tal jerarqua, algunas clases son subordinadas a otras llamadas subclases. Una subclase define el comportamiento de un conjunto de objetos que heredan algunas de las caractersticas de la clase padre, pero adquieren caractersticas especiales no compartidas por el padre, en este sentido se dice que la subclase es una especializacin de la clase padre.

Unidad 4. Modelo Orientado a Objetos

Pgina 8

La herencia mltiple y repetida permite que se pueda declarar una clase como heredera de varias, e incluso de ella misma. La herencia simple permite heredar slo de una clase padre. En estos casos, se implementan las llamadas interfaces que permiten simular la herencia mltiple. Otro tipo de interrelacin muy importante en este modelo es la agregacin, que permite construir objetos complejos o compuestos a partir de otros, correspondiendo a la nocin parte-de tiene un. Por ejemplo un auto tiene un motor. La genericidad es otra forma de interrelacin que es la capacidad de definir clases parametrizadas (genricos), creando una plantilla que permite construir tipos. Por ejemplo, se puede definir un vector de elementos de tipo X, siendo X el parmetro formal que se sustituye por el parmetro real cuando se requiere construir el tipo concreto, por ejemplo un vector de nmeros enteros, de personas, de vectores, etc. 4.1.1.11. Polimorfismo El polimorfismo es la capacidad de tener mtodos con el mismo nombre pero con una implementacin diferente o que un mtodo 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 vehculo se detendr sin importar si los frenos son de tambor o de disco. Una implementacin especfica de un comportamiento para una cierta clase se denomina mtodo. En un sistema polimrfico, un comportamiento puede tener ms de un mtodo que lo implemente. Por ejemplo, existir un mtodo frenar cuando se trata de frenos de disco y otro cuando son de tambor pero el mtodo 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 parmetros, stos no requieren herencia. Sobrescritura. Cuando una subclase redefine un servicio manteniendo el mismo nombre. Un lenguaje de programacin OO se disea para seleccionar automticamente el mtodo correcto para implementar la operacin, a partir de los datos asociados con la operacin como parmetros, y el nombre de la clase de objeto, esto es llamado enlace dinmico (dinamic binding). El enlace dinmico, permite que las entidades del programa puedan referenciar en tiempo de ejecucin a objetos de diferentes clases y est ntimamente relacionado con el concepto de herencia. En el ejemplo del frenado, el objeto seleccionar el mtodo de frenado apropiado, basado en los parmetros 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 an cuando el objeto es transformado o destruido.

Unidad 4. Modelo Orientado a Objetos

Pgina 9

Una vez almacenado en memoria secundaria, se puede reconstruir para usarlo durante la ejecucin (materializacin del objeto). Por ejemplo, se puede desear guardar informacin 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 . Siste mas de Admin istr acin de BDOO

4.2.1. Antecedente s
La historia de las BD se extiende desde mediados de los 60s y se ha caracterizado por su excepcional productividad e impresionante impacto econmico. A continuacin se muestra un resumen de las ltimas dcadas de evolucin.

4.2.2. Prim era

Generacin

Desde que empezaron a usarse las computadoras para automatizar la administracin de las empresas, la evolucin de los sistemas de informacin ha tenido impacto en la gestin de los datos, al exigir cada vez ms prestaciones de la informacin almacenada en los sistemas. Gradualmente, el enfoque de la informtica, inicialmente concentrado en el proceso donde los datos se almacenaban en archivos especficos para cada aplicacin, 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 diseo de los sistemas de informacin se centran en el modelo y estructuracin de los datos. Tras los complejos sistemas de archivos de las primeras etapas de la informtica, en las dcadas 60 y 70 naci la primera generacin de productos de BD. Los primeros DBMS que se basaron en los modelos jerrquicos y en red, proporcionaban una organizacin lgica de los datos en rboles y grafos. Si bien eran sistemas bastante eficientes, este tipo de productos usaba lenguajes procedimentales, no posean la suficiente independencia fsico/lgica y su flexibilidad era muy limitada. Sin embargo, lograron varios avances comparados con los sistemas de archivos. La incorporacin a los DBMS de facilidades de comunicacin 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 accedan a la BD a travs de una red de comunicacin. 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 artculo El Programador como Navegador, describe el proceso de navegar a travs de una BD, en el que el programador tiene que seguir un camino explcito, registro a registro, en la bsqueda de un conjunto de datos. En sus especificaciones de 1978, Codasyl propuso un Lenguaje de Definicin 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 jerrquicos y los conjuntos Codasyl se implementaron fsicamente mediante apuntadores. Esta implementacin, junto a las restricciones funcionales de estos enlaces y conjuntos, son las causas de los puntos dbiles de los sistemas basados en estos modelos (poca Unidad 4. Modelo Orientado a Objetos Pgina 10

flexibilidad en las estructuras fsicas, dependencia datos/aplicaciones, y complejidad de los lenguajes de navegacin). Sin embargo, estos mismos apuntadores son precisamente la razn de su eficiencia, uno de los puntos fuertes de este tipo de productos. Esta generacin est orientada principalmente al procesamiento por lotes.

4.2.3. S gu da Generacin e n
Los productos relacionales se consideran la segunda generacin de BD; productos como Oracle, DB2, etc., proporcionan mayor independencia fsica/lgica, mayor flexibilidad y lenguajes de consulta declarativos, en los que los usuarios indican qu quieren obtener sin describir cmo hacerlo. Con los RDBMSs, las organizaciones tambin tienen ms facilidad para distribuir sus datos. Adems los RDBMSs proporcionan una base terica ms slida. 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 optimizacin de las consultas, lenguajes de alto nivel, teora de la normalizacin, organizaciones fsicas para el almacenamiento de las relaciones, algoritmos para la gestin de memorias intermedias (buffers), tcnicas de indexacin (variaciones de los rboles B), sistemas distribuidos, dd, gestin de transacciones, etc. Estas investigaciones tuvieron como consecuencia un aumento de la eficiencia y la seguridad de los entornos transaccionales en lnea (OLTP); tema fundamental en la 2 generacin de BD. En los 80s se estandariz SQL, con la mayora de los productos ofreciendo una interfaz SQL, an los no relacionales. Muchos avances en la tecnologa 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 slo en las investigaciones tericas, sino tambin en las aplicaciones prcticas. En la mayora de los modelos de referencia se pueden encontrar dos conceptos principales: la arquitectura de tres niveles (externo, lgico e interno), tambin propuesta por Codasyl en el 78, y la descripcin recursiva de los datos. La separacin entre la apariencia lgica de los datos y su implementacin fsica ha sido siempre un objetivo importante en la evolucin 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 lneas de investigacin en las dcadas de los 70 y 80, siendo soportado por la mayora de los productos actuales. En los 90 surgieron otros DBMS basados principalmente en modelos de objetos. En los ltimos aos, con el auge del lenguaje XML, los DBMS estn soportando la gestin de este tipo de informacin con modelos XML puros o implantndolos como una capa sobre el modelo relacional. Pueden citarse tres factores clave en la evolucin de las BD: los fundamentos tericos, los productos y las aplicaciones prcticas. 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 tecnolgico 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 evolucin, fue hasta los 90 que la tecnologa ha sido guiada por las demandas de los usuarios. En los ltimos aos la tecnologa de BD ha obtenido grandes avances, temas que parecan al principio exclusivos de laboratorios y centros de investigacin, han aparecido en las ltimas versiones comerciales: multimedia, orientacin a objetos, seguridad, temporalidad (incorporan el tiempo), paralelismo, BD multidimensionales, semiestructuradas, gril, etc. Unidad 4. Modelo Orientado a Objetos Pgina 11

4.2.4. Terc era Generacin

Muchas aplicaciones no tradicionales no usaban tecnologa de BD por que sus necesidades especiales. Los DBMS han puesto atencin 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 organizacin de las empresas tambin obligaron el nacimiento de una nueva generacin de BD. Esta generacin se caracteriza por proporcionar capacidades de gestin de datos igual que las anteriores, permitiendo que grandes cantidades de datos persistentes sean compartidos por muchos usuarios. Tambin proporcionan gestin de objetos, permitiendo tipos de datos mucho ms complejos, objetos multimedia, datos derivados, encapsulamiento de la semntica de los datos, as como otras nuevas capacidades. Algunos proporcionan incluso gestin de conocimiento, soportando un gran nmero de reglas complejas para inferencia automtica de informacin y tambin para mantener las restricciones de integridad entre datos.

4.2.5. Definicin
Existen dos enfoques principales de implementacin de BD de objetos. El primero, extiende los RDBMS para que soporten los conceptos de orientacin a objetos creando las BD ObjetoRelacionales. Por otro lado, estn 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 Generacin de Stonebraker (1990), y son cumplidas por la mayora de los proveedores relacionales actuales: 1er. Principio: Adems de los servicios tradicionales de gestin de datos, los DBMS de tercera generacin proporcionarn gestin de objetos y reglas ms amplio: o Un DBMS debe tener un sistema de tipos amplio. o Debe manejar herencia. o Debe permitir definir mtodos y encapsulamiento. o Debera asignar OID para las tuplas slo si no est disponible una llave primaria. 2. Principio: Los DBMS de tercera generacin deben incluir a los DBMS de segunda generacin: o Deben tener un lenguaje de acceso declarativo y de alto nivel. o Deben existir dos formas de especificar las colecciones: por enumeracin 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 generacin deben ser abiertos a otros subsistemas: o Debe ser accesible desde mltiples lenguajes de alto nivel. o Deben soportar persistencia de variables. o SQL debe ampliarse para la expresin de datos. o Las consultas y sus respuestas deben ser el nivel ms bajo de comunicacin C/S.

Unidad 4. Modelo Orientado a Objetos

Pgina 12

Por su parte, las BD Orientadas a Objetos son ms completas y describen sus caractersticas 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 complejos Identidad del objeto Encapsulamiento Tipos y clases Jerarquas de tipos o clases Polimorfismo, sobrecarga y enlace dinmico Complecin de clculos Extensibilidad Persistencia Gestin del almacenamiento secundario Concurrencia Recuperacin Facilidad de consulta Junto con cinco caractersticas opcionales que seran convenientes presentar: Herencia mltiple Verificacin de inferencia del tipo Distribucin Transacciones de diseo Versiones Este manifiesto fue el primero que se elabor, se present como una propuesta ante la falta de acuerdos en las caractersticas de los OODBMS y, por ello, los autores aconsejan cuestionar las reglas.

4.2.6. Caractersticas
Las caractersticas de estos sistemas provienen de la unin de BD y OO. Las caractersticas que indica el ANSI (1990b) son consideradas como modelo de referencia abstracto, y que, no indica una especificacin implementable, sino una exposicin general y un punto de comparacin. 4.1.1.12. Persistencia En los OODBMS los objetos son permanentes almacenados en la BD hasta borrarlos de modo explcito, 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 operacin que hace a un objeto persistente.

Unidad 4. Modelo Orientado a Objetos

Pgina 13

4.1.1.13. Modelo de objetos A diferencia del modelo relacional, el modelo de objetos es ms realista, ya que los objetos representan entidades del mundo real dando una sensacin mucho mejor del problema que un conjunto de tablas. Adems, es ms potente, ya que es mucho ms flexible y posee caractersticas 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 programacin (ImperativoJava/ 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 difcil de respetar en los OODBMS, considerndose 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 definicin 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 mayora de los productos no conceden a la arquitectura de tres niveles gran importancia, descuidando sobre todo la definicin de vistas. 4.1.1.16. Optimizador En el caso de los OODBMS, sus lenguajes son navegacionales, por lo que la optimizacin resulta difcil 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 travs de objetos ya cargados en memoria, siempre que se puede convertir fcilmente los IDO de los objetos a posiciones de memoria. El optimizador estar condicionado a las caractersticas que posean los lenguajes del OODBMS, aunque la mayora poseen optimizadotes rudimentarios, sin estadsticas en el DD que permitan una mejor optimizacin. 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 Aplicacin (API)

Unidad 4. Modelo Orientado a Objetos

Pgina 14

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 mayora estn muy unidos a un lenguaje especfico, particularmente C++, Smalltalk y Java. Diccionarios de datos El OODBMS debe manipular metadatos sobre objetos, clases, jerarquas, colecciones, etc. con lo que se obtiene mayor riqueza semntica 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 manipulacin de las bibliotecas de clases. Esto todava no se logra al nivel de los RDBMS. 4.1.1.20. Herramientas para la transformacin de datos Deben proporcionar herramientas que permitan transferir datos entre distintos DBMS, pudindose 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 Tambin 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 mayora ofrecen una capacidad limitada para ajustes de rendimiento parametrizado. 4.1.1.22. Soporte de datos multimedia Deben soportar distintos tipos de datos, adems 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, segn sea la funcin que desempean en cada momento (DBA, Programador, diseador de clases, usuario final, etc.). Las IGU tambin siguen el PaOO, facilitando la interaccin del usuario con el sistema. 4.1.1.24. Distribucin 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. Unidad 4. Modelo Orientado a Objetos Pgina 15

4.1.1.25. Control de versiones y configuraciones El control de versiones es una caracterstica fundamental, debido a su uso en entornos de diseo CAD/CAM y sistemas de informacin de oficinas, de modo que: Todos los objetos persistentes tengan versiones y no exista un lmite en el nmero de versiones que puede tener. Las aplicaciones deben poder acceder a la versin actual de un objeto o a cualquier otra. Debe atenderse en especial a la eficiencia de las versiones actuales. Tambin es importante agrupar versiones compatibles de diversos objetos y tratarlos como una unidad de ms 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 gestin de versiones mediante un nivel de software implementado sobre el modelo bsico. Se considera la versin como una cuestin de las aplicaciones.

4.3 . ODMG

E n ar st d

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 estndar de facto, basado en las caractersticas 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 reuna a los principales vendedores de OODBMS: Object Design, Ontos, O2 Technology, Versant, Objectivity, POET Software y Servio Corporation; y que contaba tambin con diversos revisores tanto de empresas, como de universidades. A mediados del 93 ya se haba finalizado la primera versin de este estndar, determinando tambin un conjunto de caractersticas a incluir en la segunda versin. Adems ODMG propuso su estndar a los organismos oficiales de normalizacin ANSI e ISO, as como al OMG (Object Management Group). La primera versin se public en 93, y se revis en la edicin 1.1 y 1.2. Las principales mejoras de la versin 1.2 se referan al lenguaje de consulta de objetos (OQL, Object Query Language). La versin 2.0, adems de algunas mejoras como la incorporacin de nuevos tipos de colecciones, como el tipo diccionario (dictionary type), introdujo la parte de la vinculacin con el lenguaje Java. La versin ODMG 3.0 incluye algunas mejoras de vinculacin con Java, mejoras al modelo de objetos y algunas correcciones y mejoras en las especificaciones del estndar. Los principales componentes del estndar 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 especficas de las BD. Lenguaje de Especificacin de Objetos. El modelo de objetos ODMG soporta dos lenguajes de especificacin de objetos: Pgina 16 Unidad 4. Modelo Orientado a Objetos

ODL lenguaje de definicin de objetos (Object Definition Language), que no es un lenguaje de programacin completo, aunque es un lenguaje de definicin independiente. Su sintaxis extiende al IDL, lenguaje de definicin de interfaces (Interface Definition Language) desarrollado por OMG. o OIF. Una mejora que introdujo la versin 2.0 del estndar es la definicin de otro lenguaje de especificacin, el formato de intercambio de objetos (OIF, Object Interchange Format), que se puede usar para intercambiar objetos entre BD, proporcionar documentacin 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, Tambin proporciona algunos constructores para actualizar los objetos de la BD. Aunque est basado en SQL, su semntica no es la misma. OQL soporta capacidades ms 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. Vinculacin con Lenguajes de Programacin. La versin 3.0 tiene enlaces con C++, Java y Smalltalk. Estos enlaces definen la correspondencia entre ODL y los LP correspondientes. Tambin incluye una correspondencia del lenguaje de manipulacin de objetos (OML, Object Manipulation Language) para cada uno de los LP, para escribir cdigo portable que permita manipular los objetos persistentes usando uno de esos lenguajes. Adems incluye un mecanismo para invocar OQL y procedimientos para realizar operaciones y transacciones sobre las BD de objetos. o

4.3.1. Ejemplos
Declaracin de clases (ODL) class Persona (extent gente key idP) { //nombre de la clase (intencin) //nombre del archivo que contiene los datos (extensin) //si no se indica extent es interface //y opcional llave candidata del objeto(OID es automtico) //atributo atmico (int, real, char, string, boolean, enum)

attribute idP int; 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 despus como // Persona::Direc attribute telefono string; string getNombre(); //mtodo, slo la firma, implementacin en LP anfitrin, //los parmetros 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; //relacin 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, acadmico} nivel; //atributo enumerado Unidad 4. Modelo Orientado a Objetos

Pgina 17

attribute salario real(8,2); string getNivel(); real getSalario(); relationship Departamento perteneceA Inverse Departamento::tieneProfesor; //relacin bidireccional Profesor perteneceA un Depto /y su /inversa Departamento tieneProfesor Profesor (1:M) relationship Set<Grupo> daClaseEn Inverse Grupo::tieneProfesor; //relacin 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 From estudiantes e; Select g.getNombre() From g in gente; //muestra todos los id y crditos en el archivo(extent) estudiantes //muestra los nombres de todas las personas en extent gente //otra forma de alias //obtiene el conjunto de objetos relacionados al objeto //mediante la relacin e.tomaclase, muestra todas las //clases que toma el estudiante E999

Select e.idP, e.tomaClase From estudiantes as e Where e.idP = E999;

Select p.nombre //encuentra registros por su referencia (dvar iterador) From departamentos as d, d.tieneProfesor as p //muestra los profesores del Where d.nomDepto = Biologa //departamento de Biologa 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 = Biologa) as b, b.tieneProfesor as p Order By p.nombre; Avg(Select p.salario //obtiene el promedio de salarios de profesores que From prof as p //pertenecen al departamento de historia Where p.perteneceA = Historia); Select g //encuentra los grupos que tengan ms 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 (mximo 1 cuartilla). No olvidar conclusiones y bibliografa. b. Explicar cules son las diferencias entre una DBMS y un OODBMS, entre OID y llave primaria, entre BDOR y BDOO, entre SQL y OQL. Unidad 4. Modelo Orientado a Objetos Pgina 18