Relationship types using relationship types as their components are non-sense
Opponent: Relationship types defined over relationship types will be not used at all.
Proponent: Sorry let us take again the linguistics experience. People may be able to talk in SPO sentences and not using anythin else. But then it is awful to express more complex associations. Take, for instance once more the screenplay WITNESS by EARL W. WALLACE, WILLIAM KELLEY from a story by WILLIAM KELLEY your find find the following title sequence describing the situation:
The faces of several young children are presented in CLOSEUP, as they walk TOWARD US across a ploughed field.
Are you able to express this via binary associations without using object identifiers and artificial integrity constraints? The answer is yes. But you face the problem that instead of one sentence you need five (!) SPO sentences with rather complex reference relationships among the objects and subjects in the sentences. If you want then please use this. The price is a bad slowdown of the system and is a bad update behavior.
Opponent: You have made the claim that higher order relationship types make modeling simpler.
Proponent: This is true. Let us take the example in the ER book in the references. You may model the attendance of students in courses by modeling this explicitly via a relationship type with the components Teacher, Course, Term, Student, Result. But there you have to impose a severe restriction: A student may attend a lecture only of this lecture is given in reality in the university, i.e. you have a referential inclusion constraint to the Lecture relationship type stating that the triple (Teacher,Course,Term) in Attendance is a subset of the triple (Teacher,Course,Term) in ScheduledCourses.
Another observation is again the sentence structure used in natural languages. Each sentence may be extended by subsentences and so on. This structure may form a rather complex tree but is at the same time very easy to capture. To write such sentences require a lot of intellectual effort. But this effort give you the pleasure of reading.
People engaged in the writing business claim that sentences with subsentences have a lot of advantages:
1) You are able to express complex associations in a much simpler form.
2) You may be able to apply techniques of browsing by cutting out all subsentences during browsing. In this case you will not loose the track. You are able to capture the content of the database in a quick but non-dirty form of reading.
3) You are able to cluster associations together. Clustering is a very useful technique in all sciences whenever a basic fact is not possible to decompose into simpler basic facts without using abstractions.
Thus, the reduction rate in writing is 3 to 4. I.e. instead of having a very complex schema with a lot of associations among types and components you will have a much simpler schema. And this schema is easier to read, faster to capture, easier to abstract and to survey.
I believe that this reduction rate is valid in database modeling as well. SAP R/3 is using more than 70 relations for storing addresses in parallel. This redundancy increases maintenance costs. Sometimes the system does not respond for hours due to the heavy and unnecessary update. If they would have been used other approaches they could have only 6 (six!) relations expressing the same information with a hierarchic update tree. In this case update, insertion and deletion is simple to maintain.
Another bad observation is of course that you need to know modeling techniques.
Opponent: But in this case I would have to learn modeling techniques. This would require a lot of efforts form me.
Proponent: Yes, there is a simple rule in life. Anything what is complex in reality will remain to be complex. All the examples we are using for teaching and discussing design are rather simplistic and toy examples. Such toy examples are not the reality. In reality a schema may have around 100 entity types, some hundreds of relationship types and more than thousand different attributes (or at least different versions of attributes). Such applications are often met in real life. ERP applications tend to have more than ten thousand attribute, entity and relationship types. Without good modeling techniques you wont be able to maintain simplicity. For instance, SAP R/3 was based on about 16.500 relations in May 1999. After adding the internet facilities another 4.000 relations have been added to the schema without any additional data storage requirements. They only were not able to derive equivalence of concepts and to reduce complexity by including concepts into other concepts. With the development of the e-business components the size is raising again.
Opponent: But we could use CASE tools instead of that. Let them develop all the necessary associations.
Proponent: Sorry, but how the CASE tool would know about the associations and would be able to prove the equivalence. CASE tools have another very severe restriction. They usually derive their normalization of the schema introduced.
Opponent: How many different normalizations I would obtain by CASE tools?
Proponent: CASE tools allow to generate one normalization out of the schema. Some of them have some simple choice options. You may make a little experience. Develop a schema in a different order. Then the obtained normalization may be different. This strange behavior is due to the deterministic behavior of CASE tools. You generate deterministically the normalization depending on the order of the attributes introduced and of the order of the entity and relationship types.
However, theoretical investigations have shown that for n attributes they may be potentially exponential many different 3NF generated out of the given system of types and functional dependencies.
Opponent: Another problem I would like to discuss is the problem of reduction.
Proponent: Let us look into reality. The reduction rate of 3 to 4 cannot be achieved in any CASE. But we analyzed the failure of a Lufthansa Cargo project.
Opponent: I observed while working with tools such as Silverrun that dependent types have the same representation as relationship types. Translating such schema leads to a relational schema which is almost the same as the ER schema. If I use DBMain then relationship types are condensed or embedded into relational types. In this case, the ER schema is even more complex.
Proponent: Yes this is true! Relational representation of applications is based on multilayering. Observe for instance the trees of referential integrity in applications. You may have a large depth because of the tight relationship among the types. Thus, I ask you why you need to develop a schema in theory which is anyway better in the logical description.
Opponent: Your observation on Silverrun and DBMain can be extended to other CASE tools as well.
Proponent: CASE tools are using typing over types a long time already. But the research community has not taken this into consideration.
`Other related information you find in page':More readings