6. Object-Oriented Databases

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 orie ntados 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
Objetos complejos: contienen colecciones de objetos
Tablas normalizadas y restricciones de integridad:
o referencias a
identidad y referencial
El esquema conceptual corresponde a base de
otros objetos
El objeto persistente tiene la misma estructura que
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
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
Jasmine http://www.ca.com/
Poet http://www.x-solutions.poet.com/eu/
Gemstone http://www.gemstone.com/
Versant http://www.versant.com/en_US/products/objectdatabase
ObjectStore http://www.progress.com/objectstore/index.ssp
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 descar tados
(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,re ad-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