UNIDAD 2

2.1 El modelo de datos orientado a objetos.

Estructura de una BD OO.

El paradigma orientado a objetos se basa en el encapsulamiento de datos y del código relacionados con cada objeto en una sola unidad. Conceptualmente, todas las interacciones entre cada objeto y el resto del sistema se realizan mediante mensajes. Por lo tanto, la inferfaz entre cada objeto y el resto del sistema se define mediante un conjunto de mesajes permitidos.

En general, cada objeto está asociado con:

• Un conjunto de variables que contiene los datos del objeto;
las variables corresponden con los atributos del modelo E-R.

• Un conjunto de mensajes a los que responde; cada mensaje
puede o no tener parámetros o tener uno o varios.

• Un conjunto de métodos, cada uno de los cuales es el código
que implementa un mensaje; el método devuelve un valor
como respuesta al mensaje.

Mensaje en entorno OO no implica uso de mensajes físicos en redes informáticas. Por el contrario, hace referencia al intercambio de solicitudes entre los objetos, independientemente de los detalles correctos de su implementación. Se utiliza a veces la expresión invocar un método para detonar al hecho de enviar un mensaje a un objeto y la ejecución del método correspondiente.



EJEMPLOS:

CLASES DE OBJETOS
class empleado {

/ / Variables

string nombre;

strin dirección;

date fecha de alta;

int sueldo;

/ / Mensajes

int sueldo-anual ();

string obtenerNombre ();

string obtenerDireccion ();

int definirDireccion (string nueva-dir);

int antigüedad();

};

Generalmente en una base de datos hay muchos objetos similares (se entiende que responden a los mismos mensajes, utilizan los mismos métodos y tienen variables del mismo nombre y tipo). Por tanto sería un derroche definir por separado cada uno de estos objetos. Por tanto, los objetos se agrupan para formar clases. Todos los objetos de una clase comparten una definición común, pese a que se diferencien en los valores asignados a las variables.

El concepto de clase del modelo orientado a objetos se corresponde con el concepto de entidad del modelo E-R.

El ejemplo Empleado muestra las variabes y los mensajes que responden a los objetos de la clase; no se muestran aquí los métodos para el tratamiento de los mensajes.

Los principales conceptos que se utilizan en las BDOO son:

A. IDENTIDAD DE OBJETOS.

Un sistema de BDOO provee una identidad única a cada objeto independiente almacenado en la base de datos. Esta identidad única suele implementarse con un identificador de objeto único, generado por el sistema, u OID. El valor de un OID no es visible para el usuario externo, sino que el sistema lo utiliza a nivel interno para identificar cada objeto de manera única y para crear y manejar las referencias entre objetos.

La principal propiedad que debe tener un OID es la de ser inmutable; es decir, el valor del OID para un objeto en particular nunca debe cambiar. Esto preserva la identidad del objeto del mundo real que se está presentando. También es preferible que cada OID se utilice sólo una vez; esto es aunque un objeto se elimine de la Base de datos, su OID no se deberá asignar a otro objeto. Estas dos propiedades implican que el OID no debe depender del valor de ningún atributo del objeto, pues estos valores pueden cambiar. También suele considerarse inapropiado basar el OID en la dirección física del objeto en el almacenamiento, ya que una reorganización de los objetos de la base de datos podría cambiar los OID. Sin embargo, algunos sistemas sí usan la dirección física como OID para aumentar la eficiencia de la obtención de los objetos. Si la dirección física cambia, puede colocarse un apuntador indirecto en la dirección anterior, dando la nueva ubicación física del objeto. Un sistema de BDOO debe contar con algún mecanismo para generar los OID con la propiedad de inmutabilidad.
Algunos modelos de datos OO requieren que todo se represente como un objeto, ya sea un valor simple o un objeto complejo; así, todo valor básico, como un entero, una cadena o un valor booleano, tiene un OID. Con ello dos valores básicos pueden tener diferentes OID, lo cual es muy útil en algunos casos. Por ejemplo, en algunas ocasiones se podría usar el valor entero 50 para representar un peso en Kilogramos, y en otras para referirse a la edad de una persona. Así podrían crearse dos objetos básicos con diferentes OID, y ambos tendrían el mismo valor básico de 50. Aunque resulta útil como modelo teórico, esto no es muy práctico porque puede obligar a generar demasiados OID. Por ello también , la mayor parte de los sistemas de BDOO permiten representar tanto objetos como valores. Todo objeto debe tener un OID inmutable, pero los valores no tienen OID y se representan así mismo.

* Los objetos tienen identidades únicas, independientes de
los valores de sus atributos.

* La estructura orientada a objetos automáticamente impone
las restricciones relacionales, generalmente más aplicables:
dominio, llave integridad de entidad e integridad referencial.

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 programables, 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:

• Identidad de objetos

• Constructores de tipos

• Encapsulamiento

• Compatibilidad con los lenguajes de programación

• Jerarquías de tipos y herencia

• Manejo de objetos complejos

• Polimorfismo y sobrecarga de operadores

• 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

• Interno.- Como se van a guardar los objetos (disco duro)
• Conceptual.- Como guardar la estructura
• 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

• Diseño asistido por computadora CAD
• Fabricación asistida por computadora CAM
• Ingeniería de software asistido por computadora CASE
• Sistemas de gestión de red
• Sistemas de información de oficina y sistemas multimedia OIS
• Sistema autoedición digital
• Sistemas de información geográfica GIS
• Sistemas Web interactivos dinámicos

2.1.3 PRODUCTOS

SGBD libres.

·                     MySQL Licencia Dual, depende el uso (no se sabe hasta cuando, ya que la compro Oracle). Sin embargo, existen 2 versiones: una gratuita que sería equivalente a la edicion “express” SQL server de Windows y otra más completa de pago, ese pago se haría en la licencia de ella ya que permitiría usarse en otras distribuciones sin usar la licencia GNU.

·                     PostgreSQL (http://www.postgresql.org Postgresql) Licencia 

·                     BSDFirebird basada en la versión 6 de InterBase, Initial Developer’s PUBLIC LICENSE Version 1.0.

·                     SQLite (http://www.sqlite.org SQLite) Licencia Dominio PúblicoDB2 Express-C (http://www.ibm.com/software/data/db2/express/)

·                     Apache Derby (http://db.apache.org/derby/)

SGBD no libres

·                     Advantage Database

·                     dBase

·                     FileMaker

·                     Fox Pro

·                     IBM DB2 Universal Database (DB2 UDB)

·                     IBM Informix

·                     Interbase de CodeGear, filial de Borland

·                     MAGIC

·                     Microsoft Access

·                     Microsoft SQL Server

·                     NexusDB

·                     Open Access

·                     Oracle

·                     Paradox

·                     PervasiveSQL

·                     Progress (DBMS)

·                     Sybase ASE

·                     Sybase ASA

·                     Sybase IQ

·                     WindowBase

·                     IBM IMS Base de Datos Jerárquica

·                     CA-IDMS

SGBD no libres y gratuitos

·                     Microsoft SQL Server Compact Edition Basica

·                     Sybase ASE Express Edition para Linux (edición gratuita para Linux)

·                     Oracle Express Edition 10.

2.2 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 unico. 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.

Herencia

Las clases o tipos heredan de sus ancestros.

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.