Problems related to cardinality constraints

Lookup notation is better than participation notion

Opponent: Lookup notation is more useful and easier to understand.

Proponent: Could you explain why.

Opponent: Well, I am looking through the relationship type and then I see what is the number of associated types.

Proponent: But what if the type is is ternary or even n-ary.

Opponent: Well Teorey made a good proposal to color the relationship type with the non-validity of uniqueness.

Proponent: Sorry, but then you will face problems whenever you may have more than three components. and the coloring schema is also very difficult to understand. The better notion is the participation constraint, i.e., to take the relationship type and then to look how many associated relationships you will have whenever you keep one object in the component class.

Opponent: Lookup notation seems to be better understandable.

Proponent: Well you may be right to a certain extend. Let us consider a relationship type with four components A,B,C,D. Then we might observe the various cardinality constraints. These constraints can be expressed via cardinality constraints in the HERM notation or via functional dependencies between the component types of the relationship type and referential constraints between the component types and the relationship types. The relationship is given on the basis of the following table:

In the table above we use the first column to denote the component type to which the lookup constraint is attached, the second column describes the lookup constraint. The third column denotes the HERM cardinality constraint notation. The fourth column specifies the functional dependency which is valid for the relationship type. The fifth column denotes the corresponding inclusion constraint. For instance, the last line states that each combination of each object occurring in the component sets for A, B and C must occur in the relationship set.

We observe that intermixture of the directions. Lookup notation is applied to the type we are looking to.

Thus lookup constraints combine functional dependencies which are weak (all except one component against the one component) and inclusion constraints which are very strong (ANY combination of all except one component must appear in the relationship set).

Opponent: But the last argument is valid too for participation notation. They are also rather artificial.

Proponent: Let us look onto the example above again. We will use for participation notation the ordinary parentheses instead of the square brackets which are used for lookup notation. You observe the differences in the two tables. The table above relations all except one to the one component. The table below relates one component to the rest.

In some cases, this might be too strong. However, we do not require that all cardinality constraints are added to the diagrams. If we add all valid cardinality constraints to the schema then the schema will be far too complex and becomes unsurveyable.

Opponent: But often only the weakest functional dependencies are valid. Thus, we might better use the weak inclusion constraints and the weak functional dependencies.

Proponent: Then please use the HERM notation via cardinality constraints card(exp1, exp2) which relate the sets corresponding to expression exp1 to the sets corresponding to expression exp2. In the HERM model we decided to require that exp2 is a subexpression of exp1. This restriction can be weakened. However, experiments within the database design workbenches we developed have shown that weakening leads to confusion. Thus let us better stay with the restriction that exp2 is a subexpression of exp1. As a default, we abbreviate in this case R[ABCD] by R.