Base de Datos Orientado a Objetos

En una base de datos orientada a objetos, la información se representa mediante objetos como los presentes en la programación orientada a objetos. Cuando se integra las características de una base de datos con las de un lenguaje de programación orientado a objetos, el resultado es un sistema gestor de base de datos orientada a objetos (ODBMS, object database management system). Un ODBMS hace que los objetos de la base de datos aparezcan como objetos de un lenguaje de programación en uno o más lenguajes de programación a los que dé soporte. Un ODBMS extiende los lenguajes con datos persistentes de forma transparente, control de concurrencia, recuperación de datos, consultas asociativas y otras capacidades.

Los ODBMS son una buena elección para aquellos sistemas que necesitan un buen rendimiento en la manipulación de tipos de dato complejos.

Los ODBMS proporcionan los costes de desarrollo más bajos y el mejor rendimiento cuando se usan objetos gracias a que almacenan objetos en disco y tienen una integración transparente con el programa escrito en un lenguaje de programación orientado a objetos, al almacenar exactamente el modelo de objeto usado a nivel aplicativo, lo que reduce los costes de desarrollo y mantenimiento.

Una BD Orientada a Objetos (BDOO) es una base de datos en el sentido de la definición inroductoria, donde los elementos de datos son objetos y las relaciones se mantienen por medio inclusón lógica.  Las entidades de aplicación estan representadas como clases. La autodescripcion se obtiene porque las clases son metaobjetos que contiene los nombres de atributos y métodos de señal. Una BDOO contiene un método sistemático de representación de relación, y la interfaz uniforme de usuario es un sistema de mensajes que puede explorar los objetos y sus interconexiones.

En una BDOO, las entidades de aplicación son las clases, las instrancias de entidad son objetos creados desde las clases, y  las relaciones se mantienen por medio de inclusión lógica. Un sistema de señales y métodos para procesarlas contiene una interfaz uniforme para la base de datos.  

 

Estructura de una BD OO

 

El paradigma orientado a objetos se basa en el encapsulamiento de datos y  del código relacionado con cada objeto en una sola unidad. Conceptualmente, todas las interacciones entre cada objeto y el resto del sistema se realizan mediante mensajes. Por lo tanto, la interfaz entre cada objeto y el resto del sistema se define mediante un conjunto de mensajes permitidos.

 En general,  cada objeto esta asociado con:

Ø      Un conjunto de variables que contiene los  datos  del  objeto; las variables corresponden con los atributos del  modelo E-R.

Ø      Un conjunto de mensajes a los que responde;  cada  mensaje puede o no tener parámetros o tener uno o varios.

Ø      Un conjunto de métodos, cada uno de los cuales es el código que implementa un  mensaje;  el  método  devuelve  un  valor como respuesta al mensaje.

Mensaje en entorno OO no implica uso de mensajes físicos en redes informáticas. Por el contrario,  hace referencia al intercambio de solicitudes entre los objetos, independientemente de los detalles correctos de su implementación. Se utiliza a veces la expresión invocar un método para detonar al hecho de enviar un mensaje a un objeto y la ejecución del método correspondiente.

 
 EJEMPLOS:

 CLASES DE OBJETOS

class empleado {
/ / Variables
          string nombre;
          strin  dirección;
          date fecha de alta;
          int  sueldo;
/ / Mensajes
           int   sueldo-anual ();
           string obtenerNombre ();
           string obtenerDireccion ();
          int definirDireccion (string nueva-dir);
         int antigüedad();
};

Generalmente en una base de datos hay muchos objetos similares (se entiende que responden a los mismos mensajes, utilizan los mismos métodos y tienen variables del mismo nombre y tipo). Por tanto sería un derroche definir por separado cada uno de estos objetos. Por tanto, los objetos se agrupan para formar clases. Todos los objetos de una clase comparten una definición común, pese a que se diferencien en los valores asignados a las variables.

El concepto de clase del modelo orientado a objetos se corresponde con el concepto de entidad del modelo E-R.

 
El ejemplo Empleado muestra las variables y los mensajes que responden a los objetos de la clase; no se muestran aquí los métodos para el tratamiento de los mensajes.
 

Los principales conceptos que se utilizan en las BDOO son:
 

A.    IDENTIDAD DE  OBJETOS

 
Un sistema de BDOO provee una identidad única a cada objeto independiente almacenado en la base de datos. Esta identidad única suele implementarse con un identificador de objeto único, generado por el sistema, u OID. El valor de un OID no es visible para el usuario externo, sino que el sistema lo utiliza a nivel interno para identificar cada objeto de manera única y para crear y manejar las referencias entre objetos.
 
La principal propiedad que debe tener un OID es la de ser inmutable; es decir, el valor del OID para un objeto en particular nunca debe cambiar. Esto preserva la identidad del objeto del mundo real que se está presentando. También es preferible que cada OID se utilice sólo una vez; esto es aunque un objeto se elimine de la Base de datos, su OID no se deberá asignar a otro objeto. Estas dos propiedades implican que el OID no debe depender del valor de ningún atributo del objeto, pues estos valores pueden cambiar. También suele considerarse inapropiado basar el OID en la dirección física del objeto en el almacenamiento, ya que una reorganización de los objetos de la base de datos podría cambiar los OID. Sin embargo, algunos sistemas sí usan la dirección física como OID para aumentar la eficiencia de la obtención de los objetos. Si la dirección física cambia, puede colocarse un apuntador indirecto en la dirección anterior, dando la nueva ubicación física del objeto. Un sistema de BDOO debe contar con algún mecanismo para generar los OID con la propiedad de inmutabilidad. 

Algunos modelos de datos OO requieren que todo se represente como un objeto, ya sea un valor simple o un objeto complejo; así, todo valor básico, como un entero, una cadena o un valor boleano, tiene un OID. Con ello dos valores básicos pueden tener diferentes OID, lo cual es muy útil en algunos casos. Por ejemplo, en algunas ocasiones se podría usar el valor entero 50 para representar un peso en Kilogramos, y en otras para referirse a la edad de una persona. Así podrían crearse dos objetos básicos con diferentes OID, y ambos tendrían el mismo valor básico de 50. Aunque resulta útil como modelo teórico, esto no es muy práctico porque puede obligar a generar demasiados OID. Por ello también, la mayor parte de los sistemas de BDOO permiten representar tanto objetos como valores. Todo objeto debe tener un OID inmutable, pero los valores no tienen OID y se representan así mismo.

Ø      Los objetos tienen  identidades  únicas,  independientes  de los valores de sus atributos.

Ø      La estructura orientada a objetos automáticamente  impone
las restricciones relacionales, generalmente más aplicables:
dominio, llave integridad de entidad e integridad referencial.
 
 

B.  CONSTRUCTORES DE TIPOS

En las BDOO, los valores (o estados) de los objetos complejos se pueden construir a partir de otros objetos mediante ciertos constructores de tipos. Una forma de representar tales objetos es considerar a cada objeto como tripleta (i, c, v), donde i es un identificador de objeto único (el OID), c es un constructor (esto es, una indicación de cómo se construye el valor del objeto) y v es el valor (o estado) del objeto. Puede haber varios constructores, según el modelo de datos y el sistema OO.

Los tres constructores  básicos son:

Ø      constructores de átomos.

Ø      constructores de tuplas.

Ø      constructores de conjuntos.
 

Otros constructores de uso más común son los de listas y de arreglos. También existe un dominio D que contiene todos los valores atómicos básicos que están disponibles directamente en el sistema. Por lo regular estos incluyen los enteros, los números reales, las cadenas de caracteres, los tipos boléanos, las fechas y cualesquiera otros tipos de datos que el sistema maneje directamente.

C.  ENCAPSULAMIENTO:
 
Tanto la estructura de los objetos como las operaciones que se pueden aplicar a ellos se incluyen en las definiciones de clases de los objetos.
 

D.  COMPATIBILIDAD CON  LENGUAJES DE PROGRAMACION

Si se sigue el enfoque cuando se utilizan los diagramas de Entidad-Relación para modelar los datos y luego se convierten de manera manual en un conjunto de relaciones; por lo tanto los conceptos de la Programación Orientada a Objetos se utilizan simplemente como herramientas de diseño y se codifican, utilizándose para trabajar  con una base de datos.

Hay varios lenguajes posibles en los que se pueden integrar estos conceptos:
 

Ø      Una opción es extender un lenguaje para el tratamiento de datos como el SQL añadiendo tipos complejos y la programación orientada a objetos. Los sistemas proporcionan extensiones orientadas a objetos a los sistemas relacionales se denominan sistemas relacionales orientados a objetos.

 

Ø      Otra opción es tomar un lenguaje de programación orientado a objetos ya existente y extenderlo para que trabaje con las bases de datos. Estos lenguajes se denominan lenguajes de programación persistentes. Estos lenguajes permiten a los programadores trabajar directamente con los datos, desde el lenguaje de programación; sin tener que pasar por un lenguaje para el tratamiento de datos como SQL. Se denominan persistentes porque los datos  siguen existiendo una vez que el programa que los creó ha concluido.

 

Ø      A la hora de decidir que opción utilizar se debe tener en cuenta que  los Lenguajes Persistentes suelen ser potentes y resulta relativamente sencillo cometer errores de programación que dañen las vases de datos. La complejidad de los lenguajes hace la optimización automática de alto nivel, como la reducción de E/S de disco, resulte dificil. En muchas aplicaciones, la posibilidad de las consultas declarativas es de gran importancia, pero los lenguajes persistentes no permiten actualmente las consultas declarativas sin que aparezcan problemas de algun tipo.

 

E.  JERARQUIA DE TIPOS Y HERENCIA

Los esquemas de BDOO suelen necesitar un gran número de clases. Sin embargo, varias clases son parecidas entre sí.

Para permitir la representación directa de parecidos entre las clases, hay que ubicarlas en una jerarquía de especializaciones. El concepto de jerarquía de clases es parecido al de especialización del modelo E-R. Las especializaciones de las clases son denominadas subclases; lo cual especifica atributos y métodos adicionales para una clase existente. Los objetos creados por medio de una sub clases heredan todos los atributos y  métodos de la clase padre. Algunas de estas características heredadas pueden ellas mismas haber sido heredadas de clases más altas en la jerarquía.  Ejemplo:

 

 

Ejemplo: (Grafico)

Class persona {
          string nombre;
          strin  dirección;
};
Class cliente isa persona {
          int interés-prestamo;
};
Class empleado isa persona{
          date fecha de alta;
          int  sueldo;
};
Class  secretaria isa empleado {
           int  velocidad;
           int horas-trabajadas
 

F. MANEJO DE OBJETOS COMPLEJOS

Los objetos se consideran complejos porque requieren un área de almacenamiento sustancial y no forman parte de los tipos de datos estándar que suelen ofrecer los SGBD. Puesto que el tamaño de los objetos es considerable, un SGBD podría obtener una porción del objeto y proporcionarla al programa de aplicación antes de obtener todo el objeto. El SGBD podría también usar técnicas de almacenamiento intermedio y caché para obtener por anticipado porciones del objeto, antes de que el programa de aplicación necesite tener acceso a ellas.

En un SGBOO, esto puede lograrse definiendo un nuevo tipo de datos abstracto para los objetos no interpretados y suministrados los métodos para seleccionar, comprar y exhibir tales objetos.

Como un SGBOO permite a los usuarios crear nuevos tipos, y como un tipo incluye tanto estructura como operaciones, podemos considerar que un SGBOO tiene un sistema de tipos extensibles. Podemos crear bibliotecas  de nuevos tipos definiendo su estructura y operaciones, incluso con tipos complejos.

Muchos SGBDOO pueden almacenar y obtener objetos no estructurados extensos en forma de cadenas y caracteres o de bits, que se pueden pasar “tal cual” al programa de aplicación para que las interprete.

Es posible almacenar y manipular objetos complejos tanto
estructurados como no estructurados.

G. POLIMORFISMO

El polimorfismo se refiere al uso de la misma firma de mensaje para dirigir diferentes métodos en diferentes clases. Cuando el diseñador envía una señal a un objeto, el método de la clase de objeto, posiblemente heredado, procesa la señal.

Un método puede tener acceso directamente a atributos de un objeto destino por no nombre, al incluir cualesquiera atributos heredados de clases padres, pero debe tener acceso a atributos de otros objetos con señales secundarias.

En síntesis este concepto permite enlazar el mismo nombre o símbolo de operador a dos o más implementaciones diferentes del operador, dependiendo del tipo de objetos a los que éste se aplique.

EJEMPLO:

OBJETO_GEOMETRICO: Forma, Area, PuntoCentral

RECTANGULO subtype_of OBJETO_GEOMETRICO  (Forma=´rectángulo’): Ancho, Altura

TRIANGULO subtype_of OBJETO_GEOMETRICO (Forma=´triángulo’): Lado1, Lado2, Angulo

CIRCULO subtype_of OBJETO_GEOMETRICO(Forma=´círculo’): Radio
 

H. CREACION DE VERSIONES

Muchas aplicaciones de bases de datos que usan sistemas OO requieren la existencia de varias versiones del mismo objeto.

Por lo regular, se aplican actividades de mantenimiento a un sistema de software conforme sus requerimientos evolucionan. Por lo regular,  el mantenimiento implica modificar algunos de los módulos de diseño y de implementación. Si el  sistema ya está en operación, y si es preciso modificar uno o más módulos, el diseñador deberá crear una nueva versión de cada uno de ellos para efectuar cambios.

Cabe señalar que puede haber más de dos versiones de un objeto.

En caso que se requieran dos versiones, además del módulo original. Se puede actualizar concurrentemente las propias versiones del mismo módulo del software. Esto se llama ingeniería concurrente. Sin embargo, siempre llega el momento en que es preciso combinar (fusionar) estas dos versiones para que la versión hibrida incluya los cambios realizados. Es necesario de que sus cambios sean compatibles.

Un objeto complejo, como  un sistema de software, puede constar de muchos módulos. Cuando se permite la creación de múltiples versiones, es posible que cada una de esos módulos  tenga varias versiones distintas y un grafo de versiones.

Como se deduce del análisis anterior, un SGBDOO debe ser capaz  de  almacenar  y  controlar  múltiples  versiones  del mismo objeto.

 

 

 

 

 

 

 

 

 

About these ads

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

A %d blogueros les gusta esto: