Model business data and relationships

1. Start from the business question

A fictional team needs to know which party may perform each action on each portfolio. An organization chart identifies team membership but does not necessarily answer that question. A requirements map identifies dependencies but represents a different object too. Start with concepts, identity and the distinction the decision must preserve. Here, portfolio is simply the name of a business object in the exercise, with no implicit financial rules.

The model uses parties A, B and C, portfolios F1 and F2, and actions read and submit. An assignment relates all three elements. Identifiers distinguish objects in this context; similar names do not authorize merging them. The conceptual model does not choose tables, indexes or storage technology. It should support discussing facts and rules before those decisions. Ask, for example: may a party be registered without assignments? May it have different actions on different portfolios? Which information belongs to the particular assignment? Answers guide the model and acceptance examples.

2. Read minimum and maximum participation in both directions

A relationship raises different questions in each direction: how many portfolios may a party have, and how many parties may a portfolio have? One answer does not determine the other. In the exercise contract, a party may have no assignments. A draft portfolio may also exist without a submitter. An active portfolio requires at least one distinct party with submit, and any portfolio permits at most two submitters in the base configuration. These are rules of this example, not universal policies.

Count distinct people in the specified role. B/read, B/submit, C/read and C/submit on F1 represent four assignments, two parties and two submitters. The two-submitter maximum is satisfied. Counting four rows would change the rule's unit. The presence of B/read alone does not satisfy the submit requirement either. Record activation alongside the rule: placing a minimum of one on every portfolio would forbid an authorized draft state. A diagram may need an additional rule to express this condition.

3. Place each attribute on the fact it describes

In the exercise, maxItems is a positive integer from 1 to 100 and belongs to the complete assignment. A/read/F1 has limit 20; A/submit/F2 has limit 10. Keeping only limit 20 on A loses the distinction. Storing the limit on the portfolio is insufficient too if different parties or actions may have different values. Assignment identity is the combination of party, portfolio and action. B/read/F1 and B/submit/F1 can therefore coexist with their own limits.

A different rule may place an attribute at another level. In a separate conceptual example, the business defines one service currency per portfolio, independent of assignments. Two rows for the same portfolio with different currencies contradict that rule at the same instant. The answer is not automatically to declare two portfolios or choose the last row. Clarify the fact and represent its uniqueness at the appropriate level. The decision follows confirmed meaning rather than a general preference for fewer or more tables. This lesson's program does not model currencies or physical storage.

4. Preserve the joint fact

The base file contains exactly four assignments: (A,F1,read), (A,F2,submit), (B,F1,submit) and (C,F2,read). The set is complete by construction. A proposal retains only party/portfolio and portfolio/action pairs. F1 has A and B, and has read and submit; recombining those pairs produces four triples. The same occurs with A and C on F2. The proposal reconstructs eight triples although only four were established.

(A,F1,submit) is a counterexample: A belongs to F1 through read, while submit exists on F1 through B. Those two facts do not establish submit for A on F1. Neither pair needs to be wrong for the conclusion to be wrong. Explain this loss through the example before discussing an implementation. The program calls reconstructed triples absent from the direct relation spurious. The term identifies information added through recombination; it is not an observation of real access or a claim about a user.

5. More pairs may still lose meaning

The proposal now adds party/action pairs. B has only submit and C only read, so the extra B/read/F1 and C/submit/F2 combinations disappear. However, A has read on F1 and submit on F2. The third pair set still admits (A,F1,submit) and (A,F2,read). Six triples remain, including two added to the direct relation. Adding another view does not by itself establish that the original distinction was recovered.

A stronger demonstration compares the original four-triple relation with another containing those two additional triples. Both produce exactly the same three pair sets but answer the question about A submitting on F1 differently. A reader receiving only those pairs cannot determine which relation was supplied. This conclusion follows from the finite example; it does not say every decomposition is always unsuitable. If other constraints ensure faithful reconstruction, they must be explicit and their effect checked.

6. Check structure and business rules separately

The program distinguishes malformed input from understandable data that violates a business rule. A reference to a nonexistent party, repeated assignment identity or maxItems=true is rejected. true does not represent integer 1 in this contract. An active portfolio without a submitter is instead a well-formed situation that the report identifies as a rule violation. It does not automatically fill the gap or turn missing assignment into approval.

Classification rules also need context. In a separate conceptual example, the same organization may be both customer and supplier. A design imposing mutually exclusive classes would forbid a permitted case. Different names do not establish exclusivity. Similarly, if the current sample shows one portfolio per party but the confirmed need permits two, the sample does not establish a maximum of one. Use permitted and prohibited examples to challenge the model. These classification examples are not functions implemented in the Python exercise; they extend the modelling reasoning.

7. Distinguish current state from historical questions

A current relation may answer who holds an assignment today without answering who held it yesterday. Consider two histories: in the first, A held submit on F1 yesterday and B replaced A; in the second, B already held that assignment yesterday. Both end with the same current relation. A last-modified date does not necessarily contain the earlier relation. If the decision requires answering the historical question, identify which facts and periods must remain represented. Do not invent history from the current state.

Completeness needs similar care. The teaching file declares the direct list complete, so an absent combination is not assigned in that model. In an incomplete real extract, absence may mean only that information was not collected. Clarify population, instant and source before transferring the interpretation. The program compares the supplied relation and implements neither temporal history, data collection nor access enforcement. A useful conclusion states which question was answered and which information is missing for another question.

8. Exercise: construct a useful counterexample

Download the exercise, extract every file into a directory and read case-data.json before running python3 explore.py. Draw the four triples and predict the combinations reconstructed from two and three pair sets. Explain (A,F1,submit), including why recombination supplies no confirmed maxItems for it. Then compare your prediction with the JSON. python3 check_model.py runs the package's local checks.

In a copy, remove (A,F2,submit). While F2 remains draft, it has no submitter minimum. Making it active introduces a violation without changing assignments. In another copy of the base, add C/submit/F1: F1 then has two submitters, within the maximum. Adding A/submit/F1 too brings the distinct total to three and violates the maximum of two. Record the rule, example, conclusion and decision needed. Files include twelve tasks and worked solutions in both languages. Enumeration compares models in a small domain; it does not confirm suitability for a real service or grant operational authority.

Common pitfalls

Reverse cardinality directions; count rows as people; place an assignment attribute on the party; recombine pairs as if they established the joint fact; infer history or completeness without evidence.