Общее понимание дизайна схемы звезды - PullRequest
Новая
       29

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

1 голос
/ 23 сентября 2010

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

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

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

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

2.) Это нормально, я думаю, но как насчет измерения 'size', которое состоит только из столбцов 'surrogate_key' и 'value'?

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

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

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

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

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

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

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

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

Ответы [ 2 ]

3 голосов
/ 24 сентября 2010

1) Кто бы ни сказал вам:

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

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

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

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

Вырожденное измерение - это что-то вроде номера заказа на покупку. Это не факт. Вы не можете СУММАТЬ это. Но это также не измерение, так как о PO123210413 ничего не нужно говорить. Это не ФК никуда.

3 голосов
/ 23 сентября 2010

Каждое измерение имеет:

  • первичный ключ (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 имеют значения 'n / a' и 'unknown', поэтому они должны быть включены в перестановки.Таким образом, в таблице измерений всегда есть строка, на которую можно указать.

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

alt text

...