Chapter 2 — Discrete mathematics
Lesson map
Lesson 02 published. Map, example, EX004.
flowchart TD
N0["Learning outcomes"]
N1["2.1 Sets of data"]
N2["2.2 Relations and keys"]
N3["2.3 Graphs of dependencies"]
N4["2.4 Logic for rules"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX004"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 Sets of data"]
N2["2.2 Relations and keys"]
N3["2.3 Graphs of dependencies"]
N4["2.4 Logic for rules"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX004"]
[Learning outcomes]
|
v
[2.1 Sets of data]
|
v
[2.2 Relations and keys]
|
v
[2.3 Graphs of dependencies]
|
v
[2.4 Logic for rules]
|
v
[Worked example] --> [Exercise EX004]
Learning outcomes
You will (1) use sets and relations to describe data ownership; (2) model dependencies as graphs; (3) reason about keys and functions.
2.1 Sets of data
Kofi describes Tidewater's data as sets: customers, premises, meters and readings. The intersection of customers with a priority services list identifies vulnerable households needing extra support during supply interruptions. Set operations make governance questions precise. For example, the set of meters with readings but no linked premise should be empty; if it is not, some readings cannot be billed or explained. He writes such conditions as rules that can later be checked automatically against the real data. Each rule names the sets it compares and the result expected.
2.2 Relations and keys
A relation links elements of two sets, such as meters to premises. Kofi checks whether it is a function: each meter should map to exactly one premise at a time. In the synthetic replica, twelve meters map to two premises because of an old data migration. He explains that a key is an attribute that identifies each element uniquely, and that broken keys create ambiguity about who owns which reading. Defining keys and checking them is one of the first tasks of data governance.
2.3 Graphs of dependencies
Kofi models Tidewater's systems as a directed graph, with an edge from each system to the systems that use its data. The billing system depends on meter readings and tariffs; the leakage report depends on billing volumes and sensor flows. Following edges backwards from a report shows every source it relies on. He notes that graph reachability will be the basis for lineage analysis later in the course, when he traces exactly which sources feed a figure presented to Tidewater's board. Cycles are flagged.
2.4 Logic for rules
Governance rules can be expressed in logic. Kofi writes: for every reading, if the meter is active then the reading has a premise. He also writes the contrapositive and checks it on examples. Prof. Varga shows how precise logical rules prevent disagreements between teams, because ambiguous phrases such as all readings should be valid hide different meanings. He learns that writing rules formally first makes their later implementation in code and their explanation to managers more consistent. Formal rules also make test cases easier to derive later on.
Worked example
Kofi uses sets to define rule conditions, finds twelve meters mapped to two premises, models systems as a dependency graph and writes quality rules in logical form.
Synthetic case. The replica is synthetic.
Errors and limits
Formal rules can still encode the wrong requirement; validate them with data owners.
Exercises
- EX004 — Empty set rule. Which set should be empty? Rubric: 3 = meters with readings but no linked premise;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX005 — Function check. How many meters mapped to two premises? Rubric: 3 = twelve;; 2 = partly correct;; 1 = wrong;; 0 = none.
- EX006 — Graph use. What does following edges backwards from a report show? Rubric: 3 = every source it relies on;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 02 (chapter 02 of 50)
← Chapter 01 · Course chapter index · Chapter 03 →
Continue to the next authored lesson.