星型模式是非规范化模式吗?

时间:2013-08-25 21:40:00

标签: schema olap star-schema oltp

OLAP数据库由非规范化形式的数据组成。这意味着数据冗余和这种数据冗余有助于通过较少数量的连接来检索数据,从而有助于更快地检索。

但OLAP数据库的流行设计是事实维度模型。事实表将存储基于事实的数字条目(销售数量等),而维度表将存储与事实相关的“描述性属性”,即进行销售的客户的详细信息。

我的问题是,在这个设计中,它似乎根本不是非规范化的,因为所有维度表都有对事实表的外键引用。它与OLTP设计有何不同?

2 个答案:

答案 0 :(得分:8)

非规范化在星型模式的维度表中:E。g。在产品表中,您明确地在这一个表中有许多列,例如几个级别的产品类别,而不是每个级别有一个表,并使用引用这些值的外键。

这意味着您已对事实进行了规范化,但停止对维度表进行规范化。

此外,您通常甚至不能完全正常化事实。一个典型的例子是:在一个完全标准化的表中,你只使用两列“销售单位数量”和“每单位价格”,但在OLAP数据库中,冗余地为另一列提供另一列可能是有意义的。 “销售价值”,可以通过乘以销售单位和单位价格来计算。

答案 1 :(得分:0)

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).