Внешние ключи таблицы фактов пустые?

Я новичок в дизайне витрин данных и мне нужно прояснить несколько концепций.

Я немного ознакомился с моделированием измерений, где я вижу, что таблицы фактов хранят ссылки на внешние ключи для таблиц измерений.

Теперь предположим, что у меня есть таблица измерений phonenumber и таблица измерений phone_extension. (Эти таблицы имеют разные детали, из-за которых я не могу их объединить)

Как я понимаю, обе эти таблицы измерений будут иметь целочисленные первичные ключи для лучшей производительности, а таблица фактов будет иметь свой собственный целочисленный первичный ключ, а также хранить ссылки на внешние ключи на эти таблицы измерений.

Но предположим, что у меня есть ситуация, когда не все телефонные номера имеют отношение phone_extension к ним. (некоторые телефонные номера не должны иметь добавочного номера)

Для телефонных номеров, которые имеют добавочный номер, таблица фактов будет иметь ссылки на внешние ключи для обеих таблиц измерений, но как мне отразить ситуацию, когда есть только телефонные номера и нет добавочных номеров (и наоборот, то есть добавочный номер без телефонных номеров) ?

Должен ли я собирать такую ​​информацию с помощью номера телефона FK в таблице фактов, имеющей значение и внешний ключ phone_extension null ?? Или такие не связанные объекты не записаны в таблицах фактов?

Также мне нужно сгенерировать отчет об этом витрине данных. Поэтому начать с запроса таблицы фактов и получения значений ключа измерения или составить отчет прямо из таблицы измерения?

Спасибо за ваше время в чтении этого!
Цени любую помощь!

Вы можете оставить FK для некоторых таблиц измерений как NULL, если эти измерения неизвестны или неприменимы. Вам просто нужно помнить об использовании внешних объединений при выполнении запроса отчетности.

В качестве альтернативы, некоторые люди создают запись измерений «нет» и / или «н / д» для измерений витрины данных, а затем заполняют FK таблицы фактов, чтобы указывать на них, а не на значения NULL. Людям, которые делают это, нравится этот подход, потому что они испытывают отвращение к внешним соединениям.

Люди, которые используют NULL FK в таблицах фактов, обычно испытывают отвращение к людям, у которых есть версия для внешних объединений. ;) (другими словами, это стилистическая проблема, которая может привести к религиозным войнам)

Я говорю: делай, что захочешь, но выбери один подход и горячо придерживайся его.

Не кладите нули в склад или в витрины.

Склад должен быть хорошо нормализован (по крайней мере, BCNF) и поэтому должен исключать нули. Нули могут быть сохранены в промежуточных таблицах, если они существуют в источниках данных, но они не должны быть необходимы в самом хранилище.

Рынки должны быть разработаны для поддержки инструментов представления и пользовательских запросов. Null просто мешает этим вещам, потому что они никогда не отображаются, и они делают пользовательские запросы более сложными и подверженными ошибкам - особенно в столбцах внешнего ключа, которые часто подвергаются объединениям.

ключи фактов в фактах должны быть не нулевыми, и у них есть fk для измерений, чтобы исключить необходимость в левых внешних соединениях конечных пользователей, отчетов и т. д. Все нагрузки фактов должны выполнять левое внешнее соединение с измерением и по умолчанию используется ключ 0 или нет ключа вообще и не получится. Лучше потерпеть неудачу, чем выполнить соединение с измерением и не подозревать, что вы пропустили строки в своем факте, пока некоторые пользователи наконец не найдут его (если это когда-нибудь случится)

создайте запись «n / a» в измерении phone_extension и создайте ссылку на нее.

моё правило о themb - единственное значение, которое можно обнулять в datamart, и сам факт, так что агрегатные функции, такие как avg, все еще работают.