Índice 1. Evolución e Historia de las BDs 2. BDOO: Motivación 3. SGBDOO vs. SGBD de tercera...

Índice

1. Evolución e Historia de las BDs 2. BDOO: Motivación 3. SGBDOO vs. SGBD de tercera generación 3.1. Manifiesto de los SGBDOO 3.2. Manifiesto de los SGBD de 3ª generación 3.3. Productos y estándares 3.4. Convergencia 4. Características de los SGBDOO 4.1. Funcionalidades de la OO 4.2. Funcionalidades de un SGBD4.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

Sistemas de archivos (1950s)

Se conservan los datos después de que el proceso que los creó deja de existir

BDs Jerárquicas y de Red (1960s)

Concurrencia, Recuperación, rápido acceso, estructuras complejas, etc.

BDs Relacionales (1970-80s)

Mayor confiabilidad, menor redundancia, más flexibilidad, manejo de vistas, etc.

ODBMS (1990s)

Manejo de tipos de datos complejos, más relaciones (agregación, especialización), un mismo lenguaje p/ BD y programación, manejo de versiones, no es necesario “reconstruir” objetos, reusabilidad, etc.

BREVE HISTORIA de las BDs

Evolución de la tecnología de BD: Dimensiones

FUNCIONALIDAD/INTELIGENCIA

BD ActivasBD TemporalesBD Deductivas BD Seguras BD OO BD OR …

RENDIMIENTO

BD BD Distribuidas Multi BD BD Federadas BDweb BD Móviles …

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

DISTRIBUCIÓN/ INTEGRACIÓN

1. Evolución e Historia…

1960 Primeros productos de bases de datos Estándar Codasyl (Modelo de Red)

1980 Arquitectura cliente/servidor de 2 capas Bases de datos distribuidas Estándares SQL (ANSI/ISO) Herramientas CASE Manifiesto sobre bases de datos orientadas a objetos

2000 Arquitectura Cliente/Servidor en tres capas Modelo Objeto-Relacional

Bases de datos multimedia Bases de datos móviles SQL/MM (texto, espacial, imagen, minería de datos) Bases de datos XML, SQL: 2003 (XML)

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

1990 Manifiesto sobre la 3ra generación de Bases de datos Primeros productos de bases de objeto Modelos de referencia (ISO/ANSI) SQL 92 (Revisión mayor) Consorcio ODMG (Estándares OO) Almacenes de datos SQL:1999 (expres. regulares, consultas recursivas)

Hierarchical

Network

Relational

Object-Oriented

Object-Relational

Semi-Structured

XML

1960 1970 1980 1990 2000

Mo

del

o R

elac

ion

alS

tan

dar

d C

OD

AS

YL

SQ

LM

od

elo

E-R

SQ

L-8

6

OD

MG

1.0

SQ

L:1

999

XM

L

OD

MG

3.0

1. Evolución e Historia…

ver>>>

ver>>>

Índice


Orígenes

OOPLs.

tienen sus raices en el lenguaje SIMULA el cual fue introducido a finales de la decada de los 60.

SIMULA es una extensión de ALGOL 60. Sin embargo, el primer lenguaje que popularizó la aproximación a objetos fue Smalltalk (1976); este puede considerarse una síntesis de Lisp y de Simula. En los años 80, aparecen numerosos lenguajes OO inspirados en Simula o Smalltalk. Los más célebres, entre los compilados, son C++ y Objective C. La mayoría de los lenguajes OO interpretados son extensiones del Lisp; por ejemplo, Loops y Clos

Base de Datos Orientadas a

Objetos (BDOO)

Orígenes

BDOOBDOOBase de Datos Orientadas a

Objetos (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 año 1985

…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 Servo-Logic 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.

Primeros sistemas…

1. Evolución e historia…

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 semánticas de modelos clásicos como el relacional.

1990 -Third Generation Database System Manifesto (STONEBRAKER)

Considera: 1ra generación de BD son jerárquica y Red; 2da generación es Relacional y para la 3ra generación (“omite” mencionarla como OO) establece una serie de proposiciones y principios. La idea básica es que los SGBD de 3ra generación deberían 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 orientación a objeto. Postura que comparten los principales vendedores de productos relacionales.

1991 - ODMGRick 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 común. Aunque no logran el objetivo, sus esfuerzos tuvieron influencia en OQL (object query language).

Buscando establecer un estandar…1. Evolución e historia…

1995 - El Tercer Manifiesto (DARWEN y DATE)

Es un documento más formal que los otros 2 manifiestos. Reinterpreta el modelo relacional bajo una visión 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 teórico del modelo relacional. No se trata de una extensión del lenguaje SQL(opinan que SQL no es adecuado como base para el futuro lenguaje). Según 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 categorías:• Las que surgen del Modelo Relacional (RM)• Las que no surgen del Modelo de Objetos (OM)

2001 – Aparición del estandar ODMG 3.0 El estandar ODMG 3.0 en liberado. Poco después el grupo ODMG da las bases para la especificación de Java Data Objects (JDO) y luego el grupo se disuelve.


Buscando establecer un estandar…

2004 – El Advenimiento del código abierto (Open Source)

db4o es liberado como ODBMS de “código abierto”. Para Noviembre de 2005, db4o es el primero en soportar Queries “nativos” (Native Queries). Posee una librería que trabaja directamente con objetos y permite realizar consultas usando lenguajes de programación (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 más 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. Evolución e historia …

Historia reciente…

Productos comerciales recientes (listado parcial)

Db4objects: versión 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, rápida y fácil de usar. Maneja BDs, desde unos pocos KBs hasta cientos de GBs. Trabaja tanto en modo embebido como en modo cliente-servidor.


Productos comerciales recientes (continuación..)

GemStone: Es un SGBDOO “Puro” que ofrece las características 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 .NETMatisse 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 diseño de componentes de aviación.

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.) están cubriendo, en mayor o menor grado, aspectos de SGBD OR.


Índice


BDOO: Motivación

¿Porqué surgen las BDOO?

1. Por necesidades de los lenguajes de programación OO

2. Por las limitaciones de las BD relacionales

BDOO: Motivación

1. Por necesidades de los lenguajes de programación OO … Las BD pueden proporcionar a los OOPLs:

6

PERSISTENCIA DE OBJETOS (los objetos sobreviven a la ejecución

del proceso que los creó)

Eficiente almacenamiento y gestión 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 física)

Gestión de transacciones que permita: acceso concurrente, integridad, seguridad y recuperación ante fallos, Control de integridad (mediante restricciones, disparadores, etc.)

2. Las limitaciones de las BD relacionales...

Estructuras muy simples (1FN)Poca riqueza semánticaNo soportan tipos definidos por el usuario (sólo dominios) No soportan recursividad Falta de procedimientos/disparadores No admiten herencia

Características Inadecuadas Para Aplicaciones Complejas

BDOO: Motivación

Si se quieren almacenar datos alfanuméricos de pacientes, por ej., sus datos personales, historial de enfermedades,

tratamientos recibidos, y resultados de exámenes de sangre, el esquema conceptual se puede implementar eficientemente en

un RDBMS. Sin embargo, si la historia médica incluye imágenes de resonancia magnética, video de alguna cirugía, 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 aplicación descrita, por ejemplo, las de CAD/CAM, los sistemas de información geográficos, las bases de datos

multimedia, etc.

Necesidades de las nuevas aplicaciones:

►Soporte de objetos complejos y datos multimedia

►Identificadores únicos

►Soporte de referencias e interrelaciones

►Manipulación navegacional y de conjunto de registros

►Jerarquías de objetos y herencia

►Integración de los datos y procedimientos asociados

►Modelos extensibles mediante TD definidos por el

usuario

►Gestión de versiones

►Facilidades de evolución

►Transacciones de larga duración

►Interconexión e interoperabilidad

BDOO: Motivación

El conjunto de tipos predefinidos del sistema de BD debe ser Extensible, permitiendo definir tipos nuevos.

No debe haber distinción en cuanto al uso de los tipos definidos por el sistema y los extendidos

Índice


Lenguaje de ProgramaciónOrientado a Objetos

Persistencia Base de DatosOrientada a Objetos

Base de DatosRelacional

Orientacióna Objetos

Base de DatosObjeto - Relacional

SGBDOO vs. SGBD de tercera generación...

• Los Sistemas de Bases de Datos Orientadas a Objetos soportan un modelo de objetos puro, debido a que no están basados en extensiones de otros modelos más clásicos como el relacional:

• Están fuertemente influenciados por los lenguajes de programación orientados a objetos.

• Pueden verse como un intento de añadir la funcionalidad de un SGBD a un lenguaje de programación.

BDOO BDOO


Objetos (BDOO)

Base de Datos Objeto-Relacional

(BDOR)

BDOR:BDOR:

• Conserva un modelo compatible con el Modelo Relacional, el cual posee: • Fundamentos teóricos muy sólidos. • Más de 40 años de investigación.

• Extensión del MR para incorporar características deseables de OO y otras.

• Extension de SQL para incorporar nuevas características:

Extensión de tipos, objectos, herencia, Consultas recursivas, SQL/XML ...

• Estandar SQL:1999, revisado en SQL:2003

3. SGBDOO vs. SGBD de tercera generación

Enfoques de implementación de SGBD de Objetos

SGBDR “Extendidos” SGBD “Evolutivos”

TERCERA GENERACIÓN OBJETO-RELACIONAL

SGBD “Revolucionarios” SGBD OO “Puros” SGB DE OBJETOS

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

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

SQL:2003 Continuidad con la tecnología relacional / Conservación de las inversiones realizadas

ODMG 3.0 Ruptura con la anterior

tecnología / Riguroso apego a los principios de la OO


Tres tipos de características:

OBLIGATORIAS: Imprescindible satisfacerlas para merecer el calificativo de OO. OPCIONALES: Pueden añadirse para mejora el sistema. ABIERTAS: Soluciones igualmente aceptables que quedan al arbitrio del diseñador.

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

Manifiesto de los SGBDOO


Por ser SGBD • Persistencia • Concurrencia • Recuperación ante fallos • Gestión del almacenamiento secundario• Lenguajes ad-hoc para manipulación Por ser OO• Objetos complejos • Identidad del objeto • Encapsulamiento • Tipos o clases • Herencia • Polimorfismo, sobrecarga y vinculación dinámica • Extensibilidad • Completitud computacional (lenguaje de propósito general)

Características obligatorias: las reglas de oro

Overriding, overloading and late binding

volver



• Herencia múltiple • Verificación e inferencia de tipos • Distribución • Transacciones de diseño • Versiones

Características opcionales

Opciones abiertas

• Paradigma de programación • Sistema de representación (tipos atómicos y constructores) • Sistema de tipos • Uniformidad (¿todo objetos?)


3. SGBDOO vs. SGBD de 3ra generación

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

Principio 1: “Además de los servicios tradicionales de gestión de datos, los SGBD-3G proporcionarán gestión de objetos y reglas más 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 métodos) son una buena idea 1.4 Los IDOs para los registros deberían ser asignados por el SGBD sólo si no se dispone de una clave primaria 1.5 Las reglas (disparadores, restricciones) se convertirán en una característica primordial de los sistemas futuros.

Manifiesto de los SGBD de 3º Generación

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: enumeración de miembros y lenguajes de consulta para especificar la condición de pertenencia

2.3 Vistas actualizables

2.4 Los indicadores de rendimiento no deben aparecer en los modelo de datos, ya que no tiene prácticamente nada que ver con los modelos de datos.



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

3.1 Los SGBD-3G deben ser accesibles desde múltiples lenguajes

de alto nivel

3.2 Persistencia de variables

3.3 El SQL es una forma “intergaláctica” de expresión de datos

3.4 Las consultas y las respuestas resultantes deben ser el nivel más bajo de comunicación entre un cliente y un servidor


volver


BDOO BDOO

Pros de los OODBMS

•la cantidad de información que puede modelarse con un OODBMS se incrementa, y también es más fácil modelar esta información.

•Los OODBMS también son capaces de tener mayores capacidades de modelado por medio de la extensibilidad. Permitiendo de este modo modelar sistemas aún más complejos. Esta extensibilidad brinda una solución para incorporar bases de datos existentes y futuras en un solo entorno.


Objetos (BDOO)

BDOO BDOO

Pros de los OODBMS

•Además de ventajas de modelado, un OODBMS también 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 sería capaz de volver a conjuntos de datos previos, y comparar los conjuntos actuales con los anteriores.

•La reutilización de clases juega un rol vital en el desarrollo y mantenimiento más rápido de aplicaciones. Las clases genéricas son potentes, pero más importante es que ellas pueden ser usadas nuevamente. Ya que las clases pueden reutilizarse, no se necesita diseñar material redundante. Esto lleva a la más rápida producción de aplicaciones y más fácil mantenimiento de dichas aplicaciones y bases de datos.


Objetos (BDOO)

BDOO BDOO

Contras de los OODBMS

- Bajo impacto en el mercado de las BDOO.

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


Objetos (BDOO)

Base de Datos Objeto-Relacional

(BDOR)

BDOR: BDOR: “ventajas extendidas”“ventajas extendidas”

• Modelo compatible con el Modelo Relacional. • Fundamentos teóricos más sólidos. • Presencia en el mercado: -Adoptado por numerosos SGBDR Oracle, IBM DB2, Informix, PostgreSQL etc.

• Incorpora características deseables de OO sin perder lo bueno de los SGBDR SGBDOR

• Estandar SQL:1999, revisado en SQL:2003


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.

Productos y estándares

3. SGBDOO vs. SGBD de tercera generación Productos y estándares

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 programación (O2C) propios. Java • Gemstone de Servi Logic, Meier y Stone (1987) Persistencia de objetos en Samalltalk. Soporta también C++ y Java • POET de Poet Corporation Persistencia de objetos C++, Java

JavaJava, C++, Smalltalk

Embedded SQL and Java

Call-level interface for SQL and Java

Data Manipulation Language

JDO Query Language (JDOQL)

OQLObject Query Language basado en SQL-92

Embedded SQL

Call-level interface for SQL

Embedded SQL, Dynamic SQL, and Call-level interface

Query Language

Java & XML

ODL(Object

Definition Language) -“superset”del IDL del

OMG

SQL

DataDefinitionLanguage

Modelo de objetos

Java, C++ y Smalltalk

enriquecido con

persistencia transparente

(superset del modelo

OMG).

Modelo de objetosSQL:1999

Parte 1: modelo relacional Parte 2: modelo de objetosSQL:1999

modelo relacional

Modelo

JDOODMG 3.0SQL:1999SQLJJDBCSQL-92Estándarrasgo

modelo relacional

Modelo de objetos Java

enriquecido con


SQL SQL SQL




JavaJava, C++, Smalltalk

Embedded SQL and Java

Call-level interface for SQL and Java

Data Manipulation Language

JDO Query Language (JDOQL)

OQLObject Query Language basado en SQL-92

Embedded SQL

Call-level interface for SQL


Query Language

Java & XML

ODL(Object

Definition Language) -“superset”del IDL del

OMG

SQL

DataDefinitionLanguage

Modelo de objetos

Java, C++ y Smalltalk

enriquecido con


(superset del modelo

OMG).

Modelo de objetosSQL:1999

Parte 1: modelo relacional Parte 2: modelo de objetosSQL:1999

modelo relacional

Modelo

JDOODMG 3.0SQL:1999SQLJJDBCSQL-92Estándarrasgo

modelo relacional

Modelo de objetos Java

enriquecido con


SQL SQL SQL




Comparación de standards para DBMS

Integración

Programa orientado a

objetos

Programa relacional

BDOO BD relacional

3. SGBDOO vs. SGBD de tercera generación 3.4 Convergencia

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 estándares OBJECT MERGER GROUP.- grupo formado por integrantes del ODMG y del SQL3 cuyo objetivo es lograr la integración de los lenguajes de consulta de ambos estándares, 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


4. Características de los SGBDOO

BD BDOO

OO

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


SGBDOO = SGBD+ OO

Funcionalidades de un SGBDOO =

Funcionalidades de un SGBD

+ Funcionalidades de la OO

4.1. Funcionalidades de la OO

● Identificador de objeto

● Soporte de objetos complejos

● Sistema de tipos extensible

● Encapsulamiento

● Herencia

● Soportar un lenguaje completo

● Polimorfismo y sobrecarga


Repaso

4.2. Funcionalidades de un SGBD

● Persistencia● Manipulación del esquema ● Gestión de memoria secundaria ● Control de concurrencia: ● Gestión de transacciones ● Recuperación ante fallos ● Procesamiento de consultas ad-hoc ● Seguridad y control de acceso ● Otras: ● Soporte de restricciones ● Soporte de vistas


4.2.1 Persistencia y manipulación del esquema

OBJETOS TRANSITORIOS/PERMANENTES

Soportar persistencia requiere proporcionar mecanismos eficientes para representar y acceder a pequeños o grandes volúmenes de objetos en medios de almacenamiento no volátiles.

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. Creándose de esta forma una independencia entre los niveles lógicos y físicos del sistema.

El SGBD debe ser capaz de manejar el esquema de la BD:

BD relacionales → → definición del esquema mediante SQL

BDOO → → definición del esquema mediante un LPOO


Las BD sin OO almacenan sólo datos Las BDOO almacenan objetos (estructuras de datos + operaciones)


4.2.1 Persistencia y manipulación del esquema

Ventajas de almacenar juntas las estructuras de datos y las operaciones en la BO: Mejorar la manipulación y administración de los módulos de código, eliminando la necesidad de vincular (link) dicho código con las aplicacionesAumentar la flexibilidad permitiendo especificar en que sitio de una red se va a ejecutar una operación

4.2.1 Persistencia


Operaciones: lenguaje y almacenamiento

Gemstone y OpenODB soportan lenguajes para la definición completa de los métodos (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 aplicación.

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 aplicación.

► Una clase es persistente si se declara como tal.

► Todo objeto de una clase persistente puede almacenarse a si mismo.

► Modelo de persistencia explícito: cuando se crea

un objeto persistente en la RAM, hay que almacenarlo explícitamente en la BD (método 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.2.1 Persistencia


ejemplo: Persistencia en POET

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

Cada objeto puede existir una sola vez en memoria. Si una operación 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 sólo como miembros del objeto contenedor.

4.2.1 Persistencia


ejemplo: Persistencia en POET

4.2.2 Concurrencia

BO accesibles por múltiples usuarios o aplicaciones

Para asegurar que los objetos puedan ser compartidos se utilizan técnicas de BD:

Control de concurrencia: permite que varios usuarios o aplicaciones compartan objetos de un modo seguro.

Gestión de transacciones: incluye capacidades de recuperación ante fallos de la BD.


4.2.3 Procesamiento de consultas ad-hoc

Técnicas 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 noción de consulta basada en valores -de las BDs relacionales- y además soporta consultas basadas en relaciones (capacidad navegacional) y en valores que resultan de ejecutar una operación.


4.2.4 Seguridad y control de acceso

Los SGBD relacionales continúan siendo mucho más potentes en este

sentido.


Muchos SGBDOO utilizan los recursos de seguridad que brinda el Sistema Operativo subyacente (UNIX o Windows).

Otros sistemas utilizan mecanismos de protección de esquemas mediante password, pero sin proporcionar ninguna técnica adicional para controlar el acceso y la seguridad a otros niveles (a nivel de objeto, a nivel de miembro…).

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.2.5 Otras

En general:

Los SGBDOR son más potentes que los SGBDOO en cuanto a capacidades propias del sistema de gestión. Los SGBDOO tienen un modelo más rico y otras facilidades.


Modelo Relacional : ejemplo Alumno–Curso

Alumno# NombreAlumno Dirección

1 Hidalgo Juan M. Zaballa 100 N

2 Gonzales Irene

3 Sanchez Clara Inés

4 Romero Diego

5 Martinez Analía

Alumno# Curso#

1 C1

2 T2

3 T2

4 Q9

5 F3

Curso# NombreCurso

C1 Computación

F3 Filosofía

Q9 Quimica

T2 Teología

Los Alerces 810 S

Mendoza 536 N

Mitre 213 O

Ig. De la Roza 5410 O

Para obtener:

"Nombre de alumnos que cursan Teología“

‘Ir’ a curso para encontrar el curso# corresp. a Teología (i.e.T2)

‘Ir’ a Estudia y retornar todos los Alumno#s con T2

‘Ir’ a Alumno para retornar el NombreAlumno corresp. A cada Alumno#

Curso

Estudia

Alumno

Para obtener: "Nombre de alumnos que cursan Teología“

Buscar en índice de curso para hallar curso# (i.e. T2)Seguir punteros a Alumno para hallar cada NombreAlumnoEste proceso es llamado navegación, notar que depende de punteros y que muchos de ellos deberán ser persitentes.

Modelo De Objetos: ejemplo Alumno–Curso

Curso=TeologíaCurso# =T2

Alumnos

OBJETO CURSO

OBJETO ALUMNO

Alumno# =2NombreAlumno=Gonzales Irene

Curso

Alumno# =3NombreAlumno=Sanchez Inés

Next Next Nil

Índice 1. Evolución e Historia de las BDs 2. BDOO: Motivación 3. SGBDOO vs. SGBD de tercera...

Documents

Transcript of Índice 1. Evolución e Historia de las BDs 2. BDOO: Motivación 3. SGBDOO vs. SGBD de tercera...