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