Entity Modelling

www.entitymodelling.org - entity modelling introduced from first principles - relational database design theory and practice - dependent type theory


Attributes As Data Slots in Messages

As stored within information systems then the individually represented items the names, colours, quantities, the monetary amounts, the dates, etc in the language of entity modelling, are said to be the values of attributes. Thus an actual name like "John Smith" is said to the value of a ‘name’ attribute of a ‘person’ entity. We may express that information about a person is communicated or stored as message with two components name and data of birth we write

person => name,
data of birth
or otherwise we might say that a ‘person’ entity may be attributed a ‘name’ and a ‘date of birth’ on show an entity model diagram representing type ‘person’ with ‘name’ and ‘date of birth’ attribute annotations, like this:

Alternatively to say that date of birth is optional we may add a question mark like so

person => name,
data of birth?
or on a diagram we may use a circle in place of the square:
To show that the name attribute within a message is the identifying attribute we underline the annotation in the diagram:
or, equivalently, in the message structure:
person => name,
data of birth
If it is nessary to give both a person's name and their data of birth to uniquely identify them then we underline both of these attributes on the diagram:
Generally, systems will hold and communicate many different attributes of each type of entity and these attributes are shown beneath the identifying attributes:

It is clear that computer programs are effective only in so long as the data items they manipulate are intended and understood as attributes of subject entities. It follows that to have an effective information system we must first have agreed types of subject entity and also what may be attributed to entities of these types. In this agreement we agree the data content of the program or system i.e. its subject matter.

In a message about a person two or more phone numbers may be communicated. This is shown like this:

person => name,
data of birth,
phone number*

It is a rule of entity modelling that for a single attribute an entity may only be attributed a single value. For this reason if a person can have multiple phone numbers then ‘phone_number’ is not an attribute of a ‘person’ entity type per se but an attribute of a ‘phone’ entity type that stands in relation to (is owned by) the ‘person’ entity:

The existence and ownership of particular phone numbers may be communicated or stored independently in which case they have the message structure:

particular_phone_number => phone number,
name
The world as a whole now is communicated as :
world => person*,
particular_phone_number*
person => name,
data of birth
particular_phone_number => phone number,
name
(10)

This world view given by the message scheme ( 10 ) is an example of a relational schema. In summary, we have two possible ways of describing the world view in messages, the relational one ( 10 ) and the hierarchic 1 one shown in full in ( 11 ).

world => person*
person => name,
data of birth,
phone number*
(11)


1 In this context, the term hierarchical and the term relational are generally used as contrasting terms but in actual fact a relational schema can be seen to be a special case of a hierarchical schema one in which the hierarchical structure is minimised.