www.entitymodelling.org - entity modelling introduced from first principles - relational database design theory and practice - dependent type theory
Data representations are described by physical ER models as discussed in the earlier perspective: data modelling; a physical ER model is an ER model which includes for each relationship a means of representing it in data.
Previously (in the foundations of data section) we introduced the idea that databases are message systems1 and that specifying a data structure is specifying a system of messages. According to this view there are a number of types of subject entity and there is hierarchy of messages, each of them describing a subject entity; furthermore there are different types of message corresponding to the different types of subject entity and each type determines:
Relationships are represented either by message context or by explicit message attributes or by a combination of the two. Models that prescribe message representations in all or in part having a reliance on context are called hierarchical. Those that do not place a reliance on message context are called relational2. The ER model shown in figure 1 is a physical model because the model includes a specification of how each relationship is to be represented. It is relational because none of these representations have a reliance on context.
In a relational model relationships are represented by attribute For instance, In this example:
Let us add a further entity type 'C' to our example and a further relationship c: B⋺━C
then the appropriate relational model will be like this:
A more general situation regards types of entity that are identified by attributes only within the context of one or more relationships with other entities. Figure 2 is a case in point.
In a hierarchical data representation another possibility is available for it is possible to represent the relationship between B and A by nesting data for B's within data for related A's. With this choice of data representation this is the hierarchical physical model:
We can represent the nested hierarchical data representation textually like this:
B(name) A(name,B*)
This is an abbreviated form of what may be used to represent a document structure in a DTD: the former i.e. relational, may be represented in a DTD like this:
ELEMENT A(name) ELEMENT name CDATA ELEMENT B(name,aname) ELEMENT aname CDATA
ELEMENT A(name, B*) ELEMENT name CDATA ELEMENT B(name) ELEMENT aname CDATA
In the first case the xpath expression to navigate from a B element to its related A element is:
//A[name=current()/aname]
..
When we consider possibilities for a hierarchical data representation then we note that the entity type B is potentially represented as a child of A or as a child of C.
The hierarchical physical model, following our feeling that B is a child of A is like this: