Звездная схема и таблицы мостов для отношений от многих до 1/2

Question

В настоящее время я участвую в разработке нового хранилища данных. Я довольно новичок в этой теме и имею общий вопрос о связях Star Schema и Many-to-Many, в частности о взаимоотношениях Many-to-1/2.

Я хотел бы проиллюстрировать свою проблему кратким примером, например. данные о продажах. У меня есть таблица фактов, которая находится на уровне счета и содержит такие меры, как общий объем продаж в долларах США, НДС ... Для каждой из этих записей у меня есть как минимум один продавец и максимум у двух продавцов. Оба продавца имеют одинаковые атрибуты, поэтому требуется только одно простое измерение для продавцов. Как бы вы это сформулировали?

Я могу представить себе следующие три различных подхода:

1. Соединение через таблицу Bridge - Я предпочитаю, чтобы один, но я не уверен, что это из-за дополнительных усилий стола мост вызывает через дополнительный присоединиться , особенно для больших размеров и особенно в таком случае, когда запись в таблице фактов связана только с одной или двумя записями в таблице измерений.
2. Представляем два внешних ключа продавца в таблицу фактов - я бы использовал этот подход только в том случае, если в целом существует значительная разница между обоими продавцами. Например. первым продавцом всегда является тот, кто отвечает за линейку продуктов (продавец товарной линии), а второй - всегда является ключевым менеджером учетной записи клиента. С другой стороны, этот подход затрудняет запрос к хранилищу данных, например, когда мне нужны общие продажи всех продавцов, суммированных за текущий год, независимо от их роли.
3. Одна запись в таблице фактов на продавца - я создаю дубликат для записей, которые имеют двух продавцов. Благодаря этому подходу я могу избежать дополнительного соединения по сравнению с таблицей мостов, но моя таблица фактов будет больше. Кроме того, во время создания запроса или отчета я должен рассмотреть и устранить дубликаты, если это необходимо. Таким образом, этот подход также затрудняет запрос данных.

У вас есть какие-либо соображения относительно этого? Было бы здорово, если бы вы могли поделиться некоторыми знаниями. Большое спасибо.

Answer 1

Это был бы мой подход к этому, основанный на моем опыте.

1) Я бы поставил двух продавцов в одну строку, это упростит управление совокупными показателями, например.

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

3) Сделайте отдельные размеры для продавца1 и продавца2. Просто сделайте одну таблицу продавцов и настройте VIEW для этой таблицы, чтобы в итоге вы получили 2 разных измерения, но только одну физическую таблицу.

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

DW эволюционирует, ваши знания о вашем домене тоже развиваются, имейте это в виду. Возможно, этот дизайн нужно будет обновить когда-нибудь, но вы никогда не знаете. Единственное, что вам нужно сделать, это принять изменения и быть готовыми к этому.

С наилучшими пожеланиями и удачи.