ER modeling is not rich enough
Opponent: There are hundreds of extensions to the original ER model. The reason for this large variety is the simplicity of the model. Which is may be too simplistic.
Proponent: There are several reasons for extensions of the original proposal made by Peter P. Chen. The original proposal is genius. It survived all the extensions. And also all extensions. Extensions are mainly made for convenience of representation especially in large applications.
Opponent: A large number of extensions has been made because of difficulties in modeling. These difficulties are due to problems in the ER model.
Proponent: You are right, most of the extensions are based on difficulties in representing complex applications. These difficulties are not difficulties within the ER model. "Complex problems remain to be complex" is a simple statement in the first book of Moses in the Holy Bible. Complexity can be reduced by localization abstraction, i.e. by figuring out repeating patterns. These repeating patterns are defined separately. Later we use the names of these patterns instead of the patterns itself. Mathematics has shown the usefulness of such approaches by introducing definitions and lemmas. We may use this too.
Complex repeating patterns are specialization, generalization, views, derived values, complex typing (e.g., list, powerset or bag constructors beyond the set and tuple constructors used for simple applications). Some of them are easy to attach to the ER model. Some of them are however deviltry. Derived attributes belong to the last. As long as derived attributes are strictly hierarchical nothing will happen. "Strictly hierarchical" includes however the consideration of constraints. In most cases, we are trapped with them. So let us restrict derived attributes to those which can be defined on the basis of views.
Opponent: One of the best extensions is the object identifier. This identifier allows to speed up application development. It allows a horse trip instead of moving step by step.
Proponent: Object identification is a very useful "horse". But it is a wild horse! OID's are considered to be generated by the system and are usually not manipulatable by the application directly. Object identifiers may lead to non-identifiability, to non-queryability and non-maintenability. The only possible way for utilization of object-identifier is weak value-identifiablity, i.e. representability of OID's through complex values (see our homepage part on object-identification). In the last case you will be on the safe side. But in this case, OID's are an implementation tool and nothing else!
Opponent: But we need for application systems a simple identification inside the engine!
Proponent: And we use such facilities anyway. The tuple identifier is one of the basic concepts in any DBMS implementation.
Opponent: But I have seen extensions coming up again and again.
Proponent: Well this is a lack in the scientific culture. People are restricted in their time, attention and education. They read some papers. sometimes the collection of papers is inappropriate. Sometimes the collection is restricted by believes of scientific schools. Some research groups cite only their classmates and friends, nobody else. If you study such papers you will have the impression that no other relevant idea has been appeared.
`Other related information you find in page':More readings