Weak types are very useful in modeling
Opponent: Weak entity types allow a simple expression of dependence.
Proponent: You are right in your observation that weak entity and also weak relationship types are very convenient in the modeling process. If they are developed with consideration of all implications then you develop better and more compact diagrams.
Opponent: Thus, you need these types which cannot be expressed by other types in the classical ER model.
Proponent: Sorry, weak entity types may be considered as unary relationship types with cardinality (0,n). The identification of objects belonging to classes of weak types is composed of the identification of the referenced (entity) type and the the weak type (i.e. the unary relationship type). Thus, in this case you will have a simple expression and a well founded expression at the same time. If you use weak typing then you might fall into traps.
Opponent: Are there any?
Proponent: Yes, there are traps called connection trap, fan-out-trap. These traps have been observed at the time people actively applied references or inclusion constraints. These traps are caused by identification problems. If we want to manipulate or access single objects in a database (e.g. change an attribute value, delete THIS object, query THIS object) then we need to have an identification. And this identification must be unique.
Opponent: Oh, this reminds me that we should introduce the object identifier as the object-oriented database community did.
Proponent: Yes, the object identifier notion is essentially the same as the surrogate which might be hidden from the user and manipulated and accessed by the system. By the way, typical RDBMS have already object identifiers. They call it there "tuple identifier" . The identification extension of types is very useful. At the same time, the notion is TOO powerful. You may define database schemata which objects can be separated only by their identifiers but not from outside. Thus, users are not able to access and to manipulate object by object. They are able to perform a bulk update and a bulk access. And that is it. If there is no need in separation then you can live with that. But unfortunately, you might have non-identification when you did not want to have it.
It has been proven that whenever each object is weakly identifiable by a (may be rather complex) value expression then the database is well-designed.
But let us return to weak typing.
Opponent: You have claimed that weak typing leads to inconsistent databases. It seems to me that this is far too strong.
Proponent: During consultance I found a schema which consisted of two interleaved weak types. There were mutual dependent. And people were not able to apply usual database manipulation operations after the system has been set up. A simple variant of this schema is presented in the HERM book. I do not claim that that weak typing is useless. I even claim that it is very useful. But I must insist that the identification graph of weak entity types must be a tree. If this happens then there is no need in omitting weak types.
Opponent: Thus, let us include weak types into the model!
Proponent: No! The development of weak types needs more care. And developers must be careful in this case. Thus, let us force the designer to apply weak typing with care, i.e. let them develop weak types on the basis of extended relationship types which have an additional identification component beside the referenced (entity) type.
Opponent: But then it is similar to associating objects.
Proponent: Yes, this is correct.
Opponent: Tools allow weak typing!
Proponent: Yes, this is correct again. But look, for instance, how products such as ERWin or Silverrun treat weak types. they are there essentially (unary) relationship types with extended keys consisting of the key of the referenced type and of additional key attributes. Thus, they use weak typing in a correct fashion.
`Other related information you find in page':More readings