Download presentation
Presentation is loading. Please wait.
1
Factless Facts: Occurrences of Relationships or Events
Pages (Could be considered a fourth type of fact table) For each student we can measure the event of the student being enrolled in a program in a term Program Dimension Student Dimension StudentFact (=1) Term Dimension A metric that is always one, makes counting easier Feb 6, 2003 Ron McFadyen
2
Heterogeneous Products in a Bank
Pages Household Facts account_key household_key branch_key product_key status_key time_key primary_balance transaction_count Many checking facts… Many saving facts… Many credit card facts… Many safe deposit facts… product_key product_description type category many checking attributes… many savings attributes… many credit card attributes… many safe deposit attributes… One approach with all variations provided for in a single fact table and single dimension table Feb 6, 2003 Ron McFadyen
3
Heterogeneous Products in a Bank
Custom Checking Facts account_key household_key branch_key product_key status_key time_key primary_balance transaction_count Many checking facts… product_key product_description type category many checking attributes… Custom Savings Facts product_key product_description type category many saving attributes… account_key household_key branch_key product_key status_key time_key primary_balance transaction_count Many savings facts… Another approach with custom fact and custom product dimensions, with a core fact and core dimension (next slide) Feb 6, 2003 Ron McFadyen
4
Heterogeneous Products in a Bank
Core Facts account_key household_key branch_key product_key status_key time_key primary_balance transaction_count Core dimension – limited number of attributes product_key product_description type category All the product dimensions can share the same surrogate/product key values Feb 6, 2003 Ron McFadyen
5
Many-to-many dimensions Many-to-one-to-many traps
Ch 6 Graduate Course … Read pages Many-to-many dimensions Many-to-one-to-many traps Role playing dimensions Hierarchies A second assignment involves implementing each of these (any database system) Feb 6, 2003 Ron McFadyen
6
Many-to-Many Dimensions
Consider a typical DM for tracking student performance in courses: one record per student per course per term per instructor. Course Student Credit hours Grade obtained Faculty Term Feb 6, 2003 Ron McFadyen
7
Many-to-Many Dimensions
Suppose a course may be taught by a group of faculty members. That is, a fact row is logically related to 1 or more faculty rows. We can’t extend the fact table with more FKs because the number of faculty members per offering is variable. We don’t want to add more rows to the fact table... Course Student Credit hours Grade obtained m n Faculty Term Feb 6, 2003 Ron McFadyen
8
Many-to-Many Dimensions
We manage this situation with a bridge table Course Student 1 1 n n Credit hours Grade obtained TeachingBridge n 1 Term Faculty Feb 6, 2003 Ron McFadyen
9
Many-to-Many Dimensions
We manage this situation with a bridge table. The TeachingBridge table has PK {TeachingBridgeId, FacultyId} Credit hours Grade obtained TeachingBridge n 1 n 1 Faculty Feb 6, 2003 Ron McFadyen
10
Many-to-Many Dimensions
Text discusses a weighting factor used to distinguish the contribution each dimension participant makes to the group. In this case its probably 1/NumberOfMembers. Attributes in the physical TeachingBridge table are: TeachingBridgeId FacultyId WeightingFactor Faculty 1 n Credit hours Grade obtained TeachingBridge n 1 Feb 6, 2003 Ron McFadyen
11
Many-to-Many Dimensions
Visit (Encounter) Diagnosis DiagnosisGroupKey Patient Key ExamGroupKey Physician Key Time Key Patient Physician Time Exam Feb 6, 2003 Ron McFadyen
12
Many-to-Many Dimensions
Visit (Encounter) Diagnosis DiagnosisGroupKey Patient Key ExamGroupKey Physician Key Time Key Bridge Patient Bridge Physician Time Exam Feb 6, 2003 Ron McFadyen
13
Role Playing Dimensions
Consider a DM where we are tracking claims as they make their way through processing to payment or refusal We can track the date received, the date the accident occurred, the date of adjustment, the date of payment, as well as the policy holder, the policy, the claimed amount, the paid amount Accident Date Adjustment Date Receipt Date facts Payment Date PolicyHolder Policy Feb 6, 2003 Ron McFadyen
14
Role Playing Dimensions
A dimension appears several times, in different roles. We need to implement the dimension once, and reference it via several FKs. One must be careful with the SQL when retrieving data Accident Date Adjustment Date Receipt Date facts Payment Date PolicyHolder Policy Feb 6, 2003 Ron McFadyen
15
Hierarchies Suppose the companies that an organization deals with are often parts of other larger companies that can be expressed as a hierarchical structure Suppose that the companies an organization deals with are not just the ones at the bottom of the hierarchy, they could be any level If we have a regular Customer dimension, then there are some analyses that we cannot do. For instance, how much business do we do with X, where X includes its subordinate companies too. Feb 6, 2003 Ron McFadyen
16
Hierarchies A B X R Q W S Z Feb 6, 2003 Ron McFadyen
17
Hierarchies Warehouse Product Customer Time Feb 6, 2003
Ron McFadyen
18
Customer Navigation Bridge
Hierarchies Warehouse Product Customer Navigation Bridge Time Customer Feb 6, 2003 Ron McFadyen
19
Customer Navigation Bridge
Hierarchies Attributes: custKey productKey timeKey warehouseKey facts Attributes: parentCustKey subsiduaryCustKey numLevels leafFlag Warehouse Product Customer Navigation Bridge Time Customer Feb 6, 2003 Ron McFadyen
20
For our previous case we have 20 entries:
Hierarchies The bridge table here will have one row for each parent/child combination (including parent=child) For our previous case we have 20 entries: A AB AQ AW AZ AX AR AS BQ BW BZ WZ RS AA BB QQ WW ZZ XX RR SS B X R Q W S Z Feb 6, 2003 Ron McFadyen
21
Hierarchies AB1N AQ2Y AW2N AZ3Y AX1Y AR1N AS2Y BQ1Y BW1N BZ2Y WZ1Y
Attributes: parentCustKey subsiduaryCustKey numLevels leafFlag AB1N AQ2Y AW2N AZ3Y AX1Y AR1N AS2Y BQ1Y BW1N BZ2Y WZ1Y RS1Y AA0N BB0N QQ0Y WW0N ZZ0Y XX0Y RR0N SS0Y Feb 6, 2003 Ron McFadyen
22
Three ways we can join the Fact table to Customer:
Hierarchies Fact table Customer Navigation Bridge custKey productKey timeKey warehouseKey facts custKey attribute1, attribute2, … parentCustKey subsiduaryCustKey numLevels leafFlag Three ways we can join the Fact table to Customer: Fact.custKey = Customer.custKey Fact.custKey = Navigation.parentCustKey Fact.custKey = Navigation.subsiduaryCustKey Feb 6, 2003 Ron McFadyen
23
What are the reasons for using these? Fact.custKey = Customer.custKey
Hierarchies Fact table Customer Navigation Bridge custKey productKey timeKey warehouseKey facts custKey attribute1, attribute2, … parentCustKey subsiduaryCustKey numLevels leafFlag What are the reasons for using these? Fact.custKey = Customer.custKey Fact.custKey = Navigation.parentCustKey Fact.custKey = Navigation.subsiduaryCustKey Feb 6, 2003 Ron McFadyen
Similar presentations
