SQL-dəki açarlar

Sistem dizaynı ilə bağlı müsahibə sualları o qədər açıq ola bilər ki, düzgün hazırlaşmağı bilmək çox çətindir. İndi satın aldıqdan sonra Amazon, Microsoft və Adobe-nin dizayn dövrlərini sındıra bilirəm Bu kitabı. Gündəlik bir yenidən nəzərdən keçirin dizayn sualı və söz verirəm ki, dizayn dövrünü sındıra bilərsiniz.

Açar nədir? SQL-də bunlara niyə ehtiyacımız var?

Verilənlər bazası cədvəllərdən ibarətdir. Hər cədvəldə çox sayda qeyd / sətir var. Hər sətirdə istənilən obyekt haqqında bənzərsiz məlumatlar olacaqdır. Yəni verilənlər bazasındakı hər bir cədvəl hər hansı bir real dünya obyektini təmsil etmək üçün nəzərdə tutulmuşdur və həmin obyekt haqqında məlumat ehtiva edir. Beləliklə, cədvəldəki hər bir satır eyni cədvəldəki digər sətirlərdən asılı deyil və onları bir-birindən fərqləndirmək üçün hər sətir üçün bəzi unikal identifikatorlara ehtiyacımız var. Hər sətri unikal şəkildə müəyyənləşdirən hər sətirdəki bu unikal identifikator cədvəlin açarı kimi tanınır. Bu açar tək sütun və ya sütun birləşməsi ola bilər.

Aşağıdakı sütunlarla İŞÇİLƏR cədvəlini nəzərdən keçirin.

İŞÇİLƏR cədvəlində hər sətir bütün bu sütun dəyərlərindən ibarətdir. Burada EMPLOYEE_ID işçinin şəxsiyyət vəsiqəsidir. Sonra adı, e-poçtu, telefon nömrəsi, şöbəyə işə qəbul olunduğu tarix, iş id, maaş, komissiya, menecer və şöbəsi. Bütün bu sütunları izlədiyimiz zaman hər bir işçinin digərini fərqləndirən ad olduğunu görə bilərik. Ancaq eyni adlı iki işçi ola bilər. Bu səbəbdən hər satırı müəyyənləşdirmək üçün addan unikal sütun kimi istifadə edə bilmərik. Ancaq ƏMƏKDAŞLIQ hər işçi üçün unikaldır. Heç iki işçinin eyni işçi identifikatoru ola bilməz. Beləliklə bir əsas sütun ola bilər. Eynilə, hər bir işçinin e-poçt identikliyi unikaldır və bu cədvəldəki hər bir qeydin müəyyənləşdirilməsi üçün istifadə edə bilərik. Telefon nömrəsi ilə də eyni.

JOB_ID başqa bir şəxsiyyət sütunudur, lakin eyni iş kimliyinə sahib bir çox işçi ola bilər. Buna görə hər sətri təyin etmək üçün onu unikal sütun kimi istifadə edə bilmərik. HIRE_DATE, SALARY, COMMISSION_PCT, MANAGER_ID və DEPARTMENT_ID kimi digər sütunlarda da eyni problem var və açar sütun kimi istifadə edilə bilməz.
Beləliklə, EMPLOYEE_ cədvəlindəki hər bir satırı təyin etmək üçün EMPLOYEE_ID, EMAIL və PHONE_NUMBER sütunlarını istifadə edə bilərik. Bu sütunların birləşməsini açar kimi istifadə etməyimizə ehtiyac yoxdur. Sütunlardan hər hansı biri satırları təyin etmək üçün kifayətdir. Buna görə bütün bu sütunlar fərdi olaraq bir açar sütun kimi davranırlar.

Tutaq ki, hər bir işçi birdən çox şöbədə işləyə bilər. Sonra İŞÇİLƏR cədvəlində bölmələrinin hər biri üçün onun üçün birdən çox girişimiz olacaq. Bu halda qeydini təyin etmək üçün təkcə EMPLOYEE_ID-dən və ya EMAIL-dən və ya yalnız PHONE_NUMBER nömrəsindən istifadə edə bilmərik. İŞÇİLƏR cədvəlindəki hər bir qeydləri özünəməxsus şəkildə təyin edən bu üç sütundan hər hansı biri ilə birlikdə onun şöbəsidir.

Burada Alexander 30 və 60 şöbələrində Katib və İT Proqramçısı vəzifəsində çalışır. Buna görə EMPLOYEE_ID = 103 deyiriksə, onun qeydini unikal şəkildə təyin edə bilmərik. Həm qeydləri qaytaracaq. Axtarışı bənzərsiz hala gətirməyəcəkdir. Bunun əvəzinə EMPLOYEE_ID və DEPARTMENT_ID-i açar halına gətirsək, hər bir satırı özünəməxsus şəkildə müəyyən edə bilərik. Eynilə (EMAIL və DEPARTMENT_ID) və (PHONE_NUMBER və DEPARTMENT_ID) birləşməsi hər bir satırı özünəməxsus şəkildə müəyyənləşdirir. Yəni bu tip ssenaridə açar sütunların birləşməsidir. Beləliklə cədvəldə açarın təyin edilməsi cədvəlin şərtlərindən asılıdır. yəni; 'Hər bir işçi bir şöbə üçün işləyir' və 'hər bir işçi birdən çox şöbəyə sahib ola bilər' düymələri seçməkdə fərq yaradır. Buna görə əvvəlcə tələbi diqqətlə başa düşməliyik və sonra hər sətri özünəməxsus şəkildə əldə etmək üçün açara qərar verməliyik.

Sadə açar nədir?

Sadə açar cədvəlin bir sütunundan ibarət olan açar sütundur. Yəni cədvəlin yalnız bir sütunu cədvəldəki hər bir qeydləri özünəməxsus şəkildə təyin edir.

Məsələn, İŞÇİLƏR cədvəlində ya ƏMƏKÇİE_ID, EMAIL ya da TELEFON NUMARASI işçilər cədvəlindəki hər bir qeydləri təyin edə bilər (nəzərə alın ki, hər işçi yalnız bir şöbə üçün işləyir). Buna görə İŞÇİLƏR cədvəli üçün əsas sütun bu sütunlardan biridir və bu açar sütunlar sadə açar sütunlar adlanır.

Eynilə, DEPARTMENTS cədvəlində, yalnız DEPARTMENT_ID cədvəldəki hər bir qeydin təyin edilməsi üçün kifayətdir. Beləliklə DEPARTMENT_ID bir açar sütundur və sadə bir açar sütundur.

Bir düymənin NULL dəyərləri ola bilərmi?

Açar cədvəldəki hər bir qeydləri özünəməxsus şəkildə müəyyənləşdirə bilən bir sütun və ya sütun dəstidir. NULL dəyəri 'BİLMƏDİ' və ya 'Heç bir şey' deməkdir. SQL-də hər iki NULL dəyəri eyni mənanı verdiklərinə baxmayaraq tamamilə fərqlidir. Ancaq eyni NULL dəyərindən istifadə edərək, cədvəldə heç bir sıra müəyyən edə bilmirik. Bunun səbəbi SQL-in NULL = NULL-u müqayisə edə bilməməsidir (burada qeyd edin ki, bu iki boşluq iki fərqli dəyərdən bəhs edir, buna görə heç vaxt bərabər ola bilməzlər).

Ayrıca, açar sütununda NULL olan hər iki sətir varsa, onları nə ayırd edə, nə də müqayisə edə bilərik. Bu açarın tərifi ilə ziddiyyət təşkil edir. Buna görə hər hansı bir açar sütunun içində heç bir NULL dəyəri ola bilməz. Başqa sözlə, əsas sütunlar və ya namizəd açarları olaraq NULL dəyərinə sahib olan hər hansı bir sütunu seçə bilmərik.

Ancaq 'açar NULL ola bilməz' baş barmağı qaydasıdır, SQL xarici açar və unikal açarın NULL olmasına imkan verir. Ancaq bu iki açarı NULL etmək vəziyyətdən və tələbdən asılıdır.

EMPLOYEES cədvəlindəki MANAGER_ID, EMPLOYEES cədvəlinin xarici açarıdır. Burada ən yaxşı menecerin meneceri olmayacaq və onun MANAGER_ID dəyəri NULL olacaq.

Əsas düymə, xarici açar və unikal açar arasında nə fərq var?

Əsas düymə, unikal açar və xarici açar cədvəlin bir və ya daha çox sütunundan ibarət olan açarlardır. Hamısı birlikdə masanın məhdudiyyətlərinə güc verir və onu daha da gücləndirir. Ancaq hər biri öz funksiyalarını həll etmək üçün bir masa üzərində yaradılmışdır.

  • Əsas açar : Eyni cədvəlin bir və ya daha çox sütundan ibarət cədvəldəki açar sütundur. Bu əsas düymə cədvəldəki hər bir qeydin unikal şəkildə müəyyənləşdirilməsində istifadə olunan açardır. Bu qeydləri müəyyənləşdirdiyimiz əsas sütundur.

Məsələn, İŞÇİLƏR cədvəlində şöbədəki hər bir işçini müəyyənləşdirmək üçün EMPLOYEE_ID istifadə edirik. Beləliklə, ƏMƏKDAŞLIQ hər işçini digərindən fərqləndirən cədvəldəki misilsiz sütundur. Heç iki işçinin eyni şəxsiyyət vəsiqəsi ola bilməz. Buna görə də əsas açar sütun kimi qəbul edilir.

Eynilə, ŞƏKİLLƏR cədvəlini nəzərdən keçirsək, hər şöbəni adı ilə müəyyənləşdirə bilərik. Ancaq eyni adlı iki şöbə ola bilər. Qarışıqlığın qarşısını almaq üçün hər şöbəyə unikal olan şəxsiyyət vəsiqələri veririk. Bu səbəbdən DEPARTMENTS cədvəlindəki DEPARTMENT_ID birincil açar kimi qəbul edilir. Bu sütun dəyərindən istifadə edərək hər şöbəni digərindən fərqləndirə bilərik.

  • Unikal açar : Bu da əsas düyməyə bənzəyir.  Bunlar cədvəldəki hər bir qeydi digərindən unikal şəkildə müəyyən etmək üçün istifadə edilə bilən sütun və ya sütunlar dəsti. Başqa sözlə, hər bir unikal açar CAN BE əsas açar (hamısının əsas açar olması lazım deyil; hər hansı biri əsas açar ola bilər); və əsas açar A unikal açar.

Məsələn, İŞÇİLƏR cədvəlində e-poçt və telefon nömrəsi kimi digər sütunlarımız var. Hər hansı bir işçi və ya insan üçün bu iki dəyər bənzərsizdir. Bu o deməkdir ki, iki işçinin eyni e-poçt və ya telefon nömrəsi ola bilməz. yəni; bu iki sahə hər bir işçi üçün unikaldır. Beləliklə, EMAIL və PHONE_NUMBER, EMPLOYEES cədvəlində unikal açar sütunlardır. Hətta EMPLOYEE_ID unikal bir açar sütundur və hər bir qeydin əsas açarı olaraq müəyyənləşdirilməsi üçün bu sütunu seçdik.

  • Xarici Açar : Sadə sözlə, bu cari cədvəldə mövcud olan başqa bir cədvəlin sütunudur. SQL əlaqəli bir verilənlər bazasıdır və DB-dəki hər bir cədvəl valideyn-uşaq münasibətləri vasitəsi ilə bir-biri ilə əlaqəlidir. Beləliklə, valideyn və uşağı təmsil etmək və ya tanımaq üçün masaları, ana cədvəlin əsas açar sütununu uşaq cədvəlinə əlavə edirik - beləliklə əlaqəni qururuq. Uşaq cədvəlindəki bu ana açar sütunu xarici açar sütunu olaraq bilinir. Bu sütundan istifadə edərək uşaq cədvəlindəki qeydlərin hansı kateqoriyaya və ya valideynə aid olduğunu müəyyən edə bilərik.

Eyni İŞÇİLƏR və DEPARTEMNTS nümunəsini nəzərdən keçirin. Hər bir işçi müəyyən bir şöbədə işləyəcəkdir. Yəni hər bir işçinin şöbəsini təmsil edən bir ana açar sütunu var. Bu səbəbdən DEPARTMENTS cədvəlindəki DEPARTMENT_ID onun əsas açarı və İŞÇİLƏR cədvəlində xarici açardır.

Xarici açara niyə ehtiyacımız var? Referensial bütövlüyün əldə edilməsində necə kömək edir?

Xarici Düymələr bir verilənlər bazasında valideyn-övlad münasibətlərinin qurulmasına kömək edir. Bu, məlumatların referans bütövlüyü olaraq da bilinir. Bu bir verilənlər bazasında çox vacibdir. Bir verilənlər bazası və ya cədvəlləri bir DB-də tərtib etdikdə, cədvəlləri bir-birimizlə uyğunlaşdırmalı və ya əlaqələndirməliyik. Hər hansı iki cədvəl arasında bir əlaqə və ya Xəritəçəkmə yoxdursa, hər hansı bir dəyəri ola bilər və heç bir məlumat arasında heç bir bütövlük olmayacaqdır. Artıq məlumatlar da ola bilər.

İŞÇİLƏR və ŞƏKİLLƏR cədvəlinin müstəqil olduqlarını və aralarında heç bir Xəritəçəkmə olmadığını düşünün. ŞƏKİLLƏR cədvəlində bütün şöbələrin siyahısı var. İşçilər cədvəlində bütün işçilər və onların şöbələri olacaqdır. ŞƏKİLLİKLƏR və İŞÇİLƏR arasında heç bir xəritəçəkmə olmadığından, məlumatları İŞÇİLƏR cədvəlinə daxil etdikdə, BÖLMƏLƏR cədvəlində mövcudluğu üçün daxili yoxlama olmayacaqdır. Yəni mövcud olmayan şöbədə işləyən bir işçini masaya əlavə etməyimizə imkan verəcəkdir! Bu məqbul deyil və sistemdəki bütün səhv məlumatları meydana gətirəcəkdir.

Eynilə, birdən çox şöbədə çalışan təkrarlanan işçiləri daxil etməyimizə imkan verəcəkdir. Bu da məqbul deyil. Beləliklə, xarici açar vasitəsi ilə ŞƏKİLLİKLƏR və İŞÇİLƏR arasında bir xəritə yaratma yuxarıdakı səhvləri dayandıracaqdır.
Həm işçilərdə, həm də şöbələrdə yalnız DEPARTMENT_ID-in olması, aralarında heç bir xəritə yaratmayacağını unutmayın. Bunun səbəbi; derleyici bu cədvəllərin hər ikisində DEPARTMENT_ID-i başa düşməyəcəkdir. Xəritəçəkməyə sahib olmaq üçün aralarındakı əlaqəni açıq şəkildə qeyd etməliyik.

CREATE TABLE EMPLOYEES
(EMPLOYEE_ID NUMBER,
....
 CONSTRAINT "EMP_DEPT_FK" FOREIGN KEY ("DEPARTMENT_ID")
	  REFERENCES "HR"."DEPARTMENTS" ("DEPARTMENT_ID") ENABLE;

Cədvəlin özünü yaratarkən Xəritəçəkmə üsulunu belə yaradırıq. Bütün cədvəllər aşağıdakı kimi yaradıldıqdan sonra Xəritəçəkmə də yarada bilərik. Xahiş edirik unutmayın ki, bir ana cədvəllə əlaqə qurmaq üçün əvvəlcə ana cədvəl yaratmalıyıq.
ALTER TABLE EMPLOYEES 
 CONSTRAINT "EMP_DEPT_FK" FOREIGN KEY ("DEPARTMENT_ID")
	  REFERENCES "HR"."DEPARTMENTS" ("DEPARTMENT_ID") ENABLE;

Cədvəldə birdən çox əsas açar ola bilərmi?

Əsas düymələr cədvəldəki hər bir qeydin unikal şəkildə müəyyənləşdirilməsində istifadə olunan sütunun əsas nöqtəsidir. Bir çox əsas açarımız varsa, onları fərdi qeyd seçmək üçün mənbənin əsas nöqtəsi kimi izah etməyin mənası yoxdur. Cədvəldə hər bir qeydin unikal şəkildə müəyyənləşdirilməsi üçün istifadə edilə bilən birdən çox fərdi sütun ola bilər. Ancaq hər bir qeydin müəyyənləşdirilməsi üçün onlardan birini əsas açar olaraq seçməliyik. Cədvəldə yalnız bir əsas açar ola bilər. Əsas düymənin bir sütunu və ya birdən çox sütunu ola bilər.

Məsələn, EMPLOYEE_ID, EMAIL və PHONE_NUMBER hər bir qeydləri özünəməxsus şəkildə müəyyən etmək hüququna malikdir. Ancaq hamısını əsas açar halına gətirə bilmərik. Hər ikisini də əsas açar sütunu olaraq seçməliyik. Beləliklə EMPLOYEE_ID-i EMPLOYEES cədvəlinin əsas açarı olaraq seçdik.

Cədvəldə birdən çox unikal açar ola bilərmi?

Bəli, cədvəldə birdən çox unikal açar sütun ola bilər. Yəni bir cədvəldə hər bir qeydi unikal şəkildə müəyyənləşdirə bilən birdən çox sütun ola bilər. Məsələn, EMPLOYEE_ID, EMAIL və PHONE_NUMBER, EMPLOYEES cədvəlinin unikal açar sütunlarıdır.

Cədvəldə çoxlu Xarici Açar ola bilərmi?

Bəli, cədvəldə birdən çox xarici açar ola bilər. Bu xarici düymələr eyni masadan və ya fərqli masalardan ola bilər. Başqa sözlə, cədvəldə bir və ya daha çox valideyn ola bilər.

İŞÇİLƏR cədvəlini nəzərdən keçirin. Yuxarıda müzakirə etdiyimiz kimi, hər bir işçi bir şöbəyə aiddir. Beləliklə, onun şöbəsi olaraq bir valideyn var. Hər bir işçi heç bir şöbədə ayrı-ayrılıqda işləyə bilməz (çox nadirdir). Ən azı bir meneceri olacaq. Ancaq menecer həm də işçidir. Beləliklə, menecerin EMPLOYEE_ID-i MANPLER_ID olaraq EMPLOYEES cədvəlinə daxil etməliyik. Yəni İŞÇİLƏR cədvəlində öz cədvəlində xarici açar var. Başqa sözlə, İŞÇİLƏR cədvəlində birdən çox xarici açar var.

Xarici Açar Qeyri-İbtidai Açara istinad edə bilərmi?

Bəli, istinad etdiyi sütun və ya sütunların ana cədvəldə bənzərsiz bir açar olması şərtiylə xarici bir açar ana cədvəlinin birincil olmayan düyməsinə istinad edə bilər.

Xarici açarın istinad etdiyi sütunun unikal bir açar olmadığını düşünək. Sonra ana cədvəldə həmin sütun üçün təkrarlanan dəyərlər olacaqdır. Beləliklə, uşaq cədvəli ilə xəritədə göstərdiyimiz zaman aralarındakı düzgün əlaqəni tapa bilməyəcəyik. Tutaq ki, EMPLOYEES cədvəli BÖLMƏLƏR cədvəlindəki unikal açar sütun olmayan NUMBER_OF_EMP-yə istinad edir. Sonra bu xarici açara istinad edən hər bir işçi hansı şöbəyə aid olduğunu təxmin edə bilməz. DEPARTMENT_NAME-un DEPARTMENTS cədvəlində unikal olduğunu təsəvvür edin (lakin əsas açar deyil). Bu sütunda xarici açarımız varsa, onun şöbəsini müəyyənləşdirməyəcəyik.

Natural Key nədir?

Təbii açar sütun, cədvəldəki digər sütunlarla yanaşı, bu sütunlarla məntiqi əlaqəsi olan cədvəldəki sütunların birləşməsidir. Bundan əlavə, bu sütunlar cədvəlin həqiqi sütunlarıdır və onu açar halına gətirmək məqsədi ilə yaradılmamışdır.

İŞÇİLƏR cədvəlini nəzərdən keçirin. FIRST_NAME, LAST_NAME və onun EMAIL birləşməsini açar hesab etdiyimizi düşünək. Yəni bu üç sütun birlikdə hər satırı təyin etmək üçün istifadə olunur. Burada bütün bu sütunlar realdır - yəni real və mövcud məlumatlara malikdir və hər biri bir-biri ilə əlaqəlidir. yəni; FIRST_NAME, LAST_NAME ilə əlaqəlidir və hər ikisi də EMAIL id ilə əlaqəlidir. Buna görə bu üç sütun təbii sütunlardır və məntiqi baxımdan əlaqəlidir. Sütunların bu cür birləşməsi açar kimi istifadə edildikdə, onlara Natural açarı deyilir.

ƏMƏKDAŞLARI cədvəlindəki İŞLƏNİB kodunu departamenti və ya şirkəti tərəfindən verilmədiyini düşünün və cədvəlin hər qeydini təyin etmək üçün bu sütunu yaratdıq. 100-dən dəyərləri daxil edirik və hər yeni işçi üçün 1 artırılır. Hər sətri təyin etmək üçün bu əsas sütun kimi istifadə olunsa da, real həyatda mövcud olanlar deyil. Buna görə təbii bir açar sütun deyil.

Biznes açarı nədir?

Biznes açarı Natural açarla eynidir. Cədvəldəki açar kimi istifadə olunan tək və ya sütun birləşməsidir. Ancaq bu sütunda real həyat məlumatları olmalıdır. Əsas dəyərlər kimi təbii nömrələr və ya bəzi qarmaqarışıq sətirlər kimi bir istifadəçi tərəfindən yaradılan məlumatlar ola bilməz. Buna Domain Key kimi də deyilir.

Məsələn, DEPARTMENT_NAME, təbii dəyəri ehtiva edir və cədvəldəki hər şöbəni təyin etmək üçün istifadə edilə bilər. Heç bir kukla nömrəsi yoxdur.

Surroqat açar nədir? Niyə istifadə edirik?

Bunlar cədvəldəki hər sıra üçün sistem tərəfindən avtomatik olaraq yaradılan xüsusi düymələrdir. Sistemə daxildir, ancaq əsas açar kimi davranır. Sistem tərəfindən hər sətrə təyin edilmiş və istifadəçi tərəfindən görünməyən bir rəqəmdir.

Bu açar sistem mövcud olana qədər sistemdə olacaqdır. Birincil və ya unikal açar sütunlarda davamlı dəyişikliklər baş verdikdə və ya masada bir dəyişiklik tələbi olduqda faydalıdır və onu istifadə edən tətbiqlər ayrılmamalıdır.

Namizəd və orta açar nədir?

Verilənlər bazası cədvəllərində birincil açar ola bilən, lakin birincil açar kimi seçilməyən hər hansı bir sütuna ikinci dərəcəli açar adlanır. Yəni bir cədvəl yaradıldıqda, hər bir qeydin unikal şəkildə təyin oluna biləcəyi birdən çox sütun olacaqdır. Birincil açar üçün uyğun olan bütün bu sütunlar bilinir namizəd açarları. Yəni bu sütunlar birincil açar olmaq üçün namizəddir. Ancaq bir cədvəldə yalnız bir əsas açar ola bilər. Birincil açar ola biləcək sütunların qalan hissəsi adlanır İkincil açar.

Əsas, namizəd və ikincil düymələr arasındakı fərqi anlamaq üçün bir nümunəni nəzərdən keçirək. Aşağıdakı İŞÇİ cədvəlini nəzərdən keçirin.

EMPLOYEE_ID, EMAIL və PHONE_NUMBER sütuna malikdir. Bu sütunlar hər bir işçi üçün unikal sütunlardır. Başqa sözlə, heç bir işçi və ya şəxs eyni işçi kimliyinə və ya telefon nömrəsinə və ya e-poçt kimliyinə sahib ola bilməz. Hər fərdin öz id, e-poçt və telefonları var. Beləliklə, bu sütunlardan birini cədvəlin əsas açarı hesab edə bilərik. Yəni bu üç sütunun hamısı birincil açar olmaq üçün namizəddir. Beləliklə, bu üç sütuna namizəd açar sütunları deyilir. Gündəlik praktikada ID-ni birincil açar kimi qəbul edirik, çünki simlər və ya uzun sütunlardan daha çox şəxsiyyət vəsiqələri ilə sütunları işlətmək və sorğu etmək asandır. Beləliklə, İŞÇİLƏR cədvəlində EMPLOYEE_ID-i əsas açar hesab edirik. Namizəd açar sütunlarının qalan hissəsi - EMAIL və PHONE_NUMBERS ikinci dərəcəli düymələr adlanır. Beləliklə:

  • Cədvəlin əsas açarı ola biləcək bütün sütunlara Namizəd Açarı - EMPLOYEE_ID, EMAIL və PHONE_NUMBER adlanır.
  • Cədvəlin hər bir sətrini / qeydini özünəməxsus şəkildə təyin edən sütuna Birincil açar - İŞÇİE_ID adlanır.
  • Birincil açar kimi qeyd olunmayan namizəd açar sütunlarına İkincil Açar adlanır - EMAIL və PHONE_NUMBER.
  • Bütün əsas açar və köməkçi açar sütunlar Namizəd açar sütunlardır. Ancaq namizəd açar sütunundan hər hansı biri əsas açar, namizəd açar sütununun qalan hissəsi ikinci dərəcəli sütundur.

Referans Dürüstlüyü nədir?

Referensial İnteqrasiya əlaqəli verilənlər bazası konsepsiyasıdır. Bir əlaqəli verilənlər bazası, içindəki cədvəllər arasındakı əlaqələr / eşlemelerden ibarətdir. Cədvəl arasındakı bu əlaqə referans bütövlüyündən istifadə edərək qurulur. Bu, düzgün məlumatları daxil etməyimizə kömək edəcək və səhv məlumatları cədvəllərdən silməyimizi dayandıracaq.

İŞÇİLƏR və ŞƏKİLLƏR cədvəlini nəzərdən keçirin. Burada BÖLMƏLƏR cədvəli şirkətdəki bütün şöbələri özündə cəmləşdirir. İŞÇİLƏR masasında şirkətin müxtəlif şöbələrində çalışan bütün işçilər var. Yəni hər bir işçi şöbənin hər hansı birinə uyğunlaşdırılmalıdır. Bu iki cədvəl arasında heç bir xəritə yaratmadığımızı düşünün. İndi bölməsi olmayan İŞÇİLƏR cədvəlinə bir işçi qeydini daxil etməyə çalışsaq, DB işçi qeydini daxil etməyimizə imkan verəcəkdir.

Başqa bir ssenaridə, hələ çalışdığımız bəzi şöbələri silmək istəyirik. İşçinin olduğu şöbəni silsək, etibarlı olmayan bəzi şöbələrə aid işçilərimiz olacaq.

Bu ssenarilərin hər ikisi verilənlər bazasında uyğunsuz məlumatlara səbəb olacaqdır. Sistemdəki bu cür uyğunsuzluqların qarşısını almaq üçün, İŞÇİLƏR cədvəlində xarici açar məhdudlaşdırma yaradaraq bu iki cədvəl arasında istinad bütövlüyünü təqdim edirik. İndi referans bütövlüyü yaratdıq, şöbəsi DEPARTMENT cədvəlində olmayan bir işçini daxil etməyə çalışsaq, qeyd yazmağımıza icazə verməyəcəkdir. Aşağıdakı kimi səhv mesajı göstərəcəkdir.

Tutaq ki, çalışdığı işçilərin olduğu bölmələrdən birini siləcəyik. Bundan əlavə şöbə məlumatlarını silməyimizə və aşağıdakı kimi səhv mesajı göstərməyimizə imkan verməyəcəkdir.

Bu şəkildə referans bütövlüyü verilənlər bazasındakı tutarlılığı və bütövlüyü qorumağımıza imkan verir.

Crack Sistemi Dizayn Müsahibələri
Translate »