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.

1 comentario:

Anónimo dijo...

Hola Jorge, felicidades por el blog lo he encontrado recientemente y ya lo sigo, en especial este artículo y su enfoque. Yo soy principiante en esto y tras leer a Kimbal y a Inmon me parece que la solución es la mezcla de ambos, aún así hay cosas que ninguno de los dos desvela, p.ej. si tu Master Data se puede equiparar a un ODS ó al modelo Inmon, ¿que modelo de datos se utilizaría? también el clásico de las dimensiones en la cual cada tabla tendría los date_from, date_to, version, etc, solo que totalmente en la 3 forma, ó sin estas variables de tiempo (en modo oltp vamos), pero si es así sólo tendremos la última versión de cada dato, y si no tenemos un histórico se hace imposible a veces volver a "recrear" el datawarehouse desde el principio si hemos tenido cualquier problema porque los datos pueden no estas ya accesibles en el oltp, así mismo si guardamos este histórico ¿acaso no estamos haciendo una copia exacta de las dimensiones?. Ahí es donde se me escapa tu modelo de Master Data y al propio Inmon. Gracias por compartir tus conocimientos. Saludos.