Chasm Trap (Cardinality Trap)

When two tables are related by way of a higher-level table (representing a “compression”), information returned by queries on these tables can be misleading. This problem of a higher-level join is known as the “chasm trap.”

For example, a “Customer” table is related to a “Product” table to record products ordered by a customer. The same “Customer” table is also related to support case “Issue” table that records the product issues reported by the customer.

This physical view presents the appearance that it is possible to view issues by product. However, because the “Product” table and “Issue” table are linked through a higher-level table (“Customer”) that preserves only individual customers, this is in fact not possible. Through these particular joins, each product a customer purchased is associated with all issues this customer raised – regardless of the particular product.

This trap is readily identifiable by the combination of n:1 and 1:n join cardinalities. If you require “issue by product” data, you can enhance the physical view by relating the “Issue” table directly to the “Product” table, and resolving the resulting loop with a weak join. (See Resolving Loop Traps.) Otherwise, you should isolate the two relationships in two separate physical views. You can still combine the two views by building the desired Data Block within a Data Mashup.

<< Fan Trap © 1996-2013 InetSoft Technology Corporation (v11.4) 4.3.4 Extending a Physical View >>