150 likes | 162 Views
Data Warehouse (V): Applying the star schema. Developed by: Dr Eddie Ip Modified by: Dr Arif Ansari. Outline. Review of star schema Example Class exercise The DW Design Process. Review: Dimensional Design. Fact/Measure: The thing one wants to measure
E N D
Data Warehouse (V): Applying the star schema Developed by: Dr Eddie Ip Modified by: Dr Arif Ansari
Outline • Review of star schema • Example • Class exercise • The DW Design Process
Review: Dimensional Design • Fact/Measure: The thing one wants to measure • Dimension: The way one wants it to be broken into
Example • Kitchen appliances manufacturer • Sells products to customers (retailers) through sales reps • p4-8 Adamson & Venerable (reader)
Dimension Fact
Star Schema • Fact table (at the center) plus its related dimension tables (on the sides) • Example (p. 6-7 A & V)
Design principles • Facts : fully normalized (no redundancy) • PK = concatenated key=concatenation of dimension keys • Dimensions : Denormalized (all relevant attributes in one table) • Different processes, different stars • Different grains, different fact tables
Grain • Level of detail at which measures are recorded • Also provide meaning to a number stored in the fact table
Grain • All rows in one fact table should be at the same grain • E.g., sales from salesperson W for item X on day Y under order Z
Class Exercise • Star schema of a computer Hotel Example
DW: Data Modeling • Process of translating business concepts into actual physical data structures • Dimensional Business Model (star schema) > Physical Model • Some organization may keep a traditional logical model (ER diagram) • Simplicity of star schema may be sufficient
Design: DW vs OLTP • DW designed to answer business questions • DW: to provide answers to business users • Dimensional design -- user’s view of the DB • Capacity should be built in the DW at the design stage: what facts, what dimension • OLTP: to ensure operations run well • OLTP Design -- IT professional’s view of the DB
Design: DW vs OLTP • OLTP • High transaction rate • Constantly changing (volatile) • No redundancy (normalized) • Predictable SQL queries • Recoverable (e.g., mirrored disk)
Design : DW vs OLTP • DW • Data structure understandable (not necessarily normalized) • Mostly static (non-volatile) • Unpredictable and complex SQL queries (for analytical purposes) • Recoverable: regular backups of static DB
Summary • Review of star schema • Class exercise ( star schema of a computer) • Design Issues: DW Vs OLTP