2

Есть ли имя для типа Star Schema, в котором есть один Fact table, который имеет один столбец для значения, а тип значения (меры) определяется dimension?Есть ли название для такого типа структуры данных?

Другими словами, таблицу, как это:

Dim1ID  Dim2ID  MeasureID  Value 
--------- ----------- ------------- ------------ 
543  44   1    234.3 
543  45   1    256.3 
544  44   1    245.3 
544  45   1    264.5 
543  44   2    10 
543  45   2    8 
544  44   2    9 
544  45   2    10 

С одним значением столбца, который представляет различные меры, с помощью внешнего ключа.

Есть ли название для этого рисунка?

+0

это нормально не нормируется DB – Andrey

+1

@ Andrey: Правда, но нормализация - это техника, а не религия, которой мы все должны следовать:) – codeulike

ответ

2

Entity-Attribute-Value Model возможно?

Редакция: Некоторые считают, что это анти-шаблон (в SQL), хотя в магазинах на основе столбцов это обычное поведение (BigTable, Cassandra).

+0

Спасибо, EAV, а также Open-Schema - это имена. Теперь я знаю имя, я могу прочитать о теории:) ... Эта ссылка на википедию очень хороша, также эти два вопроса SO ... http://stackoverflow.com/questions/2854312/database-with-open- schema-good-or-bad-idea http://stackoverflow.com/questions/192892/performance-of-large-eav-open-schema-systems-on-sql-server – codeulike

0

Мне кажется, что, как MeasureID будет ссылаться на таблицу со всеми возможными мерами, у вас просто есть звездный платок с тремя измерениями, где одно измерение называется «Мера».

+0

Да, я так думаю, но читаю дальше звездные схемы, кажется, обычным делом является наличие внешних ключей для измерений, но сохранение каждого типа меры в его собственном столбце или таблице. – codeulike

0

Я бы назвал это 4D-таблицей: три ключевых атрибута и один не-ключ. Я не думаю, что это требует специального имени.

Я работал с почти идентичной моделью некоторое время назад. У нас было 8000 мер и несколько миллиардов рядов. В СУБД, которую мы использовали, было совершенно непрактично (и не нужно) создавать таблицы с 1000 столбцами. «Большая» версия строки не имела бы значений для большинства мер на большинстве ее строк. Таким образом, мы либо должны были бы генерировать значения null или dummy для данных, где их не было, или нам пришлось бы создавать сотни «более узких» таблиц с почти произвольными наборами мер в них. «Вертикальная» модель имеет гораздо больший смысл и будет неплохо играть в правильной СУБД.

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

+0

Я вижу, что вы можете просто думать о «MeasureID» как о другом атрибуте, но я думаю, MeasureID' изменяет значение 'value', а не просто описывает его. Например, в приведенной выше таблице с использованием проверки или ограничений уровня DB на 'значение' было бы не очень просто, потому что правила проверки будут зависеть от' MeasureID'. Поэтому я подумал, есть ли у этого шаблона имя (и, следовательно, я могу искать теорию об этом ...). Спасибо за ваши комментарии. – codeulike

+0

@codeulike: Хорошая точка зрения о сложности ограничений (и другой логики) для разных типов значений. Если вам нужно по-разному относиться к различным мерам, это может быть хорошей причиной для того, чтобы иметь несколько столбцов/таблиц мер. – sqlvogel

Смежные вопросы