таблица фактов должна иметь показатели из «слабой сущности» или должны быть введены только поля родительской сущности

Я новичок в размерном моделировании и OLAP. Я пытаюсь создать размерную модель магазина.

В таблице "заказ" есть столбцы:

'order_id(auto generated), total_order_cost, date, product_Set_Id'.

Таблица «Product_set» (содержит продукты, заказанные в каждом заказе, т.е. несколько строк для каждого заказа, таблицы, логически связанные столбцом product_set_id), имеет столбцы:

'product_set_id, product_name, quantity,Cost_per_quantity'.

В модели ER таблица product_set является своего рода слабой сущностью, зависящей от таблицы «order».

Я сомневаюсь в примере таблицы фактов 1: я должен добавить только 'order_id(fk)' и 'total_order_cost(as measure)' ==>, в этом случае меры из "product_set" не будут присутствовать в таблице фактов.

или случай 2: я должен добавить 'order_id(fk)','product_set_id(fk)' and 'cost_per_quantity(measure), quantity(measure), total_order_cost(measure)' ==>, в этом случае будет несколько строк для одного и того же 'order_id' and 'total_order_cost'

Есть и другие таблицы, такие как «клиент» и т. Д., Но я сомневаюсь в вышеупомянутом.

Заранее спасибо!


data-warehouse olap ssas dimensional-modeling entity-relationship
person TheRising    schedule 30.03.2016    source источник

Ответы (1)


arrow_upward
0
arrow_downward

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

Это ответ на вопрос?

person Faiz    schedule 01.04.2016
comment
Во-первых, спасибо за ответ. Итак, по вашему мнению, я должен удалить «total_order_cost» и сохранить «order_id» в таблице фактов ?? Это нормально, что 'order_id' повторяется, поскольку в заказе может быть несколько товаров ?? - person TheRising; 02.04.2016
comment
Привет, в моем дизайне это так, я объединил таблицы заказов и строк заказа в одну таблицу FactSales. Вот почему используется ауррогатный ключ. И не оставляйте total_order_cost (это мера). Но поскольку стоимость заказа останется прежней, я бы посоветовал вам разделить ее по строкам заказа. определите свой total_order_cost как cost_per_quantity * количество - person Faiz; 02.04.2016
comment
Еще раз спасибо, исправьте меня, если я ошибаюсь, я понял ваш дизайн. Ваш подход хорош, поскольку в нем больше смысла, но он похож на альтернативное решение. Это своего рода «звездная схема». Тем не менее предположим, что мы не объединяем их в одну таблицу, т. Е. Своего рода «схему снежинки», а используем две разные таблицы. или позвольте мне переформулировать проблему следующим образом: как мы должны вводить меры и FK в случае схемы "снежинка". - person TheRising; 03.04.2016
comment
Вы всегда должны настаивать на звездообразной схеме, да, есть другие типы измерений, такие как Mini Dims (Customer_Mini_Dim, который будет хранить данные о клиентах, но будет иметь свой ключ внешней таблицы в таблице фактов) или Outrigger (Customer_Demographics, вызывающее снежинку, поскольку у него есть внешний ключ в Custmer Dim), и существует лишь несколько сценариев, в которых вы могли бы рассмотреть вопрос о снежинке, но лучше всего иметь звездную схему, чтобы иметь возможность быстро получать результаты. Вот как кимбол учит нас создавать хранилища данных. - person Faiz; 04.04.2016
comment
В случае со снежинкой это может быть сложно, но в итоге вы получите Order (PK- OrderID) и Orderline (PK- OrderlineID и OrderID - то есть составной PK). И укажите orderID в качестве ссылочного ключа в обеих таблицах. Но отношения факт к факту, я бы не стал, приключенческие произведения сделали это, так что я думаю, вам это сойдет с рук. - person Faiz; 04.04.2016
comment
Спасибо за помощь и проявленное терпение. Я понял, что мы всегда должны настаивать на «звездной схеме». Итак, наконец, мы можем пойти так, как вы сказали, то есть объединить «порядок» и «строку заказа», а затем использовать суррогатный ключ. Другой способ, который я думаю, - иметь только измерение «строка заказа» (без «порядка») и использовать «идентификатор заказа» в качестве вырожденного измерения в «FactSales». - person TheRising; 04.04.2016
comment
Строка заказа не может быть измерением по своей природе. Это тот, который содержит меры. И вы можете использовать 'orderID' как вырожденное измерение или иметь 2 таблицы фактов Order и Orderline (если вы не хотите их объединять). Я использовал работу FactSales, когда вы объединяете 2 (строка заказа и порядок, как у меня). Это яснее? - person Faiz; 04.04.2016