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:

On reflection, we can distinguish the attribute title as being particular to the book and the other two attributes as not particular but, within the message, serving to identifying other entities. These other attributes that are not primarily properties of the subject entity in and by itself but which are indicative of a relationship between the subject entity and other entities we shall say are reference attributes^1,2.

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:

We don't see all the possibilities in this single example but what we have done is to:

• number the reference relationships R1, R2 and so on,
• depict the reference attributes as non-core,
• for each reference attribute indicate, in parentheses, the reference relationship(s) it wholy or partly communicates³.

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.

and see that now we underline the author name attribute for now this is an identifying attribute of book messages.

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:

• the attribute symbol of entity type occurring element is changed to be a reference attribute — it makes reference to a chemical element,
• the attribute molar mass of entity type compound is changed to be a derived attribute; for its value can be calculated from weighted sum of relative atomic masses of occurring elements.

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: