ISYS1055 Chap.3 ER Modelling in UML Notation: Entities and Multiplicity
ER Modelling in UML Notation: Entities and Multiplicity
Week 3 opens the design half of ISYS1055. Entity-relationship modelling is taught as a top-down, deliberately non-technical language for describing data - entities first, then relationships, then attributes, then the constraints on those relationships - so that a model can be discussed with a client and still translate cleanly into relations. The stated outcome names the notation explicitly: a diagrammatic technique for displaying an ER model using UML. That matters for marks, because the lectorial labels its own diagrams "our preferred notation" and the diagrams you draw in LucidChart for Task 1 of Assessment Task 1 are marked against UML class-style boxes with {PK} tags and min .. max multiplicity, not against Chen diamonds or Crow's Foot.
What this chapter covers
- 01Where ER modelling sits: requirements analysis → conceptual (ER) model → relational database model; why it is top-down
- 02The course's notation ruling - UML class-style boxes, {PK} and {Partial Key} tags, multiplicity written as min .. max; Chen, Crow's Foot, Barker and Information Engineering are surveyed for comparison only
- 03Entity type vs entity occurrence; physical existence (vehicle, employee, product) vs conceptual existence (inspection, transaction, maintenance job)
- 04Strong vs weak entity types: a weak entity has no key of its own, only a partial key, and always participates mandatorily in its identifying association
- 05Attribute kinds: simple, composite (split into components), multi-valued (written with a range such as [1..N]), derived, key, and attributes that belong to the relationship rather than to either participant
- 06Relationship degree: unary/recursive, binary (the common case), ternary, quaternary; and the fact that two entity types can be joined by more than one relationship
- 07Multiplicity = cardinality (the maximums: 1:1, 1:N, M:N) + participation (the minimums: 0 optional, 1 mandatory), both taken from business rules and never from sample data
- 08Extra UML constructs: aggregation (hollow diamond), composition (filled diamond), and self-association with role names at each end
Turn four business rules into a UML model with multiplicity at both ends
- +1Identify the entity types and their keys, then the associations. Three entities: Gardener(gardenerID {PK}, fullName, joinDate), Plot(plotNo {PK}, sizeSqm, soilType) and WorkingBee(beeID {PK}, focus, heldOn). Two associations, both binary (degree 2): Leases between Gardener and Plot, and JoinsIn between Gardener and WorkingBee. Each is drawn as a labelled line between two class-style boxes.
- +1Fix the cardinality of Leases from the maximums in the rules. Rule 1 caps a plot at one gardener; rule 2 allows a gardener many plots. Maximums 1 and many, so Leases is one-to-many (1:N) with Gardener on the "one" side.
- +1Fix the participation of Leases from the minimums. Rule 1 says every plot must be leased, so at the Gardener end the multiplicity is 1 .. 1 - each plot relates to exactly one gardener, which is mandatory (total) participation for Plot. Rule 2 says a gardener may currently lease none, so at the Plot end it is 0 .. * - optional (partial) participation for Gardener. Written out: Gardener 1 .. 1 - Leases - 0 .. * Plot. Read it back in both directions before you commit to it: "one plot is leased by exactly one gardener" and "one gardener leases zero or more plots".
- +1Now JoinsIn. Rule 3 gives many on both sides, so the cardinality is many-to-many (M:N). Rule 4 makes a working bee's participation optional, and nothing forces a gardener to join one, so both minimums are zero: Gardener 0 .. * - JoinsIn - 0 .. * WorkingBee. If the committee later wants to record the hours each volunteer contributed, that fact belongs to the association itself, which in UML is carried by an association class rather than by either entity box.
Key terms
- Entity type vs entity occurrence
- An entity type is a group of real-world objects with the same properties (Gardener); an entity occurrence or instance is one member of that group. Entities may have physical existence (vehicle, employee, product) or conceptual existence (an inspection, a purchase transaction, a maintenance job).
- Weak entity and partial key
- An entity type that cannot be identified on its own and depends on an owner entity for its identity. It carries only a partial key, tagged {Partial Key}, which is unique within the owner rather than globally; the association to the owner is the identifying relationship, and the weak entity always participates in it mandatorily.
- Composite and multi-valued attributes
- A composite attribute is made of components each meaningful on its own (an address split into street, suburb and postcode); a multi-valued attribute holds several values for one occurrence and is written with a range, e.g. locations[1..N]. Both are handled by specific steps of the seven-step mapping later.
- Degree of a relationship
- The number of participating entity types: unary or recursive (both ends the same entity type), binary (two - the usual case), ternary (three) and quaternary (four). Two entity types may also be joined by more than one distinct relationship, which must be modelled separately.
- Cardinality
- The maximums of a multiplicity pair: how many occurrences of one entity may be associated through the relationship. The three common forms are one-to-one, one-to-many and many-to-many.
- Participation
- The minimums of a multiplicity pair: whether all or only some occurrences take part. Minimum 1 is mandatory (total) participation; minimum 0 is optional (partial). Participation is what decides the direction of a 1:1 mapping in Week 4, so it is worth marks twice.
ER Modelling in UML Notation: Entities and Multiplicity FAQ
Which ER notation does ISYS1055 mark against?
UML. The lecture material surveys Chen, Crow's Foot, Barker's and Information Engineering notations so you can recognise them in the wild, but the course labels its own diagrams as its preferred notation and the Week 3 outcome names UML explicitly: class-style entity boxes with attributes listed underneath, {PK} on the key attribute, {Partial Key} on a weak entity's identifier, and multiplicity written as min .. max at each end. Diagrams are drawn in LucidChart, which is free with an RMIT academic account. Submitting Chen diamonds is a notation error, not a style preference.
How do I read a multiplicity pair correctly?
The multiplicity written at an association end counts how many occurrences of that entity relate to one occurrence of the entity at the other end. So in Gardener 1 .. 1 - Leases - 0 .. * Plot, the 1 .. 1 beside Gardener says each plot has exactly one gardener, and the 0 .. * beside Plot says each gardener has zero or more plots. Always translate the pair back into two plain-English sentences and check both against the business rules before you draw it.
Where do multiplicity and participation actually come from?
From business rules extracted from the client, not from the data you happen to have seen. "Are all members assigned to a group? Can a project have no staff yet?" are questions to ask, and each answer fixes one minimum or maximum. A model built by reading sample rows will encode accidents of the current data as permanent constraints.
Can an attribute belong to the relationship rather than to an entity?
Yes, and it is a common source of marks. A grade belongs to the enrolment of a student in a course, not to the student and not to the course; in UML it is carried by an association class, which holds the relationship's attributes and has no primary key of its own. When that association is many-to-many, the attribute lands in the link relation created by the mapping step in Week 4.
Assessment move
Build your own reusable UML shape library in LucidChart in the first practical of this block - entity box, {PK} tag, association line, multiplicity labels - so you are modelling rather than formatting when the assignment lands. Then practise the only sequence that matters: read a scenario, list candidate entities, strike out the ones that are really attributes, name the associations, and write the multiplicity pair last, saying both directions out loud. Do this on three or four short scenarios rather than one long one; quiz 2 falls in your Week 5 practical and covers exactly this material, and Task 1 of Assessment Task 1 is one scenario drawn under the same rules. Keep a note of every business rule you had to assume - the assignment rewards stating assumptions, and the Course Guide is the place to check what the task expects of you.
Working through ER Modelling in UML Notation: Entities and Multiplicity in ISYS1055? Sia is AskSia’s AI Information Technology tutor — ask any ISYS1055 ER Modelling in UML Notation: Entities and Multiplicity question and get a clear, step-by-step explanation grounded in how ISYS1055 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
