🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🧩 धडा 05 — Data modelling: एक तथ्य, एक जागा

📍 तुम्ही इथे आहात: 18 पैकी धडा 05 · मागे: lesson-04-transactions · पुढे: lesson-06-indexes

📦 या ब्रँचमध्ये काय आहे

धडे 01–04, आणि नोंदवह्या कोणत्या असाव्यात हे कसे ठरवायचे: normalisation (एक तथ्य, एक जागा), लिखित नियम म्हणून constraints, आणि denormalisation — एखादी माहिती मुद्दाम copy करणे, ती खरी ठेवण्याच्या नियमासह.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

एक नवी clerk एकच प्रचंड नोंदवही सुचवते: प्रत्येक ओळीत विद्यार्थिनी, वर्ग, शिक्षिका, शिक्षिकेचा phone number, grade, विषय… वाचायला सोपे! मग शिक्षिका आपला phone number बदलते. म्हणजे तीस ओळी दुरुस्त करायच्या, आणि clerk एकोणतीस दुरुस्त करते. वर्षभर एक ओळ खोटे बोलते.

हे टाळणारा नियम: एक तथ्य, एक जागा. शिक्षिकेचा phone number teachers नोंदवहीच्या एकाच ओळीत राहतो; विद्यार्थी आपल्या वर्गाकडे बोट दाखवतात, वर्ग आपल्या शिक्षिकेकडे. number एकदा बदला, आणि pointer मधून join होणारा प्रत्येक प्रश्न नवा number पाहतो. हेच normalisation, आणि प्रत्येक नोंदवहीसाठी त्याचे तीन प्रश्न:

एक ओळ म्हणजे काय? (एक विद्यार्थिनी — प्रत्येक विषयासाठी एक विद्यार्थिनी नव्हे)
ती कशाने ओळखली जाते? (ओळ क्रमांक; roll number UNIQUE आहे)
कोणती माहिती तिची आहे, ती ज्याकडे बोट दाखवते त्याची नाही? (विद्यार्थिनीचे नाव: हो; वर्गशिक्षिकेचा phone: नाही)

आणि मुद्दाम केलेला अपवाद: कधीकधी एखादा प्रश्न इतक्या वेळा विचारला जातो आणि इतके join करतो की तुम्ही एखादी माहिती ती जिथे वाचली जाते तिथेच copy करता — एक denormalised column — आणि ती copy खरी ठेवणारा नियम तुम्ही लिहून ठेवता (trigger, रात्रीचा job, किंवा "फक्त याच एका function मधून"). कारण आणि नियम घेऊनच copy करा, कधीच चुकून नाही.

🗺️ आकृती

flowchart LR
    big["❌ one big register<br/>student · class · teacher · teacher phone · grade<br/>phone changes → 30 rows, 29 fixed"]
    norm["✅ one fact, one place<br/>teachers(id, name, phone) ← classes(teacher_id) ← students(class_id) ← grades(student_id)"]
    rules["🧩 constraints: NOT NULL · UNIQUE · CHECK · FK<br/>the schema refuses nonsense"]
    den["⚖️ denormalise on purpose<br/>copy a hot value + a rule that keeps it true"]
    big -->|"1 normalise"| norm --> rules
    norm -.->|"2 measured reason only"| den

❓ काय

1NF: प्रत्येक cell मध्ये एकच value (एका column मध्ये "maths, science" नको — ती एक grades नोंदवही आहे). व्यवहारात 2NF/3NF: key नसलेला प्रत्येक column row च्या key चे वर्णन करतो आणि दुसरे काहीच नाही — जर तो row ज्याकडे बोट दाखवते त्याचे वर्णन करत असेल, तर त्याची जागा तिथे आहे.
Constraints म्हणजेच modelling: CHECK (term IN (1,2,3)), UNIQUE (student_id, subject, term), NOT NULL — domain चे नियम कपाटातच लिहिलेले, प्रत्येक program साठी लागू.
Types महत्त्वाचे: dates ISO strings (2026-10-03) किंवा DATE म्हणून; पैसे सर्वात लहान एककात integers म्हणून, floats कधीच नाही; booleans 0/1 किंवा BOOLEAN म्हणून.
Denormalisation: trigger ने update होणारा students.grade_count column; रात्रीचा class_summary table; hot read paths वर copy केलेले class_name. मोजलेल्या कारणासह (धडा 12) आणि नियमाचा मालक असेल तरच परवानगी.
नावे: tables अनेकवचनी (students), columns snake_case, foreign keys <thing>_id. कंटाळवाणी नावे म्हणजे दयाळूपणा.

🤔 का

कारण schema तो वापरणाऱ्या प्रत्येक program पेक्षा जास्त जगतो. चांगल्या model केलेल्या खोलीत नवा प्रश्न एका JOIN च्या अंतरावर असतो; वाईट model केलेल्या खोलीत प्रत्येक नवा प्रश्न आधी data साफसफाई बनतो. आणि constraints "हे कुठेतरी validate करायला हवे" याचे रूपांतर "कपाट आधीच ते करते" मध्ये करतात.

🔧 कसे (या repo मध्ये)

db/schema.sql normalised आहे: classes, students, grades, homework, प्रत्येक माहिती एकदाच, keys ने जोडलेली, UNIQUE आणि CHECK नियमांसह. demo.py मधील model() कपाट दोन प्रकारचा मूर्खपणा नाकारताना दाखवते.

🧪 करून पाहा — capstone चा पहिला दगड

# 1) add a teachers register, properly: in db/schema.sql
#    CREATE TABLE IF NOT EXISTS teachers (id INTEGER PRIMARY KEY, name TEXT NOT NULL, phone TEXT);
#    and give classes a pointer:  teacher_id INTEGER REFERENCES teachers(id)
# 2) seed one teacher per class in db/seed.sql, rebuild, and ask:
python3 db/demo.py model >/dev/null
python3 - <<'EOF'
import sqlite3; c = sqlite3.connect("db/school.db")
print(c.execute("SELECT s.name, t.name, t.phone FROM students s JOIN classes c ON c.id=s.class_id JOIN teachers t ON t.id=c.teacher_id ORDER BY s.name").fetchall())
c.execute("UPDATE teachers SET phone='000' WHERE id=1"); c.commit()     # change the fact ONCE
print(c.execute("SELECT DISTINCT t.phone FROM students s JOIN classes c ON c.id=s.class_id JOIN teachers t ON t.id=c.teacher_id WHERE c.id=1").fetchall())
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

3A च्या प्रत्येक विद्यार्थिनीच्या ओळीत तीच शिक्षिका आणि phone दिसतो; teachers वर एका UPDATE नंतर, joined query [('000',)] दाखवते — एक बदल, प्रत्येक विद्यार्थिनीला दिसतो. दुहेरी roll number किंवा Z हा grade अजूनही नाकारला जातो.

🏁 तुम्ही आत्ताच काय सिद्ध केले

तुम्ही खोलीत एका नव्या प्रकारची माहिती एकाच जागी जोडली, ती key ने जोडली, आणि सर्वांसाठी एकदाच बदलली — modelling चा नियम, अनुभवलेला.

⚠️ नेहमीच्या चुका

column मध्ये स्वल्पविरामाने वेगळ्या केलेल्या याद्या ("maths, science") — तो एक table आहे
key हवी तिथे नाव copy करणे (class_id ऐवजी class TEXT)
पैशांसाठी floats; तीन formats मध्ये dates साठी strings
मोजण्याआधीच "speed साठी" denormalise करणे — आणि copy खरी ठेवणाऱ्या नियमाशिवाय
domain ऐवजी screen चे model करणे — screens दर महिन्याला बदलतात, domain बदलत नाही

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: schema design हा असा एकमेव निर्णय आहे जो पहिल्या दिवशी स्वस्त असतो आणि 400 व्या दिवशी बदलणे विनाशकारी असते. आधी normalise करणाऱ्या आणि पुराव्यासह denormalise करणाऱ्या teams आपले पर्याय टिकवतात; उलटा क्रम म्हणजे rewrite.

⏭️ पुढे

खोलीला चांगला आकार आला आहे — आता प्रश्न जलद करा: indexes, कार्ड कॅटलॉग, आणि EXPLAIN.

git checkout lesson-06-indexes

🧩 Lesson 05 — Data modelling: one fact, one place

📍 You are here: Lesson 05 of 18 · Previous: lesson-04-transactions · Next: lesson-06-indexes

📦 What's in this branch

Lessons 01–04, plus how to decide what the registers are: normalisation (one fact, one place), constraints as the written rules, and denormalisation — copying a fact on purpose, with a rule for keeping it true.

🧒 Explain like I'm 5

A new clerk suggests one giant register: every line has the student, the class, the teacher, the teacher's phone number, the grade, the subject… Easy to read! Then the teacher changes her phone number. That is thirty lines to fix, and the clerk fixes twenty-nine. For a year, one line lies.

The rule that prevents it: one fact, one place. The teacher's phone number lives in one line of a teachers register; students point at their class, classes point at their teacher. Change the number once and every question that joins through the pointer sees the new one. That is normalisation, and its three questions per register are:

What is one line? (one student — not one student-per-subject)
What identifies it? (the line number; roll number is UNIQUE)
Which facts belong to it, not to something it points at? (the student's name: yes; the class teacher's phone: no)

And the exception, made on purpose: sometimes a question is asked so often and joins so much that you copy a fact next to where it is read — a denormalised column — and you write down the rule that keeps the copy true (a trigger, a nightly job, or "only via this one function"). Copy with a reason and a rule, never by accident.

🗺️ Diagram

flowchart LR
    big["❌ one big register<br/>student · class · teacher · teacher phone · grade<br/>phone changes → 30 rows, 29 fixed"]
    norm["✅ one fact, one place<br/>teachers(id, name, phone) ← classes(teacher_id) ← students(class_id) ← grades(student_id)"]
    rules["🧩 constraints: NOT NULL · UNIQUE · CHECK · FK<br/>the schema refuses nonsense"]
    den["⚖️ denormalise on purpose<br/>copy a hot value + a rule that keeps it true"]
    big -->|"1 normalise"| norm --> rules
    norm -.->|"2 measured reason only"| den

❓ What

1NF: one value per cell (no "maths, science" in one column — that is a grades register). 2NF/3NF in practice: every non-key column describes the row's key and nothing else — if it describes something the row points at, it belongs over there.
Constraints are modelling: CHECK (term IN (1,2,3)), UNIQUE (student_id, subject, term), NOT NULL — the rules of the domain written into the shelf, enforced for every program.
Types matter: dates as ISO strings (2026-10-03) or DATE; money as integers in the smallest unit, never floats; booleans as 0/1 or BOOLEAN.
Denormalisation: a students.grade_count column updated by a trigger; a nightly class_summary table; a copied class_name on hot read paths. Allowed with a measured reason (lesson 12) and an owner for the rule.
Naming: tables plural (students), columns snake_case, foreign keys <thing>_id. Boring names are a kindness.

🤔 Why

Because the schema outlives every program that uses it. A well-modelled room lets a new question be one JOIN away; a badly-modelled one makes every new question a data clean-up first. And constraints turn "we should validate that somewhere" into "the shelf already does".

🔧 How (in this repo)

db/schema.sql is normalised: classes, students, grades, homework, each fact once, connected by keys, with UNIQUE and CHECK rules. model() in demo.py shows the shelf refusing two kinds of nonsense.

🧪 Try it — the capstone's first stone

# 1) add a teachers register, properly: in db/schema.sql
#    CREATE TABLE IF NOT EXISTS teachers (id INTEGER PRIMARY KEY, name TEXT NOT NULL, phone TEXT);
#    and give classes a pointer:  teacher_id INTEGER REFERENCES teachers(id)
# 2) seed one teacher per class in db/seed.sql, rebuild, and ask:
python3 db/demo.py model >/dev/null
python3 - <<'EOF'
import sqlite3; c = sqlite3.connect("db/school.db")
print(c.execute("SELECT s.name, t.name, t.phone FROM students s JOIN classes c ON c.id=s.class_id JOIN teachers t ON t.id=c.teacher_id ORDER BY s.name").fetchall())
c.execute("UPDATE teachers SET phone='000' WHERE id=1"); c.commit()     # change the fact ONCE
print(c.execute("SELECT DISTINCT t.phone FROM students s JOIN classes c ON c.id=s.class_id JOIN teachers t ON t.id=c.teacher_id WHERE c.id=1").fetchall())
EOF

✅ Verify — what you should see

Every 3A student's line shows the same teacher and phone; after one UPDATE on teachers, the joined query shows [('000',)] — one change, every student sees it. A duplicate roll number or a grade of Z is still refused.

🏁 What you just proved

You added a new kind of fact to the room in one place, connected it by a key, and changed it once for everyone — the modelling rule, felt.

⚠️ Common mistakes

comma-separated lists in a column ("maths, science") — that is a table
copying a name where a key belongs (class TEXT instead of class_id)
floats for money; strings for dates in three formats
denormalising "for speed" before measuring — and without a rule that keeps the copy true
modelling the screen instead of the domain — screens change monthly, the domain does not

🏭 Why this matters in production: schema design is the one decision that is cheap on day one and ruinous to change on day 400. Teams that normalise first and denormalise with evidence keep their options; the reverse order is a rewrite.

⏭️ Next

The room is well shaped — now make questions fast: indexes, the card catalogue, and EXPLAIN.

git checkout lesson-06-indexes

← Previoustransactions Next →indexes

This page is the lesson's README from the lesson-05-data-modelling branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.