• Author / Uploaded
• Blas Antonio García F

Citation preview

UNIVERSIDAD DE ORIENTE NÚCLEO DE MONAGAS ESCUELA DE INGENÍERIA Y CIENCIAS APLICADAS DEPARTAMENTO DE INGENÍERIA DE SISTEMAS

Gestión de Almacenamiento Persistente

Profesora: Alba Ortiz

Bachilleres: Luis Docchio. CI: 23917224 Scarleth Hernández. CI: 22707171 Karla Zapata. CI: 21084191 Carlos Millán. CI: 26060821 Blas García. CI: 20915025

Maturín, junio de 2017

INTRODUCCIÓN En la gestión de base de datos es importante desarrollar el concepto de la persistencia del almacenamiento de los datos, dependiendo de las necesidades del sistema. Un almacén de datos es una representación genérica de los datos que se han vuelto persistentes al haberse almacenado en algún otro lugar, como un archivo, una base de datos o incluso un documento impreso. Los cambios realizados en una base de datos deben ser permanentes, incluso después de un apagado o una falla posterior de la base de datos u otro componente fundamental del sistema. En la terminología de objetos, se aplica el término persistencia para los datos guardados de manera permanente. La gestión de Base de Datos se puede servir ampliamente de los recursos y funciones de los lenguajes de programación de alto nivel como C++ o java para implementar la persistencia en la manera de almacenar los datos.

Primero antes de saber qué es un almacenamiento persistente, y poder definir cómo se comportaría la gestión en dicho almacenamiento es fundamental saber lo que es la persistencia, cuál es su comportamiento y como se define. En primer lugar tenemos que persistencia es la “duración o existencia de una cosa por largo tiempo.” “Firmeza y constancia en la manera de ser o de obrar.” Estos conceptos son aplicables al diario vivir, pero, ¿qué hay de la persistencia en nuestro ámbito, en el de sistemas, y en el de la informática en su defecto? Podemos citar, a un concepto que nos indica lo siguiente: “En informática, la persistencia se refiere a la propiedad de los datos para que estos sobrevivan de alguna manera. En programación, la persistencia es la acción de preservar la información de un objeto de forma permanente (guardado), pero a su vez también se refiere a poder recuperar la información del mismo (leerlo) para que pueda ser nuevamente utilizado. De forma sencilla, puede entenderse que los datos tienen una duración efímera; desde el momento en que estos cambian de valor se considera que no hay persistencia de los mismos. Sin embargo, en informática hay varios ámbitos donde se aplica y se entiende la persistencia. Entonces podemos decir simplemente que la persistencia en informática o programación es la acción que se le asigna a un conjunto de datos, elementos u objetos a persistir con el transcurso del tiempo aún cuando su creador deja de existir, pero tiene que tener ligada la cualidad de poder ser modificada posteriormente.

Algunos conceptos básicos: El almacenamiento: Es la propiedad o capacidad de guardar datos que tiene un dispositivo electrónico. Computadoras, teléfonos celulares, tabletas, televisores smart, calculadoras, consolas de videojuegos y demás dispositivos electrónicos tienen esta propiedad, la cual es muy útil no sólo para guardar datos sino también para procesarlos. Dato: Es una representación simbólica (numérica, alfabética, algorítmica, espacial, etc.) de un atributo o variable cuantitativa o cualitativa. Los datos describen hechos empíricos, sucesos y entidades. Es un valor o referente que recibe el computador por diferentes medios, los datos representan la información que el programador manipula en la construcción de una solución o en el desarrollo de un algoritmo. Base de datos: Una base de datos es el conjunto de datos informativos organizados en un mismo contexto para su uso y vinculación. Se le llama base de datos a los bancos de información que contienen datos relativos a diversas temáticas y categorizados de distinta manera, pero que comparten entre sí algún tipo de vínculo o relación que busca ordenarlos y clasificarlos en conjunto. Persistencia en Base de datos: 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. Utilizar 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é. Datos Persistentes: Conviene llamar persistente a los datos de una Base de Datos. Esto tiene por objetivo sugerir que la información de una Base de Datos difiere de otros tipos de datos cuya naturaleza sea hasta cierto punto transitoria. Datos de entrada: se refiere a la información que entra al sistema por primera vez. Esta información podría dar pie a una modificación de los datos persistentes (podría convertirse en parte de éstos últimos), pero en principio no forma parte de la Base de Datos propiamente dicha. Datos de salida: se refiere a mensajes y resultados que emanan del sistema. Esta información podría derivarse de los datos persistentes, pero no se le considera en sí como parte de la Base de Datos.

Lenguajes de programación persistentes Persistencia en C++: En los últimos años han aparecido varias bases de datos orientadas a objetos basadas en las extensiones persistentes de C++. Hay diferencias entre ellas en términos de la arquitectura de los sistemas pero tienen muchas características comunes en términos del lenguaje de programación. Varias de las características orientadas a objetos del lenguaje C++ ayudan a proporcionar un buen soporte para la persistencia sin modificar el propio lenguaje.

Persistencia en Java: En años recientes, el lenguaje java ha visto un enorme crecimiento en su uso. La demanda de soporte de la persistencia de los datos en los programas de java se ha incrementado de manera acorde. Los primeros intentos de creación de una norma para la persistencia en java fueron liderados por el consorcio ODMG; posteriormente, el consorcio concluyó sus esfuerzos, pero transfirió su diseño al proyecto Objetos de Bases de datos de Java (Java Database Objects, JDO), que coordina Sun Microsystems.

Tipos de Almacenamiento Persistentes: Existen dos tipos de persistencia: de aplicación y de objetos. La persistencia de aplicación es la capacidad para que los datos sobrevivan a la ejecución del programa que los ha creado. Sin esta capacidad, los datos sólo existen en memoria RAM, y se pierden cuando la memoria pierde energía, como cuando se apaga el computador. Este tipo de persistencia requiere que los datos sean almacenados en un medio secundario, no volátil, para su posterior reconstrucción y utilización, por lo que su tiempo de vida es independiente del proceso que los creó. Por lo tanto, deberían permanecer almacenados en memoria que no sea volátil, es decir, que en caso de interrupción de la energía que alimenta al computador, una copia de estos datos debe permanecer almacenada. La persistencia de objetos consiste en la inicialización de objetos con sus atributos por defecto lo que es posible con dos maneras de proceder. La primera sobre un medio de almacenamiento fijo, donde se guarda (cuando el objeto fue definido) un conjunto de datos que son recuperados cuando el tipo de objeto en cuestión es

creado; dichos datos son transferidos a las propiedades del objeto. Con respecto a la segunda, otro objeto mantiene los datos que serán transferidos a las propiedades del nuevo objeto creado, caso en el cual los datos están en memoria. Se debe determinar en qué momento se deben persistir u obtener los datos de la aplicación: • Estático: Se cargan todos los datos del sistema al iniciar la aplicación y se guardan los datos potencialmente modificados al finalizar su ejecución. • Momento determinado: Cuando el usuario lo indique o cada cierto tiempo, se deben persistir todos los datos de la aplicación. • Continuo: Se almacenan los datos a medida que son modificados en el sistema. No se necesita almacenar todos los datos al finalizar la ejecución de la aplicación. Mecanismo similar al utilizado por las bases de datos. Se deben manejar transacciones para que no se registren inconsistencia en los datos. Es más complejo de implementar.

Almacenamiento y Acceso a los Objetos Persistentes: ¿Qué significa guardar un objeto en una base de datos? Evidentemente, hay que guardar por separado la parte de datos de cada objeto. Lógicamente, el código que implementa los métodos de las clases debe guardarse en la base de datos como parte de su esquema, junto con las definiciones de tipos de las clases. Sin embargo, muchas implementaciones se limitan a guardar el código en archivos externos a la base de datos para evitar tener que integrar

el software del sistema, como los compiladores, con el sistema de bases de datos. Hay varias maneras de hallar los objetos de la base de datos. Una manera es dar nombres a los objetos, igual que se hace con los archivos. Este enfoque funciona con un número de objetos relativamente pequeño, pero no resulta práctico para millones de objetos. Una segunda manera es exponer los identificadores de los objetos o los punteros persistentes a los objetos, que pueden guardarse en el exterior. A diferencia de los nombres, los punteros no tienen por qué ser fáciles de recordar y pueden ser, incluso, punteros físicos internos de la base de datos. Una tercera manera es guardar conjuntos de objetos y permitir que los programas iteren sobre ellos para buscar los objetos deseados. Los conjuntos de objetos pueden a su vez modelarse como objetos de un tipo conjunto. Entre los tipos de conjuntos están los conjuntos, los multiconjuntos (es decir, conjuntos con varias apariciones posibles de un mismo valor), las listas, etc. Un caso especial de conjunto son las extensiones de clases, que son el conjunto de todos los objetos pertenecientes a una clase. Si hay una extensión de clase para una clase dada, siempre que se crea un objeto de la clase ese objeto se inserta en la extensión de clase de manera automática; y, siempre que se borra un objeto, éste se elimina de la extensión de clase. Las extensiones de clases permiten que las clases se traten como relaciones en el sentido de que es posible examinar todos los objetos de una clase, igual que se pueden examinar todas las tuplas de una relación. La mayor parte de los sistemas de bases de datos orientados a objetos soportan las tres maneras de acceso a los objetos persistentes. Dan identificadores a todos los objetos. Generalmente sólo dan nombre a las extensiones de las clases y a

otros objetos de tipo conjunto y, quizás, a otros objetos seleccionados, pero no a la mayor parte de los objetos. Las extensiones de las clases suelen conservarse para todas las clases que puedan tener objetos persistentes pero, en muchas de las implementaciones, las extensiones de las clases sólo contienen los objetos persistentes de cada clase.

Mecanismos de denominación y noción de alcance: Los objetos persistentes se almacenan en la base de datos y persisten después de la terminación del programa. Los mecanismos típicos para hacer que un objeto sea persistente son la denominación y la noción de alcance (reachability). El mecanismo de denominación implica asignar a un objeto un nombre persistente único con el que el programa actual y otros programas pueden recuperarlo. Este nombre de objeto persistente puede suministrarse mediante una sentencia u operación específica del programa. Los nombres que se suministran a los objetos han de ser únicos dentro de una base de datos particular. Por tanto, los objetos persistentes denominados se utilizan como puntos de entrada a la base de datos a través de los cuales los usuarios y las aplicaciones pueden iniciar su acceso a la base de datos. Obviamente, no resulta práctico asignar un nombre a todos los objetos de una base de datos grande que incluye miles de objetos, por lo que la mayoría de los objetos se hacen persistentes utilizando el segundo mecanismo, denominado noción de alcance. Este otro mecanismo funciona haciendo que el objeto sea alcanzable desde algún objeto persistente. Se dice que un objeto

B es alcanzable desde un objeto A si una secuencia de referencias en el gráfico del objeto conduce desde el objeto A al objeto B. Si primero creamos un objeto persistente denominado N, cuyo estado es un conjunto o una lista de objetos de alguna clase C, podemos conseguir que los objetos de C sean persistentes añadiéndolos al conjunto o la lista, y haciéndolos así alcanzables o accesibles desde N. Por tanto, N define una colección persistente de objetos de clase C.

Persistencia de objetos La persistencia es la propiedad orientada a objetos que conserva el estado de un objeto entre ejecuciones de una aplicación y a través del apagado y encendido del equipo de cómputo. En casi todos los casos, se utiliza una base de datos para guardar los objetos de manera permanente, de modo que la persistencia es implementada por la base de datos. Los objetos deben cargarse en la memoria para que una aplicación acceda a ellos, y cualquier cambio debe guardarse para su almacenamiento persistente cuando ya no se requiera. La carga de objetos en la memoria es un proceso indirecto, lo que significa que la aplicación no solicita específicamente que se cargue un objeto: el ambiente de la aplicación colabora con el entorno de la base de datos para cargar los objetos en la memoria automáticamente cuando una aplicación accede a ellos. Este acceso suele estar en forma de un mensaje que se envía al objeto pero, también puede ocurrir cuando un objeto contiene una referencia a otro.

Persistencia mediante una base de datos orientada a objetos: En la figura se muestra la recuperación de un objeto del almacenamiento persistente en una base de datos orientada a objetos. Para los fines del ejemplo, se han omitido los componentes específicos que ejecutan cada uno de los pasos ilustrados, por lo que se muestra lo que ocurre sin preocuparse de cómo ocurre. En realidad ésta es una excelente manera de considerar las bases de datos orientada a objetos, porque una propiedad común de los sistemas correspondientes es ocultar los detalles de la

implementación. Como se aprecia en la figura, la base de datos contiene copias persistentes de los objetos A1, A2, A3, B1 y C1. Suponga que la primera letra indica la clase a la que pertenecen los objetos. Observe que B1 hace referencia al objeto C1 tal como se ilustra, y se emplea una línea de guiones para conectarlos. Éste es un diseño normal en que un objeto, como un pedido, contiene la identificación de objeto (OID) de un objeto relacionado, como el cliente que hizo el pedido. En una base de datos relacional

equivalente, esta relación se implementaría mediante una clave externa en el pedido. Como se muestra en la figura, ésta es la secuencia de eventos que ocurren la primera vez que la aplicación hace referencia a un objeto: 1. Se envía a la base de datos orientada a objetos una solicitud para recuperar el objeto, por lo general porque un mensaje en el ambiente de la aplicación hizo referencia al objeto. El DBMS orientado a objetos (Object Oriented DBMS, OODBMS) recupera el objeto del almacenamiento persistente y lo transfiere al ambiente de la aplicación. Si el objeto contiene referencias a otros objetos, el OODBMS también puede recuperar automáticamente esos objetos, dependiendo de la arquitectura del OODBMS. 2. Si un objeto contiene referencias a otros, esas referencias deben transformarse en direcciones en la memoria cuando se cargan los objetos en la misma. A este proceso se le conoce como revolver las referencias. (Se desconoce el origen del término revolver, pero puede derivarse de los bastones o agitadores que sirven para revolver bebidas.) En el almacenamiento persistente, se utiliza la OID como referencia, porque el OODBMS puede emplear otras estructuras de almacenamiento similares a los índices para localizar los objetos relacionados. Por ejemplo, el objeto B1 contiene la OID del objeto C1, y el OODBMS no tiene dificultad para utilizar la OID con el propósito de localizar el objeto relacionado en el almacenamiento persistente de la base de datos. Sin embargo, la OID no sirve para localizar el objeto relacionado una vez que éste está cargado en la memoria, porque los objetos se cargan en cualquier lugar disponible de la memoria, lo que significa que no hay un modo sencillo para saber el lugar que ocupan. Por lo tanto, la

OID se traduce (se revuelve) a la dirección real que ocupa el objeto relacionado en la memoria para permitir un acceso directo de ese objeto. La OID original se conserva dentro del objeto porque será necesaria cuando el objeto se vuelva a guardar en la base de datos. 3. El objeto queda disponible para el entorno de la aplicación. Es decir, se pone en un lugar de la memoria y los mensajes dirigidos al objeto se enrutan a ese lugar. Por lo general, esto también implica registrar el objeto con el entorno de la aplicación, para que se pueda encontrar con facilidad en la memoria la siguiente ocasión que se haga referencia a él. El proceso inverso de guardar otra vez un objeto en la base de datos orientada a objetos cuando la aplicación ya no necesita acceder a él es exactamente eso: una reversión del proceso original. Las condiciones que activan la devolución del objeto al almacenamiento persistente varían de un OODBMS a otro, pero suelen contener un algoritmo tipo el utilizado menos recientemente (LRU, Least Recently Used). El algoritmo LRU es un proceso que se invoca cuando debe liberarse espacio para cargar más objetos en lugares de la memoria. El algoritmo encuentra los objetos a los que se tuvo acceso hace más tiempo (es decir, menos recientemente) y los retira de la memoria. Y, por supuesto, una solicitud para apagar la base de datos requiere que todos los objetos que están en la memoria vuelvan a ser persistentes antes de apagar dicha base. Ésta es la secuencia de eventos para trasladar un objeto de la memoria al almacenamiento persistente: 1. El objeto es retirado de un lugar en la memoria, y se elimina cualquier registro del objeto en el entorno de la aplicación.

2. Se elimina cualquier dirección de la memoria agregada al objeto cuando se revolvieron las referencias. 3. Si el objeto fue modificado mientras estaba en la memoria, se devuelve al OODBMS, que guarda la versión nueva. Persistencia mediante una base de datos relacional: Cuando los datos de un objeto se guardan en una base de datos relacional, el resultado son algunas diferencias importantes. En primer lugar, todo en una base de datos relacional debe guardarse en una tabla. Por lo tanto, los objetos deben traducirse desde las tablas relacionales y a éstas. Cada clase se suele guardar en una tabla relacional diferente, y las filas de las tablas representan instancias de objetos de las clases correspondientes. En segundo lugar, las tablas relacionales no pueden guardar objetos en su formato nativo, porque los objetos están formados por métodos y una jerarquía de clases, junto con los datos mismos. Los métodos y la jerarquía de clases no suelen guardarse en la base de datos relacional; más bien, se conservan en un lugar del sistema de archivos (directorio) administrado por el entorno de la aplicación. Existen diferencias entre la primera y segunda persistencia. En primer lugar, en esta última persistencia, los datos de un objeto se guardan en la base de datos en tablas. En segundo lugar, se requiere un paso adicional cuando se recuperan objetos para que queden disponibles en la memoria: los datos de la base de datos relacional deben convertirse a clases de objetos y variables. Esto se consigue de varias maneras. Un método común en las aplicaciones escritas en Java consiste en emitir el SQL relacional directamente desde un método de Java mediante un controlador para conectividad de base de datos de Java (JDBC, Java DataBase

Connectivity), y dentro del mismo método, relacionar los resultados devueltos por el controlador JDBC para uno o más objetos. Éste es un método manual que representa mucho trabajo para los programadores en Java. Por suerte, existen soluciones más automatizadas, en donde un servidor de aplicaciones o un producto de middleware maneja todos los detalles de los objetos guardados de manera persistente en una base de datos relacional, entre ellos la traducción entre tablas relacionales y objetos.

La figura ha sido simplificada para mostrar los pasos requeridos para ensamblar un objeto guardado en una base de datos relacional y que ha quedado disponible en el entorno de la aplicación, sin los detalles de cuáles componentes manejan los pasos.

Tal como se ilustró, ésta es la secuencia de eventos requerida para ensamblar un objeto a partir de los datos guardados en una base de datos relacional: 1. Se envía una consulta de SQL al RDBMS para recuperar la tabla (que suele ser una fila) de la base de datos. El RDBMS ejecuta la consulta y los datos resultantes se envían al entorno de la aplicación. 2. La tabla de datos se convierte en el objeto. Esto suele incluir la asignación de los datos de la tabla a una clase y las columnas individuales a variables de esa clase, junto con la recuperación de los métodos definidos para la clase del lugar donde se guardan en el sistema de archivos. Este paso de la conversión es el proverbial talón de Aquiles de esta arquitectura: es muy costoso, y requiere soluciones intermedias de diseño porque los datos de los objetos no siempre pueden representarse a la perfección 3. Igual que con la anterior persistencia, se revuelven las referencias a los objetos. 4. Igual que con la segunda figura, el objeto se pone en un lugar de la memoria y se registra con el entorno de la aplicación, con lo cual queda disponible para la aplicación. Cuando ya no se necesita un objeto en la memoria, debe volverse al almacenamiento persistente. Ésta es la secuencia de eventos: 1. El objeto se retira de la memoria, y se elimina cualquier registro con el entorno de la aplicación.

Si el objeto no fue modificado mientras estaba en la memoria, no se requiere ninguna otra acción; de lo contrario, la secuencia continúa con el paso siguiente. 2. Se retiran las direcciones de la memoria agregadas para las referencias a un objeto. 3. Los datos del objeto se vuelven a convertir en las filas de la tabla relacional de la que provinieron. Se forman una o más instrucciones de SQL (INSERT, UPDATE o DELETE) para modificar los datos de la base de datos relacional con el fin de que coincidan con los datos de objetos. Por eficiencia, a menudo esto requiere la comparación con versiones anteriores y posteriores del objeto (si están disponibles) para que sólo sea necesario hacer referencia a las variables que se modificaron de algún modo en las instrucciones SQL generadas. No es necesario hacer nada con la estructura de clases o los métodos porque no se modifican cuando el objeto es utilizado en el entorno de la aplicación. Estos componentes sólo cambian cuando se instala una versión nueva de la aplicación. 4. Las instrucciones SQL son transferidas al DBMS relacional para su procesamiento. Si el objeto no se modificó mientras estaba en la memoria, no se requiere este paso.

CONCLUSIÓN La gran mayoría de los Sistemas Informáticos de empresas, compañías y otros usuarios tienen como objeto vital el almacenamiento de datos e información de forma permanente, segura, confiable y recuperable. De igual manera, los desarrolladores Web necesitan muchas veces crear aplicaciones que requieran base de datos que almacenen los datos incluso una vez se haya apagado el equipo. Esta propiedad es la persistencia de los datos, que se guardan en memoria en el almacén de datos. Por ello es de suma importancia que los analistas, programadores y diseñadores de SI manejen y tengan a la mano las opciones que brinda la Gestión de Base de Datos, especialmente la Orientada a Objetos para poder guardar de forma permanente la información, según las necesidades del sistema.

BIBLIOGRAFIA

Andrew Oppel: “Fundamentos de Bases de Datos”, The McGrawHill Companies. 2009 Ramez Elmasri y Shamkant B. Navathe: “Fundamentos de Sistemas de Bases de Datos” PEARSON EDUCACIÓN S.A., Madrid, 2007 https://styde.net/concurrencia-y-persistencia-en-programacionorientada- a-objetos/