martes, abril 24, 2007

Nace la revista GdR (Gestión del Rendimiento)


En estos dias he estado muy liado entre otras cosas ayudando a llevar a cabo un proyecto muy interesante, una revista en papel, de esas antiguas que se leían antes de que existieran los blogs, pues de esas. Se trata de la revista GdR (Gestión del Rendimiento) Al final me he involucrado tanto que hasta tengo sección propia y todo, con un título bastante críptico "Gap de Oxímoron".

El artífice de esta experiencia es Paco Marín, que no solo ha conseguido enredarme a mi, sino tambien a otro conocido blogger del BI Jose Maria Arce.

El caso es que el primer número ya esta en la calle, este año serán 4 números y para aquellos que llegueis tarde al primer número os podreis subscribir GRATIS a los 3 siguientes.

Os pongo el índice del primer número para que podais ver de que trata.

Espero que os guste.

domingo, abril 22, 2007

Starting Area (Características: Tercera Parte)

(Nota: Este post lo estoy haciendo desde los Docs de Google a ver como queda. Es que desde que perdí todos los datos de mi agenda, me he pasado a las aplicaciones de google y la verdad me están sorprendiendo gratamente.)

Con este post acabo la trilogía de la STA, lo prometo ;-D.
Por cierto dejad de comentad tanto que no me da tiempo a leerlo todo
(ostras, no veo como se pone la letra en "irónica", solo he encontrado "cursiva", je je)

Características:

1) Responder de forma ágil cualquier petición decisional que nos surja.

Si mezclamos información de detalle, con estructuras de Inmon, podemos responder de forma ágil a cualquier petición de información decisional.
Luego si vemos que es necesaria entonces ya crearemos una estructura de análisis de tipo dimensional (Kimball) si es necesario. Pero muchas de estas peticiones suelen morir al cabo de pocas semanas, de esta manera podremos ver el uso que se hace y si debemos incorporarla definitivamente a la estructura estable del DWH. Siempre que nos pidan algo muy específico, podemos poner la información en "cuarentena" en la Starting Area antes de decidir si es lo suficientemente madura para formar parte del DWH.

Así en la Starting Area tendremos información de detalle (operacional), información agregada (operacional) al estilo ODS, información agregada decisional (Inmon) que esta esperando la "madurez" para pasar al DWH e información unificada de diferentes modelos que sirve de embrión al Masterdata.

¿Que información almaceno entonces en la STA?
Pues en la Starting Area tendremos 4 tipos de información diferente:
  1. Información de detalle (operacional) inicio de los procesos ETL.
  2. Información agregada (operacional) al estilo ODS.
  3. Información agregada decisional (tipo Inmon) que esta esperando la "madurez" para pasar al DWH.
  4. Información unificada de diferentes modelos que sirve de embrión al Masterdata..

2) Diluirse a medida que la estructura decisional madura.

Obviamente mucha de esta información que ahora estamos poniendo en la STA, tiene que seguir si propia evolución hacia un sistema decisional mas completo, la información de tipo 2 y 3 deberían ir migrando hacia un DWH estilo Inmon de forma gradual, la información de tipo 4 evolucionar hacia un proyecto de Masterdata y la de tipo 1 ir desapareciendo a medida que se consolidan en otros sistemas los otros tres tipos de información.

Por eso la Starting Area tiene una fecha de caducidad.

domingo, abril 15, 2007

Starting Area (Funcionalidades: Segunda Parte)

En el anterior Post introduje como nació la Starting Area (STA de ahora en adelante).
Esta idea ha ido evolucionado y la STA cumple actualmente 4 funcionalidades y posee 2 características (que ya avancé en el anterior post)

1) Relanzar los procesos de ETL cuando los necesites.

La primera de ellas la pudimos ver en el anterior post. Se trata de tener siempre "llenos" los primeros pasos de los procesos ETL, y no borrar esa información. Para ello cogemos el último nivel de agregación desde el que construimos el DWH. Obviamente como vamos a dejar la información de forma permanente la STA debe estar obligatoriamente en una base de datos relacional diferente a la Staging Area (STG) para poder optimizarla y realizar tunning de forma separada en el caso de que el volumen de datos así lo hiciera recomendable.

2) Ser el embrión del MasterData

Obviamente todos estos procesos necesitan de una unificación del modelo cuando las fuentes de datos son heterogeneas. Por ejemplo si estamos unificando el concepto "Cliente" podemos tener un modelo E-R de Cliente en el ERP que nada tenga que ver con el "Cliente" del CRM y que en la aplicación de gestión comercial tenga otro significado muy distinto. Obviamente desde el punto de vista decisional nosotros tenemos un único "Cliente" así pues en la STA, cuando las fuentes de datos son heterogeneas ,nos quedamos con el último nivel de detalle pera una vez unificado el modelo. Así esta tabla puede ser unificada no solo en la parte decisional sino que cualquier otra aplicación que quiera hacer uso de "Clientes" puede intorducirla como su fuente de datos operacional, de esta manera tenemos el embrión de un MasterData de la organización que mas adelante pueda servirnos tanto para la parte de sistemas de información transaccionales, como para los sistemas de información decisionales. Es una buena manera de empezar a difundir el concepto de MasterData en aquella empresas que no están maduras.


3) Proveer de Reporting para la trazabilidad decisional a nivel de detalle.

Muchas veces desde el DWH necesitamos vincular con información de detalle cuyo detalle tenemos que ir a buscarlo al operacional, por eso nos puede llegar a interesar tener algún repositorio con esa información ya almacenada (siempre que no estemos tratando de información a tiempo real). Por ejemplo, si queremos saber el número de incidencias de producción la semana pasada lo tenemos fácil, pero si queremos buscar una descripción de los incidentes de gravedad 1 de esa misma semana para ponerlo en el Informe, entonces deberíamos ir al operacional. Para facilitar esto lo que podemos hacer es traernos un nivel de detalle mas bajo que el que estamos utilizando en el DWH y vincularlo con la base de la estrella al mas puro estilo Inmon, como Reporting. Alguien podría decir que esto no es mas que un ODS (Operational Data Storage) y le daría la razón pero con un matiz, y es que los ODS carga información operacional agregada y yo cargo información de detalle muy bajo, ya que la información típicamente agregada del ODS para mí es parte del modelo del DWH al combinar Inmon y Kimball en la base de la estrella.

Este nivel de detalle bajo nos puede ayudar también a crear el MasterData y nos da esa capacidad de reporting complementaria al DWH sin que tengamos que molestar a los operacionales.

4) Realizar mejora de la calidad de forma "continua"

La STA como he dicho tiene un repositorio diferente de la STG y obviamente del DWH, así que podemos lanzar los procesos de carga de la STA con una periodicidad mucho mas pequeña que no la del DWH limpiando y puliendo los datos antes de hacer la carga definitiva del DWH. Esto nos da la posibilidad de detectar los errores antes de lanzar los procesos definitivos y mas costosos, mejorando la calidad del dato y los tiempos de los procesos de carga.
De esta manera podemos construir escenarios en los que la STA se cargue diariamente y el DWH mensualmente. La mayoría de los posibles problemas de calidad del dato tienen 30 oportunidades de ser detectados antes de cargar el DWH.


Estas son las funcionalidades de la Starting Area, en el próximo (el último de esta trilogía) comentaré como construirla y sus dos características:

1) Responder de forma ágil cualquier petición decisional que nos surja.
2) Diluirse a medida que la estructura decisional madura.