Обработка Много ко многим, 1 ко многим, связь между измерениями

Question

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

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

Опция 1

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

Вариант 2

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

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

Answer 1

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

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

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