- Refine OBIEE RPD (Repository) as per requirements
- Change The Database and Connection Pools Settings in the Repository
- Import the Cusotm Tables Required for the Project in the Repository
- Create the Joins for the Dimensions & facts using the Joins Manager.
- Create the Aliases to implement the joins as per the requirements
- Check the Physical model of the Repository
- Drag & Drop the Objects to the Logical Layer
- Rename and Remove the columns from the Logical Layer as per the Requirements.
- Remove the Hard Coded FK Key join in the Logical layer.
- Create the Complex Joins Between the Facts & Dimensions.
- Create the Dimensional hierarchy for the Logical Tables.
- Associate the hierarchy level in the Fact Sources
- Create the New Measures Required for the Project.
- Create and Realign the Objetcs in the Presentation Layer as per the Business Needs.
- Check the Local and Global Consistency Check of the Repository
- Fix the Errors, Save the Repository and Deploy the Repository
- Make the Configuration Changes in the NQS config File.
- Restart the Oracle BI server and Presenation server services to Refelct the changes made in the Repository.
- Creation of New Reports in OBIEE Answers as per the Design Document.
- Creation of Pages as per the Design Document.
- Creation of Dashboard and Association of Pages with Dashboard
- Stop the OC4J/IIS and Oracle BI Server to get the Final Web catalog.
Posted by Shiva Molabanti on September 5, 2008
http://shivabizint.wordpress.com/2008/09/05/obiee-reporting-guidelines/
OBIEE BEST PRACTICES GUIDELINES（最佳实践）
Administration与Repository相关
Repository ‐ Physical Layer
连接池
每个项目应用单独的数据库，并为它们指定有意义的名字
对于每个项目/业务单元的数据库对象和连接池，遵循合适的命名规范
使用优化的连接数量，定义每个连接池的最大连接数、共享登陆等
别让任何可能导致连接数据库失败的连接池存在，这可能会导致BI服务器崩溃
最好有一个专门的数据库连接提供给OBI，该连接可以读取全部需要的schemas并且永不失效
任何不适宜的接口调用都不该存在于连接池
确保连接池属性中“运行异步查询”选项被选中
其他
在物理层定义适当的键值
别从数据库导入外键
根据物理表的刷新周期，指定相应的缓存持久化时间
避免在物理层使用Hint
使用别名来解决环状连接
除非很有必要，否则要避免在物理层创建任何（基于SQL）的视图
不应该存在事实与事实之间的join连接
在别名中也要遵循一致的命名规范
别为退化的事实使用独立的别名
找到并消除三角关系（triangle joins）
在项目下总是定义你自己的目录（catalog），这在多人开发环境和合并库的时候通常很有用
Repository Design ‐ BMM
层次
确保每个层次（hierarchy）级别（level）都有适当的元素数量（不要求精确），并且要有层次键（level key）
只有Grand total level可以没有level key
每个层次只能有一个Grand total level
层次中最底层的粒度应该和维度表中最低粒度相同。维度层次中的最低级别，必须与其相对应的维度逻辑表的主键相对应。
一个层次中的所有列都应该来自同一个逻辑表
所有的层次都应该有其单一的根级别（root level）和单一的顶级（top level）
如果一个层次有多个分支，所有分支必须有通用的起点和终点（If a hierarchy has multiple branches, all branches must have a common beginning point and a common end point）
同一个列不能对应多个level
如果一个列属于超过一个level了，把它和它所在的最高级别相关联（If a column pertains to more than one level, associate it with the highest level it belongs to）
除了grand total level外的所有level都应该有level key
层次中不应该有不相关的键
优化维度层次，使之不会扩散到多个逻辑维度表（与5对应）
聚合
所有的聚合都应该是在事实逻辑表中，而非维度逻辑表中处理
所有不能聚合的列都应该在维度逻辑表中，而非事实逻辑表
对于事实表中的不能聚合的列，如果它们对应的源是与所有其他维度的最低聚合级别一致的时候，那么这些不能聚合的列也可以存在于事实表
把维度按照聚合层次由低到高排列
逻辑连接
如果用到外键逻辑连接（foreign key logical joins），那么逻辑事实表的主键应该由这些外键构成。
要明确事实表的外键有哪些，以及这些外键对应的维表
如果物理表中没有主键，这个事实表的逻辑主键应该由那些与它关联的外键内容组成
其他
不应该针对某个报表要求而建模，应该以模型为中心（译者注：这点我想原作者是希望不针对某几个特例而让模型变得特殊，并不是说不考虑报表需求）
在逻辑事实与逻辑维度之间的join应该用complex join来指定，而不是外键
建议在业务模型中应用星型模型
尽量把相近的信息放到同一个维度，例如，别把产品属性放到客户维度，而是该放到产品相关的维度
每个逻辑维度都应该定义层次，即使它只有Grand Total和Detail level两个层
别把映射到物理层维度表键值的逻辑列删除
明确定义逻辑源表的内容
按照命名规范来指定逻辑表和列的名字
避免对逻辑列命名成和逻辑表、主题相同的名字
对于所有源，适当配置content/level，使OBI能生成优化的SQL
避免在“where”语句中产生复杂逻辑
基于列的或者生成的计算项最好不要存在聚合表中
明确定义逻辑源表的内容，尤其是逻辑事实表
创建分离的源来做维度扩展
把事实扩展与主事实源表合并
从大的维度中分离出小的，来作为不同的逻辑表——这使得在删除大维度的时候能有所保留
如果需要比较多种日历和时间（如财务日历和常规日历），那么应该考虑将其分离以简化日期维度
事实逻辑表的源表应该定义聚合。聚合内容规则定义了哪个粒度的数据存储在该表。对于与之相关的每个维表，定义其粒度级别，确保每个相关的维度都有定义。
删除没用的物理列
在这里做逻辑列重命名，这样presentation层用到的列可以被级联修改
http://datawarehou.se/knowledge/obiee-best-practice-p1/
原文链接：http://debaatobiee.wordpress.com/category/obiee/best-practices/