IA PRCTC

Tened en cuenta de que cuando hablamos de Sistema de Información, no nos referimos a la base de datos del catálogo de productos de nuestra empresa, si no al catálogo que está conectado al ERP, que está conectado al CRM, que está conectado al Subsistema de contabilidad, que está conectado al Directorio de RRHH,…

Primero, siéntate y observa

Una estrategia efectiva puede ser estudiar cómo es el acceso a nuestras estructuras de datos y utilizar diversas técnicas de acceso según sea nuestra clasificación atendiendo a 3 intenciones:

• Minimizar las consultas a los servidores de datos del sistema de información.
• Minimizar el tráfico de red por el que viajan estos datos.
• Minimizar las operaciones que tienen que llevarse a cabo para que los distintos sistemas de información que manejamos (CRM, Financiero, ERP,..) mantenga la coherencia.

Segundo, busca patrones de conductas y relaciones

Estamos buscando una estrategia de acceso a las distintas casuísticas de datos, para lo que podremos distinguir 4 grandes grupos:

Pequeños conjuntos de datos, recurrentes, estáticos:

son datos que se consultan infinidad de veces durante el uso de las aplicaciones de explotación de datos, y que varían poco en el tiempo.

Aquí podemos directamente precargarlos cuando inicie la aplicación, y volcarlos en ficheros XML o JSON locales (caché) para que en la próxima carga ni siquiera tengamos que pedirlos al servidor. Podemos hacer que cuando la aplicación detecte que el fichero tiene más de una semana, pida una actualización al servidor. Existen unos pequeños servidores de bases de datos muy rápidos para uso local (redis), pero estamos hablando de grupos de datos muy pequeños, que se leen una única vez al cargar la aplicación y quedan en memoria.

Esta estrategia es algo semejante a cachear datos en el IIS cuando programamos una capa de datos, aunque la caché de IIS nos permite de serie funciones que nos ahorrarán líneas de código.

Ejemplos típicos de esta casuística de datos son: etiquetado con la traducción de nuestras aplicaciones si son multiidioma, datos de sucursales, departamentos,… de nuestra compañía.

Grandes conjuntos de datos, recurrentes, estáticos y que requieren un cálculo (o no):

Estos datos son el territorio del Data Warehouse. Pueden ser desde resultados anuales de venta (una vez cerrado el año ya no pueden cambiar), Ranking de clientes, listas de precios o artículos … insistimos, son grandes volúmenes de datos, sujetos a pocos cambios o de aplicación macroscópica, y por lo tanto, no debe afectarnos que se actualicen 1 vez al día o cada 12 horas, en ventanas de tiempo de baja actividad del sistema. 

Especialmente interesantes son en el caso del Datawarehouse, los procesos de ETL que nos recalculan filtran y formatean la información de varias fuentes y nos la dejan lista para el consumo por otra aplicación (generalmente un cuadro de mandos o recurso de Business Intelligence)

Tal vez no necesitemos el listado de artículos para los informes de Power BI, pero sí es una buena estrategia llevarlos al DW y almacenarlos allí para que sean consultados a esta fuente en vez de que una aplicación ataque directamente a la base de datos de producción.

Conviene mantener a la vista también en estos escenarios el uso de una base de datos espejo de sólo lectura (logshipping, snapshot o replicación asíncrona), y también tener cuidado con la frecuencia de sincronización de la base de datos Maestro y su espejo, ya que podemos bloquearlo todo si la base de datos es grande y la frecuencia de sincronización demasiado alta.

Pequeños conjuntos de datos, en tiempo real:

Estas consultas también existen, aunque no nos gusten, y deben atacar directamente a la base de datos del sistema de producción, ya que necesitan que la actualidad de los datos sea máxima: por ejemplo, la lista de pedidos pendiente de procesar o las últimas facturas abonadas para el sistema financiero, la dirección de envío de un pedido,… pueden haber sido cambiadas en cualquier momento, y el impacto de no tener esta información actualizada es un riesgo para nuestro negocio.

Afortunadamente suelen afectar a conjuntos pequeños de datos, o incluso a una única fila, por lo que una buena estrategia combinada de claves, índices y procedimientos almacenados para llevar a cabo la recuperación de la información con un bajo impacto.

Grandes conjuntos de datos en tiempo real:

No deberíamos encontrar en el diseño grupos de datos en esta clasificación, siempre que no estemos hablando de proyectos de telemetría o IoT, en estos casos optaríamos por una arquitectura diferente.

Tercero, medita y saca conclusiones

Una vez tengamos clasificados los datos que necesitará nuestra aplicación, podremos mapear las consultas al almacén más eficaz, teniendo en cuenta tanto el volumen como la volatilidad de los datos.

Haz un documento de análisis de riesgos-alternativas y expónselos al cliente, para que entienda las consecuencias de lo que nos pide, y que no todo puede ser inmediato-supermasivo.

Cuarto, se implementa al final, no al principio

Aunque parece que ahora no está de moda hacer un análisis tan profundo de los datos y los requerimientos antes de desembarcar a los programadores, para modelos BAU (Business As Usual) consolidados tendremos la oportunidad de disponer desde el principio de una aplicación bien estructurada, con las consultas necesarias a los lugares indicados.

Las metodologías ágiles están muy bien, pero hay que elegir las zapatillas adecuadas al terreno por el que vamos a correr.