Investigando un poco, encontré un artículo escrito por una de las personas que trabaja en el equipo de Kimball. Propone 10 reglas básicas que habría que seguir en la construcción de un modelo dimensional y me parecieron interesantes para compartir con ustedes. Les dejo las primeras cinco, y en un próximo post detallaré las restantes.
Regla 1: En una estructura dimensional se deben cargar los datos con el mayor nivel de detalle posible.
Llenar los modelos dimensionales con el mayor nivel de datalle posible nos debería ayudar a soportar filtros y agrupaciones inpredecibles requeridas por el usuario. Por lo general los usuarios no necesitan ver la información linea por linea, pero no se puede predecir las diferentes formas en que quedrán navegar y rotar la información. Si sólo hay disponible información sumarizada, uno puede estar asumiendo un modelo que cuando el usuario quiera ir a un nivel de profundidas mayor, no le resultará útil. Por supuesto que el detalle atómico puede y debe ser complementado con modelos sumarizados para ganar eficiencia.
Regla 2: Estructurar los modelos dimensionales en torno a los procesos de negocio.
Los procesos de negocio son las actividades realizadas por la organización; los mismos representan eventos medibles, como tomar un pedido o facturarle a un cliente. Los procesos de negocios usualmente capturan o generan métricas de eficiencia asociadas con cada evento. Las métricas de tranforman en hechos, con cada proceso de negocio representado por una tabla de hechos. Además de las tablas de hechos de procesos únicos, a veces son creadas tablas de hechos consolidadas que combinan metricas de varios procesos en una tabla de hecho con un nivel común de granularidad para todas. Pero recordemos que las tablas de hechos consolidadas son un complemento a las detalladas, pero no las sustituyen.
Regla 3: Asegurse de que toda tabla de hechos tiene una tabla de dimensión tiempo asociada.
Los eventos mencionados en la regla 2 siempre están asociados a una fecha cierta, ya sea que se trate de un balance mensual o una transacción monetaria. Toda tabla de hechos siempre debe tener al menos una foreign key a una tabla de dimensión tiempo, cuya granularidad es la fecha única en que ocurrió el evento.
Regla 4: Asegurarsde que todos los hechos que están en una misma fact tengan el mismo nivel de granularidad.
Todas las medidas de una tabla de hechos deben estar al mismo nivel de detalle. Cuando uno mezcla hechos de diferentes niveles de granularidad en la misma tabla de hechos, se está llevando al usuario a aconfundirse y a hacer que las aplicaciones de BI arrojen resultados erroneos
Regla 5: Resolver las relaciones muchos a muchos en las tablas de hechos.
Partiendo de la base de que una tabla de hechos guarda los resultados de los eventos de un proceso de negocio, es muy probable que haya alguna relación del tipo muchos a muchos (M:M) vinculada entre sus foreign keys, como por ejemplo productos vendidos en múltiples negocios en múltiples días. Estos campos de las foreign key nunca deberían ser nulos. A veces las dimensiones puden asumir múltiples valores para un hecho único, tal como muchos diagnósticos asociados con una consulta médica. En estos casos no es razonable resolver la dimensión de varios valores directamente en la tabla de hechos. Esto violaría la granularidad natural del hecho. Así, usaremos una relación muchos a muchos, con una tabla puente de clave doble en conjunto con la tabla de hechos.
Fuente: Kimball University