Я создаю DW точно так же, как и AdventureWorks. У меня есть одна таблица фактов под названием FactSales, а в базе данных есть таблица под названием SalesReason, которая сообщает нам причину, по которой определенный клиент покупает наш продукт. Дело в том, что существует два типа клиентов - продавцы и онлайн-клиенты, и только у онлайн-клиентов есть причина продажи, связанная с ними.
Прежде всего, могу ли я перейти к таблицам измерений, указывающим на тот же FK в факте? Как и в моем случае - Sk_OnlineCustomer и SK_Resseler оба указывают на FK_Customer. Их номера Id не пересекаются.
И второй, Должен ли я построить измерение причины, связать его с фактом и получить FK, который в большинстве случаев имеет значение NULL или с «фиктивной причиной»?
Должен ли я просто указать причину в факте продаж, не являясь ключом, точно так же, как техническое описание, которое допускает значение NULL?
Должен ли я разделить факт на две таблицы фактов, одну для реселлеров и одну для онлайн-клиентов? Но даже в этом случае у меня были бы некоторые клиенты, которые не отвечали бы на причину, поэтому fk_reason будет иметь значение null в некоторых его проявлениях в новом fact_Online_Customer.
В решении, которое я видел из учебника по приключенческим произведениям, создается новая таблица фактов с именем fact_reason. Он связывает factSales с DimReason. Это похоже на хорошее решение, но я не знаю, как оно работает, потому что я никогда не учил на своих занятиях, что могу связать факт с фактом, поэтому я не смогу оправдать свой выбор перед учителем.
Если бы вы могли это объяснить, я был бы признателен.
Спасибо!





Пожалуйста, найдите мои комментарии к вашим вопросам:
Прежде всего, могу ли я перейти к таблицам размеров, указывающим на тот же FK в факте? Как и в моем случае - Sk_OnlineCustomer и SK_Resseler оба указывают на FK_Customer. Их номера Id не пересекаются.
Да, измерением в этом случае будет Dim_Customer (например), и это может быть ролевое измерение. Вы можете предоставить представления отчетов, чтобы разделить онлайн-клиента и клиента-посредника.
И во-вторых, следует ли мне построить измерение причины, связать его с фактом и получить FK, который в большинстве случаев имеет значение NULL или с «фиктивной причиной»?
Да, было бы разумно построить измерение разума. Здесь вы можете пометить запись факта по причине
Должен ли я разделить факт на две таблицы фактов, одну для реселлеров и одну для онлайн-клиентов? Но даже в этом случае у меня были бы некоторые клиенты, которые не отвечали бы на причину, поэтому fk_reason будет иметь значение null в некоторых его проявлениях в новом fact_Online_Customer.
Я бы посоветовал вам сохранить один факт, поскольку ваша коммерческая деятельность связана с продажами, вы можете добавить к нему контекст, онлайн или через посредника, используя свои измерения. Если вы предпочитаете, у вас может быть отдельное измерение Dim_Sales, чтобы включать тип продаж и другие детали продаж, которые вы не можете включить в документ.
Подводя итог, вам, вероятно, могут пригодиться следующие факты:
Fact_Sales связан с Dim_Customer Dim_Sales Dim_Reason (Это тоже может быть в Dim_Sales) Dim_Date (всегда включайте измерение даты при создании решения DWH)
Надеюсь, это поможет...