Создание хранилища данных

Я создаю хранилище данных с использованием звездообразной схемы. Я успешно построил все таблицы измерений, но я как бы застрял в таблице фактов. Мне нужно сделать таблицу продаж как таблицу фактов. У него есть SalesKey, OrderKey, ProductKey и т. Д. Каждый заказ является продажей, поэтому каждый заказ будет иметь уникальный SalesKey, однако каждая продажа будет иметь более одного продукта.

Что было бы лучше всего построить этот стол?

Должен ли я создать что-то подобное

SalesKey OrderKey ProductKey
-------- -------- ----------
s1         o1        p1
s1         o1        p2
s2         o2        p1

database data-warehouse dimensional-modeling star-schema
person Buckeye    schedule 22.11.2011    source источник

Ответы (2)


arrow_upward
2
arrow_downward

В общем, когда вы разрабатываете звездную схему, предпочтительно, чтобы каждое измерение было однозначным для каждой записи факта (то есть имеет отношение 1: M между фактом и измерением).

Уловка состоит в том, чтобы включить измерение СТРОКА ЗАКАЗА, чтобы 1 заказ (= 1 продажа) мог содержать много строк заказа. Тогда каждая строка заказа содержит 1 продукт.

Таким образом, в основном вы будете использовать схему «снежинка», в которой таблица фактов связана с измерением ORDER-LINE в соотношении 1: M. Затем размер ORDER-LINE связывается с размером PRODUCT в соотношении M: 1.

Таким образом, исходная проблема, связанная с соотношением M: M между Salesfact и измерением PRODUCT, была решена с помощью измерения ORDER-LINE в качестве промежуточной таблицы.

person MOLAP    schedule 23.11.2011

arrow_upward
2
arrow_downward

Я бы добавил, что элементы / строки заказа могут быть сложными. Есть несколько способов справиться с этим.

Добавьте столбец "строка заказа" или "идентификатор управления транзакцией" в таблицу фактов.

Это позволит вам иметь SalesKey, OrderKey, ProductKey все на вашем факте с вырожденным ключом измерения «OrderLineItem», который часто является контрольным номером транзакции или номером строки заказа из исходной системы.

Одна проблема, с которой вы можете столкнуться при использовании этого метода, - это когда у вас есть меры на уровне заказа, которых нет в строке заказа (налог, идентификатор кассира и т. Д.). Предпочтительный подход Кимбалла - распределить эти меры до линии заказа, если это вообще возможно.

Вот хорошая статья Кимбалла о вырожденных измерениях: http://www.kimballgroup.com/html/designtipsPDF/DesignTips2003/KimballDT46AnotherLook.pdf

person N West    schedule 28.11.2011