CONTEXTO: El conjunto organizado de datos de carácter personal como piedra angular de información, sometido a una serie de operaciones y procedimientos técnicos constituyen en su conjunto los sistemas de información. En concreto, pueda que "0199190517" sean solo una serie de números sin sentido alguno, pero si lo consideramos dentro del conjunto "Luis Boggio", "Chimbote" , "Diseñador gráfico" y "0199190517" asociado a los entidades de "Persona", "Ciudad", "Desempeño", "Teléfono"; esta serie numérica tiene otra valoración y ponderación cuando lo que necesitamos es un "Diseñador gráfico" y deseamos contactarlo con consideración para requerirle sus servicios - Señor Boggio? Lo saluda... para... Pero el dinamismo de nuestros tiempos nos somete a cambios constantes; pueda que nuestra necesidad de un "Diseñador gráfico" se vea con el inconveniente de no poder contar con él porque lo creíamos en Chimbote, cuando en realidad se encuentra desarrollando unos trabajos por Lima. Entonces es necesario tener una operación de actualización. Y como siempre hay soluciones en esta vida, pueda que definitivamente no podamos contar con "Luis Boggio", entonces habrá que buscar a otra opción que este disponible y ofrezca las misma garantía de calidad; y buscaremos "Diseñador gráfico" dentro de la lista de diseñadores gráficos y que además se encuentre en Chimbote. Tendremos pues todo un sistema que cubre nuestras necesidades de información donde podremos tomar decisiones según convenga. Hasta ahora pues no tenemos nada especial, no he dicho nada de lo que ya todos de alguna manera saben; pero existen consideraciones que podemos resumir y ampliar como sigue: Los actuales sistemas siempre registran y presentan datos recientes. Los sistemas con varios usuarios, con permisos de modificar los datos, registran las modificaciones pero a nivel de auditoria; es decir, toda consulta de modificaciones "accidentales", se tiene que recurrir al personal de sistemas para saber el antiguo contenido y el responsable de la modificación puede estar inmerso en un ambiente de dramatismo por las especulaciones de sanción que se pueda aplicar, además de haber perdida de tiempo del personal de sistemas y el proceso de espera Algunos sistemas asocian todo el conjunto de datos a un solo responsable de la modificación: esto es poco real pues pueda que solo haya modificado un solo campo especifico (ejemplo: teléfono) y no los campos restantes. Es razonable saber también cuando fue registrado la modificación de dicho campo, para ver que tan reciente fue el nuevo cambio. Este es el punto a tratar en este pequeño trabajo, puesto que existen datos con altos índices de variaciones y modificaciones, estas son necesarias tenerlas presentes con cierta celeridad sin procesos de espera, sin sobrecargar las tareas y trabajos de personal de sistemas. Problema Modelar un sistema que este en capacidad de manejar: Un conjunto de datos como un solo registro (ejemplo: nombre, apellidos, dirección, ubigeo, teléfono, email, Pág. Web, etc.) reconociendo al responsable de creación, modificación y la fecha en que se produjo el evento. Que cada campo pueda guardar la ultima modificación, el responsable de la misma y la fecha en que sucedió Que pueda presentar un histórico de modificaciones por campos: el nombre del campo, el antiguo dato, el responsable antiguo, la fecha antigua, el nuevo dato, el responsable nuevo, la fecha nueva Ejemplo demostrativo: detalles del problema El manejo de agenda de contactos es muy usual y necesario con el tiempo, pero existe la dinámica de tener contactos que suelen viajar mucho y tener temporadas largas de estadio o trabajo en diferentes ciudades El ubigeo esta en relación a la ubicación, para nuestro caso: país, departamento, provincia y distrito (Ver documento adjunto: diccionario_2002.doc) Una opción es trabajarlo como una sola tabla (existe la razón de simplicidad de almacenamiento y procedimientos de consultas cuando existe un solo ID) La presente propuesta esta en función de: La selección de un país determinado, automáticamente carga sus departamentos correspondientes. La selección de un departamento cualquiera, automáticamente carga las provincias que le pertenecen al departamento seleccionado Para la selección de una provincia de igual manera, cargar los distritos que son de su jurisdicción Detalle de funcionalidad: La selección de un país es obligatorio. La selección de un país diferente de "PERÚ", los demás datos no son obligatorios La selección de un departamento diferente de "ANCASH", los demás datos no son obligatorios La selección de una provincia diferente de "SANTA", los demás datos no son obligatorios Si la provincia es "SANTA", debe seleccionar un distrito diferente a "" Inicialmente los valore por defecto son: País: PERÚ Departamento: ANCASH Provincia: SANTA Distrito: NUEVO CHIMBOTE Para casos de otros países, poder agregar estructura organizacional a fin a la estructura de: país, departamento, provincia, distrito Poder ver el histórico de modificaciones: el dato antiguo, la fecha en que fue ingresada, el dato nuevo y la fecha que fue ingresado el nuevo dato (esto se puede ampliar para un sistema de muchos usuarios, es decir: el responsable antiguo y nuevo del dato guardado) Ejemplo demostrativo: propuesta de solución La base de datos tendrá la estructura del ubigeo individualizado, es decir, una tabla para país, departamento, provincia y distrito El registro presentara bloques de trabajo siguientes: Para país: Id _ país, fecha _ país Para departamento: Id _ departamento, fecha _ departamento Para provincia: Id _ provincia, fecha _ provincia Para sistrito: Id _ distrito, fecha _ distrito Nuevamente se puede señalar que para sistemas de varios usuarios se puede agregar : -- autor_"nombre de campo" --, para señalar al responsable del dato guardado El formulario de visualización deberá presentar entonces ciertas característica particulares: o Al ingresar un nuevo registro deberá cargar con el ubigeo por defecto: PERU - ANCASH - SANTA - NUEVO CHIMBOTE o Todas las funcionalidades de modificaciones del ubigeo serán soportados solo en el formulario, se consideraran para modificación solo con un botón señalado para el caso de "ACTUALIZAR" o Las modificación será efectiva solo si el dato a actualizar es diferente al dato guardado Si es así: generar un registro en el histórico señalando: El campo donde se produce la modificación El dato antiguo La fecha en que se guardó el dato antiguo El dato nuevo La fecha en que se guarda este dato (este dato guarda la fecha actual: se puede ampliar el detalle guardando la hora) Nuevamente si se desea ampliar el detalle al responsable del dato antiguo y nuevo De lo contrario no ocurre nada, y no se genera ningún histórico Finalmente es necesario señalar que esta pequeña ayuda de la agenda es mejorable sin duda, pero es una pequeña experiencia que deseo compartir, sugerencias y comentario serán bien venidos Ejemplo demostrativo: software empleado VB6 - APLICATIVO SQL SERVER Ejemplo demostrativo: esquema de BD País ID Descripción Departamento ID Descripción Provincia ID Descripción Distrito ID Descripción Amigos o ID o Campos como: nombre, apellidos, etc... o Id_ país o Fecha _ país o Id _ departamento o Fecha _ departamento o Id _ provincia o Fecha _ provincia o Id _ distrito o Fecha _ distrito o Otros campos complementarios: email, pagina Web, etc Historico_Amigos ID ID_amigos Nombre _ campo Dato _ antiguo Fecha _ antigua Dato _ nuevo Fecha _ nueva Ejemplo demostrativo: formulario vb propuestos Formulario para ingreso Formulario para modificaciones o actualizaciones Ejemplo demostrativo: estrategia a seguir Utilización de procedimientos almacenados Amigos Insert_Amigo Select_Amigo Update_Amigo Select_Historico_Amigo Ubigeo Select_Pais Select_Departamento Select_Provincia Select_Distrito Criterios predefinidos Los comparaciones para detectar variaciones de datos se realizaran: SinAcentos(Ucase(dato guardado)) <> SinAcentos(Ucase(dato entrante)) Solo para la etapa de comparación La fechas se trabajan como cadena "año" + "mes" + "dia": ejemplo: "20040802" y se presentaran en formulario "02/08/2004" El seguimiento de datos, sus modificaciones y variaciones en el tiempo nos pueden ser de gran ayuda, tanto para una pequeña agenda de amigos como para un sistema de seguimiento interno de datos, permite la interrelación dinámica entre el personal encargada de hacerlo; terminando el mar de especulaciones y preocupaciones innecesarias por la perdida de algún dato antiguo, pues los datos antiguos siempre estarán presentes y visibles en el histórico. Conclusiones: Es evidente la dinámica de los datos y su importancia en el tiempo. Facilitar los procesos de actualización y el seguimiento de estas actualizaciones es una necesidad creciente en las empresas de estos tiempos de la era digital. Recurrir a sistemas mas sofisticados pueda que supere los costos programados, por lo que es necesario recurrir a alternativas mas económicas - como la propuesta en este documento, aun más si se recurre a programas no propietarios - ; el siguiente punto a considerar será el incremento acelerado del volumen de información, y en consecuencia mayor consumo de tiempo para las consultas. No todo es fácil, porque seria muy aburrido.. ¿di? Bibliografías Experiencia laboral 2004 Comenta éste artículo en el foro de informatizate.     Otros Artículos del Autor: Fecha Publicación: Libertad de libertades Abril 26 del 2004 Planes de Trabajo 21 de Setiembre del 2003