Общее представление о дизайне звездообразной схемы

Итак, я думаю, что понял, что ставить в измерениях, что в таблице фактов и как этого добиться. Теперь у меня есть проблема, что у меня есть измерение "продукт" и измерение "productProperties". Мне пришлось разделить это, иначе мой естественный ключ в «продукте» больше не был бы уникальным. Я задал это в этом вопросе.

Итак, моя таблица размеров productProperties должна была выглядеть так: Color | Материал | Размер

1.) Чтобы добиться этого, мне пришлось создать всевозможные перестановки значений «цвет», «материал», «размер» и так далее, верно?

Это было бы намного больше 200 миллионов строк, поэтому я решил разделить это. Теперь у меня есть измерение «Цвет», которое на самом деле состоит из столбцов «цвет», «colorFront», «colorBack».

2.) Думаю, это нормально, но как насчет измерения «размер», которое состоит только из столбцов «surrogate_key» и «значение»?

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

Что, если я должен это сделать?

3.) Являются ли эти вырожденные измерения частью первичного ключа в таблице фактов?

Самый важный вопрос: в моей таблице фактов будут записи продуктов, которые не соответствуют каждому столбцу в моих измерениях или не всем измерениям вообще. Это означает, что у меня может быть запись / продукт со свойством «цвет», но не «colorFront» или «colorBack». Поскольку я создал каждую перестановку 'color', 'colorFront' и 'colorBack', при попытке заполнить мою таблицу фактов я получу несколько суррогатных ключей, если продукт имеет только свойство 'color', что приводит к дублированию в моем таблица фактов, верно?

4.) Так должен ли я отфильтровывать эти дубликаты при запросе моей таблицы фактов? Или это вообще неправильно?

Конечно, я мог бы разделить «цвет» измерения на три измерения. Но тогда я получу записи со значениями NULL в некоторых столбцах. То же самое и с записями / товарами, которые вообще не используют какие-то размеры.

5.) Как обрабатывать эти значения NULL?

Заранее благодарю за любую помощь.


person fancyPants    schedule 23.09.2010    source источник


Ответы (2)


В каждом измерении есть:

  • первичный ключ (DateKey, TimeKey, ProductKey, ...)
  • бизнес-ключ (FullDate, ProductFullName, ColorNaturalKey, ...)
  • строка со значением 'unknown' (Key = 0, BusinessKey = 'unknown', все остальные = 'n / a')
  • строка со значением 'n / a' (Key = -1, BusinessKey = 'n / a', все остальные = 'n / a')

В таблице Color столбцы Color, ColorFront и ColorBack имеют значения «н / д» и «неизвестно», поэтому их следует включать в перестановки. Таким образом, в таблице измерений всегда есть строка, на которую можно указать.

Вы можете сделать размер вырожденным измерением, переместив SizeValue в таблицу фактов и отбросив dimSize.

alt text

person Damir Sudarevic    schedule 23.09.2010
comment
Если один и тот же товарный ключ представлен более чем в одном размере, то SizeKey должен быть частью факта PK, я мог бы использовать размер XL и XXL одной и той же рубашки одновременно ... один для меня и один для моего брата. Я мог купить один и тот же ключ продукта двух разных цветов. Я почти всегда покупаю одну и ту же рубашку более чем одного цвета. Цвет тоже должен быть частью ПК. Фактически, если в таблице фактов есть FK, который не является частью PK, он описывает существующее измерение и, вероятно, должен быть там. - person Stephanie Page; 24.09.2010
comment
@Stephanie Верно, составной первичный ключ следует выбирать более тщательно. Модифицировал модель согласно вашему комментарию. - person Damir Sudarevic; 24.09.2010
comment
@Damir И если у меня нет ColorNaturalKey, следует ли мне разделить его, чтобы размеры были похожи на dimMaterial? - person fancyPants; 24.09.2010
comment
@tombom - вам нужен какой-то деловой (естественный) ключ, чтобы иметь возможность получать первичный ключ во время загрузки. Так что придумайте такой, например 'c=blue-f=blue-b=na' подойдет. - person Damir Sudarevic; 24.09.2010
comment
@ Дамир Извини, я не понимаю. Ключом моей компании будет полное название цвета. Точно так же, как вы сделали это с dimMaterial. - person fancyPants; 27.09.2010
comment
@tombom - деловой (естественный) ключ однозначно идентифицирует объект (сущность), который описывает строка измерения. Например, Color = blue; ColorFront = blue; ColorBack = blue и Color = blue; ColorFront = blue; ColorBack = na являются двумя разными цветовыми объектами и будут иметь разные естественные ключи. Вы также можете переместить передний и задний цвета в таблицу фактов в качестве ключей, чтобы иметь ColorKey, FrontColorKey и BackColorKey; затем удалите столбцы из измерения. - person Damir Sudarevic; 27.09.2010
comment
Спасибо за помощь и терпение :) - person fancyPants; 28.09.2010

1) Кто вам сказал:

Итак, моя таблица размеров productProperties должна была выглядеть так: Color | Материал | Размер

был либо неправ, либо вы неправильно поняли.

Эта идея называется «Измерение мусора». И для начала он не обязательно должен содержать декартово произведение. Его можно загружать, как и любое другое измерение. Если комбинация необходима в таблице фактов, а не в измерении, вы добавляете ее. Декартово его использование для начала - это удобство, но тогда вам лучше знать, что когда добавляется новый цвет, вы должны повторно декартово. Лучше загружать при необходимости и не беспокоиться об этом.

2) Хорошо, теперь я прочитал весь ваш вопрос и понял, что вы читаете о трехмерном моделировании, но похоже, что вы просматриваете его.

Вырожденное измерение - это что-то вроде номера заказа на закупку. Это не факт. Вы не можете СУММИРОВАТЬ. Но это тоже не Dimension, так как о PO123210413 больше нечего сказать. Это НЕ FK никуда.

person Stephanie Page    schedule 23.09.2010
comment
Весь мой процесс ETL выглядит так: я извлекаю строки, которые были созданы или изменены в моей исходной базе данных, и сохраняю их в соответствующих таблицах в моем хранилище данных. После этого я перестраиваю свои размеры или соответственно меняю или добавляю столбцы. Я сделал это, потому что думал о размерах как об описывающих элементах. Таким образом, конечный пользователь может, например, запрашивает продукт и не сбивается с толку, если результат таков, что данный продукт неt purchased yet. Thought that he may be confused if he wasnt может найти продукт (причина того, что он еще не был куплен). Разве это не хорошая практика? - person fancyPants; 24.09.2010
comment
Ну, это наоборот ... как вы можете добавить строку в таблицу фактов, если у вас нет FK для нового значения измерения? Если у вас 1 = красный, 2 = синий, то когда будет добавлена ​​первая желтая рубашка, каким будет FK в таблице фактов? - person Stephanie Page; 24.09.2010
comment
Я перестраиваю свои размеры (или, скорее, добавляю / меняю вновь созданные / измененные строки) каждый раз, когда выполняется процесс ETL. Поэтому вставить желтую рубашку в таблицу фактов не составит труда. - person fancyPants; 27.09.2010