Chapterبەش 4 · Lectureوانە 4.1

Database Keysکلیلەکانی بنکەدراوە

The ten keys that hold a relational database together and the rules that protect them: super, candidate, primary and alternate keys; foreign keys and referential integrity; partial, composite, unique, surrogate and secondary keys. All on one university example, with the course material's mistakes corrected.

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

48 min read47 خولەک خوێندنەوە · 34 stepsهەنگاو

What you will learnچی فێر دەبیت

Explain what a key is, why a table needs one, and why some keys link or search instead of identifying rows.
Find the super keys and candidate keys of a table, choose a primary key and name the alternate keys.
Link tables with foreign keys and explain referential integrity, including what happens on DELETE and UPDATE.
Tell apart partial, composite, unique, surrogate, natural and secondary keys.
Declare keys in SQL with PRIMARY KEY, UNIQUE, FOREIGN KEY, NOT NULL and CHECK.
Recognise the common mistakes about keys that course notes often repeat.

ڕوونی بکەیتەوە چییە، بۆچی خشتە پێویستی پێیەتی و بۆچی هەندێک لە جیاتی ناساندنی ، دەبەستنەوە یان گەڕانی تێدا دەکەن.
و خشتەیەک بدۆزیتەوە، هەڵبژێریت و ناو ببەیت.
خشتەکان بە ببەستیتەوە و ڕوون بکەیتەوە، لەوانە ئەوەی لە کاتی DELETE و UPDATEدا چی ڕوو دەدات.
، ، ، ، و لێک جیا بکەیتەوە.
لە SQLدا بە ⁦PRIMARY KEY⁩، UNIQUE، ⁦FOREIGN KEY⁩، ⁦NOT NULL⁩ و CHECK ڕابگەیەنیت.
ئەو هەڵە باوانەی دەربارەی بناسیتەوە کە تێبینییەکانی کۆرس زۆرجار دووبارەیان دەکەنەوە.

Keys: how a database tells rows apartکلیلەکان: بنکەدراوە چۆن ڕیزەکان لێک جیا دەکاتەوە

A university in Sulaimani may have 20,000 students, and several of them can share a name: there is more than one Aram Kamal in the city. Still, the database must find exactly one student, change exactly one grade and connect every grade to the right person. Keys make this possible.

زانکۆیەک لە سلێمانی لەوانەیە ٢٠٬٠٠٠ قوتابیی هەبێت و چەند دانەیەکیان دەکرێت هەمان ناویان هەبێت: لە شارەکەدا زیاتر لە یەک «ئارام کەمال» هەیە. لەگەڵ ئەوەشدا دەبێت تەنها یەک قوتابی بدۆزێتەوە، تەنها یەک نمرە بگۆڕێت و هەموو نمرەیەک بە کەسە ڕاستەکەوە ببەستێتەوە. ئەمە بە هۆی دەکرێت.

This lesson follows Module 4 of the course. First it shows what a good table design looks like. Then it teaches the ten keys: super, candidate and primary keys; alternate, foreign and partial keys; composite, unique, surrogate and secondary keys. The key slides of Module 2 (key attribute, primary, super, alternate, unique and foreign key) are merged in here, so every key is taught once.

ئەم وانەیە پەیڕەوی مۆدیوڵی ٤ی کۆرسەکە دەکات. سەرەتا پیشان دەدات دیزاینێکی باشی چۆنە. پاشان دە فێر دەکات: ، و ؛ ، و ؛ ، ، و . ئەو سلایدانەی مۆدیوڵی ٢ کە باسی دەکەن (، ، ، ، و ) لێرەدا تێکەڵ کراون، بۆ ئەوەی هەر تەنها یەک جار بخوێنرێت.

Finding a house in Sulaimaniدۆزینەوەی خانوویەک لە سلێمانی

A letter carrier cannot deliver a letter to 'Kamal's house': many houses belong to someone called Kamal. The street name alone is not enough either. Street + house number is enough, because no two houses in one street share a number. That pair is a key for houses. The address on the envelope is like a foreign key: it does not describe the house, it points to it.

نامەبەر ناتوانێت نامەیەک بگەیەنێتە «ماڵی کەمال»: زۆر خانوو هی کەسێکن بە ناوی کەمال. ناوی شەقامیش بە تەنها بەس نییە. شەقام + ژمارەی خانوو بەسە، چونکە لە یەک شەقامدا دوو خانوو هەمان ژمارەیان نییە. ئەو جووتە بۆ خانووەکان. ناونیشانی سەر زەرفەکەش وەک وایە: باسی خانووەکە ناکات، بەڵکو ئاماژەی بۆ دەکات.

Where the analogy stops workingسنووری ئەم نموونەیە

Real addresses change, and some houses have no number. In a database a key must always have a value and should not change, so designers choose keys more carefully than a city names its streets.

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

Good design comes firstسەرەتا دیزاینی باش

Before it names any key, the course says what a good table (a relational schema) should look like. Keys are the tools that reach these goals.

پێش ئەوەی ناوی هیچ بهێنێت، کۆرسەکە دەڵێت باش ( پەیوەندیدار) دەبێت چۆن بێت. ئەو ئامرازانەن کە ئەم ئامانجانە دەپێکن.

Easy-to-explain meaning (semantics). Anyone should be able to say in one sentence what one row means, for example 'one row = one student'.
As little repeated (redundant) data as possible. Repetition wastes space and causes update anomalies (next screen).
As few NULL values as possible. Fewer NULLs use space better and reduce the need for outer joins, which cost extra work.

واتایەک کە ئاسان ڕوون بکرێتەوە. هەر کەسێک دەبێت بتوانێت بە یەک ڕستە بڵێت یەک چی دەگەیەنێت، بۆ نموونە «یەک = یەک قوتابی».
کەمترین . دووبارەبوونەوە شوێن بە فیڕۆ دەدات و دەبێتە هۆی (پەڕەی داهاتوو).
کەمترین نرخی NULL. NULLی کەمتر شوێن باشتر بەکار دەهێنێت و پێویستی بە کەم دەکاتەوە، کە کاری زیاتریان دەوێت.

Good design comes firstسەرەتا دیزاینی باش

Three update anomaliesسێ ناڕێکیی نوێکردنەوە

Here is a badly designed table. It stores students and their departments together, so a department's name is repeated in every row of that department.

ئەمە خراپ دیزاینکراوە. قوتابییەکان و بەشەکانیان پێکەوە هەڵدەگرێت، بۆیە ناوی هەر بەشێک لە هەموو ئەو بەشەدا دووبارە دەبێتەوە.

student_dept — one table for two kinds of fact (a bad design)⁦student_dept⁩ — یەک بۆ دوو جۆر ڕاستی (دیزاینێکی خراپ)
`student_no`	`full_name`	`dept_code`	`dept_name`
2024-0137	Aram Kamal	CS	Computer Science
2024-0152	Shilan Omar	IT	Information Technology
2024-0188	Karwan Aziz	CS	Computer Science
2024-0190	Aram Salih	SE	Software Engineering

The course names three update anomalies. Each is a way in which repeated data goes wrong:

کۆرسەکە ناوی سێ دەهێنێت. هەریەکەیان ڕێگایەکە کە تێیدا دووبارەکراو تێک دەچێت:

Insertion anomaly — you cannot add one fact without also inventing another. The university opens a new department, CY (Cyber Security). It has no students yet, so no row can hold its name: student_no cannot be empty.
Deletion anomaly — removing one row accidentally destroys a different fact. Shilan is the only IT student. When she graduates and her row is deleted, the database also forgets that IT means Information Technology.
Modification anomaly — one change has to be repeated in many rows, and one gets missed. If CS is renamed, every CS row must change. Miss one, and the database shows two different names for the same department.

— ناتوانیت ڕاستییەک زیاد بکەیت بەبێ ئەوەی ڕاستییەکی تریش دابهێنیت. زانکۆ بەشێکی نوێ دەکاتەوە، ⁦CY (Cyber Security)⁩. هێشتا هیچ قوتابییەکی نییە، بۆیە هیچ نییە ناوەکەی هەڵبگرێت: student_no ناتوانێت بەتاڵ بێت.
— سڕینەوەی یەک بە هەڵە ڕاستییەکی تر لەناو دەبات. شیلان تاکە قوتابیی بەشی ITـە. کاتێک دەردەچێت و دەسڕدرێتەوە، ئەوەش لە بیر دەکات کە IT واتە ⁦Information Technology⁩.
— یەک گۆڕانکاری دەبێت لە چەندین دووبارە بکرێتەوە و یەکێکیان لە بیر دەچێت. ئەگەر ناوی CS بگۆڕدرێت، دەبێت هەموو CS بگۆڕدرێت. ئەگەر یەکێکیان لە بیر بچێت، دوو ناوی جیاواز بۆ هەمان بەش پیشان دەدات.

Quick checkپشکنینی خێراThe last student enrolled in WP101 drops the course. Her row is deleted, and with it the only place that stored the course title 'Web Programming'. Which anomaly is this?دوایین قوتابی کە لە ⁦WP101⁩ تۆمار کرابوو وانەکە بەجێ دەهێڵێت. دەسڕدرێتەوە و لەگەڵیدا تاکە شوێنێک کە ناونیشانی وانەکەی («⁦Web Programming⁩») تێدا بوو. ئەمە کام ناڕێکییە؟Deletion anomalyناڕێکیی سڕینەوەInsertion anomalyناڕێکیی زیادکردنModification anomalyناڕێکیی گۆڕین

Good design comes firstسەرەتا دیزاینی باش

Why as few NULLs as possible?بۆچی تا بکرێت NULLی کەمتر؟

NULL means that a cell has no value. Many NULLs waste space and make questions to the database harder. For example, to list all students together with their courses, including students who have no course yet, you need an outer join: a join that also keeps the rows that have no partner in the other table and fills the gaps with NULL. You meet it in Relational algebra and calculus.

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

A value that almost nobody hasنرخێک کە بە دەگمەن هەیە

If only a few rows will ever have a value – say 1 student in 100 has a sports scholarship – do not add a mostly-NULL column to student. Give it a small table of its own, scholarship(student_no, scholarship_name), with one row for each student who has one. It is linked 1:1 to student, and nobody else needs a NULL.

ئەگەر تەنها چەند هەرگیز نرخیان دەبێت – بۆ نموونە لە هەر ⁦100⁩ قوتابییەک یەکێکیان بورسی وەرزشیی هەیە – پڕ لە NULL مەخەرە سەر student. بچووکی تایبەتی بدەرێ، scholarship(student_no, scholarship_name)، بە یەک بۆ هەر قوتابییەک کە بورسی هەیە. بە 1:1 بە studentـەوە دەبەسترێتەوە و کەسی تر پێویستی بە NULL نابێت.

Quick checkپشکنینی خێراWhy does the course want as few NULL values as possible?بۆچی کۆرسەکە دەیەوێت تا بکرێت نرخی NULL کەمتر بێت؟Because a table with NULLs cannot have a primary keyچونکە خشتەیەک کە NULLی تێدا بێت ناتوانێت کلیلێکی سەرەکیی هەبێتBecause SQL does not allow NULL at allچونکە SQL هەرگیز ڕێگە بە NULL ناداتTo use space well, to avoid extra outer joins, and because a NULL can mean more than one thingبۆ بەکارهێنانی باشی شوێن، دوورکەوتنەوە لە لێکبەستنە دەرەکییەکان زیادە و چونکە NULL دەکرێت زیاتر لە یەک واتای هەبێت

Our example: a university in Sulaimaniنموونەکەمان: زانکۆیەک لە سلێمانی

All through this lesson we use one small database of a university in Sulaimani. It has four tables:

لە سەرانسەری ئەم وانەیەدا بچووکی زانکۆیەک لە سلێمانی بەکار دەهێنین. چوار هەیە:

department: one row for each department (CS, IT, SE).
student: one row for each student, with the student number, national ID number, university email, name, date of birth, phone and department.
course: one row for each course. A course may need another course first (its prerequisite).
enrolment: one row each time a student takes a course in a semester, with the grade.

department: یەک بۆ هەر بەشێک (CS، IT، SE).
student: یەک بۆ هەر قوتابییەک، لەگەڵ ژمارەی قوتابی، ژمارەی کارتی نیشتمانی، زانکۆ، ناو، ڕێکەوتی لەدایکبوون، ژمارەی مۆبایل و بەش.
course: یەک بۆ هەر وانەیەک. لەوانەیە وانەیەک پێویستی بە وانەیەکی تر بێت پێش خۆی (prerequisite).
enrolment: هەر جارێک قوتابییەک لە وەرزێکدا وانەیەک دەخوێنێت، یەک لەگەڵ نمرەکەی.

The four tables of our example and the keys we will meet. Every arrow is a foreign key.چوار خشتەکەی نموونەکەمان و ئەو دەیانبینین. هەموو تیرێک .CêIT

What is a key?کلیل چییە؟

Definitionپێناسە

An attribute, or a set of attributes, that identifies each (tuple) of a uniquely or links tables together. The course teaches ten kinds, from the to the .

خەسڵەتێک یان کۆمەڵە خەسڵەتێکە کە هەر بە تەنها دەناسێنێت یان خشتەکان بەیەکەوە دەبەستێت. کۆرسەکە دە جۆری دەخوێنێت، لە تا .

The course defines it like this: a DBMS key is an attribute, or a set of attributes, which helps you identify a tuple (a record or row) of data in a relation (a table) uniquely. Keys are also used to build relationships between the different tables and columns of a relational database.

کۆرسەکە بەم شێوەیە دەیناسێنێت: (خەسڵەتێک) یان کۆمەڵە کە یارمەتیت دەدات هەر ( یان tuple) لە (relation) بە تەنها بناسێنیت. هەروەها بۆ دروستکردنی پەیوەندی لە نێوان خشتە و جیاوازەکانی بەکار دێن.

The course lists ten important keys. The picture sorts them by the job they do:

کۆرسەکە دە گرنگ ڕیز دەکات. وێنەکە بەپێی ئەو ئەرکەی هەریەکەیان دەیکات ڕیزیان دەکات:

The ten keys of the course, grouped by what they are for. Redrawn from the course's 'different kinds of keys' picture (which spelled 'Foriegn').دە کۆرسەکە، بەپێی ئەوەی بۆ چین. لە وێنەی «جۆرە جیاوازەکانی »ی کۆرسەکەوە دووبارە کێشراوەتەوە (کە «Foriegn»ی بە هەڵە نووسیبوو).CêIT

Not every key identifies a rowهەموو کلیلێک ڕیز ناناسێنێت

The course's definition says that a key identifies a row uniquely. That is true for seven of the ten. A foreign key links a row to another row, and its values repeat. A partial key identifies a row only together with its owner's key. A secondary key only helps searching. So a better definition is: a key is a column, or set of columns, with a special job; most keys identify rows, some link or search them. Also: Module 2 listed seven keys, Module 4 lists ten. The standard textbooks build the theory on super, candidate, primary, foreign and partial keys; the other five names are used more loosely, and books and products do not always mean exactly the same by them. You will meet all of them at work.

پێناسەکەی کۆرسەکە دەڵێت بە تەنها دەناسێنێت. ئەمە بۆ حەوت لە دە ڕاستە. بە ترەوە دەبەستێت و نرخەکانی دووبارە دەبنەوە. تەنها لەگەڵ کلیلی خاوەنەکەیدا دەناسێنێت. تەنها یارمەتیی گەڕان دەدات. بۆیە پێناسەیەکی باشتر ئەمەیە: یان کۆمەڵە کە ئەرکێکی تایبەتی هەیە؛ زۆربەی دەناسێنن، هەندێکیان دەبەستنەوە یان گەڕانی تێدا دەکەن. هەروەها: مۆدیوڵی ٢ حەوت ڕیز دەکات و مۆدیوڵی ٤ دە دانە. کتێبە ستانداردەکان تیۆرییەکە لەسەر ، ، ، و بنیات دەنێن؛ پێنج ناوەکەی تر بە شێوەیەکی ئازادتر بەکار دێن و هەموو کتێب و بەرهەمێک ڕێک هەمان مانایان پێ نادات. لە کاردا هەموویان دەبینیت.

1. Super key١. کلیلی باڵا

Definitionپێناسە

Any set of attributes that identifies each of a table uniquely. It may contain extra attributes that are not needed; the smallest super keys are the .

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

A super key is a set of attributes that can identify each tuple uniquely in the relation. It is not limited to any number of attributes: it may have one column, two, or all of them.

کۆمەڵە کە دەتوانێت هەر لە بە تەنها بناسێنێت. بە هیچ ژمارەیەکی دیاریکراوی خەسڵەت سنووردار نییە: دەکرێت یەک ، دوو یان هەموو تێدا بێت.

student (four rows of our example)student (چوار لە نموونەکەمان)
`student_no`	`national_id`	`email`	`full_name`	`birth_date`	`dept_code`
2024-0137	N-48213	aram.kamal@uni.example	Aram Kamal	2005-03-14	CS
2024-0152	`NULL`	shilan.omar@uni.example	Shilan Omar	2006-01-09	IT
2024-0188	N-50977	karwan.aziz@uni.example	Karwan Aziz	2005-11-30	CS
2024-0190	`NULL`	aram.salih@uni.example	Aram Salih	2006-06-02	SE

Which sets of columns are super keys here? Think about the university's rules, not only about these four rows:

لێرەدا کام کۆمەڵە ؟ بیر لە ڕێساکانی زانکۆ بکەرەوە، نەک تەنها لەم چوار :

{student_no} — the university never gives the same number twice.
{email} — every student gets an email address of their own.
{student_no, full_name} and {email, birth_date} — still unique, but they carry a column that is not needed.
All six columns together — the whole row is never repeated.
Not super keys: {full_name} (there are two students called Aram), {dept_code} (many students per department) and {full_name, birth_date} (unique today, but no rule of the university promises it).

{student_no} — زانکۆ هەرگیز هەمان ژمارە دوو جار نادات.
{email} — هەموو قوتابییەک تایبەت بە خۆی وەردەگرێت.
{student_no, full_name} و {email, birth_date} — هێشتا یەکتان، بەڵام تێدایە کە پێویست نییە.
هەر شەش پێکەوە — هەموو هەرگیز دووبارە نابێتەوە.
نین: {full_name} (دوو قوتابی ناویان ئارامە)، {dept_code} (هەر بەشێک چەندین قوتابیی هەیە) و {full_name, birth_date} (ئەمڕۆ یەکتایە، بەڵام هیچ ڕێسایەکی زانکۆ بەڵێنی ئەوە نادات).

This gives a handy rule: add any column to a super key and you still have a super key. {student_no} is a super key, so {student_no, phone}, {student_no, phone, birth_date} and every other set that contains student_no are super keys too. The opposite is not true: taking a column away can break it.

ئەمە یاسایەکی بەسوودمان دەداتێ: هەر بخەیتە سەر ، هێشتا . {student_no} ، بۆیە {student_no, phone}، {student_no, phone, birth_date} و هەموو کۆمەڵەیەکی تر کە student_noـی تێدا بێت . پێچەوانەکەی ڕاست نییە: لابردنی دەکرێت بیشکێنێت.

1. Super key١. کلیلی باڵا

The course's examplesنموونەکانی کۆرسەکە

The course uses a school class list: Student(roll, name, sex, age, address, class, section). Roll numbers start again at 1 in every class and section, so roll alone is not enough. Each of these sets identifies a pupil, so each is a super key:

کۆرسەکە لیستی پۆلێکی قوتابخانە بەکار دەهێنێت: Student(roll, name, sex, age, address, class, section). ژمارەی ڕیز ⁦(roll)⁩ لە هەر پۆل و هۆبەیەکدا لە 1ەوە دەست پێدەکاتەوە، بۆیە roll بە تەنها بەس نییە. هەریەکە لەم کۆمەڵانە قوتابییەک دەناسێنێت، بۆیە هەریەکەیان :

(roll, name, sex, age, address, class, section) — all the attributes
(class, section, roll)
(class, section, roll, sex)
(name, address)

(roll, name, sex, age, address, class, section) — هەموو خەسڵەتەکان
(class, section, roll)
(class, section, roll, sex)
(name, address)

Keys come from rules, not from today's rowsکلیلەکان لە ڕێساکانەوە دێن، نەک لە ڕیزەکانی ئەمڕۆ

(name, address) is a super key only if the school's rules make sure that no two pupils with the same name live at the same address. Twins or cousins could break this. A set of columns is a key only when the real world guarantees it, not because the rows in the table happen to be different today.

(name, address) تەنها کاتێک کە ڕێساکانی قوتابخانە دڵنیا بکەنەوە کە هیچ دوو قوتابییەک بە هەمان ناو لە هەمان ناونیشاندا ناژین. دووانە یان ئامۆزاکان دەتوانن ئەمە تێک بدەن. کۆمەڵە تەنها کاتێک کە جیهانی ڕاستەقینە زامنی بکات، نەک لەبەر ئەوەی خشتەکە ئەمڕۆ بە ڕێکەوت جیاوازن.

Module 2 gives one more example: Apartment(street, number, floor, flat, size, number_of_rooms, year). The whole set identifies one flat, so it is a super key. Smaller sets work too. (street, number, floor, flat) finds the building by street and number, then the flat by floor and flat number. If the flats in a building are numbered 1, 2, 3 … without starting again on each floor, (street, number, flat) is already enough. size, number_of_rooms and year only describe the flat: adding them still gives a super key, but they are not needed.

مۆدیوڵی ٢ نموونەیەکی تر دەدات: Apartment(street, number, floor, flat, size, number_of_rooms, year). هەموو کۆمەڵەکە یەک شوقە دەناسێنێت، بۆیە . کۆمەڵەی بچووکتریش کار دەکەن. (street, number, floor, flat) باڵەخانەکە بە شەقام و ژمارە دەدۆزێتەوە، پاشان شوقەکە بە نهۆم و ژمارەی شوقە. ئەگەر شوقەکانی باڵەخانەیەک بە 1، 2، 3 … ژمارە کرابن بەبێ ئەوەی لە هەر نهۆمێکدا لە سەرەتاوە دەست پێبکەنەوە، (street, number, flat) بەسە. size، number_of_rooms و year تەنها باسی شوقەکە دەکەن: زیادکردنیان هێشتا دەدات، بەڵام پێویست نین.

Quick checkپشکنینی خێراIs {dept_code, full_name} a super key of our student table?ئایا {dept_code, full_name} خشتەی studentـی ئێمەیە؟Yes, because no two of the four rows share both valuesبەڵێ، چونکە هیچ دوو ڕیزێک لە چوار ڕیزەکە هەردوو نرخیان وەک یەک نییەNo, because nothing stops two students with the same name from being in the same departmentنەخێر، چونکە هیچ شتێک ڕێگە ناگرێت لەوەی دوو قوتابی بە هەمان ناو لە هەمان بەشدا بن

2. Candidate key٢. کلیلی پاڵێوراو

Definitionپێناسە

A minimal : if you remove any attribute from it, it no longer identifies each row. Its value is always unique and never NULL. A table can have several; one of them becomes the .

کە هیچ خەسڵەتێکی زیادەی تێدا نییە: ئەگەر هەر خەسڵەتێکی لێ لابەریت، ئیتر هەموو ڕیزەکان بە تەنها ناناسێنێت. نرخەکەی هەمیشە یەکتایە و هەرگیز NULL نییە. خشتەیەک دەکرێت چەند دانەیەکی هەبێت؛ یەکێکیان دەبێتە .

A minimal super key is called a candidate key: the smallest set of attributes that can still identify each tuple uniquely. In our student table, {student_no} and {email} are candidate keys. {student_no, full_name} is not: remove full_name and student_no still works alone.

کە کەمترین خەسڵەتی تێدا بێت پێی دەوترێت : بچووکترین کۆمەڵە خەسڵەت کە هێشتا دەتوانێت هەر بە تەنها بناسێنێت. لە خشتەی studentـی ئێمەدا، {student_no} و {email} . {student_no, full_name} وا نییە: full_name لاببە و student_no هێشتا بە تەنها کار دەکات.

All the attributes in a candidate key are sufficient and necessary to identify each tuple.
Removing any attribute from a candidate key means it can no longer identify each tuple.
The value of a candidate key must always be unique.
The value of a candidate key can never be NULL.
A relation can have several candidate keys.

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

In the course's school example, (class, section, roll) and (name, address) are both candidate keys. Remove roll from the first and it fails: one section has many pupils.

لە نموونەی قوتابخانەکەی کۆرسەکەدا، (class, section, roll) و (name, address) هەردووکیان . roll لە یەکەمیان لاببە و ئیتر کار ناکات: یەک هۆبە چەندین قوتابیی هەیە.

The attributes that appear in some candidate key are called prime attributes. In student, student_no and email are prime; full_name, birth_date and dept_code are not. You need this word for normalization (second normal form).

ئەو خەسڵەتانەی لە هەن پێیان دەوترێت . لە studentدا، student_no و email سەرەتایین؛ full_name، birth_date و dept_code سەرەتایی نین. ئەم وشەیە بۆ پێویستە (شێوەی نۆرماڵی دووەم).

Quick checkپشکنینی خێراWhich statement about candidate keys is true?کام ڕستە دەربارەی ڕاستە؟It must be a single column.دەبێت تەنها یەک ستوون بێت.If you remove any column from it, it stops identifying the rows.ئەگەر هەر ستوونێکی لێ لاببەیت، ئیتر ڕیزەکان ناناسێنێت.A table has exactly one candidate key.هەر خشتەیەک تەنها یەک کلیلی پاڵێوراوی هەیە.It may contain NULL values.دەکرێت نرخی NULLی تێدا بێت.

3. Primary key٣. کلیلی سەرەکی

Definitionپێناسە

A (or group of fields) whose value is different in every , so it identifies each row. It can never be empty; an id column with is the usual choice.

ستوونێکە (یان چەند ستوونێک) کە هیچ دوو هەمان نرخیان تێیدا نییە، بۆیە هەر ڕیزێک بە تەنها دەناسێنێت. هەرگیز بەتاڵ نابێت؛ ستوونی id لەگەڵ هەڵبژاردنی باوە.

A primary key is the candidate key that the database designer selects and implements. It is a column, or a set of columns, that identifies every record in the table uniquely. Our designer picks student_no rather than email: it is short, it is printed on every student card, and it never changes. An email address can change, for example when the university moves to a new email domain.

کە دیزاینەری هەڵیدەبژێرێت و جێبەجێی دەکات. یان کۆمەڵە کە هەموو لە خشتەکەدا بە تەنها دەناسێنێت. دیزاینەرەکەمان student_no هەڵدەبژێرێت نەک email: کورتە، لەسەر هەموو کارتێکی قوتابی چاپ کراوە و هەرگیز ناگۆڕێت. دەکرێت بگۆڕێت، بۆ نموونە کاتێک زانکۆ دەچێتە سەر دۆمەینێکی نوێی .

The value of a primary key can never be NULL.
The value of a primary key must always be unique: no repetitions.
The value must be given when a record is inserted.
A table has only one primary key (one PRIMARY KEY constraint). That one key may have several columns.
The PRIMARY KEY (PK) constraint on a column or set of columns allows no NULL values and no duplicates.

نرخی هەرگیز ناتوانێت NULL بێت.
نرخی دەبێت هەمیشە یەکتا بێت: هیچ دووبارەبوونەوەیەک نییە.
نرخەکە دەبێت لە کاتی زیادکردنی بدرێت.
هەر خشتەیەک تەنها یەک هەیە (تەنها یەک ⁦PRIMARY KEY⁩). ئەو یەک کلیلە دەکرێت چەند هەبێت.
⁦PRIMARY KEY (PK)⁩ لەسەر یان کۆمەڵە ڕێگە بە هیچ NULLێک و هیچ دووبارەیەک نادات.

Every primary key is a candidate key, and every candidate key is a super key. Redrawn from the course's 'super key, candidate key, primary key' picture, with our example added.هەموو و هەموو . لە وێنەی «، ، »ی کۆرسەکەوە دووبارە کێشراوەتەوە و نموونەکەمانی بۆ زیاد کراوە.CêIT

3. Primary key٣. کلیلی سەرەکی

Choosing a good primary keyهەڵبژاردنی کلیلێکی سەرەکیی باش

Short, stable – and never private dataکورت، جێگیر – و هەرگیز دراوەی تایبەت نا

A primary key is copied into every table that points to it, and it appears in reports, forms and web addresses. So choose a key that is short, stable and means nothing to an outsider. Never use private data such as a national ID number, a passport number or a phone number: it would spread into every corner of the database, and it can change.

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

Quick checkپشکنینی خێراA hospital in Duhok needs a primary key for its patients. Which is best?نەخۆشخانەیەک لە دهۆک بۆ نەخۆشەکانی پێویستە. کامیان باشترە؟The patient's phone numberژمارەی مۆبایلی نەخۆشەکەA file number that the hospital gives each patientژمارەی دۆسیەیەک کە نەخۆشخانەکە بە هەر نەخۆشێک دەداتThe patient's national ID numberژمارەی کارتی نیشتمانیی نەخۆشەکە

3. Primary key٣. کلیلی سەرەکی

The primary key in SQLکلیلی سەرەکی لە SQLدا

In SQL you declare the primary key when you create the table. From then on the DBMS checks both rules on every INSERT and UPDATE, and it builds an index on the key automatically so that rows are found quickly by it.

لە SQLدا لە کاتی دروستکردنی خشتەکەدا ڕادەگەیەنیت. لەوە بەدواوە لە هەموو INSERT و UPDATEێکدا هەردوو ڕێساکە دەپشکنێت و بە شێوەیەکی خۆکار لەسەر کلیلەکە دروست دەکات بۆ ئەوەی بە خێرایی پێی بدۆزرێنەوە.

Declaring a primary key and testing its two rules (MySQL)ڕاگەیاندنی کلیلی سەرەکی و تاقیکردنەوەی دوو ڕێساکەی ⁦(MySQL)⁩SQLRuns in the databaseلە ناو بنکەدراوە کار دەکات

CREATE TABLE student (
  student_no  CHAR(9)      PRIMARY KEY,
  full_name   VARCHAR(100) NOT NULL
);

INSERT INTO student VALUES ('2024-0137', 'Aram Kamal');   -- accepted
INSERT INTO student VALUES ('2024-0137', 'Dilan Hama');   -- same number again
INSERT INTO student VALUES (NULL, 'Dilan Hama');          -- no number at all

Explain the codeڕوونکردنەوەی کۆدەکە

Lineدێڕی 2

PRIMARY KEY = unique + NOT NULL, and one per table.

PRIMARY KEY = یەکتا + NOT NULL؛ هەر خشتەیەک تەنها یەک دانەی هەیە.

Lineدێڕی 7

Breaks 'never repeated'.

ڕێسای «هەرگیز دووبارە نابێتەوە» دەشکێنێت.

Lineدێڕی 8

Breaks 'never NULL'.

ڕێسای «هەرگیز NULL نییە» دەشکێنێت.

SQLite is different hereSQLite لێرەدا جیاوازە

The SQL standard says that PRIMARY KEY always means NOT NULL. Because of an old bug that was kept for compatibility, SQLite accepts NULL in most PRIMARY KEY columns, so in SQLite write NOT NULL PRIMARY KEY. An INTEGER PRIMARY KEY column is a special case: it never stores NULL, but it does not refuse one either. SQLite silently puts the next free number there instead (normally one more than the largest), so a test 'insert a row without a key' succeeds:

ستانداردی SQL دەڵێت ⁦PRIMARY KEY⁩ هەمیشە واتە ⁦NOT NULL⁩. لەبەر هەڵەیەکی کۆن کە بۆ گونجاندن هێڵراوەتەوە، لە زۆربەی ⁦PRIMARY KEY⁩دا NULL وەردەگرێت، بۆیە لە NOT NULL PRIMARY KEY بنووسە. INTEGER PRIMARY KEY حاڵەتێکی تایبەتە: هەرگیز NULL هەڵناگرێت، بەڵام ڕەتیشی ناکاتەوە. بێدەنگ ژمارەی بەتاڵی داهاتوو لە جێگەی دادەنێت (بە شێوەی ئاسایی یەک زیاتر لە گەورەترین ژمارە)، بۆیە تاقیکردنەوەی « بەبێ کلیل زیاد بکە» سەردەکەوێت:

SQLite fills in the NULL key itselfSQLite خۆی کلیلە NULLەکە پڕ دەکاتەوەSQLRuns in the databaseلە ناو بنکەدراوە کار دەکات

CREATE TABLE sport_choice (
  roll_no INTEGER PRIMARY KEY,
  sport   TEXT
);

INSERT INTO sport_choice VALUES (24, 'Football');
INSERT INTO sport_choice VALUES (NULL, 'Volleyball');  -- no error!
SELECT * FROM sport_choice;

Quick checkپشکنینی خێراA table already has the primary key student_no. Can the designer add a second PRIMARY KEY on email?خشتەیەک پێشتر student_noـی هەیە. ئایا دیزاینەر دەتوانێت ⁦PRIMARY KEY⁩ی دووەم لەسەر email زیاد بکات؟Yes, a table can have as many primary keys as it needsبەڵێ، خشتەیەک دەتوانێت هەر چەند کلیلێکی سەرەکیی پێویست بێت هەبێتNo; make email an alternate key with NOT NULL UNIQUE insteadنەخێر؛ لە جیاتی ئەوە email بکە بە کلیلی جێگرەوە بە NOT NULL UNIQUE

4. Alternate key٤. کلیلی جێگرەوە

Definitionپێناسە

A that was not chosen as the . It is still unique, so it is a good place for a UNIQUE constraint or a .

کە وەک هەڵنەبژێردراوە. هێشتا یەکتایە، بۆیە شوێنێکی باشە بۆ ڕێسای UNIQUE یان .

A table can have several choices for its primary key, but it can choose only one. The candidate keys that are left unused after the primary key is chosen are called alternate keys. In short: unimplemented candidate keys are alternate keys. In our table, email is the alternate key.

خشتەیەک دەکرێت چەند هەڵبژاردەیەکی بۆ هەبێت، بەڵام تەنها دەتوانێت یەکێکیان هەڵبژێرێت. تر، واتە ئەوانەی دوای هەڵبژاردنی بەکارنەهێنراو دەمێننەوە، پێیان دەوترێت . بە کورتی: هەر کە جێبەجێ نەکرابێت . لە خشتەکەماندا email .

The course's example: if (class, section, roll) and (name, address) are both candidate keys and you pick the first as the primary key, then (name, address) becomes an alternate key.

نموونەی کۆرسەکە: ئەگەر (class, section, roll) و (name, address) هەردووکیان بن و یەکەمیان وەک هەڵبژێریت، ئەوا (name, address) دەبێتە .

5. Foreign key٥. کلیلی بیانی

Definitionپێناسە

A column (or columns) in one table whose values must match the of another table, the . It links the two tables; unlike a primary key it can be NULL and is usually not unique.

بریتییە لە (یان چەند ستوونێک) لە خشتەیەکدا کە نرخەکانی دەبێت لەگەڵ خشتەیەکی تردا () یەک بگرنەوە. دوو خشتەکە بەیەکەوە دەبەستێت؛ بە پێچەوانەی دەکرێت NULL بێت و زۆرجار یەکتا نییە.

A foreign key is a copy of a primary key that is placed in another table to form a relationship between the two. The course also gives a formal definition: an attribute X is a foreign key to an attribute Y when the values of X depend on the values of Y — X can take only values that Y already has.

کۆپییەکی کە لە تردا دادەنرێت بۆ دروستکردنی پەیوەندی لە نێوان هەردووکیاندا. کۆرسەکە پێناسەیەکی فەرمیش دەدات: خەسڵەتی X بۆ خەسڵەتی Y کاتێک نرخەکانی X پشت بە نرخەکانی Y دەبەستن — X تەنها دەتوانێت ئەو نرخانە وەربگرێت کە Y پێشتر هەیەتی.

The table that holds Y (the key that is pointed at) is the referenced relation.
The table that holds X (the foreign key) is the referencing relation.

ئەو خشتەیەی Y (ئەو کلیلەی ئاماژەی بۆ دەکرێت) هەڵدەگرێت ـە.
ئەو خشتەیەی X () هەڵدەگرێت ـە.

Our university has three foreign keys: enrolment.student_no → student.student_no, enrolment.course_code → course.course_code, and student.dept_code → department.dept_code. An enrolment can only name a student and a course that really exist.

زانکۆکەمان سێ هەیە: enrolment.student_no ← student.student_no، enrolment.course_code ← course.course_code و student.dept_code ← department.dept_code. تۆمارکردنێک تەنها دەتوانێت ناوی قوتابییەک و وانەیەک بهێنێت کە بەڕاستی هەن.

Each foreign key value points to an existing row of the referenced table. Redrawn from the course's Teacher–Department picture with our tables.هەر نرخێکی ئاماژە بۆ هەبووی دەکات. لە وێنەی ⁦Teacher–Department⁩ـی کۆرسەکەوە بە خشتەکانی خۆمان دووبارە کێشراوەتەوە.CêIT

The course's own example has two schemas: Teacher(t_no, t_name, t_age, t_dept) and Department(dept_no, dept_name). The Department table holds the list of real departments. t_dept is a foreign key: it can take only values that are present in dept_no, because only those departments actually exist.

نموونەی خودی کۆرسەکە دوو هەیە: Teacher(t_no, t_name, t_age, t_dept) و Department(dept_no, dept_name). خشتەی Department لیستی بەشە ڕاستەقینەکان هەڵدەگرێت. t_dept : تەنها دەتوانێت ئەو نرخانە وەربگرێت کە لە dept_noدا هەن، چونکە تەنها ئەو بەشانە بەڕاستی هەن.

The attribute Y may be in another table or in the same table. In our course table, prerequisite points to course_code of the same table: DB201 (Database Administration) needs DB101 first. A course with no prerequisite has NULL there. This is called a self-referencing foreign key.

خەسڵەتی Y دەکرێت لە خشتەیەکی تردا بێت یان لە هەمان خشتەدا. لە خشتەی courseـی ئێمەدا، prerequisite ئاماژە بۆ course_codeـی هەمان خشتە دەکات: ⁦DB201 (Database Administration)⁩ پێویستی بە ⁦DB101⁩ هەیە پێش خۆی. وانەیەک کە هیچ وانەیەکی پێشوەختی پێویست نەبێت لەوێدا NULLی هەیە. ئەمە پێی دەوترێت کە ئاماژە بۆ خشتەی خۆی دەکات.

Quick checkپشکنینی خێراWhat is a foreign key? چییە؟The key that a foreign student gets from the universityئەو کلیلەی قوتابیی بیانی لە زانکۆ وەری دەگرێتA second primary key of the same tableکلیلێکی سەرەکیی دووەمی هەمان خشتەA copy of a primary key placed in another table to form a relationshipکۆپییەکی کلیلی سەرەکی کە لە خشتەیەکی تردا دادەنرێت بۆ دروستکردنی پەیوەندی

What is a Foreign Key Constraint? Understanding Primary & Foreign KeysCockroachDB · Englishئینگلیزی · 112K viewsبینین · 1.9K likesلایک
A short animated explanation of what a foreign key is, how it points to a primary key, and how it blocks rows that point nowhere.
ڕوونکردنەوەیەکی کورت بە وێنەی جووڵاو: چییە، چۆن ئاماژە بە دەکات و چۆن ڕێگە نادات زیاد بکرێت کە ئاماژە بە شتێکی نەبوو بکات.
Whole video (4 min): primary key, foreign key and what the foreign key protects.
هەموو ڤیدیۆکە (⁦4⁩ خولەک): ، و ئەوەی دەیپارێزێت.

5. Foreign key٥. کلیلی بیانی

Seven rules about foreign keysحەوت ڕێسا دەربارەی کلیلە بیانییەکان

The course gives seven rules worth memorising. Two of them need a small correction (see below).

کۆرسەکە حەوت ڕێسا دەدات کە شایەنی لەبەرکردنن. دووانیان پێویستیان بە ڕاستکردنەوەیەکی بچووک هەیە (لە خوارەوە).

A foreign key references the primary key of the other table — or another unique key of it (see the correction).
A foreign key can take only values that are present in the referenced key.
A foreign key may have a different name from the key it references: student.dept_code could be called department and still point to department.dept_code.
A foreign key can be NULL — if the column allows NULL. course.prerequisite is NULL for DB101. (It is a foreign key to its own table: a recursive relationship.)
A foreign key does not have to be unique; usually it is not. 2024-0137 appears twice in enrolment.student_no.
The referenced relation may also be called the master table or primary table.
The referencing relation may also be called the foreign table. (Microsoft's documentation says 'primary key table' and 'foreign key table'.)

ئاماژە بۆ خشتەکەی تر دەکات — یان بۆ تری (بڕوانە ڕاستکردنەوەکە).
تەنها دەتوانێت ئەو نرخانە وەربگرێت کە لە کلیلە ئاماژەپێکراوەکەدا هەن.
دەکرێت ناوێکی جیاواز لە ناوی ئەو کلیلەی هەبێت کە ئاماژەی بۆ دەکات: student.dept_code دەکرێت ناوی department بێت و هێشتا ئاماژە بۆ department.dept_code بکات.
دەکرێت NULL بێت — ئەگەر ڕێگە بە NULL بدات. course.prerequisite بۆ ⁦DB101 NULL⁩ـە. ( بۆ هەمان : پەیوەندییەکی خۆیی.)
پێویست ناکات یەکتا بێت؛ زۆرجار یەکتا نییە. 2024-0137 دوو جار لە enrolment.student_noدا هاتووە.
هەروەها پێی دەوترێت خشتەی سەرەکی (master table یان primary table).
هەروەها پێی دەوترێت خشتەی بیانی (foreign table). (بەڵگەنامەکانی Microsoft دەڵێن primary key table و foreign key table.)

Correctionڕاستکردنەوە

Rules 1 and 2 say 'the primary key'. In SQL a foreign key may point to the primary key or to any UNIQUE key of the referenced table (an alternate key such as email). Rule 4 is true only when the column allows NULL: a foreign key declared NOT NULL (like student.dept_code) must always point to a real row.

ڕێساکانی ١ و ٢ دەڵێن «». لە SQLدا دەکرێت ئاماژە بۆ یان بۆ هەر بکات ( وەک email). ڕێسای ٤ تەنها کاتێک ڕاستە کە ڕێگە بە NULL بدات: کە بە NOT NULL ڕاگەیەندرابێت (وەک student.dept_code) دەبێت هەمیشە ئاماژە بۆ ڕاستەقینە بکات.

Quick checkپشکنینی خێراCan a foreign key be NULL?ئایا دەتوانێت NULL بێت؟Only once in the whole tableتەنها یەک جار لە هەموو خشتەکەداYes, if the column allows NULL; and it may also be repeatedبەڵێ، ئەگەر ستوونەکە ڕێگە بە NULL بدات؛ هەروەها دەکرێت دووبارەش ببێتەوەNever, just like a primary keyهەرگیز، وەک کلیلی سەرەکی

Three integrity rules that keys enforceسێ ڕێسای دروستی کە کلیلەکان جێبەجێیان دەکەن

Keys only help if the DBMS enforces them. A relational DBMS checks three families of integrity constraints every time data is added or changed, and refuses any change that breaks them:

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

Ruleڕێسا	What it saysچی دەڵێت	How SQL writes itSQL چۆن دەینووسێت
Domain constraint	Each column holds only allowed values: the right data type, a value when NULL is not allowed, and any extra test.هەر تەنها نرخی ڕێگەپێدراو هەڵدەگرێت: ڕاست، نرخێک کاتێک NULL ڕێگەپێنەدراوە و هەر تاقیکردنەوەیەکی زیادە.	`INT`, `DATE`, `NOT NULL`, `CHECK (credits BETWEEN 1 AND 6)INT`، `DATE`، `NOT NULL`، `CHECK (credits BETWEEN 1 AND 6)`
Entity integrity	Every row has a primary key value that is unique and never NULL.هەموو نرخێکی یەکتا و هەرگیز NULL نەبووی هەیە.	`PRIMARY KEYPRIMARY KEY`
Referential integrity	Every foreign key value matches an existing row of the referenced table (or is NULL, if allowed).هەموو نرخێکی لەگەڵ هەبووی یەک دەگرێتەوە (یان NULLـە، ئەگەر ڕێگەپێدراو بێت).	`FOREIGN KEY … REFERENCES …FOREIGN KEY … REFERENCES …`

The whole university database with all its keys (MySQL 8)هەموو بنکەدراوەی زانکۆکە لەگەڵ هەموو کلیلەکانی ⁦(MySQL 8)⁩university.sqlSQLRuns in the databaseلە ناو بنکەدراوە کار دەکات

CREATE TABLE department (
  dept_code  CHAR(2)      PRIMARY KEY,
  dept_name  VARCHAR(60)  NOT NULL UNIQUE
);

CREATE TABLE student (
  student_no  CHAR(9)      PRIMARY KEY,                -- entity integrity
  national_id VARCHAR(12)  UNIQUE,                     -- unique key: NULL allowed
  email       VARCHAR(100) NOT NULL UNIQUE,            -- alternate key
  full_name   VARCHAR(100) NOT NULL,
  birth_date  DATE,
  phone       VARCHAR(20),
  dept_code   CHAR(2)      NOT NULL,
  FOREIGN KEY (dept_code) REFERENCES department (dept_code)
);

CREATE TABLE course (
  course_code  CHAR(5)      PRIMARY KEY,
  title        VARCHAR(100) NOT NULL,
  credits      INT          NOT NULL CHECK (credits BETWEEN 1 AND 6),
  prerequisite CHAR(5)      NULL,
  FOREIGN KEY (prerequisite) REFERENCES course (course_code)
);

CREATE TABLE enrolment (
  student_no  CHAR(9)     NOT NULL,
  course_code CHAR(5)     NOT NULL,
  semester    VARCHAR(11) NOT NULL,
  grade       CHAR(1)     CHECK (grade IN ('A', 'B', 'C', 'D', 'E', 'F')),
  PRIMARY KEY (student_no, course_code, semester),
  FOREIGN KEY (student_no)  REFERENCES student (student_no) ON DELETE CASCADE,
  FOREIGN KEY (course_code) REFERENCES course (course_code)
);

Explain the codeڕوونکردنەوەی کۆدەکە

Lineدێڕی 3

A department name must also be unique: another alternate key.

ناوی بەشیش دەبێت یەکتا بێت: تر.

Lineدێڕی 8

UNIQUE without NOT NULL: students without a number are allowed.

UNIQUE بەبێ NOT NULL: ڕێگە بە قوتابیی بێ ژمارە دەدرێت.

Lineدێڕی 14

Referential integrity: every student belongs to an existing department.

: هەموو قوتابییەک سەر بە بەشێکی هەبووە.

Lineدێڕی 20

A domain constraint: 0 or 9 credits are refused.

: 0 یان 9 یەکە ڕەت دەکرێتەوە.

Lineدێڕی 21-22

Self-referencing foreign key; NULL = no prerequisite.

کە ئاماژە بۆ خشتەی خۆی دەکات؛ NULL = هیچ وانەیەکی پێشوەخت نییە.

Lineدێڕی 30

A composite primary key (key 7).

وەک ( ٧).

Lineدێڕی 31

Deleting a student also deletes their enrolments (next screens).

سڕینەوەی قوتابییەک تۆمارکردنەکانیشی دەسڕێتەوە (پەڕەکانی داهاتوو).

Three integrity rules that keys enforceسێ ڕێسای دروستی کە کلیلەکان جێبەجێیان دەکەن

Watch the rules at workڕێساکان لە کاتی کارکردندا ببینە

After the tables are filled with our example rows, each of these statements breaks one rule. The DBMS refuses all four, and the data stays correct:

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

SQLRuns in the databaseلە ناو بنکەدراوە کار دەکات

INSERT INTO student (student_no, email, full_name, dept_code)
  VALUES (NULL, 'dilan.hama@uni.example', 'Dilan Hama', 'CS');   -- entity integrity

INSERT INTO enrolment VALUES ('2024-0137', 'XX999', '2025-Spring', NULL);  -- referential integrity

INSERT INTO course VALUES ('AI301', 'Artificial Intelligence', 9, NULL);   -- domain constraint

INSERT INTO student (student_no, national_id, email, full_name, dept_code)
  VALUES ('2024-0202', 'N-48213', 'hana.rauf@uni.example', 'Hana Rauf', 'IT');  -- unique key

Three rules or six?سێ ڕێسا یان شەش؟

Some books count six kinds of constraint instead of three: they list the NOT NULL rule and CHECK on their own (here both belong to the domain constraint) and add semantic integrity: a value of the right type must also make sense – '#@!' is text, but it is not a city. SQL has no keyword for semantic integrity. It is enforced with a CHECK, a foreign key to a lookup table (a city table that lists the real cities), a trigger, or checks in the application.

هەندێک کتێب لە جیاتی سێ، شەش جۆر دەژمێرن: ڕێسای NOT NULL و CHECK بە جیا دەنووسن (لێرەدا هەردووکیان بەشێکن لە ) و دروستیی واتایی زیاد دەکەن: نرخێک کە جۆرەکەی ڕاستە دەبێت واتاشی هەبێت – '#@!' دەقە، بەڵام شار نییە. SQL هیچ وشەیەکی تایبەتی بۆ دروستیی واتایی نییە. بە CHECK، بە بۆ لیست (خشتەی city کە شارە ڕاستەقینەکان ڕیز دەکات)، بە یان بە پشکنین لە ناو بەرنامەکەدا جێبەجێ دەکرێت.

Three integrity rules that keys enforceسێ ڕێسای دروستی کە کلیلەکان جێبەجێیان دەکەن

Deleting or changing a referenced rowسڕینەوە یان گۆڕینی ڕیزێکی ئاماژەپێکراو

Referential integrity also protects the referenced table. What should happen if someone deletes course DB101, while enrolments still point to it? If it simply let the delete happen, those enrolments would become orphan records: rows whose foreign key points to a row that no longer exists. Preventing orphans is the whole point of referential integrity, so by default the DBMS refuses. When you create a foreign key you can choose another action with ON DELETE and ON UPDATE:

هەروەها دەپارێزێت. چی ڕوو بدات ئەگەر کەسێک وانەی ⁦DB101⁩ بسڕێتەوە، لە کاتێکدا هێشتا تۆمارکردنەکان ئاماژەی بۆ دەکەن؟ ئەگەر ڕێگەی بە سڕینەوەکە بدایە، ئەو تۆمارکردنانە دەبوونە : کە ئاماژە بۆ دەکات کە ئیتر بوونی نییە. ڕێگرتن لە تەواوی مەبەستی ، بۆیە بە شێوەی بنەڕەتی ڕەتی دەکاتەوە. کاتێک دروست دەکەیت، دەتوانیت بە ON DELETE و ON UPDATE کاردانەوەیەکی تر هەڵبژێریت:

Actionکردەوە	What happens to the referencing rowsچی بەسەر ئاماژەکەرەکان دێت
`NO ACTION / RESTRICT`	The default. The DELETE or UPDATE of the referenced row is refused while rows still point to it.بنەڕەتییە. DELETE یان UPDATEی ئاماژەپێکراوەکە ڕەت دەکرێتەوە تا کاتێک تر ئاماژەی بۆ بکەن.
`CASCADE`	The referencing rows are deleted too (ON DELETE), or their foreign key is changed to the new value (ON UPDATE). ئاماژەکەرەکانیش دەسڕدرێنەوە ⁦(ON DELETE)⁩، یان دەگۆڕدرێت بۆ نرخە نوێیەکە ⁦(ON UPDATE)⁩.
`SET NULL`	Their foreign key becomes NULL. The column must allow NULL. دەبێتە NULL. دەبێت ڕێگە بە NULL بدات.
`SET DEFAULT`	Their foreign key gets its default value. SQL Server supports it; MySQL's InnoDB engine does not accept it. وەردەگرێت. ⁦SQL Server⁩ پشتگیریی دەکات؛ بزوێنەری InnoDBـی MySQL وەری ناگرێت.

SQLRuns in the databaseلە ناو بنکەدراوە کار دەکات

DELETE FROM course WHERE course_code = 'DB101';      -- enrolments point to it: NO ACTION
DELETE FROM student WHERE student_no = '2024-0152';  -- ON DELETE CASCADE
SELECT * FROM enrolment;

Correctionڕاستکردنەوە

The course says: 'Any value in the primary key cannot be changed by any foreign keys.' That sentence is unclear. What is true: a primary key value can be changed with UPDATE. But while foreign keys point to it, the DBMS refuses to change or delete it (NO ACTION), unless the foreign key was created with ON UPDATE / ON DELETE CASCADE, SET NULL or SET DEFAULT. A foreign key never changes a primary key; changes flow the other way, from the referenced row to the referencing rows.

کۆرسەکە دەڵێت: «هیچ نرخێکی ناتوانرێت بە هیچ بگۆڕدرێت.» ئەم ڕستەیە ناڕوونە. ئەوەی ڕاستە: نرخی دەتوانرێت بە UPDATE بگۆڕدرێت. بەڵام تا کاتێک ئاماژەی بۆ دەکەن، ڕێگە نادات بگۆڕدرێت یان بسڕدرێتەوە ⁦(NO ACTION)⁩، مەگەر بە ON UPDATE / ON DELETE CASCADE، SET NULL یان SET DEFAULT دروست کرابێت. هەرگیز ناگۆڕێت؛ گۆڕانکاری بە پێچەوانەوە دەڕوات، لە ئاماژەپێکراوەکەوە بۆ ئاماژەکەرەکان.

Quick checkپشکنینی خێراenrolment.course_code was created with no ON DELETE clause. What happens to DELETE FROM course WHERE course_code = 'WP101' while Aram is enrolled in WP101?enrolment.course_code بەبێ بڕگەی ON DELETE دروست کراوە. چی بەسەر DELETE FROM course WHERE course_code = 'WP101' دێت لە کاتێکدا ئارام لە ⁦WP101⁩دا تۆمار کراوە؟The DELETE is refused (NO ACTION is the default)DELETEـەکە ڕەت دەکرێتەوە (⁦NO ACTION⁩ بنەڕەتییە)The course is deleted and Aram's enrolment tooوانەکە و تۆمارکردنەکەی ئارامیش دەسڕدرێنەوەThe course is deleted and Aram's course_code becomes NULLوانەکە دەسڕدرێتەوە و ⁦course_code⁩ـی ئارام دەبێتە NULL

6. Partial key٦. کلیلی بەشەکی

Definitionپێناسە

The attribute of a that tells apart the weak entities belonging to the same owner. On its own it is not unique, but together with the owner's it identifies each row. It is also called the discriminator, and an E-R diagram underlines it with a dashed line.

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

The course defines a partial key as a key that cannot identify all the records of the table uniquely, but that can pick out a group of related tuples. Partial keys appear with weak entities: things that cannot exist on their own. A lecturer's dependent (a family member registered for health insurance) is recorded only because the lecturer exists.

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

dependent — the family members of two lecturersdependent — ئەندامانی خێزانی دوو مامۆستا
`lecturer_no`	`dependent_name`	`relation`
L01	Dilan	Daughter
L01	Rezan	Son
L02	Dilan	Mother
L02	Karwan	Father

dependent_name alone repeats: there are two Dilans. But inside one lecturer's family the names are different. So dependent_name is the partial key (some textbooks call it the discriminator). It identifies a row only together with the owner's key: the full key of the table is (lecturer_no, dependent_name). lecturer_no itself is a foreign key to the lecturer table.

dependent_name بە تەنها دووبارە دەبێتەوە: دوو «دیلان» هەن. بەڵام لەناو خێزانی یەک مامۆستادا ناوەکان جیاوازن. بۆیە dependent_name (هەندێک کتێب پێی دەڵێن discriminator). تەنها لەگەڵ کلیلی خاوەنەکەیدا دەناسێنێت: کلیلی تەواوی خشتەکە (lecturer_no, dependent_name)ـە. lecturer_no خۆی بۆ خشتەی lecturer.

Correctionڕاستکردنەوە

The course's table is called Department(Emp_no, Dependent_name, Relation) with employees E1 and E2, and it calls Emp_no the partial key ('everyone who depends on employee E1'). Two things need fixing. (1) The table holds dependents, so its name should be Dependent, not Department. (2) In the standard textbooks (Silberschatz calls it the discriminator), the partial key is the weak entity's own attribute, Dependent_name. Emp_no comes from the owner, Employee: it is a foreign key. Finding 'everyone who depends on E1' is simply a search on that foreign key.

خشتەکەی کۆرسەکە ناوی Department(Emp_no, Dependent_name, Relation)ـە لەگەڵ فەرمانبەرانی ⁦E1⁩ و ⁦E2⁩ و ⁦Emp_no⁩ بە دادەنێت («هەموو ئەوانەی سەر بە فەرمانبەری ⁦E1⁩ن»). دوو شت پێویستیان بە چاککردن هەیە. (١) خشتەکە کەسانی سەر بە فەرمانبەرەکان هەڵدەگرێت، بۆیە ناوەکەی دەبێت Dependent بێت نەک Department. (٢) لە کتێبە ستانداردەکاندا (Silberschatz پێی دەڵێت discriminator)، خەسڵەتی خودی ، واتە Dependent_name. Emp_no لە خاوەنەکەوە دێت، Employee: . دۆزینەوەی «هەموو ئەوانەی سەر بە ⁦E1⁩ن» تەنها گەڕانێکە بەپێی .

Quick checkپشکنینی خێراEach course has sections A, B, C … and the letters start again for every course: section(course_code, section_no, room). Which attribute is the partial key?هەر وانەیەک هۆبەی A، B، C … ی هەیە و پیتەکان بۆ هەر وانەیەک لە سەرەتاوە دەست پێدەکەنەوە: section(course_code, section_no, room). کام خەسڵەت ؟section_nosection_noroomroomcourse_codecourse_code

7. Composite key٧. کلیلی لێکدراو

Definitionپێناسە

A key made of two or more attributes used together, because no single attribute is unique on its own.

کلیلێکە کە لە دوو خەسڵەت یان زیاتر پێکدێت کە پێکەوە بەکار دێن، چونکە هیچ خەسڵەتێک بە تەنها یەکتا نییە.

The course defines a composite key as a primary key made of more than one attribute. Its example is the school's (class, section, roll) used together as the primary key. In our university, enrolment needs three columns. Shilan failed DB101 in the fall and passed it in the spring, so (student_no, course_code) repeats; semester makes each row different:

کۆرسەکە وا دەناسێنێت کە لە زیاتر لە یەک خەسڵەت پێکهاتووە. نموونەکەی (class, section, roll)ـی قوتابخانەکەیە کە پێکەوە وەک بەکار دێن. لە زانکۆکەماندا enrolment پێویستی بە سێ هەیە. شیلان لە وەرزی پاییزدا لە ⁦DB101⁩ دەرنەچوو و لە بەهاردا دەرچوو، بۆیە (student_no, course_code) دووبارە دەبێتەوە؛ semester هەموو جیاواز دەکات:

enrolment — primary key (student_no, course_code, semester)خشتەی enrolment — ⁦(student_no, course_code, semester)⁩
`student_no`	`course_code`	`semester`	`grade`
2024-0137	DB101	2024-Fall	B
2024-0137	WP101	2024-Fall	A
2024-0152	DB101	2024-Fall	E
2024-0152	DB101	2025-Spring	B
2024-0188	DB201	2025-Spring	A

In a composite key one column alone may repeat (2024-0137 twice, DB101 three times); only the combination of all its columns must be unique. In SQL it is written once, at the end of the table: PRIMARY KEY (student_no, course_code, semester).

لە یەک بە تەنها دەکرێت دووبارە ببێتەوە (2024-0137 دوو جار، DB101 سێ جار)؛ تەنها تێکەڵەی هەموو دەبێت یەکتا بێت. لە SQLدا یەک جار، لە کۆتایی خشتەکەدا دەنووسرێت: PRIMARY KEY (student_no, course_code, semester).

Correctionڕاستکردنەوە

The course says a composite key is a primary key with several attributes. In practice any key can be composite: a candidate key, a unique key and a foreign key can all have several columns. For example, a table that points to an enrolment would need the foreign key (student_no, course_code, semester). Microsoft's documentation uses the composite primary key (ProductID, VendorID) as its example.

کۆرسەکە دەڵێت بە چەند خەسڵەتێکەوە. لە ڕاستیدا هەر دەکرێت لێکدراو بێت: ، و هەموویان دەکرێت چەند هەبێت. بۆ نموونە، خشتەیەک کە ئاماژە بۆ تۆمارکردنێک بکات پێویستی بە (student_no, course_code, semester) دەبێت. بەڵگەنامەکانی Microsoft لێکدراوی (ProductID, VendorID) وەک نموونە بەکار دەهێنن.

Quick checkپشکنینی خێراWhy can enrolment not use (student_no, course_code) as its primary key?بۆچی enrolment ناتوانێت (student_no, course_code) وەک بەکار بهێنێت؟Because a student can take the same course again in another semesterچونکە قوتابییەک دەتوانێت هەمان وانە لە وەرزێکی تردا دووبارە بخوێنێتەوەBecause a primary key may have only one columnچونکە کلیلی سەرەکی تەنها دەتوانێت یەک ستوونی هەبێتBecause course_code is a foreign keyچونکە ⁦course_code⁩ کلیلی بیانییە

8. Unique key٨. کلیلی یەکتا

Definitionپێناسە

A column (or set of columns) whose values must all be different, like a , but which may hold NULL where the value is unknown. A table can have several unique keys.

بریتییە لە یان کۆمەڵە ستوونێک کە دەبێت هەموو نرخەکانی جیاواز بن، وەک ، بەڵام دەکرێت لە شوێنی نرخێکی نەزانراودا NULL هەڵبگرێت. خشتەیەک دەکرێت چەند کلیلێکی یەکتای هەبێت.

A unique key is a column, or set of columns, whose values must all be different: it is unique for all the records of the table. Unlike a primary key, it may contain NULL, and a table can have several unique keys.

یان کۆمەڵە کە دەبێت هەموو نرخەکانی جیاواز بن: بۆ هەموو خشتەکە یەکتایە. بە پێچەوانەی ، دەکرێت NULLی تێدا بێت و خشتەیەک دەکرێت چەند هەبێت.

The course's best example is the number on the Iraqi identity card. The course calls it the 'Social Card Number'; the card's official name is the Unified National Card (Arabic البطاقة الوطنية الموحدة), issued by Iraq's Ministry of Interior, and its national number is unique for every citizen. Not every citizen has received the card yet, so for some people the value is NULL. In our table this is national_id: Shilan and Aram Salih have NULL.

باشترین نموونەی کۆرسەکە ژمارەی کارتی ناسنامەی عێراقییە. کۆرسەکە پێی دەڵێت «⁦Social Card Number⁩»؛ ناوی فەرمیی کارتەکە کارتی نیشتمانیی یەکگرتووە (بە عەرەبی البطاقة الوطنية الموحدة) کە وەزارەتی ناوخۆی عێراق دەریدەکات و ژمارە نیشتمانییەکەی بۆ هەموو هاووڵاتییەک یەکتایە. هێشتا هەموو هاووڵاتییەک کارتەکەی وەرنەگرتووە، بۆیە بۆ هەندێک کەس نرخەکە NULLـە. لە خشتەکەماندا ئەمە national_idـە: شیلان و ئارام ساڵح NULLیان هەیە.

A unique key in action (MySQL)کلیلی یەکتا لە کاتی کارکردندا ⁦(MySQL)⁩SQLRuns in the databaseلە ناو بنکەدراوە کار دەکات

-- national_id VARCHAR(12) UNIQUE   (no NOT NULL)
INSERT INTO student (student_no, national_id, email, full_name, dept_code)
  VALUES ('2024-0201', NULL, 'rezan.ali@uni.example', 'Rezan Ali', 'IT');      -- one more NULL

UPDATE student SET national_id = 'N-60001' WHERE student_no = '2024-0152';  -- Shilan gets her card

INSERT INTO student (student_no, national_id, email, full_name, dept_code)
  VALUES ('2024-0202', 'N-48213', 'hana.rauf@uni.example', 'Hana Rauf', 'IT');  -- Aram's number again

8. Unique key٨. کلیلی یەکتا

Two corrections about unique keysدوو ڕاستکردنەوە دەربارەی کلیلە یەکتاکان

'Only one NULL' depends on the DBMS«تەنها یەک NULL» پەیوەستە بە سیستەمی بەڕێوەبردنی بنکەدراوە

The course says a unique key 'can have only one null value' (Primary key: no nulls at all. Unique key: one null allowed). That is the rule of Microsoft SQL Server. MySQL and SQLite accept many NULLs in a UNIQUE column, because one unknown value is never 'equal' to another. So the correct rule is: a unique key may contain NULL; how many NULLs are allowed depends on the DBMS.

کۆرسەکە دەڵێت «تەنها دەتوانێت یەک نرخی NULLی هەبێت» (: هیچ NULLێک. : یەک NULL ڕێگەپێدراوە). ئەمە ڕێسای ⁦Microsoft SQL Server⁩ـە. MySQL و SQLite چەندین NULL لە UNIQUEدا وەردەگرن، چونکە نرخێکی نەزانراو هەرگیز «یەکسان» نییە بە یەکێکی تر. بۆیە ڕێسا ڕاستەکە ئەمەیە: دەکرێت NULLی تێدا بێت؛ ژمارەی NULLە ڕێگەپێدراوەکان پەیوەستە بە .

A unique key can be updatedکلیلی یەکتا دەتوانرێت نوێ بکرێتەوە

The course says a unique key is 'non-updatable': once assigned, it cannot be changed, and a lost card is reissued with the same number. A UNIQUE constraint only refuses duplicates. The DBMS lets you change the value with UPDATE as long as it stays unique (as in the example on the previous screen). Whether a replacement card keeps the old number is decided by the office that issues the cards, not by the database: a unique key only forbids duplicates.

کۆرسەکە دەڵێت «ناتوانرێت نوێ بکرێتەوە»: کاتێک درا، ناگۆڕدرێت و کارتێکی ونبوو بە هەمان ژمارە دووبارە دەدرێتەوە. UNIQUE تەنها دووبارەکان ڕەت دەکاتەوە. ڕێگە دەدات نرخەکە بە UPDATE بگۆڕیت تا کاتێک یەکتا بمێنێتەوە (وەک لە شاشەی پێشوودا بینیت). ئایا کارتێکی نوێ هەمان ژمارەی کۆنی دەبێت یان نا، ئەو فەرمانگەیە بڕیاری لەسەر دەدات کە کارتەکان دەردەکات، نەک : تەنها ڕێگە لە دووبارەبوونەوە دەگرێت.

Quick checkپشکنینی خێراIn MySQL, national_id is declared UNIQUE (without NOT NULL). Which row is refused?لە MySQLدا national_id بە UNIQUE ڕاگەیەندراوە (بەبێ NOT NULL). کام ڕەت دەکرێتەوە؟A third student with national_id NULLقوتابیی سێیەم بە ⁦national_id⁩ـی NULLA student whose national_id is already used by another studentقوتابییەک کە ⁦national_id⁩ـەکەی پێشتر قوتابییەکی تر بەکاری هێناوەChanging Shilan's NULL to a new, unused numberگۆڕینی NULLـی شیلان بۆ ژمارەیەکی نوێی بەکارنەهێنراو

9. Surrogate key٩. کلیلی دەستکرد

Definitionپێناسە

A key with no meaning of its own, such as an automatic number, added to a table only to identify each row. It is never NULL and is usually made with .

کلیلێکە کە هیچ واتایەکی خۆی نییە (وەک ژمارەیەکی خۆکار) و تەنها بۆ ناساندنی هەر ڕیزێک زیاد دەکرێتە سەر خشتەکە. هەرگیز NULL نییە و زۆرجار بە دروست دەکرێت.

A surrogate key is an artificial identifier that the database adds to a table: usually an automatic number (AUTO_INCREMENT in MySQL, IDENTITY in SQL Server) or a random UUID. It is not taken from the real-world data and means nothing outside the database. It is unique, never NULL, and normally never changed.

دەستکردە کە زیادی دەکاتە سەر خشتەیەک: زۆرجار ژمارەیەکی خۆکار (AUTO_INCREMENT لە MySQL، IDENTITY لە ⁦SQL Server⁩) یان UUIDێکی هەڕەمەکی. لە جیهانی ڕاستەقینەوە وەرناگیرێت و لە دەرەوەی هیچ واتایەکی نییە. یەکتایە، هەرگیز NULL نییە و بە شێوەی ئاسایی هەرگیز ناگۆڕدرێت.

Its opposite is a natural key: data that already means something in the real world, such as student_no, national_id, email or a phone number. Many designers give a table a surrogate key and keep its natural key as a UNIQUE key. Here enrolment gets a surrogate key instead of its three-column primary key:

پێچەوانەکەی ـە: کە پێشتر لە جیهانی ڕاستەقینەدا واتای هەیە، وەک student_no، national_id، email یان ژمارەی مۆبایل. زۆر دیزاینەر دەدەنە خشتەیەک و وەک دەهێڵنەوە. لێرەدا enrolment لە جیاتی سێ ستوونییەکەی وەردەگرێت:

SQLRuns in the databaseلە ناو بنکەدراوە کار دەکات

CREATE TABLE enrolment (
  enrolment_id INT AUTO_INCREMENT PRIMARY KEY,   -- surrogate key: 1, 2, 3 …
  student_no   CHAR(9)     NOT NULL,
  course_code  CHAR(5)     NOT NULL,
  semester     VARCHAR(11) NOT NULL,
  grade        CHAR(1),
  UNIQUE (student_no, course_code, semester),    -- the natural key stays unique
  FOREIGN KEY (student_no)  REFERENCES student (student_no) ON DELETE CASCADE,
  FOREIGN KEY (course_code) REFERENCES course (course_code)
);

INSERT INTO enrolment (student_no, course_code, semester, grade)
  VALUES ('2024-0137', 'DB101', '2024-Fall', 'B'),
         ('2024-0137', 'WP101', '2024-Fall', 'A');
SELECT enrolment_id, student_no, course_code FROM enrolment;

Correctionڕاستکردنەوە

The course defines a surrogate key as 'unique, updatable, cannot be NULL' and gives as example 'the mobile number of students in a class where every student owns a mobile phone'. A mobile number is the opposite: a natural key, and a weak one. Numbers change, a family may share one, and an old number can be given to someone else. A surrogate key is not found in the data at all: the system makes it. And it is normally not updated, because nothing in the real world ever asks to change it.

کۆرسەکە وا دەناسێنێت: «یەکتایە، دەتوانرێت نوێ بکرێتەوە، ناتوانێت NULL بێت» و وەک نموونە «ژمارەی مۆبایلی قوتابیانی پۆلێک کە هەموو قوتابییەک مۆبایلی هەیە» دەهێنێتەوە. ژمارەی مۆبایل پێچەوانەکەیە: و لاوازیشە. ژمارەکان دەگۆڕێن، خێزانێک دەکرێت یەک ژمارەیان هەبێت و ژمارەیەکی کۆن دەکرێت بدرێتە کەسێکی تر. هەرگیز لە نییە: سیستەمەکە دروستی دەکات. بە شێوەی ئاسایی نوێش ناکرێتەوە، چونکە هیچ شتێک لە جیهانی ڕاستەقینەدا داوای گۆڕینی ناکات.

Questionپرسیار	Natural key	Surrogate key
Where it comes fromلە کوێوە دێت	the real worldجیهانی ڕاستەقینە	made by the DBMS دروستی دەکات
Meaning outside the databaseواتا لە دەرەوەی	yesبەڵێ	noneهیچ
Can it change?دەگۆڕێت؟	sometimes (new email, new phone)هەندێک جار ( نوێ، مۆبایلی نوێ)	normally neverبە ئاسایی هەرگیز
Examplesنموونە	`student_no, email, national_id, phone`	`enrolment_id INT AUTO_INCREMENT`

9. Surrogate key٩. کلیلی دەستکرد

Three rules for surrogate keysسێ یاسا بۆ کلیلە دەستکردەکان

Three rules make surrogate keys work well:

سێ یاسا باش بەکار دەخەن:

Keep the natural key unique as well. A surrogate key does not replace it: without UNIQUE (student_no, course_code, semester) the same enrolment could be typed twice, with two different ids.
Keep it inside the database. Users see student_no on the student card, never enrolment_id. If people need a number of their own, such as an account number, add a separate, unique, nicely formatted column for them (an alternate key).
It only has to be unique in its own table. A number that must be unique in the whole world, such as a product's barcode, is business data; it is not a reason to change the key.

هەر بە یەکتایی بهێڵەوە. جێگەی ناگرێتەوە: بەبێ UNIQUE (student_no, course_code, semester) هەمان تۆمارکردن دەکرێت دوو جار بنووسرێت، بە دوو id جیاواز.
لە ناو بیهێڵەوە. بەکارهێنەران student_no لەسەر کارتی قوتابی دەبینن، هەرگیز enrolment_id نا. ئەگەر خەڵک پێویستیان بە ژمارەیەکی تایبەت بە خۆیان هەبێت، وەک ژمارەی هەژمار، جیا، یەکتا و ڕێکوپێکیان بۆ زیاد بکە ().
تەنها لە خۆیدا دەبێت یەکتا بێت. ژمارەیەک کە دەبێت لە هەموو جیهاندا یەکتا بێت، وەک بارکۆدی کاڵایەک، کارەکەیە؛ هۆیەک نییە بۆ گۆڕینی کلیلەکە.

Quick checkپشکنینی خێراenrolment has the surrogate key enrolment_id. Why keep UNIQUE (student_no, course_code, semester) as well?enrolment enrolment_idـی هەیە. بۆچی UNIQUE (student_no, course_code, semester)ـیش دەهێڵینەوە؟Without it, the same enrolment could be stored twice with two different idsبەبێ ئەو، هەمان تۆمارکردن دەکرێت دوو جار بە دوو id جیاواز هەڵبگیرێتIt makes the table faster to readخوێندنەوەی خشتەکە خێراتر دەکاتSQL needs two keys in every tableSQL لە هەموو خشتەیەکدا دوو کلیلی پێویستە

9. Surrogate key٩. کلیلی دەستکرد

AUTO_INCREMENT or UUID?⁦AUTO_INCREMENT⁩ یان UUID؟

An automatic number (AUTO_INCREMENT) is short and fast, but one server must hand out the numbers. A UUID is a 128-bit value such as 0192f1a4-7c2e-7b51-9a3d-5c8e1f0b2a77. Any computer or phone can make one on its own, without asking a central server, and two of them practically never collide. Version 4 is random; version 7 (RFC 9562, 2024) starts with the time, so new keys arrive in order and the index stays fast. Choose UUIDs when rows are created in many places, for example by an app that works offline.

ژمارەی خۆکار (AUTO_INCREMENT) کورت و خێرایە، بەڵام دەبێت یەک ژمارەکان دابەش بکات. UUID نرخێکە بە درێژیی ⁦128⁩ ، وەک 0192f1a4-7c2e-7b51-9a3d-5c8e1f0b2a77. هەر یان مۆبایلێک دەتوانێت بە تەنها یەکێک دروست بکات، بەبێ پرسیارکردن لە ناوەندی و دووانیان بە کردەوە هەرگیز وەک یەک نابن. وەشانی 4 هەڕەمەکییە؛ وەشانی ⁦7 (RFC 9562⁩، ⁦2024⁩) بە کات دەست پێدەکات، بۆیە کلیلە نوێیەکان بە ڕیز دێن و خێرا دەمێنێتەوە. UUID هەڵبژێرە کاتێک لە چەند شوێنێکدا دروست دەکرێن، بۆ نموونە بە کە بەبێ ئینتەرنێت کار دەکات.

Not a lockقوفڵ نییە

Hiding the key is not security. If a web page shows /enrolment?id=41, someone will try id=42. A random UUID makes the next id hard to guess, but RFC 9562 says UUIDs must not be used as a permission. The server must check on every request that this user may see this row.

شاردنەوەی کلیل ئاسایش نییە. ئەگەر /enrolment?id=41 پیشان بدات، کەسێک id=42 تاقی دەکاتەوە. UUIDی هەڕەمەکی مەزەندەکردنی id داهاتوو قورس دەکات، بەڵام ⁦RFC 9562⁩ دەڵێت UUID نابێت وەک مۆڵەت بەکار بهێنرێت. دەبێت لە هەموو داواکارییەکدا بپشکنێت کە ئەم بەکارهێنەرە ڕێگەی هەیە ئەم ببینێت.

Quick checkپشکنینی خێراA field-survey app saves forms on tablets in villages without internet and sends them to the server days later. Which surrogate key fits best? ڕاپرسی مەیدانی فۆرمەکان لەسەر تابلێتەکان لە گوندی بێ ئینتەرنێت هەڵدەگرێت و چەند ڕۆژ دواتر دەیاننێرێت بۆ . کام باشترە؟AUTO_INCREMENT, so the numbers stay shortAUTO_INCREMENT، بۆ ئەوەی ژمارەکان کورت بمێننەوەThe surveyor's phone numberژمارەی مۆبایلی ڕاپرسیکارA UUID (version 7) made on each tabletUUID (وەشانی ⁦7⁩) کە لەسەر هەر تابلێتێک دروست دەکرێت

10. Secondary key١٠. کلیلی دووەمی

Definitionپێناسە

A column that is not used to identify rows but is indexed so that searches on it are fast, for example a surname column.

ستوونێکە کە بۆ ناساندنی ڕیزەکان بەکار نایەت، بەڵام بۆ دروست دەکرێت بۆ ئەوەی گەڕان بەپێی ئەو ستوونە خێرا بێت، بۆ نموونە ستوونی ناوی خێزان.

A secondary key is used for indexing: for better and faster searching. It is not for identity at all, so its values may repeat. The registry office often searches students by name, so full_name is a good secondary key. The DBMS builds an index on it — like the index at the back of a book, it lists every name with the place of its rows, so the DBMS does not have to read the whole table.

بۆ بەکار دێت: بۆ گەڕانی باشتر و خێراتر. هەرگیز بۆ ناساندن نییە، بۆیە نرخەکانی دەکرێت دووبارە ببنەوە. فەرمانگەی تۆمار زۆرجار بەپێی ناو بەدوای قوتابییەکاندا دەگەڕێت، بۆیە full_name باشە. لەسەری دروست دەکات — وەک پێڕستی کۆتایی کتێبێک، هەموو ناوێک لەگەڵ شوێنی ڕیز دەکات، بۆیە پێویست ناکات هەموو خشتەکە بخوێنێتەوە.

SQLRuns in the databaseلە ناو بنکەدراوە کار دەکات

CREATE INDEX idx_student_name ON student (full_name);

SELECT student_no, full_name FROM student WHERE full_name = 'Aram Kamal';

Noteتێبینی

Indexes are not free: each one takes disk space and slows down every INSERT, UPDATE and DELETE a little, because the index must be updated too. Create them for columns that are searched or joined often (foreign keys are good candidates). More in Choosing indexes.

بێبەرانبەر نین: هەریەکەیان شوێن لە دیسک دەگرێت و هەموو INSERT، UPDATE و DELETEێک کەمێک خاو دەکاتەوە، چونکە دەبێت ئەویش نوێ بکرێتەوە. بۆ ئەو دروستیان بکە کە زۆر گەڕانیان تێدا دەکرێت یان زۆر لێکدەبەسترێن ( نموونەی باشن). زیاتر لە هەڵبژاردنی پێڕستەکان.

Quick checkپشکنینی خێراWhat makes a secondary key different from the other identifying keys?چی لە ناسێنەری تر جیا دەکاتەوە؟It can never contain NULLهەرگیز ناتوانێت NULLی تێدا بێتIt is the second primary key of the tableکلیلی سەرەکیی دووەمی خشتەکەیەIt is not for identity at all, only for faster searching; its values may repeatهەرگیز بۆ ناساندن نییە، تەنها بۆ گەڕانی خێراترە؛ نرخەکانی دەکرێت دووبارە ببنەوە

All ten keys side by sideهەر دە کلیلەکە لە تەنیشت یەکتر

Correctionڕاستکردنەوە

The course ends with a small table: unique key 'non-updatable, may be NULL'; surrogate key 'updatable, can never be NULL'; secondary key 'not for identity at all — only for fast searching'. The last line is right; the first two repeat the mistakes corrected above. Use this table instead.

کۆرسەکە بە خشتەیەکی بچووک کۆتایی دێت: «ناتوانرێت نوێ بکرێتەوە، دەکرێت NULL بێت»؛ «دەتوانرێت نوێ بکرێتەوە، هەرگیز NULL نییە»؛ «هەرگیز بۆ ناساندن نییە — تەنها بۆ گەڕانی خێرا». دێڕی کۆتایی ڕاستە؛ دووانەکەی یەکەم ئەو هەڵانە دووبارە دەکەنەوە کە لە سەرەوە ڕاست کرانەوە. لە جیاتی ئەوە ئەم خشتەیە بەکار بهێنە.

The ten keys of the course, correctedدە کۆرسەکە، ڕاستکراوە
Key	Identifies a row alone?بە تەنها دەناسێنێت؟	May be NULL?دەکرێت NULL بێت؟	Values may repeat?نرخ دووبارە دەبێتەوە؟	In our universityلە زانکۆکەماندا
1 Super١	yesبەڵێ	not in its key part; extra columns may beلە بەشە کلیلییەکەیدا نا؛ زیادەکانی دەکرێت	noنەخێر	`{student_no, full_name}`
2 Candidate٢	yes (minimal)بەڵێ (کەمترین)	noنەخێر	noنەخێر	`{student_no}, {email}`
3 Primary٣	yes (the chosen one)بەڵێ (هەڵبژێردراوەکە)	neverهەرگیز	neverهەرگیز	`student_no`
4 Alternate٤	yesبەڵێ	no (declare NOT NULL)نەخێر (⁦NOT NULL⁩ ڕابگەیەنە)	noنەخێر	`email`
5 Foreign٥	no — it linksنەخێر — دەبەستێتەوە	yes, if allowedبەڵێ، ئەگەر ڕێگەپێدراو بێت	yesبەڵێ	`enrolment.student_no`
6 Partial٦	only with the owner's keyتەنها لەگەڵ کلیلی خاوەنەکەی	noنەخێر	yes, across ownersبەڵێ، لە نێوان خاوەنەکاندا	`dependent.dependent_name`
7 Composite٧	yes, as a primary/candidate keyبەڵێ، وەک یان	not as a primary keyوەک نا	one column may; the combination may notیەک بەڵێ؛ تێکەڵەکە نەخێر	`(student_no, course_code, semester)`
8 Unique٨	yes, where it is not NULLبەڵێ، لەو شوێنانەی NULL نییە	yes (how many: depends on the DBMS)بەڵێ (چەند دانە: پەیوەستە بە )	no (except NULLs)نەخێر (جگە لە NULL)	`national_id`
9 Surrogate٩	yesبەڵێ	neverهەرگیز	neverهەرگیز	`enrolment_id`
10 Secondary١٠	no — for searchingنەخێر — بۆ گەڕان	yesبەڵێ	yesبەڵێ	`full_name`

Quick checkپشکنینی خێراWhat is the difference between a unique key and a surrogate key?جیاوازیی نێوان و چییە؟A unique key may be NULL and can never be changed; a surrogate key can be changed but never NULLکلیلی یەکتا دەکرێت NULL بێت و هەرگیز ناگۆڕدرێت؛ کلیلی دەستکرد دەگۆڕدرێت بەڵام هەرگیز NULL نییەA unique key is a real-world value that must not repeat (it may be NULL); a surrogate key is a meaningless ID made by the system, used as the primary key and never NULLکلیلی یەکتا نرخێکی جیهانی ڕاستەقینەیە کە نابێت دووبارە ببێتەوە (دەکرێت NULL بێت)؛ کلیلی دەستکرد ناسێنەرێکی بێواتایە کە سیستەمەکە دروستی دەکات، وەک کلیلی سەرەکی بەکار دێت و هەرگیز NULL نییە

Common mistakesهەڵە باوەکان

Mistakeهەڵە	Why it is wrongبۆچی هەڵەیە	Do this insteadلە جیاتی ئەوە ئەمە بکە
`full_name` as the primary key`full_name` وەک	Names repeat (two Arams)ناوەکان دووبارە دەبنەوە (دوو ئارام)	`student_no` or a surrogate key`student_no` یان
A mobile number as the primary key, called 'surrogate'ژمارەی مۆبایل وەک ، بە ناوی «»	It is a natural key that changes, is shared and is reused کە دەگۆڕێت، هاوبەشە و دووبارە بەکار دێتەوە	`id INT AUTO_INCREMENT PRIMARY KEY`; keep the phone as an ordinary column`id INT AUTO_INCREMENT PRIMARY KEY`؛ مۆبایلەکە وەک ئاسایی بهێڵەوە
`UNIQUE` alone on an alternate keyتەنها `UNIQUE` لەسەر	NULLs slip in, so it is no longer a candidate keyNULL دێتە ناوەوە، بۆیە ئیتر نییە	`NOT NULL UNIQUENOT NULL UNIQUE`
Expecting a foreign key to be uniqueچاوەڕوانی ئەوەی یەکتا بێت	One student has many enrolmentsیەک قوتابی چەندین تۆمارکردنی هەیە	Repeated values in a foreign key are normalنرخی دووبارە لە ئاساییە
A foreign key with a different type or length بە جۆر یان درێژییەکی جیاواز	The DBMS refuses the constraint or matches badly ڕەت دەکاتەوە یان بە خراپی بەراوردیان دەکات	Same type as the referenced column (`CHAR(9)` ↔ `CHAR(9)`)هەمان جۆری ئاماژەپێکراوەکە (`CHAR(9)` ↔ `CHAR(9)`)
Deleting a parent row and being surprised by the errorسڕینەوەی سەرەکی و سەرسوڕمان لە	NO ACTION is the default⁦NO ACTION⁩ بنەڕەتییە	Delete or move the child rows first, or choose `ON DELETE CASCADE` on purposeسەرەتا لاوەکییەکان بسڕەوە یان بیانگوازەوە، یان بە ئەنقەست `ON DELETE CASCADE` هەڵبژێرە
Several course codes in one cell ('DB101, WP101')چەند کۆدێکی وانە لە یەک خانەدا ⁦('DB101, WP101')⁩	No key can point to one of them; not in first normal formهیچ ناتوانێت ئاماژە بۆ یەکێکیان بکات؛ لە نییە	One row per course (Normalization)یەک بۆ هەر وانەیەک (نۆرماڵکردن)

Exercisesڕاهێنانەکان

ExerciseڕاهێنانKeys of a libraryکلیلەکانی کتێبخانەیەک

A university library stores every physical copy of a book: copy(barcode, isbn, copy_no, title, shelf). Each title (ISBN) can have several copies, numbered 1, 2, 3 … for that ISBN. Every copy also has a printed barcode label that is unique in the whole library. Find (a) the candidate keys, (b) a good primary key, (c) the alternate key, (d) one super key that is not a candidate key, (e) the prime attributes.

کتێبخانەی زانکۆیەک هەموو دانەیەکی فیزیکیی کتێبەکان هەڵدەگرێت: copy(barcode, isbn, copy_no, title, shelf). هەر ناونیشانێک ⁦(ISBN)⁩ دەکرێت چەند دانەیەکی هەبێت کە بۆ ئەو ISBNـە بە 1، 2، 3 … ژمارە کراون. هەر دانەیەک هەروەها لیبڵێکی بارکۆدی چاپکراوی هەیە کە لە هەموو کتێبخانەکەدا یەکتایە. ئەمانە بدۆزەوە: (أ) ، (ب) باش، (ج) ، (د) کە نەبێت، (هـ) .

Hintئاماژە

Ask: which columns alone, or together, can never repeat? Then remove what is not needed.

پرسیار بکە: کام بە تەنها یان پێکەوە هەرگیز دووبارە نابێتەوە؟ پاشان ئەوەی پێویست نییە لای ببە.

Show answerوەڵامەکە پیشان بدە

(a) Candidate keys: {barcode} and {isbn, copy_no}.
(b) barcode: one short column, printed on the copy, never changes. (A surrogate copy_id would also be fine.)
(c) {isbn, copy_no}, declared NOT NULL with UNIQUE (isbn, copy_no).
(d) For example {barcode, title} or {isbn, copy_no, shelf}: unique, but not minimal.
(e) barcode, isbn and copy_no. title and shelf are non-prime. Notice that title depends only on isbn, part of a candidate key — a problem that normalization removes.

(أ) : {barcode} و {isbn, copy_no}.
(ب) barcode: یەک کورتە، لەسەر دانەکە چاپ کراوە و هەرگیز ناگۆڕێت. (copy_idـی دەستکردیش باش دەبوو.)
(ج) {isbn, copy_no}، بە NOT NULL و UNIQUE (isbn, copy_no) ڕادەگەیەندرێت.
(د) بۆ نموونە {barcode, title} یان {isbn, copy_no, shelf}: یەکتان، بەڵام کەمترین نین.
(هـ) barcode، isbn و copy_no. title و shelf . ئاگادار بە کە title تەنها پشت بە isbn دەبەستێت، کە بەشێکە لە — کێشەیەک کە نۆرماڵکردن لای دەبات.

ExerciseڕاهێنانFix the mobile-number keyکلیلی ژمارەی مۆبایل چاک بکەرەوە

A teacher designs class_list(mobile, name, stage) and calls mobile the surrogate primary key, because every student in the class owns a phone. Explain the two mistakes and write a better CREATE TABLE.

مامۆستایەک class_list(mobile, name, stage) دیزاین دەکات و mobile بە دەستکرد ناو دەبات، چونکە هەموو قوتابییەکی پۆلەکە مۆبایلی هەیە. دوو هەڵەکە ڕوون بکەرەوە و CREATE TABLEێکی باشتر بنووسە.

Show answerوەڵامەکە پیشان بدە

(1) A mobile number is not a surrogate key: it comes from the real world, so it is a natural key. (2) It is a poor primary key: numbers change, brothers and sisters may share one, and an old number can be given to someone else. Add a real surrogate key and keep the phone as ordinary data:

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

SQLRuns in the databaseلە ناو بنکەدراوە کار دەکات

CREATE TABLE class_list (
  student_id INT AUTO_INCREMENT PRIMARY KEY,  -- surrogate key
  name       VARCHAR(100) NOT NULL,
  stage      INT          NOT NULL,
  mobile     VARCHAR(20)                      -- may change, may be shared, may be missing
);

ExerciseڕاهێنانLecturers and their dependents in SQLمامۆستاکان و کەسانی سەر بە ئەوان لە SQLدا

Write the CREATE TABLE statements for lecturer(lecturer_no, full_name, dept_code) and dependent(lecturer_no, dependent_name, relation). Use the right primary keys and foreign keys. When a lecturer is deleted, their dependents must disappear too.

فەرمانەکانی CREATE TABLE بنووسە بۆ lecturer(lecturer_no, full_name, dept_code) و dependent(lecturer_no, dependent_name, relation). و ڕاست بەکار بهێنە. کاتێک مامۆستایەک دەسڕدرێتەوە، دەبێت کەسانی سەر بەویش نەمێنن.

Hintئاماژە

The dependent table needs the owner's key plus the partial key.

خشتەی dependent پێویستی بە کلیلی خاوەنەکە لەگەڵ هەیە.

Show answerوەڵامەکە پیشان بدە

SQLRuns in the databaseلە ناو بنکەدراوە کار دەکات

CREATE TABLE lecturer (
  lecturer_no CHAR(3)      PRIMARY KEY,
  full_name   VARCHAR(100) NOT NULL,
  dept_code   CHAR(2)      NOT NULL,
  FOREIGN KEY (dept_code) REFERENCES department (dept_code)
);

CREATE TABLE dependent (
  lecturer_no    CHAR(3)     NOT NULL,
  dependent_name VARCHAR(50) NOT NULL,
  relation       VARCHAR(20) NOT NULL,
  PRIMARY KEY (lecturer_no, dependent_name),                         -- owner's key + partial key
  FOREIGN KEY (lecturer_no) REFERENCES lecturer (lecturer_no) ON DELETE CASCADE
);

ExerciseڕاهێنانAccepted or refused?وەردەگیرێت یان ڕەت دەکرێتەوە؟

Start from the university tables and their example rows (with the keys of university.sql). For each statement say whether the DBMS accepts it, and why: (a) DELETE FROM department WHERE dept_code = 'IT'; (b) UPDATE course SET course_code = 'DB100' WHERE course_code = 'DB101'; (c) INSERT INTO enrolment VALUES ('2024-0188', 'DB101', '2025-Spring', 'B');

لە خشتەکانی زانکۆ و نموونەییەکانیانەوە دەست پێبکە (بە university.sql). بۆ هەر فەرمانێک بڵێ ئایا وەری دەگرێت و بۆچی: (أ) DELETE FROM department WHERE dept_code = 'IT'; (ب) UPDATE course SET course_code = 'DB100' WHERE course_code = 'DB101'; (ج) INSERT INTO enrolment VALUES ('2024-0188', 'DB101', '2025-Spring', 'B');

Show answerوەڵامەکە پیشان بدە

(a) Refused: Shilan's row in student has dept_code = 'IT' (NO ACTION).
(b) Refused: enrolments and the prerequisite of DB201 point to DB101, and these foreign keys have no ON UPDATE CASCADE.
(c) Accepted: student 2024-0188 and course DB101 exist, and Karwan has no row for DB101 in 2025-Spring yet.

(أ) ڕەت دەکرێتەوە: شیلان لە studentدا dept_code = 'IT'ـی هەیە ⁦(NO ACTION)⁩.
(ب) ڕەت دەکرێتەوە: تۆمارکردنەکان و وانەی پێشوەختی ⁦DB201⁩ ئاماژە بۆ ⁦DB101⁩ دەکەن و ON UPDATE CASCADEیان نییە.
(ج) وەردەگیرێت: قوتابیی ⁦2024-0188⁩ و وانەی ⁦DB101⁩ هەن و کاروان هێشتا هیچ بۆ ⁦DB101⁩ لە ⁦2025-Spring⁩دا نییە.

All three answers were checked by running the statements.

هەر سێ وەڵامەکە بە جێبەجێکردنی فەرمانەکان پشکنران.

Exercisesڕاهێنانەکان

Exercises: finding the keysڕاهێنان: دۆزینەوەی کلیلەکان

ExerciseڕاهێنانTwo columns that are unique togetherدوو ستوون کە پێکەوە یەکتان

A company keeps staff(staff_no, full_name, dept, grade, salary_iqd, building, desk_no). Its rules: every member of staff has a staff number of their own, and every desk – a desk number inside a building – belongs to exactly one person. Desk 12 exists in building A and in building B. Which candidate keys does the table have?

کۆمپانیایەک staff(staff_no, full_name, dept, grade, salary_iqd, building, desk_no) هەڵدەگرێت. یاساکانی: هەر فەرمانبەرێک ژمارەیەکی فەرمانبەریی تایبەت بە خۆی هەیە و هەر مێزێک – ژمارەی مێزێک لە ناو باڵەخانەیەکدا – ڕێک هی یەک کەسە. مێزی ⁦12⁩ هەم لە باڵەخانەی A و هەم لە باڵەخانەی B هەیە. کامانەن؟

Show answerوەڵامەکە پیشان بدە

Two: {staff_no} and {building, desk_no}. Neither building nor desk_no is enough alone (desk 12 is in two buildings), but together they never repeat: a candidate key made of two attributes. staff_no becomes the primary key, and {building, desk_no} is an alternate key, declared NOT NULL with UNIQUE (building, desk_no). A second person at desk 12 of building B is then refused: UNIQUE constraint failed: staff.building, staff.desk_no.

دوو: {staff_no} و {building, desk_no}. نە building و نە desk_no بە تەنها بەس نین (مێزی ⁦12⁩ لە دوو باڵەخانەدایە)، بەڵام پێکەوە هەرگیز دووبارە نابنەوە: کە لە دوو پێکهاتووە. staff_no دەبێتە و {building, desk_no} ، بە NOT NULL و UNIQUE (building, desk_no) ڕادەگەیەنرێت. ئەوکات کەسی دووەم لەسەر مێزی ⁦12⁩ی باڵەخانەی B ڕەت دەکرێتەوە: UNIQUE constraint failed: staff.building, staff.desk_no.

ExerciseڕاهێنانWhich column can be a candidate key?کام ستوون دەتوانێت کلیلی پاڵێوراو بێت؟

A ministry's employee table has these columns. For each, say whether it can be a candidate key, and why: (a) employee_no, given by the ministry; (b) national_id; (c) family_name; (d) first_name + family_name; (e) district; (f) home_phone.

employeeـی وەزارەتێک ئەمانەن. بۆ هەر یەکێکیان بڵێ دەتوانێت بێت یان نا و بۆچی: (أ) employee_no، کە وەزارەت دەیدات؛ (ب) national_id؛ (ج) family_name؛ (د) first_name + family_name؛ (هـ) district؛ (و) home_phone.

Show answerوەڵامەکە پیشان بدە

(a) Yes: given once, never repeated, never empty. The best primary key.
(b) No: a foreign worker may have no Iraqi national card, so it can be NULL; and it is private data. At most a unique key.
(c) No: relatives share a family name.
(d) No: two people can have the same first and family name. Names never make reliable keys.
(e) No: many employees live in one district.
(f) No: a family shares one home phone, and numbers change.

(أ) بەڵێ: یەکجار دەدرێت، هەرگیز دووبارە نابێتەوە و هەرگیز بەتاڵ نییە. باشترین .
(ب) نەخێر: لەوانەیە کرێکارێکی بیانی کارتی نیشتمانیی عێراقیی نەبێت، بۆیە دەکرێت NULL بێت؛ هەروەها تایبەتە. لانی زۆر .
(ج) نەخێر: خزمان هەمان ناوی بنەماڵەیان هەیە.
(د) نەخێر: دوو کەس دەکرێت هەمان ناو و ناوی بنەماڵەیان هەبێت. ناو هەرگیز کلیلی متمانەپێکراو نییە.
(هـ) نەخێر: زۆر فەرمانبەر لە یەک گەڕەکدا دەژین.
(و) نەخێر: خێزانێک یەک تەلەفۆنی ماڵی هەیە و ژمارەکانیش دەگۆڕێن.

ExerciseڕاهێنانTwo tables: keys and degreesدوو خشتە: کلیلەکان و پلەکان

employee(national_id, full_name, address, department, employee_no) and dependent(employee_no, dependent_name, relation). Every employee has both a national ID number and a ministry number. (a) Give the candidate keys of employee. (b) What is the primary key of dependent, and which column links the two tables? (c) What is the degree of each table?

employee(national_id, full_name, address, department, employee_no) و dependent(employee_no, dependent_name, relation). هەموو فەرمانبەرێک هەم ژمارەی کارتی نیشتمانی و هەم ژمارەی وەزارەتی هەیە. (أ) employee بنووسە. (ب) dependent چییە و کام دوو دەبەستێتەوە؟ (ج) هەر یەکێکیان چەندە؟

Show answerوەڵامەکە پیشان بدە

(a) {employee_no} and {national_id}: here every employee has a national ID, so it is never NULL. Still choose employee_no as the primary key: it is short and not private.
(b) (employee_no, dependent_name): the owner's key plus the dependent's partial key (a weak entity). dependent.employee_no is a foreign key to employee.employee_no. To list one employee's dependents you need only dependent; add employee if you also want the employee's name.
(c) employee has degree 5 and dependent degree 3: the degree counts the columns (degree and cardinality).

(أ) {employee_no} و {national_id}: لێرەدا هەموو فەرمانبەرێک ژمارەی نیشتمانیی هەیە، بۆیە هەرگیز NULL نییە. هێشتا employee_no وەک هەڵبژێرە: کورتە و تایبەت نییە.
(ب) (employee_no, dependent_name): کلیلی خاوەنەکە لەگەڵ dependent_name (). dependent.employee_no بۆ employee.employee_no. بۆ لیستکردنی کەسانی سەر بە یەک فەرمانبەر تەنها dependentـت پێویستە؛ ئەگەر ناوی فەرمانبەرەکەشت دەوێت، employee زیاد بکە.
(ج) employee 5ـە و هی dependent 3: پلە دەژمێرێت (پلەی خشتە و ژمارەی تۆمارەکانی خشتە).

ExerciseڕاهێنانA cinema's hallsهۆڵەکانی سینەمایەک

A cinema in Erbil keeps movie(movie_id, title, release_date) and hall(hall_no, movie_id, seats, screen_type, ticket_iqd). A film runs in several halls, and each hall shows different films during the week. (a) Is movie_id a good primary key for movie? (b) Can hall_no be the primary key of hall while hall also stores movie_id? (c) Which foreign key is there?

سینەمایەک لە هەولێر movie(movie_id, title, release_date) و hall(hall_no, movie_id, seats, screen_type, ticket_iqd) هەڵدەگرێت. فیلمێک لە چەند هۆڵێکدا پیشان دەدرێت و هەر هۆڵێک لە ماوەی هەفتەدا فیلمی جیاواز پیشان دەدات. (أ) ئایا movie_id باشە بۆ movie؟ (ب) ئایا hall_no دەتوانێت hall بێت لە کاتێکدا hall movie_idیش هەڵدەگرێت؟ (ج) چ هەیە؟

Show answerوەڵامەکە پیشان بدە

(a) Yes: one number per film, never repeated.
(b) Only if each hall shows one film for ever. Hall 2 shows several films, so with hall_no as the key it can hold only one of them. Keep hall(hall_no, seats, screen_type) and add screening(hall_no, show_time, movie_id, ticket_iqd) with the key (hall_no, show_time): one hall, one time, one film.
(c) movie_id in hall (or, after the fix, in screening) is a foreign key to movie; in screening, hall_no is a foreign key to hall too.

(أ) بەڵێ: بۆ هەر فیلمێک یەک ژمارە، هەرگیز دووبارە نابێتەوە.
(ب) تەنها ئەگەر هەر هۆڵێک بۆ هەمیشە یەک فیلم پیشان بدات. هۆڵی 2 چەند فیلمێک پیشان دەدات، بۆیە بە hall_no وەک کلیل تەنها دەتوانێت یەکێکیان هەڵبگرێت. hall(hall_no, seats, screen_type) بهێڵەوە و screening(hall_no, show_time, movie_id, ticket_iqd) زیاد بکە بە کلیلی (hall_no, show_time): یەک هۆڵ، یەک کات، یەک فیلم.
(ج) movie_id لە hall (یان دوای چاککردنەکە لە screening) بۆ movie؛ لە screeningدا hall_noیش بۆ hall.

Exercisesڕاهێنانەکان

Exercises: will the DBMS accept the row?ڕاهێنان: ئایا سیستەمی بەڕێوەبردنی بنکەدراوە ڕیزەکە وەردەگرێت؟

ExerciseڕاهێنانOne sport per studentیەک وەرزش بۆ هەر قوتابییەک

Each student of a class may choose one sport: sport_choice(roll_no INT NOT NULL PRIMARY KEY, sport). Someone tries to store the rows (1, Football), (2, NULL), (3, Volleyball), (3, Basketball) and (NULL, Swimming). (a) May a student's sport be NULL? (b) Which rule do the two rows for roll number 3 break, and which key stops them? (c) Can (NULL, Swimming) be stored, as a sport that nobody chose?

هەر قوتابییەکی پۆلێک دەتوانێت یەک وەرزش هەڵبژێرێت: sport_choice(roll_no INT NOT NULL PRIMARY KEY, sport). کەسێک هەوڵ دەدات ⁦(1, Football)⁩، ⁦(2, NULL)⁩، ⁦(3, Volleyball)⁩، ⁦(3, Basketball)⁩ و ⁦(NULL, Swimming)⁩ هەڵبگرێت. (أ) ئایا وەرزشی قوتابییەک دەکرێت NULL بێت؟ (ب) دوو ژمارە 3 کام ڕێسا دەشکێنن و کام کلیل ڕێگەیان لێ دەگرێت؟ (ج) ئایا ⁦(NULL, Swimming)⁩ دەکرێت هەڵبگیرێت، وەک وەرزشێک کە کەس هەڵینەبژاردووە؟

Show answerوەڵامەکە پیشان بدە

(a) Yes: sport has no NOT NULL, so NULL simply means 'no choice yet'.
(b) Entity integrity: a primary key value may not repeat. The primary key on roll_no refuses the second row for 3.
(c) No: a primary key is never NULL. A list of all sports, chosen or not, belongs in a sport table of its own.

(أ) بەڵێ: sport بێ NOT NULLـە، بۆیە NULL تەنها واتە «هێشتا هەڵنەبژێردراوە».
(ب) : نرخی نابێت دووبارە بێتەوە. لەسەر roll_no دووەمی 3 ڕەت دەکاتەوە.
(ج) نەخێر: هەرگیز NULL نییە. لیستی هەموو وەرزشەکان، هەڵبژێردراو بن یان نا، sportـی تایبەت بە خۆی پێویستە.

SQLRuns in the databaseلە ناو بنکەدراوە کار دەکات

CREATE TABLE sport_choice (
  roll_no INT  NOT NULL PRIMARY KEY,
  sport   TEXT
);

INSERT INTO sport_choice VALUES (1, 'Football');
INSERT INTO sport_choice VALUES (2, NULL);
INSERT INTO sport_choice VALUES (3, 'Volleyball');
INSERT INTO sport_choice VALUES (3, 'Basketball');
INSERT INTO sport_choice VALUES (NULL, 'Swimming');
SELECT * FROM sport_choice;

ExerciseڕاهێنانA school-uniform shopدوکانی جلی قوتابخانە

A school-uniform shop in Duhok keeps uniform(ucode PRIMARY KEY, uname NOT NULL, ucolor) and cost(ucode, size, price_iqd CHECK (price_iqd > 0), PRIMARY KEY (ucode, size)), where cost.ucode is a foreign key to uniform. uniform already holds the codes 1–4. Which rows are accepted? (a) uniform (7, 'Scarf', NULL); (b) uniform (4, 'Belt', 'Black'); (c) uniform (8, NULL, 'White'); (d) cost (7, 'S', 0); (e) cost (9, 'XL', 15000).

دوکانێکی جلی قوتابخانە لە دهۆک uniform(ucode PRIMARY KEY, uname NOT NULL, ucolor) و cost(ucode, size, price_iqd CHECK (price_iqd > 0), PRIMARY KEY (ucode, size)) هەڵدەگرێت و cost.ucode بۆ uniform. uniform پێشتر کۆدەکانی 1 تا 4ی تێدایە. کام وەردەگیرێن؟ (أ) ⁦uniform (7, 'Scarf', NULL)⁩؛ (ب) ⁦uniform (4, 'Belt', 'Black')⁩؛ (ج) ⁦uniform (8, NULL, 'White')⁩؛ (د) ⁦cost (7, 'S', 0)⁩؛ (هـ) ⁦cost (9, 'XL', 15000)⁩.

Show answerوەڵامەکە پیشان بدە

(a) Accepted: only the colour is missing, and it may be NULL.
(b) Refused: code 4 already exists (primary key).
(c) Refused: uname is NOT NULL.
(d) Refused: the CHECK wants a price above 0.
(e) Refused: there is no uniform 9, so the row would be an orphan (referential integrity). Without the foreign key the DBMS would accept it, and the shop would sell a price for nothing.

(أ) وەردەگیرێت: تەنها ڕەنگەکە نییە و دەکرێت NULL بێت.
(ب) ڕەت دەکرێتەوە: کۆدی 4 پێشتر هەیە ().
(ج) ڕەت دەکرێتەوە: uname بە NOT NULLـە.
(د) ڕەت دەکرێتەوە: CHECK نرخێکی سەرووی 0 دەوێت.
(هـ) ڕەت دەکرێتەوە: جلی ژمارە 9 نییە، بۆیە دەبێتە (). بەبێ وەریدەگرت و دوکانەکە نرخی بۆ شتێک دادەنا کە بوونی نییە.

SQLRuns in the databaseلە ناو بنکەدراوە کار دەکات

PRAGMA foreign_keys = ON;

CREATE TABLE uniform (
  ucode  INT  NOT NULL PRIMARY KEY,
  uname  TEXT NOT NULL,
  ucolor TEXT
);
CREATE TABLE cost (
  ucode     INT  NOT NULL,
  size      TEXT NOT NULL,
  price_iqd INT  CHECK (price_iqd > 0),
  PRIMARY KEY (ucode, size),
  FOREIGN KEY (ucode) REFERENCES uniform (ucode)
);
INSERT INTO uniform VALUES (1, 'Shirt', 'White'), (2, 'Trousers', 'Grey'),
                           (3, 'Tie', 'Blue'), (4, 'Jacket', 'Navy');

INSERT INTO uniform VALUES (7, 'Scarf', NULL);       -- (a)
INSERT INTO uniform VALUES (4, 'Belt', 'Black');     -- (b)
INSERT INTO uniform VALUES (8, NULL, 'White');       -- (c)
INSERT INTO cost    VALUES (7, 'S', 0);              -- (d)
INSERT INTO cost    VALUES (9, 'XL', 15000);         -- (e)

ExerciseڕاهێنانAdd the rules afterwards (MySQL)ڕێساکان دواتر زیاد بکە ⁦(MySQL)⁩

The shop first made its tables without any rules: uniform(ucode INT PRIMARY KEY, uname VARCHAR(30), ucolor VARCHAR(20)) and cost(ucode INT, size VARCHAR(4), price_iqd INT, PRIMARY KEY (ucode, size)). cost already has a row for code 9, but uniform has no item 9 yet (it is a sweater). With ALTER TABLE, add: a foreign key from cost to uniform, NOT NULL on uname, and a CHECK that prices are above 0. What must you do first?

دوکانەکە سەرەتا خۆی بەبێ هیچ ڕێسایەک دروست کرد: uniform(ucode INT PRIMARY KEY, uname VARCHAR(30), ucolor VARCHAR(20)) و cost(ucode INT, size VARCHAR(4), price_iqd INT, PRIMARY KEY (ucode, size)). cost پێشتر بۆ کۆدی 9 هەیە، بەڵام uniform هێشتا جلی ژمارە 9ی نییە (بلوزێکە). بە ALTER TABLE ئەمانە زیاد بکە: لە costـەوە بۆ uniform، NOT NULL لەسەر uname و CHECKێک کە نرخەکان سەرووی 0 بن. سەرەتا دەبێت چی بکەیت؟

Show answerوەڵامەکە پیشان بدە

First repair the data: add the missing item 9. Otherwise the row for code 9 stays an orphan and the new foreign key cannot hold. MySQL also refuses to add a CHECK that existing rows already break, so fix any price of 0 before adding it.

سەرەتا چاک بکەرەوە: جلی ژمارە 9 زیاد بکە. ئەگەرنا کۆدی 9 هەر دەمێنێتەوە و ناتوانێت ڕاست بێت. MySQL هەروەها ڕێگە نادات CHECKێک زیاد بکرێت کە ئێستا دەیشکێنن، بۆیە پێش زیادکردنی هەر نرخێکی 0 چاک بکەرەوە.

MySQL 8بۆ ⁦MySQL 8⁩SQLRuns in the databaseلە ناو بنکەدراوە کار دەکات

INSERT INTO uniform VALUES (9, 'Sweater', 'Navy');

ALTER TABLE cost
  ADD CONSTRAINT fk_cost_uniform FOREIGN KEY (ucode) REFERENCES uniform (ucode);
ALTER TABLE uniform
  MODIFY uname VARCHAR(30) NOT NULL;
ALTER TABLE cost
  ADD CONSTRAINT price_positive CHECK (price_iqd > 0);

Explain the codeڕوونکردنەوەی کۆدەکە

Lineدێڕی 4

MODIFY repeats the whole column definition, now with NOT NULL.

MODIFY هەموو پێناسەی دووبارە دەکاتەوە، ئێستا بە NOT NULLەوە.

Lineدێڕی 6

MySQL enforces CHECK from version 8.0.16.

MySQL لە وەشانی ⁦8.0.16⁩ـەوە CHECK جێبەجێ دەکات.

ExerciseڕاهێنانStudents and their projectsقوتابیان و پرۆژەکانیان

student(roll_no PRIMARY KEY, name, class, section, registration_id NOT NULL UNIQUE), project(project_no PRIMARY KEY, pname, submission_date) and project_assigned(registration_id, project_no): each row of the last table says which student works on which project. (a) Name the primary keys, the foreign keys and the alternate key. (b) May two students have the same roll number? (c) Which inserts succeed: a student without a roll number; a student without a registration ID; a project without a submission date; registration ID R-9999 on project 999, neither of which exists?

student(roll_no PRIMARY KEY, name, class, section, registration_id NOT NULL UNIQUE)، project(project_no PRIMARY KEY, pname, submission_date) و project_assigned(registration_id, project_no): هەر کۆتایی دەڵێت کام قوتابی لەسەر کام پرۆژە کار دەکات. (أ) ، و ناو بهێنە. (ب) ئایا دوو قوتابی دەکرێت هەمان ژمارەی ڕیزیان هەبێت؟ (ج) کام زیادکردن سەردەکەوێت: قوتابییەک بێ ژمارەی ڕیز؛ قوتابییەک بێ ژمارەی تۆمار؛ پرۆژەیەک بێ ڕێکەوتی ڕادەستکردن؛ ژمارەی تۆماری ⁦R-9999⁩ لەسەر پرۆژەی ⁦999⁩، کە هیچیان بوونیان نییە؟

Show answerوەڵامەکە پیشان بدە

(a) Primary keys: student.roll_no, project.project_no and the composite (registration_id, project_no). Foreign keys: project_assigned.registration_id → student.registration_id (a foreign key may point to a unique key) and project_assigned.project_no → project.project_no. Alternate key: student.registration_id.
(b) No: roll_no is the primary key. (In real schools roll numbers start again in every class, so the true key would be (class, section, roll_no), as in the course's examples.)
(c) Only the project without a date succeeds. The two students break NOT NULL, and the assignment breaks both foreign keys.

(أ) : student.roll_no، project.project_no و کلیلە لێکدراوەکەی (registration_id, project_no). : project_assigned.registration_id بۆ student.registration_id ( دەکرێت ئاماژە بۆ بکات) و project_assigned.project_no بۆ project.project_no. : student.registration_id.
(ب) نەخێر: roll_no . (لە قوتابخانە ڕاستەقینەکاندا ژمارەی ڕیز لە هەر پۆلێکدا لە سەرەوە دەست پێدەکاتەوە، بۆیە کلیلی ڕاستەقینە (class, section, roll_no) دەبوو، وەک نموونەکانی کۆرسەکە.)
(ج) تەنها پرۆژە بێ ڕێکەوتەکە سەردەکەوێت. دوو قوتابییەکە NOT NULL دەشکێنن و دابەشکردنەکە هەردوو دەشکێنێت.

SQLRuns in the databaseلە ناو بنکەدراوە کار دەکات

PRAGMA foreign_keys = ON;

CREATE TABLE student (
  roll_no         INT  NOT NULL PRIMARY KEY,
  name            TEXT NOT NULL,
  class           INT,
  section         TEXT,
  registration_id TEXT NOT NULL UNIQUE
);
CREATE TABLE project (
  project_no      INT  NOT NULL PRIMARY KEY,
  pname           TEXT NOT NULL,
  submission_date DATE
);
CREATE TABLE project_assigned (
  registration_id TEXT NOT NULL REFERENCES student (registration_id),
  project_no      INT  NOT NULL REFERENCES project (project_no),
  PRIMARY KEY (registration_id, project_no)
);
INSERT INTO student VALUES (1, 'Aram', 11, 'A', 'R-1001'), (2, 'Shilan', 11, 'B', 'R-1002');
INSERT INTO project VALUES (101, 'Weather station', '2026-03-01');

INSERT INTO student VALUES (NULL, 'Karwan', 11, 'A', 'R-1003');     -- no roll number
INSERT INTO student VALUES (3, 'Dilan', 11, 'B', NULL);             -- no registration ID
INSERT INTO project VALUES (102, 'School website', NULL);           -- no date
INSERT INTO project_assigned VALUES ('R-9999', 999);                -- nobody, nothing

Exercisesڕاهێنانەکان

Quick check: name the termپشکنینی خێرا: ناوی زاراوەکە بهێنە

Review questionsپرسیارەکانی پێداچوونەوە

A collection of logically related records, kept together.کۆمەڵێک تۆمار کە بە لۆجیکی پەیوەندییان پێکەوە هەیە و پێکەوە هەڵدەگیرێن.

A database.

.

The place where the DBMS keeps the description of every table, column and key.ئەو شوێنەی سیستەمی بەڕێوەبردنی بنکەدراوە وەسفی هەموو خشتە، ستوون و کلیلێکی تێدا هەڵدەگرێت.

The data dictionary, also called the system catalog (the database describes itself).

، کە پێی دەوترێت کاتالۆگی سیستەمیش (بنکەدراوە خۆی وەسف دەکات).

The attribute (or set of attributes) chosen to identify each tuple.ئەو خەسڵەتەی (یان کۆمەڵە خەسڵەتەی) کە بۆ دیاریکردنی هەر تۆمارێک هەڵبژێردراوە.

The primary key.

.

What is stored when a value is unknown or does not apply.ئەوەی هەڵدەگیرێت کاتێک نرخێک نەزانراوە یان پەیوەندیی نییە.

NULL.

.

A candidate key that was not chosen as the primary key.کلیلێکی پاڵێوراو کە وەک کلیلی سەرەکی هەڵنەبژێردراوە.

An alternate key.

.

Software used to create and manage a relational database.ئەو نەرمەواڵەیەی بۆ دروستکردن و بەڕێوەبردنی بنکەدراوەیەکی پەیوەندیدار بەکار دێت.

An RDBMS (a relational DBMS), such as MySQL, PostgreSQL or SQLite.

RDBMS ( بۆ )، وەک MySQL، PostgreSQL یان .

What is the difference between the degree and the cardinality of a relation?جیاوازیی نێوان پلەی خشتە و ژمارەی تۆمارەکانی خشتە چییە؟

The degree is the number of attributes (columns) and changes only with the design; the cardinality is the number of tuples (rows) now (degree and cardinality). Do not confuse it with E-R cardinality (1:1, 1:N, M:N).

ژمارەی () و تەنها بە گۆڕینی دیزاین دەگۆڕێت؛ ژمارەی ئێستایە (پلەی خشتە و ژمارەی تۆمارەکانی خشتە). تێکەڵی مەکە لەگەڵ لە (1:1، 1:N، M:N).

Summary and reviewپوختە و پێداچوونەوە

Good design: clear meaning, little repetition (no update anomalies), few NULLs.
Super key ⊇ candidate key (minimal) ⊇ primary key (the chosen one); the other candidate keys are alternate keys.
A primary key is never NULL and never repeated; a table has only one.
A foreign key points to a primary (or unique) key; it may repeat and may be NULL if allowed. Referential integrity decides what happens on DELETE and UPDATE.
Partial key = the weak entity's own attribute (dependent_name), used together with the owner's key.
Composite key = any key with several columns. Unique key = no duplicates, NULL allowed, can be updated.
Surrogate key = a meaningless ID made by the system; natural key = real-world data. Secondary key = an indexed column for searching.

دیزاینی باش: واتای ڕوون، دووبارەبوونەوەی کەم (بێ )، NULLی کەم.
⊇ (کەمترین) ⊇ (هەڵبژێردراوەکە)؛ تر .
هەرگیز NULL نییە و هەرگیز دووبارە نابێتەوە؛ هەر خشتەیەک تەنها یەکی هەیە.
ئاماژە بۆ (یان ) دەکات؛ دەکرێت دووبارە ببێتەوە و ئەگەر ڕێگەپێدراو بێت NULL بێت. بڕیار دەدات لە کاتی DELETE و UPDATEدا چی ڕوو بدات.
= خەسڵەتی خودی ⁦(dependent_name)⁩، کە لەگەڵ کلیلی خاوەنەکەیدا بەکار دێت.
= هەر بە چەند . = بێ دووبارە، NULL ڕێگەپێدراوە، دەتوانرێت نوێ بکرێتەوە.
= ناسێنەرێکی بێواتا کە سیستەمەکە دروستی دەکات؛ = جیهانی ڕاستەقینە. = کە هەیە بۆ گەڕان.

Review questionsپرسیارەکانی پێداچوونەوە

What is a super key?کلیلی باڵا چییە؟

Any set of attributes that can identify each tuple uniquely.

هەر کۆمەڵە خەسڵەتێک کە بتوانێت هەر بە تەنها بناسێنێت.

What makes a candidate key different from a super key?چی کلیلی پاڵێوراو لە کلیلی باڵا جیا دەکاتەوە؟

A candidate key is minimal: remove any attribute and it stops working.

کەمترینە: هەر خەسڵەتێکی لێ لاببەیت ئیتر کار ناکات.

Can a foreign key be NULL?ئایا کلیلی بیانی دەتوانێت NULL بێت؟

Yes, if the column allows NULL. It can also be repeated. That is unlike a primary key.

بەڵێ، ئەگەر ڕێگە بە NULL بدات. هەروەها دەکرێت دووبارە ببێتەوە. ئەمە بە پێچەوانەی .

What is the difference between a unique key and a surrogate key?جیاوازیی نێوان کلیلی یەکتا و کلیلی دەستکرد چییە؟

A unique key is a real-world value that must not repeat; it may be NULL (how many NULLs depends on the DBMS) and it can be updated. A surrogate key is a meaningless ID made by the system, used as the primary key, never NULL and normally never changed. (The course's answer 'unique: NULL, not updatable; surrogate: updatable, never NULL' is wrong.)

نرخێکی جیهانی ڕاستەقینەیە کە نابێت دووبارە ببێتەوە؛ دەکرێت NULL بێت (ژمارەی NULLەکان پەیوەستە بە ) و دەتوانرێت نوێ بکرێتەوە. ناسێنەرێکی بێواتایە کە سیستەمەکە دروستی دەکات، وەک بەکار دێت، هەرگیز NULL نییە و بە ئاسایی هەرگیز ناگۆڕدرێت. (وەڵامی کۆرسەکە «یەکتا: NULL، نوێ ناکرێتەوە؛ دەستکرد: نوێ دەکرێتەوە، هەرگیز NULL نییە» هەڵەیە.)

What is a foreign key?کلیلی بیانی چییە؟

A copy of a primary key (or another unique key) placed in another table to form a relationship.

کۆپییەکی (یان تر) کە لە خشتەیەکی تردا دادەنرێت بۆ دروستکردنی پەیوەندی.

Name the three integrity rules that keys enforce.ناوی ئەو سێ ڕێسای دروستییە بهێنە کە کلیلەکان جێبەجێیان دەکەن.

Domain constraints (type, NOT NULL, CHECK), entity integrity (primary key unique and never NULL) and referential integrity (foreign keys match existing rows).

(جۆر، ⁦NOT NULL⁩، CHECK)، ( یەکتا و هەرگیز NULL نییە) و ( لەگەڵ هەبووەکاندا یەک دەگرنەوە).

Videoڤیدیۆ

Watch a videoسەیری ڤیدیۆیەک بکە

A video that viewers liked a lot and praised in their comments, chosen for this lesson.ڤیدیۆیەک کە بینەران زۆریان پێ خۆش بووە و لە کۆمێنتەکانیاندا ستایشیان کردووە، بۆ ئەم وانەیە هەڵبژێردراوە.

Database Keys Made Easy - Primary, Foreign, Candidate, Surrogate, & Many MoreDecomplexify · Englishئینگلیزی · 290K viewsبینین · 9.5K likesلایک
All the main keys with clear examples: primary, candidate, super, alternate and foreign keys, surrogate and natural keys, and composite keys.
گرنگترین جۆرەکانی بە نموونەی ڕوون: ، ، ، ، ، ، و .
Whole video: a review of most keys in this lesson (it does not cover unique, partial or secondary keys).
هەموو ڤیدیۆکە: پێداچوونەوەیەک بە زۆربەی ئەم وانەیەدا (باسی ، و ناکات).

Lesson complete!وانەکە تەواو بوو!

Well done. Review the key terms, then go on to the next lesson.دەستخۆش. سەیرێکی زاراوە سەرەکییەکان بکەرەوە، پاشان بڕۆ بۆ وانەی داهاتوو.

Key termsزاراوە سەرەکییەکان

Next lessonوانەی داهاتوو

Normalizationنۆرماڵکردن

Related lecturesوانە پەیوەندیدارەکان

References and further readingسەرچاوەکان و خوێندنەوەی زیاتر

This lecture is a first edition. The Kurdish text and terminology are waiting for review by Kurdish IT teachers.ئەم وانەیە چاپی یەکەمە. دەقە کوردییەکە و زاراوەکانی چاوەڕێی پێداچوونەوەی مامۆستایانی کوردی بواری IT ن.