Configurar tablas de Dim y Fact para un Data Warehouse

Question

Tengo la tarea de crear un datawarehouse para un cliente. Las tablas involucradas realmente no siguen los ejemplos tradicionales (productos / pedidos), por lo que necesito ayuda para comenzar. El cliente es esencialmente un centro de procesamiento de casos (similar a un caso legal). Cada día, se ingresan nuevos casos en la base de datos debajo de " casos " mesa. Cada columna contiene algo de información relacionada con el caso. A medida que se procesa el caso, se completan tablas uno a muchos adicionales con eventos relacionados con el caso. Hay bastantes de estas tablas de eventos, las tablas de ejemplo pueden ser: (case-open, case-dept1, case-dept2, case-dept3, etc.). Cada una de estas tablas tiene un caseid que se asigna de nuevo a los "casos". mesa. También hay algunas tablas de búsqueda involucradas también.

Actualmente, las necesidades de informes se relacionan con la exposición de cuellos de botella en las distintas etapas y la granularidad se encuentra en el nivel horario para ciertas áreas del proceso.

Puedo estar preguntando demasiado aquí, pero estoy buscando alguna dirección sobre cómo debo configurar mis tablas de Dim and Fact o cualquier otra sugerencia que pueda tener.

Answer 1

Le sugiero que consulte los libros de Kimball, particularmente este , que debería tener algunos ejemplos para que piense en las aplicaciones para su dominio problemático.

En cualquier caso, debe decidir si un modelo dimensional es incluso apropiado. Es muy posible tratar un 'almacén de datos empresariales' de una base de datos 3NF con diferentes índices o resúmenes, o lo que sea.

Sin ver su esquema actual, es REALMENTE difícil de decir. Parece que terminarás con varios modelos de estrellas con algunas dimensiones conformadas que los unen. Por lo tanto, puede tener una dimensión de caso como una de sus dimensiones conformadas. Las tablas de hechos de cada una serían tablas de hecho que se vinculan tanto a la dimensión conformada como a cualquier otra dimensión apropiada para los hechos, por ejemplo, si hay una identificación de empleado en caso abierto, se vincularía a una dimensión conformada de empleado , de la tabla de casos abiertos. Esta dimensión conformada puede vincularse varias veces desde varias de sus tablas de hechos subsidiarias.

El método de modelado de Kimball es bastante sencillo y puede seguirse como una receta. Debe comenzar por identificar todos sus hechos, agruparlos en tablas de hechos, identificar dimensiones individuales en cada tabla de hechos y luego agruparlos según corresponda en tablas de dimensiones e identificar el tipo de cada dimensión.

Answer 2

La tabla de hechos es el evento de caso y no tiene ningún hecho porque no tiene valor numérico. Las dimensiones serían tiempo, tipo de evento, caso y tal vez algunos otros dependiendo de qué otros datos hay en el sistema.

Debe consolidar las tablas de eventos en una sola tabla de hechos, etiquetada con una dimensión de 'tipo de evento'. Los informes de rendimiento / cuello de botella calculan las diferencias entre los tiempos de eventos para combinaciones específicas de tipos de eventos en un caso determinado.

Los informes deben calcular los tiempos de evento-evento y posiblemente agruparlos en un histograma. También puede etiquetar ciertos tipos de combinaciones de eventos y aplicar la etiqueta a los eventos de interés. Estos eventos podrían tener el tiempo registrado en su contra, lo que permitiría operaciones de cortar y cortar en dados en el momento con una herramienta OLAP.

Si desea comparar ciertas etapas en la progresión del ciclo de vida, tendrá una tabla que incluye el tipo de caso, tipo de evento 1, tipo de evento 2, tiempo de referencia.

Con un poco de masaje, es posible que pueda usar un kit de herramientas de minería de datos o incluso un simple análisis de regresión para detectar correlaciones entre atributos de caso y tiempos de evento-evento (YMMV).

Answer 3

Como cualquier otra faceta del desarrollo, debe abordar el problema desde los requisitos finales ("historias de usuario", si lo desea) hacia atrás. El enfoque más conservador para un almacén es simplemente representar una copia de la base de datos de transacciones. A partir de ahí, guiados por los requisitos, se pueden realizar ciertas optimizaciones para mejorar el rendimiento de ciertos patrones de acceso a datos. Sin embargo, creo que es importante ver esto como optimizaciones y no asumir que un almacén de datos automáticamente debe ser una explosión compleja de cada dimensión posible sobre cada hecho. Mi experiencia es que, para la mayoría de los propósitos, una representación directa es adecuada o incluso ideal para más del 90% de las consultas analíticas. Para el resto, primero considere los índices, las vistas indexadas, las estadísticas adicionales u otras optimizaciones que se pueden realizar sin afectar las estructuras. Entonces, si se necesita la agregación u otras estructuras redundantes para mejorar el rendimiento, considere separarlas en un "data mart". (al menos conceptualmente) que proporciona una separación entre hechos primitivos y redundancias de los mismos. Finalmente, si los requisitos son demasiado fluidos y la agregación exige demasiado para funcionar eficientemente de esta manera, entonces puede considerar explosiones de datos al por mayor, es decir, el esquema estelar. Una vez más, limite esto a la sección transversal más pequeña posible de los datos.

Answer 4

Esto es lo que se me ocurrió esencialmente. Thx NXC

Eventos de hecho

EventID TimeKey CaseID

Dim Eventos

EventID EventDesc

Tiempo de atenuación

TimeKey

Regiones tenues

RegionID RegionDesc

Casos

CaseID ID de región

Answer 5

Este puede ser un caso de elegir una solución antes de considerar el problema. No todos los datawarehouses se ajustan al modelo de esquema en estrella. No veo que esté agregando ningún dato aquí. Hasta ahora tenemos una tabla de hechos sin hechos y al menos una dimensión (casos) que cambia rápidamente.

Mirando lo que veo hasta ahora, creo que la entidad central en esta base de datos debería ser el caso. Intentar mantener el evento en el medio no parece correcto. Intenta verlo de otra manera. Tal vez, caso, eventos y eventos de caso para comenzar.