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: Bachilleres:
Alba Ortiz 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 McGraw-

Hill 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-programacion-
orientada- a-objetos/