Historia de BD OO

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)
Se conservan los datos despus de que el proceso

que los cre deja de existir
BDs Jerrquicas y de
Red (1960s)
Concurrencia, Recuperacin, rpido acceso,

estructuras complejas, etc.
BDs Relacionales
(1970-80s)
Mayor confiabilidad, menor redundancia, ms

flexibilidad, manejo de vistas, etc.
ODBMS (1990s)
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.
Evolucin de la tecnologa de BD: Dimensiones
FUNCIONALIDAD/
INTELIGENCIA
BD Distribuidas
Multi BD
BD Federadas
BDweb
BD Mviles
DISTRIBUCIN/
INTEGRACIN
BD Activas
BD Temporales
BD Deductivas
BD Seguras
BD OO
BD OR
RENDIMIENTO
BD
BD Paralelas
BD en Memoria Principal
BD Grid
BD en Tiempo Real
1. Evolucin e Historia
1960
Primeros productos de bases de datos

Estndar Codasyl (Modelo de Red)
1970
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
1990
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)
2000
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)
ODMG 3.0
SQL:1999
XML
ODMG 1.0
SQL-86
SQL
Modelo E-R
Modelo Relacional
Standard CODASYL
1. Evolucin e Historia
Hierarchical
Network
Relational
Object-Oriented
Object-Relational
Semi-Structured
XML
1960
1970
1980
1990
2000
ver>>>
ver>>>
ndice

2. BDOO: Motivacin
3.4. Convergencia
4.2.1. Persistencia
4.2.2. Concurrencia
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.
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).
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.
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)
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.
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

2. BDOO: Motivacin
3.4. Convergencia
4.2.1. Persistencia
4.2.2. Concurrencia
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
Caractersticas
Inadecuadas
Para
Aplicaciones
Complejas
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.
BDOO: Motivacin
Necesidades de las nuevas aplicaciones:

Soporte
de objetos complejos y datos multimedia
Identificadores
Soporte
nicos
de referencias e interrelaciones
Manipulacin
Jerarquas
navegacional y de conjunto de registros
de objetos y herencia
Integracin
de los datos y procedimientos asociados
Modelos
extensibles mediante TD definidos por el usuario
Gestin
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

2. BDOO: Motivacin
3.4. Convergencia
4.2.1. Persistencia
4.2.2. Concurrencia
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:
Base de Datos
Objeto-Relacional
(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.
Extension de SQL para incorporar nuevas

caractersticas:
Extensin de tipos, objectos, herencia,

Consultas recursivas, SQL/XML ...
Estandar SQL:1999, revisado en SQL:2003
Enfoques de implementacin de SGBD de Objetos

SGBDR Extendidos
SGBD Evolutivos
TERCERA GENERACIN
OBJETO-RELACIONAL
ORACLE, IBM, MICROSOFT,

INFORMIX, SYBASE, ...
SQL:2003
Continuidad con la tecnologa
relacional / Conservacin de las
inversiones realizadas
SGBD Revolucionarios
SGBD OO Puros
SGB DE OBJETOS
OBJECTSTORE, O2, ONTOS,

VERSANT, POET, GEMSTONE, ..
ODMG 3.0
Ruptura con la anterior tecnologa /
Riguroso apego a los principios de
la OO
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.

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)

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.
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.
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
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.
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
Modelo
SQL-92
modelo
relacional
JDBC
modelo
relacional
SQLJ
Parte 1:
modelo
relacional
Parte 2:
modelo de
objetos
SQL:1999
SQL:1999
Modelo de
objetos
SQL:1999
ODMG 3.0
JDO
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
Call-level
interface
for SQL
Embedded
SQL
OQL
Embedded
SQL, Dynamic Object Query
SQL, and Call- Language
basado en
level interface
SQL-92
Embedded
Call-level
Data
Manipulation SQL, Dynamic interface
SQL, and Call- for SQL
Language
Embedded
SQL and
Java
Embedded
SQL, Dynamic
SQL, and Calllevel interface
Query
Language
Embedded
SQL, Dynamic
SQL, and Calllevel interface
level interface
and Java
Java, C++,
Smalltalk
JDO Query
Language
(JDOQL)
Java
3.4 Convergencia
Integracin
Programa
relacional
BD relacional
Programa
orientado a
objetos
BDOO
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

2. BDOO: Motivacin
3.4. Convergencia
4.2.1. Persistencia
4.2.2. Concurrencia
4.2.5. Otras
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.
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
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.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.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.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.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.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.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.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.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.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 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#
NombreAlumno
Direccin
Hidalgo Juan
M. Zaballa 100 N
Gonzales Irene
Los Alerces 810 S
Sanchez Clara Ins
Romero Diego
Martinez Anala
Estudia
Alumno#
Curso#
C1
T2
T2
Q9
F3
Para obtener:
"Nombre de alumnos que cursan
Teologa
Ir a curso para encontrar el
curso# corresp. a Teologa (i.e.T2)
Curso
Curso#
Mendoza 536 N
Mitre 213 O
Ig. De la Roza 5410 O
NombreCurso
C1
Computacin
F3
Filosofa
Q9
Quimica
T2
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.

Historia de BD OO

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Historia de BD OO

Загружено:

Авторское право:

Доступные форматы

ndice

1. Evolucin e Historia de las BDs

BREVE HISTORIA de las BDs

Se conservan los datos despus de que el proceso

Concurrencia, Recuperacin, rpido acceso,

Mayor confiabilidad, menor redundancia, ms

Manejo de tipos de datos complejos, ms relaciones

Evolucin de la tecnologa de BD: Dimensiones

Primeros productos de bases de datos

Arquitectura cliente/servidor de 2 capas

Manifiesto sobre la 3ra generacin de Bases de datos

Arquitectura Cliente/Servidor en tres capas

1. Evolucin e Historia de las BDs

tienen sus raices en el lenguaje SIMULA el

Buscando establecer un estandar

Buscando establecer un estandar

Productos comerciales recientes (listado parcial)

ObjectDB: Es una Base de Datos java pura, ObjectDB est

Productos comerciales recientes (continuacin..)

Otros productos y prototipos que podemos agregar a este listado

Respecto a las relacionales, todas (Oracle, IBM DB2, Informix,

1. Evolucin e Historia de las BDs

Porqu surgen las BDOO?

1. Por necesidades de los lenguajes de programacin OO

2. Por las limitaciones de las BD relacionales

2. Las limitaciones de las BD relacionales...

Si se quieren almacenar datos alfanumricos de pacientes, por

Necesidades de las nuevas aplicaciones:

de objetos complejos y datos multimedia

navegacional y de conjunto de registros

de los datos y procedimientos asociados

extensibles mediante TD definidos por el usuario

El conjunto de tipos predefinidos del

1. Evolucin e Historia de las BDs

SGBDOO vs. SGBD de tercera generacin...

Los Sistemas de Bases de Datos Orientadas a

Estn fuertemente influenciados por los lenguajes

Conserva un modelo compatible con el Modelo

Extension de SQL para incorporar nuevas

Extensin de tipos, objectos, herencia,

3. SGBDOO vs. SGBD de tercera generacin

Enfoques de implementacin de SGBD de Objetos

ORACLE, IBM, MICROSOFT,

OBJECTSTORE, O2, ONTOS,

3. SGBDOO vs. SGBD de tercera generacin

Manifiesto de los SGBDOO

Tres tipos de caractersticas:

OBLIGATORIAS: Imprescindible satisfacerlas para merecer el

ABIERTAS: Soluciones igualmente aceptables que quedan al

3. SGBDOO vs. SGBD de tercera generacin

Manifiesto de los SGBDOO

Por ser SGBD

3. SGBDOO vs. SGBD de tercera generacin

Manifiesto de los SGBDOO

3. SGBDOO vs. SGBD de 3ra generacin

Manifiesto de los SGBD de 3 Generacin

Principio 1: Adems de los servicios tradicionales de

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

3. SGBDOO vs. SGBD de 3ra generacin

Manifiesto de los SGBD de 3 Generacin

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