Dimension Table Dimension table is one that describe the business entities of an enterprise, represented as hierarchical, categorical information

such as time, departments, locations, and products. Dimension tables are sometimes called lookup or reference tables. Location Dimension In a relational data modeling, for normalization purposes, country lookup, state lookup, county lookup, and city lookups are not merged as a single table. In a dimensional data modeling(star schema), these tables would be merged as a single table called LOCATION DIMENSION for performance and slicing data requirements. This location dimension helps to compare the sales in one region with another region. We may see good sales profit in one region and loss in another region. If it is a loss, the reasons for that may be a new competitor in that area, or failure of our marketing strategy etc. Example of Location Dimension: Figure 1.8

Country Lookup Country Code USA Country Name United States Of America DateTimeStamp 1/1/2005 11:23:31 AM

State Lookup State Code NY FL CA NJ State Name New York Florida California New Jersey DateTimeStamp 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM

County Lookup

County Code NYSH FLJE CAMO NJHU City Lookup City Code NYSHMA FLJEPC CAMOSH NJHUJC

County Name Shelby Jefferson Montgomery Hudson

DateTimeStamp 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM

City Name Manhattan Panama City San Hose Jersey City

DateTimeStamp 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM

Location Dimension Location Dimension Id 1 2 3 4 Country Name USA USA USA USA State Name New York Florida California New Jersey County Name Shelby Jefferson Montgomery Hudson City Name Manhattan Panama City San Hose Jersey City DateTime Stamp 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM

Product Dimension In a relational data model, for normalization purposes, product category lookup, product sub-category lookup, product lookup, and and product feature lookups are are not merged as a single table. In a dimensional data modeling(star schema), these tables would be merged as a single table called PRODUCT DIMENSION for performance and slicing data requirements.

Example of Product Dimension: Figure 1.9

Product Category Lookup Product Category Code Product Category Name DateTimeStamp 1 Apparel 1/1/2005 11:23:31 AM 2 Shoe 1/1/2005 11:23:31 AM Product Sub-Category Lookup Product Sub-Category Code 11 12 13 14 Product Lookup Product Code 1001 1002 1003 1004 Product Name Van Heusen Arrow Nike Adidas DateTimeStamp 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM Product Sub-Category Name Shirt Trouser Casual Formal DateTime Stamp 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM

Product Feature Lookup Product Feature Code Product Feature Description DateTimeStamp 10001 Van-M 1/1/2005 11:23:31 AM 10002 Van-L 1/1/2005 11:23:31 AM

10003 10004 10005 10006 10007 10008 Product Dimension

Arr-XL Arr-XXL Nike-8 Nike-9 Adidas-10 Adidas-11

1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM

Product Product Category Dimension Id Name 100001 100002 100003 100004 100005 100006 100007 100008 Apparel Apparel Apparel Apparel Shoe Shoe Shoe Shoe

Product SubProduct Category Name Name Shirt Shirt Shirt Shirt Casual Casual Casual Casual Van Heusen Van Heusen Arrow Arrow Nike Nike Adidas Adidas

Product DateTime Feature Desc Stamp Van-M Van-L Arr-XL Arr-XXL Nike-8 Nike-9 Adidas-10 Adidas-11 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM

Organization Dimension In a relational data model, for normalization purposes, corporate office lookup, region lookup, branch lookup, and employee lookups are not merged as a single table. In a dimensional data modeling(star schema), these tables would be merged as a single table called ORGANIZATION DIMENSION for performance and slicing data. This dimension helps us to find the products sold or serviced within the organization by the employees. In any industry, we can calculate the sales on region basis, branch basis and employee basis. Based on the performance, an organization can provide incentives to employees and subsidies to the branches to increase further sales.

Example of Organization Dimension: Figure 1.10

Corporate Lookup Corporate Code CO Corporate Name American Bank DateTimeStamp 1/1/2005 11:23:31 AM

Region Lookup Region Code Region Name DateTimeStamp SE South East 1/1/2005 11:23:31 AM MW Mid West 1/1/2005 11:23:31 AM Branch Lookup Branch Code Branch Name DateTimeStamp FLTM Florida-Tampa 1/1/2005 11:23:31 AM ILCH Illinois-Chicago 1/1/2005 11:23:31 AM Employee Lookup Employee Code E1 E2 Employee Name Paul Young Chris Davis DateTimeStamp 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM

Organization Dimension

Organization Dimension Id 1 2

Corporate Name American Bank American Bank

Region Name South East

Branch Name FloridaTampa IllinoisMid West Chicago

Employee Name

DateTime Stamp 1/1/2005 Paul Young 11:23:31 AM 1/1/2005 Chris Davis 11:23:31 AM

Time Dimension In a relational data model, for normalization purposes, year lookup, quarter lookup, month lookup, and week lookups are not merged as a single table. In a dimensional data modeling(star schema), these tables would be merged as a single table called TIME DIMENSION for performance and slicing data. This dimensions helps to find the sales done on date, weekly, monthly and yearly basis. We can have a trend analysis by comparing this year sales with the previous year or this week sales with the previous week. Example of Time Dimension: Figure 1.11

Year Lookup Year Id Year Number DateTimeStamp 1 2004 1/1/2005 11:23:31 AM 2 2005 1/1/2005 11:23:31 AM Quarter Lookup Quarter Number 1 2 3 Quarter Name Q1 Q2 Q3 DateTimeStamp 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM

4 Month Lookup Month Number 1 2 3 4 5 6 7 8 9 10 11 12 Week Lookup Week Number 1 1 1 1 1 1 1 2 2 2 2 2 2 2

Q4

1/1/2005 11:23:31 AM

Month Name January February March April May June July August September October November December

DateTimeStamp 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM

Day of Week Sunday Monday Tuesday Wednesday Thursday Friday Saturday Sunday Monday Tuesday Wednesday Thursday Friday Saturday

DateTimeStamp 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM 1/1/2005 11:23:31 AM

Time Dimension Time Year Day Quarter Month Month Dim No Of No No Name Month Week Day Cal Date DateTime Day No of Stamp

Id 1 2 3 4

Year 2004 1 2004 32 2005 1 2005 32 Q1 Q1 Q1 Q1 1 2 1 2

No January 1 February 1 January 1 February 1 1 5 1 5

Week 5 1 7 3 1/1/2005 1/1/2004 11:23:31 AM 1/1/2005 2/1/2004 11:23:31 AM 1/1/2005 1/1/2005 11:23:31 AM 1/1/2005 2/1/2005 11:23:31 AM

Slowly Changing Dimensions Dimensions that change over time are called Slowly Changing Dimensions. For instance, a product price changes over time; People change their names for some reason; Country and State names may change over time. These are a few examples of Slowly Changing Dimensions since some changes are happening to them over a period of time. Slowly Changing Dimensions are often categorized into three types namely Type1, Type2 and Type3. The following section deals with how to capture and handling these changes over time. The "Product" table mentioned below contains a product named, Product1 with Product ID being the primary key. In the year 2004, the price of Product1 was $150 and over the time, Product1's price changes from $150 to $350. With this information, let us explain the three types of Slowly Changing Dimensions. Product Price in 2004: Product ID(PK) Year Product Name Product Price 1 2004 Product1 $150 Type 1: Overwriting the old values. In the year 2005, if the price of the product changes to $250, then the old values of the columns "Year" and "Product Price" have to be updated and replaced with the new values. In this Type 1, there is no way to find out the old value of the product "Product1" in year 2004 since the table now contains only the new price and year information. Product Product ID(PK) Year Product Name Product Price

2005 Product1

$250

Type 2: Creating an another additional record. In this Type 2, the old values will not be replaced but a new row containing the new values will be added to the product table. So at any point of time, the difference between the old values and new values can be retrieved and easily be compared. This would be very useful for reporting purposes. Product Product ID(PK) Year Product Name Product Price 1 2004 Product1 $150 1 2005 Product1 $250 The problem with the above mentioned data structure is "Product ID" cannot store duplicate values of "Product1" since "Product ID" is the primary key. Also, the current data structure doesn't clearly specify the effective date and expiry date of Product1 like when the change to its price happened. So, it would be better to change the current data structure to overcome the above primary key violation. Product Product ID(PK) 1 1 Effective DateTime(PK) 01-01-2004 12.00AM 01-01-2005 12.00AM Year Product Name Product Price $150 $250 Expiry DateTime 12-31-2004 11.59PM

2004 Product1 2005 Product1

In the changed Product table's Data structure, "Product ID" and "Effective DateTime" are composite primary keys. So there would be no violation of primary key constraint. Addition of new columns, "Effective DateTime" and "Expiry DateTime" provides the information about the product's effective date and expiry date which adds more clarity and enhances the scope of this table. Type2 approach may need additional space in the data base, since for every changed record, an additional row has to be stored. Since dimensions are not that big in the real world, additional space is negligible.

Type 3: Creating new fields. In this Type 3, the latest update to the changed values can be seen. Example mentioned below illustrates how to add new columns and keep track of the changes. From that, we are able to see the current price and the previous price of the product, Product1. Product

Current Product ID(PK) 1 Year 2005

Product Current Name Product Price Product1 $250

Old Product Old Year Price $150 2004

The problem with the Type 3 approach, is over years, if the product price continuously changes, then the complete history may not be stored, only the latest change will be stored. For example, in year 2006, if the product1's price changes to $350, then we would not be able to see the complete history of 2004 prices, since the old values would have been updated with 2005 product information. Product Product Product ID(PK) Year Name 1 Product Old Product Old Year Price $250 2005

Price 2006 Product1 $350