Download Diapositiva 1 - BasesAvanzadas

Í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 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 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.
Evolución de la tecnología de BD: Dimensiones
FUNCIONALIDAD/
INTELIGENCIA
BD Distribuidas
Multi BD
BD Federadas
BDweb
BD Móviles
…
DISTRIBUCIÓN/
INTEGRACIÓN
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. Evolución e Historia…
1960
Primeros productos de bases de datos
Estándar Codasyl (Modelo de Red)
1970
Modelo Relacional
Prototipos SGBDR
Trabajos teóricos 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
Estándares SQL (ANSI/ISO)
Herramientas CASE
Manifiesto sobre bases de datos orientadas a objetos
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)
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)
ODMG 3.0
SQL:1999
XML
ODMG 1.0
SQL-86
SQL
Modelo E-R
Modelo Relacional
Standard CODASYL
1. Evolución e Historia…
Hierarchical
Network
Relational
Object-Oriented
Object-Relational
Semi-Structured
XML
1960
1970
1980
1990
2000
ver>>>
ver>>>
Í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 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
Orígenes
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 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
Orígenes
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 año 1985
1. Evolución 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. Evolución 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 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 - 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 común. Aunque no
logran el objetivo, sus esfuerzos tuvieron influencia en OQL (object
query language).
1. Evolución e historia…
Buscando establecer un estandar…
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.
1. Evolución e historia …
Historia reciente…
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…
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.
1. Evolución e historia…
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 .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 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
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 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: 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:
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.)
6
BDOO: Motivación
2. Las limitaciones de las BD relacionales...
Estructuras muy simples (1FN)
Poca riqueza semántica
No 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
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.
BDOO: Motivación
Necesidades de las nuevas aplicaciones:
►Soporte
de objetos complejos y datos multimedia
►Identificadores
►Soporte
únicos
de referencias e interrelaciones
►Manipulación
►Jerarquías
navegacional y de conjunto de registros
de objetos y herencia
►Integración
de los datos y procedimientos asociados
►Modelos
extensibles mediante TD definidos por el usuario
►Gestión
de versiones
El conjunto de tipos predefinidos del
sistema de BD debe ser Extensible,
►Facilidades de evolución
permitiendo definir tipos nuevos.
No debe haber distinción
►Transacciones de larga duración
en cuanto al uso de los
tipos definidos por el
►Interconexión e interoperabilidad
sistema y los extendidos
Í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 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 generación...
Lenguaje de Programación
Orientado a Objetos
Persistencia
Base de Datos
Orientada a Objetos
Base de Datos
Relacional
Orientación
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 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.
BDOR:
Base de Datos
Objeto-Relacional
(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
ORACLE, IBM, MICROSOFT,
INFORMIX, SYBASE, ...
SQL:2003
Continuidad con la tecnología
relacional / Conservación 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 tecnología /
Riguroso apego a los principios de
la OO
3. SGBDOO vs. SGBD de tercera generación
Manifiesto de los SGBDOO
Atkinson, Bancilhon, DeWitt. Dittrich, Maier, Adonik (1989)
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.
3. SGBDOO vs. SGBD de tercera generación
Manifiesto de los SGBDOO
Características obligatorias: las reglas de oro
Por ser SGBD
• Persistencia
• Concurrencia
• Recuperación ante fallos
• Gestión del almacenamiento secundario
• Lenguajes ad-hoc para manipulación
volver
Por ser OO
• Objetos complejos
• Identidad del objeto
• Encapsulamiento
• Tipos o clases
Overriding, overloading and late binding
• Herencia
• Polimorfismo, sobrecarga y vinculación dinámica
• Extensibilidad
• Completitud computacional (lenguaje de propósito general)
3. SGBDOO vs. SGBD de tercera generación
Manifiesto de los SGBDOO
Características opcionales
• Herencia múltiple
• Verificación e inferencia de tipos
• Distribución
• Transacciones de diseño
• Versiones
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
Manifiesto de los SGBD de 3º 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.
3. SGBDOO vs. SGBD de 3ra generación
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.
3. SGBDOO vs. SGBD de 3ra generación
Manifiesto de los SGBD de 3º Generación
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
Pros de los OODBMS
Base de Datos
Orientadas a
Objetos (BDOO)
•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.
BDOO
Pros de los OODBMS
Base de Datos
Orientadas a
Objetos (BDOO)
•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.
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 teóricos más sólidos.
Base de Datos
Objeto-Relacional
(BDOR)
• 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
3. SGBDOO vs. SGBD de tercera generación
Productos y estándares
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 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
Comparación de standards para DBMS
Estándar
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. SGBDOO vs. SGBD de tercera generación
3.4 Convergencia
Integración
Programa
relacional
BD relacional
Programa
orientado a
objetos
BDOO
3. SGBDOO vs. SGBD de tercera generación
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
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 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. 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.
4. Características de los SGBDOO
SGBDOO = SGBD+ OO
Funcionalidades de un SGBDOO =
Funcionalidades de un SGBD
+
Funcionalidades de la OO
4. Características de los SGBDOO
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. Características de los SGBDOO
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. Características de los SGBDOO
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
4. Características de los SGBDOO
4.2.1 Persistencia y manipulación del esquema
Las BD sin OO almacenan sólo 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 manipulación y administración de los módulos
de código, eliminando la necesidad de vincular (link) dicho
código con las aplicaciones
Aumentar la flexibilidad permitiendo especificar en que sitio de
una red se va a ejecutar una operación
4. Características de los SGBDOO
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.
4. Características 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 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. Características 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 (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. Características de los SGBDOO
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. Características de los SGBDOO
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. Características 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 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…).
Los SGBD relacionales continúan siendo
mucho más potentes en este sentido.
4. Características 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. Características de los SGBDOO
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
Alumno#
NombreAlumno
Dirección
1
Hidalgo Juan
M. Zaballa 100 N
2
Gonzales Irene
Los Alerces 810 S
3
Sanchez Clara Inés
4
Romero Diego
5
Martinez Analía
Estudia
Alumno#
Curso#
1
C1
2
T2
3
T2
4
Q9
5
F3
Para obtener:
"Nombre de alumnos que cursan
Teología“
‘Ir’ a curso para encontrar el
curso# corresp. a Teología (i.e.T2)
Curso
Curso#
Mendoza 536 N
Mitre 213 O
Ig. De la Roza 5410 O
NombreCurso
C1
Computación
F3
Filosofía
Q9
Quimica
T2
Teología
‘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 Alumno–Curso
OBJETO
CURSO
Curso=Teología
Curso# =T2
Alumnos
Next
Next
Nil
Alumno# =3
NombreAlumno=Sanchez Inés
Alumno# =2
NombreAlumno=Gonzales Irene
Curso
OBJETO
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 NombreAlumno
Este proceso es llamado navegación, notar que depende de punteros y que
muchos de ellos deberán ser persitentes.