1NF, 2NF और 3NF Examples के साथ

जिस एक table को normalize करेंगे

1NF, 2NF और 3NF सीखने का सबसे अच्छा तरीक़ा है एक अव्यवस्थित table लेकर उसे अपनी आँखों के सामने ठीक करना। नीचे एक student_marks table है ठीक वैसे जैसे कोई शुरुआती पहली बार डिज़ाइन करता — सब कुछ एक साथ ठुँसा हुआ।

यहाँ तीन अलग समस्याएँ छिपी हैं। subjects cell एक list रखती है। teacher का phone हर उस student के लिए दोहराता है जिसे teacher पढ़ाता है। और phone number असल में teacher का है, student row का नहीं। हम इन्हें एक-एक form करके साफ़ करेंगे।

चरण 1: 1NF में बदलें

1NF नियम: हर cell में एक अकेली value हो। subjects column इसे तोड़ता है, तो हम हर subject को अपनी अलग row में बाँटते हैं।

अब किसी cell में list नहीं, तो table 1NF में है। यहाँ स्वाभाविक key जोड़ी (student_id, subject) है, क्योंकि यही संयोजन एक ख़ास mark row पहचानता है। दो समस्याएँ बाक़ी हैं: student name दोहराता है, और teacher phone दोहराता है।

चरण 2: 2NF में बदलें

2NF नियम: 1NF में हो, और हर non-key column पूरी key पर निर्भर हो। हमारी key (student_id, subject) है। पर student_name सिर्फ़ student_id पर निर्भर है — यह partial dependency है। हम student के तथ्य अलग table में ले जाते हैं।

CREATE TABLE students (
    student_id   INT PRIMARY KEY,
    student_name VARCHAR(50)
);

CREATE TABLE marks (
    student_id INT,
    subject    VARCHAR(30),
    teacher    VARCHAR(50),
    teacher_phone VARCHAR(15),
    PRIMARY KEY (student_id, subject),
    FOREIGN KEY (student_id) REFERENCES students(student_id)
);

अब student name हर subject के बजाय हर student के लिए एक बार रखा है। Partial dependency ख़त्म, तो डिज़ाइन 2NF में है। पर marks देखिए: teacher का phone अब भी दोहराता है, और वह teacher पर निर्भर है, student-subject key पर नहीं।

चरण 3: 3NF में बदलें

3NF नियम: 2NF में हो, और कोई non-key column किसी दूसरे non-key column पर निर्भर न हो। marks में teacher_phone, teacher पर निर्भर है — दोनों non-key column हैं। यह transitive dependency है। हम teacher के तथ्य अलग table में निकालते हैं।

CREATE TABLE teachers (
    teacher       VARCHAR(50) PRIMARY KEY,
    teacher_phone VARCHAR(15)
);

CREATE TABLE marks (
    student_id INT,
    subject    VARCHAR(30),
    teacher    VARCHAR(50),
    PRIMARY KEY (student_id, subject),
    FOREIGN KEY (student_id) REFERENCES students(student_id),
    FOREIGN KEY (teacher)    REFERENCES teachers(teacher)
);

अब teacher का phone number ठीक एक जगह रहता है। इसे teachers में एक बार बदलिए और हर mark row तुरंत वही दिखाती है। Transitive dependency हट गई — डिज़ाइन 3NF में है।

अंतिम normalized डिज़ाइन

हमने एक भीड़-भरी table से शुरू किया और तीन साफ़ tables पर ख़त्म किया, हर एक एक ही तरह की चीज़ बताती है:

• students — student कौन है।
• teachers — teacher और उनका phone।
• marks — कौन student कौन-सा subject किस teacher के अधीन लेता है।

अब हर तथ्य एक जगह रहता है। न कोई student name, न teacher phone, कभी दो बार लिखा जाता है। यही 3NF डिज़ाइन देता है: update करते समय सुरक्षा, और पढ़ते समय स्पष्टता।

आमने-सामने तुलना

पैटर्न देखिए: हर चरण पर हमने पूछा "यह column असल में किस पर निर्भर है?" और उसे उसी चीज़ के पास ले गए जिससे वह जुड़ा है।

आम गलतियाँ

• 1NF जाँचे बिना 3NF पर कूदना। अगर कोई cell अब भी list रखती है, तो कोई बाद का form मान्य नहीं। पहले atomic value ठीक कीजिए।
• यह सोचना कि single-column key 2NF तोड़ सकती है। Partial dependency को composite key चाहिए। Single-column key वाली tables 1NF में आते ही 2NF में हैं।
• Foreign key छोड़ देना। Tables बाँटने के बाद उन्हें foreign key से जोड़िए, वरना link मान्य रहने की गारंटी खो जाती है।
• ऐसा data normalize करना जो कभी दोहराता ही नहीं। अगर column में कोई redundancy नहीं, तो उसे बाँटना बिना फ़ायदे के सिर्फ़ join जोड़ता है।

सारांश

• Forms क्रम में लगाइए: 1NF, फिर 2NF, फिर 3NF।
• 1NF: हमने multi-value subjects cell हटाया।
• 2NF: हमने student_name बाहर किया क्योंकि यह key के सिर्फ़ हिस्से पर निर्भर था।
• 3NF: हमने teacher_phone बाहर किया क्योंकि यह दूसरे non-key column पर निर्भर था।
• परिणाम: तीन केंद्रित tables जहाँ हर तथ्य एक बार रखा है।

अंतर्निहित सिद्धांत पढ़िए normalization in DBMS में, या इन tables को जोड़ने वाली keys सीखिए primary और foreign key में।