Este documento presenta información sobre sistemas gestores de bases de datos orientados a objetos. Explica que estos sistemas surgieron para satisfacer las necesidades de aplicaciones que requerían estructuras de datos más complejas que las que podía manejar el modelo relacional. También resume las características principales de los SGBDOO, incluyendo el almacenamiento y manejo de objetos, y las diferencias con los SGBD relacionales. Por último, resume tres manifiestos importantes sobre los SGBDOO que definieron sus características esenciales.
1. UNIVERSIDAD NACIONAL DE TRUJILLO
FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS
Escuela Académico Profesional de Informática
SISTEMAS GESTORES DE BASE DE DATOS
ORIENTADO A OBJETOS
CURSO : BASE DE DATOS I
DOCENTE : Ms. RICARDO MANUEL GUEVARA RUIZ
ALUMNOS :
CAMPOS PULIDO, Miguel
DIAZ FERNANDEZ, Pedro Pablo
HOYOS IPARRAGUIRRE, Kevin
CICLO : V
TRUJILLO – PERÚ
2012
2. SISTEMAS GESTORES DE BASE DE DATOS ORIENTADOS A
OBJETOS
1. ¿POR QUÉ SURGEN LOS SGBDOO?
Los sistemas de gestión de bases de datos orientadas a objetos surgen debido a la falta de
capacidad semántica del Modelo Relacional para atender nuevos tipos de aplicaciones:
Diseño y fabricación en ingeniería (CASE, CAD/ CAM).
Bases de datos gráficas y de imágenes.
Bases de datos científicas.
Sistemas de información geográfica.
Bases de datos multimedia.
Acceso uniforme a sistemas de múltiples bases de datos.
Este tipo de aplicaciones necesita trabajar con datos de forma diferente a lo que
conocemos porque necesitan:
Estructuras más complejas para los objetos.
Transacciones de mayor duración.
Nuevos tipos de datos para almacenar imágenes o grandes bloques de texto.
Necesidad de definir operaciones no estándar, especificas para cada
aplicación.
Controlar versiones y configuraciones.
2. ¿QUÉ ES UN SGBD?
Un SGBD es un conjunto de datos relacionados entre sí y un grupo de programas para tener
acceso a esos datos. Las principales razones para emplear un SGBD son:
Tamaño: Cuando el volumen de información aumenta, es necesario algún sistema
que nos facilite el intercambio de información con memoria secundaria, la
búsqueda rápida, etc.
Concurrencia: Es necesario un mecanismo de control sobre la información cuando
sobre ella pueden existir varias personas o programas interactuando, de modo que
coordine sus accesos para que cada uno no invalide el trabajo realizado por el
resto.
Recuperación e Integridad: Cuando la información sobre la que se está trabajando
es importante, es necesario algún mecanismo que se encargue de protegerla de
pérdidas accidentales provocadas por fallos de energía, fallos de la propia
aplicación, etc.
Persistencia: Representa la posibilidad de que la información permanezca aún
después de desconectar el ordenador.
3. Además de lo anteriormente expuesto un SGBD suele proporcionar otras capacidades
adicionales, tales como:
Distribución: Posibilidad de que la información esté almacenada en lugares
diferentes. Los usuarios no necesitan conocer dónde está la información, el SGBD la
encuentra para ellos.
Seguridad: Permite restringir el acceso a la información a usuarios no autorizados.
Administración: Permite a los usuarios o administradores de bases de datos
examinar, controlar y ajustar el comportamiento del sistema. Permite por tanto
mantener las restricciones de integridad definidas por el usuario.
Un SGBD necesita para su funcionamiento dar soporte a tres áreas básicas mediante un
lenguaje para cada una de ellas:
Definición de datos: Debe permitir a los usuarios definir nuevas estructuras y
tipos de información.
Manipulación de Datos: Debe permitir acceder a las instancias de dichas
estructuras de información, permitiendo incluso su modificación.
Consultas (Query): Debe permitir a los usuarios enunciar declarativamente la
información que desean, siendo el propio SGBD quién se encargue de
obtenerla. El soporte para la consulta suele incluir un motor que examinará la
declaración de la información que se ha solicitado, elaborará un plan de
ejecución para obtenerla, optimizará ese plan basándose en el conocimiento
de la base de datos (índices, que información es local y cual es remota, etc.) y
finalmente la ejecutará.
3. ¿QUÉ ES UN SGBDOO?
Un SGBDOO es un sistema de objetos y un sistema de bases de datos. Se puede entonces
decir que un SGBDOO es un SGBD que almacena objetos, permitiendo concurrencia,
recuperación, etc. Para los usuarios tradicionales de bases de datos, esto quiere decir que
pueden tratar directamente con objetos, no teniendo que hacer la traducción a tablas o
registros. Para los programadores de aplicaciones, esto quiere decir que sus objetos se
conservan, pueden ser gestionados aunque su tamaño sea muy grande, pueden ser
compartidos entre múltiples usuarios, y se mantienen tanto su integridad como sus
relaciones.
Las bases de datos tradicionales almacenan sólo datos, mientras que las bases de datos
orientadas a objetos almacenan objetos, con una estructura arbitraria y un
comportamiento.
Ejemplo Para su Entendimiento:
En un sistema de objetos el coche es un objeto, el garaje es un objeto, y hay una operación
simple que es almacenar-coche-en-garaje. En un sistema relacional, todos los datos deben
ser traducidos a tablas, de esta forma el coche debe ser desarmado, y todos los pistones
almacenados en una tabla, todas las ruedas en otra, etc.
4. Por la mañana, antes de irse a trabajar hay que componer de nuevo el coche para poder
conducir (problema: al componer piezas puede salir una moto en vez de un coche).
Como podemos ver un coche se representaría dependiendo del tipo de sistema de gestión
de bases de datos:
Una posible solución sería traducir cada objeto a tablas, pero esto es una tarea tediosa, y
en el caso de utilizar datos complejos puede llegar a ser excesivamente complicado. El
problema de la traducción a tablas implica:
Tiempo de Desarrollo: El tiempo empleado en generar el código para la traducción
de objetos a tablas y viceversa.
Errores: Debidos precisamente a esa traducción.
Inconsistencia: Debida a que el ensamblaje/ desensamblaje puede realizarse de
forma diferente en las distintas aplicaciones.
Tiempo de Ejecución: Empleado en el ensamblaje/ desensamblaje.
Muchos vendedores de bases de datos relacionales están incorporando capas de objetos
sobre sus motores relacionales (basados en tablas), que son bastante útiles para la
integración con aplicaciones y bases de datos de objetos, y que pueden ayudar en la
generación de algunos códigos de ensamblaje/ desensamblaje, pero no mejora en absoluto
el tiempo de ejecución del problema (el coche todavía necesita ser ensamblado y
desensamblado).
5. 4. CARACTERÍSTICAS DE LAS BDOO Y DIFERENCIAS DE ESTAS CON RESPECTO A LAS
RELACIONES.
Mientras que en una BDR los datos a almacenar se almacenan representados en tablas en
un BDOO los datos se almacenan como objetos. Un objeto en BDOO como en POO es una
entidad identificable unívocamente que describe tanto el estado como el comportamiento
de una entidad del ‘mundo real’. El estado de un objeto es descrito mediante atributos
mientras que su comportamiento es definido mediante métodos.
Las características son:
Objetos: Cada entidad del mundo real se modela como un objeto.
La forma de identificar objetos es mediante un identificador de objetos (OID,
Object Identifier), único para cada objeto. Generalmente este identificador no es
accesible ni modificable para el usuario. Los OID son independientes del contenido.
Si dos objetos tienen el mismo estado pero diferentes OID, son equivalentes pero
tienen identidades diferentes.
Encapsulamiento: cada objeto contiene y define procedimientos (métodos) y la
interfaz mediante la cual se puede acceder a él y otros objetos pueden manipularlo.
Generalmente, los SGBDOO permiten al usuario especificar qué atributos y
métodos son visibles en la interfaz del objeto y pueden invocarse desde afuera.
Otros conceptos utilizados de la misma manera que en la POO son:
Clases.
Herencia simple, múltiple y repetida.
Polimorfismo de operación, de inclusión y paramétrico; ligadura tardía;
sobrecarga y suplantación o anulación.
Objetos complejos
Diferencias entre SGBD y SGBDOO
SGBD Relacionales:
Los datos residen en la base de datos y los procesos se encuentran en las
aplicaciones desarrolladas mediante el lenguaje de datos asociado al SGBD
(SQL) inmerso en un lenguaje de programación.
Desarrollo bajo Sistemas Relacionales:
Modelo conceptual de datos - modelo lógico.
Eficientes para aplicaciones tradicionales de negocios.
SGBD Orientados a Objetos
Gestionan objetos en los cuales están encapsulados los datos y las
operaciones que actúan sobre ellos.
Desarrollo bajo SGBDOO: un único modelo subyacente, implementado en
el SGBBOO, al que pueden acceder directamente las aplicaciones.
Intentan satisfacer necesidades de aplicaciones más complejas.
Característica clave: poder que dan al diseñador de la base de datos tanto
para especificar la estructura de los objetos complejos como las
operaciones que se pueden aplicar a estos objetos.
6. 5. MANIFIESTOS ACERCA DE LOS SGBDOO:
MANIFIESTO DE ATKINSON:
En 1989 se hizo el Manifiesto de los sistemas de base de datos orientados a objetos
el cual propuso trece características obligatorias para un SGBDOO y cuatro
opcionales. Las trece características obligatorias estaban basadas en dos criterios:
debía tratarse de un sistema orientado a objetos y un SGBD.
Características de los SGBDOO Puras:
Las características que debe seguir una sistema de gestión de bases de datos para
considerarse orientado a objetos se dividen en tres grupos:
Obligatorias – Trece reglas.
Opcionales, aquellas que pueden añadirse para mejorar el sistema pero
que no son obligatorias – Cinco reglas.
Abiertas, aquellas que el diseñador puede incluir para adaptar el sistema a
sus necesidades. – Cuatro reglas.
Características Obligatorias: “Las Reglas de Oro”
I. Tipos complejos
II. Identidad de objeto
III. Encapsulamiento
IV. Tipos y clases
V. Herencia
VI. Polimorfismo, sobrecarga y ligadura tardía
VII. Completud de cálculos
VIII. Extensibilidad
IX. Persistencia
X. Gestión de almacenamiento
XI. Concurrencia
XII. Recuperación
XIII. Facilidad de consultas ad-hoc
Características Opcionales
I. Herencia múltiple
II. Comprobación de tipos
III. Distribución
IV. Transacciones de diseño
V. Versiones
7. Características Abiertas
I. Paradigma de programación
II. Sistema de representación
III. Sistema de tipos
IV. Uniformidad
MANIFIESTO DE STONEBRAKER, 1990:
Se considera el manifiesto de definición de sistemas gestores de bases de datos de
tercera generación siendo:
SGBD primera generación: Sistemas Jerárquicos y de Red.
SGBD segunda generación: Sistemas Relacionales.
SGBD tercera generación: siguiente generación de sistemas de bases de
datos cuyos principios básicos de desarrollo presenta el manifiesto.
Las características se recogen en tres principios básicos junto con trece
proposiciones que indican los requerimientos más específicos de estos sistemas, las
cuales no difieren mucho de las trece características obligatorias que indicaba el
manifiesto de Atkinson.
Así los tres principios y las proposiciones para conseguirlos son los siguientes:
I. PRIMER PRINCIPIO:
“ADEMÁS DE LOS SERVICIOS TRADICIONALES DE GESTIÓN DE DATOS, LOS
SGDB DE TERCERA GENERACIÓN PROPORCIONARÁN GESTIÓN DE OBJETOS Y
REGLAS MÁS RICAS”
Proposiciones:
1.1. Los SGBD de la tercera generación debe tener un sistema de tipos rico.
1.2. La herencia es aconsejable.
1.3. La reutilización y la encapsulación son aconsejables.
1.4. Se deberían asignar IDO para los registros sólo si no está disponible una
clave primaria.
1.5. Las reglas de convertirán en una característica primordial de los futuros
sistemas. Las reglas no deberían asociarse con una función específica.
II. SEGUNDO PRINCIPIO:
“LOS SGDB DE TERCERA GENERACIÓN DEBEN INCLUIR A LOS SGBD DE
SEGUNDA”
Proposiciones:
2.1. Un SGBD de la tercera generación debe tener un lenguaje de acceso
declarativo y de alto nivel.
8. 2.2. Deben existir dos formas de especificar colecciones: por enumeración de
sus miembros o mediante un lenguaje de consulta.
2.3. Las vistas deben ser actualizables.
2.4. Los indicadores de resultados no deben aparecer en los datos.
III. TERCER PRINCIPIO:
“LOS SGDB DE TERCERA GENERACIÓN DEBEN ESTAR ABIERTOS A OTROS
SUBSISTEMAS”.
Proposiciones:
3.1. Se puede acceder a un SGBD de tercera generación desde múltiples
lenguajes de alto nivel.
3.2. Debe soportar la persistencia de las variables.
3.3. El lenguaje SQL es una forma universal de expresión de datos.
3.4. Las consulta y sus respuestas deben constituir el nivel más bajo de
comunicación entre un cliente y un servidor.
TERCER MANIFIESTO
El enfoque purista ha sido duramente criticado por expertos de bases de datos
relacionales:
“Los productos relacionales se apoyan en un lenguaje basado en la lógica,
que lleva más de dos mil años demostrando su validez”.
“Sería una pena desperdiciar más de veinte años de investigación y
desarrollo en bases de datos relacionales”.
El Tercer Manifiesto, DARWEN y DATE, 1995
Reinterpreta el modelo relacional bajo una visión orientada al objeto.
Propone un lenguaje D que proporciona algunas ventajas de la orientación
al objeto, como los tipos de datos y la herencia, manteniendo el
fundamento teórico del modelo relacional. No se trata de una extensión del
lenguaje SQL.
Según el manifiesto, tal lenguaje D, debe estar sujeto a una serie de
prescripciones, proscripciones y lo que denomina “sugerencias muy
fuertes” las cuales divide en categorías.
RM: surgen del Modelo Relacional
OO: no surgen del Modelo relacional
9. 6. VENTAJAS E INCONVENIENTES DE LAS BDOO:
Aunque los SGBDOO pueden proporcionar soluciones apropiadas para muchos tipos de
aplicaciones avanzadas de bases de datos, también tienen sus desventajas.
Las ventajas de un SGBDOO son:
Mayor capacidad de modelado. El modelado de datos orientado a objetos
permite modelar el ‘mundo real’ de una manera mucho más fiel. Esto se
debe a:
Un objeto permite encapsular tanto un estado como un
comportamiento
Un objeto puede almacenar todas las relaciones que tenga con
otros objetos
Los objetos pueden agruparse para formar objetos complejos
(herencia).
Ampliabilidad. Esto se debe a:
Se pueden construir nuevos tipos de datos a partir de los ya
existentes.
Agrupación de propiedades comunes de diversas clases e incluirlas
en una superclase, lo que reduce la redundancia.
Reusabilidad de clases, lo que repercute en una mayor facilidad de
mantenimiento y un menor tiempo de desarrollo.
Lenguaje de consulta más expresivo. El acceso navegacional desde un
objeto al siguiente es la forma más común de acceso a datos en un SGBDOO.
Mientras que SQL utiliza el acceso asociativo. El acceso navegacional es más
adecuado para gestionar operaciones como los despieces, consultas
recursivas, etc.
Adecuación a las aplicaciones avanzadas de base de datos. Hay muchas
áreas en las que los SGBD tradicionales no han tenido excesivo éxito como el
CAD, CASE, OIS, sistemas multimedia, etc. en los que las capacidades de
modelado de los SGBDOO han hecho que esos sistemas sí resulten efectivos
para este tipo de aplicaciones.
Mayores prestaciones. Los SGBDOO proporcionan mejoras significativas de
rendimiento con respecto a los SGBD relacionales. Aunque hay autores que
han argumentado que los bancos de prueba usados están dirigidos a
aplicaciones de ingeniería donde los SGBDOO son más adecuados. También
está demostrado que los SGBDR tienen un rendimiento mejor que los
SGBDOO en las aplicaciones tradicionales de bases de datos como el
procesamiento de transacciones en línea (OLTP).
10. Los inconvenientes de un SGBDOO son:
Carencia de un modelo de datos universal. No hay ningún modelo de datos
que esté universalmente aceptado para los SGBDOO y la mayoría de los
modelos carecen una base teórica.
Carencia de experiencia. Todavía no se dispone del nivel de experiencia del
que se dispone para los sistemas tradicionales.
Carencia de estándares. Existe una carencia de estándares general para los
SGBDOO.
Competencia. Con respecto a los SGBDR y los SGBDOR. Estos productos
tienen una experiencia de uso considerable. SQL es un estándar aprobado y
ODBC es un estándar de facto. Además, el modelo relacional tiene una
sólida base teórica y los productos relacionales disponen de muchas
herramientas de soporte que sirven tanto para desarrolladores como para
usuarios finales.
La optimización de consultas compromete la encapsulacion. La
optimización de consultas requiere una compresión de la implementación
de los objetos, para poder acceder a la base de datos de manera eficiente.
Sin embargo, esto compromete el concepto de encapsulación.
El modelo de objetos aún no tiene una teoría matemática coherente que le
sirva de base.
7. BIBLIOGRAFÍA:
http://topicosjvcarlos.wikispaces.com/file/view/bdoo.pdf
http://basededatos2010.wikispaces.com/file/view/BD+O-
O+ventajas+y+desventajas.pdf
http://www.l3onetworks.com/blog/?p=76
http://es.wikipedia.org/wiki/Base_de_datos_orientada_a_objetos
http://www.monografias.com/trabajos79/base-datos-orientadas-objetos/base-
datos-orientadas-objetos2.shtml
http://www.buenastareas.com/ensayos/Sistemas-Gestores-De-Bases-De-
Datos/2755666.html
http://www.forosdelweb.com/f21/base-datos-orientado-objetos-394261/
http://tejo.usal.es/~fgarcia/docencia/poo/02-03/trabajos/S1T3.pdf