Hierarchy bridge tables (p 161+) Many-to-one-to-many join (p 169+) Ch 5 Ideas Mini dimensions (p 154+) Hierarchy bridge tables (p 161+) Many-to-one-to-many join (p 169+) February 2004 91.4904 Ron McFadyen

Rapidly Changing Monster Dimensions If a dimension becomes too large Split some attributes off into a new dimension, creating a minidimension Customer dimension has attributes removed Customer key Last name First name … Age Gender Income level Customer key Last name First name … Age Gender Income level A new dimension is created February 2004 91.4904 Ron McFadyen

Minidimension dimensions Fact table Customer key Last name First name … Customer key Demographics key Other keys facts Demographics key Age Gender Income level Demographics minidimension Another FK February 2004 91.4904 Ron McFadyen

Customer organizations are often hierarchically structured Hierarchies Customer organizations are often hierarchically structured Customer 1 Customer 2 Customer 7 Customer 3 Customer 4 Customer 8 Customer 5 Customer 6 February 2004 91.4904 Ron McFadyen

To facilitate access to facts to answer questions such as Bridge table To facilitate access to facts to answer questions such as How much business do we do with Customer X (and its subsiduaries)? we introduce a helper/bridge table Customer bridge Parent customer key Subsidiary customer key Levels from parent Level name Bottom flag Top flag One row in the bridge table for each pair of nodes along the path from root to a leaf February 2004 91.4904 Ron McFadyen

We can access facts in any one of three ways Bridge table We can access facts in any one of three ways 1 Customer Customer bridge Fact table Customer key … Parent customer key Subsidiary customer key … … Customer key February 2004 91.4904 Ron McFadyen

We can access facts in any one of three ways Bridge table We can access facts in any one of three ways 2 Customer Customer bridge Fact table Customer key … Parent customer key Subsidiary customer key … … Customer key February 2004 91.4904 Ron McFadyen

We can access facts in any one of three ways Bridge table We can access facts in any one of three ways 3 Customer Fact table Customer key … … Customer key The bridge table is optional – we can use it, or not Question: could we apply this to the employee hierarchy in Northwind? February 2004 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. February 2004 91.4904 Ron McFadyen

Hierarchies A B X R Q W S Z February 2004 91.4904 Ron McFadyen

Hierarchies Warehouse Product Customer Time February 2004 91.4904 Ron McFadyen

Customer Navigation Bridge Hierarchies Warehouse Product Customer Navigation Bridge Time Customer February 2004 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 February 2004 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 February 2004 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 February 2004 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 February 2004 91.4904 Ron McFadyen

Many-to-one-to-many We need information that can only be obtained by accessing two fact tables through a common dimension Fact table1 Dimension table Fact table2 … dim key dim key … … dim key Multipass SQL: each fact table is queried independently and the results combined/merged February 2004 91.4904 Ron McFadyen