¿Una o varias tablas de hechos?

Question

Estoy tratando de construir una tienda de datos.

Tengo muchas dimensiones, y un par de medidas - hechos. Cada medida está conectada a todas las dimensiones en términos de negocios. Existe el enfoque estándar de que habrá una gran tabla de hechos con todas las medidas.

Pero tengo una idea: ¿Qué pasa si tengo tablas de hechos separadas para cada medida? ¿Qué hará con el rendimiento de la base de datos, la extensibilidad de la solución, etc.?

EDIT ::: existirá una enorme solución basada en cubos olap en un entorno corporativo realmente complejo. Por lo tanto, las necesidades son de fácil extensibilidad y mantenimiento al principio, luego, rendimiento

Answer 1

cliff notes: Veo problemas de escalabilidad en abundancia con la noción de una tabla de hechos/medida.

si su objetivo es la "extensibilidad y mantenimiento", entonces podría considerar seguir una metodología estándar para toda la industria ... como Kimball y agrupe sus hechos primero por proceso comercial y segundo por granularidad con dimensiones ajustadas. Esto, me alegraría argumentar, proporcionará la máxima flexibilidad & escalabilidad al mismo tiempo que garantiza la extensibilidad y el mantenimiento a través de la estandarización.

Además, sus SAN-admins odiarán sus agallas si diseña una tabla de hechos separada para cada medida porque efectivamente está aumentando los requisitos de espacio por la cantidad de medidas ... al menos inicialmente mientras todas sus medidas encajan actualmente una sola tabla de hechos.

El rendimiento de las consultas frente al DW también será un problema ... los informes y/o consultas ad-hoc tendrán que escanear (o buscar ... si sus san-admins todavía están hablando con usted y son lo suficientemente generosos para otorgarle el espacio necesario para indexar correctamente sus tablas de basura) en cualquier momento que necesite combinar más de 1 medida.

Aún no hemos discutido los cubos de olap, pero ya estoy temiendo los problemas de procesamiento que tendrá. Escaneos de tablas completos en abundancia ... o escaneos de particiones ... si implementa particiones en sus tablas de hechos ... lo cual debería hacer ahora con SQL 2012 en el horizonte ... ¡¡Estoy mirando ColumnStore Index !!

Answer 2

Si la granularidad de todas las medidas es la misma, manténgalas en la misma tabla. Solo comienza a usar tablas de hechos múltiples cuando tiene hechos de diferentes niveles de granularidad. Al ver que dijiste que todos tus datos están vinculados a todas tus dimensiones, en esta etapa parece que solo necesitas una tabla de hechos.