Editing Data warehouse (section)

====Dimensional approach====
In a [[Star schema|dimensional approach]], [[transaction data]] is partitioned into "facts", which are usually numeric transaction data, and "[[dimension (data warehouse)|dimensions]]", which are the reference information that gives context to the facts. For example, a sales transaction can be broken up into facts such as the number of products ordered and the total price paid for the products, and into dimensions such as order date, customer name, product number, order ship-to and bill-to locations, and salesperson responsible for receiving the order.

This dimensional approach makes data easier to understand and speeds up data retrieval.<ref name=":0" /> Dimensional structures are easy for business users to understand because the structure is divided into measurements/facts and context/dimensions. Facts are related to the organization's business processes and operational system, and dimensions are the context about them (Kimball, Ralph 2008). Another advantage is that the dimensional model does not involve a relational database every time. Thus, this type of modeling technique is very useful for end-user queries in data warehouse.

The model of facts and dimensions can also be understood as a [[data cube]],<ref>{{cite web| url = http://www2.cs.uregina.ca/~dbd/cs831/notes/dcubes/dcubes.html| title = Introduction to Data Cubes}}</ref> where dimensions are the categorical coordinates in a multi-dimensional cube, the fact is a value corresponding to the coordinates.

The main disadvantages of the dimensional approach are:
# It is complicated to maintain the integrity of facts and dimensions, loading the data warehouse with data from different operational systems
# It is difficult to modify the warehouse structure if the organization changes the way it does business.