Я в целом согласен с ответом Дамира на это, но поскольку таблица фактов очень узка в вашем конкретном случае, все же есть смысл в том, чтобы Аарон поддерживал сохранение NULL.
У нас есть несколько звездных схем в конкретных предметных областях с несколькими таблицами фактов, которые разделяют большинство (если не все) измерений (согласованных и внутренних). Измерения ограниченной области не считаются «согласованными» в масштабах всего предприятия, но это то, что мы бы назвали «общими внутренними» измерениями.
Теперь обычно, если данные загружаются одновременно, так что измерение не изменилось, вы можете объединить обе таблицы фактов на ключах, но в общем случае, конечно, вы не можете объединить две разные звездные схемы на ключах измерений, если они являются суррогатами в традиционных медленно меняющихся измерениях. В общем случае вы должны объединять отдельные звезды по естественным ключам или «бизнес-ключам» в измерении, а не в суррогатах (за исключением обычно в особом случае измерения даты, когда оно не меняется и имеет только естественный ключ).
Обратите внимание, что когда вы присоединяетесь к двум звездам, вы должны использовать LEFT JOIN, и в этом случае вы получите NULL, которые вам, вероятно, все равно придется учитывать - так что вы фактически возвращаетесь к исходной модели. Вы имели с NULL! ; -)
Преимущество дополнительной таблицы фактов становится более очевидным, когда у вас широкие таблицы с меньшим набором ключей, а вертикальное разделение данных обеспечивает экономию пространства, а также более чистую логическую модель - это особенно верно, когда ключи только действительно поделился до некоторой степени - наличие одного фиктивного ключа или NULL-ключа определенно не очень хорошая идея - это обычно указывает на проблему размерного моделирования.
Однако, как говорит Аарон, если вы доведете его до крайности, в каждой таблице фактов может быть один столбец фактов с общими ключами, что означает, что издержки, связанные с ключами, уменьшают стоимость фактов, и вы действительно в конечном итоге получаете замаскированный EAV модель.
Я бы также посмотрел, не окажетесь ли вы в ситуации Кимбалла "слишком мало измерений". Похоже, что у вас должны быть хорошие размерные атрибуты, смешанные в SessionKey и SiteItemKey - но, не видя всей вашей модели и требований, сложно сказать, но я думаю, что у вас будут некоторые демографические данные в низко-кардинальном или даже снежинчатом измерении без полное измерение сеанса или сайта.