An OLAP database consists of data in denormalized form. This means data redundancy and this data redundancy helps retrieve data through less number of joins, hence facilitating faster retrieval.
But a popular design for OLAP database is fact-dimension model. Fact table will store numerical fact-based entries (# of Sales, etc.) while dimension tables will store "descriptive attributes" related to the fact, i.e. details of the customer to which the sale was made.
My question is, in this design, it does not seem denormalized at all, as all dimension tables will have foreign key references to the fact table. How is it different from an OLTP design?
A star schema is used to denormalize business data into dimensions (like time and product) and facts (like transactions in amounts and quantities). A star schema has a single fact table in the center, containing business "facts" (like transaction amounts and quantities).
The snowflake schema is a fully normalized data structure. Dimensional hierarchies (such as city > country > region) are stored in separate dimensional tables. On the other hand, star schema dimensions are denormalized. Denormalization refers to the repeating of the same values within a table.
The Star Schema dimensions are denormalized in that it has the same values repeated multiple times in the same table. On the other hand, Snowflake Schema has a fully normalized data structure. The dimensional hierarchies are stored in separate dimensional tables.
A star schema consists of one fact table, and one or more dimension tables. The fact table contains information about changes. In the most basic kind of fact table, each row represents a transaction.
The denormalization is in the dimension tables in a star schema: E. g. in a product table, you explicitly have many columns like several levels of product category in this one table, instead of having one table for each level, and using foreign keys referencing those values.
This means you have normalization with regard to facts, but stop normalizing on the dimension tables.
Furthermore, you often do not even completely normalize the facts. A typical example would be this: in a completely normalized table, you would use only two columns 'number of units sold' and 'price per unit', but in an OLAP database, it may make sense to redundantly have another column for the 'sales value' which could easily be calculated by multiplying units sold and the price per unit.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With