2.1. EL MODELO DE DATOS
ORIENTADO A OBJETOS.
Desde
la aparición de la programación orientada a objetos (POO u OOP) se empezó a
pensar en bases de datos adaptadas a estos lenguajes.
La
programación orientada a objetos permite cohesionar datos y procedimientos,
haciendo que se diseñen estructuras que poseen datos y procedimientos; haciendo
que se diseñen estructuras que poseen datos (atributos) en las que se definen
los procedimientos operaciones) que pueden realizar con los datos. En las bases
orientadas a objetos se utiliza esta misma idea.
A
través de este concepto se intenta que estas bases de datos consigan arreglar
las limitaciones de las relacionales. Por ejemplo, el problema de la herencia
(el hecho de que no se puedan realizar relaciones de herencia entre las
tablas), tipos definidos por el usuario, disparadores (triggers) almacenables
en la base de datos, soporte multimedia...
Se
supone que son las bases de datos de tercera generación (la primera fue las
bases de datos en red y la segunda las relacionales), lo que significa que el
futuro parece estar a favor de estas bases de datos. Pero siguen sin reemplazar
a las relacionales, aunque son el tipo de base de datos que más está creciendo
en los últimos años.
Su
modelo conceptual se suele diseñar en UML y el lógico actualmente en ODMG
(Object Data Management Group), grupo de administración de objetos de datos,
organismo que intenta crear estándares para este modelo.
2.1.1. CARACTERÍSTICAS
DE LOS SGBDOO.
1.-Debe
soportar objetos complejos. Debe ser posible construir objetos complejos
aplicando constructores a objetos básicos.
2.-Identidad
del objeto. Todos los objetos deben tener un identificador, el cual es
independiente de los valores de sus atributos.
3.-Encapsulamiento.
Los programadores solo tienen acceso a la interfaz de los métodos, y los datos
e implementación de estos métodos están en los objetos.
4.-Tipos
o clases. El esquema de una base orientada a objetos contiene un conjunto de
clases o tipos.
5.-Tipos
o clases deben ser capaces de heredar de sus súper-tipos o superclases los
atributos y los métodos.
6.-La
sobrecarga debe ser soportada, los métodos deben poder aplicarse a diferentes
tipos.
7.-El
DML debe ser completo. El DML en los sistemas gestores de bases de datos
orientados a objetos debe ser un lenguaje de programación de propósito general.
8.-El
conjunto de tipos de datos debe ser extensible. No habrá distinción entre los
tipos definidos por el usuario y los tipos definidos por el sistema,
9.-Persistencia
de datos. Los datos deben mantenerse después de que la aplicación que los creó
haya finalizado, el usuario no tiene que hacer copia explícitamente.
10.-El
SGBD debe ser capaz de manejar bases de datos grandes.
11.-El
SGDB debe soportar la concurrencia. Debe disponer del mecanismo para el control
de la concurrencia.
12.-Recuperaci¢n.
El sistema gestor debe de proveer mecanismos de recuperación de la información
en caso de fallo de sistema.
13.-El
SGDB debe proveer de manera fácil de hacer consultas.
2.1.2. TIPOS DE SGBDOO.
Las
Bases de datos orientados a objetos se propusieron con la idea de satisfacer
las necesidades de las aplicaciones más complejas. El enfoque orientado a
objetos ofrece la flexibilidad para cumplir con algunos de estos requerimientos
sin estar limitado por los tipos de datos y los lenguajes de consulta
disponibles en los sistemas de bases de datos tradicionales.
Como
cualquier Bases de Datos programable, una Base de Datos Orientada a Objetos
(BDOO) proporciona un ambiente para el desarrollo de aplicaciones y un depósito
persistente listo para su explotación. Una BDOO almacena y manipula información
que puede ser digitalizada (presentada) como objetos, además proporciona un
acceso ágil y permite una gran capacidad de manipulación.
Los
principales conceptos que se utilizan en las Bases de Datos Orientada a Objetos
(BDOO) son las siguientes:
1.
Identidad de objetos.
2.
Constructores de tipos.
3.
Encapsulamiento.
4.
Compatibilidad con los lenguajes de programación.
5.
Jerarquías de tipos y herencia.
6.
Manejo de objetos complejos.
7.
Polimorfismo y sobrecarga de operadores.
8.
Creación de versiones.
BDOO
Está
diseñada para simplificar la POO almacena objetos directamente en la base de
datos empleando las mismas estructuras que leguajes de programación.
SGBOO
Es
un sistema de objetos y un sistema de base de datos que almacena objetos
permitiendo la concurrencia y recuperación. Pueden tratar directamente con los
objetos sin hacer la traducción a tablas registros, para los programadores de
aplicación (general o específica) los objetos se conservan en su forma y tamaño
pueden compartirse con múltiples usuarios.
Niveles de abstracción
1.
Interno. - Como se van a guardar los objetos (disco duro).
2.
Conceptual. - Como guardar la estructura.
3.
Externo. - Lo que vamos a mostrar al usuario (interfaz).
Consideraremos
el problema de almacenar un coche en el garaje en un sistema de objetos, el
coche es un objeto, el garaje es un objeto y hay una operación simple que es
almacena el coche en el garaje. En el sistema relacional todos los datos se
traducen en tablas, entonces el coche debe de ser desarmado, las llantas se
colocan en un lugar, los birlos en otro lugar, por la mañana antes de salir hay
que componer el coche antes de conducir.
Aplicaciones de la BDOO
1.
Diseño asistido por computadora CAD.
2.
Fabricación asistida por computadora CAM.
3.
Ingeniería de software asistido por computadora CASE.
4.
Sistemas de gestión de red.
5.
Sistemas de información de oficina y sistemas multimedia OIS.
6.
Sistema autoedición digital.
7.
Sistemas de información geográfica GIS.
8.
Sistemas Web interactivos dinámicos.
2.1.3. PRODUCTOS.
El
número de productos para utilizar XML con Bases de Datos está creciendo a una
gran velocidad. Nuevos productos entran al mercado de forma constante. Aquí se
realiza una clasificación de estos productos, mencionando cuales son las
características genéricas de los mismos, que funcionalidades brindan y se
analizan algunos de estos productos existentes en el mercado.
Antes
de continuar, hay que realizar la aclaración de que los documentos XML
pertenecen a dos categorías: "basados en datos" y "basados en documentos".
Los documentos XML "basados en datos" son en los que XML es usado
como un transporte de datos. Estos son por ejemplo órdenes de compra, registros
de pacientes y datos científicos. Los "basados en documentos" son en
los que XML es usado para representar documentos, como un manual de usuario,
páginas estáticas, folletos de marketing. Este último tipo de documento se
caracteriza por su estructura irregular.
Para
grabar y recuperar datos en un documento "basados en datos", se
necesitará una Base de datos, como puede ser una Base de Datos relacional o una
orientada a objetos.
Para
grabar y recuperar datos en un documento "basados en documentos", se
necesita una Base de Datos de XML o un Sistema de Administración de Contenidos.
Ambos están diseñados para almacenar fragmentos del contenido, como
procedimientos, capítulos, y glosarios, y pueden incluir metadatos, como nombre
del autor, fecha de revisión, etc. Un Sistema de Administración de Contenidos
generalmente tiene funcionalidades adicionales, como editores, controladores de
versiones, etc. [Bourret R., XML].
En
años recientes, han aparecido muchos prototipos experimentales y sistemas de
bases de datos comerciales orientados a objetos. Entre los primeros se
encuentran los sistemas:
Prototipos Experimentales
.
ORION, OpenOODB, IRIS, ODE y
.
el proyecto ENCORE/ObServer.
Y
entre los sistemas disponibles en el mercado están:
Sistemas
de Bases de Datos Comerciales Orientados a Objetos
.
GEMSTONE/OPAL de ServicLogic,
.
ONTOS de Ontologic,
.
Objectivity de Objectivity Inc.,
.
Versant de Versant Technologies,
.
ObjecStore de Object Design y
.
O2 de O2 Technology.
Esta
es solo una lista parcial de los prototipos experimentales y de los sistemas de
bases de datos comerciales orientados a objetos. Desafortunadamente, es aún
demasiado pronto para saber cuáles sistemas se instalarán como líderes en este
campo.
2.2. EL ESTÁNDAR ODMG.
Este
Modelo estándar ODMG, especifica los elementos que se definirán, y en qué
manera se hará, para la consecución de persistencia en las Bases de datos
orientadas a objetos que soporten el estándar. Consta de un lenguaje de
definición de objetos, ODL, que especifica los elementos de este modelo. Un
grupo de representantes de la industria de las bases de datos formaron el ODMG
(Object Database Management Group) con el propósito de definir estándares para
los SGBD orientados a objetos. Este grupo propuso un modelo estándar para la
semántica de los objetos de una base de datos. Su última versión, ODMG 3.0,
apareció en enero de 2000.
El
estándar ODMG es un producto de consorcio internacional OMG, el cual
principalmente proporciona técnicas orientadas a objetos para la ingeniería de
software. Sus estándares pueden ser aceptados por empresas certificadas como
ISO. El estándar OSMG es el modelo para la semántica de los objetos de una base
de datos. Permite portar tanto los diseños como las implementaciones en
diversos sistemas compatibles.
ODMG está compuesto
por:
Modelo de Objeto
El
modelo de objetos ODMG permite que tanto los diseños, como las
implementaciones, sean portables entre los sistemas que lo soportan. Dispone de
las siguientes primitivas de modelado:
Los
componentes básicos de una base de datos orientada a objetos son los objetos y
los literales. Un objeto es una instancia autocontenida de una entidad de
interés del mundo real. Los objetos tienen algún tipo de identificador único.
Un literal es un valor específico, como “Amparo” o 36. Los literales no tienen
identificadores. Un literal no tiene que ser necesariamente un solo valor,
puede ser una estructura o un conjunto de valores relacionados que se guardan
bajo un solo nombre.
Los
objetos y los literales se categorizan en tipos. Cada tipo tiene un dominio
específico compartido por todos los objetos y literales de ese tipo. Los tipos
también pueden tener comportamientos. Cuando un tipo tiene comportamientos,
todos los objetos de ese tipo comparten los mismos comportamientos. En el
sentido práctico, un tipo puede ser una clase de la que se crea un objeto, una
interface o un tipo de datos para un literal (por ejemplo, integer).
Un
objeto se puede pensar como una instancia de un tipo. Lo que un objeto sabe
hacer son sus operaciones. Cada operación puede requerir datos de entrada
(parámetros de entrada) y puede devolver algún valor de un tipo conocido. Los
objetos tienen propiedades, que incluyen sus atributos y las relaciones que
tienen con otros objetos. El estado actual de un objeto viene dado por los valores
actuales de sus propiedades. Una base de datos es un conjunto de objetos
almacenados que se gestionan de modo que puedan ser accedidos por múltiples
usuarios y aplicaciones. La definición de una base de datos está contenida en
un esquema que se ha creado mediante el lenguaje de definición de objetos ODL
(Object Definition Language) que es el lenguaje de manejo de datos que se ha
definido como parte del estándar propuesto para las bases de datos orientadas a
objetos.
Lenguaje de definición
de objeto ODL
ODL
es un lenguaje de especificación para definir tipos de objetos para sistemas
compatibles con ODMG. ODL es el equivalente del DDL (lenguaje de definición de
datos) de los SGBD tradicionales.
Define
los atributos y las relaciones entre tipos, y especifica la signatura de las
operaciones. La sintaxis de ODL extiende el lenguaje de definición de
interfaces (IDL) de la arquitectura CORBA (Common Object Request Broker
Architecture).
Lenguaje de Consulta de
objetos OQL
OQL
es un lenguaje declarativo del tipo de SQL que permite realizar consultas de
modo eficiente sobre bases de datos orientadas a objetos, incluyendo primitivas
de alto nivel para conjuntos de objetos y estructuras. Está basado en SQL-92,
proporcionando un súperconjunto de la sintaxis de la sentencia SELECT.OQL no
posee primitivas para modificar el estado de los objetos ya que las modificaciones
se pueden realizar mediante los métodos que ´éstos poseen. La sintaxis básica
de OQL es una estructura SELECT...FROM...WHERE..., como en SQL.
2.3. IDENTIDAD Y
ESTRUCTURA DE OBJETOS
Identidad
La
identidad es la propiedad que permite diferenciar a un objeto y distinguirse de
otros. Generalmente esta propiedad es tal, que da nombre al objeto. Tomemos por
ejemplo el "verde" como un objeto concreto de una clase color; la
propiedad que da identidad única a este objeto es precisamente su
"color" verde. Tanto es así que para nosotros no tiene sentido usar
otro nombre para el objeto que no sea el valor de la propiedad que lo
identifica.
En
programación la identidad de los objetos sirve para comparar si dos objetos son
iguales o no. No es raro encontrar que en muchos lenguajes de programación la
identidad de un objeto esté determinada por la dirección de memoria de la
computadora en la que se encuentra el objeto, pero este comportamiento puede
ser variado redefiniendo la identidad del objeto a otra propiedad.
Estructura
Es
la disposición, distribución y orden de las partes del cuerpo de una cosa
determinada inanimada, que puede ser perceptible por algún sentido, y se puede
accionar sobre ella.
Desglosando
la definición, es de considerar que objeto es una cosa, que puede ser material
real (materia con una forma definida, que se puede percibir con algún sentido
(vista, tacto, etc.), ejemplo una mesa, o una manzana), o abstracta (por
ejemplo una idea, o un proyecto que todavía no se concreta o se hace real), y
que esa cosa u objeto, está conformado por partes (aún lo más pequeño, como el
átomo, se forma por un conjunto de elementos), y las mismas están dispuestas,
ordenadas, o acomodadas de tal forma que conforman un cuerpo, ya sea que forme
parte de la naturaleza, o haya sido creado por el ser humano (en este caso
entonces es una obra de ingenio).
2.4. ENCAPSULAMIENTO,
HERENCIA Y POLIMORFISMO EN BDOO.
Encapsulamiento
El
encapsulamiento se centra en la implementación que da lugar al comportamiento
observable de un objeto. El encapsulamiento se consigue a menudo mediante la
ocultación de información, es decir, se basa en ocultar todos los secretos de
un objeto que no contribuyen a sus características esenciales.
El
encapsulamiento proporciona, por tanto, barreras explícitas entre abstracciones
diferentes. Existen dos visiones diferentes del encapsulamiento [ATK89], la primera
y original que es la del lenguaje de programación; y la segunda que es la
adaptación de esa visión para la base de datos.
Desde
el punto de vista de las bases de datos, esto se traduce en el hecho de que un
objeto abarca operaciones y datos, pero con una diferencia. En las bases de
datos no está claro si la parte estructural es parte de la interfaz (depende
del sistema), mientras que en los lenguajes de programación la estructura de
datos es claramente parte de la implementación y no de la interfaz. Como se
puede observar, el encapsulamiento proporciona una forma lógica de independencia
de los datos, ya que se puede cambiar la implementación de un tipo sin cambiar
ninguno de los programas que usan ese tipo.
Herencia
Ventajas de la herencia
·
Ayuda al modelado porque proporciona
una descripción concisa y precisa del mundo.
·
Ayuda a compartir especificaciones e
implementaciones en las aplicaciones.
Tipos
de herencia a destacar en los sistemas de gestión de bases de datos
Herencia
de sustitución: en cualquier lugar donde podamos tener un objeto de tipo
podemos sustituirlo por un objeto de tipo t si t hereda de t’.
Herencia
de restricción: es un subcaso de la herencia de inclusión. Un tipo t es un
subtipo de si está formado por todos los objetos de t que satisfacen una
restricción dada.
Herencia
d especialización: un tipo t es un subtipo de t’, si los objetos de tipo t son
objetos de tipo t’ que contienen información más específica.
Polimorfismo
Existen
casos en los que se desea tener el mismo nombre para diferentes operaciones.
Supongamos la operación dibuja que toma un objeto como entrada y lo dibuja en pantalla.
Dependiendo del tipo de objeto (cuadrado, estrella, flecha,…) debemos emplear
diferentes mecanismos de visualización. Es decir, necesitamos visualizar un
conjunto cuyos miembros no se conocen en tiempo de compilación.
En
una aplicación que emplee el sistema convencional, habrá tantas operaciones
como figuras a representar: dibuja cuadrado, dibuja estrella, dibuja flecha
etc. En un sistema orientado a objetos se definirá la operación en una clase
más general.
Para
proporcionar esta nueva funcionalidad, el sistema no puede asociar los nombres
de las operaciones con los métodos correspondientes en tiempo de compilación;
se hará en tiempo de ejecución. Esto es lo que se conoce como ligadura tardía y
dificulta o imposibilita el chequeo de tipo
Una
base de datos orientada a objetos es una base de datos que incorpora todos los
conceptos importantes del paradigma de objetos:
Encapsulación
– Propiedad que permite ocultar la información al resto de los objetos,
impidiendo así accesos incorrectos o conflictos.
Herencia
– Propiedad a través de la cual los objetos heredan comportamiento dentro de
una jerarquía de clases.
Polimorfismo
– Propiedad de una operación mediante la cual puede ser aplicada a distintos
tipos de objetos.
En
bases de datos orientadas a objetos, los usuarios pueden definir operaciones
sobre los datos como parte de la definición de la base de datos. Una operación
(llamada función) se especifica en dos partes. La interfaz (o signatura) de una
operación incluye el nombre de la operación y los tipos de datos de sus
argumentos (o parámetros). La implementación (o método) de la operación se especifica
separadamente y puede modificarse sin afectar la interfaz. Los programas de
aplicación de los usuarios pueden operar sobre los datos invocando a dichas
operaciones a través de sus nombres y argumentos, sea cual sea la forma en la
que se han implementado. Esto podría denominarse independencia entre programas
y operaciones.
2.5. PERSISTENCIA,
CONCURRENCIA Y RECUPERACIÓN EN BDOO.
Persistencia
Esta
se refiere a la capacidad de manipular directamente los datos almacenados en
una base de datos usando un lenguaje de programación orientado a objetos. Esto
contrasta con una base de datos utilizada por SQL o una interfaz utilizada por
ODBC o JDBC. Utilizando un objeto de base de datos significa que se puede tener
un mayor rendimiento y se aminora la escritura de código. Con la persistencia
la manipulación de objetos se realiza directamente por el lenguaje de
programación de la misma manera que en la memoria, sin persistencia de objetos.
Esto se logra mediante el uso inteligente de almacenamiento en caché.
Concurrencia
Los
SMBDOO deben poder ser accesibles por múltiples usuarios. Cuando una aplicación
está accesando a una sección de la base de datos, otras aplicaciones deben
poder acceder a otras secciones de la base de datos. La concurrencia permite a
los usuarios cooperar y colaborar en una aplicación. Los mecanismos de control
de concurrencia son necesarios para reforzar las propiedades delas
transacciones (ACID). Los modos básicos de control de concurrencia son: Modo
Pesimista Modo optimista Modo mixto Modo semi-optimista. El modo pesimista
obliga a una transacción a esperar a que se resuelva el conflicto que pueda o
ponga en riesgo la concurrencia para dejarle continuar cuando el conflicto haya
sido resuelto.
El
modo optimista deje correr la transacción como si no ocurriera ningún conflicto
y resuelve este al final del commit, generalmente se emplea usando estampas de
tiempo y copias de los elementos de la transacción. El modo mixto combina
diferentes controles de concurrencia a diferentes objetos y tipos de datas en
una misma transacción. El modo semi-optimista es una variante del modo mixto que
no detiene a la transacción hasta que esta termina. Los principales mecanismos
de control de concurrencia son tres: Candados que prohíben accesos que puedan
provocar conflictos de acceso Estampas de tiempo. - estas permiten impedir
violaciones a los datos. Guardar múltiples versiones de los objetos de datos.
Recuperación
Con
recuperación nos referimos al proceso de aplicación de consistencia después de
que una transacción a abortado como resultado de fallas de hardware o problemas
de comunicación. Las fallas del sistema, tanto de hardware como de software no
deben repercutir en estados de inconsistencia de la base datos. La recuperación
es la técnica que asegura que eso no ocurra. La recuperación puede ser total o
parcial dependiendo de las circunstancias, de la recuperabilidad.
REFERENCIAS
http://carlosmariosd.wordpress.com/2013/12/03/2-1-2-tipos-de-sgbdoo/yhttp://topicos-1.wikispaces.com/1.1+Bases+de+datos+orientadas+a+objetos
No hay comentarios:
Publicar un comentario