OBIEE的RPD建模的20条黄金法则

物理层
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,绝不应该出现用户从主题区域中选取的对象没有逻辑关联。如果有任何从同一主题区域中选择的对象无法共存，那么一定是你的主题区域设计不正确。