Cuando se realiza el análisis de un sistema de información es importante analizar la vida útil de los objetos que han fallecido o que fallecerán. Este análisis suele ser importante pues, los datos fallecidos no vuelven a ser utilizados por el sistema de información a excepción de ciertas circunstancias muy particulares, tales como: una auditoría externa, una situación legal ocurrida por un reclamo, etc.
Sabemos que los objetos forman parte de la memoria de un sistema para siempre, serán eternos. Es decisión de su creador (aunque no arbitraria) por cuanto tiempo han de quedarse eternizados estos objetos en la memoria del sistema.
¿Por cuánto tiempo mantendremos al objeto hasta que nos empiece a molestar?
La respuesta resulta simple, cuando el objeto comience a molestar en el sistema habrá llegado el momento de eliminarlo; ten por seguro que ese momento llegará.
La molestia comienza a presentarse cuando los tiempos de respuesta del sistema implementado decae, o simplemente se presenta información que ya no tiene sentido para el usuario. No creo que sean las únicas razones, pero seguro que están presente en los sistemas implementados en software.
Imagínate que todavía pudieras vender en tu sistema de ventas disquetes de 5 ¼, o cualquier producto que no se produce más, como un cassette; o ves a ese cliente que hace años que no te compra, o esa factura que jamás fue pagada, o simplemente esa persona que trabajaba con vos, pero ya no lo hace, y aún podés asignarle trabajo desde el sistema en funcionamiento. El dato / la información no corresponde que estén presente pues, ya produce efectos que no son buenos. Suelen poner de mal humor al usuario, o incluso producir errores no pensados.
Obviamente que los datos suelen ser borrados por razones más poderosas que las mencionadas, tienen que ver con la performance. Cuando las aplicaciones que implementan los sistemas se ponen lentas, el destino es borrar los datos que no tienen utilidad. Imagínate que se producen en tu ciudad, desde tu empresa, para tus 200.000 clientes, 200.000 facturas mensuales. Luego en 10 meses tenés 1 millón, luego en 5 años tendrás 6.000.000, pero si te fue bien tendrás más. Ahora imagínate las empresas que facturan servicios y, que en muchos casos son monopolio. Imagínate un municipio generando impuestos, o en un banco el nivel de transacciones diarias de sus clientes.
Las otras razones poderosas por la que los datos se mantienen por un tiempo y, hasta que no son necesarios, está dado por restricciones legales o porque son necesarios estadísticamente, o bien, su historia produce un beneficio social a largo plazo; luego solo pensaremos en destruirlos (Los datos que se mantiene para obtener estadísticas dentro del contexto social tienen una riqueza importante para comprender las sociedades en la que vivimos o vivíamos)
¿Qué debemos tener en cuenta para eliminar datos?
Sabemos que los datos no están solos en la memoria del sistema, sino que están dentro de una red de conexiones invisibles, por lo que, al momento de destruir, el analista debe analizar no solo que se borren los datos deseados, sino que también se borren los datos y las conexiones que los sostienen, los hacen estables o permiten que otros sean estables o comprendidos. Si vas a eliminar datos no podés dejar huecos en la memoria, no podes producir islas que constituyan puertas a errores que antes no existían, simplemente no te lo podés permitir.
Ejemplo: si quiero borrar un cliente que ha realizado compras y las compras tiene diferentes pagos, entonces borrar el cliente implica borrar sus compras y los pagos de estas. Si no lo hago dejo huecos de memoria irrecuperables, compras realizadas por humanos que se desconoce quienes son….un horror.
Entonces sin más preámbulos, borrar un objeto de la memoria, implica tomar todas los datos y las conexiones cuya vida depende del objeto y borrarlas también. Es lo que comúnmente llamamos una eliminación en cascada, pero ojo que si el dato conectado te sirve entonces quizás no corresponda borrar nada.
Definir estados anulados, cancelado o fuera de línea puede ayudar a quitar el dato obsoleto sin quitarlo realmente. Manejar bajar lógicas es otra historia del análisis que suele sacar de línea objetos obsoletos. Si tu problema no es de performance puede ser una solución buena, pero solo buena; cada nuevo requerimiento deberá ser analizado a luz de no contabilizar datos obsoletos, esto aumenta la complejidad.
Sabemos que los objetos forman parte de la memoria de un sistema para siempre, serán eternos. Es decisión de su creador (aunque no arbitraria) por cuanto tiempo han de quedarse eternizados estos objetos en la memoria del sistema.
¿Por cuánto tiempo mantendremos al objeto hasta que nos empiece a molestar?
La respuesta resulta simple, cuando el objeto comience a molestar en el sistema habrá llegado el momento de eliminarlo; ten por seguro que ese momento llegará.
La molestia comienza a presentarse cuando los tiempos de respuesta del sistema implementado decae, o simplemente se presenta información que ya no tiene sentido para el usuario. No creo que sean las únicas razones, pero seguro que están presente en los sistemas implementados en software.
Imagínate que todavía pudieras vender en tu sistema de ventas disquetes de 5 ¼, o cualquier producto que no se produce más, como un cassette; o ves a ese cliente que hace años que no te compra, o esa factura que jamás fue pagada, o simplemente esa persona que trabajaba con vos, pero ya no lo hace, y aún podés asignarle trabajo desde el sistema en funcionamiento. El dato / la información no corresponde que estén presente pues, ya produce efectos que no son buenos. Suelen poner de mal humor al usuario, o incluso producir errores no pensados.
Obviamente que los datos suelen ser borrados por razones más poderosas que las mencionadas, tienen que ver con la performance. Cuando las aplicaciones que implementan los sistemas se ponen lentas, el destino es borrar los datos que no tienen utilidad. Imagínate que se producen en tu ciudad, desde tu empresa, para tus 200.000 clientes, 200.000 facturas mensuales. Luego en 10 meses tenés 1 millón, luego en 5 años tendrás 6.000.000, pero si te fue bien tendrás más. Ahora imagínate las empresas que facturan servicios y, que en muchos casos son monopolio. Imagínate un municipio generando impuestos, o en un banco el nivel de transacciones diarias de sus clientes.
Las otras razones poderosas por la que los datos se mantienen por un tiempo y, hasta que no son necesarios, está dado por restricciones legales o porque son necesarios estadísticamente, o bien, su historia produce un beneficio social a largo plazo; luego solo pensaremos en destruirlos (Los datos que se mantiene para obtener estadísticas dentro del contexto social tienen una riqueza importante para comprender las sociedades en la que vivimos o vivíamos)
¿Qué debemos tener en cuenta para eliminar datos?
Sabemos que los datos no están solos en la memoria del sistema, sino que están dentro de una red de conexiones invisibles, por lo que, al momento de destruir, el analista debe analizar no solo que se borren los datos deseados, sino que también se borren los datos y las conexiones que los sostienen, los hacen estables o permiten que otros sean estables o comprendidos. Si vas a eliminar datos no podés dejar huecos en la memoria, no podes producir islas que constituyan puertas a errores que antes no existían, simplemente no te lo podés permitir.
Ejemplo: si quiero borrar un cliente que ha realizado compras y las compras tiene diferentes pagos, entonces borrar el cliente implica borrar sus compras y los pagos de estas. Si no lo hago dejo huecos de memoria irrecuperables, compras realizadas por humanos que se desconoce quienes son….un horror.
Entonces sin más preámbulos, borrar un objeto de la memoria, implica tomar todas los datos y las conexiones cuya vida depende del objeto y borrarlas también. Es lo que comúnmente llamamos una eliminación en cascada, pero ojo que si el dato conectado te sirve entonces quizás no corresponda borrar nada.
Definir estados anulados, cancelado o fuera de línea puede ayudar a quitar el dato obsoleto sin quitarlo realmente. Manejar bajar lógicas es otra historia del análisis que suele sacar de línea objetos obsoletos. Si tu problema no es de performance puede ser una solución buena, pero solo buena; cada nuevo requerimiento deberá ser analizado a luz de no contabilizar datos obsoletos, esto aumenta la complejidad.
