Dilema: Versión de Registros/Tuplas en la Base de Datos ¿Como?

[D-MO]

Hace mucho que no escribía por acá, y aunque lo visito frecuentemente, la verdad es que no tenía nada productivo que aportar, aunque ¿Será que ya tengo algo productivo que aportar?.

Bueno, al grano. Llegó el momento de poner un poco de orden donde trabajo, llevar un mejor control. Trabajo en el área de Soporte Técnico en una Institución del Estado y la verdad es que no puedo opinar mucho de los controles de TI pues los desconozco, no existen. Pero bueno, de nuevo me salí del tema...

Resulta que desde hace algunos días he estado con la inquietud de empezar con algunos controles de TI, y porqué no, desarrollar el sistema a medida basándome en mi experiencia en este puesto. Pero no quiero hacer las cosas porque si, ni tirarme al agua sin saber nadar. Quiero trabajar con reglas/procedimientos probados, que han tenido éxito, que miles de empresas usan a nivel mundial y que mejor que estudiar la norma ISO/IEC 20000, mas específico, desde la Biblioteca de Infraestructura de Tecnología de Información (ITIL, por sus siglas en inglés).

Obviamente, implementar todo lo que indica ITIL es una tarea enorme, casi imposible para una sola persona, ¿pero de que sirve la vida son los retos?... Para empezar, quiero iniciar por el principio ... la CMDB.

Acá pongo la imagen de mi diagrama de herencia de clases (aún no están marcadas la relaciones) donde podremos ver el nivel de detalle al que debemos llegar (según ITIL) para poder llevar un control completo.


Uploaded with ImageShack.us

En el diagrama faltan muchos objetos por modelar, y casi todos los modelos no tiene sus atributos asignados, sin embargo, ya podemos darnos una idea de la CMDB.

La CMDB es la parte central según ITIL. Yo en lo personal lo veo muy acertado. Pero la CMDB tiene una característica peculiar, debe mantener un histórico de los estados/cambios/sucesos vinculados a un equipo, así, si decimos que a la computadora X le incrementamos la memoria ram, pasó de ser X.n (n por en número de versión) a ser X.{n+1}... ¡¡¡Excelente!!!, aquí si hay control.

Mi frustación hasta este momento, ha iniciado en este punto. ¿De que manera debería de implementarse esta "pequeña" característica requerida según ITIL?. De momento se me ocurren dos posibilidades, pero ninguna de ellas me convence, las indico:

• Una tabla, registros duplicados

La primera posibilidad sería tener una llave primaria compuesta, formada por el ID del equipo y la versión del mismo, cada que cambia de versión duplicar el registro (para mantener el histórico), cambiar el estado del registro anterior y marcar como activo al registro nuevo. De entrada se ve bastante prometedor, hasta que nos topamos con el problema de como hacer para que, cada dispositivo esté vinculado a la versión actual pero también saber a que otras versiones del mismo u otro equipo ha pertenecido, pues, al pasar la computadora X de X.n a X.{n+1} solo podríamos hacer referencia de los dispositivos hacia una sola versión del equipo. ¡Ouch!

Dos tablas, Encabezado + Histórico

La segunda opción quizá sea un poco mas funcional, sin embargo, no termina de convencerme. Explico:

Tenemos dos tablas, una tabla Computadora y otra Histórico de Computadora. Entonces, desde la tabla de cada dispositivo hago referencia al ID del equipo y en la tabla Histórico de Computadora mantengo un registro por cada versión de la computadora con llave foránea hacia la tabla Computadora utilizando el ID.

De esta manera resolvemos el problema encontrado en la opción anterior, sin embargo, lo que no me parece es que debería de tener una tabla histórica por cada objeto modelado, imaginen:

• hard_disk
• hard_disk_revisions
• ram
• ram_revisions
• network_card
• network_card_revisions
• access_point
• access_point_revisions
• etc...

No me convence por "estética", la parte de desarrollo no me preocupa pues con cualquier ORM podría definir un modelo de tipo "Versionable" y la superclase se encargaría del trabajo sucio, lo que no me gusta es ver la BD con tanta tabla duplicada.

¿Ustedes que opinan?

[luisgutierrezb]

Bueno creo que voy a hablar sin saber pero segun lo que veo, si haces una sola tabla historica con el tipo de componente y la revision la puedes obtener con un count a esa tabla historica

[D-MO]

Saludos Luis, te comento, el problema no es como obtener los datos, sino (hablando del primero de los casos) que como mantengo el histórico de dispositivos asociados a un equipo y que la relación no se pierda aún si el equipo cambie de versión. Ejemplifico:

Computadora 10, versión 1
- HD #50, version 1
- Ram 1GB #75, version 1
- Ram 1GB #130, version 1
- ...

Viendo este caso, todo marcha a la perfección, ahora los problemas:

El Disco Duro sufre problemas y se manda por garantía, se reemplaza por el HD #200 (el de "repuesto"). en ese momento debe suceder lo siguiente:

1. El disco duro #50 se marca como deshabilitado
2. La computadora cambia a la versión 2
3. Se le incrementa un 1 a la versión del disco # 200
4. El Disco Duro #200 se asigna a la computadora #10, versión 2

Luego, resulta que el Disco solo tenía un pin roto (por pensar en algo) y bastó con que la empresa que cubre la garantía lo reparara y listo, debemos regresarlo a la computadora original, en ese momento debe suceder lo siguiente:

1. El Disco Duro #50 se cambia a versión 2
2. La computadora #10 se cambia a versión 3
3. El Disco Duro #200 se marca como "desconectado"

Ahora, resulta que necesitamos utilizar una de las memorias ram del equipo #10 en otro, así que debería suceder lo siguiente:

1. Computadora #10 cambia a versión 4
2. Memoria #130 se asigna a Computadora #33
3. Memoria #130 se cambia a versión 2
4. Computadora #33 se cambia a versión 2

Y lo mismo para cualquier modificación, tanto en la computadora como en sus componentes. Un cambio en un componente podría ser simplemente el hecho de moverlo a otro equipo.

El problema acá es, cuál sería la forma mas eficiente de modelar la BD para que cumpla lo siguiente:

Alguien (un directivo) necesita que se le de un reporte especificando que configuración tenían los equipos en una determinada fecha, y de allí para acá hacer un rastreo de todos los cambios que han sufrido, desde un simple cambio de usuario, software, ip, hasta un cambio de procesador, ram, etc... Así mismo, por qué equipos y en que momento ha pasado determinado componente.

Si se preguntan, ¿Quién podrá pedir reportes de este tipo?... recuerden pues que trabajo para el gobierno y acá cualquier cosa es posible

Y muchos dicen que no es muy importante el análisis y diseño lógico de sistemas previo a su desarrollo, se imaginan haber empezado a programar sin haber pensado en esto primero... ¡¡¡Dios me libre!!!

Saludos

[D-MO]

Dándole algunas vueltas al asunto, pensando en la segunda opción, el modelo de la bd quedaría de la siguiente manera (ojo que solo incluyo dos componentes):



Uploaded with ImageShack.us

Aunque, como todos comparten la misma estructura en la tabla principal, y cada componente (independientemente del tipo) tiene un ID único, lo ideal sería una sola tabla principal (Configuration Item) que contenga el id y la versión y todas las demás mantengan el histórico de las versiones de cada una en su propia tabla, quedando mas o menos de la sigueinte manera:



Uploaded with ImageShack.us

Pácticamente es una mezcla de las dos opciones que comento en el primer post, hasta aquí he podido optimizar, o al menos eso pensaba, hasta que recordé que cada tipo de componente tiene atributos específicos que no van a variar de una versión a otra, por lo que necesitaría una tabla maestra para cada uno, estos datos serían:

Disco Duro: Capacidad
Ram: Capacidad/Velocidad
Procesador: Nucleos/Velocidad/Socket
Monitor: Tamaño

Por mucho que el componente sufra cambios, nunca podrán cambiar estos (y muchos otros) atributos propios. Por lo que vuelvo al mismo punto. ¿Será la solución de las múltiples tablas la mas indicada?

Saludos.

[luisgutierrezb]

yo creo que las multiples tablas si serian la opcion porque por ejemplo en disco duro tal vez debas especificar que tipo es, ide, sata, SSD aparte de la capacidad y que tal si adquiren un disco hibrido sata-ssd y que tal si despues salen los discos duros enfriados por agua (es un decir) entonces con una tabla por componente creo yo que aunque es mas trabajo, es mas facil el mantenimiento, o solo que se uniformaran las caracteristicas de todos los componentes donde tipo sea DDR3 para la memoria y Sata para un disco duro y blue ray para una unidad optica, etc

[D-MO]

Saludos Luis, lo que dices es justamente la razón por la que cada clase representa un objeto real, osea, se está modelando desde el punto mas bajo. En diagrama ER no he detallado todos los atributos de cada objeto, solo las diseñé para darme una idea y evaluar de mejor manera la situación. La verdad es que quizá termine diseñando un híbrido entre ambos modelos, es a lo que le he estado dando vueltas.

Otro punto muy importante, que no he especificado. Quizá alguien esté pensando que si estamos duplicando los registros cada que se hace una modificación, la BD crecerá de manera exponencial. La verdad que sí, eso está contemplado. Lo que estoy pensando es que la aplicación en producción debería ser "purgada" cada cierto tiempo, dependiendo del volumen de información que almacene. Así podríamos decir que cada 15 días se saca una copia de los registros y pasan a una segunda base de datos, la Base Histórica, el Data Warehouse, y será desde acá donde se generarán los reportes, así no sacrificamos el rendimiento de la aplicación en producción cada que se necesite un reporte muy detallado.

Esta es mi loca idea hasta el momento, a ver en que termina.

Saludos.