Overview of modelling

The production of an E-R diagram is the result of modelling the data requirements for a given situation. The principle constructs used within an E-R Diagram are the entity types, their attributes and their relationships. A further requirement may be any assumptions or constraints placed upon the data.

Entity types

Defined in block 1 as:

An entity represents a thing that has meaning in a given context and about which there is a need to record data.

The thing could be anything about which we need to record data. However, there could be many attributes associated with our thing, not all of them may need to be recorded. e.g. a vehicle fleet database may require information on a vehicle's size, load carrying capacity, tyre size, engine size and registration number. What it probably won't require is information about the number of its wheel nuts or the size of its glove box. The information that is needed to be recorded becomes the entity, and not the vehicle itself. The entity is determined by the data requirements. Our vehicle in this scenario has become the subject. Only relevant information about a subject is used to construct an entity.

An entity type is used to refer to a group/collection of entities that have common properties. As a modelling construct, our Vehicle Entity type will not be given in the data requirements. It has been inferred. Changing the requirements may introduce the need to classify different Vehicle Types. Large goods vehicles, buses, vans, cars, tankers etc. Providing they share the common properties they can remain of the the same entity type. Should the information needed be changed, it may require the definition of a different entity. Remember, it is the data that makes the entity, not the subject.

Relationships

In relationship modelling, it is the existence of connections between subjects, as opposed to the data involved, that is to be recorded. A connection exists between a vehicle and a driver, but there is no data involved in the connection. The connection itself is the relevant information. The importance of this connection is, that it cannot exist alone, there must be two subjects. There can be no connection involving only one subject on its own.

Where there are numerous instances of entity types, there will be corresponding numerous connections.

Relationships have names. They also have properties of degree, specifying how many connections exist, and participation conditions, specifying whether an occurrence of each entity type must have a connection.

A valid name for the relationship between Driver and Vehicle could be Drives. Straight forward! A Driver Drives a Vehicle. A Vehicle IsDrivenBy a Driver is also valid. However, the direction of the connection is usually expressed as being from one to many (1:n) as in the Drives example.

An E-R diagram shows a relationship as a connecting line between entity types. This does not mean that all occurrences are connected. Where all occurrences are not connected the relationship is described as optional as opposed to mandatory.

Nor is it possible to allow for a foreign key in a diagram. There would be duplication - connections between entities as relationships and as foreign keys. Relationships can be represented in the E-R diagram without knowledge of their attributes.

Although many to many (m:n) relationships can exist in E-R diagrams, they are relatively rare. It is preferable to have an entity type and two (1:n) relationships. Information can be better represented, it helps to prevent duplication of data and it may become necessary, in a future requirement, to include additional data (evolving database scenario).

Data requirements may not explicitly state the nature of a relationships participation. Assumptions may have to be made or further clarification sought. Where a m:n relationship is resolved to two 1:n, the general rule is that both resultant 1:n relationships would have mandatory participation. The degree and participation provide for the representation of constraints.

Comments, suggestions, ideas to
Stuart Banner