You are on page 1of 5

Repository ‐ Physical Layer Connection Pool 1.

Use individual database for every project and also specify the meaningful name for it 2.Follow proper naming convention to the database object & connection pool as per the project/business unit. 3.Use optimized number of connection pools, maximum connections for each pool ,shared logon etc. 4.Do not have any connection pools which are unable to connect to the databases as this might lead to BI server crash as it continuously ping to the connection. 5. It is advised to have a dedicated database connection for OBI which can read all the required schemas and which never expires 6.Any improper call interface should not be in the connection pool 7.Ensure to check “Execute queries asynchronously” option in the connection pool details Others 1.Define proper keys in physical layer 2.Do not import foreign keys from Database 3.Specify the intelligent cache persistence time depending on any physical table refreshing period 4.Avoid using Hints at the Physical table Level. 5.Use aliases to resolve all circular joins 6.Avoid to create any views (SQL based objects) in the physical layer unless it is necessary 7.There should be no fact table to fact table joins 8.Use consistent naming conventions across aliases 9.Do not use a separate alias for degenerate facts 10.Search and destroy triangle joins 11.Always define your catalog under projects (typically useful for Multi User Development environment and repository merging)

The aggregation content rule defines at what level of granularity the data is stored in this fact table.Level based or derived calculations should not be stored in Aggregated tables 13. associate it with the highest level it belongs to. Modelling should not be any report specific. 12.Repository Design ‐ BMM Hierarchy 1.1:N not foreign key joins 3.For e. especially for logical fact tables. 0.All aggregation should be performed from a fact logical table and not from a dimension logical table.Should not be unnecessary keys in hierarchy 12. define the level of granularity.Avoid assigning logical column same name as logical table or subject area 10.No column can be associated with more than one level. 2.Combine all like attributes into single dimensional logical table. then consider separating them into different logical dimension tables – simplifies calendar table construction 18. 14. 2.All columns that cannot be aggregated should be expressed in a dimension logical table and not in a fact logical table 3. Never put product attributes in customer dimension 5.A hierarchy should only have one grand total level 4. Create separate source for dimension extensions. Each logical table source of a fact logical table needs to have an aggregation content defined. Explicitly declare content of logical table sources 8. Avoid to apply complex logic at the “Where Clause” filter. fiscal and Gregorian).Optimizes dimensional hierarchy so that it do not span across multiple logical dimension tables Aggregation 1. 8. Explicitly declare the content of logical table sources.g. all branches must have a common beginning point and a common end point.Configure the content/levels properly for all sources to ensure that OBI generates optimised SQL 11. For each dimension that relates to this fact logical table.Arrange dimensional sources in order of aggregation from lowest level to highest level Others 1.All hierarchies should have a single root level and a single top level. 15.Joins between logical facts and logical dimensions should be complex(intelligent) i.If a hierarchy has multiple branches.Never delete logical columns that map to keys of physical dimension tables 7. 11.All the columns in a hierarchy should come from one logical table 6.If a column pertains to more than one level. Combine Fact extension into main fact source 16.No level key should be at Grand total level 3. 10. it should be model centric 2. 9.Lowest level of the hierarchy should be same as lowest grain of the Dimension Table. ensuring that every related . 7. lowest level of a dimension hierarchy must match the primary key of its corresponding dimension logical tables 5. Proper naming convention to be followed for logical tables and columns 9.Non‐aggregated columns can exist in a logical fact table if they are mapped to a source which is at the lowest level of aggregation for all other dimensions 4.g. If multiple calendars and time comparisons for both are required (e.All levels except the grand total level must have level keys. 6.Every Logical Dimension should have a hierarchy declared even if it only consists of a Grand Total and a Detail Level. Separate mini‐dimensions from large dimensions as different logical tables – keeping options open on deleting large dimensions 17.Ensure each level of hierarchy has an appropriate number of elements e e e ts and level key.It is advised to have a logical star in the business model 4.e.

Create the logical key of the fact table as a combination of those foreign keys. 3. 19.Look at the foreign keys for the fact table and find references for all of the dimension tables that join to this fact table. 2. Delete unnecessary physical column from here 20. the primary key of a logical fact table should then be comprised of the foreign keys. . If the physical table does not have a primary key. the logical key for a fact table needs to be made up of the key columns that join to the attribute tables .dimension is defined. Rename logical column here so that all referenced presentation column would changes cascaded Logical Joins 1. If foreign key logical joins are used.

13. If presentation table is in tree like structure then place a dummy column as ‘_’ to enforce proper table sorting . Mark “Facts” or “Measures” for column having Aggregation rules 16.’%’.) for naming convention in Presentation Layer and also for Dashboards Others RPD Security 1. Verify that reports do not use the aliases 7.’_’.Any project specific work is not supposed to be saved in “My Folders”. Use naming convention for initialization block and variable for ease of maintenance 7. 2. NOT in physical table/column terms 4.Use template groups (i.Use Externalized security for user‐group association to roll‐out large number of users 2. Try to avoid complex pivot tables. and edit the repository in Offline mode.) for naming convention in Dashboards/reports. .Do not use any special characters(‘$‘. It should be simple Break out complex logical models into simple.Compact and balanced and Feature Rich 2. degenerate facts) are non‐conforming with other fact tables 17.Users should not be stored inside the repository 3. Do not use any special characters(‘$‘.’’’ etc.e.Proper Naming Convention for all tables and columns by Initial cap Labellings. security filters with session variables) to minimize group proliferation 4.End‐Users should not get any errors when querying on any two random columns in a well designed presentation layer 8. Report Name . Each project or business unit will be given a dedicated shared folder on the catalog to create/save the corresponding report developments.’’’ etc. Follow proper migration strategies Report Design Shared Folders 1. 3. as the detailed dimensions (e.Do not combine tables and columns from mutually incompatible logical fact and dimension tables 6. Delete unnecessary columns of BMM in presentation layer 11. If the presentation catalog is in Tree like folder structure(main and sub folders). Limit online repository updates to minor changes.g.Dashboard. and manageable subject areas. discrete. Each Catalog should have the description which will be visible from Answers 9. Detailed presentation catalogs should include measures from one fact table only as a general rule. It’s not recommended to use Guided Navigation which effects the report performance. Page Name .’_’. All columns should be named in business‐relevant terms. This also help in merging activities 15. Report should have descriptions Interactive Dashboard 1. 6. Web Groups should be saved to relevant business area shared folders with proper and easily identifiable naming conventions 4. For major editing take backup copy of the repository. Avoid naming catalog folders same as presentation tables 12.’&’.Presentation Layer 1. 4.’&’. Page .Expose most important facts and dimensions 3.’%’. 5. Overview catalogs dimensionality is intersection of the conforming dimensions of the base facts 18. Avoid to set permissions to tables or groups unless necessary 14. Each Presentation column should have description visible from answers on mouse hover to it 10. then place a dummy measure in the main catalog folder. 3. Separate numeric and non‐numeric quantities into separate folder sets.Each Dashboard . 5. 2. Ensure that aliases for presentation layer columns and tables are not used unless necessary.

Create Visibility Roles 25. 2‐D charts are easier to read than 3‐D counterpart typically for bar charts 18. etc. Augment basic reports with Conditional Formatting 23. Do role based personalization wherever applicable 10. Pivot Table.Filter. Place Filter Views underneath Title views 26. Always try to put a single Go 15. Report Navigation & Drill‐down 24. Ticker. Avoid horizontal scrolling of dashboard page 31. Always leverage Portal Navigation. Put the Download . Use standard dashboard layout across all pages 19. Narrative. Apply filter with some default value to avoid high response time 12.5. Reduce the SELECT statements executes by the OBIEE Server 6. Applying Database hints for a table in the Physical layer of the Repository 5. Make Drill in place in dashboard for Drilled down reports 16. Remember people read from left to right & top to bottom 21. Limit the generation of lengthy physical SQL queries by Modeling dimension hierarchies (Hierarchy ( Drill Key and Level Key) 7.Metadata Repository size to be Reduced to the possible Extent by removing the unused Objects 3. setting the Query Limits and turn off logging 9. Good Caching and Purging strategy(Web server cache and Siebel Analytic Server Cache) .Name should be meaningful for business 8. For date calendar column place it in pivot rather tabular data show 14. Remember that you can embed folders or groups of folders 32. Disable or remove the unused initialization blocks and also reduce the number of init blocks in the Repository 8. Print link across all reports 17. Should have no Global Consistency Errors and Warnings 2. Avoid drop down list for filters for large set of distinct values 13.Apply the hidden column format as the system‐wide default for these preservation measures 7. Push the complex functions to be performed at the database side 10. Try to keep only 3 to 4 messages per page 20. Use single GO button for g all the prompts in the report 6. Don’t Show Detailed Filters (They look cluttered) 27. Always Drill/Navigate from summary to detail. Optimized settings for BI server and Web server configuration file parameters 4.Refresh . Chart. Use standard saved templates to import formatting and apply the layout 28.) Performance 1. Use region/section collapsible features . Always try to leverage each request view within an application or demonstration (Table. Use View selector to allow same data to be replicate across several view 30. Set the correct and recommended log level in the Production. 29. Answers access should be restrictive to group of users via privilege control by BI Administrator 11. Always keep dashboards symmetrical. top to bottom 33. Each report can have title definition 9. balanced and visually appealing 22.