In the CODASYL network data model, what is true of a set type's owner–member definition and occurrences at runtime?

Introduction / Context:
CODASYL (Conference on Data Systems Languages) defined the classic network data model used by early DBMSs. Understanding ‘‘set types’’—which relate an owner record type to a member record type—is central to reasoning about CODASYL schemas and navigation.

Given Data / Assumptions:

• A ‘‘set type’’ is a schema-level construct.
• It connects exactly one owner record type to exactly one member record type.
• At runtime, there are many owner and member occurrences participating in individual set occurrences.

Concept / Approach:
In CODASYL, each set type specifies one owner record type and one member record type. ‘‘Occurrences’’ are runtime instances: there can be many owner occurrences and many member occurrences linked through set occurrences. Navigation uses currency indicators to traverse owner-to-member and member-to-owner.

Step-by-Step Solution:

Verification / Alternative check:
Example: Set type EMP-OF-DEPT has owner DEPARTMENT and member EMPLOYEE. Many departments and many employees exist; each set occurrence links one department to zero or more employees.

Why Other Options Are Wrong:

• Multiple owner types per set type: violates CODASYL definition.
• One owner with multiple member types in the same set type: also not how a single set type is defined (define separate set types instead).
• No owners: contradicts the owner–member concept.
• None of the above: incorrect because the correct definition is provided in the chosen option.

Common Pitfalls:
Confusing schema definitions (types) with runtime instances (occurrences), and assuming multiple member types belong to one set type.

Final Answer:
One owner record type and one member record type are defined; there can be many owner and member occurrences at runtime