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. 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.
Historia
Los lenguajes de programación orientado a objeto 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, Simula es un lenguaje fuertemente tipado para entornos compilados. Sin embargo, el primer lenguaje que popularizó la aproximación a objetos fue Smalltalk (1976); que ofrece una gran flexibilidad gracias a la interpretación, y de Simula, añadiendo el concepto de metaclase.
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 Entre los lenguajes compilados, los más celebres son C++, Objective C y Ediffel.
En años recientes, han aparecido muchos prototipos experimentales y sistemas de bases de datos comerciales orientados a objetos. Entre los primeros se encuentran los sistemas ORION, OpenOODB, IRIS, ODE y el proyecto ENCORE/ObServer. Y entre los sistemas disponibles en el mercado están: GESTONE/OPAL de ServioLogic, ONTOS de Ontologic, Objectivity de Objectivity Inc., Versant de Versant Technologies, ObjecStore de ObjectDesign y O2 de O2 Technology.
Origen de las base de datos orientadas a objetos
El origen se encuentra básicamente en las siguientes razones:
La existencia de problemas para representar cierta información y modelar ciertos aspectos del "mundo real", puesto que los modelos clásicos permiten representar gran cantidad de datos, pero las operaciones y representaciones que se pueden realizar sobre ellos son bastante simples.
El paso del modelo de objetos al modelo relacional genera dificultades que en el caso no surgen ya que el modelo es el mismo.Por lo tanto, las bases de datos orientadas a objetos surgen básicamente para tratar de paliar las deficiencias de los modelos anteriores y para proporcionar eficiencia y sencillez a las aplicaciones.
Las debilidades y limitaciones de los Sistema Gestor de Bases de Datos Orientadas a Objetos son:
Pobre representación de las entidades del "mundo real".
Sobrecarga y poca riqueza semánticas.
Soporte inadecuado para las restricciones de integridad y empresariales
Estructura de datos homogénea
Operaciones limitadas
Dificultades para gestionar las consultas recursivas
Desadaptación de impedancias
Problemas asociados a la concurrencia, cambios en los esquemas y el inadecuado acceso navegacional.
No ofrecen soporte para tipos definidos por el usuario (sólo dominios)
Mientras que las necesidades de las aplicaciones actuales con respecto a las bases de datos son:
Soporte para objetos complejos y datos multimedia
Identificadores únicos
Soporte a referencias e interrelaciones
Manipulación navegacional y de conjunto de registros
Jerarquías de objetos o tipos y herencia
Integración de los datos con sus procedimientos asociados
Modelos extensibles mediante tipos de datos definidos por el usuario
Gestión de versiones
Facilidades de evolución
Transacciones de larga duración
Interconexión e interoperabilidad
Debido a las limitaciones anteriormente expuestas, su uso es más ventajoso si se presenta en alguno de los siguientes escenarios:
Un gran número de tipos de datos diferentes
Un gran número de relaciones entre los objetos
Objetos con comportamientos complejos
Se puede encontrar este tipo de complejidad acerca de tipos de datos, relaciones entre objetos y comportamiento de los objetos principalmente en aplicaciones de ingeniería, manufacturación, simulaciones, automatización de oficina y en numerosos sistemas de información. No obstante, las BDOO no están restringidas a estas áreas. Ya que al ofrecer la misma funcionalidad que su precursoras relacionales, el resto de campos de aplicación tiene la posibilidad de aprovechar completamente la potencia que las BDOO ofrecen para modelar situaciones del mundo real.
Características
Una de las características mandatorias de o reglas son:
1.-Debe tener un motor de base de datos.
2.-Debe ser un sistema orientado a objetos.
Mandatorias.- Son las que el Sistema debe satisfacer a orden de tener un sistema de base de datos orientadas a objetos y estos son: Objetos complejos, Identidad de objetos, Encapsulación, Tipos ó Clases, Sobre paso combinado con unión retardada, Extensibilidad, Completación Computacional, Persistencia y Manejador de almacenamiento secundario, Concurrencia, Recuperación y Facilidad de Query.
Opcional.- Son las que pueden ser añadidas para hacer el sistema mejor pero que no son Mandatorias estas son de: herencia múltiple, chequeo de tipos e inferencia distribución y diseño de transacciones y versiones.
Abiertas.- Son los puntos donde el diseñador puede hacer un número de opciones y estas son el paradigma de la programación la representación del sistema ó el tipo de sistema y su uniformidad.
El modelo orientado a objetos se basa en encapsular código y datos en una única unidad, llamada objeto. El interfaz entre un objeto y el resto del sistema se define mediante un conjunto de mensajes. El término mensaje en un contexto orientado a objetos, no implica el uso de un mensaje físico en una red de computadoras, si no que se refiere al paso de solicitudes entre objetos sin tener en cuenta detalles específicos de implementación. El modelo de datos orientado a objetos es una extensión del paradigma de programación orientado a objetos. Los objetos entidad que se utilizan en los programas orientados a objetos son análogos a las entidades que se utilizan en las bases de datos orientadas a objetos puros, pero con una gran diferencia: los objetos del programa desaparecen cuando el programa termina su ejecución, mientras que los objetos de la base de datos permanecen. A esto se le denomina persistencia.
Ventajas e inconvenientes de las bas e de datos orientadas a objetos
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, también tienen sus desventajas.
Las ventajas de un Sistema Gestor de Bases de Datos Orientadas a Objetos son:
Mayor capacidad de modelado. El modelado de datos orientado a objetos permite modelar el "mundo real" de una manera mucho más fiel. Esto se debe a:
1. un objeto permite encapsular tanto un estado como un comportamiento
2. un objeto puede almacenar todas las relaciones que tenga con otros objetos
3. los objetos pueden agruparse para formar objetos complejos (herencia).
Ampliabilidad. Esto se debe a:
1. Se pueden construir nuevos tipos de datos a partir de los ya existentes.
2. Agrupación de propiedades comunes de diversas clases e incluirlas en una superclase, lo que reduce la redundancia.
3. Reusabilidad de clases, lo que repercute en una mayor facilidad de mantenimiento y un menor tiempo de desarrollo.
Lenguaje de consulta más expresivo. El acceso navegacional desde un objeto al siguiente es la forma más común de acceso a datos en un 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.
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.
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).
Los inconvenientes de un Sistema Gestor de Bases de Datos Orientadas a Objetos son:
Carencia de un modelo de datos universal. No hay ningún modelo de datos que esté universalmente aceptado para los SGBDOO y la mayoría de los modelos carecen una base teórica.
Carencia de experiencia. Todavía no se dispone del nivel de experiencia del que se dispone para los sistemas tradicionales.
Carencia de estándares. Existe una carencia de estándares general para los Sistema Gestor de Bases de Datos Orientadas a Objetos.
Competencia. Con respecto a los SGBDR y los SGBDOR. Estos productos tienen una experiencia de uso considerable. SQL es un estándar aprobado y ODBC es un estándar de facto. Además, el modelo relacional tiene una sólida base teórica y los productos relacionales disponen de muchas herramientas de soporte que sirven tanto para desarrolladores como para usuarios finales.
La optimización de consultas compromete la encapsulación. La optimización de consultas requiere una compresión de la implementación de los objetos, para poder acceder a la base de datos de manera eficiente. Sin embargo, esto compromete el concepto de encapsulación.
El modelo de objetos aún no tiene una teoría matemática coherente que le sirva de base.
Autor:
Andrés de la Torre
PROFESOR: Msc. Richard I. Ramirez A.
SEMESTRE: VI Ingeniería en Sistemas
AÑO: 2009 – 2010
UNIVERSIDAD ESTATAL DE MILAGRO
| Página siguiente |