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

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

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

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

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

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


data-warehouse etl star-schema database-design
person moewe    schedule 12.08.2015    source источник
comment
Кажется, здесь есть фундаментальная проблема: если у вас есть два продавца, A и B, которые связаны со счетом на сумму 10 фунтов стерлингов, то при запуске отчета о продавце и стоимости счета-фактуры стоимость счета дублируется. Это происходит независимо от того, какую из схем вы выбираете (но особенно когда [вам] нужны общие продажи всех продавцов, суммированные за текущий год, независимо от их роли), и подсказывает мне, что с моделью в целом что-то не так. Сколько разных ролей может быть у продавцов?   -  person David Aldridge    schedule 12.08.2015
comment
Спасибо за комментарий. Я думаю, что вы правы насчет базовой модели, но, к сожалению, мы не можем ее изменить. У продавцов две роли, но они ненадежны. Часто роли смешиваются, и у нас нет возможности выявить проблемные записи и исправить смешанные роли. По этой причине мы хотим относиться к ним как к равным, чего, к счастью, достаточно для нашей отчетности.   -  person moewe    schedule 13.08.2015
comment
Тогда я бы выбрал вариант 1.   -  person David Aldridge    schedule 13.08.2015

Ответы (1)


arrow_upward
1
arrow_downward

Это было бы мое мнение по этому поводу, основываясь на моем опыте.

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

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

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

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

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

С уважением и удачи.

person Community    schedule 13.08.2015