IS5413 Chap.3 Entity Types and Attributes in ER Modelling
Entity Types and Attributes in ER Modelling
Three constructs, and the type against instance trap
Entity relationship modelling has three constructs and the course states them plainly: an entity is something uniquely identifiable, a relationship is an association between entities, and an attribute is a property that defines either of them. The difficulty is not the three words.
Both of the first two come in a type flavour and an instance flavour, and questions are written to see whether you keep them apart. An entity type names a whole group of things described the same way and lands as a table; one member of that group lands as a row. A relationship type is the labelled line between two entity types; a relationship instance is one specific link between two specific records.
The published illustration counts ten relationship instances sitting behind one relationship type, and that ratio is the whole point of the distinction.
What is allowed to be an entity type
The published test has three positive conditions and two disqualifiers. An entity type should have many instances, should be composed of multiple attributes, and should be something the business needs to track.
It must not be somebody who uses the system, and must not be something the system produces. The two disqualifiers are the ones that catch people. A treasurer who reads the system is a user; an expense report the system prints is an output. Strip both from a model and what remains is an account and an expense, which are genuine data objects.
Applying this filter to every candidate noun in a narrative is the first deliverable of any design question, and it is done before a single box is drawn.
Strong, weak, and the identifying relationship
A strong entity type exists independently and has its own unique identifier.
A weak entity type has no unique identifier of its own and depends on an identifying owner, with the link between them called the identifying relationship. The published example is a dependent who cannot exist in the database without the employee carrying them: the dependent's partial identifier only becomes unique once the employee identifier is added.
Notation reflects this with a double lined box and a partial identifier underlined with dashes.
Deciding strong against weak is always a question about identification and never about how important the thing is to the business.
Four independent axes, and four identifier criteria
An attribute is classified on four axes that are decided separately: required or optional, simple or composite, single valued or multivalued, and stored or derived.
They are independent, so an attribute can be optional, composite and stored at the same time, and treating them as one four way choice loses marks. An identifier is then chosen against four criteria. It must not change, which rules out names, addresses and locations. It must always hold a value. It should carry no intelligence, because a key encoding a department or a site breaks when the business reorganises.
And it should be simple where it can be, with a long composite key usually better replaced by a surrogate created for the purpose.
What this chapter covers
- 01
Entity type against entity instance
- 02
Relationship type against relationship instance
- 03
The three positive tests and two disqualifiers
- 04
Strong entities, weak entities and identifying relationships
- 05
Required, composite, multivalued and derived attributes
- 06
The four criteria for a usable identifier
Worked example · free
Filter the nouns and classify the attributes
- 3Sort the nouns and justify each exclusion.
- 3Classify the auditorium attributes on all four axes.
- 2Choose an identifier for the auditorium and defend it.
Key terms
- Entity Instance
- One member of an entity type, landing as a single row in the eventual table. Contrast with the entity type, which is the whole collection.
- Weak Entity
- An entity type with no unique identifier of its own, dependent on an identifying owner and drawn with a double lined box and a dashed partial identifier.
- Identifying Relationship
- The link connecting a weak entity to the strong entity that identifies it. Without the owner, the weak entity cannot be uniquely picked out.
- Composite Attribute
- An attribute with meaningful component parts that are themselves attributes, such as an address made of street, city and postal code.
- Derived Attribute
- An attribute calculated from other stored values rather than held itself, shown in square brackets in the notation and deliberately kept out of the eventual table.
- Candidate Key
- Any attribute or combination that could serve as the identifier of an entity type. One of the candidates is chosen as the primary key.
- Surrogate Key
- A newly created identifier with no business meaning, substituted for a long or unstable natural key so that real world change does not force a key change.
Entity Types and Attributes in ER Modelling FAQ
How do I tell an entity type from an attribute?
Ask whether the thing has many instances and multiple properties the business cares about. Something with exactly one property of its own is usually an attribute of something else, and something the business describes with several facts is usually an entity type.
The honest answer is that borderline cases exist and both readings can be correct; what loses marks is choosing without saying so, since a stated assumption is credited and a silent one reads as an error.
Why is a report never an entity type?
Because a report is produced from data the system already holds, so modelling it would store the same facts twice and create a second version of the truth that nothing keeps in step. The published guidance disqualifies outputs of the system explicitly, alongside users of the system, and narratives often mention both precisely to see whether the filter is applied.
Exam move
Take three narratives from any source and do nothing but the noun sort on each: list every noun, mark it kept or dropped, and write one clause of justification. Then pick the richest entity type from each and classify every one of its attributes on all four axes, saying aloud why each axis was decided as it was. Finish by choosing an identifier and naming which of the four criteria your first instinct would have violated.
Working through Entity Types and Attributes in ER Modelling in IS5413? Sia is AskSia’s AI Information Technology tutor — ask any IS5413 Entity Types and Attributes in ER Modelling question and get a clear, step-by-step explanation grounded in how IS5413 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
