Persistencia 2

[TEMAS SELECTOS PARA LAS BASES DE DATOS]

Tema IV

PERSISTENCIA (Segunda parte) Debido a que los objetos se crean durante la ejecución, no existe más allá del tiempo de ejecución del programa Se han desarrollado métodos para proporcionar la persistencia de objetos. Lo cual significa que la estructura del objeto se graba en algún medio de almacenamiento permanente.

Los objetos se crean al invocar a los constructores de objetos, los cuales son programas que obtienen la memoria principal y crean las estructuras necesarias para representar un objeto mediante un ejemplo concreto.

Los destructores de objetos son programas que desligan los objetos y liberan la memoria.

Los objetos pueden ser transitorios o persistentes.

Un objeto transitorio solo existe en la memoria volátil durante la ejecución de un programa. Cuando éste finaliza se pierde el objeto.

Un objeto persistente es aquel que se guarda en un almacenamiento permanente, por ejemplo: un disco Un objeto persistente sobrevive a la ejecución de un programa y puede volver a leer en la memoria desde el almacenamiento.

El objetivo de un ODBMS, es brindar un almacenamiento de objetos persistentes. Un objeto está conformado por datos y métodos, lo cual significa que un ODBMS diferente a un DBMS tradicional, debe almacenar los programas de objetos y también los datos.

Debido a que cada objeto de una clase especifica tiene el mismo conjunto de métodos, éstos necesitan almacenarse sólo una vez por clase, en contraste, lo elementos de los datos deben almacenarse una vez por cada caso de objetos.

Editado por Sandra Pérez Díaz

1

[TEMAS SELECTOS PARA LAS BASES DE DATOS]

Tema IV

La siguiente figura refleja lo anteriormente mencionado:

Datos del CLIENTE 100 Métodos del objeto CLIENTE

Datos del CLIENTE 200

Datos del CLIENTE 300 Los métodos del objeto se almacenan sólo una vez para cada clase. El dato del objeto se almacena sólo una vez por cada caso de objeto.

La siguiente imagen resume las estructuras de datos que existen después de que se ha creado un PEDIDO (ORDEN):

Ejemplo de las estructuras de datos objetos Objeto

Objeto VENDEDOR

CLIENTE

PEDIDO Número

PEDIDO fecha

PEDIDO Total

Artículos de línea Número de Nombre de Cantidad Cantidad Precio Artículo Artículo reordenada amplio Número de Nombre de Cantidad Cantidad Precio Artículo Artículo reordenada amplio Número de Nombre de Cantidad Cantidad Precio Artículo Artículo reordenada amplio

Objeto

Objeto PEDIDO

ARTICULO

En el objeto pedido existen datos básicos, incluyendo: PEDIDO. Número, PEDIDO. Fecha y PEDIDO. Total (Orden. Number, ORDEN. Date, ORDEN. Total), así como, un grupo Editado por Sandra Pérez Díaz

2

[TEMAS SELECTOS PARA LAS BASES DE DATOS]

Tema IV

repetitivo para los artículos en línea, el cual contiene ArtículoNúmero, ArtículoNombre, Cantidad, CantidadOrdenadaNuevamente y PrecioAmpliado (Item-Number, ItemName, Quiantity, a QuantityBackordered y Extended Price) Además los datos del pedido tienen un apuntador al objeto del CLIENTE asignado, un apuntador al objeto VENDEDOR asignado y un apuntador a cada ARTÍCULO (ITEM) para cada artículo en línea.

Por lo que, estos apuntadores son parte del objeto PEDIDO. Para hacer este objeto persistente, se deben almacenar todos estos datos.

Además aunque no se conoce su estructura, se debe almacenar cada objeto CLIENTE, VENDEDOR y ARTÍCULO. Los apuntadores poseen un problema en particular: en la mayoría de los lenguajes orientados a objetos, éstos se encuentran en alguna forma de dirección almacenada en memoria Dichas direcciones sólo son válidas durante la ejecución del programa, si éste termina y después se reinicia, las direcciones de los objetos serán diferentes.

Por lo tanto, cuando se almacena un objeto, los apuntadores almacenados en la memoria necesitan transformarse en un identificador único permanente que sea válido durante el tiempo de vida del objeto, se encuentre o no almacenado en la memoria.

El proceso de la transformación de los identificadores permanentes en direcciones almacenadas en la memoria se llama intercambio (swizzing) Es importante que recordemos que un objeto se define como los valores de los datos más los métodos.

Por lo tanto, para hacer persistente un objeto se deben guardar los métodos y los valores del objeto.

Sin embargo, a diferencia de los valores de datos, cada objeto de una clase específica tienen los mismo métodos, por lo que, sólo se necesitan almacenar los métodos una vez para todas las instancias del objeto en la clase del objeto.

TAREAS NECESARIAS PARA LA PERSISTENCIA DEL OBJETO Guardar los valores de los datos de los casos del objeto

Editado por Sandra Pérez Díaz

3

[TEMAS SELECTOS PARA LAS BASES DE DATOS]

Tema IV

Convertir los apuntadores de objetos almacenado en la memoria en identificadores únicos permanentes (intercambio).

Guardar los métodos de la clase del objeto.

PERSISTENCIA DE OBJETOS MEDIANTE ALMACENAMIENTO TRADICIONAL DE ARCHIVOS Los objetos pueden guardarse usando el almacenamiento tradicional de archivos, sin embargo, hacerlo le otorga una gran carga al programador.

El programador debe decidir crear un archivo que contenga métodos para todos los objetos y un segundo archivo que contenga los datos para todos los objetos.

Para llevar a cabo lo anterior, se necesita desarrollar una estructura generalizada para introducir los métodos y los datos en los archivos, así como, restaurarlos cada vez que sea necesario.

La siguiente figura muestra un ejemplo de dicho archivo, sólo para el almacenamiento de los elementos de datos.

EMPLEO DE UN ARCHIVO DE LONGITUD DETERMINADA QUE SOPORTE LOS DATOS DEL OBJETO Número de registros 1 2 3 4

Código del registro PEDIDO VENDEDOR CLIENTE ARTÍCULO DE LÍNEA

5

ARTÍCULO DE LÍNEA

…

…

Contenido PEDIDO 100 datos VENDEDEOR Jones datos CLIENTE 10000 datos Artículo de línea del PEDIDO 100 datos Artículo de línea del PEDIDO 100 datos …

Enlace 4 Nulo Nulo 5 Nulo …

Los objetos pueden hacerse persistente mediante el almacenamiento tradicional de archivos, un DBMS relacional o un ODBMS. Para hacer uso de dicho archivo, el programador tendrá que escribir el código en los métodos de Guardar para empacar o desempacar datos de objetos en estos registros, para encontrar los objetos solicitados, controlar el espacio disponible del archivo, etc.

Así mismo, el programador necesitara idear e implementar algoritmos de intercambio (swizzing) y de no intercambio (de- swizzing).

Además, es importante mencionar que existe un problema de secuencia: Editado por Sandra Pérez Díaz

4

[TEMAS SELECTOS PARA LAS BASES DE DATOS]

Tema IV

Todos los métodos se almacenan en archivos incluyendo los que almacenan y leen métodos.

Entonces, nos podemos preguntar: ¿Cómo es el método que lee el primer método que se obtiene?

Todos estos problemas pueden superarse: durante muchos años se han resuelto en los subsistemas de procesamiento de archivos del sistema operativo, pero se encuentra que la programación es lenta, tediosa, arriesgada y difícil.

Debido a estos problemas, el almacenamiento tradicional de archivos es viable para la persistencia del objeto solamente cuando la aplicación tenga algunos objetos simples, cuyas estructuras no cambien.

PERSISTENCIA DE OBJETOS MEDIANTE EL DBMS RELACIONAL Otro enfoque sobre la persistencia es utilizar los productos comerciales del DBMS relacional.

A diferencia del procesamiento tradicional de archivos, este enfoque le da una carga pequeña al programador, debido a que el DBMS controla las tareas de la administración básica de archivos, tales como la asignación de registros, administración de espacio, etc.

Las tareas de la administración de datos que el programador debe realizar son la definición de las estructuras relacionales para representar los objetos y escribir el código que interactúe con el DBMS, con el fin de obtener y establecer objetos e intercambiar los apuntadores.

La siguiente figura refleja las tablas necesarias para almacenar los objetos PEDIDO, CLIENTE, ARTÍCULODE LÍNEA, VENDEDOR Y ARTÍCULO.

RELACIONALES NECESARIAS PARA ALMACENAR LOS OBJETOS EMPLEADO (Número, Nombre,…)

VENDEDOR (Número, Comisión Total, Pedidos Totales,…)

CLIENTE (Nombre, teléfono, CódigoPostal, BalanceActual,…)

ARTÍCULO ( Número, Nombre, Descripción, Precio,…)

ORDEN (Número, Fecha, Total, VENDEDOR. Número, CLIENTE.Nombre,…)

ARTÍCULODELÍNEA (PEDIDO.Número, ARTÍCULO.Número, Nombredel Artículo, CantidaddeArtículos, CantidadReordenada, PrecioAumentado,…)

MÉTODOS (NombredelObjeto, NombredelMétodo, Códigodel Método,…)

Editado por Sandra Pérez Díaz

5

[TEMAS SELECTOS PARA LAS BASES DE DATOS]

Tema IV

Las bases de datos relacionales representa relaciones mediante llaves externas. Lo que significa que el programador de la aplicación debe idear algunos medios para utilizar llaves externas y hacer persistentes las relaciones.

La manera más común de realizar esto es codificar la creación de un ID (Identificación) único en el método constructor del objeto.

Este ID se puede almacenar en la tabla básica del objeto y mostrarse como una propiedad de sólo lectura.

Los objetos que necesitan enlazarse al objeto pueden guardar el valor del ID. Con esta estrategia el problema se genera cuando se destruye un objeto debe notificarlo a todos los que están conectados a él para que puedan eliminar el apuntador al objeto que está a punto de destruirse y considerar otra acción como apropiada.

La ideología y el diseño de la orientación a objetos se encuentran en las relaciones dentro del contexto. Por lo tanto, cuando un objeto PEDIDO se asigna así mismo a un VENDEDOR, sólo se interesa en la parte de dicha relación.

Si PEDIDO desea conectarse a muchos VENDEDORES, simplemente lo hace.

El objeto PEDIDO desconoce si un VENDEDOR tiene una relación con uno o con muchos PEDIDOS. Dicho conocimiento está encapsulado en el objeto VENDEDOR y no es la parte de la lógica PEDIDO. Esta característica representa una ventaja y una desventaja, dependiendo del punto de vista de cada programador.

Supongamos que PEDIDO puede tener varios VENDEDORes y que un VENDEDOR puede tener muchos PEDIDOs. En el lenguaje de bases de datos, PEDIDO y VENDNDEDOR tienen una relación M:N Por lo que, en el mundo de bases de datos relaciones se define una tabla de intersección para mantener a los identificadores de PEDIDOs y VENDEDORes relacionales entre sí.

En el mundo de los objetos, el objeto VENDEDOR sabe que tiene muchos PEDIDOs y el objeto PEDIDO sabe que tiene muchos VENDEDOres, pero ninguno de ellos sabe nada del otro.

Editado por Sandra Pérez Díaz

6

[TEMAS SELECTOS PARA LAS BASES DE DATOS]

Tema IV

Por lo tanto, las estructuras de datos que sostienen la relación están separadas. PEDIDO contendrá el almacenamiento de muchos enlaces a VENDEDOR y VENDEDOR contendrá el almacenamiento de muchos enlaces a PEDIDO. El conjunto de los enlaces estará separado de uno del otro.

Por lo que, nosotros como programados y en nuestra clase de Temas Selectos de BD, nos tenemos que preguntar ¿esto realmente importa?: No, mientras no existan errores en el procesamiento de objetos. Pero existe un riesgo debido a que los enlaces de objetos están separados, pero no son independientes.

Si el PEDIDO 1000 se enlaza a VENDEDOR A, entonces, por definición VENDEDOR A se enlaza al PEDIDO 1000.

PERSISTENCIA DE OBJETOS USANDO EL ODBMS La tercera alternativa para la persistencia de objetos es utilizar en ODBMS. Dichos productos están diseñados especialmente para la persistencia de objetos y por lo tanto, ahorran la mayor parte del trabajo al programador de la aplicación.

Un ODBMS está diseñado para integrarse con un lenguaje orientado a objetos. Debido a que no existe ninguna estructura especial, como SQL, se necesita implantar una en el código de aplicación.

Además los productos ODBMS incluyen un compilador que procesa el código fuente y automáticamente crea estructuras de datos en la base de datos de objetos para almacenar objetos.

PERSISTENCIA DE OBJETOS MEDIANTE ORACLE. Oracle ha extendido los dispositivos de sus productos de base de datos para incluir el soporte para la modelación de objetos y el almacenamiento de objetos persistentes.

Editado por Sandra Pérez Díaz

7