20 GOLDEN RULES FOR REPOSITORY DESIGN This document provides a check-list of thi ngs to check when conducting a BI Repository

(RPD)review. Helping Your Business Intelligence Journey Peak Indicators Limited www.peakindicators.com enquiries@p eakindicators.com Peak Indicators Limited Physical Layer1. Always use Foreign Key joins, not Comple x Joins on the Physical Layer 2. When modelling a star-schema data-model, create aliases for all your physical tables(prefixed with either Dim_, Fact_ or Fact_Agg_ . When possible, configure your connection pools to use a native driver to connect to yourphysical databases. For example, use OCI for connecting to an Oracle da tabase rather thanODBC Business Model Layer4. All Logical Tables should be pref ixed with either Dim , Fact or Fact Compound 5. No physical column names sh e seen on the Business Model layer. All namingconventions should be business ori ented. For example use $ Revenue rather thanDOLLARS 6. Physical Primary Keys or Sur rogate Keys should not be present on the Business Model layer(unless, for exampl e, you have a Primary Key such as Order Id which will be displayed onreports) 7 . Dimension Logical Tables must always have a Logical Key assigned. The Logical Key shouldbe something business oriented such as Employee Login rather than EMPLOYEE _PK 8. Dimension Logical Tables must only contain dimension attributes, they sho uld never containany measure columns (which have an Aggregate Rule) 9. Fact Log ical Tables should not have a Logical Key assigned 10. Every Logical Column wit hin a Fact Logical Table must be a measure column, and thereforehave an Aggregat ion Rule assigned 11. When defining Logical Joins between Logical Tables, only use Complex Joins (and use thedefault settings you only ever specify a Driving Tabl e when dealing with cross-databasejoins) 12. The Buiness Model should only consi st of logical star-schemas, there should not be anysnow-flaking 13. Every Dimen sion Logical Table should have a corresponding Dimension Hierarchy (withTotal as a Grand Total level, and Detail at the lowest level) 14. Each level of a Dimension Hierarchy should have its Number of Elements appropriately set(there is a utility that can do this automatically) 15. Every Logical Table Source within every di mension and fact Logical Table should have itsContent Levels appropriately set. The only time the Content Level is not set for aparticular dimension is when there is no logical relationship existing Peak Indicators Limited 16. Do not merge all your measures into a single Fact Logical Table. For example, you shouldsplit Forecast Sales and Actual Sales measu res into two Logical Tables e.g. Fact Salesand Fact Forecast Presentation Layer17. When you have multiple Subject Areas, list the common dimensions in the same ord eracross all the Subject Areas 18. Presentation Table names within each Subject Area must not begin with Dim or Fact or Fact Compound . So remove these prefi they are present after creating theSubject Area by dragging Logical Tables direc tly from the Business Model 19. The Time presentation table should be listed as t he first Presentation Table in each subjectarea. The Presentation Table contai ning your facts should be listed right at the bottom, andthe Presentation Table should be called Measures 20. There should be absolutely no possibility whatsoeve r of a user selecting objects from aSubject Area that have no logical relationsh ip. So, if there are any objects within the sameSubject Area that cannot co-exi st in the same report, then your Subject Area design isincorrect!