Best Practice - Pentaho OLAP Design Guidelines

Transcription

1 Best Practice - Pentaho OLAP Design Guidelines

2 This page intentionally left blank.

3 Contents Overview... 1 Schema Maintenance Tools... 2 Use Schema Workbench to create and maintain schemas... 2 Limit number of schemas per database connection... 2 Schema Object Naming... 2 Use name and caption where available... 2 Specific Dimension Handling... 2 Identify date and time dimensions and levels with Pentaho Analyzer... 2 Use all dates between start and end date in dimension table... 3 Populate dimension tables with values that exist in the fact table... 3 Add geographic annotations to your schema... 3 Measure Definition... 3 Create measures and dimension keys... 3 Organize measures into sub-groups... 3 Dimension and Hierarchy Definitions... 4 Create multiple hierarchies in dimensions... 4 Populate approxrowcount of every hierarchy... 4 Use shared dimensions... 4 Development Process... 4 Extend Analyzer schemas incrementally... 4 Test your schema before publishing... 5 Related Information... 5

4 This page intentionally left blank.

5 Overview This document is intended to provide best practices around how to design and build your Pentaho OLAP solution for maximum speed, reuse, portability, maintainability, and knowledge transfer. Topics are arranged in a series of groups with individual best practices for that topic explained. It is not intended to demonstrate how to implement each best practice or provide templates based on the best practices defined within the document. Some of the things discussed here include schema maintenance, schema object naming, specific dimension handling, and measure, dimension, and hierarchy definitions. The intention of this document is to speak about topics generally; however, these are the specific versions covered here: Software Version Pentaho 5.4, 6.x, 7.x Pentaho 1

6 Schema Maintenance Tools Use Schema Workbench to create and maintain schemas Use Schema Workbench for the primary creation and maintenance tool of your schemas. Definition - Use the Pentaho Data Access wizard only to create the Analyzer schema. Use Schema Workbench or XML editor from that point onward. Rationale - The DA Wizard only provides about 70% of the functionality that is provide to Schema Workbench or in the XML. Limit number of schemas per database connection Limit the number of schemas per database connection to one. You can have multiple cubes in one schema as long as the cubes belong to the same connection. Definition - Define multiple cubes for each fact table and use shared dimensions that are conformed across the multiple facts. Do not use the Data Access Wizard as it only allows you to create one cube per schema. Rationale - By using multiple cubes per schema, you get better caching performance easier maintenance and security integration. Schema Object Naming Use name and caption where available Use name and caption where available, since most schema objects have a caption property. Definition Use the caption property to display to the user of the data. The designer and code refers to the name property. Use same case without spaces in the name. When doing so, you can write your MDX query without using []. Rationale If you change the name later on, the code will not work properly. Changing the caption is easier and can be localized/internationalized. Specific Dimension Handling Identify date and time dimensions and levels with Pentaho Analyzer Make sure that your date/time dimension and levels are identified to Pentaho Analyzer. Definition Your date dimension should be of type TimeDimension. Each level in all time hierarchies should have the leveltype attribute set to one of the TimeXYZ types. Add AnalyzerDateFormat Annotations to each level down to the day level as described in Enable Relative Date Filters in Mondrian. Sub-day annotations are not supported at this time. Rationale Pentaho has extra features available to time dimensions and each level type. For instance, it knows how to calculate Year to date, Month to date, etc., because of this identification. Analyzer goes further by providing a handy GUI interface for relative date filtering ONLY to those hierarchy levels that have AnalyzerDateFormat properly defined. Pentaho 2

7 Use all dates between start and end date in dimension table Populate your dimension table with every date between your data s start and end date. Definition During data load you can populate the data with only all dates between your data s start and end date. Rationale This allows you to analyze dates without data. This analysis is often very useful and difficult without date members for each day. Populate dimension tables with values that exist in the fact table For all dimensions other than time dimensions, do not populate your dimension table with values that do not exist in the fact table. Definition During data load you can populate your dimensions with only those that you have data for. Rationale Dimensions have many more possible values than data is provided. It increases overhead and memory usage for values that cannot be analyzed. Contrasting to dates, there will always be dates in time, but might not be any data for that date. Add geographic annotations to your schema Identify your geographic levels to Analyzer by adding annotations to the schema. Definition Add Data.Role and Geo.Role annotations to make sure that each level is recognized by the Geo-mapping visualization in Analzyer as described in Add Geo Map Support to a Mondrian Schema. Alternatively, if you have run the Data Access Wizard, it should identify and add those annotations for you. Rationale This allows Analyzer to know how to drill up and down on geographic dimension levels. Measure Definition Create measures and dimension keys Create all possible varieties of a measure and dimension keys in a cube. Definition Define the following measures, dimension, and primary keys: o Sum, min, max, and avg measures for all facts. o Distinct count for all dimension key fields. o Count and distinct count measures for the primary key of the fact table. o Optional: Create a spread (Max-Min) measure to provide a range of values to be used for distribution analysis. Rationale These additional measures might not be requested or used in Analyzer, but provides business users with maximum flexibility for data analysis without having to modify the schema later. Organize measures into sub-groups Use the AnalyzerBusinessGroup annotation to organize measures into sub-groups. Definition Add Business Groups in Pentaho Documentation describes this process. Rationale This helps users navigate and find measures in the Analyzer UI when you have many measures and natural grouping are needed by users. Pentaho 3

8 Dimension and Hierarchy Definitions Create multiple hierarchies in dimensions Create multiple hierarchies in dimensions where different start points and drill-downs are necessary Definition Analyzer schemas support multiple hierarchies per dimension. Avoid too many single level hierarchies in a dimension. Many single level hierarchies should be converted into Member properties. Each child level of a hierarchy should have more rows than the parent and be directly related to the parent level. Independent levels should be on their own hierarchy in the same dimension. Rationale Multiple hierarchies should be used when you will need to analyze a lower level of a hierarchy independent of the higher levels. This is most common with time/date. A day of month level allows analysis for which day is most active, etc. without regard to month or year levels. In that case, a day of month level is the top-most level in a new hierarchy. Populate approxrowcount of every hierarchy Populate the approxrowcount attribute for all levels of every hierarchy. Definition In Schema Workbench or XML, Pentaho allows you to specify the estimated number of rows. This does not need to be exactly the correct number or the right magnitude (correct number of 0 s). Rationale Analyzer uses this attribute to determine how to load and cache members. When this is not specified, Analyzer has to build queries to go after this data at runtime, impacting performance. Use shared dimensions Make frequent but appropriate usage of shared dimensions. Definition Don't use a shared dimension that is not used across more than one cube in a schema. If it is only one, then it is not shared. Make it a local dimension. If all cubes have only conformed dimensions, then you should consider just having one cube. Normally each cube has at least one dimension that is not conformed. Inferred in this practice is the usage of multiple cubes within one schema. A schema should house all cubes related to that database connection. Rationale Shared dimensions allow Analyzer to cache members and reuse them across multiple cubes in the same schema. This improves performance and reduced memory required. Development Process Extend Analyzer schemas incrementally Create and extend an Analyzer schema incrementally. Definition Create only the most basic schema first and then expand (one cube, one dimension, one hierarchy, one level, one measure). When expanding, only add one or a few measures or hierarchies before testing again. Rationale This avoids hard-to-trace errors on the server and allows only functioning schemas to be provided to users. When too many pieces are added to a schema, the true error can be hard to track down. Pentaho 4

9 Test your schema before publishing Run a test MDX query on each cube in your schema before publishing to the BA Server. Definition In Schema Workbench, go to File/New MDX Query. If you can connect to the schema, that means that Analyzer can at least parse the schema. Many errors are caught this way. Further test can be a simple MDX query SELECT Measures.members on COLUMNS from [MyCubeName]. This simple test will prove you can connect to the cube, database and get the default members for all hierarchies. Rationale This avoids hard to trace errors on the server and allows only functioning schemas to be provided to end users. Related Information These articles provide more detail than we go into here: Add Business Groups Add Geo Map Support to a Mondrian Schema Enable Relative Date Filters in Mondrian If you are using this best practices document, we would be happy if you would leave us a comment or suggestion to let us know what you think! This will help us learn about who is using our best practices, and also give us some insight as to what you find helpful about them. As always, if you have a more information or a solution that would enhance this document, we would love to hear about that, too. Pentaho 5