1 ACCTG 6910 Building Enterprise & Business Intelligence Systems (e.bis) Dimensional Modeling VI Olivia R. Liu Sheng, Ph.D. Emma Eccles Jones Presidential.

Slides:



Advertisements
Similar presentations
Chapter 4 Tutorial.
Advertisements

Chapter 4 Tutorial.
Two 11 th grade students were selected to be participants in the activity. Both students are male and are currently enrolled at Salem High School. While.
Adv. DBMS & DW Chapter 9: Insurance Chapter 10: Factless Fact Tables
Lecture 3 Themes in this session Basics of the multidimensional data model and star- join schemata The process of, and specific design issues in, multidimensional.
Tips and Tricks for Dimensional Modeling
BY LECTURER/ AISHA DAWOOD DW Lab # 2. LAB EXERCISE #1 Oracle Data Warehousing Goal: Develop an application to implement defining subject area, design.
MIS 451 Building Business Intelligence Systems
Advanced Databases Temporal Databases Dr Theodoros Manavis
Dimensional Modeling Business Intelligence Solutions.
Dimensional Modeling CS 543 – Data Warehousing. CS Data Warehousing (Sp ) - Asim LUMS2 From Requirements to Data Models.
1 ACCTG 6910 Building Enterprise & Business Intelligence Systems (e.bis) Introduction to Data Mining Olivia R. Liu Sheng, Ph.D. Emma Eccles Jones Presidential.
1 9 Ch3, Hachim Haddouti Adv. DBS and Data Warehouse CSC5301 Ch3 Hachim Haddouti Hachim Haddouti.
MIS 451 Building Business Intelligence Systems Logical Design (5) – Aggregate.
1 ACCTG 6910 Building Enterprise & Business Intelligence Systems (e.bis) Data Staging Olivia R. Liu Sheng, Ph.D. Emma Eccles Jones Presidential Chair of.
1 ACCTG 6910 Building Enterprise & Business Intelligence Systems (e.bis) Association Rule Mining II Olivia R. Liu Sheng, Ph.D. Emma Eccles Jones Presidential.
Hachim Haddouti, adv. DBMS & DW CSC5301, Ch6 Chapter 6: The Big Dimensions Adv. DBMS & DW Hachim Haddouti.
Ch5: Software Specification. 1 Descriptive specifications  Describe desired properties of system  Three types:
1 ACCTG 6910 Building Enterprise & Business Intelligence Systems (e.bis) Dimensional Modeling V Olivia R. Liu Sheng, Ph.D. Emma Eccles Jones Presidential.
1 ACCTG 6910 Building Enterprise & Business Intelligence Systems (e.bis) Dimensional Modeling I Olivia R. Liu Sheng, Ph.D. Emma Eccles Jones Presidential.
1 ACCTG 6910 Building Enterprise & Business Intelligence Systems (e.bis) From Information Management to Knowledge Management Olivia R. Liu Sheng, Ph.D.
1 ACCTG 6910 Building Enterprise & Business Intelligence Systems (e.bis) Association Rule Mining Olivia R. Liu Sheng, Ph.D. Emma Eccles Jones Presidential.
ACCTG 6910 Building Enterprise & Business Intelligence Systems (e.bis)
1 ACCTG 6910 Building Enterprise & Business Intelligence Systems (e.bis) Physical Data Warehouse Design Olivia R. Liu Sheng, Ph.D. Emma Eccles Jones Presidential.
1 ACCTG 6910 Building Enterprise & Business Intelligence Systems (e.bis) Dimensional Modeling II Olivia R. Liu Sheng, Ph.D. Emma Eccles Jones Presidential.
1 ACCTG 6910 Building Enterprise & Business Intelligence Systems (e.bis) Introduction to Data Warehouse Olivia R. Liu Sheng, Ph.D. Emma Eccles Jones Presidential.
Data Warehousing - 3 ISYS 650. Snowflake Schema one or more dimension tables do not join directly to the fact table but must join through other dimension.
1 ACCTG 6910 Building Enterprise & Business Intelligence Systems (e.bis) The Data Warehouse Lifecycle Olivia R. Liu Sheng, Ph.D. Emma Eccles Jones Presidential.
MIS 451 Building Business Intelligence Systems Logical Design (3) – Design Multiple-fact Dimensional Model.
1 ACCTG 6910 Building Enterprise & Business Intelligence Systems (e.bis) Clustering Olivia R. Liu Sheng, Ph.D. Emma Eccles Jones Presidential Chair of.
July 14, 2015ICS 424: recap1 Relational Database Design: Recap of ICS 324.
1 ACCTG 6910 Building Enterprise & Business Intelligence Systems (e.bis) Olivia R. Liu Sheng, Ph.D. Emma Eccles Jones Presidential Chair of Business Dimensional.
Lecture 5 CS.456 DATABASE DESIGN.
CS 345: Topics in Data Warehousing Thursday, October 7, 2004.
Review Session What is data, what is information, and give a real world example to differentiate these two concepts.
Entity-Relationship Model Ch. 3
DATABASEMODELSDATABASEMODELS  A database model ◦ defines the logical design of data. ◦ Describes the relationships between different parts of data.
Dimensional model. What do we know so far about … FACTS? “What is the process measuring?” Fact types:  Numeric Additive Semi-additive Non-additive (avg,
More on relational databases, including 1 to 1, 1 to many and many to many relationships Please use speaker notes for additional information!
Chapter 1 Adamson & Venerable Spring Dimensional Modeling Dimensional Model Basics Fact & Dimension Tables Star Schema Granularity Facts and Measures.
Data Warehouse design models in higher education courses Patrizia Poščić, Associate Professor Danijela Subotić, Teaching Assistant.
Basic Model: Retail Grocery Store
COMP231 Tutorial 1 ER Model and ER to Relational Schema.
1 Data Warehousing Lecture-15 Issues of Dimensional Modeling Virtual University of Pakistan Ahsan Abdullah Assoc. Prof. & Head Center for Agro-Informatics.
More Dimensional Modeling. Facts Types of Fact Design Transactional Periodic Snapshot –Predictable time period –Ex. Monthly, yearly, etc. Accumulating.
Fact Table The fact table stores business events. The attributes explain the conditions of the entity at the time the business event happened.
MIS 451 Building Business Intelligence Systems Logical Design (1)
Data Warehousing (Kimball, Ch.5-12) Dr. Vairam Arunachalam School of Accountancy, MU.
June 08, 2011 How to design a DATA WAREHOUSE Linh Nguyen (Elly)
Copyright© 2014, Sira Yongchareon Department of Computing, Faculty of Creative Industries and Business Lecturer : Dr. Sira Yongchareon ISCG 6425 Data Warehousing.
Dr. Abdul Basit Siddiqui. The Process of Dimensional Modeling Four Step Method from ER to DM 1. Choose the Business Process 2. Choose the Grain 3. Choose.
DO NOT COPY --CONFIDENTIAL Homework 5 Partial Key Star Diagrams & Data Warehouse Design BCIS 4660 Dr. Nick Evangelopoulos Spring 2012.
Howard Paul. Sequential Access Index Files and Data File Random Access.
Last Updated : 26th may 2003 Center of Excellence Data Warehousing Introductionto Data Modeling.
Houston Petroleum Valve Company Data-Mining Project Data Modeling Phase Fouad Alibrahim Mohammad H. Monakes University of Houston Clear Lake University.
DATA WAREHOUSING – DIMENSIONAL MODELLING AND SCHEMAS With MIKE –AARONE ATUHE Handout 5.
Copyright © 2016 Pearson Education, Inc. Modern Database Management 12 th Edition Jeff Hoffer, Ramesh Venkataraman, Heikki Topi CHAPTER 9: DATA WAREHOUSING.
Applying Data Warehouse Techniques
Applying Data Warehouse Techniques
Applying Data Warehouse Techniques
Data warehouse architecture CIF, DM Bus Matrix Star schema
Factless Facts: Occurrences of Relationships or Events
Retail Sales is used to illustrate a first dimensional model
Dimensional Model January 16, 2003
Applying Data Warehouse Techniques
Examines blended and separate transaction schemas
Review of Major Points Star schema Slowly changing dimensions Keys
This is an example of Object-Oriented Modeling diagram.
Applying Data Warehouse Techniques
Review of Major Points Star schema Slowly changing dimensions Keys
Presentation transcript:

1 ACCTG 6910 Building Enterprise & Business Intelligence Systems (e.bis) Dimensional Modeling VI Olivia R. Liu Sheng, Ph.D. Emma Eccles Jones Presidential Chair of Business

2 Outline Factless Facts (Ch. 2, 12, 15) Snapshot Facts (Ch. 3) Slowly Changing Dimensions (Ch. 4) M-to-M Relationships – Multi-valued Dimensions (Ch. 9, 13)

3 FacultyStudent Course (Ternary) Relationship: One or many students take one or many courses from one teacher Measure: # of times the whole or a partial relationship occurs 1m m Factless Facts: Measuring Occurrences of Relationships or Events

4 Enrollment Fact Faculty Key Student Key Course Key Time Key Student Dimension Course Dimension Time Dimension Faculty Dimension Factless Facts No attributes other than the DW keys of dimension tables are in the fact table

5 FacultySemester Course 1m m Classroom 1 Factless Facts Relationship: a teacher teaches in a classroom 1 or many courses over one or many semesters Measure: # of times the whole or a partial relationship occurs

6 Room Assignment Fact Room Key Faculty Key Course Key Time Key Room Dimension Course Dimension Time Dimension Faculty Dimension Factless Facts

7 Snapshot Facts: The Simplest Inventory Schema Time Dimension time_key product_key warehouse_key quantity_on_hand Warehouse Dimension Product Dimension Inventory Fact Accumulative measure

8 Slowly Changing Dimension

9 Values of attributes in dimension tables may evolve over time. For example, customers moved from one city to another city. CID CNameStateCity 101JonArizonaTucson 102TomArizonaTucson 103MarkArizonaPhoenix Tom moved from Tucson to Salt Lake City Salt Lake City Utah

10 Slowly Changing Dimension There are three ways to handle slowly changing dimension. Method 1: Overwrite old values with new values CID CNameStateCity 101JonArizonaTucson 102TomArizonaTucson 103MarkArizonaPhoenix CID CNameStateCity 101JonArizonaTucson 102TomUtahSalt Lake city 103MarkArizonaPhoenix

11 Slowly Changing Dimension Drawbacks of method 1: Historical information is totally lost. We will never know that customer 102 lived in Tucson before. Moreover, when listing sales by city, all the sales of customer 102 will be counted as part of Salt Lake City sales, although 102 was in Tucson before.

12 Slowly Changing Dimension Method 2: Add a new attribute to record current value of the changing attribute. CID CNameStateCity 101JonArizonaTucson 102TomArizonaTucson 103MarkArizonaPhoenix CIDCNameStateOriginal CityCurrent City 101JonArizonaTucson 102TomArizonaTucsonSalt Lake City 103MarkArizonaPhoenix Current State Arizona Utah

13 Slowly Changing Dimension Drawbacks of method 2: Only partial Historical information (original & current) is kept. Considering that customer 102 moved from Tucson to Phoenix then to Salt Lake City, the customer information of customer 102 only includes Tucson and Salt Lake City.

14 Slowly Changing Dimension Warehouse key Method 3: Add a new dimension record whenever change occurs  keep all the information. Utah Utah Salt Lake City

15 Multi-Value Dimension Most of the dimension tables have a 1-m relationship with the fact table Product  Sale, Customer  Sale, SalesDate  Sale… What if there is a m-to-m relationship between a dimension and a fact?

16 Multi-Value Dimension PatientDatePhysicianMedication 1Medication 2 112/11/00JamesAspirinTylenol 21/2/01KathyTylenolAlomide 12/1/01JamesAtivanLodine The above table is a visit table from a clinic. We want a factless fact table and preserve medication information

17 Multi-Value Dimension VISIT Time Patient Med. Physician m to m !! A physician may prescribe 1 or many medications at a patient visit A physician may prescribe the same medication at different visits

18 Multi-Value Dimension If we have a “grouping” table for medication…. PatientDatePhysicianGroupID 112/11/00James1 21/2/01Kathy2 12/1/01James3 GroupIDMedication 1Aspirin 1Tylenol 2 2Alomide 3Lodine 3Ativan

19 Medication Dimension Medication Group Bridge Medication Group GroupIDMedication 1Aspirin 1Tylenol 2 2Alomide 3Lodine 3Ativan GroupID Medication Aspirin Tylenol Alomide Lodine Ativan 11 m m Medication Group Bridage is what we call a bridge table

20 Multi-Value Dimension Medication Medication Group Bridge Medication Group 1 1 m m VISIT Time PatientPhysician