Normalizationنۆرماڵکردن

In Database keys you saw a table that mixed students and departments: one change had to be made in many rows, and deleting one row destroyed a different fact. Normalization is the step-by-step method that fixes this. It splits a table into smaller tables so that every fact is stored once, and keys join the pieces again whenever you need them.

لە کلیلەکانی بنکەدراوە خشتەیەکت بینی کە قوتابی و بەشەکانی تێکەڵ کردبوو: یەک گۆڕانکاری دەبوو لە چەندین ڕیزدا (Table row) بکرێت و سڕینەوەی یەک ڕیز ڕاستییەکی تری لەناو دەبرد. نۆرماڵکردن ئەو ڕێگا هەنگاو بە هەنگاوەیە کە ئەمە چاک دەکاتەوە. خشتەیەک لەت دەکات بۆ چەند خشتەیەکی بچووکتر، بۆ ئەوەی هەر ڕاستییەک تەنها یەک جار هەڵبگیرێت و کلیلەکان هەر کاتێک پێویستت بوو پارچەکان پێکەوە دەبەستنەوە.

Normalization does not remove every repetition. The columns that link the tables – the foreign keys – still repeat: CS appears in the row of every computer-science student. That small, planned repetition is called controlled redundancy: everything else is stored once.

نۆرماڵکردن هەموو دووبارەبوونەوەیەک لانابات. ئەو ستوونانەی (Field) خشتەکان (Table) دەبەستنەوە – کلیلە بیانییەکان – هێشتا دووبارە دەبنەوە: CS لە ڕیزی هەموو قوتابییەکی زانستی کۆمپیوتەردا دەردەکەوێت. ئەو دووبارەبوونەوە بچووک و پلان بۆ دانراوە پێی دەوترێت دووبارەبوونەوەی کۆنترۆڵکراو (controlled redundancy): هەموو شتێکی تر یەک جار هەڵدەگیرێت.

The office of a college in Sulaimani keeps the registrations of one semester in a single spreadsheet. There is one row for each student, and all of a student's courses are typed into one cell:

نووسینگەی کۆلێژێک لە سلێمانی تۆمارکردنەکانی یەک وەرز لە یەک بەرنامەی خشتەییدا (Spreadsheet) هەڵدەگرێت. بۆ هەر قوتابییەک یەک ڕیز هەیە و هەموو وانەکانی قوتابییەک لە یەک خانەدا نووسراون:

It looks tidy, but try to use it. 'Which students take WP101?' needs a text search inside every cell. No key can point to one course inside a cell. And 'Database Fundamentals (3)' is typed again for every student who takes it. We will normalize this sheet in three steps: 1NF, 2NF and 3NF.

ڕێکوپێک دەردەکەوێت، بەڵام هەوڵ بدە بەکاری بهێنیت. «کام قوتابییانە ⁦WP101⁩ دەخوێنن؟» پێویستی بە گەڕانی دەق لەناو هەموو خانەیەکدا هەیە. هیچ کلیلێک ناتوانێت ئاماژە بۆ یەک وانە لەناو خانەیەکدا بکات. هەروەها «⁦Database Fundamentals (3)⁩» بۆ هەر قوتابییەک کە دەیخوێنێت دووبارە دەنووسرێتەوە. ئەم پەڕەیە بە سێ هەنگاو نۆرماڵ دەکەین: ⁦1NF⁩، ⁦2NF⁩ و ⁦3NF⁩.

The rule of 1NF: every cell holds one atomic value. No lists in a cell, and no repeating groups of columns such as course1, course2, course3. It is the third of the three properties of a relation.

ڕێسای ⁦1NF⁩: هەموو خانەیەک یەک نرخی دابەشنەکراو هەڵدەگرێت. نە لیست لە خانەیەکدا، نە کۆمەڵە ستوونی دووبارەبووەوە وەک course1، course2، course3. ئەمە سێیەمیانە لە سێ تایبەتمەندییەکەی relation.

The 1NF table has one value per cell, but look at the repetition: 'Computer Science' four times, each course title twice, each student's name in every one of their rows. All three update anomalies of the course appear:

خشتە ⁦1NF⁩ـەکە یەک نرخی لە هەر خانەیەکدا هەیە، بەڵام سەیری دووبارەبوونەوەکە بکە: «⁦Computer Science⁩» چوار جار، ناونیشانی هەر وانەیەک دوو جار و ناوی هەر قوتابییەک لە هەموو ڕیزەکانیدا. هەر سێ جۆرەکەی ناڕێکیی نوێکردنەوە کە کۆرسەکە باسی کردوون دەردەکەون:

To remove these anomalies we need a precise way to say which column belongs with which. That tool is the functional dependency.

بۆ لابردنی ئەم ناڕێکییانە پێویستمان بە ڕێگایەکی ورد هەیە بۆ ئەوەی بڵێین کام ستوون لەگەڵ کامیاندا دەڕوات. ئەو ئامرازە وابەستەیی فەنکشنییە.

We write a functional dependency as X → Y and read it 'X determines Y'. It holds when any two rows that have the same value in X also have the same value in Y. X is called the determinant. In our table, course_code → course_title, credits: every row with DB101 says 'Database Fundamentals' and 3 credits.

وابەستەیی فەنکشنی بەم شێوەیە دەنووسین: X → Y و دەیخوێنینەوە «X، Y دیاری دەکات». کاتێک ڕاستە کە هەر دوو ڕیزێک لە Xدا هەمان نرخیان هەبێت، لە Yیشدا هەمان نرخیان هەبێت. X پێی دەوترێت دیاریکەر. لە خشتەکەماندا course_code → course_title, credits: هەموو ڕیزێک کە ⁦DB101⁩ی تێدایە دەڵێت «⁦Database Fundamentals⁩» و 3 یەکە.

The college's rules give four functional dependencies for registration:

ڕێساکانی کۆلێژەکە چوار وابەستەیی فەنکشنی بۆ registration دەدەن:

The only candidate key is (student_no, course_code), so student_no and course_code are the prime attributes; all the others are non-prime. Dependency 4 is fine: grade needs the whole key. Dependencies 1 and 3 are partial: a non-prime column needs only part of the key. Dependency 2 makes dept_name depend on the key only through dept_code: a transitive dependency. 2NF removes the first kind, 3NF the second.

تاکە کلیلی پاڵێوراو (student_no, course_code)ـە، بۆیە student_no و course_code خەسڵەتە سەرەتاییەکانن (Prime attribute)؛ هەموو ئەوانی تر خەسڵەتە ناسەرەتاییەکانن (Non-prime attribute). وابەستەیی ٤ باشە: grade پێویستی بە هەموو کلیلەکە هەیە. وابەستەییەکانی ١ و ٣ بەشەکین: ستوونێکی ناسەرەتایی تەنها پێویستی بە بەشێک لە کلیلەکە هەیە. وابەستەیی ٢ وا دەکات dept_name تەنها لە ڕێگەی dept_codeـەوە پشت بە کلیلەکە ببەستێت: وابەستەییەکی ناڕاستەوخۆیە. ⁦2NF⁩ جۆری یەکەم لادەبات و ⁦3NF⁩ جۆری دووەم.

The rule of 2NF: the table is in 1NF, and no non-prime attribute depends on only part of a candidate key. Every non-key column must depend on the whole key. A table whose candidate keys all have one column cannot break this rule; only tables with a composite key can.

ڕێسای ⁦2NF⁩: خشتەکە لە ⁦1NF⁩دایە و هیچ خەسڵەتێکی ناسەرەتایی تەنها پشت بە بەشێک لە کلیلێکی پاڵێوراو نابەستێت. هەموو ستوونێکی ناکلیلی دەبێت پشت بە هەموو کلیلەکە ببەستێت. خشتەیەک کە هەموو کلیلە پاڵێوراوەکانی یەک ستوون بن ناتوانێت ئەم ڕێسایە بشکێنێت؛ تەنها خشتەکانی خاوەن کلیلی لێکدراو (Composite key) دەتوانن.

Each course title is now stored once, and the new course AI301 can be added to course before anyone enrols. But 'Computer Science' is still written twice in student.

ئێستا ناونیشانی هەر وانەیەک تەنها یەک جار هەڵگیراوە و وانە نوێیەکەی ⁦AI301⁩ دەتوانرێت پێش تۆمارکردنی هەر کەسێک بخرێتە ناو course. بەڵام «⁦Computer Science⁩» هێشتا دوو جار لە studentدا نووسراوە.

The rule of 3NF: the table is in 2NF, and no non-prime attribute depends on a key through another non-key column (no transitive dependency). In student, student_no → dept_code → dept_name: the department's name is a fact about the department, not about the student.

ڕێسای ⁦3NF⁩: خشتەکە لە ⁦2NF⁩دایە و هیچ خەسڵەتێکی ناسەرەتایی لە ڕێگەی ستوونێکی تری ناکلیلییەوە پشت بە کلیل نابەستێت (هیچ وابەستەییەکی ناڕاستەوخۆ نییە). لە studentدا، student_no → dept_code → dept_name: ناوی بەش ڕاستییەکە دەربارەی بەشەکە، نەک دەربارەی قوتابییەکە.

The result is four tables — department, student, course and enrolment — exactly the database of the Database keys lesson. The three anomalies are gone: AI301 is added to course alone; deleting Shilan's enrolment keeps Shilan and the IT department; renaming WP101 changes one row.

ئەنجامەکە چوار خشتەیە — department، student، course و enrolment — ڕێک بنکەدراوەکەی وانەی کلیلەکانی بنکەدراوە. هەر سێ ناڕێکییەکە نەمان: ⁦AI301⁩ بە تەنها دەخرێتە ناو course؛ سڕینەوەی تۆمارکردنی شیلان، شیلان و بەشی IT دەهێڵێتەوە؛ گۆڕینی ناوی ⁦WP101⁩ یەک ڕیز دەگۆڕێت.

Each normal form includes the ones before it: a table in 3NF is also in 2NF and in 1NF. In daily work, 'normalized' usually means 'in 3NF' (or BCNF, next screen).

هەر شێوەیەکی نۆرماڵ ئەوانەی پێش خۆی لەخۆ دەگرێت: خشتەیەک کە لە ⁦3NF⁩دا بێت لە ⁦2NF⁩ و ⁦1NF⁩ـیشدایە. لە کاری ڕۆژانەدا «نۆرماڵکراو» زۆرجار واتە «لە ⁦3NF⁩دا» (یان BCNF، پەڕەی داهاتوو).

BCNF has one simple rule: every determinant must be a super key — for every dependency X → Y that is not trivial, X must identify the rows. 3NF allows one exception: when Y is a prime attribute, X need not be a super key. BCNF removes that exception. Our four university tables are already in BCNF: in each of them, the only determinant is the table's own key.

BCNF یەک ڕێسای سادەی هەیە: هەموو دیاریکەرێک دەبێت کلیلی باڵا بێت — بۆ هەموو وابەستەییەکی X → Y کە بێبایەخ نەبێت، X دەبێت ڕیزەکان بناسێنێت. ⁦3NF⁩ ڕێگە بە یەک بەدەرکردن دەدات: کاتێک Y خەسڵەتێکی سەرەتایی بێت، پێویست ناکات X کلیلی باڵا بێت. BCNF ئەو بەدەرکردنە لادەبات. چوار خشتەکەی زانکۆکەمان پێشتر لە BCNFدان: لە هەریەکەیاندا تاکە دیاریکەر کلیلی خودی خشتەکەیە.

Here is a table that is in 3NF but not in BCNF. The college gives students extra tutoring. Each student has one tutor per subject, and each tutor teaches only one subject:

ئەمە خشتەیەکە کە لە ⁦3NF⁩دایە بەڵام لە BCNFدا نییە. کۆلێژەکە وانەی بەهێزکردن بە قوتابییەکان دەدات. هەر قوتابییەک بۆ هەر بابەتێک یەک ڕاهێنەری هەیە و هەر ڕاهێنەرێک تەنها یەک بابەت دەڵێتەوە:

BCNF is about single facts. 4NF is about lists. Hana, a lecturer, sits on two committees (Exams, Library) and teaches two courses (DB101, WP101). The committees have nothing to do with the courses. Put both lists into one table and every committee must be paired with every course:

BCNF دەربارەی ڕاستیی تاکە. ⁦4NF⁩ دەربارەی لیستەکانە. هانا، کە مامۆستایە، ئەندامی دوو لیژنەیە (تاقیکردنەوە، کتێبخانە) و دوو وانە دەڵێتەوە (⁦DB101⁩، ⁦WP101⁩). لیژنەکان هیچ پەیوەندییەکیان بە وانەکانەوە نییە. ئەگەر هەردوو لیستەکە بخەیتە یەک خشتەوە، دەبێت هەموو لیژنەیەک لەگەڵ هەموو وانەیەکدا جووت بکرێت:

Textbooks call this a multivalued dependency, written lecturer →→ committee: one lecturer fixes a whole set of committees, whatever the courses. The rule of 4NF: a table is in BCNF and holds no two independent lists like this.

کتێبەکان بەمە دەڵێن وابەستەیی فرەنرخ، کە بەم شێوەیە دەنووسرێت lecturer →→ committee: یەک مامۆستا کۆمەڵێکی تەواوی لیژنەکان دیاری دەکات، هەر وانەیەک بێت. ڕێسای ⁦4NF⁩: خشتەکە لە BCNFدایە و دوو لیستی سەربەخۆی لەم جۆرە هەڵناگرێت.

The fix is one table for each independent list. Both keys are the whole row:

چارەسەرەکە یەک خشتەیە بۆ هەر لیستێکی سەربەخۆ. کلیلی هەردووکیان هەموو ڕیزەکەیە:

Four rows became $2+2$, and a third course now needs one new row. In E-R terms the two lists are two binary relationships, LECTURER–COMMITTEE and LECTURER–COURSE, not one ternary relationship: use a ternary only when the three things really belong together, as in a prescription.

چوار ڕیز بوونە $2+2$ و وانەی سێیەم ئێستا تەنها یەک ڕیزێکی نوێی پێویستە. بە زمانی مۆدێلی قەوارە و پەیوەندی (E-R model)، دوو لیستەکە دوو پەیوەندیی دووانین، ⁦LECTURER–COMMITTEE⁩ و ⁦LECTURER–COURSE⁩، نەک یەک پەیوەندیی سێیانی: پەیوەندیی سێیانی (Ternary relationship) تەنها کاتێک بەکار بهێنە کە سێ شتەکە بە ڕاستی پێکەوە بن، وەک لە ڕەچەتەیەکدا.

Every split must be reversible: when the new tables are joined again on their shared column (a natural join), we must get back exactly the original rows — no fewer, and no extra ones. Such a split is called lossless. A simple rule keeps it safe: the shared column must be a key of at least one of the new tables. In our steps, student_no is the key of student, course_code of course, and dept_code of department.

هەموو لەتکردنێک دەبێت بگەڕێتەوە: کاتێک خشتە نوێیەکان دووبارە لەسەر ستوونە هاوبەشەکەیان پێکەوە دەبەسترێنەوە (لێکبەستنی سروشتی)، دەبێت ڕێک ڕیزە ئەسڵییەکان وەربگرینەوە — نە کەمتر و نە ڕیزی زیادە. لەتکردنێکی وا پێی دەوترێت lossless (بێ لەدەستدان). ڕێسایەکی سادە دەیپارێزێت: ستوونە هاوبەشەکە دەبێت کلیلی بەلایەنی کەمەوە یەکێک لە خشتە نوێیەکان بێت. لە هەنگاوەکانماندا student_no کلیلی studentـە، course_code کلیلی course و dept_code کلیلی department.

A bad split shows why. Two different students are both called Aram Kamal: 2024-0137 in CS and 2025-0311 in SE. If we split them into (student_no, student_name) and (student_name, dept_code), the shared column student_name is a key of neither table. Joining again on the name gives four rows, and two of them are false:

لەتکردنێکی خراپ هۆکارەکە پیشان دەدات. دوو قوتابیی جیاواز هەردووکیان ناویان ئارام کەمالە: ⁦2024-0137⁩ لە CS و ⁦2025-0311⁩ لە SE. ئەگەر بیانکەین بە (student_no, student_name) و (student_name, dept_code)، ستوونە هاوبەشەکە، student_name، کلیلی هیچ کامیان نییە. دووبارە بەستنەوەیان لەسەر ناو چوار ڕیز دەدات و دووانیان هەڵەن: