NivaarExam PrepOfficial exam papers ↗

25-Comp-B3 Data Bases and File Systems · December 2015

Question 3 of 8

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Notes on this paper

98-Comp-B3, Data Bases & File Systems — National Exams, December 2015. 3 hours, closed book, no calculators. Candidates were instructed to answer five questions: one of Questions 1/2, one of Questions 3/4, and three of Questions 5–8 — only those five are marked, and question 4 of note states all eight questions carry equal value (20 marks each). All 8 questions are answered below for completeness (this is a study resource covering the full syllabus).

Reference texts: Silberschatz, Korth & Sudarshan, Database System Concepts (7th ed.) — ER modelling, normal forms, and transactions/serializability; Ramakrishnan & Gehrke, Database Management Systems (3rd ed.) — B+-tree indexing, SQL, and relational algebra.

Question 3 (20 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Given. Shows are released as seasons of episodes (an episode belongs to exactly one season; a show may have several seasons); each episode has its own unique ID, title, copyright date, plus a season ID and show ID; each show has a show ID and a format; actors have an actor ID, SIN, name, address, and phone, and "no address has more than one phone"; a role (e.g. "Moses") has a name, gender, and type, and is portrayed in a given episode by exactly one actor, though a role may recur across many episodes/seasons and the same actor may portray the same role many times.

Find. A complete Chen-notation ER diagram with keys and cardinality/participation constraints, plus any constraint the diagram cannot express.

Approach. Read "a season has a season ID" alongside "an episode appears in only one season" and "a show may have one or more seasons": nothing in the prose says a SeasonID is unique ACROSS different shows (only that each show numbers its own seasons), so Season is modelled as a weak entity owned by Show. Episode, by contrast, IS given "a unique identification number" of its own, so it is a strong entity related to Season by an ordinary (if mandatory) 1:N relationship. The trickiest rule — "the role for a single episode is played by exactly one actor" — is a functional (key) constraint on a THREE-way relationship among Role, Episode, and Actor, drawn as a ternary relationship with an arrow into Actor.

Entities. Show (ShowID key, Format). Season (weak; partial key SeasonID, Title — owned by Show). Episode (EpisodeID key, Title, CopyrightDate). Role (RoleName key, Gender, Type). Actor (ActorID key, SIN, Name, Address, Phone).

Relationships. Has (identifying): Show (1) – Season (N, total — a season cannot exist without its owning show). Contains (identifying): Season (1) – Episode (N, total — "an episode appears in only one season" makes this both mandatory and single-valued). Portrays (ternary): Episode (M) – Role (N) – Actor, with a functional (key) constraint drawn as an arrow into Actor: for any given (Role, Episode) combination, at most one Actor participates — exactly the constraint "the role for a single episode is played by exactly one actor." Neither Role nor Episode is required to participate in every combination (a role need not appear in every episode), so participation on those two sides is partial.

SHOWSEASONEPISODEROLEACTORHas1NContains1NPortraysMN1
Question 3 — OilyWood Shows ER diagram (Chen notation; double line = total participation; arrow into ACTOR = key constraint: {Role, Episode} functionally determines Actor)
Check — assumptions
Role is modelled as its own strong entity keyed on RoleName (e.g. "Moses" is the same Role wherever it recurs, matching "a role can be portrayed in many different episodes in many different seasons"); if RoleName is not guaranteed unique across unrelated shows in practice, a synthetic RoleID would be substituted with no other change to the diagram. SeasonID is treated as only locally unique per Show (weak entity), since the source never states it is globally unique.

Constraint the ER diagram cannot capture. "Poorly paid actors often share the same address, and no address has more than one phone" encodes a functional dependency BETWEEN TWO ATTRIBUTES of the same entity, Address → Phone: every Actor tuple sharing a given Address value must also carry the same Phone value. Chen ER diagrams express cardinality/participation constraints on relationships BETWEEN entities (or key uniqueness within one entity); they have no notation for "attribute X of an entity determines attribute Y of that SAME entity." Capturing this properly would require pulling Address out into its own entity (with Phone as an attribute of THAT entity, and a relationship from Actor to it) — a normalization step, not something expressible by annotating the diagram above. By contrast, "an episode appears in only one season" and "the role for a single episode is played by exactly one actor" ARE both fully captured, by Episode's ordinary participation in Contains and by the functional arrow on Portrays.

Final results — Question 3
ItemValue
EntitiesShow, Season (weak), Episode, Role, Actor
RelationshipsHas (Show–Season, identifying, 1:N total); Contains (Season–Episode, identifying, 1:N total); Portrays (ternary Episode–Role–Actor, key constraint on Actor)
Constraint NOT expressibleAddress → Phone functional dependency (intra-entity FD; needs normalization, not ER notation)