6. Object-Oriented Databases


6.1 Object Oriented


6.1.1 Definición

El primer modelado fue relacional, los DBMS lo implementaban ampliamente en RDBMS, cuando surgieron los lenguajes orientados a objetos como C++ o Java se pensó en una manera de plantear ese paradigma en bases de datos, finalmente si se programaba en un leguaje orientado a objetos, los más natural sería almacenar esa información de la misma forma.

  • Una base de datos orientada a objetos es una colección de objetos persistentes con un propósito común.
  • Objetos: instancias de una clase, abstracción de "algo" de la realidad
  • Persistentes: "sobreviven" en el tiempo a la ejecución de un programa

 

class Movie
        (extent Movies key (title, year))
{
       attribute string title;
       attribute integer year;
       attribute integer length;
       attribute enum Film {color, b&w} filmType;
       relationship Set<Star> stars
                         inverse Star::starredIn;
       relationship Studio ownedBy
                         inverse Studio::owns;
       float lengthInHours() raises(noLengthFound);
       void starNames(out Set<String>);
       void otherMovies(in Star, out Set<Movie>)
                         raises(noSuchStar);
};

class Star
        (extent Stars key name)
{
       attribute string name;
       attribute struct Addr
                         {string street, string city} address;
       relationship Set<Movie> starredIn
                         inverse Movie::stars;
};

class Studio
        (extent Studios key name)
{
       attribute string name;
       attribute string address
       relationship Set<Movie> owns
                         inverse Movie::ownedBy;
};

 

6.1.2 Diferencias entre RDBMS y OODBMS

RDBMS OODBMS
  • Tablas normalizadas y restricciones de integridad: identidad y referencial
  • El esquema conceptual corresponde a base de
    datos empresarial y la aplicación explota a través de su esquema externo
  • Puede iniciarse una consulta a partir de cualquier relación derivable de las relaciones representadas por las tablas de la base de datos.
  • Busca una representación independiente de las aplicaciones que explotan la base de datos
  • Ofrece a las diferentes arquitecturas de aplicaciones una interfaz común: SQL
  • Objetos complejos: contienen colecciones de objetos o referencias a
    otros objetos
  • El objeto persistente tiene la misma estructura que su versión transiente
  • Requiere la definición de objetos distinguidos que fungen como puntos de acceso a partir de los cuales es posible acceder al resto de los objetos
  • Las aplicaciones deben conocer los puntos de entrada.
  • Busca la equivalencia entre la estructura de los objetos en la base de datos y los objetos utilizados en las aplicaciones.
  • Requiere un API específico para un lenguaje orientado a objetos o bien, si está disponible, OQL




6.1.3 Características deseables en ambos tipos de DBMS

  • Acceso a la base de datos a través de un servidor
  • Acceso concurrente de múltiples procesos cliente
  • Consultas y transacciones tanto locales como distribuidas
  • Capacidad de recuperación de fallas
  • Seguridad
  • Respaldos en línea, auditoría

 

6.1.4 Ejemplos de OODBMS


6.1.5 ObjectStore

6.1.5.1 Introducción

Instrumentación de OODBMS que cubre las características deseables con alto desempeño y en sistemas abiertos:

  • Servidor distribuido, con administración de replicación
  • Respaldo y recuperación en línea
  • Seguridad
  • Control total de acceso concurrente
  • API's multilenguaje: Java, C++, ActiveX

6.1.5.2 ObjectStore: metas de diseño

  • Relaciones complejas en objetos de las aplicaciones:
    • Rutas de navegación profunda
    • Agrupación de objetos con alta cohesión
    • Objetos compartidos por múltiples usuarios
  • Extendible y escalable
    • Optimiza el acceso repetido a objetos
    • Posibilidad de definir en métodos las rutas de acceso más importantes
  • Adaptación a requerimientos de negocio cambiantes
    • Integración de nuevos casos de uso y componentes
    • Arquitectura flexible, con múltiples participantes
  • Enfasis en velocidad, integridad y disponibilidad
    • Maximiza el aprovechamiento de disco, RAM y uso del procesador

 

6.1.5.3 ObjectStore: Modelo de persistencia

  • Persistencia ortogonal al tipo
    • La misma clase es transiente y persistente
    • Utiliza los métodos de la clase sin cambios
  • Sincronización transparente entre objetos de la aplicación y almacenados en la base de datos
    • Recuperación de objetos automática, por demanda de la aplicación
    • Vaciado automático de las actualizaciones a la base de datos
    • Recuperación y consistencia determinada por fronteras transaccionales

Impacto en el lenguaje:

SQL: SELECT * FROM a, b WHERE a.id =b.ida
OS: a.b

SQL: INSERT INTO a VALUES (x,y)
OS: new a(x,y)

SQL: UPDATE a SET a.d=x
OS: a.d=x

SQL: DELETE FROM a WHERE a.id=x
OS: ¡Noesnecesario! (Garbagecollection)


6.1.5.4 ObjectStore: Arquitectura

 

6.1.5.5 ObjectStore: Modelo transaccional

  • Soporte a transacciones serializables
  • Controladas programáticamente a través de los métodos begin,commit y abort de la clase Transaction del paquete com.odi.
  • Las transacciones deben ejecutarse en el contexto de una sesión creada con el método create de la clase com.odi.Session, para la cual se enlaza un thread, con el método join.
  • Una sesión puede tener cero o a lo más una transacción.



El modelo transaccional garantiza que:

  • Todos los cambios confirmados (commited) a objetos persistentes queden salvados en disco
  • Si la transacción aborta, todos los cambios hechos a objetos persistentes desde el inicio de la transacción son descartados (rolledback).
  • Otros usuarios pueden acceder a los datos confirmados.
  • ObjectStore bloquea automáticamente, no se requiere código adicional explícito.
  • Los bloqueos se mantienen hasta que la transacción concluye.
  • Puede efectuarse un bloqueo retardado (LazyLock) para reducir el overhead.
  • En transacciones que involucran dos o más bases de datos, se utiliza en protocolo de Two Phase Commit para asegurarla
    integridad distribuida.
  • Se cuenta con espera por bloqueos y detección de deadlocks interconstruida.

 

Fin de una transacción

  • Commit
    • Todos los objetos transientes referidos por objetos persistentes se hacen a su vez persistentes.
    • Todos los objetos persistentes son vaciados a la base de datos.
    • Los bloqueos se liberan.
    • Se revisa la materialización de los objetos dependiendo del modo de retención definido para el commit (stale,hollow,read-only)
  • Abort
    • Los cambios hechos desde el inicio de la transacción son revertidos.
    • Los bloqueos se liberan.
    • Los objetos persistentes quedan en modo de retención stale.
    • Los cambios hechos en objetos transientes deben revertirse en forma explícita

 

6.1.5.6 Ejemplos del API de ObjectStore

 

6.2 Object-Relational Model

 

6.2.1 Antecedentes

Las bases de datos orientadas a objetos tuvieron gran auge durante los 90's pero luego todos los OODBMS se desplomaron. Como se predijo alrededor de 1990, los vendedores de DBMS comerciales hicieron una mezcla que permitiera utilizar los aspectos del modelo relacional y del orientado a objetos, resultando el modelo "object-relational", surgiendo así los ORDBMS.

Las OR databases incorporan:

  • Structured types for attributes
  • Methods
  • Identifiers
  • References

6.2.2 Ejemplo de ORDBMS

  • Oracle
  • DB2

 

6.2.3 Ejemplos de ORDBMS usando Oracle

create type ADDRESS_TY as object
(Street VARCHAR(50),
City     VARCHAR(25),
State   CHAR(2),
Zip     NUMBER);

create type PERSON_TY as object
(Name    VARCHAR(25),
Address  ADDRESS_TY);

create table CUSTOMER
(Customer_ID     NUMBER,
Person               PERSON_TY);

insert into CUSTOMER values
(1,
  PERSON_TY('NEIL MULLANE',
                     ADDRESS_TY('57 MT PLEASANT ST',
                                          'FINN', 'NH', 11111)));

select Name
     from CUSTOMER          /*ERROR*/

select Customer_ID, C.Person.Name
     from CUSTOMER C;

C.Person.Name    =     Correlation.Column.Attribute

 

6.3 OQL (Object Query Language)

SELECT m.year
FROM Movies m
WHERE m.title = "Titanic

SELECT s.name
FROM Movies m, m.stars s
WHERE m.title = "Casablanca "

SELECT DISTINCT s.name
FROM (SELECT m
         FROM Movies m
        WHERE m.ownedBy.name = "Disney") d,
         d.stars s

AVG(SELECT m.length FROM Movies m)

CREATE METHOD houseNumber() RETURNS CHAR(10)
FOR AdrdressType
BEGIN
         .....
END