Algunos SGBDOO

A lo largo del tiempo han ido surgiendo diversos Sistemas Gestores de Bases de Datos Orientadas a Objetos, entre los más destacados se pueden enlistar los siguientes:

GemStone (http://www.gemstone.com/)

Fue de los primeros manejadores de bases de datos orientados a objetos, incluso el más puro que existe. GemStone está basado en una extensión de Smalltalk llamada OPAL, el cual puede manejar objetos persistentes y no requiere de un lenguaje de programación en específico (a diferencia de la mayoría).

El creador de GemStone, Servio Logic Corporation, la ha enfocado principalmente a aplicaciones CAD/CAM. Es el producto con más tiempo en el mercado y de los más maduros que existen 

 OPAL dispone de una biblioteca que abarca características como abstracción, herencia e identidad, pero no admite herencia múltiple. Así mismo un problema menor de GemStone es que su lenguaje de acceso construye las consultas y los índices usando atributos de objetos, lo que se puede usar para violar la seguridad del encapsulamiento. Se le puede dar, opcionalmente, un tipo o clase a los atributos, pero no se impiden fallos en la ejecución debido al polimorfismo.

Está basado en arquitectura cliente-servidor y además admite la distribución. La Stone (piedra) es el servidor de la base de datos (el administrador de objetos), y se accede a él a través de múltiples versiones de Gem (gema), una máquina virtual que compila y ejecuta métodos OPAL, GemStone también almacena los métodos directamente en la base de datos, y gracias a toda esta estructura, se logra que se pueda usar con casi cualquier lenguaje.

Aún con su robustez GemStone también carece de un modelado semántico de datos como estructuras de agragación, excepciones, reglas, limitaciones, activadores, soporte para atributos multivaluados, relaciones de conjuntos, relaciones uno-a-uno, inversa de relaciones y claves. A los programadores Smalltalk les resulta fácil usar GemStone, pero para otros les puede ser útil GeODE (GemStone Objet Development Environment) que es un lenguaje de cuarta generación que tiene una potente herramienta para la creación de formularios y diseño de esquemas, consultas interactivas y en general, un lenguaje de programación ligeramente visual.

Proximos en un par de horas :)

Sistemas Gestores de Bases de Datos Orientadas a Objetos (SGBDOO)

El

El Modelo Orientado a Objetos (MOO) / Objet Oriented Data Model (OODM)

El Modelo de Datos Orientado a Objetos (OODM) es la base del Modelo de Base de Datos Orientada a Objetos (OODBM) y el cual es manejado por un Sistema de Administración de Bases de Datos Orientado a Objetos (OODBMS). Aunque todos los autores coinciden en considerar como idea fundamental del paradigma orientado a objetos la integración de datos y procesos, no existe un modelo estándar como en el caso del modelo relacional.


En la orientación a objetos, un sistema se concibe como un conjunto de objetos que se comunican entre si mediante mensajes. Tradicionalmente los datos y procedimientos  se almacenan por separado, 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 procedimientos de una entidad con sus datos, es decir,  el comportamiento es parte de la entidad en sí, por lo que en cualquier lugar en que se utilice, se comporta de un modo predecible y conocido.


LA ORIENTACIÓN A OBJETOS EN PROGRAMACIÓN

En palabras sencillas, la programación orientada a objetos intenta simplificar la complejidad y representar de forma simple las actividades. Los conceptos del paradigma de orientación a objetos en programación guardan una estrecha relación con el de las bases de datos, pues básicamente es una extensión del mismo.Estos conceptos involucran:

• OBJETO: Es una entidad que almacena atributos, variables o propiedades; que pueden realizar acciones, que se denominan métodos, servicios, funciones, procedimientos u operaciones.
  Los objetos solo dan información sobre sí mismos a través de los métodos que poseen para compartir su información; y aunque ocultan la implementación de sus procedimientos se les puede pedir que los ejecuten. De esta manera, tanto usuarios como aplicaciones no pueden ver que hay dentro dentro de los métodos, solo pueden ver los resultados de ejecutarlos, lo que también se conoce como ocultación de información o encapsulamiento. Para pedir datos a un objeto o que éste realice una acción, se le debe enviar un mensaje.
  
  Es decir, un programa orientado a objetos es un conjunto de objetos que tienen atributos y métodos y que interactúan entre si enviándose mensajes.
  
  Los objetos persistentes son aquellos que siguen existiendo después de que concluye una sesión, pues de lo contrario un objeto después de ser creado en memoria, es destruido, es decir, los objetos del programa desaparecen cuando el programa termina su ejecución. La forma de hacer que alguno de ellos tenga persistencia es que se almacene en una Base de Datos (preferentemente orientada a objetos), para lo cual se requiere un "Identidad de objetos", es decir, un identificador único para poder diferenciarlos.
  
  Por ejemplo, cuando un niño comienza a hablar es porque entiende conceptos de "objetos" empezando a nombrar las "cosas" como agua, perro, casa, mamá, etc.; los cuales poseen sus propiedades únicas, como el perro que tiene nombre, color, sexo, etc., éstos son sus "atributos". Así nos damos cuenta que no tenemos un completo control sobre los objetos y que aunque no queramos que un perro ladre, lo hará, ya que cada uno posee una "programación" que le dice como reaccionar ante determinados estímulos o situaciones "métodos". Es así como los objetos pueden ser de un cierto tipo (perro o gato), pertenecer a cierta familia (mamíferos) y ser únicos (Mi perro puppy).
  En la oración "Micaela, de 5 años, dice: Mira el perro negro y blanco, se llama Tito, le toco la cabeza y mueve la cola, y si le doy de comer, al rato, hace caca". Por lo tanto:
• El objeto es de tipo "Perro"
• "es de color negro y blanco", por lo que el color es un atributo del objeto perro
• "reacciona si le tocan la cabeza", es decir, el comportamiento ante un estimulo externo
• "mueve la cola", tiene acciones
• "come", una acción que se relaciona con su exterior e interior
• "hace caca", otra acción que está relacionada con su interior y que en algún momento se exterioriza de alguna forma
• "Micaela" es otro objeto que existe en un contexto donde se permite la interacción con "Perro".

• (Programación orientada a objetos para PHP5, Enrique Place,  http://phpsenior.blogspot.mx/2009/02/disponible-el-libro-poo-para-php5.html )

• ENCAPSULAMIENTO: Cada objeto contiene y define los procedimientos (métodos) y la interfaz mediante la cual se puede acceder a él y otros objetos que pueden manipularlo. La interfaz de un objeto consiste en un conjunto de operaciones que pueden ser invocadas sobre el objeto. El estado de un objeto (atributo) es manipulado mediante los métodos invocados por las operaciones correspondientes.

• CLASE: Es una plantilla en la que se basan objetos que similares. Cuando una aplicación 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.
  Existen 3 tipos de clases:
  
  • Clases de control: Gestionan el flujo de operación de un programa (por ejemplo el proceso para hacer una actividad).
  • Clases de entidad: Usadas para crear objetos que manejan datos (por ejemplo una clase para crear una persona).
• Clases de interface: Manejan la entrada y salida de información (por ejemplo los menús y apariencia de las ventanas).Muchas aplicaciones orientadas a objetos manejan un cuarto tipo:
• Clase contenedor: Contienen o manejan múltiples objetos creados a partir del mismo tipo de clase, manteniéndolos en orden, listandolos o incluso permitir búsquedas en ellos. Los SGBD suelen llamarlos extents (extensiones).
Las clases se organizan en una jerarquía de clases (parecido a un árbol invertido), donde cada clase tiene un solo padre.

Por ejemplo la clase "CLIENTE" y la clase "EMPLEADO" comparten una clase "PERSONA" padre. Como se indica al comienzo, es una plantilla para crear objetos similares, es decir tanto cliente como empleado también son persona y comparten ciertos atributos como podría ser que tienen 2 manos y 2 pies, cerebro, etc.

• HERENCIA: Cuando se necesita trabajar con clases que son similares pero no idénticas, se usa la herencia, es decir, que una clase puede tener varias subclases que contengan los atributos indicados en la súperclase. No todas las clases se utilizan para crear objetos, pues algunas solo ocupan los atributos o métodos de sus súperclases; para el caso de las clases que se utilizan para crear objetos se denominan clases concretas.
  
  Por ejemplo la clase "ANIMAL" (que tiene los atributos, raza, edad y tamaño) tiene las subclases "PERRO" (con atributos nombre y color) y "GATO" (con el atributo dueño), por lo que se puede saber las raza del "perro" al tener "animal" como súperclase
  
  
  
  
  HERENCIA MÚLTIPLE: Cuando una clase hereda atributos de más de una súperclase.

  
  

  
  

  
  

  
  
• MÉTODO: Es el que define el comportamiento de los objetos. Tiene un cuerpo y un encabezado; el encabezado contiene nombre, argumentos o parámetros y tipo de resultado esperado; mientras que el cuerpo contiene la lógica de implementación según el lenguaje a usar. Estos métodos son reutilizables y hay varios que son comunes a la mayoría de las clases:
• Constructores: Tiene el mismo nombre que la clase y se ejecuta al crear un objeto de una clase. Contiene las instrucciones para inicializar las variables de un objeto.
• Destructores: Método usado para destruir un objeto.
• Accesores: Método que devuelve el valor de un atributo privado de otro objeto. Esta es la forma que se usa para que los objetos externos accedan a datos encapsulados.
• Mutadores: Método que almacena un nuevo valor en un atributo. Esta es la forma que se usa para que los objetos externos puedan modificar los datos encapsulados.

• POLIMORFISMO: Significa que el mismo comportamiento que es conocido por un nombre, puede ser implementado o completado de maneras distintas para diferentes subclases.

Por ejemplo, el método "CERRAR" puede ser implementado de una forma para "VENTANA" (deslizar para cerrar), y de otra forma para "PUERTA" (girar para cerrar).

CÓMO NOMBRAR A LOS ATRIBUTOS CLASES Y MÉTODOS

En orientación a objetos se maneja una formalidad para nombrar a las clases, los métodos y atributos:

• Clases: Empieza con letra mayúscula seguida de minúsculas. Si hay más de una palabra, se pueden separar con subrayado o quitar los espacios y poner la primera letra de cada palabra en mayúsculas.
  
  Ejemplo: Materia_prima o MateriaPrima
• Atributos y métodos: Empiezan por minúsculas. Si hay más de una palabra, se pueden separar con subrayado o quitar los espacios y poner la primera letra de cada palabra en mayúsculas.
  
  Ejemplo: num_empleado o NúmEmpleado
• Accesores: Empiezan con la palabra "get" seguida del nombre de atributo al que acceden.
  
  Ejemplo: getEmpleado
• Mutadores: Empiezan con la palabra "set" seguida del nombre del atributo al que acceden.
  
  Ejemplo: setEmpleado

VENTAJAS Y DESVENTAJAS SOBRE EL MODELO ENTIDAD-RELACIÓN

Entre las VENTAJAS que se pueden destacar se encuentran:

1. Agrega contenido semántico: Facilita el entendimiento en el modelo, dándole un mayor significado.
2. La presentación visual incluye contenido semántico: Modela visualmente las relaciones pero le agrega contenido semántico en la representación visual de los objetos, facilitando el entendimiento de relaciones complejas dentro y entre objetos.
3. Integridad de la base de datos: Se incluye herencia para proteger la integridad pero también se incluyen más tipos de relaciones y mucho más complejas.
4. Independencia estructural de los datos: La autonomía de los objetos garantiza la independencia de la estructura y también de los datos.

Por contraparte, entre las DESVENTAJAS que hacen que el modelo E-R este por delante, se encuentran:

1. Carencia de estándares de OOBM: No existe un estándar para el modelo de datos orientado a objetos, por ejemplo, no existe una estandarización en la forma de acceso a los datos, lo que provoca problemas de incopatibilidad de sistemas.
2. Acceso navegacional a los datos complejos: El acceso a los datos se parece al modelo jerárquico y de red.
3. Curva de aprendizaje pronunciada: El hecho de que puedan contener tanto contenido semántico los hace difíciles de diseñar y ejecutar, e incluso al usuario final le hace parecer difícil de operar.
4. Alta complejidad del sistema que hace lentas las transacciones: Su ejecución implica gastos indirectos de hardware y sistema operativo. La complejidad del ambiente y elevados requerimientos tienden a hacer lentas las transacciones, algo que es inaceptable.

Las Bases de Datos Orientadas a Objetos (BDOO)

Las tradicionales bases de datos inicialmente fueron creadas para aplicaciones que procesaran una gran cantidad de volúmenes, bajo cierta estructura. Es así como a lo largo del tiempo los modelos para el manejo de grandes volúmenes de datos ha ido evolucionando, desde las Bases de Datos Jerárquicas pasando por las Bases de Datos Relacionales hasta las Bases de Datos Orientadas a Objetos.

Por ejemplo en el caso de las Bases de Datos Relacionales, la tabla es simple y comprensible, los métodos para manipular sus datos son conocidos y eficaces, incluso se facilita la posibilidad de unir los datos de diversas tablas; por lo que este modelo es adecuado para aplicaciones de contabilidad o otras aplicaciones en donde los datos son simples y escasos en números. Sin embargo, el modelo relacional dificulta expresar la semántica de objetos complejos, ya que los Sistemas de Gestión de Bases de Datos Relacionales son realmente para datos de registros (tuplas).

En los 90's las nuevas aplicaciones requerían manipular estructuras de datos complejas y grandes así como un alto rendimiento. Fue así como se vio la necesidad de soportar la orientación a objetos en una base de datos que interactúa con aplicaciones igualmente exigentes que han sido desarrolladas con programación orientada a objetos. Es por ello que hoy en día el modelo orientado a objetos es una de las vías más prometedoras en el desarrollo de software, pues a pesar de que la fase inicial de análisis es larga, la cantidad de código es menor facilitando su mantenimiento y reutilización, lo que involucra una reducción en costos.
En otras palabras, las bases de datos tradicionales son difíciles de utilizar cuando la aplicación que accede a ellas está desarrollada bajo un lenguaje de programación orientado a objetos.


UNA LINEA DEL TIEMPO

La primera generación de Sistemas Gestores de Bases de Datos Orientadas a Objetos (SGBDOO) data de 1986 cuando la compañia Graphael lanza G-Base, en 1987 Servio Corp introdujo GemStone, luego en 1988 Ontologic lanza su sistema VBase y la empresa Simbolics lanza Statice. Todos ellos con la finalidad de apoyar lenguajes persistentes como los usados para la inteligencia artificial.

La segunda generación se caracterizó por emplear una arquitectura cliente-servidor, y puede considerarse a partir del lanzamiento de Ontos en 1989, así como de Objet Design, Objectivity y de Versant Objet Technology,

Una tercera generación fue marcada por la salida al mercado de Itasca en 1990, que es una versión comercial de Orion, otros ejemplos son O2 de la compañia Altair así como Zeitgeist creado por Texas Instruments. De igual manera lo que marcó la tercera generación fue que ya se manejaban lenguajes de definición y manipulación de datos orientados a objetos (DDL/DML).


¿POR QUÉ EXISTEN LAS BDOO?

Básicamente las bases de datos orientadas a objetos fueron creadas para tener una interfaz limpia con un lenguaje de programación orientado a objetos también, donde la aplicación que requiera la flexibilidad  de una base de daros relacional que no tiene un rendimiento adecuado. La razón radica en que prácticamente las BDOO pueden ser 100 veces más rápidas para ciertos tipos de aplicaciones.

También se ha demostrado que mientras la vía orientada a objetos requiere una larga fase inicial de análisis, la mayoría de los proyectos de desarrollo de software son más cortos y requieren menos personas. Incluso también se ha descubierto que la cantidad de código es significativamente menor; y además algo muy notable es que se puede prever una reducción drástica en la cantidad de código y un aumento en su reutilización que tendrá efecto en la reducción de costos.

Los sistemas de bases de datos relacionales ofrecen lenguajes de acceso no basados en procedimientos, es decir declarativos (por ejemplo: select * from clientes; indica específicamente qué, de dónde y cómo se obtienen los datos ). En cambio los sistemas orientados a objetos son principalmente basados en procedimientos y no declarativos, lo que requieren menos optimizaciones pero más eficiente para consultas de objetos complejos.