Higher-order types are too abstract
Opponent: We cannot find real natural examples for higher-order types.
Proponent: Let us use an example which has been used for demonstration of failure of the ER model. In one of the exciting database design books I found an example for a vinery database. Information on cultivation areas, sites, vintages, vintagers, grape kinds are considered to be the base information. This information is used for constructing the more complex objects such as grape kinds of the cultivation area, grape charges, mix of charges and vine. Additionally we need information on the co-operative societies, vine trades. In the database design book a discussion section has been devoted to the failure of the ER model. The complexity in this application comes from the component-wise construction of the associations. Vine is a complex object which is depends on the mix of charges. Charges are dependent on the grape juice. Grape juices are classified by the sit(S)e, the grape kind (K), the vintage (V), and the vintages (W). So, the complexity of associations leads to an overwhelming complex combinatorics. If we look onto the grape juice construction then we observe that not any combination is possible. Thus, instead of the 4-ary relationship type we may introduce four ternay relationship types:
KSV (displaying the relationship between grape kinds, vintages and sites),
KSW (representing the association among vintagers, sites and grape kinds),
KVW (representing the association among vintages, vintagers and grape kinds),
SVW (displaying the combination of sites, vintages and vintagers).
We observe further that KLV is based on VL and KL relationship types and KV is superfluous component in the KLV type.
The association SVW itself is based again on an association between SV, SW and VW. Thus, the complexity is rather complex.
If we use the classical ER model without higher order types we must develop almost all types as entity types and must add their associations additionally. Thus we obtain the entity types:
GRAPE_KIND, VINTAGE, CULTIVATION AREA, SITE; GRAPE_JUICE, CHARGE, VINTAGE, CO_OPERATIVE_SOCIETY, MIX_OF_CHARGES, VINE, WINE_TRADER.
Natural relationship types are: GRAPE_VINTAGE _OF CULTIVATION AREA, SYNONYM_OF_GRAPE KIND, AREA (between CULTIVATION_AREA and SITE), TRADES (between VINE and WINE_TRADER).
Furthermore we must use unnatural and unnecessary binary relationships between GRAPE_JUICE and respectively GRAPE_KIND, CHARGE, VINTAGE and SITE.
Also, the construction of charges and mix of charges lead to binary relationship types.
All this is superfluous.
Opponent: Why this is superfluous? I know that any representation language has its merits and disadvantages. Arab language is more compact than English which is again more compact than German. Thus, there will we no complete translation among them.
Proponent: Let me be more precise. A type in a conceptual database schema is superfluous if this type does not have a direct counterpart in the logical database schema For instance, the relational database model allows complex keys which consist of referencing components. We might loose the unnatural relationship types by representing them via referential integrity constraints. This happens with the constructing components in CHARGE, MIX_OF_CHARGES, VINE. This is also true for GRAPE_JUICE. But in this case we have types which use identifying components of other types as their components. Thus, we might better use directly the construction mechanism, i.e. higher-order relationship types. In the example above we have in the classical schema 25 entity and relationship types. If we decide to use higher-order relationship types we will have 15 entity and relationship types. The logical schema in the relational model has the same number of relational types.
Opponent: Let me discuss based on your example another discharming observation. If we look onto this example then the data stored in the database come in waves. First we know the cultivation area. Only after that we define vintagers. The same inclusion direction is observed for cultivation area, area and site. Also, vine is composed step by step. Why we should not represent such stepwise construction similarly to the network model?
Proponent: Your argument is based on a correct observation. In the last example, CULTIVATION_AREA is required for characterization of AREA. SITE requires AREA. GRAPE, GRAPE_KIND and VINTAGE are used for constructing objects such as GRAPE_VINTAGE_OF_CULTIVATION_AREA. So, we may restrict insertion of objects of type SITE to such which are related to an AREA object and correspondingly to an object of CULTIVATION_AREA.
The proposed extended entity-relationship model allows this kind of insertion restriction.