Base de datos orientada a objetos (página 2)

Partes: 1, 2

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.