Modelo de Base de Datos Orientado a Objetos

 El paradigma orientado a objetos está basado en el encapsulamiento de los datos y del código relacionados con cada objeto en una sola unidad cuyo contenido no es visible desde el exterior. Conceptualmente, todas las interacciones entre cada objeto y el resto del sistema se realizan mediante mensajes. Por tanto, la interfaz entre cada objeto y el resto del sistema se define mediante un conjunto de mensajes permitidos. En general, cada objeto está asociado con
• Un conjunto de variables que contiene los datos del objeto; las variables se corresponden con los atributos del modelo E-R. 
• Un conjunto de mensajes a los que responde; cada mensaje puede no tener parámetros, tener uno o varios. 
• Un conjunto de métodos, cada uno de los cuales es código que implementa un mensaje; el método devuelve un valor como respuesta al mensaje.
El término mensaje en un entorno orientado a objetos no implica el 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 concretos de su implementación. Se utiliza a veces la expresión invocar a un método para denotar el hecho de enviar un mensaje a un objeto y la ejecución del método correspondiente

Clases de objetos

Generalmente, en una base de datos hay muchos objetos similares. Por similar se entiende que responden a los mismos mensajes, utilizan los mismos métodos y tienen variables del mismo nombre y del mismo tipo.

El concepto de clases es parecido al concepto de los tipos abstractos de datos. Sin embargo, hay varios aspectos adicionales en el concepto de clase respecto al de tipos abstractos de datos. Para representar estas propiedades adicionales, cada clase se trata como si fuera un objeto. Un objeto clase incluye
• Una variable de tipo conjunto cuyo valor es el conjunto de todos los objetos que son ejemplares de la clase. 
• La implementación de un método para el mensaje nuevo, que crea un nuevo ejemplar de la clase.

Herencia

Los esquemas de las bases de datos orientadas a objetos suelen necesitar gran número de clases. Frecuentemente, sin embargo, varias de las clases son parecidas entre sí. Por ejemplo, supóngase que se tiene una base de datos orientada a objetos en la aplicación bancaria. Cabe esperar que la clase de los clientes del banco sea parecida a la clase de los empleados en que ambas definan variables para nombre, dirección, etcétera. Sin embargo, hay algunas variables específicas de los empleados (sueldo, por ejemplo) y otras específicas de los clientes (interés-préstamo, por ejemplo). Sería conveniente definir una representación de las variables comunes en un solo lugar. Esto sólo puede hacerse si se combinan los empleados y los clientes en una sola clase.  

Herencia múltiple

La herencia múltiple permite a las clases heredar variables y métodos de múltiples superclases. La relación entre clases y subclases se representa mediante un grafo acíclico dirigido(GAD) en el que las clases pueden tener más de una superclase. Por ejemplo, supóngase que los empleados pueden ser contratados por horas (para un periodo limitado) o bien a tiempo completo. Se pueden crear las subclases por-horas y a-tiempo-completo de la clase empleado. La subclase por-horas tendría un atributo último-día que especifica cuándo concluye el periodo de empleo. La subclasea-tiempo-completopuede tener un método para el cálculo de las contribuciones al plan de pensiones de la compañía, que no es aplicable a los empleados por horas. La clasificación expuesta de empleados como temporal y a tiempo completo es independiente de la clasificación basada en el trabajo que ellos realizan, es decir, administrativo, cajero, o secretario. Se podrían tener administrativos a tiempo completo, administrativos por horas, cajeros a tiempo completo y cajeros por horas. Usando la herencia múltiple, simplemente se crea una nueva clase, tal como cajero-por-horas, que es una subclase de por-horas y de cajero, y cajero-atiempo-completo, que es una subclase de a-tiempo-completo y de cajero. La combinación que no puede ocurrir en la vida real no necesita ser creada; por ejemplo, si todos los administrativos son a tiempo completo, no es necesario crear una clase de administrativos por horas.  La jerarquía de clases resultantes aparece en la siguiente Figura.

Identidad de los objetos

Los objetos de las bases de datos orientadas a objetos suelen corresponder a entidades del sistema modelado por la base de datos. Las entidades conservan su identidad aunque algunas de sus propiedades cambien con el tiempo. De manera parecida, los objetos conservan su identidad aunque los valores de las variables o las definiciones de los métodos cambien total o parcialmente con el tiempo. Este concepto de identidad no se aplica a las tuplas de las bases de datos relacionales. En los sistemas relacionales las tuplas de una relación sólo se distinguen por los valores que contienen. La identidad de los objetos es un concepto de identidad más potente que el que suele hallarse en los lenguajes de programación o en los modelos de datos que no se basan en la programación orientada a objetos.

Fuente: FUNDAMENTOS DE BASES DE DATOS
SILBERSCHATZ • KORTH • SUDARSHA