Hosting Peru

Opinión: Entre otras cosas, es importante evitar el ?Síndrome de Diógenes de los Datos?.

Cuando se quiere organizar, ordenar o diseñar un modelo de datos de información, es necesario guiarse por la experiencia. Así, existen cinco claves para diseñar, construir y mantener un modelo que soporte el proceso de la toma de decisiones en cualquier organización.

La primera de ellas tiene que ver con lo relevante de la data. Para resolver una necesidad de información, el modelo debe contener información relevante para el proceso de negocio y objetivo del área o proyecto que lo utilizará. Y es que se corre riesgo de almacenar demasiados datos, ya sea por caer en el ?Síndrome de Diógenes de los Datos?, o sea, recolectar datos que se asume servirán en el futuro; o por almacenar información útil, pero al mismo nivel de detalle que los sistemas operacionales, lo cual sirve para una solución de reportes, pero no para los demás tipos de soluciones. Lo recomendable, entonces, es analizar los datos fuente e identificar los datos útiles para el negocio y aquellos que aporten información al proceso.

La segunda clave es enfocarse en las necesidades existentes. Un error habitual es guiarse por el cómo resuelven la necesidad de información en vez de pensar más el qué necesitan. Así, el modelo de datos no sólo debe soportar y mejorar el proceso actual, sino también considerar el objetivo de la solución de información y ser diseñado en función de las necesidades y, por supuesto, de las capacidades de la organización. La idea es llevar más allá el uso de los datos, facilitar el acceso, simplificar los procesos y permitir el desarrollo futuro de la solución.

La tercera es que el modelo sea flexible y escalable, lo cual se basa en los dos tips anteriores.

La cuarta tiene que ver con no duplicar datos. Para mantener un modelo consistente en el tiempo y a lo largo de las distintas necesidades de información que surjan, la no duplicación de datos es vital. El modelo de información será más eficiente mientras los datos de consulta frecuente, asociados a un tema específico, se encuentren juntos. Así, no es necesario tener una tabla diferente de Cliente por cada data mart que exista. Por ejemplo, si ya hay un data mart de Ventas que contiene las dimensiones de Cliente y Producto y se requiere construir uno nuevo de Costos, es recomendable reutilizar las dimensiones compartidas como Cliente y Producto y agregar las columnas necesarias para analizar los datos de costos. Esto permite mantener una sola tabla por dimensión de análisis, lo que simplifica los procesos de mantención y permite analizar con los mismos datos diferentes perspectivas de negocio.

Por último, se requiere una clave única y separar los ambientes Operacional del de información, pues a pesar de que sean los mismos datos fuentes, la forma de almacenarlos en el modelo de información debe ser diferente.

Por Diego Arenas, jefe Soluciones Business Intelligence de Formulisa