Как справиться с одинаково растущими таблицами фактов / измерений при проектировании хранилища данных?

У меня есть набор исходных данных с:
1. customer
2. customer_product_purchase
3. customer_support_plan_purchase
4. customer_support_request

Все они связаны такими отношениями, что запрос поддержки направляется против плана и покупки продукта. И что клиент покупает план поддержки продукта (который покупает и клиент).

Чтобы спроектировать для этого схему хранилища данных, я думал о создании единой таблицы фактов, я подумал о следующих подходах:

A. Наличие объединенной таблицы фактов с customer_product_purchase, customer_support_plan_purchase и customer_support_request в одну, поскольку у них есть несколько общих атрибутов (и несколько необычных, которые могут оставьте пустым для других). Насколько я понимаю, степень детализации у них одинаковая (покупка продукта / план поддержки, запрос против плана поддержки). Это будет означать потерю некоторой конкретной информации, которая сделает ее общей, например, срок действия гарантии на продукт и плана поддержки под тем же именем срок действия.

Б. Создание таблицы фактов из customer_product_purchase и customer_support_plan_purchase, которые по своей сути являются покупками и могут храниться вместе с некоторыми общими и некоторыми необычными атрибутами. customer_support_request можно рассматривать отдельно.

C. Создание таблицы фактов вокруг customer_support_request, поскольку она связана с обеими другими таблицами, которые могут быть измерениями. Однако это будет означать, что размеры также будут расти с той же скоростью, что и факт (который я прочитал, является индикатором плохого дизайна).

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


data-warehouse dimensional-modeling star-schema database-design
person Yankee    schedule 19.06.2020    source источник
comment
Я ожидаю, что вы можете подать ноль или несколько запросов на поддержку по одному плану поддержки, поэтому я чувствую, что support_request это собственный факт. Есть ли только один или один план поддержки для каждой покупки? Может ли быть последующий план поддержки после истечения срока действия первого? Если так, то это тоже должны быть отдельные факты. Если у вас очень мало идентифицированных постоянных клиентов, то да, ваш клиентский тусклый рост будет расти с той же скоростью, что и факт, но это неизбежно.   -  person Nick.McDermaid    schedule 19.06.2020
comment
Таблицы фактов в звездообразных схемах должны моделировать бизнес-процессы. Я предлагаю не слишком стараться объединить факты, если это не имеет четкого смысла. Факты с разной степенью детализации - это красный флаг, который нельзя комбинировать.   -  person Nick.McDermaid    schedule 19.06.2020
comment
@ Nick.McDermaid Да, вы правы, планы поддержки можно покупать впоследствии и несколько раз в обмен на продукт. Кроме того, из вашего второго комментария я хочу знать, считаются ли product sale и support plan sale одинаковыми или нет? Это по-прежнему отдельные транзакции (однако в каждом плане поддержки упоминается покупка продукта). Поэтому я подумал об объединении их в один, с несколькими разреженными столбцами (которые не пересекаются между двумя таблицами), с столбцами типа, в которых в качестве типа покупки указывается «план поддержки» или «продукт». Думаете, это хорошая практика?   -  person Yankee    schedule 19.06.2020
comment
Они не на одном уровне, потому что продажа продукта происходит только один раз. Продажа плана поддержки происходит 0 или много раз для данной продажи продукта. Если вы поместите их в один и тот же факт, и у вас есть две продажи продукта для одного и того же клиента, одна с нулевыми планами поддержки и одна с тремя, вы получите пять (2 + 3) записей в вашем факте, и будет трудно связать поддержите планы продажей, потому что они находятся в разных строках. Да, вы можете пометить их одним и тем же номером счета, но это просто не кажется правильным (здесь работает процесс принятия ключевых дизайнерских решений!)   -  person Nick.McDermaid    schedule 19.06.2020
comment
@ Nick.McDermaid Отлично. Большое спасибо. Если бы вы могли скопировать свои комментарии как один ответ, я бы отметил его как принятый   -  person Yankee    schedule 19.06.2020

Ответы (1)


arrow_upward
1
arrow_downward

Некоторые моменты из моих комментариев

  • Таблицы фактов в звездообразных схемах должны моделировать бизнес-процессы.

  • Я предлагаю не слишком сильно пытаться объединить факты, если это не имеет четкого смысла. Факты с разной степенью детализации - сильный индикатор, который нельзя объединять.

Вот некоторые наблюдения об уровнях детализации фактов;

  • У вас может быть 0 или несколько планов поддержки на одну покупку. Это другой уровень детализации и, вероятно, другой факт.

  • Вы можете подать ноль или несколько запросов на поддержку по одному плану поддержки. Это другой уровень детализации и, вероятно, другой факт.

  • Если вы поместите план поддержки и продажу в один и тот же факт, и у вас есть две продажи продукта для одного и того же клиента, одна с нулевыми планами поддержки и одна с тремя, вы получите пять (2 + 3) записей в вашем факте, и это сложно чтобы связать планы поддержки с продажей, потому что они находятся в разных строках. Например, если вы хотите, чтобы соотношение стоимости плана поддержки к сумме покупки для данной группы продуктов, хотя и не невозможно, просто не «пахнет» правильным, если все это разбросано по одному и тому же факту.

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

Имейте в виду, что никогда не бывает "лучшего" решения, поэтому не зацикливайтесь на аналитическом параличе. Стоит быстро смоделировать что-то вроде Power BI и задать ему несколько бизнес-вопросов. Помните, что ваша звездная схема упрощает ответы на деловые вопросы.

person Nick.McDermaid    schedule 20.06.2020