Chapter 4 — Data models

Chapter 4 — Data models

Lesson map

Lesson 04 published. Map, example, EX010.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 Designing data models"]
  N2["4.2 On-ledger and off-ledger data"]
  N3["4.3 Personal data in models"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX010"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 Designing data models"]
  N2["4.2 On-ledger and off-ledger data"]
  N3["4.3 Personal data in models"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX010"]

[Learning outcomes]
    |
    v
[4.1 Designing data models]
    |
    v
[4.2 On-ledger and off-ledger data]
    |
    v
[4.3 Personal data in models]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX010]

Learning outcomes

You will (1) design simple data models; (2) separate on-ledger and off-ledger data; (3) protect personal data in models.

4.1 Designing data models

A data model describes what information a system keeps and how pieces relate. Lucas models the makerspace's booking system: members, machines, bookings, workshops taught and credits earned. Each booking links a member to a machine and a time slot. He draws the model as boxes and lines before building anything. Good models prevent errors: a booking without a valid machine should be impossible. He also models the token side, where a credit balance belongs to an address. Seeing both models side by side shows exactly where the two systems must agree and where mistakes might creep in.

4.2 On-ledger and off-ledger data

Not all data should go on the ledger. Lucas keeps member names, emails and safety training records in the booking database, which can be corrected and deleted. The ledger holds only credit balances and transfers linked to addresses. A mapping from member to address is kept in the database with restricted access. He records why each item is placed where it is. NIST IR 8202 explains that ledger data is replicated and hard to remove, so careful placement protects privacy and makes later corrections possible without needing to alter an immutable record.

4.3 Personal data in models

Lucas marks every personal field in the model and asks whether it is needed. Birth dates were collected for no clear reason, so he proposes dropping them. Safety training dates are needed to allow machine bookings. Emails are needed for notices. He also limits who can see each field: workshop leaders see names and training status, while only the manager sees emails. Data protection begins in the model, because fields that are never collected cannot leak. The manager approves the changes and Lucas updates the model diagram and its notes accordingly.

Worked example

Lucas keeps names and training records off-ledger, stores only balances and transfers on-ledger, and drops unneeded birth dates.

Synthetic case. The data models are synthetic; NIST IR 8202 is a real source.

Errors and limits

Placing personal data on a replicated ledger makes later correction or deletion very hard.

Exercises

• EX010 — Model entities. Name one entity in the booking model. Rubric: 3 = machines;; 2 = bookings;; 1 = weather;; 0 = none.
• EX011 — Mapping location. Where is the member-to-address mapping kept? Rubric: 3 = in the database with restricted access;; 2 = database;; 1 = on-ledger;; 0 = none.
• EX012 — Dropped field. Which field does Lucas propose dropping? Rubric: 3 = birth dates;; 2 = birth date;; 1 = email;; 0 = none.

Synthesis

Thoughtful data models place information where it can be protected and corrected.

Continue studying — chapter 04 of 30

← Chapter 03 (draft) · Course chapter index · Chapter 05 (draft) →