Business Information Systems Dimensional Analysis Overview
•Als ODP, PDF herunterladen•
11 gefällt mir•6,760 views
![Dimensional Models ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Business Information Systems Dimensional Analysis Overview
Ähnlich wie Business Information Systems Dimensional Analysis Overview (20)
Mehr von Prithwis Mukerjee
Mehr von Prithwis Mukerjee (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Business Information Systems Dimensional Analysis Overview
- 1. Business Information Systems Dimensional Analysis Prithwis Mukerjee, Ph.D.
- 4. Queried and maintained by SQL or special purpose management tools.
- 10. May be redundant
- 13. Optimize update
- 17. The data warehousing model
- 19. Respond well to changes in user reporting needs
- 20. Relatively easy to add data without reloading tables
- 21. Standard design approaches have been developed
- 22. There exist a number of products supporting the dimensional model “ The Data Warehouse Toolkit” by Ralph Kimball & Margy Ross “ The Data Warehouse Lifecycle Toolkit” by Ralph Kimball & Margy Ross
- 23. A Transactional Database OrderDetails OrderHeaderID ProductID Amount OrderHeader OrderHeaderID CustomerID OrderDate FreightAmount Products ProductID Description Size Customers CustomerID AddressID Name Addresses AddressID StateID Street States StateID CountryID Desc Countries CountryID Description
- 24. A Dimensional Model FactSales CustomerID ProductID TimeID SalesAmount Products ProductID Description Size Subcategory Category Customers CustomerID Name Street State Country Time TimeID Date Month Quarter Year
- 25. Extract Transform Load Relational Dimensional Model Process Oriented Subject Oriented Transactional Aggregate Current Historic
- 27. Dimensions contain textual descriptors of the business. They provide context for the facts.
- 29. Tend to have huge numbers of records
- 31. 1 in a 1-M relationship
- 32. Generally the source of interesting constraints
- 33. Typically contain the attributes for the SQL answer set.
- 34. GB Video E-R Diagram Customer #Cust No F Name L Name Ads1 Ads2 City State Zip Tel No CC No Expire Rental #Rental No Date Clerk No Pay Type CC No Expire CC Approval Line #Line No Due Date Return Date OD charge Pay type Requestor of Owner of Video #Video No One-day fee Extra days Weekend Title #Title No Name Vendor No Cost Name for Holder of
- 35. GB Video Data Mart Customer CustID Cust No F Name L Name Rental RentalID Rental No Clerk No Store Pay Type Line LineID OD Charge OneDayCharge ExtraDaysCharge WeekendCharge DaysReserved DaysOverdue CustID AddressID RentalId VideoID TitleID RentalDateID DueDateID ReturnDateID Video VideoID Video No Title TitleID TitleNo Name Cost Vendor Name Rental Date RentalDateID SQLDate Day Week Quarter Holiday Due Date DueDateID SQLDate Day Week Quarter Holiday Return Date ReturnDateID SQLDate Day Week Quarter Holiday Address AddressID Adddress1 Address2 City State Zip AreaCode Phone
- 37. Process events produce fact records
- 40. Foreign (surrogate) keys refer to dimension tables (entities)
- 41. Classification values help define subsets
- 45. Less volatile than facts (1:m with the fact table)
- 46. Null entries
- 47. Date dimensions
- 50. Multidimensional models simpler to use and more efficient
- 51. The Bus Matrix Process Date Product Store Promotion Warehouse Vendor Contract Shipper Retail Sales X X X X Retail Inventory X X X Retail Deliveries X X X Warehouse Inventory X X X X Warehouse Deliveries X X X X Purchase Orders X X X X X X
- 54. Flexible
- 56. The structure can be overwhelmingly complex. We may wind up creating many small relations which the user might think of as a single relation or group of data.
- 60. Choose the Facts
- 62. Translate this into a dimensional model. This step reflects the information and analytical characteristics of the data warehouse.
- 63. Translate this into the physical model. This reflects the changes necessary to reach the stated performance objectives.
- 65. The star architecture that we will develop here depends upon taking the central intersection entities as the fact tables and building the foreign key => primary key relations as dimensions.
- 68. Replace operational keys with surrogate keys
- 69. Promote the keys from all hierarchies to the fact table
- 71. Split all compound attributes
- 72. Add necessary categorical dimensions
- 73. Fact (varies with time) / Attribute (constant)
- 74. The Big Picture OL T P OL A P
- 76. Identify an association table as the central fact table
- 77. Determine facts to be included
- 78. Replace all keys with surrogate keys
- 79. Promote foreign keys in related tables to the fact table
- 81. Refine the dimension tables
- 83. Single source or multiple source
- 85. Typically have a fact table for each process
- 87. Typically correspond to an associative entity in the E-R model
- 89. Snapshots (points in time)
- 92. Non-key attributes in the fact table Attributes in dimension tables are constants. Facts vary with the granularity of the fact table
- 94. Connected with surrogate (generated) keys, not operational keys
- 95. Dimension tables contain text or numeric attributes
- 96. ORDER order_num (PK) customer_ID (FK) store_ID (FK) clerk_ID (FK) date STORE store_ID (PK) store_name address district floor_type CLERK clerk_id (PK) clerk_name clerk_grade PRODUCT SKU (PK) description brand category CUSTOMER customer_ID (PK) customer_name purchase_profile credit_profile address PROMOTION promotion_NUM (PK) promotion_name price_type ad_type ORDER-LINE order_num (PK) (FK) SKU (PK) (FK) promotion_key (FK) dollars_sold units_sold dollars_cost ERD
- 97. TIME time_key (PK) SQL_date day_of_week month STORE store_key (PK) store_ID store_name address district floor_type CLERK clerk_key (PK) clerk_id clerk_name clerk_grade PRODUCT product_key (PK) SKU description brand category CUSTOMER customer_key (PK) customer_name purchase_profile credit_profile address PROMOTION promotion_key (PK) promotion_name price_type ad_type FACT time_key (FK) store_key (FK) clerk_key (FK) product_key (FK) customer_key (FK) promotion_key (FK) dollars_sold units_sold dollars_cost DIMENSONAL MODEL
- 99. Descriptive
- 100. Complete
- 101. Quality assured
- 102. Indexed (b-tree vs bitmap)
- 103. Equally available
- 104. Documented
- 105. Date Dimensions
- 108. Understandability
- 109. M:N relationships
- 110. Star Schema ProductID TimeID CustomerID SalesAmount factSales ProductID ProductName CategoryName SubCategoryName dimProduct … dimCustomer … dimTime
- 111. Snowflake Schema ProductID TimeID CustomerID SalesAmount factSales ProductID CategoryID Description dimProduct CategoryID subCategoryID Description dimCategory SubCategoryID Description dimSubCategory
- 112. Simple DW hierarchy pattern.
- 113. If you don’t consider changes over time your model will start out like this…
- 114. … but ending up like this!
- 116. Type 2: Create a dimension record for each value (with or without date stamps)
- 117. Type 3: Create an attribute in the dimension record for previous value
- 118. Examples Type 3 Type 2 Type 1 Original Hybrid ProductKey Description Category SKU 21553 LeapPad Education LP2105 ProductKey Description Category SKU 21553 LeapPad Toy LP2105 ProductKey Description Category SKU 21553 LeapPad Education LP2105 44631 LeapPad Toy LP2105 ProductKey Description Category OldCat SKU 21553 LeapPad Toy Education LP2105 ProductKey Description Category OldCat SKU 21335 LeapPad Electronics Education LP2105 44631 LeapPad Electronics Toy LP2105 68122 LeapPad Education Electronics LP2105
- 120. Only updates existing records
- 121. Overwrites history
- 122. Type 1 Slowly Changing Dimension CustomerID Code Name State Gender 1 K001 Miranda Kerr NSW F CustomerID Code Name State Gender 1 K001 Miranda Kerr VIC F
- 124. Generates a new record each time the state changes
- 125. Usually requires the use of effective dates when joining to facts.
- 126. Type 2 Slowly Changing Dimension 23/2/09 CustomerID Code Name State Gender Start End 1 K001 Miranda Kerr NSW F 1/1/09 <NULL> CustomerID Code Name State Gender Start End 1 K001 Miranda Kerr NSW F 1/1/09 23/2/09 2 K001 Miranda Kerr VIC F 24/2/09 <NULL>
- 128. Only keeps a limited history
- 129. Stores changes in separate columns
- 130. Type 3 Slowly Changing Dimension VIC NSW CustomerID Code Name Current State Gender Prev State 1 K001 Miranda Kerr F <NULL>
Hinweis der Redaktion
- A simplistic transactional schema showing 7 tables relating to sales orders
- This is a star schema, (later on we will discuss snowflake schemas.) showing 4 tables that relate to the previous transactional schema State and Country have been denormalized under Customer Dimensions are in Blue These are the things that we analyse “by” (eg. By Time, By Customer, By Region) Fact is yellow These are ususally quantitative things that we are interested in
- We already have the data in a data model – why create another data model…? Well… What is currently called “Data Warehousing” or “Business Intelligence” was originally often called “Decision Support Systems” We already have all the data in the OLTP system, why replicate it in a dimensional model? Atomic - Summary Supports Transaction throughput – Supports Aggregate queries Current - Historic
- Facts work best if they are additive Dimensions allow us to “slice & dice” the facts into meaningful groups. The provide context
- Designing the Perfect Data Warehouse (the paper formerly known as: Data Modeling for Data Warehouses), Frank McGuff , http://members.aol.com/fmcguff/dwmodel/
- There are some changes where it is valid to overwrite history. When someone gets married and changes their name, they may want to carry the history of their previous purchases over to their new name rather than see a split history.
- This makes inserts into your fact table more expensive as you always need to match on the effective dates as well as the business key. Sometimes people kept a “Current” flag. Another approach rather than putting nulls in the End date is to put an arbitrary date well in the future, this can make the join logic a bit simpler.
- This type of change tracking is more useful when there is a once off change like a change in sales regions where you want to see history re-cast into the new regions, but may also want to compare the old and new regions.