En general estoy de acuerdo con la respuesta de Damir al respecto, pero debido a que la tabla de hechos es muy limitada en su caso particular, todavía hay mérito en la defensa de Aaron por mantener los NULL.
Tenemos varios esquemas de estrella en áreas temáticas particulares con múltiples tablas de hechos que comparten la mayoría (si no todas) de las dimensiones (conformadas e internas). Las dimensiones de alcance limitado no se consideran "conformes" en toda la empresa, pero son lo que podríamos llamar dimensiones "compartidas internas".
Normalmente, si los datos se cargan contemporáneamente para que la dimensión no haya cambiado, puede unir ambas tablas de hechos en las claves, pero en general, por supuesto, no puede unir dos esquemas de estrella diferentes en las claves de dimensión si son sustitutos en las dimensiones tradicionales de cambio lento. En general, debe unir estrellas separadas en las claves naturales o "claves de negocios" dentro de la dimensión y no en los sustitutos (excepto por lo general en el caso especial de la dimensión de fecha donde es invariable y solo tiene una clave natural).
Tenga en cuenta que cuando se une a las dos estrellas, tiene que usar un LEFT JOIN, en cuyo caso PRODUCIRÁ valores NULL que probablemente tendrá que tener en cuenta, por lo que en realidad está volviendo al original modelo que tenías con NULLs!;-)
El beneficio de la tabla de hechos extra es más obvio cuando las tablas son anchas con un conjunto de claves más pequeño y la partición vertical de los datos produce ahorros de espacio y un modelo lógico más limpio; esto es especialmente cierto cuando las claves solo se comparten realmente hasta cierto punto, tener una clave ficticia o NULA definitivamente no es una buena idea, esto generalmente apunta a un problema de modelado dimensional.
Sin embargo, como dice Aaron, si llevas los extremos, puedes tener una sola columna de hechos en cada tabla de hechos con claves compartidas, lo que significa que la clave enana empequeñece el hecho y realmente terminas disfrazado Modelo EAV.
También me gustaría ver si estás en la situación de Kimball de "muy pocas dimensiones". Parece que debe tener buenos atributos dimensionales agrupados en SessionKey y SiteItemKey, pero sin ver su modelo completo y sus requisitos, es difícil de decir, pero creo que tendría algunos datos demográficos de usuario en una dimensión de baja cardinalidad o incluso copo de nieve sin el Sesión completa o dimensión del sitio.
¡Gracias por la discusión! Creo que tengo una situación de dimensiones internas compartidas. La comparación de unir dos tablas de hechos arroja luz sobre por qué mantenemos NULLs en lugar de ceros (los ceros afectarían el promedio aquí, y tenemos selecciones con casos extraños para NULL. No puedo divulgar mucho más sobre nuestro esquema, pero estás corregir que algunos usuarios podrían beneficiarse de dimensiones adicionales y más específicas. –