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

Question

У меня есть набор исходных данных с:
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 в один, поскольку у них есть несколько общих атрибутов (и несколько необычных, которые можно оставить пустыми для других ). Как я полагаю, они имеют одинаковую степень детализации (покупка продукта / план поддержки, создание запроса против плана поддержки). Это означало бы потерю некоторой конкретной c информации, чтобы сделать ее общей c, например, срок действия гарантии на продукт и плана поддержки под тем же именем срок действия

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

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

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

Answer 1

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

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

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

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

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

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

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

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