Обработка «многие ко многим», «1 ко многим», отношение между измерениями

Question

У меня есть сценарий, в котором один продавец связан с несколькими отделами, и мне нужно рассчитать продажи на уровне торгового представителя и уровня отдела. Пожалуйста, поделитесь мыслями о том, как это можно смоделировать

Мой мыслительный процесс ниже

Вариант 1

Я буду создавать как измерение 'Sales Rep' и измерение 'Department' и связать его с таблицей мостов, у которой есть dept_id и sales rep_id Здесь оба измерения я предпочитаю иметь историю, так что это тип SCD 2

Вариант 2

Я буду создавать измерение «Торговый представитель» и измерение «Отдел», а в измерении отдела я добавлю заполненный «идентификатор торгового представителя». который связывает торгового представителя с отделом. Недостаток, который я заметил здесь, заключается в том, что данные отдела будут повторяться в таблице «Отдел» для каждого сотрудника. Здесь оба измерения я предпочитаю иметь историю, так что это тип SCD 2

Пожалуйста, поделитесь своим ответом, приведенными выше вариантами, какой из них лучше, или любым другим третьим наилучшим подходом -

Answer 1

Этот ответ больше относится к бизнес-модели, чем к технологическим потребностям:
Варианты 2 имеют смысл, если продавец может принадлежать более чем одному отделу, держать отдел за таблицей фактов "продажи" итогда нет необходимости держать отдел в измерении «продавец».Вариант 1 имеет смысл, если продавец работает одновременно только с одним отделом, но он может менять отделы, сделайте это медленно изменяющимся типом измерения 2, в котором вы сохраняете историю.

Медленно изменяющееся измерение означает, что таблица мостов вам не нужна, отдел является частью таблицы «специалист по продажам», и вы можете узнать больше об этом по предоставленной ссылке.
В нечетном случае, когда продавец может работать в нескольких отделах и подчиняться ему из разных отделов, тогда вся иерархическая модель должна быть в другой таблице.В SSAS самоотражающая таблица не работает должным образом, попробуйте проверить способы устранения этих проблем.

Обратите внимание, что при проектировании хранилища данных схема «звезда» означает именно это: данные могутповторить себя в разных таблицах, чтобы упростить отчетность.Эти проблемы никогда не имеют четкого решения, и я советую вам прочитать как можно больше о дизайне хранилища данных, пока у вас не закружится голова, чтобы обдумать это.