1. Multivalued Dimensions and Bridges
Presented by :Ali Sellami
Intelligent information systems lab

2. Presentation plan introduction Multi-Valued Dimensions
One-to-Many and many-to-many Relationships
Multi-Valued Dimensions
Multi-Valued Attributes
Summary

3. introduction
The real world is much more complex for modeling a process in a simple star schema
Some of the challenges that we might have :
Multi-valued dimensions occur when a fact table row may need to refer to more than one row in a dimension table.
Multi-valued attributes occur when a dimension row needs to capture multiple values for a single attribute.

4. introduction
The proposed solution for these two problems is introducing a new kind of tables called Bridge tables.
Bridge tables got pros and cons :
It provides the ultimate power and flexibility, enabling a wide variety of analytic possibilities.
increases the possibility that the schema can be misused, producing inaccurate results.

5. Standard One-to-Many Relationships
Every fact is related to exactly one instance value of each dimension.
Example: each order is related to exactly one product and each dimension value may be related to one or more fact table rows :

6. Many-to-Many Relationships
What happens when a fact may be related to one or more instances of a dimension?

7. Multi-Valued Dimensions
situations where a given fact may relate to one or more rows in a dimension table.
A multi-valued dimension does not fit with the established primary key–foreign key relationship between dimension table and fact table.
What if we place more than one key value in the fact table ?
An alternative is to bridge the relationship between fact table and dimension table with a special table “bridge table”

8. Multi-Valued Dimensions
Simplifying the relationship
deal with a multi-valued dimension is to decompose the many-to-many relationship into two or more one-to-many relationship (using rules from chapter 6)
For a given fact, each of the relationships will identify exactly one row in the dimension table.
order_facts can be designed with two salesrep_keys. One is designated as primary, the other as secondary.

9. Multi-Valued Dimensions
Simplifying the relationship
much more complicated, fixed number of relationships …
Want to total up order_dollars for a particular salesperson?
Want to list all salespeople along with the total order_dollars in which they were involved?

10. Multi-Valued Dimensions
Using a Bridge for Multi-Valued Dimensions
A group table contains a group_key and a foreign key column referring to the dimension in question.
A row is added for each group member.
The fact table and the bridge can be joined using the group_key.

11. Multi-Valued Dimensions
Using a Bridge for Multi-Valued Dimensions

12. Multi-Valued Dimensions
Bridges and Double-Counting
Using a Bridge for Multi-Valued Dimensions
What If you query orders by region ?
sometimes double-counting is actually a good thing ! (a report that shows order_dollars by salesperson).
it would be a serious error to take that information and produce a grand total.

13. Multi-Valued Dimensions
Bridges and Double-Counting
Using a Bridge for Multi-Valued Dimensions
The only safe way to construct an impact report is to group by a column in the dimension that will have a unique value for each member of the group. Most often, this will be the natural key.

14. Multi-Valued Dimensions
Bridges and Double-Counting
Using a Bridge for Multi-Valued Dimensions
What If we eliminate the many-to-many relationship between fact table and bridge by asserting that each group will be used only once.?
does not solve the problem because still in danger of being double-counted and the bridge table is likely to grow very large

15. Multi-Valued Dimensions
Adding an Allocation Factor
Using a Bridge for Multi-Valued Dimensions
selects the sum (order_dollars * allocation)

16. Multi-Valued Dimensions
Adding an Allocation Factor
Using a Bridge for Multi-Valued Dimensions
Double-counting can be avoided by adding an allocation to the bridge table and aggregating allocated facts. Ownership of allocation factors must rest with the business community, not the technical community. If a clean allocation factor exists, consider the possibility of changing the grain of the fact table instead.
it is possible to avoid bridging altogether. This is done by defining the grain of the fact table as “order lines allocated to salesreps.”
Some facts cannot be meaningfully allocated (selling 1 refrigerator by 2 salespersons)

17. Multi-Valued Dimensions
Supplementing the Bridge with a Primary Member
Using a Bridge for Multi-Valued Dimensions

18. Multi-Valued Dimensions
Other Impacts of Bridging
Using a Bridge for Multi-Valued Dimensions
Implications of Slow Changes:
If a bridged dimension row undergoes a type 1 change, it will remain associated with any existing groups.
If a bridged dimension undergoes a type 2 change, a new group will be required the next time members collaborate.

19. Multi-Valued Dimensions
Resolving the Many-to-Many Relationship
Using a Bridge for Multi-Valued Dimensions
If you have a software product that will not allow a many-to- many relationship, you can create an intersect table to resolve it.

20. Multi-Valued Attributes
a small subset of the dimension’s attributes may take on more than one value for a single natural key value.

21. Multi-Valued Attributes
Simplifying the Multi-Valued Attribute
The solution is limited to a specific number of values.
Filtering a query for a particular industry will require defining multiple conditions, since the industry in question may appear in any one of the columns.
Grouping facts by industry will be particularly challenging, since a given industry may appear in any of the three columns.

22. Multi-Valued Attributes
Using an Attribute Bridge
the bridge will be placed between the dimension table and an outrigger

23. Multi-Valued Attributes
Double-Counting
Using an Attribute Bridge
This situation is sometimes called for but is also dangerous.

24. Multi-Valued Attributes
Double-Counting
Using an Attribute Bridge
the RDBMS will repeat the $10,000 order for each related industry.
Suppose Company placed a $10,000 order that appears in the order_facts table
grand total ?

25. Multi-Valued Attributes
Double-Counting
Using an Attribute Bridge
When an attribute bridge is employed, any query involving the outrigger risks the possibility of double-counting. This risk can be minimized by using a flag to isolate a single member for each group; this can be used to constrain the view of the schema presented to inexperienced users.

26. Multi-Valued Attributes
The Impact of Changes
Using an Attribute Bridge
Type 2 changes in an outrigger will require type 2 changes in the dimension and new groups in the bridge table. These can also be supplemented with time stamps, if desired.
In cases where the history of changes to group membership is to be maintained, any change to a group will require creating a row in the dimension table that refers to the revised grouping.
In case of type-2 Changes to the Dimension the new “version” will have a new surrogate key. If the multi-valued attributes have not changed, the new row can reuse the same group_key .
When the outrigger is a group, try not to use the word “group” to describe the bridge. Doing so will lead to confusion.

27. Multi-Valued Attributes
Resolving the Many-to-Many Relationship
Using an Attribute Bridge
If you have a software product that will not allow a many-to- many relationship, you can create an intersect table to resolve it.

28. Summary
When a fact must refer to more than one instance of a dimension, it may be possible to simplify the many-to-many relationship into multiple one-to-many relationships, but its limited (fixed).
A bridge table allows a fact table row to be associated with any number of dimension rows, and keeps the reporting simple, but brings the risk of double-countings.
The presence of a bridge makes it necessary to think carefully about the implications of slow changes, not only to attributes but also to relationships.
Some tools identify bridge tables as fact tables because they carry multiple foreign keys. This is fine, but be sure that the tool does not decide to drill across.

29. Thank you
ANY QUESTIONS ?