Является ли схема "звезда" денормализованной схемой?

Question

База данных OLAP состоит из данных в денормализованной форме. Это означает избыточность данных, и эта избыточность данных помогает извлекать данные с помощью меньшего числа соединений, что способствует более быстрому извлечению.

Но популярным дизайном для базы данных OLAP является модель измерения фактов. В таблице фактов будут храниться числовые записи фактов (количество продаж и т. Д.), А в таблицах измерений будут храниться "описательные атрибуты", связанные с фактом, то есть сведения о клиенте, которому была сделана продажа.

Мой вопрос заключается в том, что в этом дизайне он вообще не выглядит денормализованным, поскольку все таблицы измерений будут иметь ссылки на внешние ключи к таблице фактов. Чем он отличается от дизайна OLTP?

Answer 1

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

Это означает, что у вас есть нормализация по фактам, но вы прекратили нормализацию в таблицах измерений.

Кроме того, вы часто даже не полностью нормализуете факты. Типичным примером может быть следующий: в полностью нормализованной таблице вы будете использовать только два столбца "количество проданных единиц" и "цена за единицу", но в базе данных OLAP может иметь смысл избыточно иметь другой столбец для " продажная стоимость ", которая может быть легко рассчитана путем умножения проданных единиц и цены за единицу.

Answer 2

You can get the difference if you study first "highly normalized schemas".
https://www2.microstrategy.com/producthelp/10.6/ProjectDesignGuide/WebHelp/Lang_1033/Content/ProjectDesign/Highly_normalized_schema__Minimal_storage_space.htm

Will give you an example: Consider a "city" inside a "country" for a "person",
all what you need to store for a person is only his "city" because anyway that city resides in a "country". 
so you don't have also to store the "country" in the "person" table. 
This approach will have advantage of "minimal" storage. 
But as disadvantage it will be annoying to retrieve "country" for a "person"
 since you will have to do many joins to achieve that.

So regarding your question, in your design, if we stored both "city_id" and "country_code" in "person" table, 
this will cause little redundancy but as advantage it will be more easier to get "person" "country" by directly joining the two tables "Countries" and "person" together. 

Normalization main purpose is to remove redundancy. And to achieve data consistency. 
For example, in your case OLAP , developer can make mistake by inserting correct "city_id" and wrong "country_id" 
for example he can insert "Paris" as city and by mistake he can insert "Germany" as the country which is wrong.
If the schema is fully normalized, this cannot never happens since it will store only "Paris" "city id" in "party" table and will not store "country" id.

  So yes, OLAP is de-normalized since it allows data redundancy and developers (application) mistakes (if any).