This document is designed to assist with viewing the model and runs through the different types of relationships between entities and the key things to look out for.
PRIMARY KEYS
Each entity within the model has a primary key This allows the entity to be uniquely identified within a provider's submitted data. In some cases, this will be one field, in others it may be made up of more than one field.
Within the data model, each entity is split in two with the field or fields that are part of the primary key appearing above the line.
For the Qualification entity, the primary key is the Qualification identifier (QUALID) as it appears above the line. The QUALID returned for each Qualification must therefore be unique within a provider so it can be used to identify any individual Qualification.
The other fields in the entity are displayed below the line in alphabetical order, including any derived fields.
FOREIGN KEYS
Whenever the primary key of an entity appears on a different entity, it is referred to as a foreign key. This allows two entities to be linked together with the unique keys.
Foreign keys will appear in either blue or red depending on whether these are part of the primary key of the entity on which they appear.
In the above example, QUALID appears as a foreign key on both the Qualification subject and Qualification awarded entities.
A Qualification subject entity cannot be uniquely identified in a provider's submission outside of the context of the associated Qualification as different Qualifications can have the same subjects. The QUALID is therefore part of the primary key for the Qualification subject entity and appears in red.
A Qualification awarded entity can be uniquely identified in a provider's submission outside of the context of the associated Qualification as each Qualification awarded entity has its own unique identifier. The QUALID is therefore not part of the primary key for the Qualification awarded entity and appears in blue.
All foreign keys appear in the data model, foreign keys that need to be submitted are listed in the data dictionary.
IDENTIFYING AND NON-IDENTIFYING RELATIONSHIPS
The relationships between entities on the model are displayed as either solid or dashed lines. These indicate whether the relationship is identifying or non-identifying.
Where the relationship is identifying, one entity cannot exist without the other.
Where the relationship is non-identifying, the entities can exist and be identified individually.
In the above example, the relationship between Qualification and Qualification subject is identifying as the line displays as solid. The Qualification subject entity also has curved corners to indicate the identifying relationship. The relationship between Qualification and Qualification awarded is dashed (and the entity has sharp corners) and so the relationship is non-identifying.
In this example, there are two fields above the dividing line on the Qualification subject entity, one of which is the QUALID. The primary key for the Qualification subject therefore includes the QUALID meaning the
Qualification is required to identify an individual Qualification subject entity and the relationship is identifying.
The primary key for the Qualification awarded entity is the Qualification awarded identifier. This is the unique key for each Qualification awarded and so the QUALID is not required to identify a Qualification awarded. This means the relationship is non-identifying.
ONE TO MANY RELATIONSHIPS
The relationships between entities in the model also give you information regarding the number of times an entity can be returned.
OPTIONAL AND MANDATORY RELATIONSHIPS
The relationships on the model indicate whether an entity is mandatory or optional. In this context optional means that the entity may only be required under certain circumstances.
