Проблемы с колонкой в ​​таблице фактов

Question

Я строю DW точно так же, как тот из AdventureWorks.У меня есть одна таблица фактов, называемая FactSales, и есть таблица в базе данных, называемая SalesReason, которая сообщает нам причину, по которой определенный покупатель покупает наш продукт.Дело в том, что есть два типа клиентов - реселлеры и онлайн-клиенты - и только онлайн-клиенты имеют причину продаж, связанную с ними.

Прежде всего , могу ли я обратиться кТаблицы размеров, указывающие на один и тот же ФК в Факте?Как и в моем случае - Sk_OnlineCustomer и SK_Resseler оба указывают на FK_Customer.Их идентификационные номера не перекрываются -

И второе , если я построю измерение разума, свяжу его с фактом и получу FK, который в большинстве случаев равен нулю или с "фиктивная причина "?

Должен ли я просто указать причину в продажах фактов, не являясь ключом, как в техническом описании, которое можно обнулять?

Должен ли я разделить факт на две таблицы фактовс одним для реселлеров и одним для онлайн-клиентов?Но даже в этом случае у меня были бы некоторые клиенты, которые не отвечают на причину, поэтому fk_reason был бы нулевым в некоторых его появлениях в новом fact_Online_Customer.

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

Если бы вы могли это объяснить, я был бы признателен.

Спасибо!

Answer 1

Пожалуйста, найдите мои комментарии по вашим вопросам:

Прежде всего, могу ли я перейти к таблицам измерений, указывающим на тот же FK в факте?Как и в моем случае - Sk_OnlineCustomer и SK_Resseler оба указывают на FK_Customer.Их номера идентификаторов не перекрываются -

Да, размерность в этом случае будет Dim_Customer (например,), и это может быть ролевое измерение.Вы можете открыть представления отчетов для разделения клиента Online и клиента Reseller

И, во-вторых, если я построю измерение причины, свяжите его с фактом и получите FK, который в большинстве случаев равен нулю или«фиктивная причина»?

Да, имеет смысл построить измерение причины.В этом вы можете пометить запись факта по причине

Должен ли я разделить факт в двух таблицах фактов, одна для реселлеров и одна для онлайн-клиентов?Но даже в этом случае у меня были бы некоторые клиенты, которые не отвечают на причину, поэтому fk_reason был бы нулевым в некоторых его появлениях в новом fact_Online_Customer.

Я бы посоветовал вам сохранитьОдним из фактов, поскольку ваша деятельность связана с продажами, вы можете добавить контекст, онлайн или через посредника, используя ваши измерения.Если вы предпочитаете, у вас может быть отдельное измерение Dim_Sales, включающее тип продаж и другие детали продаж, которые вы не можете включить в документ

Подводя итог, вы, вероятно, были бы хорошо осведомлены о следующих фактах:

Fact_Sales связано с Dim_Customer Dim_Sales Dim_Reason (это также может быть указано в Dim_Sales) Dim_Date (всегда включает измерение даты при создании решения DWH)

Hopeэто помогает ...