\

QUE SON LAS BASES DE DATOS ORIENTADOS A OBJETOS

El desarrollo del paradigma orientado a objetos aporta un gran cambio en el modo en que vemos los datos y los procedimientos que actúan sobre ellos. Tradicionalmente, los datos y los procedimientos se han almacenado separadamente: los datos y sus relaciones en la base de datos y los procedimientos en los programas de aplicación. La orientación a objetos, sin embargo, combina los procedimientos de una entidad con sus datos.

Esta combinación se considera como un paso adelante en la gestión de datos. Las entidades son unidades auto contenidas que se pueden reutilizar con relativa facilidad. En lugar de ligar el comportamiento de una entidad a un programa de aplicación, el comportamiento es parte de la entidad en sı, por lo en cualquier lugar en el que se utilice la entidad, se comporta de un modo predecible y conocido.

El modelo orientado a objetos también soporta relaciones de muchos a muchos, siendo el primer modelo que lo permite. Aun así se debe ser muy cuidadoso cuando se diseñan estas relaciones para evitar pérdidas de información por otra parte, las bases de datos orientadas a objetos son navegaciones:

El acceso a los datos es a través de las relaciones, que se almacenan con los mismos datos. Esto se considera un paso atrás. Las bases de datos orientadas a objetos no son apropiadas para realizar consultas ad hoc, al contrario que las bases de datos relacionales, aunque normalmente las soportan. La naturaleza navegacional de las bases de datos orientadas a objetos implica que las consultas deben seguir relaciones predefinidas y que no pueden insertarse nuevas relaciones “al vuelo”.

No parece que las bases de datos orientadas a objetos vayan a reemplazar a las bases de datos relacionales en todas las aplicaciones del mismo modo en que ́estas reemplazaron a sus predecesoras.

Los objetos han entrado en el mundo de las bases de datos de formas:

SGBD orientados a objetos puros: son SGBD basados completamente en el modelo orientado a objetos.

SGBD híbridos u objeto–relacionales: son SGBD relacionales que permiten almacenar objetos en sus relaciones (tablas).

A continuación se definen los conceptos del paradigma orientado a objetos en programación, ya que el modelo de datos orientado a objetos es una extensión del mismo.

Objeto.

Es un elemento auto contenido utilizado por el programa. Los valores que almacena un objeto se denominan atributos, variables o propiedades. Los objetos pueden realizar acciones, que se denominan métodos, servicios, funciones, procedimientos u operaciones. Los objetos tienen un gran sentido de la privacidad, por lo que solo dan información sobre sı mismos a través de los métodos que poseen para compartir su información. También ocultan la implementación de sus procedimientos, aunque es muy sencillo pedirles que los ejecuten.

Los usuarios y los programas de aplicación no pueden ver que hay dentro de los métodos, solo pueden ver los resultados de ejecutarlos. A esto es a lo que se denomina ocultación de información o encapsulamiento de datos.

Cada objeto presenta una interface pública al resto de objetos que pueden utilizarlo. Una de las mayores ventajas del encapsulamiento es que mientras que la interface publica sea la misma, se puede cambiar la implementación de los métodos sin que sea necesario informar al resto de objetos que los utilizan. Para pedir datos a un objeto o que ́este realice una acción se le debe enviar un mensaje. Un programa orientado a objetos es un conjunto de objetos que tienen atributos y métodos. Los objetos interactúan enviándose mensajes. La clave, por supuesto, es averiguar que objetos necesita el programa y cuáles deben ser sus atributos y sus métodos.

Clase.

Es un patrón o plantilla en la que se basan objetos que son similares. Cuando un programa crea un objeto de una clase, proporciona datos para sus variables y el objeto puede entonces utilizar los métodos que se han escrito para la clase. Todos los objetos creados a partir de la misma clase comparten los mismos procedimientos para sus métodos, también tienen los mismos tipos para sus datos, pero los valores pueden diferir.

Una clase también es un tipo de datos. De hecho una clase es una implementación de lo que se conoce como un tipo abstracto de datos. El que una clase sea también un tipo de datos significa que una clase se puede utilizar como tipo de datos de un atributo.

Tipos de clases.

En los programas orientados a objetos hay tres tipos de clases: clases de control, clases entidad y clases interface.

Las clases de control gestionan el flujo de operación de un programa (por ejemplo, el programa que se ejecuta es un objeto de esta clase)

Las clases entidad son las que se utilizan para crear objetos que manejan datos (por ejemplo, clases para personas, objetos tangibles o eventos).

Las clases interface son las que manejan la entrada y la salida de información (por ejemplo, las ventanas gráficas y los menús utilizados por un programa).

En los programas orientados a objetos, las clases entidad no hacen su propia entrada/salida. El teclado es manejado por objetos interface que recogen los datos y los envían a los objetos entidad para que los almacenen y los procesen. La salida impresa y por pantalla la formatea un objeto interface para obtener los datos a visualizar de los objetos entidad. Cuando los objetos entidad forman parte de la base de datos, es el SGBD el que se encarga de la entrada/salida a ficheros.

El resto de la entrada/salida la manejan los programas de aplicación o las utilidades del SGBD. Muchos programas orientados a objetos tienen un cuarto tipo de clase: la clase contenedor. Estas clases contienen, o manejan, múltiples objetos creados a partir del mismo tipo de clase. También se conocen como agregaciones. Las clases contenedor mantienen los objetos en algún orden, los listan e incluso pueden permitir búsquedas en ellos. Muchos SGBD orientados a objetos llaman a sus clases contenedor Extents (extensiones) y su objetivo es permitir el acceso a todos los objetos creados a partir de la misma clase.

Tipos de métodos.

Hay varios tipos de métodos que son comunes a la mayoría de las clases:

Constructores. Un constructor es un método que tiene el mismo nombre que la clase. Se ejecuta cuando se crea un objeto de una clase. Por lo tanto, un constructor contiene instrucciones para inicializar las variables de un objeto. Destructores. Un destructor es un método que se utiliza para destruir un objeto.

No todos los lenguajes orientados a objetos poseen destructores accesores. Un accesor es un método que devuelve el valor de un atributo privado de otro objeto. Así es como los objetos externos pueden acceder a los datos encapsulados. Mutadores. Un mutador es un método que almacena un nuevo valor en un atributo. De este modo es como objetos externos pueden modificar los datos encapsulados. Además, cada clase tendrá otros métodos dependiendo del comportamiento especıfico que deba poseer.

Sobrecarga de métodos.

Una de las características de las clases es que pueden tener métodos sobrecargados, que son métodos que tienen el mismo nombre pero que necesitan distintos datos para operar. Ya que los datos son

distintos, las interfaces públicas de los métodos serán diferentes. Por ejemplo, consideremos una clase contenedor. (Marqués, 12 de abril de 2002)

CARACTERÍSTICAS

Un sistema de base de datos orientados a objetos debe poseer las siguientes características, desde los más sencillos a objetos más complejos.

I. Tipos complejos

Array: Son matrices de elementos de datos, como los que podemos encontrar en innumerables aplicaciones científicas.

Sentencia de tipo: Insertar elementos en una matriz en cualquier posición.

Tuplas: Forma natural de representar las propiedades de una entidad.

Conjunto: Forma natural de representar los grupos del mundo real.

Funciones: Para crear, modificar y borrar otros objetos.

Uniones: Elementos de datos que pueden tomar diferentes valores de los diferentes tipos, es decir, matrices heterogéneas.

II. Identidad de objeto

La identidad es aquella propiedad de un objeto que lo distingue de todos los demás objetos. La idea es

que en un modelo con identidad de los objetos, la existencia de un objeto es independiente de su valor.

Cada objeto se representa por un ID (Identificador de objetos) que es único dentro de toda la base de

datos. Estos IDOs no tienen que ser gestionados por el programador ya que son implementados a bajo

nivel por el sistema, lo que a su vez incrementa el rendimiento del mismo. De esta forma dos objetos

serán diferentes si tienen IDOs diferentes, aunque sus atributos tengan los mismos valores. Así, dos

objetos pueden ser idénticos (son el mismo objeto, tienen el mismo IDO) o iguales (tienen el mismo valor).

Esto implica que dos objetos idénticos son a su vez iguales, mientras que lo inverso no es cierto.

La identidad de los objetos es además una potente primitiva que puede ser la base para el manejo de

tuplas, conjuntos, y objetos complejos recursivos. También permite operaciones tales como asignación o

copia de objetos.

III. Encapsulamiento

El encapsulamiento se centra en la implementación que da lugar al comportamiento observable de un objeto. El encapsulamiento se consigue a menudo mediante la ocultación de información, es decir, se basa en ocultar todos los secretos de un objeto que no contribuyen a sus características esenciales. El encapsulamiento proporciona, por tanto, barreras explícitas entre abstracciones diferentes. Existen dos visiones diferentes del encapsulamiento [ATK89], la primera y original que es la del lenguaje de programación; y la segunda que es la adaptación de esa visión para la base de datos. Desde el punto de vista de las bases de datos, esto se traduce en el hecho de que un objeto abarca operaciones y datos, pero con una diferencia. En las bases de datos no está claro si la parte estructural es parte de la interfaz (depende del sistema), mientras que en los lenguajes de programación la estructura de datos es claramente parte de la implementación y no de la interfaz. Como se puede observar, el encapsulamiento proporciona una forma lógica de independencia de los datos, ya que se puede cambiar la implementación de un tipo sin cambiar ninguno de los programas que usan ese tipo. IV. Tipos y clases

Existen dos categorías principales de sistemas orientados a objetos, los que soportan el concepto de clases y los que soportan el concepto de tipo. Un tipo en un sistema orientado a objetos se corresponde con el concepto de tipo abstracto de datos.

Es un conjunto de objetos que tienen un mismo comportamiento (comparten una misma funcionalidad) que se puede observar desde afuera. Esto significa que el tipo al cual un objeto pertenece depende de qué operaciones puedan invocarse sobre el objeto. V. Herencia

Las clases o tipos heredan de sus ancestros. Ventajas de la herencia:

Ayuda al modelado porque proporciona una descripción concisa y precisa del mundo.

Ayuda a compartir especificaciones e implementaciones en las aplicaciones. VI. Polimorfismo, sobrecarga y ligadura tardía.

Existen casos en los que se desea tener el mismo nombre para diferentes operaciones. Supongamos la operación dibuja que toma un objeto como entrada y lo dibuja en pantalla. Dependiendo del tipo de objeto (cuadrado, estrella, flecha,...) debemos emplear diferentes mecanismos de visualización. Es decir, necesitamos visualizar un conjunto cuyos miembros no se conocen en tiempo de compilación.

En una aplicación que emplee el sistema convencional, habrá tantas operaciones como figuras a representar: dibuja cuadrado, dibuja estrella, dibuja flecha, etc.

En un sistema orientado a objetos se definirá la operación en una clase más general. Así dibuja tendrá un único nombre y podrá emplearse indiferentemente sobre cualquier figura.

VII. Complejidad de cálculos

Puede expresarse cualquier función computable utilizando el lenguaje de modificación de datos de un sistema de base de datos.

VIII. Extensibilidad.

El conjunto de tipos predefinidos que aporta el sistema de base de datos debe ser extensible mediante algún mecanismo que permita definir tipos nuevos.

No debe haber distinción en cuanto al uso de los tipos definidos por el sistema y los extendidos.

IX. Persistencia

La persistencia es una de las características que los SGBDOO heredan tanto de los SGBD como del modelo de objetos. La diferencia está en que la persistencia proporcionada por el SGBD tradicional, se refiere únicamente a la conservación de los datos, mientras que la persistencia heredada del modelo de objetos hace referencia no sólo a la conservación del estado de un objeto, sino también a la conservación de la clase, que debe trascender a cualquier programa individual, de forma que todos los programas interpreten de la misma manera el estado almacenado.

X. Gestión de almacenamiento

La gestión del almacenamiento secundario es soportada por un conjunto de mecanismos que no son visibles al usuario, tales como gestión de índices, agrupación de datos, selección del camino de acceso, optimización de consultas, etc. Estos mecanismos evitan que se tengan que escribir programas para mantener índices, asignar el almacenamiento en disco, o trasladar los datos entre el disco y la memoria principal, creándose de esta forma una independencia entre los niveles lógicos y físicos del sistema.

XI. Concurrencia

El SGBO debe gestionar el acceso de múltiples usuarios a la vez. Soportando la noción de atomicidad de una secuencia de operaciones y la compartición controlada. .

Si se introduce concurrencia en nuestro sistema hay que considerar cómo los objetos activos sincronizan sus actividades con otros, así como con objetos puramente secuenciales. Por ejemplo, si dos objetos activos intentan enviar mensajes a un tercer objeto, hay que tener la seguridad de que existe algún mecanismo de exclusión mutua, de forma que el estado del objeto sobre el que se actúa no está corrupto cuando los dos objetos activos intentan actualizarlo simultáneamente. En presencia de la concurrencia no hay que definir simplemente los métodos de un objeto; hay que asegurarse también de que la semántica de estos métodos se mantiene a pesar de la existencia de múltiples usuarios concurrentes.

XII. Recuperación

El sistema debe proporcionar como mínimo el mismo nivel de recuperación que los sistemas de bases de datos actuales. De forma que, tanto en caso de fallo de hardware como de fallo de software, el sistema pueda retroceder hasta un estado coherente de los datos. Los fallos de los que un sistema debe ser capaz de recuperarse pueden producirse por diferentes motivos, por ejemplo:

Interrupción en el suministro de energía, de forma que se pierda la información almacenada en la memoria principal y en los registros de uso general.

Errores de software, debido a que los resultados generados son incorrectos, lo que provoca respuestas erróneas a los usuarios y que la base de datos entre en un estado incongruente.

XIII. Facilidad de consulta ad hoc

El sistema debería proporcionar la funcionalidad de un lenguaje de consulta ad hoc, es decir, permitir al usuario hacer cuestiones sencillas a la base de datos. Este tipo de consultas tienen como misión proporcionar la información solicitada por el usuario de una forma correcta y rápida. (Prieto, 2011)

CARACTERÍSTICAS OPCIONALES

I. Herencias múltiples

Tipo de herencia que permite a una clase tener más de una super-clase y heredar características de sus ancestros. Así, si un sistema ofrece herencia múltiple pueden surgir una serie de conflictos, como el hecho de que dos o más superclases tengan un atributo con el mismo nombre, pero con dominios diferentes. También puede ocurrir que exista Herencias repetidas, esto pasa cuando dos o más superclases "hermanas", comparten una superclase común, ya que entonces hay que decidir si la clase que hereda de ambas debe tener una sola copia o muchas copias de la estructura de la clase compartida.

II. Distribución

Los objetos de las bases de datos pueden estar almacenados en diferentes ubicaciones, sin que el usuario al acceder a ellos sea consciente de esta circunstancia, el sistema debe proporcionar una forma de realizar esta operación de manera transparente.

III. Versiones

La mayoría de las nuevas aplicaciones, tales como CAD/CAM y CASE, comprenden una actividad de diseño que requiere alguna forma de versionado una versión es una instantánea semánticamente significativa tomada al objeto de diseño en un momento dado en el tiempo. Una versión de un objeto se crea a partir de las modificaciones hechas en el tiempo a las versiones previas de éste, comenzando con una versión inicial. La traza de estas derivaciones se mantiene a través de una historia de las versiones.

Una versión de un objeto complejo puede constar de las versiones específicas de sus objetos componentes. (Prieto, 2011)

VENTAJAS Y DESVENTAJAS

Las ventajas de un BDOO son:

Mayor capacidad de modelado:

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).

Se pueden construir nuevos tipos de datos a partir de los ya existentes

Agrupar 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.

El acceso navegacional desde un objeto al siguiente es la forma más común de acceso a datos en

un SGBDOO. Mientras que SQL utiliza el acceso asociativo.

El acceso navegacional es más adecuado para gestionar operaciones como los despieces,

consultas recursivas, etc.

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 SGBDOO han

hecho que esos sistemas sí resulten efectivos para este tipo de aplicaciones. .

Los SGBDOO proporcionan mejoras significativas de rendimiento con respecto a los SGBD

relacionales.

Las desventajas de una BDOO 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.

Lentitud a la hora de ejecutar el sistema.

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 SGBDOO.

Competencia. Con respecto a los SGBDR y los SGBDOR.

El acceso navegacional desde un objeto al siguiente es la forma más común de acceso a datos en

un SGBDOO. Mientras que SQL utiliza el acceso asociativo.

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. Bases de Datos Orientadas a Objetos

El modelo de objetos aún no tiene una teoría matemática que le sirva de base. (Torres, 2010)

DIFERENCIAS ENTRE EL MODELO DE OBJETOS Y EL MODELO RELACIONAL

Mientras que en una BDR los datos a almacenar se almacenan representados en tablas en un BDOO los

datos se almacenan como objetos. Un objeto en BDOO como en POO es una entidad identificable

unívocamente que describe tanto el estado como el comportamiento de una entidad del ‘mundo real’.

El estado de un objeto es descrito mediante atributos mientras que su comportamiento es definido mediante métodos.

La forma de identificar objetos es mediante un identificador de objetos (OID, Object Identifier), único para cada objeto. General mente 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.

Cada objeto contiene 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. (María Pilar Azcarate Toro, 2011)

Bibliografía María Pilar Azcarate Toro, A. C. (2011). Base de datos orientado a objetos y objeto relacional.

Pereira.

Marqués, M. (12 de abril de 2002). Bases de datos orientadas a objetos (Vol. 2). Diseño de

Sistemas de Bases de Datos.

Prieto, A. B. (2011). Introducción a los sistemas de gestión de bases de. Universidad de Oviedo.

Torres, J. P. (2010). Base de datos orientado a objetos (Vol. 2). IES SAN VICENTE.