虽然是烂熟于网络的帖子,还是转了一份
物理层
1,在物理层总是使用Foreign join,不要用complex join
2,当数据模型是星型时,为物理表建别名(以Dim_,Fact_或者Fact_Agg作为前缀)
3,在可能的情况下,配置你的连接池使用本地驱动来连接物理数据库。例如,使用OCI而不是ODBC来连接Oracle数据库。
业务模型层
4,所有的逻辑表都应该以Dim_,Fact_或者Fact_Compund_开头。
5,所有的物理层的列名称都不应该出现在逻辑层。逻辑的命名必须是“面向业务”的。例如使用$ Revenue而不是DOLLARS
6,物理主键和代理键不应该出现在业务模型层。
7,维度逻辑表必须要指定逻辑键。这个逻辑健应该是面向业务的,比如应该是“Employee Login”而不是“EMPLOYEE_PK”
8,维度逻辑表必须仅仅包含维度属性,他们永远不应该包含任何度量列(有聚合规则)。
9,事实逻辑表不应该指定逻辑键。
10,在事实逻辑表中,每一列都是度量列,同时要指定聚合规则。
11,当定义两个逻辑表的逻辑连接时,仅仅使用“Complex join”(同时应该使用默认设置,除非需要处理跨数据库的join,需要指定DrivingTable)
12,业务模型应该仅包含逻辑星型,不应该是雪花型。
13,每一个维度逻辑表都应该有对应的维度层次。
14,每一个维度层级都设置适当的元素个数。一般要指定子层级的要比父层级的元素个数多。
15,每一个维度和事实逻辑表都应设置合适的"content level"。唯一不需要设置特定维度的“content level”的情况是在没有逻辑关系存在时。
16,不要将所有度量合并到单独的一个事实逻辑表。例如,你应该将“Forecast Sales”和“Actual Sales”度量放到两个逻辑表中---“Fact_Sales”和“Fact_Forecast”
展现层
17,当你有多个主题区域时,在每个主题区域以相同的顺序列出这些公用的维度。
18,展示层的表的名字不要以Dim或Fact开头了。如果主题区域中的表是直接从逻辑层拖过来的话,要移除该前缀。
19,时间维度表列在每一个主题区域的第一个位置。包含事实的展现层表应该列在底部,同时展现表应该被称作"measures"
20,绝不应该出现用户从主题区域中选取的对象没有逻辑关联。如果有任何从同一主题区域中选择的对象无法共存,那么一定是你的主题区域设计不正确。
转自:http://jianchen.iteye.com/blog/766299