A data model separates data design from code. In a library management system, begin with entities such as Book and Author, refine their fields, and make every relationship explicit. section 3.1
A data-oriented model represents records as heterogeneous string maps. Their values can be primitives, positional collections, or indexes, with composition and association connecting records. section 3.6
Design the model by asking:
- How will each relationship be represented rather than merely drawn? section 3.1
- Which information paths expose the needed fields and nested values? section 3.6
- Is the flexibility of adding, removing, or renaming fields worth giving up compile-time safety? section 3.6
Book and Author
A many-to-many Book–Author association can use a collection of author IDs in each Book record and a collection of book IDs in each Author record. The relation remains data rather than class-defined behavior. section 3.1
Figure 3.3 Library management relation model. Dashed lines (e.g., between Book and Author) denote indirect relations, [String] denotes a positional collection of strings, and {Book} denotes an index of Books.
Use the relation model to inspect direct and indirect relationships, positional collections, and indexed records at a glance. section 3.1
