Tutorial/Schema cheatsheet
Revision as of 08:24, 28 February 2014 by old>Admin (→Related solution ONE step away)
Schema structure overview
- Table (one):
- Structure: The centre table containing the measures (FACT table)
- OLAP cube: Not displayed
- Dimensions (many)
- Structure: Related tables or groupable values (FACT table relations)
- OLAP cube: Columns/row "headers" in the cube
- Measures (many)
- Structure: Values found in the centre table (FACT table values)
- OLAP cube: Numbers to be displayed in the table cells
Standard lookup value
The cube schema below only needs adjustment for the system name of the lookup field.
Structure
Solution as displayed | "Sample solution" : "Category" = xxx |
Solution system names | sample : CATEGORY = xxx |
Database table names | data_sample : CATEGORY = xxx |
Data model
- data_sample
- CATEGORY: Field containing the lookup value
Cube schema
...... <Dimension name="Example" foreignKey="CATEGORY"> <Hierarchy hasAll="true" primaryKey="LookupID">
Standard record Status
The cube schema below can be copied directly without modification: The status properties and tablenames are allways the same.
Structure
Solution as displayed | "Sample solution" : "Status" = xxx |
Solution system names | sample : "StatusID" = xxx |
Database table names | data_sample "StatusID" = xxx |
Data model
- data_sample
- StatusID: Field containing status reference (allways the same)
Cube schema
...... <Dimension name="Example" foreignKey="StatusID"> <Hierarchy hasAll="true" primaryKey="StatusID">
Related solution ONE step away
Structure
Solutions as displayed | "Some child" : "Parent" -> "Father or mother" |
Solution system names | child : PARENT -> parent |
Database table names | data_child : PARENT -> data_parent |
Data model
- data_child
- PARENT: Key to the "parent" solution
- data_parent
- GRANDPARENT: Key to the "grandparent" solution
- PARENTNAME: Descriptive field
Cube schema
...... <Dimension name="Example" foreignKey="PARENT"> <Hierarchy hasAll="true" primaryKey="DataID" primaryKeyTable="data_parent">
Related solution TWO steps away
Note that the schemas for multi join tables are written from "inside out", that might seem counterintuitive i relation to what you want to display in the cube later.
Structure
Solutions as displayed | "Some child" -> "Father or mother" -> "Grandma and Grandpa's" |
Solution system names | child -> parent -> grandparent |
Database table names | data_child -> data_parent -> data_grandparent |
Data model
- data_child
- PARENT: Key field pointing to the "parent" solution
- data_parent
- GRANDPARENT: Key field pointing to the "grandparent" solution
- PARENTNAME: Descriptive field
- data_grandparent
- GRANDPARENTNAME: Descriptive field
Cube schema
...... <Dimension name="Example" foreignKey="PARENT"> <Hierarchy hasAll="true" primaryKey="DataID" primaryKeyTable="data_parent"> <Join leftKey="GRANDPARENT" rightKey="DataID">
Defining dimensions for inline values
Simple text/number values
Date/period values
Enumeration values
Defining measures
Normal values
Measures are allways numeric values, that can be agggated to higher levels (the levels in the dimensions)
Type | Aggregator | Examples |
---|---|---|
Sums | SUM | Time spent, costs |
Average | AVG | Process time |
Cube schema