Persistencia (informática)

De Wikipedia, la enciclopedia libre
Saltar a: navegación, búsqueda

Persistencia en informática de modo técnico, se refiere a la propiedad de los datos para que estos sobrevivan de alguna manera.

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.


Tipos de persistencia de datos[editar]

Se consideran varios tipos de persistencia en informática, según a qué persistencia nos refiramos. Se describen a continuación:

Persistencia en memoria[editar]

La persistencia en memoria es la capacidad de un dato u objeto para seguir existiendo tras determinadas operaciones. La operación más común que se presta a la persistencia en memoria es la asignación. Existen dos ideas respecto de lo que debe suceder con un dato, estructura u objeto una vez asignado desde el original.

  • En unos casos lo que se desea es que haya dos referencias a los mismos datos. Es decir: un mismo dato tiene dos punteros desde los que es posible acceder a ellos. Un tipo de dato que utiliza este método se dice que tiene persistencia si cuando se elimina uno de los punteros, los datos siguen aún en memoria. En este caso el tipo de datos utiliza un contador de referencias, de modo que cada vez que se crea una referencia se aumenta la cuenta en 1 y cuando se elimina una referencia se disminuye el contador en 1. El tipo de datos, por tanto, sólo es realmente eliminado cuando la cuenta del contador llega a 0; es decir, cuando no tiene referencias apuntando a los datos.

Veamos un ejemplo: Se crea un objeto de tipo colección y se le asignan dos datos; luego se crea otro objeto al que se le asigna la colección previa.

Dim x As Collection
Dim y As Collection
Dim dia As String
 
Set x = New Collection
 
x.Add ("Domingo")
x.Add ("Jueves")
Set y = x
dia = y.Item(1)
MsgBox dia
 
y.Add ("Sábado")
dia = x.Item(3)
MsgBox dia
 
Set x = nothing
 
dia = y.Item(1)
MsgBox dia

Para verificar que son la misma referencia, después de ver que en la 1ª asignación a dia es 'Domingo' (hasta este momento no hay razones para pensar si hubo una copia o son la misma referencia), añadimos luego un nuevo ítem a la 2ª colección. Volvemos a obtener ahora el ítem recién añadido pero ahora utilizando la primera colección. Se demuestra que son la misma referencia al constatar que el ítem añadido con la 2ª colección también es accesible desde la 1ª, algo que no podría suceder si cada colección apuntara a diferentes posiciones en memoria. Finalmente eliminamos una de las colecciones y observamos cómo la otra aún tiene acceso a los datos. El ejemplo demuestra cómo hay persistencia de los datos. Las colecciones son persistentes.

  • En otros casos lo que interesa cuando se hace una asignación es copiar, crear totalmente aparte un duplicado de los datos a asignar (hay preferencias para llamar a este tipo de copia clonar en vez de copiar). Por tanto no necesitan o no utilizan nunca más de una referencia, ni por tanto precisan tener un contador de referencias. Estos casos se dice que no tienen persistencia. Al eliminar la referencia los datos quedan perdidos, nunca tienen más de una referencia, ya que cuando se hace una asignación se realiza un duplicado de los datos con su propia referencia.

Veamos ahora un ejemplo de memoria no persistente: El ejemplo es similar al anterios, pero en vez de usar colecciones usamos arrays.

Dim x() As Byte
Dim y() As Byte
Dim dia As String
 
ReDim x(0 To 2)
 
x(0) = 25
x(1) = 14
y = x
dia = y(1)
MsgBox dia
 
y(2) = 6
dia = x(2)
MsgBox dia

Se puede constatar cómo los arrays no son persistentes. Cuando asignamos el valor 6 al segundo array en su elemento 2 vemos que el elemento 2 del primer array no contiene el mismo dato que acabamos de introducir en el 2º array; nos devuelve 0, ya que nunca ha sido asignado dicho elemento para el array 1º.

La comprobación del contador de referencias para (si llega el caso) su eliminación, en los lenguajes más modernos recae en el recolector de basura que se encarga de liberar la memoria ocupada por los objetos sin referencias. En los lenguajes sin este mecanismo, debe explícitamente eliminarse cada objeto y en general cada aplicación es responsable de los objetos que crea.

Persistencia de aplicación[editar]

Es la capacidad para que los datos sobreviven a la ejecución del programa que los ha creado. Sin esta capacidad, los datos solo 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án 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.

Se puede citar, a modo ejemplo, un fichero que está almacenado en disco. Es común a muchas aplicaciones guardar en disco una copia de las opciones de configuración de un programa cada vez que el usuario realiza cambios. Si dichos cambios no se guardaran a disco, la próxima vez que el usuario ejecutare la aplicación tendría que volver a definir las opciones de preferencia.

Persistencia de objetos[editar]

La persistencia de objetos puede ser fácilmente confundida con la persistencia en memoria; incluso con la persistencia de aplicación. La persistencia de objetos consiste en la inicialización de objetos con sus atributos por defecto. Esto es posible con dos maneras de proceder.

  • Sobre un medio (de almacenamiento) fijo 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.
  • Otro objeto mantiene los datos que serán transferidos a las propiedades del nuevo objeto creado. En este caso los datos están en memoria.

Hay muchos ejemplos para este tipo de persistencia. Un caso típico son los controles ActiveX. Cuando el control es compilado junto al código se guarda una copia de los datos que el programador definió por defecto. Cuando se instancia una referencia al control, éste lee del disco (donde está almacenada la librería asociada al control) los datos que definen y configuran sus propiedades.

Otro ejemplo son las primitivas que se utilizan para recrear objetos 3D a partir de los cual pueden crearse objetos más complejos. Supongamos que vamos a crear un avión con geometría 3D. Inicialmente podemos crear cada primitiva que compone el mismo, desde memoria, el motor de la aplicación puede definir un nuevo objeto con las medidas que el usuario define y posicionado igualmente en las coordenadas que el usuario señala para crear el objeto. Sin embargo, a medida que el objeto crece y tiene más datos, se hace necesario guardar el objeto en disco. Este objeto puede ahora ser guardado y ser utilizado las próximas veces como una primitiva, un punto a partir del cual iniciar la creación de otros objetos más complejos basados en éste. Si ahora quiero crear un nuevo modelo de avión posiblemente sea más sencillo modificar la primitiva definida que crear uno totalmente nuevo; por tanto, es necesaria la persistencia de la primitiva para recrear nuevos objetos basados en ella. Las primitivas complejas se acoplan a la primera manera definida y las primitivas sencillas se ajustan a la segunda manera definida.

Para guardar los datos de objetos en disco se recurre a un mecanismo conocido como serializar, que dispone en una secuencia de bytes todos los datos (o sólo aquellos que se desee) que definen el objeto.

Referencias[editar]

Véase[editar]