Dimensional Data Model
There are three types of facts
1. Additive 2. Non-additive 3. Semi- additive
Here are the steps to create Dimension Model
1. Identify Business Process 2. Identify Grain (level of detail) 3. Identify Dimensions 4. Identify Facts 5. Build Star
There are two popular schemas
1. Star Schema 2. Snowflake Schema
fact table
A fact table is a primary table in a dimensional model. A Fact Table contains 1. Measurements/facts 2. Foreign key to dimension table
Step 3) Identify the dimensions
Dimensions are nouns like date, store, inventory, etc. These dimensions are where all the data should be stored. For example, the date dimension may contain data like a year, month and weekday.
Step 1) Identify the business process
Identifying the actual business process a data rehouse should cover. This could be Marketing, Sales, HR, etc. as per the data analysis needs of the organization. The selection of the Business process also depends on the quality of data available for that process. It is the most important step of the Data Modelling process, and a failure here would have cascading and irreparable defects. To describe the business process, you can use plain text or use basic Business Process Modelling Notation (BPMN) or Unified Modelling Language (UML).
Step 5) Build Schema
In this step, you implement the Dimension Model. A schema is nothing but the database structure (arrangement of tables).
Benefits of dimensional modeling
Standardization of dimensions allows easy reporting across areas of the business. • Dimension tables store the history of the dimensional information. • It allows to introduced entirely new dimension without major disruptions to the fact table. • Dimensional also to store data in such a fashion that it is easier to retrieve the information from the data once the data is stored in the database. • Compared to the normalized model dimensional table are easier to understand. • Information is grouped into clear and simple business categories. • The dimensional model is very understandable by the business. This model is based on business terms, so that the business knows what each fact, dimension, or attribute means.
Example of Facts:
The CEO at an MNC wants to find the sales for specific products in different locations on a daily basis. The fact here is Sum of Sales by product by location by time.
Example of Dimensions:
The CEO at an MNC wants to find the sales for specific products in different locations on a daily basis. Dimensions: Product, Location and Time Attributes: For Product: Product key (Foreign Key), Name, Type, Specifications Hierarchies: For Location: Country, State, City, Street Address, Name
Example of Grain:
The CEO at an MNC wants to find the sales for specific products in different locations on a daily basis. So, the grain is "product sale information by location by the day."
Step 2) Identify the grain
The Grain describes the level of detail for the business problem/solution. It is the process of identifying the lowest level of information for any table in your data warehouse. If a table contains sales data for every day, then it should be daily granularity. If a table contains total sales data for each month, then it has monthly granularity. During this stage, you answer questions like 1. Do we need to store all the available products or just a few types of products? This decision is based on the business processes selected for Datawarehouse 2. Do we store the product sale information on a monthly, weekly, daily or hourly basis? This decision depends on the nature of reports requested by executives 3. How do the above two choices affect the database size?
2. Snowflake Schema
The snowflake schema is an extension of the star schema. In a snowflake schema, each dimension are normalized and connected to more dimension tables.
1. Star Schema
The star schema architecture is easy to design. It is called a star schema because diagram resembles a star, with points radiating from a center. The center of the star consists of the fact table, and the points of the star is dimension tables. The fact tables in a star schema which is third normal form whereas dimensional tables are de-normalized.
Step 4) Identify the Fact
This step is co-associated with the business users of the system because this is where they get access to data stored in the data warehouse. Most of the fact table rows are numerical values like price or cost per unit, etc.
dimensional model
a data structure technique optimized for Data warehousing tools
Dimensional models
are used in data warehouse systems and not a good fit for relational systems
Dimension
provides the context surrounding a business process event. In simple terms, they give who, what, where of a fact. In the Sales business process, for the fact quarterly sales number, dimensions would be • Who - Customer Names • Where - Location • What - Product Name
Fact
the measurements/metrics or facts from your business process. For a Sales business process, a measurement would be quarterly sales number
Attributes
the various characteristics of the dimension. In the Location dimension, the attributes can be • State • Country • Zipcode etc. Attributes are used to search, filter, or classify facts. Dimension Tables contain Attributes
In Dimensional modeling
there is need to ensure that every fact table has an associated date dimension table
Dimension table
• A dimension table contains dimensions of a fact. • They are joined to fact table via a foreign key. • Dimension tables are de-normalized tables. • The Dimension Attributes are the various columns in a dimension table • Dimensions offers descriptive characteristics of the facts with the help of their attributes • No set limit set for given for number of dimensions • The dimension can also contain one or more hierarchical relationships
Rules for Dimensional Modeling
• Load atomic data into dimensional structures. • Build dimensional models around business processes. • Need to ensure that every fact table has an associated date dimension table. • Ensure that all facts in a single fact table are at the same grain or level of detail. • It's essential to store report labels and filter domain values in dimension tables • Need to ensure that dimension tables use a surrogate key • Continuously balance requirements and realities to deliver business solution to support their decision-making