Modeling workshop: narrative → entities, relationships, associative & weak

The exam format you must be able to produce

The modeling short-answer does not ask you to draw — it asks you to list. Given a business narrative, produce four lists:

1. (a) all entities, 2. (b) all relationships, 3. (c) which of those entities are associative, and 4. (d) which (if any) are weak.

This lesson is pure *production*: a repeatable procedure, then a fully worked example, then you do a fresh narrative cold for the checkpoint.

The procedure.

1. Underline the nouns → candidate entities. Drop the ones that are a single instance, are computable, or are really an attribute of another entity.
2. Underline the verbs that connect nouns → candidate relationships; name each as a present-tense verb phrase and note its cardinality both ways.
3. Flag associative entities: any relationship that is M:N and carries its own attributes/identity becomes an associative entity (apply the four conditions from 2.5). Watch for "records X *for each* pairing of A and B" — that X is a relationship attribute → associative.
4. Flag weak entities: any entity that cannot be identified without an owner and exists only as detail of another entity (look for "for each ___, the company records…" sub-detail).

Worked example — the airline

*An airline has a number of planes (attributes: plane-id (unique), name, vendor). It serves many destinations (destination-id (unique), name, flight-date). Each plane flies to one or more destinations, or may be a backup, or may be under maintenance and fly to none. For each plane undergoing maintenance, the company records the technician name and the type of maintenance. A destination may be served by one or more planes. A plane's service charges vary by the number of destinations it serves; the airline records the service charge for each plane when it flies to a certain destination. At year end the airline applies a degenerating percentage to each plane, computed from its service charges and total flying hours.*

Work the four lists:

(a) Entities. *PLANE* (many instances, unique id) and *DESTINATION* (many, unique id) are clear strong entities. *Maintenance* is recorded only "for each plane undergoing maintenance" — it is sub-detail of a plane, with a partial identity → a MAINTENANCE entity. The *service charge per plane-per-destination* is data about the plane↔destination pairing → it becomes an entity (call it SERVICE_CHARGE). The *degenerating percentage* is derived from service charges and flying hours → it is a derived attribute of PLANE, not an entity (computable data is never an entity). So entities: PLANE, DESTINATION, MAINTENANCE, SERVICE_CHARGE.

(b) Relationships. PLANE Flies_to DESTINATION (the core M:N — each plane to one-or-more destinations, each destination served by one-or-more planes). PLANE Undergoes MAINTENANCE (a plane may have maintenance records; each maintenance record belongs to exactly one plane — its identifying relationship). The service-charge fact is carried by SERVICE_CHARGE linking PLANE and DESTINATION.

(c) Associative entities. SERVICE_CHARGE is associative: *Flies_to* is many-to-many and carries an attribute (the charge) that belongs to the plane–destination *pairing*, not to either alone — exactly the four conditions. So the M:N *Flies_to* is resolved by the associative entity SERVICE_CHARGE.

(d) Weak entities. MAINTENANCE is weak: it has no independent meaning — a maintenance record exists only in the context of a specific plane, and *technician name + type* are only a partial identifier, made unique by combining with the owning plane's id. Its link to PLANE is the identifying relationship.

Final answer: Entities = PLANE, DESTINATION, MAINTENANCE, SERVICE_CHARGE · Relationships = Flies_to (resolved by SERVICE_CHARGE), Undergoes (PLANE–MAINTENANCE) · Associative = SERVICE_CHARGE · Weak = MAINTENANCE. That is the complete Part B Q2 answer, with each choice justified — which is exactly what earns the marks.