Factless Facts: Occurrences of Relationships or Events Pages 212-216 (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 91.4904 Ron McFadyen

Heterogeneous Products in a Bank Pages 203-205 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 91.4904 Ron McFadyen

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 91.4904 Ron McFadyen

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 91.4904 Ron McFadyen

Many-to-many dimensions Many-to-one-to-many traps Ch 6 Graduate Course … Read pages 217-231 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 91.4904 Ron McFadyen

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 91.4904 Ron McFadyen

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 91.4904 Ron McFadyen

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 91.4904 Ron McFadyen

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 91.4904 Ron McFadyen

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 91.4904 Ron McFadyen

Many-to-Many Dimensions Visit (Encounter) Diagnosis DiagnosisGroupKey Patient Key ExamGroupKey Physician Key Time Key Patient Physician Time Exam Feb 6, 2003 91.4904 Ron McFadyen

Many-to-Many Dimensions Visit (Encounter) Diagnosis DiagnosisGroupKey Patient Key ExamGroupKey Physician Key Time Key Bridge Patient Bridge Physician Time Exam Feb 6, 2003 91.4904 Ron McFadyen

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 91.4904 Ron McFadyen

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 91.4904 Ron McFadyen

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 91.4904 Ron McFadyen

Hierarchies A B X R Q W S Z Feb 6, 2003 91.4904 Ron McFadyen

Hierarchies Warehouse Product Customer Time Feb 6, 2003 91.4904 Ron McFadyen

Customer Navigation Bridge Hierarchies Warehouse Product Customer Navigation Bridge Time Customer Feb 6, 2003 91.4904 Ron McFadyen

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 91.4904 Ron McFadyen

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 91.4904 Ron McFadyen

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 91.4904 Ron McFadyen

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 91.4904 Ron McFadyen

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 91.4904 Ron McFadyen