Bases de datos orientadas a objetos Melisa Astudillo Sebastián García Sebastián Espinoza Profesor José Miguel Rubio León. Ayudantes Fanny Gallardo. Yeison Severino.
Abstract
los lenguajes de consulta de los sistemas de bases de datos tradicionales.
The database applications in areas such as Computer-aided Design (CAD), Software engineering and the information systems at the offices, doesn’t fit with the older type of data processing applications. Because of this the ObjectOriented Model has been proposed for to work with several of these new types of applications. This paper attempts to define an object-oriented database system. It describes the main features and characteristics that an object-oriented database system must have.
Una característica clave de las bases de datos orientadas a objetos es la potencia que proporcionan al diseñador al permitirle especificar tanto la estructura de objetos complejos, como las operaciones que se pueden aplicar sobre dichos objetos. Otro motivo para la creación de las bases de datos orientadas a objetos es el creciente uso de los lenguajes orientados a objetos para desarrollar aplicaciones.
2. Reseña histórica. 1. Introducción. Los modelos de bases de datos tradicionales (relacional, red y jerárquico) son capaces de abarcar distintas necesidades en relación a los sistemas de gestión de bases de datos tradicionales. No obstante, presentan ciertas falencias cuando se trata de aplicaciones más complejas, por ejemplo, el diseño y fabricación en ingeniería (CAD/CAM, CIM), los experimentos científicos, o los sistemas multimedia. Los requerimientos y características son más complejos, las transacciones son de larga duración, se requieren distintos tipos de datos para almacenar imágenes y textos, también es necesario definir operaciones no estándar, específicas para cada aplicación. Las bases de datos orientadas a objetos se crearon para tratar de satisfacer las necesidades de estas nuevas aplicaciones. La orientación a objetos ofrece flexibilidad para manejar algunos de estos requisitos y no es limitada por los tipos de datos y
Los orígenes del término orientados a objetos se remontan a los lenguajes de programación orientados a objetos. Estos tienen sus raíces en el lenguaje Simula 67, propuesto a finales de la década de 1960. En Simula, el concepto de clase agrupa la estructura de datos interna de un objeto en una declaración de clase, es decir, introduce en el lenguaje Algol los conceptos de objeto y de clase. Como Algol, Simula es un lenguaje fuertemente tipado para entornos de compilados. Sin embargo, el primer lenguaje que popularizó la aproximación de objetos fue Small talk (1976); este puede considerarse una síntesis de años del lenguaje Lisp, que ofrece una gran flexibilidad gracias a la interpretación, y Simula, añadiendo el concepto de metaclase. Small talk ha podido responder a las necesidades de flexibilidad presentadas por el desarrollo de entornos de programación gráficos, favoreciendo la rápida creación de prototipos de interfaces de usuarios amigables. Fue utilizado con éxito en la primera estación gráfica Xerox.
Con la llegada de las estaciones de trabajo en los años 80, han crecido numerosos lenguajes orientados a objetos inspirados en Simula o Smalltalk. La mayor parte de los lenguajes interpretados son extensiones del Lisp. Es interesante notar que la mayor parte de los lenguajes populares existentes se encuentran en curso de ampliación para convertirse en orientados a objetos. Las bases de datos se han convertido en piezas fundamentales de muchos sistemas de información y las bases de datos tradicionales son difíciles de utilizar cuando las aplicaciones que acceden a ellas estén escritas en un lenguaje de programación orientado a objetos como C++, Smalltalk o Java. Las bases de datos orientadas a objetos se han diseñado para que se puedan integrar directamente con aplicaciones desarrolladas con lenguajes orientados a objetos, habiendo adoptado muchos de los conceptos de estos lenguajes.
3. El Modelo de Datos Orientado a Objetos. Las técnicas de orientación a objetos procuran satisfacer las necesidades de los clientes finales como las de los desarrolladores de software mediante la capacidad de modelar el mundo real. -En la programación orientada a objetos (POO) las entidades principales son los datos (objetos). -Los objetos se comunican entre sí mediante el uso de mensajes y el conjunto de objetos que responden a los mismos mensajes se implementan mediante clases. -La clase describe e implementa todos los métodos que capturan el comportamiento de sus instancias. -La implementación se encuentra totalmente encapsulada dentro de la clase, y de esta manera puede ser extendida y modificada sin afectar al usuario. -Una clase es parecido a un módulo. Sin embargo, las clases también son posibles de extender y especializar (mecanismo de herencia).
3.2.
Objeto.
Entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos) los mismos que consecuentemente reaccionan a eventos.
-Se presentan como nombres propios o referencias específicas en la descripción de un problema. -Algunos objetos tienen una entidad real y otras, entidades conceptuales (por ejemplo, fórmulas aritméticas para resolver problemas o ecuaciones). -Existen objetos que se introducen por razones de implementación y poseen un significado intangible u abstracto (por ejemplo, un árbol binario). -Cada objeto tiene existencia propia y puede ser identificado. Se ha definido la identidad como: “aquella propiedad de un objeto que lo distingue del resto de objetos”. -En la etapa de análisis de una aplicación es posible dar por supuesto que los objetos tienen identidad. -En el diseño, es necesario adoptar una metodología para implementar dicha identidad (identificadores únicos). -Esta noción de identidad es una parte integral y muy importante de la tecnología orientada a objetos. Los objetos y sus relaciones se describen mediante diagramas de instancias:
unArbolBinario:ArbolBinario
ASG:Aeropuerto códigoAeropuerto=ASG nombreAeropuerto=Asgard zonaHoraria=MET
Melseb:Ciudad nombreCiudad= Dist1 población=5
DA:Aeropuerto códigoAeropuerto=DA
-Las clases y sus relaciones son descritas a través de diagramas de clases:
nombreAeropuerto=DatAirport zonaHoraria=Central
Sim143:Simulación
Árbol Binario
Ciudad nombreCiudad población
descripción=Normal fechaEjecución=14-Dic-2009 convergencia=false Diagrama 1.
unArbolBinario pertenece a la clase ArbolBinario y no se han especificado los valores de los atributos. El objeto Da pertenece a la clase Aeropuerto y tiene los valores Da, DatAirport y Central. Cuando se construye un modelo es necesario decidir qué objetos mostrar y cuales ignorar. Un objeto representa sólo los aspectos relevantes de un problema. No resulta útil modelar detalles irrelevantes o extraños, ya que el ámbito de un objeto depende sólo de qué necesita la aplicación.
3.3.
Clase.
Una clase es un modelo que define las variables y métodos comunes a todos los objetos de un cierto tipo. Una Clase es la descripción de un grupo de objetos con: -Propiedades semejantes (atributos del objeto). -Comportamiento y semántica común. -Establecen n el mismo tipo de relaciones con otros objetos. -Las clases proporcionan un mecanismo para compartir la estructura entre objetos semejantes. Algunas clases tienen un equilibrio real (persona y empresa por ejemplo). -Otras son entidades conceptuales (ecuación algebraica). -Además, existen clases que son sólo mecanismo de una implementación determinada (por ejemplo, árbol binario).
Aeropuerto códigoAeropuerto nombreAeropuerto zonaHoraria Simulación Descripción fechaEjecución convergencia calcular Diagrama 2.
En este conjunto de diagramas no se especifican ni los atributos, ni las operaciones de la clase ArbolBinario. La clase Ciudad tiene los atributos nombreCiudad y población. La clase Aeropuerto cuenta con los atributos códigoAeropuerto, nombreAeropuerto y zonaHoraria. No se muestran las operaciones de Ciudad y Aeropuerto. Sin embargo, esto no quiere decir que a las dos clases les falten operaciones, sino que sólo se ha decidido no mostrarlas. La clase Simulación tiene los atributos descripción, fechaEjecución y convergencia así como también posee la operación calcular.
4. Características de BDOO. "La orientación a objetos proporciona una solución que conduce a un Universo de Objetos 'bien educados' que se piden de manera cortés, concederse mutuamente sus deseos"1. En concreto, la orientación a objetos se define como un conjunto de principios de diseño y desarrollo basados en 1
Dan Ingalls (Pionero en la Programación orientada a objetos).
estructuras de computadoras conceptualmente autónomas conocidas como objetos. Cada objeto representa una entidad del mundo real con la capacidad de actuar consigo misma y de interactuar con otros objetos: .Teniendo en cuenta este concepto, las bases de datos orientadas a objetos (OODB) están diseñadas para capturar los datos de un sistema de negocio, que puede ser considerado como un conjunto de objetos que interactúan entre sí. Las características asociadas a las BDOO son: Objetos: cada entidad del mundo real se modela como un objeto. La forma de identificar objetos es mediante un identificador de objetos (OID, Object Identifier), único para cada objeto. Por lo general este identificador no es accesible ni modificable para el usuario (modo de aumentar la integridad de entidades y la integridad referencial). Los OID son independientes del contenido. Es decir, si un objeto cambia los valores de atributos, sigue siendo el mismo objeto con el mismo OID. Si dos objetos tienen el mismo estado pero diferentes OID, son equivalentes pero tienen identidades diferentes. Encapsulación: cada objeto contiene y define procedimientos (métodos) y la interfaz mediante la cual se puede acceder a él y otros objetos pueden manipularlo. La mayoría de los SGBDOO permite el acceso directo a los atributos incluyendo operaciones definidas por el propio SGBDOO las cuales leen y modifican los atributos para evitar que el usuario tenga que implementar una cantidad considerable de métodos cuyo único propósito sea el de leer y escribir los atributos de un objeto. Generalmente, los SGBDOO permiten al usuario especificar qué atributos y métodos son visibles en la interfaz del objeto y pueden invocarse desde afuera. Además las distintas características, pueden ser clasificadas en tres grupos: Mandatarias: Son aquellas características obligatorias, las que el sistema debe satisfacer, para así poseer un sistema de Base de Datos Orientado a Objetos. Estas son: Objetos complejos, Identidad de objetos, Encapsulamiento, Clases, Sobre paso combinado con unión retardada, Extensibilidad, Completación Computacional, Persistencia y Manejador de almacenamiento secundario, Concurrencia y Recuperación. Opcionales: No son características obligatorias, pero se incluyen para desarrollar un mejor sistema. Éstas pueden ser: herencia múltiple,
chequeo de tipos e inferencia distribución y diseño de transacciones y versiones. Abiertas: Son aquellas características que el diseñador puede agregar, es decir, son un aporte del mismo y están relacionadas con el modelo de programación, la representación del sistema ó el tipo de sistema y su uniformidad.
5. Ventajas y desventajas de SGBDOO. Aunque los Sistema Gestor de Bases de Datos Orientadas a Objetos pueden proporcionar soluciones apropiadas para muchos tipos de aplicaciones avanzadas de bases de datos, no son perfectos y presentan ciertas desventajas, a continuación se presenta un contraste entre pro y contras que apreciables en dicho modelo: Las ventajas de un Sistema Gestor de Bases de Datos Orientadas a Objetos son: 1. Mayor capacidad de modelado. El modelado de datos orientado a objetos permite modelar el "mundo real" de una manera mucho más fiel. Esto se debe principalmente a : Un objeto permite encapsular tanto un estado como un comportamiento Un objeto puede almacenar todas las relaciones que tenga con otros objetos Los objetos pueden agruparse para formar objetos complejos (herencia). 2. Ampliabilidad. Esto se debe a: -Se pueden construir nuevos tipos de datos a partir de los ya existentes. -Agrupación de propiedades comunes de diversas clases e incluirlas en una superclase, lo que reduce la redundancia. -Reusabilidad de clases, lo que repercute en una mayor facilidad de mantenimiento y un menor tiempo de desarrollo. 3. Lenguaje de consulta más expresivo. El acceso navegacional desde un objeto al siguiente es la forma más común de acceso a datos en un Sistema Gestor de Bases de Datos Orientadas a Objetos. Mientras que SQL utiliza el acceso asociativo. El acceso navegacional es más adecuado para gestionar operaciones como los despieces, consultas recursivas, etc.
4. Adecuación a las aplicaciones avanzadas de base de datos. Hay muchas áreas en las que los SGBD tradicionales no han tenido excesivo éxito como el CAD, CASE, OIS, sistemas multimedia, etc. en los que las capacidades de modelado de los Sistema Gestor de Bases de Datos Orientadas a Objetos han hecho que esos sistemas sí resulten efectivos para este tipo de aplicaciones.
muchas herramientas de soporte que sirven tanto para desarrolladores como para usuarios finales.
5. Mayores prestaciones. Los Sistema Gestor de Bases de Datos Orientadas a Objetos proporcionan mejoras significativas de rendimiento con respecto a los Sistema Gestor de Bases de Datos Orientadas a Objetos relacionales. Aunque hay autores que han argumentado que los bancos de prueba usados están dirigidos a aplicaciones de ingeniería donde los Sistema Gestor de Bases de Datos Orientadas a Objetos son más adecuados. También está demostrado que los SGBDR tienen un rendimiento mejor que los Sistema Gestor de Bases de Datos Orientadas a Objetos en las aplicaciones tradicionales de bases de datos como el procesamiento de transacciones en línea (OLTP).
Las BDOO permiten que los objetos hagan referencia directamente a otro mediante apuntadores suaves. Esto hace que las BDOO pasen más rápido del objeto A al objeto B que las BDR, las cuales deben utilizar comandos JOIN para lograr esto. Incluso el JOIN optimizado es más lento que un recorrido de los objetos. Así, incluso sin alguna afinación especial, una BDOO es en general más rápida en esta mecánica de caza-apuntadores. Las BDOO hacen que el agrupamiento sea más eficiente. La mayoría de los sistemas de bases de datos permiten que el operador coloque cerca las estructuras relacionadas entre sí, en el espacio de almacenamiento en disco. Esto reduce en forma radical el tiempo de recuperación de los datos relacionados, puesto que todos los datos se leen con una lectura de disco en vez de varias. Sin embargo, en una BDR, los objetos de la implantación se traducen en representaciones tabulares que generalmente se dispersan en varias tablas. Así, en una BDR, estos renglones relacionados deben quedar agrupados, de manera que todo el objeto se pueda recuperar mediante una única lectura del disco. Esto es automático en una BDOO. Además, el agrupamiento de los datos relacionados, al igual que todas las sub partes de un ensamble, puede afectar radicalmente el rendimiento general de una aplicación. Esto es relativamente directo en una BDOO, puesto que representa el primer nivel de agrupamiento. Por el contrario, el agrupamiento físico es imposible en una BDR, debido a que necesita un segundo nivel de agrupamiento: un nivel para agrupar las hileras que representan a los objetos individuales y un segundo para los grupos de hileras que representan a los objetos relacionados.
Los inconvenientes de un Sistema Gestor de Bases de Datos Orientadas a Objetos son: 1. Carencia de un modelo de datos universal. No hay ningún modelo de datos que esté universalmente aceptado para los SGBDOO y la mayoría de los modelos carecen una base teórica. 2. Carencia de experiencia. Todavía no se dispone del nivel de experiencia del que se dispone para los sistemas tradicionales. 3. Carencia de estándares. Existe una carencia de estándares general para los Sistema Gestor de Bases de Datos Orientadas a Objetos. 4. La optimización de consultas compromete la encapsulación. La optimización de consultas requiere una compresión de la implementación de los objetos, para poder acceder a la base de datos de manera eficiente. Sin embargo, esto compromete el concepto de encapsulación. 5. Competencia. Con respecto a los SGBDR y los SGBDOR. Estos productos tienen una experiencia de uso considerable. SQL es un estándar aprobado y ODBC es un estándar de facto. Además, el modelo relacional tiene una sólida base teórica y los productos relacionales disponen de
6. El modelo de objetos aún no tiene una teoría matemática coherente que le sirva de base.
6. Rendimiento.
7. Estándares BDOO. En el diseño de BDOO no existe una metodología estándar ampliamente aceptada que guíe el proceso de diseño ni un conjunto de reglas para evaluación de diseño, como en otros modelos. Sin embargo, esta situación está mejorando. En 1989, un consorcio de fabricantes de ODBMS formó el Object Management Group (OMG) para garantizar la interoperabilidad entre todos los
diferentes sistemas orientados a objetos (lenguajes, ambientes, bases de datos, etc.). El OMG produce estándares y especificaciones independientes del proveedor para componentes y sistemas basados en objetos. El estándar propuesto por OMG se denomina ODMG (Object Data Management Group). Los principales componentes de este estándar son cuatro: 1. Modelo de objetos: el modelo de objetos está basado en el modelo de objetos de OMG y lo extiende, añadiendo algunos componentes (por ejemplo las Relaciones) para soportar las necesidades específicas de las bases de datos. 2. Lenguajes de especificación de objetos: el modelo de objetos de OMG soporta dos lenguajes de especificación de objetos: el ODL (Object Definition Language) y el OIF (Object Interchange Format). El ODL no es un lenguaje de programación completo aunque es un lenguaje de definición independiente para la especificación de objetos. La sintaxis del ODL extiende el lenguaje de definición de interfaces (IDL) desarrollado por OMG. OIF es otro lenguaje de especificación que fue introducido en la versión 2.0 del estándar y que se puede usar para intercambiar objetos entre bases de datos, proporcionar documentación de bases de datos o guiar un conjunto de pruebas de bases de datos. 3. Lenguaje de consulta de objetos (OQL): es un lenguaje declarativo para consultar bases de datos. También proporciona algunos constructores para actualizar los objetos de la misma. Aunque está basado en el lenguaje 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 “colección” diferentes. Sin embargo, el resultado de una consulta SQL siempre es una tabla. 4. Vinculación con lenguajes de programación: la actual versión del estándar tiene Vinculación con los lenguajes de programación C++, JAVA y Smalltalk. Estas Vinculaciones definen la correspondencia entre el ODL y los lenguajes de Programación correspondiente.
8. Manifiesto de Malcolm Atkinson. Malcolm Atkinson (13 de octubre 1943, Inglaterra): En 1989 se hizo el Manifiesto de los sistemas de base de datos orientados a objetos el cual propuso
trece características obligatorias para un SGBDOO y cuatro opcionales. Las trece características obligatorias estaban basadas en dos criterios: debía tratarse de un sistema orientado a objetos y un SGBD.
8.1. Características orientación a objetos:
obligatorias
de
1. Deben soportarse objetos complejos. 2. Deben soportarse mecanismos de identidad de los objetos. 3. Debe soportarse la encapsulación. 4. Deben soportarse los tipos o clases. 5. Los tipos o clases deben ser capaces de heredar de sus ancestros. 6. Debe soportarse el enlace dinámico. 7. El DML debe ser computacionalmente complejo. 8). El conjunto de todos los tipos de datos debe ser ampliable.
8.2. Características obligatorias de SGBD: 9) Debe proporcionarse persistencia a los datos. 10) El SGBD debe ser capaz de gestionar bases de datos de muy gran tamaño. 11) El SGBD debe soportar a usuarios concurrentes. 12) El SGBD debe ser capaz de recuperarse de fallos hardware y software. 13) El SGBD debe proporcionar una forma simple de consultar los datos
9. Tecnología orientada a objeto En la actualidad existen sistemas de gestión de bases de datos orientadas a objetos al igual que simples gestores de almacenamiento persistente, tanto a nivel comercial como a nivel de investigación en proyectos realizados por distintas universidades. Lo que no se ha encontrado es SGBDOO integrados con máquinas abstractas persistentes y sistemas operativos orientados a objetos. A continuación se exponen brevemente las características de algunos de los sistemas encontrados. Universidad de Oviedo [OMDG-93]: La mayor limitación de las bases de datos orientadas a objetos es la carencia de un estándar. ODMG-93 (ObjectOriented Database Management Group) es un punto de partida muy importante para ello. Adopta una arquitectura que consta de un sistema de gestión que
soporta un lenguaje de bases de datos orientado a objetos, con una sintaxis similar a un lenguaje de programación también orientado a objetos como puede ser C++ o Smalltalk. El lenguaje de bases de datos es especificado mediante un lenguaje de definición de datos (ODL), un lenguaje de manipulación de datos (OML), y un lenguaje de consulta (OQL), siendo todos ellos portables a otros sistemas con el fin de conseguir la portabilidad de la aplicación completa. En definitiva, ODMG-93 intenta definir un SGBDOO que integre las capacidades de las bases de datos con las capacidades de los lenguajes de programación, de forma que los objetos de la base de datos aparezcan como objetos del lenguaje de programación, intentando de esta forma eliminar la falta de correspondencia existente entre los sistemas de tipos de ambos lenguajes. El SGBDOO extiende el lenguaje con persistencia, concurrencia, recuperación de datos, consultas asociativas, etc. Texas [Singhal 92]: Es un sistema persistente orientado a objetos desarrollado en la universidad de Texas en Austin. Se ha implementado como una librería de C++, de tal manera que cualquier aplicación enlazada con dicha librería podrá generar y manipular tanto objetos persistentes como transitorios. Al igual que la base de datos22 orientada a objetos comercial ObjectStore emplea un mecanismo de traducción de punteros (pointer swizzling) cuando se produce el fallo de página. Los objetos almacenan las referencias a otros objetos como identificadores de objetos persistentes sobre disco, pero cuando se trae una página a memoria todas las referencias sobre esa página son traducidas a punteros en memoria virtual. Todo esto es realizado de una forma transparente al programa cliente, y una vez que las referencias a los objetos han sido traducidas, los programas clientes pueden acceder rápidamente a los objetos en memoria. Thor [Thor 97]: Es un sistema de base de datos distribuido orientado a objetos desarrollado en el Instituto Tecnológico de Massachusetts. Proporciona un sistema de almacenamiento persistente de objetos, permitiendo el acceso a los mismos mediante transacciones. En Thor un objeto se convierte en persistente cuando es alcanzado por el objeto raíz. La arquitectura de Thor se organiza en torno a un repositorio de objetos residente en el servidor y a unos pares front-end/cliente almacenados en los clientes. Los procesos front-end son los que hacen las veces de intermediarios entre el programa cliente y el repositorio de objetos. Además, en el cliente para cada lenguaje soportado se proporciona una librería de código que
implementa la interfaz entre el cliente y el front-end. Los objetos dentro de Thor se implementan y especifican usando un nuevo lenguaje procedural de programación denominado Theta. Este lenguaje es orientado a objetos, extensible y fuertemente tipado, permitiendo tanto la especificación de la interfaz de un tipo como la implementación del mismo. Shore [Shore 97]: Es un sistema persistente de objetos, sucesor de Exodus, que está siendo desarrollado en la Universidad de Wisconsin en USA. Representa una mezcla entre las tecnologías de bases de datos orientadas a objetos y los sistemas de ficheros En Shore todo dato persistente es un objeto, y todo objeto tiene una identidad especificada por un identificador de objeto único. Todos los datos persistentes son descritos a través del lenguaje SDL (Shore Data Language) parecido al ODL propuesto por ODMG. Shore permite el control de la concurrencia, la recuperación de caídas, el manejo de transacciones y las consultas optimizadas sobre ciertos tipos. También implementa un espacio de nombres, un modelo de control de acceso similar a los de Unix, y los servicios tradicionales de toda base de datos como el acceso asociativo a los datos, la indexación y el agrupamiento.
10. Bases de Datos Objetos Relacionales. Las bases de datos objeto-relacionales son bases de datos hibridas por ser evolución natural de las bases de datos orientadas a objetos puras y las relaciones puras, debido a las limitaciones de ambas. El modelo objeto relacional también se conoce como el modelo racional extendido ya que incluye nuevas funciones y extensiones soportadas por objetos. Las limitaciones presentadas por el relacional son las siguientes: -Debido a la imposición de la primera forma normal en el modelo relacional la representación de los objetos es bastante pobre. A este se une la falta de relaciones anidadas. Como consecuencia de esto surge la necesidad de utilizar de muchas tablas para dar soporte a estructuras complejas, como por ejemplo el uso de tablas intermedias para resolver las relaciones de cardinalidad uno a muchos. -Al tratar estructuras recursivas o anidadas y en colecciones de datos que correspondiendo al mismo tipo de entidad, el modelo no ofrece una respuesta adecuada. -En el caso de la descomposición de los datos en múltiples tablas complica su recuperación.
-La creación de tipos está altamente limitada. -Ausencia de mecanismos de reutilización. Con objeto de solución estas limitaciones, surge el modelo orientado a objetos puro, y una transición entre ambos aparece el modelo objetorelacional.
11. Diferencias entre SGBD Relacionales Y SGBDOO. Una principal diferencia entre estos dos paradigmas de gestión e implementación de bases de datos la vemos ya al comparar la definición de las unidades básicas de información de cada caso. El modelo relacional define las tuplas como “instancias específicas de una entidad” con un identificador único y las propiedades de esa entidad. En cambio, en el caso de las bases de datos orientadas a objetos, se almacenan los objetos que se definen como “un objeto está modelando una situación o entidad del mundo real al tener una identificación única, propiedades específicas a sí misma y la habilidad de trabajar en conjunto con objetos tanto de la misma o distinta especificación”. Las tuplas del modelo relacional carecen de esa habilidad de trabajar con otras tuplas ya que de comportamiento. Además, el modelo objeto es capaz de representar situaciones del mundo real, en cambio el modelo relacional carecen el modelo relacional sólo trabaja con entidades, por lo tanto, si se quisiera modelar situaciones habría que adaptarlas, transformándolas en entidades perdiendo por el camino parte de la información, o creando un modelo extremadamente complejo.
Diagrama 3. La identificación única de las entidades también difiere en ambos casos. Por un lado el modelo objeto define el OID (Object identity) que proveerá el sistema y le otorgara al objeto su
identidad única. Por otro lado el modelo relacional utiliza el concepto de clave primaria para identificar a sus entidades de una manera única. Esta clave es un valor que puede introducir y cambiar el usuario del sistema gestor con la única restricción de que nos e repita con ninguna otra clave primaria que contenga la tabla en ese momento, aunque también puede asignarla al propio sistema gestor. El modelo objeto, provee de un sistema de tipos análogo al lenguaje de programación con el que se utiliza. De esta forma permite definir nuevas clases así como utilizar la herencia para extender las ya creadas. De esta manera logra aplicar toda la potencia de la orientación a objetos en las bases de datos. Los modelos relacionales tradicionales sólo permitían tipos de datos simples ofrecidos por SQL y en última instancia por el sistema gestor. Esto hace bastante costoso trabajar con atributos multivaluados.
12. Diferencias entre SGBD ObjetoRelacional y SGBDOO. Las BDOO y las BD Objeto-Relacional son modelos que persiguen facilitar el almacenamiento de objetos en la base de datos, pero presentan algunas diferencias. Las bases de datos orientadas a objetos obtienen un mejor rendimiento cuando se usan objetos, ya que estos objetos se almacenan en disco de forma transparente para el lenguaje de programación (lenguaje orientado a objetos), ya que no se utiliza ningún tipo de lenguaje para trabajar con los datos como puede ser SQL, debido a esto no es necesario hacer tipos de conversiones entre datos como ocurre con las bases de datos objetoRelacionales esto puede generar errores ya que es el programador el encargado de realizar esas conversiones y un aumento en el número de líneas de código para la conversión de los tipos de datos así como la carga o descarga de objetos en la base de datos, así como el código propio para hacer consultas o modificaciones en la base de datos. Por un lado este tipo de base de datos es más fácil de desarrollar y mantener lo que implica un coste menor. Por otro lado al carecer de un lenguaje para trabajar los datos (transparente) y además sea el propio lenguaje de programación quien trabaja con ellos, puede ocurrir que la gran potencia del lenguaje permita realizar acciones que dañen la base de datos, problema que no ocurre con las bases de datos Objeto-Relacionales.
Las bases de datos Objeto-Relacionales siguen utilizando lenguaje de tratamiento de datos para trabajar con los objetos. Otra ventaja de este modelo es que permite realizar “consultas ad-hoc”, este tipo de consultas son unas de las causas por la que las bases de datos relacionales se extendieron tan rápidamente y permiten realizar consultas por el usuario sin que estuvieran planificadas cuando se diseñó la aplicación. Presentan un menor rendimiento y por tanto un mayor coste de desarrollo y mantenimiento, pero debido a su gran implantación de las bases de datos relacionales has ido más fácil extender el modelo que diseñar de nuevo los sistemas para cambiar a bases de datos orientados a objetos.
13. Características Bases de datos objetorelacional. Las bases de datos objeto-relacional permiten crear nuevos tipos de datos para gestionar aplicaciones más complejas con una gran riqueza de dominios. Estos pueden ser tipos compuestos, lo que implica que se debe definir al menos dos métodos transformadores uno para convertir el tipo nuevo a ASCII y otro que convierta de ASCII al nuevo tipo. Se pueden compartir varias bibliotecas de clases ya existentes, esto es lo que se conoce como reusabilidad. Se soporta la herencia en los tipos tupla o registro y el encadenamiento dinámico. Soportan los tipos complejos como referencias, listas, conjuntos, registros, colas, pilas y arreglos. Se pueden crear funciones que tengan un código en algún lenguaje de programación como por ejemplo Java, SQL, C, etc. Tienen una mayor capacidad expresiva para los conceptos y asociaciones. Se pueden crear operadores asignándoles nombres y existencia de nuevas consultas con mayor capacidad consultiva. Existe la posibilidad de incluir el chequeo de las reglas de integridad referencial a través de los trigger. El único inconveniente que tienen las bases de datos objetos relacionales es que al aumentar la complejidad del sistema existe un aumento en el coste asociado. .
14. Lenguajes de orientados a objetos.
programación
Los lenguajes de programación orientados a objetos tratan a los programas como conjuntos de objetos que se ayudan entre ellos para realizar acciones. Son lenguajes dinámicos en los que estos objetos se pueden crear y modificar sobre la marcha. Esta tipo de programación orientación, tomó importancia a mediados de los años ochenta debido a la propagación de las interfaces gráficas de usuarios, para lo que los lenguajes de programación orientados a objetos están especialmente dotados. Entre los lenguajes orientados a objetos puros, podemos nombrar a: Simula67: es aceptado como el primer lenguaje que posee las características principales de un lenguaje orientado a objetos. Fue diseñado por los profesores Ole-Johan Dahl y Kristen Nygaard, para hacer programas de simulación de naves, en donde los "objetos" son la representación de la información más importante. SmallTalk: Es un lenguaje orientado a objetos puro, pues todas las entidades que maneja son objetos. El lenguaje se basa en conceptos tales como mensajes y objetos. Éste integra de una manera consistente características tales como un editor, un compilador, un debugger, utilitarios de impresión, un sistema de ventanas y un manejador de código fuente. Este lenguaje, elimina la frontera entre aplicación y sistema operativo, modelando todos los elementos como objetos. Eiffel: Es un lenguaje de programación escrito por Bertrand Meyer. Al contrario que Smalltalk, incluye un preprocesador que permite la traducción de código Eiffel a Lenguaje C. Es ideal para la ingeniería de software, que permite la encapsulación, control de acceso y ámbito de las modificaciones. Como lenguaje orientado a objetos puro, es presumiblemente el mejor por sus capacidades técnicas. Los programas consisten en la declaración de colecciones de clases que incluyen métodos. El punto primordial de un programa Eiffel es la declaración de clases, que asocia atributos. Clases y atributos, son accesibles a partir de la implementación de un concepto llamado característica. Una característica es, por tanto, una agrupación de datos y unas formas típicas de tratarlos. Entre otros se encuentran Java, Actor, Simula, entre otros.
No todos los lenguajes de programación orientados a objetos, son específicamente orientados a objetos. Sino que algunos de ellos se le han añadido extensiones orientadas a objetos, estos son los llamados mixtos y entre ellos se encuentran: C++: Es un lenguaje de uso general que deriva del C. Añade a su predecesor una serie de características que le convierten en un lenguaje orientado a objetos. Dentro de estas características debemos resaltar la abstracción de datos y la programación orientada a objetos, ya que permite asociar a los datos las funciones que los manipulan. Los aspectos más importantes que hacen del C++ un lenguaje orientado a objetos. La mayor contribución que realiza C++ al C es la introducción del tipo clase. Las clases permiten definir conjunto de datos y las funciones que los manipulan. La ocultación de datos es el mecanismo para implementar la abstracción de datos. La abstracción de datos permite al programador “olvidar” el funcionamiento interno de una clase, ya que sabe que su funcionamiento no va a alterar el funcionamiento de otras clases. Una vez definida la clase es transparente para el desarrollador y permite operar con ella como si fuera un tipo básico. La herencia extiende el concepto de abstracción de datos al permitir la construcción de clases a partir de otras (sus antecesores) Los operadores definidos por el usuario permiten un tratamiento homogéneo entre los tipos predefinidos por el lenguaje y los desarrollados por el programado. Phyton: Es un lenguaje de programación multi paradigma. Lo que quiere decir que, en vez de forzar a los programadores a adoptar un estilo particular de programación, permite varios estilos: programación orientada a objetos, programación imperativa (aquellos en los cuales se le ordena a la computadora cómo realizar una tarea siguiendo una serie de pasos o instrucciones) y programación funcional (basado en la utilización de funciones matemáticas). Algunas de las características importantes de Python son: La resolución dinámica de nombres; es
decir, lo que enlaza un método y un nombre de variable durante la ejecución del programa (también llamado enlace dinámico de métodos). La facilidad de extensión, es otro objetivo del diseño del lenguaje. Se pueden escribir nuevos módulos fácilmente en C o C++. Python puede incluirse en aplicaciones que necesitan una interfaz programable.
15. Glosario. Objeto: Un objeto es un concepto, abstracción o cosa que tiene un cierto significado para una aplicación. Clase: Construcción que es utilizada como una plantilla para la creación de objetos de ese tipo. Modularizar: Módulos fáciles de manejar y que comprenden las estructuras de datos y las operaciones permisibles. Encapsulado: Propiedad que permite ocultar la información al resto de los objetos, impidiendo así accesos incorrectos o conflictos. Distingue entre la interfaz a un objeto (qué es lo que hace), de la implementación (cómo lo hace). Herencia: Reutilización, ya que se pueden crear nuevas clases a partir de una preexistente. Facilita la creación de objetos a partir de otros ya existentes, e implica que una subclase obtiene todo el comportamiento (métodos) y eventualmente los atributos (variables) de su superclase. Polimorfismo: Propiedad de una operación mediante la cual puede ser aplicada a distintos tipos de objetos. Mensajes: Cuando un objeto recibe un mensaje concreto, codificado de una forma simple, estándar e independiente de cómo o dónde está implementado el objeto. éste lleva a cabo sus acciones. Identificador de Objetos (OID): Sirve para identificar los objetos y es único para cada objeto. Valor: Es un trozo de información (dato). Es importante no confundir valores y objetos: Los objetos tienen identidad mientras que los valores no.
Atributo: Es una propiedad de una clase a la que se le asigna un nombre y que contiene un valor para cada objeto de la clase. Operación: Es una función o procedimiento que se puede aplicar por un objeto o sobre un objeto. Cada operación actúa sobre un objeto que es su argumento implícito. Al nombre de la operación se pueden añadir detalles opcionales tales como la lista de argumentos o el tipo de resultado. Algunas operaciones son polimórficas, esto es, aplicables a muchas clases. Método: La implementación operación para una clase concreta.
de
una
Dato: Conjunto de caracteres con algún significado. Campo: Es la unidad más pequeña a la cual se puede hacer referencia en un programa. Registro: Colección de campos de iguales o diferente tipo de alguna manera asociados entre sí. Bases de Datos: Recopilación de información perteneciente a un propósito o asunto en particular. El objetivo de una base de datos, es el de almacenar información de manera eficiente. Tablas: Son la parte más importante de una base de datos, ya que es ahí donde se guarda y organiza la información, las tablas se componen de dos partes la primera son las columnas (nombres de los campos) y la segunda son las filas también llamadas registros Tipos de datos abstractos: Agrupa todos los objetos que tienen la misma interfaz y los trata como si fueran del mismo tipo.
16. Conclusión. En Conclusión se sabe que las BDOO representan el siguiente paso en la evolución de las bases de datos, para soportar el Análisis, Diseño y Programación OO. Las BDOO permiten que el mismo modelo conceptual se aplique al Análisis, diseño, programación, definición y acceso a la base de datos. Esto reduce el problema del operador de traducción entre los diferentes modelos a través de todo el ciclo de vida. Esto reduce el problema del operador de traducción entre los diferentes modelos a través de todo el ciclo de vida. El modelo conceptual debe ser la base de las herramientas CASE OO totalmente integradas, las cuales ayudan a generar la estructura de datos y los métodos. Permiten el mantenimiento y desarrollo de aplicaciones complejas con un costo Significativamente menor. Las BDOO ofrecen un mucho mejor rendimiento de la máquina que las bases de datos por relación, para aplicaciones o clases con estructuras complejas de datos. Sin embargo, Las BDOO coexistirán con las bases de datos por relación durante los próximos años, puesto que a menudo se utilizará un modelo por relación como una forma de estructura de datos dentro de una BDOO.
17. Bibliografía.
1. Programación Orientada a Objetos: Una forma de desarrollar un sistema, pensando en las entidades principales del problema que dicho sistema pretende resolver.
Sistema Gestor de Bases de Datos Orientadas a Objetos (SGBDOO): El gestor de una base de datos orientada a objetos. Evento: un suceso en el sistema ( tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente.
Fundament de Bases de datos 5ªEdiciónEditorial: McGraw Hill. Autores: Silberschatz, Korth, Sudarshan 2. http://kybele.escet.urjc.es/documentos/BD/T3Model oOR.pdf 3. http://informatica.uv.es/iiguia/DBD/Practicas/boleti n_1.pdf
4. http://informatica.uv.es/iiguia/DBD/Teoria/capitulo _4.pdf 5. http://tejo.usal.es/~fgarcia/docencia/poo/0203/trabaj os/S1T3.pdf 6. http://www.kybele.etsii.urjc.es/docencia/BD/20122013/Material/[BD-2011-12]T1.BDOO.pdf 7. ict.udlap.mx/activities/GIS/html/files/ModeladoDeD atos.doc 8. http://ilianpatricia18.wordpress.com/2011/02/05/def inicion-y-conceptos-de-las-base-de-datosorientadas-a-objetos/