Peter Chen presented the entity-relationship model at the first VLDB conference in September 1975 and published it in ACM Transactions on Database Systems in March 1976. His diagrams write 1 and N looking across the diamond: the number beside an entity says how many of that entity meet one instance of the other. A department with many employees gets its 1 next to Department and its N next to Employee — the opposite places from the pairs of the papers. Both conventions are still in use (background, not from the slides).
The ER alphabet of the exam
After this lesson you will read any diagram of a past paper aloud: each (min,max) pair from the side it stands on, each pair of ISA letters, each underline — and you will know what its legend leaves out.
The exam of 13 June 2025 opens with a diagram in which a diamond named Compose joins Orchestra and Musician. Next to Orchestra it prints (10,N); next to Musician, (1,2).
Read the two pairs one way and you get what any concert-goer expects: an orchestra has at least ten musicians, and a musician plays in one or two orchestras. Read them the other way and you get a world of duets: every orchestra has one or two musicians, each of whom plays in at least ten orchestras. Nothing on the paper says which reading is meant — only a small icon in its corner, a diamond with two curved arrows and no words.
Every practical exercise of every past paper starts from a diagram like this one. By the end of the lesson you will know which reading is right, prove it with the course's own legend, and see why the man who invented these diagrams put the 1 and the N on the opposite sides.
Three levels: why every exercise starts from a drawing
Picture the farmers and local markets of the September 2025 paper before any database exists. Somebody first decides what the data means: there are farmers and farms, a farmer works at one or two farms, a farm is identified by its name. Nothing in that sentence mentions tables, documents or disks.
The lecture splits database design into three levels (p. 63), and each one commits to one more decision:
- Conceptual design — "Constructing an information model, independent from all physical consideration for an enterprise". Its product is an ER diagram.
- Logical design — "Building an organization database based on a specific data model": relational tables (lesson 8), or the graph, documents and column families of the NoSQL lessons.
- Physical design — "Implementing a database using specific data storage structure(s) and access methods": a product, its files, its indexes.
The order matters for two reasons. Each level is the input of the next, so a mistake in the meaning travels all the way down into the indexes. And the first level commits to no technology, so one conceptual design can be mapped to several logical ones. That is exactly what the practical exam does: each of the nine past papers opens with an ER diagram, and its exercises turn parts of that same diagram into a graph model, documents, Cassandra tables, an Elasticsearch mapping, Redis keys or Spark DataFrames (Fig. 1).
For a relational target the slides list what each level produces. Conceptual: "Entities", "Relationships", "Attributes (simple, no composite, no derived)", "Attribute domains", "Key attributes" (p. 64) — "no composite" because a relational cell holds one value, although the session's legend has a composite-attribute symbol (p. 1292). Logical: the "Mapping ER to logical database schema", normalisation (primary key, foreign key, "Normal form, BCNF") and constraints (p. 65) — lessons 8 and 9. Physical: transaction analysis, file organisation (indexes, disk space) and security (p. 66).
The exam hands you the conceptual level; your answers are logical and physical designs of it.
Entities, relationships and what identifies them
Take the restaurant of the September 2024 paper. "Octopus with Potatoes" at 25.00 EUR is one dish; all the dishes together are what the diagram draws as one rectangle, Dish, with the attributes Dish_ID, Name, Price, Recipe and Description. The page that defines these words is p. 68:
Entity — "Real-world object distinguishable from other objects. An entity is described using a set of attributes."
Entity set — "A collection of entities of the same kind. E.g., all employees." All its entities have the same set of attributes; "Each entity set has a key (a set of attributes uniquely identifying an entity)"; "Each attribute has a domain."
The rectangle is the entity set; the papers, the session and this notebook simply call it "the entity". "Distinguishable" is why a key must exist: two objects that no attribute can tell apart are not two entities. The domain is the set of values an attribute may take; the papers note it in brackets: Allergies (Yes/No), Magnitude (1 to 10), Quantity (in grams). Up to 2025 they list the attributes under the diagram — "The primary keys are underlined." Two names underlined together form a composite key (Location — Name, Address, June 2025), and a child entity writes "(...)" for what it inherits from its parent.
Relationships come next (p. 69). A relationship is an "Association among two or more entities"; a relationship set is a "Collection of similar relationships"; "An n-ary relationship set R relates n entity sets E1 ... En; each relationship in R involves entities e1 ∈ E1, ..., en ∈ En". Two more sentences complete the slide: the same entity set "could participate in different relationship sets, or in different 'roles' in same set", and "Relationship sets can also have descriptive attributes (e.g., the since attribute of Works_In)". Fig. 2 redraws both examples of the slide.
Roles are needed exactly when one entity set appears twice in the same relationship. Without the names "supervisor" and "subordinate", the pair (Ann, Bob) in Report_To could mean "Ann supervises Bob" or the opposite.
The last sentence of p. 69 is the one with the most consequences: "A relationship is uniquely identified by participating entities without reference to descriptive attributes." A relationship set is a set of tuples, \(R \subseteq E_1 \times \dots \times E_n\), and a set holds each tuple once. The tuple (Joe, Toys) is the fact "Joe works in Toys"; since only describes it.
| Employee | Department | since | What the database makes of it |
|---|---|---|---|
| Joe | Toys | 2015 | an instance |
| Ann | Toys | 2018 | another instance: another pair |
| Joe | Shoes | 2019 | another instance: another pair |
| Joe | Toys | 2021 | not a new instance: (Joe, Toys) already exists |
The papers lean on this rule without naming it. In the Formula 1 paper (11 Feb 2025) Include, between Team Member and Team, carries Hiring_Date and Resignation_Date: different teams are different pairs, but a member back at the same team is the same pair, with room for one period only. Lesson 7 gives a repeated period its own identity; lesson 8 turns the rule into the primary key (ssn, did) of the Works_In table.
A relationship instance is its tuple of participants: one pair of entities, one instance, whatever its attributes say.
Two constraints, one pair
Two consecutive slides ask two questions about the same company. Can a department have two managers? "In contrast, each dept has at most one manager, according to the key constraint on Manages" (p. 70). And: "Does every department have a manager?" (p. 71). The first is about a maximum, the second about a minimum, and the lecture gives them two names.
A key constraint says that an entity takes part in at most one instance of the relationship; the slides draw it as an arrow from the entity into the diamond, Department → Manages. The name comes from the textbook the slides follow (Ramakrishnan and Gehrke's, see the resources): a department that appears at most once in Manages identifies its Manages instance, as a key would. Combining "at most one" or "many" on the two sides gives the four pictures of p. 70.
A participation constraint fixes the minimum. "If so, this is a participation constraint: the participation of Departments in Manages is said to be total (vs. partial)" (p. 71). Total means every entity takes part at least once, drawn as a thick line; partial means it may take part in none, a thin line. The slide reads its own figure in three sentences: "Every Department MUST have at least an employee", "Every employee MUST work at least in one department", "There may exist employees managing no department".
The exam papers draw no key-constraint arrows and no thick lines. They pack both constraints into one (min,max) pair written next to the entity: the minimum is the participation (0 = partial, optional; 1 = total, mandatory), the maximum is the key constraint (1 = at most once; N = no upper bound). Fig. 4 translates p. 71 picture by picture.
Before: the lecture's dialect (p. 71)
After: the exam's dialect
| Lecture, pp. 70–71 | Constraint | Exam pair |
|---|---|---|
| thin line, no arrow | partial, many | (0,N) |
| thick line, no arrow | total, many | (1,N) |
| thin line with an arrow | partial, key constraint | (0,1) |
| thick line with an arrow | total, key constraint | (1,1) |
In symbols, which the slides never write: if the pair \((m, M)\) stands next to entity \(E\) on relationship \(R\), then for every instance \(e\) of \(E\)
\[ m \;\le\; \#\{\, r \in R : e \in r \,\} \;\le\; M \]
- \(e \in r\)
- the instance \(e\) takes part in the relationship instance \(r\)
- \(m\)
- the minimum: 0 (partial, optional) or 1 (total, mandatory); the papers also print 10
- \(M\)
- the maximum: 1, 2 or N, where N means no upper bound
For a binary relationship, "relationship instances of \(e\)" are "instances of the other entity linked to \(e\)", since a pair of entities is linked at most once (section 2). The type of a relationship comes from the two maxima — 1 and 1 one-to-one, 1 and N one-to-many, N and N many-to-many — and optional or mandatory from each minimum, separately. The papers also print explicit bounds: Farmer (1, 2), Orchestra (10,N), Race 10:N.
"Cardinality is the key constraint." The title of p. 70 says "Key Constraints (a.k.a. Cardinality)", and there the word means the ratio of the pictures — 1-to-1, 1-to Many — which is only the maximum. The session's legend labels its whole pair "Cardinalities" (p. 1292), and the papers mean both numbers. When a question asks for a cardinality, give min and max.
Why insist on constraints at all? The slide answers in capitals: "Constraints are IMPORTANT because they must be ENFORCED when IMPLEMENTING the database" (p. 70). Each pair is a rule some layer must check. Lesson 8 turns a (1,1) side into a foreign key that may not be null; in the NoSQL systems of this course the same rule often has to be checked by the application.
Read it from the right side
The exercise session fixes the notation of the papers in one slide, "ER Basic Elements" (p. 1292; the other group's deck splits it over pp. 1324–1325): an alphabet of nine symbols, each with its name.
| Symbol | Meaning · in the papers |
|---|---|
| Entity | An entity set: all the instances of one kind. In the papers: every diagram, with 7 to 13 rectangles. |
| Relationship | A relationship set between entities. In the papers: named with a verb — Cook, Compete, Buy. |
| Attribute | A property, with a domain. In the papers: listed under the diagram; drawn as small circles in 2026. |
| Primary Key | The attribute that identifies an instance. In the papers: "The primary keys are underlined." |
| Composite Primary Key | Two attributes that identify an instance together. In the papers: Location — Name, Address (13 Jun 2025). |
| ISA "Relationship" | The child IS A parent. Not a real relationship: no name, no pair. In the papers: the arrowhead touches the parent. |
| Composite Attribute | An attribute made of sub-attributes. In the papers: never; the session's own solutions use it (lesson 7). |
| Cardinalities | The (min,max) pair next to each entity; each arrow starts on the leg of its pair and points into the diamond — the reading direction. In the papers: the same icon in a corner of six diagrams, without labels except on 21 Jan 2025 (1:N on both arrows). |
| ISA Hierarchy | One arrow from each child into the parent, with the two letters T/P, E/O between them. In the papers: the children's lines usually join into one arrow, labelled (T, E), (P, O)… (section 5). |
A pair has two spellings. The session and the papers of May, June and September 2025 write (1,N) or (1, N); the papers of 2024, of January and February 2025 and of January 2026 write 1:N. They mean the same thing.
Now the rule, which the session and the papers use everywhere and no slide states in words. The pair written next to an entity counts, for one instance of that entity, the relationship instances it takes part in — for a binary relationship, how many instances of the other entity it is linked to. You read it from the side where it is written, looking through the diamond. Three pieces of evidence, from three sources:
- The legend draws the rule. In "Cardinalities" (p. 1292) the arrow labelled (1,N) starts on the left leg, next to its pair, and points into the diamond; the (1,1) arrow does the same from the right. Read each arrow as a sentence: one instance of the entity where it starts takes part in min to max instances of the relationship (Fig. 5). Six papers print this icon in a corner — unlabelled, except on 21 Jan 2025, where both arrows say 1:N. It is the reading key, not a relationship.
- The session's own solution agrees. On p. 1298 Credit Card (1,1) — Owns — (1,N) Customer: a card has exactly one owner, a customer owns one or more cards. Read across, a card would belong to a crowd of customers and every customer would have exactly one card.
- The papers make sense only this way. Orchestra (10,N) — Compose — Musician (1,2) gives orchestras of ten or more players; read across, it gives the duets of the opening puzzle. Race 10:N — Compete — 1:N Pilot (11 Feb 2025) gives every race a field of at least ten pilots; read across, a race could have a single pilot, and a newcomer who has run only nine races could not be stored.
"1:N next to Race, so Attend is one-to-many." Right conclusion, wrong reason: a pair describes only its own entity's participation. Ticket 1:1 — Attend — 1:N Race (11 Feb 2025) is one-to-many because of both maxima, 1 and N. In the same paper Pilot carries the same 1:N on Compete, and Compete is many-to-many, since Race's maximum there is N too.
Read a pair from its own side: one instance of the entity it touches, min to max instances across the diamond.
ISA: two questions, four letter pairs
Back to the lecture's company (p. 72). Some employees are paid by the hour (hourly_wages, hours_worked), others are on contract (contractid). An ISA hierarchy keeps the shared part — ssn, name, lot — on the parent Employee and gives each child, Hourly_Emp and Contract_Emp, only what is its own; a child inherits every attribute and relationship of the parent. The slide gives two "Reasons for using ISA: To add descriptive attributes specific to a subclass. To identify entities that participate in a relationship."
Two questions then decide the shape of the hierarchy, and they are independent:
- Overlap: "Can Joe be an Hourly_Emps as well as a Contract_Emps entity? if so, specify => Hourly_Emps OVERLAPS Contract_Emps."
- Covering: "Does every Employees’ entity also have to be an Hourly_Emps or a Contract_Emps entity?. If so, write Hourly_Emps AND Contract_Emps COVER Employees."
The session and the papers replace the two sentences with two letters next to the ISA arrow (p. 1325): "(T, E) Total Exclusive, (T, O) Total Overlapping, (P, E) Partial Exclusive, (P, O) Partial Overlapping" — T or P answers the covering question, E or O the overlap question. So COVER is T, its absence P; OVERLAPS is O, its absence E. The table on the same page says it in the lecture's words: (T, E) "Overlapping constraints do not apply, Covering ones do"; (T, O) "Both Overlapping and Covering constraints apply"; (P, E) "Overlapping and Covering constraints do not apply"; (P, O) "Overlapping constraints apply", covering ones do not. In probability terms (T, E) makes the children a partition of the parent, like the events of the law of total probability.
Lecture, p. 72: a triangle and two sentences
Session and papers: an arrow and two letters
Two details of the drawing. The arrow points from the children to the parent: the arrowhead always touches the parent. And an ISA carries no (min,max) pair — the legend even writes ISA "Relationship" in quotation marks (p. 1292): belonging to a child is not something an instance does a number of times, it is something the instance is.
The session's table explains the four pairs with a town of citizens who may hold a hunting licence, a fishing licence, or both (p. 1325) — the clearest page of the deck, with one slip:
The nine papers use three of the four pairs; (T, O) appears only in the session's table, so be ready for it all the same. The paper of 6 Jun 2024 has the other three, without brackets: Earthquake, Flooding, Landslide and Tornado under Natural Disaster are "T, E" (every disaster is exactly one kind); Ambulance and Fire Truck under Vehicle are "P, E"; Paramedic, Firefighter and Policeman under Person are "P, O", with "Note → A paramedic can be a firefighter (the same applies to the other entities involved in that ISA relationship)" — the O in words. The restaurant paper of September 2024 prints no letters at all; there you state your own assumption.
T or P: must every parent be in some child? E or O: may it be in two? Two independent questions, one arrow into the parent.
What the legend leaves out — and the duets explained
The papers use four things for which the legend of p. 1292 has no symbol.
Attributes of relationships. The lecture hangs an oval on the diamond (since, p. 69). The papers list them in a second paragraph, "The following attributes describe the relationships.": Book — Number of People, Booking Date (6 Sep 2024); Compete — Winner (Yes/No), Fastest_Lap (11 Feb 2025). The 2026 paper draws them on the diamond (Role on Works For). Either way they describe one tuple of participants.
Recursive relationships. Both legs of one diamond return to the same entity: Cause on Natural Disaster ("A Natural Disaster may cause another Natural Disaster", 6 Jun 2024), Dubbing on Digital Content (21 Jan 2025). The lecture's Report_To names its legs; the papers do not (Fig. 7). Cause prints 0:1 on one leg and 0:N on the other: either "each disaster is caused by at most one disaster and may cause any number", or the same with the roles swapped. Choose one and write it down as an assumption.
Lecture, p. 69: roles named
Exam, 6 Jun 2024: roles left to you
N.B. lines. Some constraints no pair can carry. "N.B. There is only one Head Chef per Restaurant. Tables are served by more Waiters overall, but only one at a time." (6 Sep 2024): "one at a time" is about time, and the diagram has none. "N.B. Only the original digital content can be dubbed." (21 Jan 2025) depends on the value of an attribute, original (Y/N). Read the N.B. lines as part of the diagram; they often decide a query.
Attributes on the drawing. The paper of 30 January 2026 draws every attribute as a small circle on a stem — the key filled, its name underlined — and writes no attribute list, like Fig. 2 and the lecture's pp. 77 and 83 (lesson 7). Its ISA arrowhead is a hollow triangle, as in the legend of p. 1292, whereas the earlier papers print a filled one. Same meaning.
That is also why the lecture's labels look backwards next to the pairs: "1-to Many" on p. 70 is a look-across name, so its "1" sits on the side where a pair would print N (Fig. 3). Names like "one-to-many" are read across, pairs from their own side — so (10,N) next to Orchestra means ten or more musicians per orchestra, and the duets were never on the paper. The little icon in its corner, a diamond with two curved arrows and no words, was saying so all along.
Exam-style questions
Theory questions in the form of the written exam — closed ones, where a wrong tick may cost points, and open ones of a few sentences — and two reading exercises on the diagrams of past papers. The papers never ask for these readings directly; every practical exercise assumes them.
Consider the fragment Credit Card (1,1) — Owns — (1,N) Customer, drawn in the ER notation of the course. Which of the following statements are true? Select all that apply.
Show model answer
The first and the third. Each pair describes one instance of the entity next to which it is written: a credit card takes part in exactly one Owns (one owner, never none), a customer in one to N (at least one card, possibly many). The maxima 1 and N make the relationship one-to-many.
The fragment is the session's own solution (p. 1298). The classic wrong tick is the second option, from reading (1,N) as "a card has 1 to N customers" — the look-across reading of this lesson's hook.
Explain the difference between a key constraint and a participation constraint on a relationship set. How are both expressed in the (min,max) notation used in the course? Give an example.
Show model answer
A key constraint states that an entity takes part in at most one instance of the relationship set: in the lecture's example each department has at most one manager, so Department has a key constraint on Manages, drawn as an arrow from Department to the diamond. A participation constraint states whether every entity must take part in at least one instance: total participation (every department has a manager, drawn as a thick line) or partial participation (there may exist employees managing no department). In the (min,max) pair written next to an entity, the minimum expresses participation (0 partial or optional, 1 total or mandatory) and the maximum expresses the key constraint (1 if the entity takes part at most once, N otherwise). Department (1,1) on Manages means that every department has exactly one manager; Employee (0,N) means that an employee manages zero or more departments.
A complete answer names three things: max versus min, the words total and partial, and the side on which the pair is written. Mentioning the arrow and the thick line of pp. 70–71 shows you can read both dialects.
Explain the constraints (T, E), (T, O), (P, E) and (P, O) of an ISA hierarchy using an example. How do they relate to the overlap and covering constraints presented in the lecture?
Show model answer
An ISA hierarchy is constrained along two independent axes. Covering: Total (T) means every instance of the parent belongs to at least one child; Partial (P) means some parent instances may belong to no child. Overlap: Exclusive (E) means no instance belongs to two children; Overlapping (O) means an instance may belong to several. Example: the parent Citizen with the children Hunter and Fisherman. (T, E): every citizen is either a hunter or a fisherman, not both — the children form a partition. (T, O): every citizen is a hunter, a fisherman or both. (P, E): a citizen may be a hunter or a fisherman, not both, or neither. (P, O): any combination, including neither and both. In the lecture's terms, "Hunter AND Fisherman COVER Citizen" is T and "Hunter OVERLAPS Fisherman" is O; without these statements the hierarchy is P and E. The ISA arrow points from the children to the parent and carries no cardinalities.
Name the two axes separately; a frequent weak answer treats the four pairs as four unrelated cases. If you quote the session's (T, E) sentence, write Fisherman, not Citizen (see the red pen).
Describe the three levels of database design presented in the course. What does each level produce, and why is the conceptual level designed first?
Show model answer
Conceptual design constructs an information model independent from all physical considerations: in the course, an ER diagram with entities, relationships, attributes with their domains, keys and cardinalities. Logical design builds the database on a specific data model: for a relational database it maps the ER schema to relations, normalises them (primary and foreign keys, normal forms up to BCNF) and adds constraints; for a NoSQL system it produces a graph, document or column-family design. Physical design implements the database with specific storage structures and access methods: file organisation, indexes and disk space, chosen after analysing the transactions, plus the security policy. The conceptual level comes first because it commits to no technology: the same diagram can then be mapped to different data models and products, and each later level takes the previous one as its input. The slides compare the three levels to CIM, PIM and PSM in model-driven software engineering.
Three levels, one product each, and the reason for the order. The CIM/PIM/PSM line is printed on p. 63; one sentence about it is enough.
True or false: a relationship set Works_In may contain two relationships between the same employee and the same department, as long as they have different values of the descriptive attribute since.
Show model answer
False. A relationship is uniquely identified by its participating entities, without reference to its descriptive attributes: the pair (employee, department) can appear only once in Works_In, whatever the value of since.
A natural true/false item, built on the last sentence of p. 69. The fix — turning the period into an entity — is lesson 7's p. 75.
Consider the following ER Diagram, which represents a data structure for tracking Formula 1 races (exam of 11 Feb 2025; only the part used here):
- Race 10:N — Compete — 1:N Pilot; Compete - Winner (Yes/No), Fastest_Lap
- Ticket 1:1 — Attend — 1:N Race
- Race 1:1 — On — 1:N Track
- Team Member 1:N — Include — 1:N Team; Include - Hiring_Date, Resignation_Date
- Spectator, Team Member, Team Owner ISA Person (T, E); Engineer, Pilot, Mechanic ISA Team Member (P, E)
- N.B. Each Team Member might have worked for different Teams in different periods of time.
(a) State in one sentence each the constraint expressed by the cardinalities of Compete, Attend and On, and classify each of the three relationships as one-to-one, one-to-many or many-to-many. (b) Explain the two ISA pairs. (c) The N.B. says that a team member may have worked for different teams in different periods. Can Include, as drawn, store this? Which closely related situation can it not store, and why?
Show model answer
(a) Compete: every race has at least ten competing pilots, and every pilot competes in at least one race; both maxima are N, so it is many-to-many. Attend: every ticket is for exactly one race, and every race has at least one ticket; one-to-many, one race with many tickets. On: every race takes place on exactly one track, and every track hosts at least one race; one-to-many, one track with many races.
(b) (T, E) on Person: every person is exactly one of spectator, team member or team owner — a partition. (P, E) on Team Member: a team member is at most one of engineer, pilot and mechanic, and may be none of them.
(c) Yes for different teams: each (member, team) pair is a separate Include instance with its own Hiring_Date and Resignation_Date. But a relationship is identified by its participants, so a member and a team can be linked only once: a member who left a team and later came back cannot be stored with two periods for that team. That would require the employment period to become an entity of its own.
The exercises of this paper build on (a): its graph model and its query on "races where at least 15 pilots competed" need Compete as a many-to-many relationship and a ticket that belongs to exactly one race. Part (c) is the kind of N.B. that changes a design; the fix the lecture proposes is in lesson 7.
Consider the ER Diagram representing a data structure for tracking natural disasters (exam of 6 Jun 2024; only the part used here):
- Natural Disaster - ID, …; children Earthquake, Flooding, Landslide, Tornado, ISA labelled T, E
- Person - Personal ID, …; children Paramedic, Firefighter, Policeman, ISA labelled P, O. Note → A paramedic can be a firefighter (the same applies to the other entities involved in that ISA relationship).
- Vehicle - Plate, …; children Ambulance, Fire Truck, ISA labelled P, E
- Cause: a relationship between Natural Disaster and itself, 0:1 on one leg and 0:N on the other, attribute Causal Description (A Natural Disaster may cause another Natural Disaster).
(a) For each hierarchy, describe one population of instances that it forbids, or explain why it forbids none. (b) Read the cardinalities of Cause, stating the assumption you need.
Show model answer
(a) T, E on Natural Disaster forbids a disaster that is none of the four kinds, and a disaster recorded both as an earthquake and as a flooding. P, E on Vehicle forbids a vehicle that is both an ambulance and a fire truck; a vehicle that is neither is allowed. P, O on Person forbids no population: a person may belong to none of the three children or to several of them at once, as the note says.
(b) The diagram does not name the two legs, so I assume that the leg marked 0:1 is the role "caused disaster" and the leg marked 0:N the role "causing disaster". Then every disaster is caused by at most one other disaster, possibly none, and a disaster may cause any number of others, possibly none. With the opposite assumption a disaster would cause at most one other disaster and could have many causes.
The paper's Note is the letter O written out in words, and the paper prints its letters without brackets ("P, O"): same meaning. In (b) write the assumption down: the diagram leaves the choice open, and either reading is defensible once it is stated.
Check yourself
Orchestra (10,N) — Compose — (1,2) Musician (exam of 13 June 2025). In how many orchestras can one musician play?
Table 1:1 — Has — 1:N Restaurant (exam of 6 September 2024). Which single change makes Has many-to-many?
The hierarchy of Hunter and Fisherman under Citizen is labelled (T, O). Which populations are legal? Select all that apply.
T guards the region "neither", E guards the region "both": with (T, O) only "neither" is forbidden.
On p. 71 Department is joined to Manages by a thick line with an arrow into the diamond. Which pair goes next to Department in the exam's notation?
Works_In(Employee, Department) has the attribute since. Joe worked in Toys from 2015 to 2016 and, after a break, again from 2019. What can a database built on this diagram store?
The picture labelled "1-to Many" on p. 70 has a left dot with two lines, and every right dot has at most one. Where does the N go in the exam's notation?
The papers label Painting → Image (P, E) in May 2025 and Farmer → People (P, O) in September 2025; each hierarchy has a single child. What does the second letter change?
Key take-aways
- Design goes conceptual → logical → physical; the exam hands you the conceptual level, an ER diagram "independent from all physical consideration", and asks for logical and physical designs of it in several data models.
- An entity set is a box of distinguishable instances with the same attributes, each with a domain and the key underlined; a relationship instance is identified by its participants alone, so a pair of entities is linked at most once whatever the descriptive attributes say.
- A (min,max) pair packs two lecture constraints: the minimum is the participation (0 partial or optional, 1 total or mandatory, p. 71), the maximum the key constraint (1 at most once, N many, p. 70); the type of a relationship comes from the two maxima.
- Read a pair from the side where it is written: it counts the relationship instances of one instance of that entity, so (10,N) next to Orchestra means at least ten musicians per orchestra. The papers write it (1, N) or 1:N; the legend's curved arrows show the direction.
- ISA is an arrow from the children into the parent with two independent letters, T or P (must every parent be in a child? the lecture's COVER) and E or O (may it be in two? the lecture's OVERLAPS); (T, E) is a partition, and the session's (T, E) sentence should name "a Hunter or a Fisherman", not "a Hunter or Citizen".
- The legend omits relationship attributes, recursive relationships with unnamed legs, N.B. constraints and the 2026 circle attributes; read them anyway, and write down an assumption when the diagram leaves a choice.
What to watch and read
-
Database Systems: Concepts, Languages and Architectures
Atzeni, Ceri, Paraboschi, Torlone — free PDF from the authors
Chapter 5, section 5.2 (printed pp. 163–183) is the ER model in the notation of the papers, (min,max) next to the entity: cardinalities "describe the maximum and minimum number of relationship occurrences in which an entity occurrence can participate", and figure 5.4 is a one-page legend. Open it next to section 4.
-
The Entity-Relationship (ER) Model
University of Waterloo, CS 338 (after Elmasri and Navathe)
Slide 18 puts the three ways of writing one relationship constraint side by side — cardinality ratio, participation, and the (min, max) pair — the dictionary of section 3 in another teacher's words.
-
The Entity-Relationship Model (chapter 2 slides)
Ramakrishnan and Gehrke, Database Management Systems, 3rd ed.
The original of pp. 68–72, arrows and thick lines included, plus what the course left out: weak entities, aggregation, ternary relationships.
-
Entity–relationship model
Wikipedia
Chen's notation, crow's foot and the min-max convention side by side. Read it to recognise a diagram drawn in another dialect before you trust its numbers.