ndice

1. Evolucin e Historia de las BDs 2. BDOO: Motivacin 3. SGBDOO vs. SGBD de tercera generacin 3.1. Manifiesto de los SGBDOO 3.2. Manifiesto de los SGBD de 3 generacin 3.3. Productos y estndares 3.4. Convergencia 4. Caractersticas de los SGBDOO 4.1. Funcionalidades de la OO 4.2. Funcionalidades de un SGBD 4.2.1. Persistencia 4.2.2. Concurrencia 4.2.3. Procesamiento de consultas ad-hoc 4.2.4. Seguridad y control de acceso 4.2.5. Otras

BREVE HISTORIA de las BDs

Sistemas de archivos (1950s) BDs Jerrquicas y de Red (1960s) BDs Relacionales (1970-80s)

Se conservan los datos despus de que el proceso que los cre deja de existir Concurrencia, Recuperacin, rpido acceso, estructuras complejas, etc. Mayor confiabilidad, menor redundancia, ms flexibilidad, manejo de vistas, etc. Manejo de tipos de datos complejos, ms relaciones (agregacin, especializacin), un mismo lenguaje p/ BD y programacin, manejo de versiones, no es necesario reconstruir objetos, reusabilidad, etc.

ODBMS (1990s)

Evolucin de la tecnologa de BD: Dimensiones

FUNCIONALIDAD/ INTELIGENCIA

BD Activas BD Temporales BD Deductivas BD Seguras BD OO BD OR

BD Distribuidas Multi BD

RENDIMIENTO

BD
BD Paralelas BD en Memoria Principal BD Grid BD en Tiempo Real

BD Federadas
BDweb BD Mviles DISTRIBUCIN/ INTEGRACIN

1. Evolucin e Historia
1960 1970
Primeros productos de bases de datos Estndar Codasyl (Modelo de Red)

Modelo Relacional
Prototipos SGBDR Trabajos tericos relacionales Los tres niveles de la arquitectura (ANSI) Modelo E/R Primeros productos relacionales del mercado

1980

Arquitectura cliente/servidor de 2 capas Bases de datos distribuidas Estndares SQL (ANSI/ISO) Herramientas CASE Manifiesto sobre bases de datos orientadas a objetos Manifiesto sobre la 3ra generacin de Bases de datos Primeros productos de bases de objeto Modelos de referencia (ISO/ANSI) SQL 92 (Revisin mayor) Consorcio ODMG (Estndares OO) Almacenes de datos SQL:1999 (expres. regulares, consultas recursivas) Arquitectura Cliente/Servidor en tres capas Modelo Objeto-Relacional Bases de datos multimedia Bases de datos mviles SQL/MM (texto, espacial, imagen, minera de datos) Bases de datos XML, SQL: 2003 (XML)

1990

2000

1. Evolucin e Historia

Modelo Relacional Standard CODASYL

SQL Modelo E-R

ODMG 1.0

Hierarchical Network Relational Object-Oriented

Object-Relational
Semi-Structured XML

SQL:1999 XML

ODMG 3.0

SQL-86

ver>>>
ver>>>

1960

1970

1980

1990

2000

ndice

1. Evolucin e Historia de las BDs 2. BDOO: Motivacin 3. SGBDOO vs. SGBD de tercera generacin 3.1. Manifiesto de los SGBDOO 3.2. Manifiesto de los SGBD de 3 generacin 3.3. Productos y estndares 3.4. Convergencia 4. Caractersticas de los SGBDOO 4.1. Funcionalidades de la OO 4.2. Funcionalidades de un SGBD 4.2.1. Persistencia 4.2.2. Concurrencia 4.2.3. Procesamiento de consultas ad-hoc 4.2.4. Seguridad y control de acceso 4.2.5. Otras

Orgenes
OOPLs.
Base de Datos Orientadas a Objetos (BDOO)

tienen sus raices en el lenguaje SIMULA el cual fue introducido a finales de la decada de los 60.
SIMULA es una extensin de ALGOL 60.
Sin embargo, el primer lenguaje que populariz la aproximacin a objetos fue Smalltalk (1976); este puede considerarse una sntesis de Lisp y de Simula. En los aos 80, aparecen numerosos lenguajes OO inspirados en Simula o Smalltalk. Los ms clebres, entre los compilados, son C++ y Objective C. La mayora de los lenguajes OO interpretados son extensiones del Lisp; por ejemplo, Loops y Clos

Orgenes

Base de Datos Orientadas a Objetos (BDOO)

BDOO
El concepto de O.O. se vino a relacionar con las bases de datos a mediados de los 80, el termino "object-oriented database system" apareci por primera vez en el ao 1985

1. Evolucin e historia

Primeros sistemas
principio de los 1980s Won Kim en Microelectronics and Computer Technology Corporation (MCC) inicia el proyecto ORION. Dos productos surgen luego ITASCA y Versant. final de los 1980s 1ros productos comerciales. Graphael, un sistema basado en Lisp, aparece en Francia, de l surge luego Matisse. Servo-Logic comienza a trabajar en GemStone (ahora ServoLogic es GemStone Systems). Se inicia el desarrollo de O2 (en INRIA Francia). El fundador de O2 es Francois Bencilhon. Tom Atwood de Ontologic produce Vbase, luego Ontologic se convierte en ONTOS, y Vbase es re-escrito para soportar C++. Tom Atwood funda luego Object Design con ObjectStore (basado en C++). Otro producto de aquel tiempo es Objectivity/DB.

1. Evolucin e historia

Buscando establecer un estandar

1989 - The OODBMS Manifesto (ATKINSON ) Manifiesto de los Sistemas de Bases de Datos OO puras. Enfoque purista que sostiene que los SGBDOO deben soportar un modelo de objetos puros y no basarse en extensiones semnticas de modelos clsicos como el relacional. 1990 -Third Generation Database System Manifesto (STONEBRAKER) Considera: 1ra generacin de BD son jerrquica y Red; 2da generacin es Relacional y para la 3ra generacin (omite mencionarla como OO) establece una serie de proposiciones y principios. La idea bsica es que los SGBD de 3ra generacin deberan mantener las ventajas del modelo relacional, especialmente su DML no procedural, por lo tanto propone SGBD Relacionales extendidos que sean capaces de soportar los conceptos de orientacin a objeto. Postura que comparten los principales vendedores de productos relacionales. 1991 - ODMG Rick Cattell inicia el ODMG con 5 vendedores de OODBMS. El primer estandar ODMG-93 surge en 1993. Durante los 90s, el ODMG trabaja con el comit X3H2 (SQL) en un lenguaje query comn. Aunque no logran el objetivo, sus esfuerzos tuvieron influencia en OQL (object query language).

1. Evolucin e historia

Buscando establecer un estandar

1995 - El Tercer Manifiesto (DARWEN y DATE) Es un documento ms formal que los otros 2 manifiestos. Reinterpreta el modelo relacional bajo una visin orientada a objetos. Propone un lenguaje D con algunas ventajas de la OO como son los tipos de datos definidos por el usuario y la herencia, manteniendo el fundamento terico del modelo relacional. No se trata de una extensin del lenguaje SQL(opinan que SQL no es adecuado como base para el futuro lenguaje). Segn el manifiesto, tal lenguaje D, debe estar sujeto a una serie de prescripciones, proscripciones y lo que denomina sugerencias muy fuertes que divide en dos categoras: Las que surgen del Modelo Relacional (RM) Las que no surgen del Modelo de Objetos (OM) 2001 Aparicin del estandar ODMG 3.0 El estandar ODMG 3.0 en liberado. Poco despus el grupo ODMG da las bases para la especificacin de Java Data Objects (JDO) y luego el grupo se disuelve.

1. Evolucin e historia

Historia reciente
2004 El Advenimiento del cdigo abierto (Open Source) db4o es liberado como ODBMS de cdigo abierto. Para Noviembre de 2005, db4o es el primero en soportar Queries nativos (Native Queries). Posee una librera que trabaja directamente con objetos y permite realizar consultas usando lenguajes de programacin (Java/C#). No obstante existen en el mercado los llamados ORM (Object-Relational Mapping) para pasar las acciones que se realizan sobre objetos (guardar, leer, consultar, etc.) a su correspondiente secuencia SQL. Un ORM de los ms conocidos en el mercado es Hibernate (Hibernate mapea a los objetos con tablas del mundo relacional). Otros productos open source son, por ejemplo, EyeDB, NeoDatis ODB, Ozone, Perst, Zope (ZODB)

1. Evolucin e historia

Productos comerciales recientes (listado parcial)

Db4objects: versin comercial de db4o Objectivity/DB: Maneja BDs localizadas, centralizadas o distribuidas mediante una arquitectura de software escalable de procesamiento distribuido SOA (Arquitectura Orientada a Servicios) ObjectStore: Es un ODBMS (SGBDOO Puro) que anuncia solidez y alta performance para aplicaciones en ambientes empresariales. Versant Object Database: Es un ODBMS (SGBDOO Puro) que maneja objetos complejos modelados en java y C++, ofrece alta performance, escalabilidad, alta concurrencia, etc.

ObjectDB: Es una Base de Datos java pura, ObjectDB est escrita enteramente en java y cumple con el estandar JDO (Java Data Objects). Se ofrece como compacta, rpida y fcil de usar. Maneja BDs, desde unos pocos KBs hasta cientos de GBs. Trabaja tanto en modo embebido como en modo cliente-servidor.

1. Evolucin e historia

Productos comerciales recientes (continuacin..) GemStone: Es un SGBDOO Puro que ofrece las caractersticas propias de un ODBMS y extiende algunas de ellas para abordar la persistencia de objetos de manera diferente a las BDs tradicionales. Los objetos no son aplanados o serializados, sino que se almacenan como un todo. Matisse 8: Una base de datos .NET Matisse 8 es una BD Post-Relational que ofrece lo mejor de dos mundos. Tiene la capacidad de mapear objetos desde .NET directamente a la base de datos, soporta lenguaje query estandar (SQL-99) y la escalabilidad de los productos relacionales. Airbus usa Matisse en el diseo de componentes de aviacin.

Otros productos y prototipos que podemos agregar a este listado

parcial son: ORION, OpenOODB , IRIS, ONTOS de Ontologic, O2 , ObjectDB etc.

Respecto a las relacionales, todas (Oracle, IBM DB2, Informix, PostgreSQL, etc.) estn cubriendo, en mayor o menor grado, aspectos de SGBD OR.

ndice

1. Evolucin e Historia de las BDs 2. BDOO: Motivacin 3. SGBDOO vs. SGBD de tercera generacin 3.1. Manifiesto de los SGBDOO 3.2. Manifiesto de los SGBD de 3 generacin 3.3. Productos y estndares 3.4. Convergencia 4. Caractersticas de los SGBDOO 4.1. Funcionalidades de la OO 4.2. Funcionalidades de un SGBD 4.2.1. Persistencia 4.2.2. Concurrencia 4.2.3. Procesamiento de consultas ad-hoc 4.2.4. Seguridad y control de acceso 4.2.5. Otras

BDOO: Motivacin

Porqu surgen las BDOO?

1. Por necesidades de los lenguajes de programacin OO

2. Por las limitaciones de las BD relacionales

BDOO: Motivacin 1. Por necesidades de los lenguajes de programacin OO Las BD pueden proporcionar a los OOPLs: PERSISTENCIA DE OBJETOS (los objetos sobreviven a la ejecucin del proceso que los cre) Eficiente almacenamiento y gestin de datos en memoria secundaria Independencia de los datos respecto de los programas Lenguaje de consulta eficiente y de alto nivel (independiente de la estructura fsica) Gestin de transacciones que permita: acceso concurrente, integridad, seguridad y recuperacin ante fallos, Control de integridad (mediante restricciones, disparadores, etc.)

BDOO: Motivacin

2. Las limitaciones de las BD relacionales...

Estructuras muy simples (1FN) Poca riqueza semntica No soportan tipos definidos por el usuario (slo dominios) No soportan recursividad Falta de procedimientos/disparadores No admiten herencia
Si se quieren almacenar datos alfanumricos de pacientes, por ej., sus datos personales, historial de enfermedades, tratamientos recibidos, y resultados de exmenes de sangre, el esquema conceptual se puede implementar eficientemente en un RDBMS. Sin embargo, si la historia mdica incluye imgenes de resonancia magntica, video de alguna ciruga, fotos del paciente, etc., el modelo relacional es completamente inconveniente, pues no tiene estructura ni operaciones apropiadas para manejar esos datos. Existen muchas aplicaciones con necesidades similares a la aplicacin descrita, por ejemplo, las de CAD/CAM, los sistemas de informacin geogrficos, las bases de datos multimedia, etc.

Caractersticas Inadecuadas Para Aplicaciones Complejas

BDOO: Motivacin

Necesidades de las nuevas aplicaciones:

Soporte

de objetos complejos y datos multimedia nicos de referencias e interrelaciones navegacional y de conjunto de registros de los datos y procedimientos asociados de objetos y herencia

Identificadores Soporte

Manipulacin Jerarquas

Integracin Modelos Gestin

extensibles mediante TD definidos por el usuario de versiones

El conjunto de tipos predefinidos del sistema de BD debe ser Extensible, Facilidades de evolucin permitiendo definir tipos nuevos. No debe haber distincin Transacciones de larga duracin en cuanto al uso de los tipos definidos por el Interconexin e interoperabilidad sistema y los extendidos

ndice

1. Evolucin e Historia de las BDs 2. BDOO: Motivacin 3. SGBDOO vs. SGBD de tercera generacin 3.1. Manifiesto de los SGBDOO 3.2. Manifiesto de los SGBD de 3 generacin 3.3. Productos y estndares 3.4. Convergencia 4. Caractersticas de los SGBDOO 4.1. Funcionalidades de la OO 4.2. Funcionalidades de un SGBD 4.2.1. Persistencia 4.2.2. Concurrencia 4.2.3. Procesamiento de consultas ad-hoc 4.2.4. Seguridad y control de acceso 4.2.5. Otras

SGBDOO vs. SGBD de tercera generacin...

Lenguaje de Programacin Orientado a Objetos

Persistencia

Base de Datos Orientada a Objetos

Base de Datos Relacional

Orientacin a Objetos

Base de Datos Objeto - Relacional

BDOO

Base de Datos Orientadas a Objetos (BDOO)

Los Sistemas de Bases de Datos Orientadas a Objetos soportan un modelo de objetos puro, debido a que no estn basados en extensiones de otros modelos ms clsicos como el relacional:

Estn fuertemente influenciados por los lenguajes de programacin orientados a objetos.

Pueden verse como un intento de aadir la funcionalidad de un SGBD a un lenguaje de programacin.

BDOR:
Conserva un modelo compatible con el Modelo Relacional, el cual posee: Fundamentos tericos muy slidos. Ms de 40 aos de investigacin. Extensin del MR para incorporar caractersticas deseables de OO y otras.

Base de Datos Objeto-Relacional (BDOR)

Extension de SQL para incorporar nuevas caractersticas:

Extensin de tipos, objectos, herencia, Consultas recursivas, SQL/XML ...

Estandar SQL:1999, revisado en SQL:2003

3. SGBDOO vs. SGBD de tercera generacin

Enfoques de implementacin de SGBD de Objetos

SGBDR Extendidos SGBD Evolutivos TERCERA GENERACIN OBJETO-RELACIONAL

SGBD Revolucionarios SGBD OO Puros SGB DE OBJETOS

ORACLE, IBM, MICROSOFT, INFORMIX, SYBASE, ...

OBJECTSTORE, O2, ONTOS, VERSANT, POET, GEMSTONE, ..

SQL:2003 Continuidad con la tecnologa relacional / Conservacin de las inversiones realizadas

ODMG 3.0 Ruptura con la anterior tecnologa / Riguroso apego a los principios de la OO

3. SGBDOO vs. SGBD de tercera generacin

Manifiesto de los SGBDOO

Atkinson, Bancilhon, DeWitt. Dittrich, Maier, Adonik (1989)

Tres tipos de caractersticas:

OBLIGATORIAS: Imprescindible satisfacerlas para merecer el calificativo de OO.

OPCIONALES: Pueden aadirse para mejora el sistema.

ABIERTAS: Soluciones igualmente aceptables que quedan al arbitrio del diseador.

3. SGBDOO vs. SGBD de tercera generacin

Manifiesto de los SGBDOO

Caractersticas obligatorias: las reglas de oro

Por ser SGBD Persistencia Concurrencia Recuperacin ante fallos Gestin del almacenamiento secundario Lenguajes ad-hoc para manipulacin volver Por ser OO Objetos complejos Identidad del objeto Encapsulamiento Tipos o clases Overriding, overloading and late binding Herencia Polimorfismo, sobrecarga y vinculacin dinmica Extensibilidad Completitud computacional (lenguaje de propsito general)

3. SGBDOO vs. SGBD de tercera generacin

Manifiesto de los SGBDOO

Caractersticas opcionales

Herencia mltiple Verificacin e inferencia de tipos Distribucin Transacciones de diseo Versiones

Opciones abiertas

Paradigma de programacin Sistema de representacin (tipos atmicos y constructores) Sistema de tipos Uniformidad (todo objetos?)

3. SGBDOO vs. SGBD de 3ra generacin

Manifiesto de los SGBD de 3 Generacin

Stonebraker, Lindsay, Gray, Carey, Brodie, Bernstein, Beech (1990)

Principio 1: Adems de los servicios tradicionales de gestin de datos, los SGBD-3G proporcionarn gestin de objetos y reglas ms ricas
1.1 Un SGBD-3G debe disponer de un rico sistema de tipos 1.2 La herencia es una buena idea 1.3 Las funciones (procedimientos y mtodos) son una buena idea 1.4 Los IDOs para los registros deberan ser asignados por el SGBD slo si no se dispone de una clave primaria 1.5 Las reglas (disparadores, restricciones) se convertirn en una caracterstica primordial de los sistemas futuros.

3. SGBDOO vs. SGBD de 3ra generacin

Manifiesto de los SGBD de 3 Generacin

Principio 2: Los SGBD-3G deben subsumir los SGBD-2G

2.1 Lenguaje de acceso declarativo (no procedimental) y de alto nivel 2.2 Dos formas de especificar colecciones: enumeracin de miembros y lenguajes de consulta para especificar la condicin de pertenencia 2.3 Vistas actualizables 2.4 Los indicadores de rendimiento no deben aparecer en los modelo de datos, ya que no tiene prcticamente nada que ver con los modelos de datos.

3. SGBDOO vs. SGBD de 3ra generacin

Manifiesto de los SGBD de 3 Generacin

Principio 3: Los SGBD-3G deben ser abiertos a otros subsistemas

3.1 Los SGBD-3G deben ser accesibles desde mltiples lenguajes de alto nivel 3.2 Persistencia de variables 3.3 El SQL es una forma intergalctica de expresin de datos 3.4 Las consultas y las respuestas resultantes deben ser el nivel ms bajo de comunicacin entre un cliente y un servidor

volver

BDOO
Pros de los OODBMS

Base de Datos Orientadas a Objetos (BDOO)

la cantidad de informacin que puede modelarse con un OODBMS se incrementa, y tambin es ms fcil modelar esta informacin. Los OODBMS tambin son capaces de tener mayores capacidades de modelado por medio de la extensibilidad. Permitiendo de este modo modelar sistemas an ms complejos. Esta extensibilidad brinda una solucin para incorporar bases de datos existentes y futuras en un solo entorno.

BDOO
Pros de los OODBMS

Base de Datos Orientadas a Objetos (BDOO)

Adems de ventajas de modelado, un OODBMS tambin tienen ventajas de sistema. En un OODBMS, el manejo de versiones est disponible para ayudar a modelar cambios sobre los sistemas. Con el manejo de versiones, uno sera capaz de volver a conjuntos de datos previos, y comparar los conjuntos actuales con los anteriores.

La reutilizacin de clases juega un rol vital en el desarrollo y mantenimiento ms rpido de aplicaciones. Las clases genricas son potentes, pero ms importante es que ellas pueden ser usadas nuevamente. Ya que las clases pueden reutilizarse, no se necesita disear material redundante. Esto lleva a la ms rpida produccin de aplicaciones y ms fcil mantenimiento de dichas aplicaciones y bases de datos.

BDOO
Contras de los OODBMS

Base de Datos Orientadas a Objetos (BDOO)

- Bajo impacto en el mercado de las BDOO.

-La falta de estandares en la industria orientada a objetos.

BDOR: ventajas extendidas

Modelo compatible con el Modelo Relacional. Fundamentos tericos ms slidos.
Base de Datos Objeto-Relacional (BDOR)

Presencia en el mercado: -Adoptado por numerosos SGBDR Oracle, IBM DB2, Informix, PostgreSQL etc. Incorpora caractersticas deseables de OO sin perder lo bueno de los SGBDR SGBDOR Estandar SQL:1999, revisado en SQL:2003

3. SGBDOO vs. SGBD de tercera generacin

Productos y estndares

Objeto-Relacional

estandar: SQL: 1999, Melton (1999) SQL: 2003, Melton (2003)

Productos: POSTGRE Combina capacidades de BD OO y activas con BD relacionales. ORACLE Extiende el modelo relacional del SQL2 con capacidades de objetos. Universal Server de Informix, etc.

3. SGBDOO vs. SGBD de tercera generacin

Productos y estndares

Objetos puros

estandar: ODMG-93, Cattell (1994), Cattell (1995) ODMG V.2.0 Cattell (1997) ODMG V.3.0 Cattell (2000)

Productos: ObjectStore de Object Design Persistencia de objetos en C++, Java O2 de O2, Leeluse et al. (1988) Lenguajes: C++, lenguajes de consulta (O2SQL) y programacin (O2C) propios. Java Gemstone de Servi Logic, Meier y Stone (1987) Persistencia de objetos en Samalltalk. Soporta tambin C++ y Java POET de Poet Corporation Persistencia de objetos C++, Java

Comparacin de standards para DBMS

Estndar rasgo SQL-92 JDBC SQLJ SQL:1999 ODMG 3.0 JDO

Modelo

modelo relacional

modelo relacional

Parte 1: modelo relacional Parte 2: modelo de objetos SQL:1999

Modelo de objetos SQL:1999

Modelo de objetos Java, C++ y Modelo de Smalltalk objetos enriquecido Java con enriquecido persistencia con transparente persistencia (superset transparente del modelo OMG).

ODL
Data Definition Language

SQL

SQL

SQL

SQL

(Object Definition Language) - Java & XML superset del IDL del OMG JDO Query Language (JDOQL)

Query Language

Embedded SQL, Dynamic SQL, and Calllevel interface

Call-level interface for SQL

Embedded SQL Embedded SQL and Java

OQL Embedded SQL, Dynamic Object Query SQL, and Call- Language basado en level interface SQL-92
Embedded SQL, Dynamic SQL, and Calllevel interface

Embedded Call-level Data Manipulation SQL, Dynamic interface SQL, and Call- for SQL Language level interface

Java, C++, Smalltalk

Java

and Java

3. SGBDOO vs. SGBD de tercera generacin

3.4 Convergencia

Integracin

Programa relacional

Programa orientado a objetos

BD relacional

BDOO

3. SGBDOO vs. SGBD de tercera generacin

3.4 Convergencia

Necesidad de convergencia
Es hora de que pongamos a nuestros clientes en primer lugar y les ayudemos a salir del falso dilema que hemos creado. La base de datos del futuro ser, de hecho, orientada a objetos, pero retendr todas las ventajas del modelo relacional, Taylor (1992)

Convergencia de estndares OBJECT MERGER GROUP.- grupo formado por integrantes del ODMG y del SQL3 cuyo objetivo es lograr la integracin de los lenguajes de consulta de ambos estndares, a fin de conseguir el entendimiento entre BD3G y BDOO Convergencia de productos UniSQL, permite la coexistencia entre BD relacionales y BD orientadas a objeto.

ndice

1. Evolucin e Historia de las BDs 2. BDOO: Motivacin 3. SGBDOO vs. SGBD de tercera generacin 3.1. Manifiesto de los SGBDOO 3.2. Manifiesto de los SGBD de 3 generacin 3.3. Productos y estndares 3.4. Convergencia 4. Caractersticas de los SGBDOO 4.1. Funcionalidades de la OO 4.2. Funcionalidades de un SGBD 4.2.1. Persistencia 4.2.2. Concurrencia 4.2.3. Procesamiento de consultas ad-hoc 4.2.4. Seguridad y control de acceso 4.2.5. Otras

4. Caractersticas de los SGBDOO

BD BDOO OO

Los ODBMS son una buena eleccin para aquellos sistemas que necesitan un buen rendimiento en la manipulacin de tipos de datos complejos. Las bases de datos orientadas a objetos se disean para trabajar bien en conjuncin con lenguajes de programacin orientados a objetos como Java, C#, Visual Basic.NET y C++. Los ODBMS usan exactamente el mismo modelo que estos lenguajes de programacin. Los ODBMS tienen una integracin transparente con el programa escrito en un lenguaje de programacin orientado a objetos, al almacenar exactamente el modelo de objeto usado a nivel aplicativo, lo que reduce los costes de desarrollo y mantenimiento.

4. Caractersticas de los SGBDOO

SGBDOO = SGBD+ OO

Funcionalidades de un SGBDOO = Funcionalidades de un SGBD + Funcionalidades de la OO

4. Caractersticas de los SGBDOO

4.1. Funcionalidades

de la OO

Identificador de objeto de objetos complejos de tipos extensible

Soporte Sistema

Encapsulamiento Herencia Soportar

un lenguaje completo y sobrecarga

Polimorfismo

Repaso

4. Caractersticas de los SGBDOO

4.2. Funcionalidades

de un SGBD

Persistencia Manipulacin

del esquema Gestin de memoria secundaria Control de concurrencia: Gestin de transacciones Recuperacin ante fallos Procesamiento de consultas ad-hoc Seguridad y control de acceso Otras: Soporte de restricciones Soporte de vistas

4. Caractersticas de los SGBDOO

4.2.1 Persistencia y manipulacin del esquema
OBJETOS TRANSITORIOS/PERMANENTES

Soportar persistencia requiere proporcionar mecanismos eficientes para representar y acceder a pequeos o grandes volmenes de objetos en medios de almacenamiento no voltiles. Mantener ndices, asignar el almacenamiento en disco, seleccionar caminos de acceso, optimizar consultas, o trasladar los datos entre el disco y la memoria principal, deben ser aspectos no visibles al usuario. Crendose de esta forma una independencia entre los niveles lgicos y fsicos del sistema. El SGBD debe ser capaz de manejar el esquema de la BD: BD relacionales definicin del esquema mediante SQL BDOO definicin del esquema mediante un LPOO

4. Caractersticas de los SGBDOO

4.2.1 Persistencia y manipulacin del esquema

Las BD sin OO almacenan slo datos Las BDOO almacenan objetos (estructuras de datos + operaciones)

Ventajas de almacenar juntas las estructuras de datos y las operaciones en la BO: Mejorar la manipulacin y administracin de los mdulos de cdigo, eliminando la necesidad de vincular (link) dicho cdigo con las aplicaciones Aumentar la flexibilidad permitiendo especificar en que sitio de una red se va a ejecutar una operacin

4. Caractersticas de los SGBDOO

4.2.1 Persistencia

Operaciones: lenguaje y almacenamiento Gemstone y OpenODB soportan lenguajes para la definicin completa de los mtodos (Opal y OSQL). Ambos productos almacenan y ejecutan las operaciones en el motor de la BD en lugar de hacerlo en el espacio de la aplicacin. Sin embargo en muchos de los SGBDOO que soportan C++, las operaciones tienen que ser programadas en C++; se almacenan en ficheros .cxx para ser vinculadas (linked) con la aplicacin.

4. Caractersticas de los SGBDOO

4.2.1 Persistencia

ejemplo: Persistencia en POET

Una

clase es persistente si se declara como tal.

Todo

objeto de una clase persistente puede

almacenarse a si mismo.
Modelo

de persistencia explcito: cuando se crea un objeto persistente en la RAM, hay que almacenarlo explcitamente en la BD (mtodo Assign).

Si

se almacena un objeto, se almacenan todos los objetos a los que hace referencia. Si se carga un objeto en la RAM, se cargan todos los objetos a los que haga referencia.

4. Caractersticas de los SGBDOO

4.2.1 Persistencia

ejemplo: Persistencia en POET

Para cada clase declarada se crea un conjunto, AllSet, que guarda todos los objetos (extensin).

Cada objeto puede existir una sola vez en memoria. Si una operacin de la BD busca un objeto, primero se comprueba que no est ya en memoria; si lo est, se devuelve el puntero al objeto.
Las clases pueden contener punteros a objetos persistentes, y set de punteros. No pueden contener punteros a objetos no persistentes. Una clase persistente puede contener objetos embebidos (no tienen OID) que existen slo como miembros del objeto contenedor.

4. Caractersticas de los SGBDOO

4.2.2 Concurrencia

BO accesibles por mltiples usuarios o aplicaciones

Para asegurar que los objetos puedan ser compartidos se utilizan tcnicas de BD:

Control de concurrencia: permite que varios usuarios o aplicaciones compartan objetos de un modo seguro.
Gestin de transacciones: incluye capacidades de recuperacin ante fallos de la BD.

4. Caractersticas de los SGBDOO

4.2.3 Procesamiento de consultas ad-hoc

Tcnicas para consultar objetos en una BDOO: Utilizando el propio LPOO para consultar a la BDOO. Mediante un lenguaje de consulta de objetos con una sintaxis similar a la del SQL. Este lenguaje soporta la nocin de consulta basada en valores -de las BDs relacionales- y adems soporta consultas basadas en relaciones (capacidad navegacional) y en valores que resultan de ejecutar una operacin.

4. Caractersticas de los SGBDOO

4.2.4 Seguridad y control de acceso

Muchos SGBDOO utilizan los recursos de seguridad que brinda el Sistema Operativo subyacente (UNIX o Windows). Otros sistemas utilizan mecanismos de proteccin de esquemas mediante password, pero sin proporcionar ninguna tcnica adicional para controlar el acceso y la seguridad a otros niveles (a nivel de objeto, a nivel de miembro).

Los SGBD relacionales continan siendo mucho ms potentes en este sentido.

4. Caractersticas de los SGBDOO

4.2.5 Otras funcionalidades

RESTRICCIONES: Los SGBDOO no soportan restricciones. Las restricciones soportadas por los SGBD relacionales se soportan mediante operaciones VISTAS: Los SGBDOO no soportan vistas. Las vistas soportadas por los SGBD relacionales se soportan mediante operaciones

4. Caractersticas de los SGBDOO

4.2.5 Otras

En general:

Los SGBDOR son ms potentes que los SGBDOO en cuanto a capacidades propias del sistema de gestin. Los SGBDOO tienen un modelo ms rico y otras facilidades.

Modelo Relacional : ejemplo AlumnoCurso

Alumno
Alumno# 1 2 3 NombreAlumno Hidalgo Juan Gonzales Irene Sanchez Clara Ins Direccin M. Zaballa 100 N Los Alerces 810 S Mendoza 536 N Mitre 213 O Ig. De la Roza 5410 O

4
5

Romero Diego
Martinez Anala

Estudia
Alumno# 1 C1 Curso#

Para obtener: "Nombre de alumnos que cursan Teologa Ir a curso para encontrar el curso# corresp. a Teologa (i.e.T2)

2
3 4 5

T2
T2 Q9 F3

Curso
Curso# C1 F3 Q9 T2 NombreCurso Computacin Filosofa Quimica Teologa

Ir a Estudia y retornar todos los Alumno#s con T2 Ir a Alumno para retornar el NombreAlumno corresp. A cada Alumno#

Modelo De Objetos: ejemplo AlumnoCurso

OBJETO CURSO Curso=Teologa Curso# =T2 Alumnos

Next

Next

Nil

Alumno# =3
NombreAlumno=Sanchez Ins

Alumno# =2
NombreAlumno=Gonzales Irene

Curso OBJETO ALUMNO

Para obtener: "Nombre de alumnos que cursan Teologa Buscar en ndice de curso para hallar curso# (i.e. T2) Seguir punteros a Alumno para hallar cada NombreAlumno Este proceso es llamado navegacin, notar que depende de punteros y que muchos de ellos debern ser persitentes.