1. The classic Star Schema
1) dimension tables
Dimension attribute/described attributes (non-dimension attributes)
Answer to "What/whe/WHO /..."
Described attributes correspond to master Data .
2) fact table
Answer to "How much/how many", focus on "amount/quantity ..."
Link to dimension table by a unique key
From OLTP perspective, fact table <---> transaction data
3) star schema can answer these questions:
Who have sold?
What have we sold?
How much have we sold?
When did we recommend it?
2. the sap star schema
1) Problems of the classic Star Schema:
-- The drill down analysis cannot be flexibly created.
-- It is difficult to support multiple languages.
-- Create a character field-based index on a large table (fact table), resulting in poor data access performance
-- If attributes of dimensions changes over time, it is difficult to maintain comparative analysis of old and new values.
-- The master data is replicated multiple times, requiring more infocube
-- Hierarchy relationship must be modeled as attributes of dimension.
2) sap bw star schema
-- Key Figures --> facts of fact table
-- Characteristics --> dimension attribute
-- Dimension table (optional)/Sid tables/(optional) master data tables --> dimension (dimension table)
However, characteristics does not exist in the dimension table, but uses an alternative ID (SID) to correspond to characteristics.
Stored in dimension table
-- Additional information about characteristics is stored in the master data table,
Attributes
Texts
External hierarchy