Salam Dostlar.

Keçən dərsimizdə Transact-SQL sorğu dilinin CREATE TABLE operatorunun sintaksisi ilə tanış olduq və kod nümunələrini oxuduq. Kodlardan istifadə edərək yeni cədvəllər yaratdıq. Dərsimizin sonunda bəzi tapşırıqlar verilmişdi. Həmin tapşırıqların cavablarını nəzərinizə çatdırıram:

Tapşırıq 1. Yeni test_baza adlı verilənlər bazası yaradın.

Cavab:

CREATE DATABASE test_baza

Tapşırıq 2. Yuxarıda göstərilən qaydada Books Online for SQL Server 2014 kod nümunəsini açın və yaratdığınız bazada iki cədvəl yaradın: test_table1 (Name, Surname, Lastname sütunları ilə) və test_table2 (Company,  Department sütunları ilə).

Cavab:

USE test_baza
GO

CREATE TABLE dbo.test_table1
(
 Name nvarchar(50) NULL,
 Surname nvarchar(50) NULL,
 LastName nvarchar(50) NULL
)

CREATE TABLE dbo.test_table2
(
 Company nvarchar(25) NULL,
 Department nvarchar(50) NULL
)

Nəzəri dərsələrimizdən bildiyiniz kimi, münasibətli verilənlər modelində (Relational Database Model) formal olaraq sütunlar “atributlar”, sətirlər isə “kortejlər” adlandırılır. Münasibət – müəyyən bir sxemə (cədvəlin başlığına) uyğun olan kortejlərin (cədvəlin sətirlərinin) çoxluğudur. Belə olan münasibətlər adi cədvəl şəklində təsvir etmək asandir, lakin həmin münasibətlər riyaziyyatda olan çoxluqlar kimi təsvir olunduğu üçün adi cədvəllərdən fərqlənirlər. K.C. Deytin təyininə görə münasibətli verilənlər bazalarının cədvəllərinin adı cədvəllərdən aşağıdakı fərqləri vardır:

1. Yuxarıdan-aşağı sətirlərin nizamlılığı yoxdur. Biz deyə bilmərik ki, hər hansı bir sətir mütləq digər sətirdən sonra gəlməlidir. Adi cədvəldə isə ardıcıllıq mütləqdir.
2. Soldan-sağa sütunların nizamlılığı yoxdur. Biz deyə bilmərik ki, hər hansı bir sütun mütləq digər sütundan sonra gəlməlidir. Münasibətli bazada sütunların ardıcıllığı vacib deyil. Adi cədvəldə isə sütunların sırası gözlənilməlidir.
3. Təkrarlanan sətirlər yoxdur. Adi cədvəldə isə istənilən miqdarda təkrarlanan sətirlər ola bilər.
4. Adi cədvəlin xanasında vergüllə ayrılan istənilən qiymətlər yaza bilərik. Münasibətli cədvəldə isə buna yol verilmir.

Bugünkü dərsimizdə biz üçüncü bənddə olan fərq barəsində danışacağıq: münasibətli verilənlər bazasında təkrarlanan sətirlər olmamalıdır. Bu qayda verilənlər bazasının bütövlülüyünün təminatıdır. Yəni cədvəldə iki və daha çox eyni sətir olduqda, hər hansı bir dəyişiklik zamanı (İNSERT, UPDATE, DELETE) Verilənlər Bazalarının İdarəetmə Sistemi (gələcəkdə mətndə VBİS) eyni sətirlərdən hansının dəyişəcəyi barədə qərar qəbul edə bilməyəcək və beləliklə də verilənlər bazasının bütövlülüyü pozulacaq. Bunun üçün verilənlər bazasında açarlar vasitəsilə məhdudiyyət təyin olunmuşdur. Həmin açarlar vasitəsilə bazada olan hər bir dəyişiklik süzgəcdən keçirilir, kontrol edilir və qaydalar pozulduğu halda həmin dəyişiklərin icrası baş tutmur.  

ANSİ SQL standartında açarlar vasitəsilə məhdudiyyətin dörd növü təsvir olunub: PRIMARY KEY, UNIQUE, CHECK və FOREIGN KEY. Ayrı-ayrı VBİS-lərdə bu siyahı daha geniş ola bilər, məsələn: Microsoft SQL Serverdə əlavə olaraq DEFAULT açar məhdudiyyəti də vardır.

Keçən dərslərimizdə kadrların uçotu aparılacaq verilənlər bazası sxemi üzərində çalışdıq. Həmin verilənlər bazasının quruluşunu bir daha yadımıza salaq:

Fərz edək ki, ilkin mərhələdə bazamız üç cədvəldən ibarətdir: “Department”, “Personnel” və “Phone”:

UNIQUE CONSTRAİNT

Diqqət etsək görərik ki, Personnel cədvəlində əməkdaşların adları və soyadları eyni ola bilər. Məsələn: Vüqar Məmmədov və Vüqar Orucov adlı əməkdaşların adları eynidir. Tofiq Məmmədov və Vüqar Məmmədov adlı əməkdaşların isə soyadları eynidir. Həmçinin eyni adı və soyadı olan bir neçə əməkdaş ola bilər. Məsələn: Vüqar Məmmədov adı ölkəmizdə geniş yayıldığını nəzərə alsaq bir neçə əməkdaşın belə ad və soyadla cədvəlimizdə olması da mümkündür. Belə olan halda cədvəl sətirlərinin unikallığını və ya təkrarolunmazlığını necə təmin edə bilərik? Unikal sözü İngilis dilində yazılışı “UNIQUE” şəklindədir. Bu sözdən istifadə edərək SQL-də cədvəl sətirləri üçün unikal açar təyin olunur. Məsələn: biz istəyirik ki, FirstName sütununda olan adlar unikal olsun, yəni Vüqar adı təkrarlanmasın.  Həmin sütuna unikal açar məhdudiyyətini təyin etməklə bunu təmin edə bilərik. Bu zaman biz Vüqar adını bir dəfədən artıq cədvəlimizə əlavə etmək istəsək bunu edə bilməyəcəyik. Eynisini LastName sütununda da edə bilərik, və beləliklə ikinci dəfə Məmmədov soyadını əlavə etmək istəsək bunu edə bilməyəcəyik. Fərz edək ki, Vüqar Məmmədov ad və soyadının təkrar olunmasını istəmirik. Bunun üçün iki sütun birləşməsinə FirstName/LastName unikal açar məhdudiyyəti təyin edə bilərik. Bu zaman cədvəlimizə ikinci dəfə Vüqar Məmmədov ad və soyad birləşməsini əlavə etmək istəsək bunu edə bilməyəcəyik.

ANSİ SQL standartına uyğun olaraq açarlar vasitəsilə məhdudiyyət cədvəl sütunlarına ayrı-ayrılıqda və tam cədvələ təyin etmək olar. Açarlar vasitəsilə məhdudiyyət cədvəllərin CREATE TABLE əmri ilə yaradılması zamanı və cədvəllərdə ALTER TABLE əmri ilə dəyişiklik etməklə təyin olunur. Açarlar vasitəsilə məhdudiyyətin sintaksisinə baxaq:

CONSTRAINT [məhdudiyyətin_adı] məhdudiyyətin_tipi 
[(sütun[, ...])]

Daha aydın olması üçün nümunələr üzərində göstərək.

Cədvəlin yaradılması (CREATE TABLE) zamanı açar məhdudiyyətinin təyin olunması.

Cədvəl sütunlarına məhdudiyyətinin təyin olunması:

USE kadrlar
GO

CREATE TABLE dbo.Personnel
(
 Per_ID int NOT NULL,
 FirstName nvarchar(50) NULL UNIQUE,
 LastName nvarchar(50) NULL UNIQUE,
 Address nvarchar(100) NULL,
 Dep_ID int NULL
)

Nümunədə keçən dərsimizdə yaratdığımız kadrlar verilənlər bazasından istifadə etdik. Əgər kadrlar bazasında cədvəllər artıq mövcuddursa, yəni keçən dərsimizdə onları artıq yaratmısınızsa, sorğunun əvvəlinə aşağıda göstərilən İF EXİST komandasını əlavə edin. Bu komanda vasitəsilə əgər cədvəl verilənlər bazasında artıq mövcuddursa silinəcək və daha sonra həmin cədvəli yenidən yarada bilərsiniz. Bu komanda Microsoft SQL Serverdə aşağıdakı şəkildə istifadə olunur:

IF OBJECT_ID('dbo.Personnel', 'U') IS NOT NULL
DROP TABLE dbo.Personnel

Lakin mən ANSİ SQL standartında olan komandanı daha çox istifadə edirəm, çünki bu komanda Microsoft SQL Serverlə yanaşı, digər platformalar tərəfindən də dəstəklənir:

IF EXISTS (SELECT 1 from sys.objects WHERE name = 'Personnel'and TYPE = 'u')
DROP TABLE Personnel

Deməli, sorğumuzu aşağıdakı şəkildə yaza bilərik:

USE kadrlar
GO

IF EXISTS (SELECT 1 from sys.objects WHERE name = 'Personnel'and TYPE = 'u')
DROP TABLE Personnel

CREATE TABLE dbo.Personnel
(
 Per_ID int NOT NULL,
 FirstName nvarchar(50) NULL UNIQUE,
 LastName nvarchar(50) NULL UNIQUE,
 Address nvarchar(100) NULL,
 Dep_ID int NULL
)

Biz burada iki sütuna: FirstName və LastName unikal açar məhdudiyyəti qoyduq. Qeyd etmək lazımdır ki, məhdudiyyət hər iki sütuna ayrı-ayrılıqda verilib, yəni ad təkrarlana bilməz, həmçinin soyad da təkrarlana bilməz. Məsələn: biz bir neçə dəfə Vüqar adını, və bir neçə dəfə Məmmədov soyadını  cədvəlimizə əlavə edə bilmərik. Lakin deyə bilərik ki, əməkdaşlar ad və soyadla tanınır və buna görə də yaxşı olar ki, ad və soyad ayrı-ayrılıqda deyil cəm şəklində təkrarlanmasın, məsələn: Vüqar Məmmədov adı təkrarlanmasın. Bu qaydanı təmin etmək üçün məhdudiyyəti tam cədvələ təyin etmək lazımdır.

Məhdudiyyətinin tam cədvələ təyin olunması:

USE kadrlar
GO

IF EXISTS (SELECT 1 from sys.objects WHERE name = 'Personnel'and TYPE = 'u')
DROP TABLE Personnel

CREATE TABLE dbo.Personnel
(
 Per_ID int NOT NULL,
 FirstName nvarchar(50) NULL,
 LastName nvarchar(50) NULL,
 Address nvarchar(100) NULL,
 Dep_ID int NULL,
 CONSTRAINT UQ_Name_Surname UNIQUE (FirstName, LastName)
)

Məhdudiyyəti tam cədvələ təyin etmək üçün sorğunun sonunda göstərilən sətir əlavə olunur:

CONSTRAINT UQ_Name_Surname UNIQUE (FirstName, LastName)

Burada məhdudiyyətin adı və yumru mötərizədə cəm şəklində məhdudiyyət qoyulan sütunların adları qeyd olunub. Bu sətirdə CONSTRAINT UN_Name_Surname  sözlərini buraxmaq olar:

USE kadrlar
GO

IF EXISTS (SELECT 1 from sys.objects WHERE name = 'Personnel'and TYPE = 'u')
DROP TABLE Personnel

CREATE TABLE dbo.Personnel
(
 Per_ID int NOT NULL,
 FirstName nvarchar(50) NULL,
 LastName nvarchar(50) NULL,
 Address nvarchar(100) NULL,
 Dep_ID int NULL,
 UNIQUE (FirstName, LastName)
)

Bu zaman VBİS özü həmin məhdudiyyətə qarışıq bir ad təyin edir, məsələn: məndə  sorğunu icra etdikdən sonra Microsoft SQL Server məhdudiyyət üçün UQ__Personne__2457AEF082C3B668 adını təyin etdi:

Gördüyünüz kimi ad uzun və mürəkkəbdir. Bu ad gələcəkdə sorğularda tez-tez istifadə oluna bilər. Qeyd etmək lazımdır ki, açar məhdudiyyətləri cədvəldə ayrı bir obyekt kimi saxlanılır. Buna görə də təcrübəyə əsasən məhdudiyyətə məntiqli ad qoyulmalıdır. Məsələn: yuxarıdakı sorğuda biz məhdudiyyətə UQ_Name_Surname adını təyin etdik:

CONSTRAINT UQ_Name_Surname UNIQUE (FirstName, LastName)

Bu addan aydındır ki, məhdudiyyət hansı sütunların kombinasiyasına qoyulub. Həmçinin məhdudiyyət ayrı-ayrı sütunlar səviyyəsində qoyularsa bu zaman da biz məntiqli bir ad qoya bilərik, məsələn:

USE kadrlar
GO

IF EXISTS (SELECT 1 from sys.objects WHERE name = 'Personnel'and TYPE = 'u')
DROP TABLE Personnel

CREATE TABLE dbo.Personnel
(
 Per_ID int NOT NULL,
 FirstName nvarchar(50) NULL CONSTRAINT UQ_Name UNIQUE,
 LastName nvarchar(50) NULL,
 Address nvarchar(100) NULL,
 Dep_ID int NULL
)

Burada sadəcə bir neçə məqama diqqət etmək lazımdır:

1. Məhdudiyyətə ad qoyulursa adın önündə CONSTRAİNT operatoru mütləq yazılmalıdır.
2. Bir cədvəldə bir neçə UNİQUE unikal məhdudiyyəti təyin etmək olar.
3. UNİQUE unikal məhdudiyyət qoyulan sütunda NULL qiyməti ola bilər. Lakin sütunun cəmi bir sətrində NULL qiyməti ola bilər. Burada NULL “sıfır” mənasında deyil “heç bir qiyməti olmayan” mənasındadır.

PRİMARY KEY

Unikal açar məhdudiyyətinin digər bir növüdür. Yuxarıdakı cədvəllər sxeminə diqqət etsək görərik ki, ad və soyadlar tez-tez təkrarlana bilər, çünki eyni adda və soyadda, həmçinin ad və soyad kombinasiyasında bir neçə əməkdaş ola bilər. Bu əslində məntiqlidir, çünki elə adlar və soyadlar var ki, ölkəmizdə geniş yayılıb. Həmçinin yuxarıda qeyd etdik ki, Unikal (UNİQUE)  məhdudiyyət qoyulan sütunda NULL qiyməti ola bilər. Məsələn: hər hansı bir əməkdaşın soyadı olmaya bilər. Verilənlər bazasının qurulması zamanı cədvəlin bütövlülüyünü təmin etmək üçün sətirlərin unikallığını təmin edən ən optimal bir sütun seçilir. Bu unikal sütun PRİMARY KEY adlandırılır.  Həmin sütun mövcud olan sütunlardan seçilə bilər və buna “natural” açar deyilir. Məsələn: yuxarıdakı sxemə diqqət yetirsək, görərik ki, Address sütunu belə açar üçün real namizəddir, çünki deyə bilərik ki, bir ünvanda iki və daha çox əməkdaş yaşaya bilməz. Lakin həmin sütunda olan yazılar, məsələn: şəhər, ev, mənzil və s. sətir tipindədir və mürəkkəbdir, həmçinin nəzərə alsaq ki, açar məhdudiyyəti ilə biz gələcəkdə tez-tez rastlaşacayıq, bu seçim o qədər də rahat deyil. Buna görə də verilənlər bazasının layihəsi ilə məşğul olan mütəxəssislər daha rahat və məntiqli bir seçim edirlər. Bunun üçün mövcud olan sütunlara ədədlər tipində olan daha bir sütun əlavə edirlər. Buna “Surrogate” (İng.- süni) açar deyilir. Yuxarıda göstərilən sxemdə Per_İD sütununu görürük. Həmin sütun cədvəl sətirlərinin unikallığını təmin etmək üçün yaradılıb. Həmçinin belə sütunlara məntiqli bir ad qoyulması məsləhət olunur. Məsələn: Per_İD adından aydındır ki, Personnel cədvəlinin (Per) identifikasiyası (İD) üçün yaradılmış bir sütundur. Belə sütunlar təcrübəyə əsasən tam ədədlər tipində olması məsləhətdır. PRİMARY KEY məhdudiyyətinin unikal açarlar (UNİQUE)  məhdudiyyətindən aşağıdakı fərqləri mövcuddur:

1. PRİMARY KEY məhdudiyyəti qoyulan sütunda NULL qiyməti ola bilməz. Yəni belə sütunun bütün sətirlərində qiymət mütləq olmalıdır.
2. Cədvəldə yalnız bir PRİMARY KEY məhdudiyyəti təyin oluna bilər.

PRİMARY KEY açar məhdudiyyətini cədvəl yaradılan zaman ayrı-ayrı sütunlar və tam cədvəl səviyyəsində təyin etmək olar. PRİMARY KEY məhdudiyyəti cədvəl yaradılarkən bir sütuna qoyulursa bu sütun qarşısında (sütun səviyyəsində), iki sütun birləşməsinə qoyulursa, sonuncu sütunun izahından sonra cədvəl səviyyəsində təyin olunur.  Həmçinin PRİMARY KEY açar məhdudiyyətini cədvəldə ALTER TABLE əmri ilə dəyişiklik etməklə təyin etmək olar.

PRİMARY KEY açar məhdudiyyətinin sintaksisinə aşağıdakı nümunə üzərində baxaq:

USE kadrlar
GO

IF EXISTS (SELECT 1 from sys.objects WHERE name = 'Personnel'and TYPE = 'u')
DROP TABLE Personnel

CREATE TABLE dbo.Personnel
(
 Per_ID int NOT NULL PRIMARY KEY,
 FirstName nvarchar(50) NULL,
 LastName nvarchar(50) NULL,
 Address nvarchar(100) NULL,
 Dep_ID int NULL
)

Burada biz Per_İD sütununa PRİMARY KEY açar məhdudiyyətini təyin etdik. Sorğu icra olunduqda VBİS özü həmin məhdudiyyətə qarışıq bir ad təyin edir, məsələn: məndə sorğunu icra etdikdən sonra Microsoft SQL Server məhdudiyyət üçün PK__Personne__2705F9601CBF9CA9 adını təyin etdi:

Gördüyünüz kimi ad uzun və mürəkkəbdir. Nəzərə alsaq ki, bu ad gələcəkdə digər  cədvəllər arasında əlaqə yaradılan zaman istifadə oluna bilər məhdudiyyətə məntiqli adın qoyulması məsləhətdir. Məsələn:

USE kadrlar
GO

IF EXISTS (SELECT 1 from sys.objects WHERE name = 'Personnel'and TYPE = 'u')
DROP TABLE Personnel

CREATE TABLE dbo.Personnel
(
 Per_ID int NOT NULL CONSTRAINT PK_Personnel PRIMARY KEY,
 FirstName nvarchar(50) NULL,
 LastName nvarchar(50) NULL,
 Address nvarchar(100) NULL,
 Dep_ID int NULL
)

Burada PK_Personnel adından aydındır ki, bu açar Personnel cədvəlinin PRİMARY KEY açar məhdudiyyətidir.

Fərz edək ki, Per_İD sütunumuz yoxdur və biz istəyirik ki ad/soyad kombinasiyası təkrarlanmnasın və qiymətləri mütləq olsun, yəni təyin olunmamış ad və soyad olmasın. Bu zaman qərara alırıq ki, həmin sütunlar yığımı və ya kombinasiyası unikal olmalıdır və cədvəlin PRİMARY KEY məhdudiyyəti olmalıdır. Bunu həyata keçirmək üçün cədvəlin yaradılması sorğusunun sonuna aşağıdakı sətri əlavə etməliyik:

CONSTRAINT PK_Personnel PRIMARY KEY (FirstName, LastName)

Sorğumuz aşağıdakı şəkildə olacaq:

USE kadrlar
GO

IF EXISTS (SELECT 1 from sys.objects WHERE name = 'Personnel'and TYPE = 'u')
DROP TABLE Personnel

CREATE TABLE dbo.Personnel
(
 Per_ID int NOT NULL,
 FirstName nvarchar(50) NOT NULL,
 LastName nvarchar(50) NOT NULL,
 Address nvarchar(100) NULL,
 Dep_ID int NULL,
 CONSTRAINT PK_Personnel PRIMARY KEY (FirstName, LastName)
)

Göründüyü kimi biz bu sorğuda bəzi qaydaları dəyişdik: FirstName və LastName sonunda NOT NULL komandasını əlavə etdik. Bununla biz təminat yaradırıq ki, həmin sütunların qiymətsiz (boş) sətirləri olmayacaq, yəni mütləq şəkildə ad və soyad mövcud olacaq. Əslində bu qaydanı PRİMARY KEY məhdudiyyəti tələb edir, çünki PRİMARY KEY məhdudiyyəti qoyulan sütunda NULL qiyməti ola bilməz. Yəni belə sütunun bütün sətirlərində qiymət mütləq olmalıdır:

Qeyd etmək lazımdır ki, belə olan halda ad təkrarlana bilər, həmçinin soyad da təkrarlana bilər, lakin ad/soyad birləşməsi təkrarlana bilməz. Məsələn: bir neçə Vüqar adı ola bilər və bir neçə Məmmədov soyadı ola bilər , lakin Vüqar Məmmədov ad birləşməsi təkrarlana bilməz. Göstərdiyim bu nümunə düzgün və optimal seçim deyil, çünki təcrübəyə əsasən PRİMARY KEY təyin olunanda tək sütunlu və tam ədəd tipli sütunlar seçilir. Mürəkkəb  PRİMARY KEY açar məhdudiyyəti isə nadir hallarda istifadə olunur.

Cədvəllərin yaradılması prosesində müəyyən hazırlıqlar aparılır. Məsələn: cədvəlin sxemi çəkilir və cədvəllər arasında münasibətlər qurulur. Cədvəllərin sayı azdırsa və açarların yeri dəqiq təyin olunubsa açar məhdudiyyətlərini cədvəllərin yaradılması zamanı təyin etmək olar. Bu üsulun sintaksisi yuxarıda izah olundu. Lakin təcrübəyə əsasən ilk öncə cədvəllər yaradılır və daha sonra açar məhdudiyyətləri təyin olunur. Bu üsul cədvəllərdə dəyişiklik etməklə (ALTER TABLE) həyata keçirilir. Keçən dərsimizdə kadrlar verilənlər bazasında üç cədvəl yaratdıq: Department, Personnel və Phone. İndi isə həmin cədvəllərdə dəyişıklik etməklə açar məhdudiyyəti təyin edək:

UNIQUE CONSTRAINT

USE kadrlar;
GO

ALTER TABLE dbo.Personnel
 ADD CONSTRAINT UQ_Name UNIQUE (FirstName);
GO

PRİMARY KEY CONSTRAINT

USE kadrlar;
GO

ALTER TABLE dbo.Personnel
 ADD CONSTRAINT PK_Personnel PRIMARY KEY (Per_ID);
GO

Göründüyünüz kimi sorğu çox sadədir: birinci sorğuda UQ_Name adlı unikal açar təyin etdik,  ikinci sorğuda isə PK_Personnel adlı PRİMARY KEY əlavə etdik.

Beləliklə bugünkü dərsimizi yekunlaşdıraq və qısa məcmusunu təyin edək:

1. ANSİ SQL standartında açarlar vasitəsilə məhdudiyyətin dörd növü təsvir olunub: PRIMARY KEY, UNIQUE, CHECK və FOREIGN KEY. Ayrı-ayrı VBİS-lərdə bu siyahı daha geniş ola bilər, məsələn: Microsoft SQL Serverdə əlavə olaraq DEFAULT açar məhdudiyyəti də vardır.
2. ANSİ SQL standartına uyğun olaraq açarlar vasitəsilə məhdudiyyət cədvəl sütunlarına ayrı-ayrılıqda və tam cədvələ təyin etmək olar.
3. Açarlar vasitəsilə məhdudiyyət cədvəllərin CREATE TABLE əmri ilə yaradılması zamanı və cədvəllərdə ALTER TABLE əmri ilə dəyişiklik etməklə təyin olunur.
4. Bir cədvəldə bir neçə UNİQUE unikal məhdudiyyəti təyin oluna olar.
5. Cədvəldə yalnız bir PRİMARY KEY məhdudiyyəti təyin oluna bilər.
6. UNİQUE unikal məhdudiyyət qoyulan sütunda NULL qiyməti ola bilər. Lakin sütunun cəmi bir sətrində NULL qiyməti ola bilər. Burada NULL “sıfır” mənasında deyil “heç bir qiyməti olmayan” mənasındadır.
7. PRİMARY KEY məhdudiyyəti qoyulan sütunda NULL qiyməti ola bilməz. Yəni belə sütunun bütün sətirlərində qiymət mütləq olmalıdır.
8. Məhdudiyyətlərə məntiqli və anlaşılan adın qoyulması məsləhətdir.
9. Məhdudiyyətə ad qoyulursa adın önündə CONSTRAİNT operatoru mütləq yazılmalıdır.

Yuxarıda göstərilən SQL kod nümunələrinin əksəriyyəti həm Microsoft SQL Server, həm də Oracle Database tərəfindən dəstəklənir və siz onları T-SQL və PL/SQL  məşğələlərində istifadə edə bilərsiniz. Növbəti dərsimizdə FOREİGN KEY, CHECK və DEFAULT məhdudiyyətləri barədə danışacağıq və yazılış sintaksisi ilə tanış olacağıq

Tapşırıqlar:

Yuxarıda göstərilən verilənlər bazası sxeminə uyğun olaraq Department və Phone cədvəllərinin PRİMARY KEY açar məhdudiyyətlərini təyin edin.

Növbəti məqalələrdə görüşənədək.

Diqqətinizə görə təşəkkür edirəm.

Dərsliyin əvvəlki hissələrini aşağıdakı keçidlərdən tapa bilərsiniz:

Transact-SQL. CREATE TABLE operatoru. Cədvəllərin yaradılması

Books Online for SQL Server 2014 (BOL). T-SQL sintaksisinin oxunuş qaydası

Transact-SQL və CREATE DATABASE operatoru nümunələrlə