www.entitymodelling.org - entity modelling introduced from first principles - relational database design theory and practice - dependent type theory
When we look at the cover of a book and read the title, the author and the publisher then we are looking at a message and within the message we see character strings that can be modelled as attributes of a book entity type like so:
Reference attributes are those attributes which appear in messages communicating entities and singly or taken multiply serve to identify entities other than the subject of the message. Reference attributes are significant because they model the way that relationships may be communicated in messages or, in the specific case, represented in databases. Understanding and modelling reference attributes is important because typically we form or aquire models working from given examples and these are represented to us in messages of various forms — all we have of entitites (i.e. the knowledge that we can have of them) is by way of messages and in these messages almost all we have of relationships is reference attributes.
Reference attributes are derived attributes which appear in messages with the purpose, wholy or partially, of communicating relationships. We use a Shlaer-Lang notation to document them in an entity model. In the case of the book entity type, to model author and publisher as reference attributes then we need introduce individual and publishing company entity types, say, and introduce reference relationships as shown here:
Now let us suppose that a book is uniquely identified by the combination of title and author and not just by its title alone. To document this in the entity model we show specify the author relationship by drawing a bar across the relationships line.
Earlier we gave examples of (i) a model of a molecular compound, its alses and its chemical formula and (ii) a model of chemical elements, their isotopes and allotropes. Because a chemical formula makes reference to chemical elements we can combine these models into a single model as shown in figure 6. In the combined model some attributes which were core in the contributing models are now derived:
We now come to a very important point — the topic is usually covered in database design courses and it is usually presented as a secondary step as a sort of correction; providing that we have document relationship scope then this does not need be from the outset. The question is how are redundant reference attributes avoided when designing message structutes for communication or storage of entitities. The answer is tthat we must take account of reference relationship scope at the outset.
Consider these two entity models which are different only in the reference attributes present on entity type student:
One or the other of these entity models is suitable in regard to messages communicating or storing student entitites dependening on whether or not a student is always assigned a professor within the same department as themselves. This is a question of scope. In other words is the triangle of relationships depicted a commuting triangle or not.
Previously, in section , we described how the scopes of reference relationships can be documented on entity modelling diagrams. Provided that we document these scopes then reference attributes are implicit i.e. can be algorithmically generated and therefore do not have to be included in the model. The following diagram with scope specified implicitly defines the right hand message structure from the two diagrams above: