ISYS2120 Chap.2 Entity Relationship Modelling
Entity Relationship Modelling
Entity Relationship Modelling turns statements about a domain into a technology-independent conceptual design. The chapter separates entity types from individual entities, then assigns simple, composite and multivalued attributes to the object they describe. Relationships add roles and their own attributes.
The central modelling work is bidirectional: for each participant, decide the maximum participation captured by a key constraint and the minimum participation captured by total participation. Weak entities, recursive relationships, ISA hierarchies and ternary relationships are treated as distinct modelling decisions rather than decorative diagram shapes.
Because the conceptual-model assignment and the examination reward justified constraints, the chapter closes with a validation loop that tests every identifier, relationship direction and apparently redundant connection against a concrete domain state.
What this chapter covers
- 01
Start from domain statements
- 02
Identify entity types by identity
- 03
Attach attributes to the right owner
- 04
Model relationships as facts
- 05
Read cardinality in both directions
- 06
Separate minimum participation
- 07
Use weak entities only when identity depends
- 08
Resolve recursive roles explicitly
- 09
Choose subtype constraints deliberately
- 10
Aggregate a work assignment before managing it
- 11
Validate models with counterexamples
- 12
Explain every modelling decision
Map a weak session entity
- +1Choose FitnessClass as the owning entity type with class_code as its key. Session depends on that owner for identification.
- +1Use session_no as Session's discriminator, not as a globally unique key, because numbering restarts for each class.
- +1Map Session to class_code, session_no and start_time; class_code is both an owner reference and part of the composite primary key.
- +1Populate the two stated sessions and check that another class could also have session_no 1 without an identity collision.
Key terms
- Requirements
- Statements from stakeholders about the information a system must retain and the business rules that valid data must obey. They are the input to conceptual design.
- Conceptual model
- A technology-independent account of relevant domain objects, their properties, connections and constraints.
- Constraint
- A rule limiting valid domain states. Identifiers, maximum participation and minimum participation capture different constraints.
- Entity type
- A collection of distinguishable entities that share common properties, represented by a rectangle in the unit's ER notation.
- Entity
- A distinguishable person, place, object, event or concept about which the database needs to retain information.
- Key
- A minimal attribute or combination of attributes that distinguishes every entity in an entity type.
- Attribute
- A property describing one aspect of an entity type or relationship type, drawn as an ellipse in the unit's notation.
- Composite attribute
- An attribute whose value has meaningful component parts, such as an address divided into house number, street and suburb.
- Multivalued attribute
- An attribute for which one entity can have several values, such as a person's collection of hobbies.
- Relationship type
- A set of similar connections among entities from specified entity types. It may have attributes and explicit role names of its own.
- Total participation
- A minimum-participation constraint requiring every entity in a participant type to occur in at least one relationship instance.
- Weak entity
- An entity type whose instances are identified by combining a local discriminator with the key of an owning entity.
Entity Relationship Modelling FAQ
How do I decide whether a domain noun is an entity type?
Ask whether instances need independent identity and participate in facts the system must retain. Some nouns are attributes, roles or events instead. A useful entity type has a defensible key and a clear persistence requirement.
What do cardinality symbols say in an ER diagram?
Maximum cardinality limits how many counterparts an instance may have, while minimum participation says whether participation is optional or required. Read the relationship in both directions and translate each end into a plain-language rule.
When is a weak entity the right modelling choice?
Use a weak entity when its identity depends on an owning entity plus a partial key, such as an inspection number within one vehicle. Few attributes or business importance alone do not make an entity weak.
Why can a ternary relationship resist binary decomposition?
The unit's aggregation example binds an Employee, Job and Branch in one work assignment, then associates that combination with a Manager. Separate binary links can lose which manager belongs to which employee-job-branch combination or admit combinations that never occurred. Test the decomposition with counterexamples.
How can I validate a conceptual model before mapping it?
Narrate valid and invalid domain stories against every identity, participation, cardinality and subtype rule. Mark assumptions that requirements leave open. A model is defensible when each symbol preserves a stated fact and rejects the intended counterexample.
Exam move
Start every modelling drill from a short domain paragraph, not from an empty diagram. Circle candidate entity nouns, underline descriptive attributes and box relationship verbs, then challenge each choice: does it have an identity, does the system retain information about it, and is the proposed attribute really another entity's identifier?
For every relationship, ask the maximum and minimum question in both directions before drawing arrows or thick lines. Test the diagram with tiny legal and illegal populations; a single counterexample often exposes a reversed key constraint. Practise weak entities, recursive roles, ternary facts and ISA hierarchies separately because each has a different identity problem.
For the conceptual-model assignment, keep a requirement-to-symbol ledger so every line is justified. For the examination, redraw without software and narrate what each mark means in domain language. Finish by removing any relationship that is deducible from others unless the requirements demand that fact independently.
Working through Entity Relationship Modelling in ISYS2120? Sia is AskSia’s AI Information Technology tutor — ask any ISYS2120 Entity Relationship Modelling question and get a clear, step-by-step explanation grounded in how ISYS2120 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
