“Nəzəriyyəni bilmədən təcrübəyə arxalanan bir kəs

 sükansız və kompassız gəmini idarə edən sükançıya bənzəyir –

O, gəminin hara getdiyini bilmir”

Leonardo da Vinçi

Salam Dostlar

Bugünkü məqalədə mövzunun davamı olaraq münasibətli verilənlər bazaları barədə qisaca da olsa bir qədər məlumat verməyə çalışacağam. Əslində, çoxluqlar üzərində əməllər və bu əməllərin münasibətli verilənlər bazalarında istifadəsi barədə bəhs etməli idik. Lakin mövzunun olduqca geniş olduğunu və bəzən yanlış təsvir olunduğunu nəzərə alaraq, münasibətli modeli barədə daha ətraflı məlumat verməyə qərarına gəldim. Bu və sonrakı məqalələrdə “relational database” termini Ana dilimizdə olan tərcüməsi, yəni “münasibətli verilənlər bazası” şəklində veriləcək. Bu termin barədə öncəki məqalədə ümumi məlumat verməyə çalışdım. Sual yarana bilər ki, riyaziyyatın bir sahəsi olan çoxluqlar nəzəriyyəsi SQL (Structured Query Language – strukturlaşdırılmış sorğu dili) və verilənlər bazalarının öyrənməsi zamanı nəyə lazımdır? İstənilən sahə üzrə peşəkar mütəxəssis həmin sahənin özülünü təşkil edən əsas bilgilərə sahib olmalıdır. Müasir verilənlər bazalarının özülünü E.F. Kodd tərəfindən irəli sürülmüş verilənlərin münasibətli modeli təşkil edir. Bu modelinin əsasını isə riyaziyyatın iki sahəsini təşkil edir: çoxluqlar nəzəriyyəsi və predikatlar məntiqi və hesabı. Beləliklə, verilənlər bazası üzrə mütəxəssis onun özülü olan münasibətli modelini yaxşı bilməlidir. Əksər kurslarda və ədəbiyyatda bu modelə heç baxılmır və onun yerinə SQL və ya onun hər hansı bir dialekti təqdim olunur. Məsələ bundadır ki, münasibətli model heç bir konkret məhsula bağlı deyildir, onun əsas vəzifəsi prinsiplərin yaradılmasıdır. “Prinsip” sözünün “Azərbaycan dilinin izahlı lüğətində” mənası: hər hansı bir nəzəriyyənin, təlimin, əqidənin, dünyagörüşünün, elmin və s.-nin əsas müddəası, çıxış nöqtəsi. Prinsiplərin ən əhəmiyyətli xüsusiyyəti onların uzunömürlülüyüdür. Məhsullar və texnologiyalar (SQL dili həmçinin) hər zaman dəyişirlər, prinsiplər isə daimi sabit qalırlar. Tutaq ki, məsələn, siz Oracle VBİS-ini bilirsiniz; hətta fərz edək ki, siz Oracle üzrə böyük mütəxəssissiniz. Amma əgər sizin bilikləriniz yalnız Oracle-la məhdudlaşırsa, onlar DB2 və ya SQL Server mühitində yararsız ola bilər. Əgər siz əsas prinsipləri, başqa sözlə, münasibətli modeli bilirsinizsə, sizin bilikləriniz və bacarıqlarınız daşınandır – siz onları hər bir mühitdə tətbiq edə bilərsiniz və onlar heç vaxt köhnəlməyəcək.

Qeyd etmək lazımdır ki, E.F. Kodd verilənlər bazasının əsas strukturu kimi sütunları və sətirləri nizamsız olan “cədvəllərdən” istifadə etməyi təklif etdi. Nizamsız olan “cədvəllər” isə riyaziyyatın çoxluqlar nəzəriyyəsində olan “münasibətlərdir”. İlk növbədə adi cədvəl və “münasibət” arasındakı fərqlərə nəzər yetirək. Cədvəllərlə demək olar ki, hamı tanışdır. Cədvəllər verilənlər bazalarının əsas elementidir. Lakin keçən dərsimizdə deyildiyi kimi, bizim bildiyimiz cədvəllər – verilənlər bazalarının  mürəkkəb daxili strukturlarının yalnız xarici təsviridir. Daha dəqiq desək, cədvəl –  verilənlərə edilən sorğunun ekrana, printerə çıxarılan nəticəsidir. Əksər hallarda cədvəl axtarışın, seçimin, sorğunun nəticəsidir, yəni ekranda biz bütün verilənləri görmürük, yalnız rahat cədvəl formasında onların hansısa bir hissəsini görürük. Bəs münasibətli verilənlər bazasının “daxili” quruluşu necədir?

Cədvəl dedikdə ağlımıza gələn ilk şey Microsoft Excel cədvəli olur. Məsələn, adi bir şirkətin əməkdaşları barədə cədvəl misal gətirə bilərik:

Göründüyü kimi, hər bir əməkdaşın üç telefon nömrəsi var. Excel cədvəlində hər bir sətir  və sütun ardıcıl düzülüb və hərəsinin öz ardıcıl sıra nömrəsi var – bu Excel proqramının xüsusiyyətidir. Fərz edək ki, Məmməd Əliyev adında əməkdaş dördüncü nömrə aldı. Biz bu nömrəni cədvələ əlavə etmək üçün əlavə sütun yaratmalıyıq. Əlavə olaraq, Tofiq Məmmədovun bir neçə elektron poçt ünvanı var. Yenə də bunu cədvələ əlavə etmək üçün əlavə sətir yaratmalıyıq. İndi isə təsəvvür edək ki, əməkdaşların sayı yüzlərcə və ya minlərcədir.  Təbii ki, bu zaman həmin cədvəllə bizim işimiz çox çətinləşər. Əslində biz cədvəli çoxluqlar kimi təsəvvür etsək hər şey asanlaşar, məsələn əməkdaşlar (insanlar) çoxluğu, binalar (ünvanlar) çoxluğu, telefon nömrələri çoxluğu və elektron poçtları çoxluğu. Çoxluq de­dikdə hər han­sı əla­­mət­lə­rinə, xüsu­siy­yət­lərinə görə seçilmiş obyektlər  top­lusu, yığımı ba­­şa düşülür. Çoxluğu təşkil edən obyektlər onun ele­ment­ləri adlanırlar. Münasibətli verilənlər modelində çoxluq dedikdə eyni tipdə olan verilənlərin yığımı başa düşülür. Münasibətli verilənlər modelində 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. K.C. Deytin təyininə görə münasibətin sxemi – münasibətin başlığı, kortejlər çoxluğu isə münasibətin cismi adlanır. Münasibətin başlığı cədvəlin başlığına, münasibətin cismi isə cədvəldə olan bütün verilənlərin məcmusuna uyğundur. 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. Fərqlər isə bunlardır:

1. Yuxarıdan-aşağı sətirlərin nizamlılığı yoxdur. Biz deyə bilmərik ki, Tofiq Məmmədov mütləq Məmməd Əliyevdən sonra gəlməlidir və ya Vuqar Orucov Əli Məsimovdan əvvəl 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, ünvan sütunu mütləq soyad sütunundan 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. Sətrin və sütunun hər kəsişməsi uyğun olan “domendən” yalnız bir qiymətini özündə saxlayır. Yəni biz sətrin və sütunun kəsişməsində, məsələn,  elektron poçt ünvanlarını ardıcıl, yəni [email protected], [email protected] şəklində yaza bilmərik. Adi cədvəllərdə isə bu mümkündür. Adi cədvəlin xanasında vergüllə ayrılan istənilən qiymətlər yaza bilərik.  

Münasibətli verilənlər bazasının digər terminləri – “verilənlərin tipləri” və “domen”lərdir.  Münasibətli verilənlər bazasında saxlanılan verilənlərin bütün qiymətləri tipləşdirilmişdir, yəni hər saxlanılan qiymətin tipi məlumdur. Münasibətli verilənlər bazasında “verilənlərin tipləri” anlayışı proqramlaşdırma dillərində olan “verilənlərin tipləri” anlayışına tamamilə uyğundur. Münasibətli verilənlər bazasında “domen“lər anlayışı “verilənlərin tipləri” anlayışına sıx bağlıdır. Domen verilənlərin tiplərinin dəqiqləşdirilməsi kimi başa düşmək olar. Terminlərə biz hələ qayıdacağıq. Münasibətli bazanın əsas anlayışları bizim əməkdaşlarımızın cədvəli üzərində göstərə bilərik:   

İndi isə bizi qane etməyən cədvəlimizi bir qədər dəyişək. Başqa sözlə cədvəli çoxluqlara bölək, məsələn əməkdaşlar (insanlar) çoxluğu, binalar (ünvanlar) çoxluğu, telefon nömrələri çoxluğu və elektron poçtları çoxluğu. Yuxarıda deyildiyi kimi, belə çoxluqlar münasibətli bazada münasibətlər şəklində təsvir olunacaq. Münasibəti asan təsvir etmək üçün isə cədvəldən istifadə edəcəyik, yəni cədvəlimizi bir neçə kiçik cədvəllərə böləcəyik. Bizim cədvəlimizdə telefon nömrələri təkrarlanır, yəni bir əməkdaşın bir neçə telefon nömrəsi ola bilər, həmçinin dedik ki, hər bir işçinin bir neçə elektron poçt ünvanı ola bilər. Beləliklə, cədvəlimizi 3 hissəyə bölürük: “əməkdaşlar cədvəli”, “e-mail” cədvəli və “telefon nömrəsi” cədvəli:

Yuxarıda qeyd etdik ki, münasibətli verilənlər bazasında təkrarlanan sətirlər olmamalıdır, yəni biz eyni adda olan əməkdaşı cədvəldə iki dəfə ayrı-ayrı sətirlərdə qeyd edə bilmərik. Cədvəlin hər bir sətrini unikal yəni təkrarolunmaz etmək üçün alınan cədvəllərə yeni sütunlar əlavə etməliyik və həmin sütunlara unikal index və ya “açar” əlavə etməliyik. Burada münasibətli modelinin yeni terminiylə tanış olaq: “primary key” (PK) – “əsas açar” və “foreign key” (FK) – “xarici açar”. Deməli hər üç cədvəlimizə “primary key” (PK) – “əsas açar” əlavə etsək sətirlərin unikallığını təmin edirik.

Bəs bu ayrı-ayrı cədvəllər arasında münasibəti necə qurmalıyıq? Belə olan halda cədvəllərdən bilinmir ki, hansı telefon və e-mail hansı əməkdaşa məxsusdur. Burada isə bizim köməyimizə  “foreign key” (FK) – “xarici açar” gələcəkdir. Bunun üçün “E-mail” və “Telefon nömrələri” adlı cədvəllərimizə yeni sütun əlavə etməliyik. Foreign key (FK) – “xarici açar” əməkdaşlar adlı cədvəlin primary key (PK) – “əsas açar”ına istinad etsə hansı telefon və e-mailin hansı əməkdaşa məxsus olduğunu çox asanlıqla tapa bilərik. Həmçinin, əməkdaşların istənilən qədər telefon nömrəsini bazamız əlavə edə bilərik. Beləliklə, biz sonda aşağıdakı şəkildə göstərilən münasibətli verilənlər bazası yaratmış oluruq:   

Nəticədə, faktiki olaraq biz müəyyən tiplərə uyğun çoxluqlar və həmin çoxluqlar arasında münasibətləri görürük.

Bugünkü məqalənin sonuna gəlib çatdıq. Ümid edirəm ki, faydalı olacaq. 

Növbəti məqalədə mövzunun davamı olaraq çoxluqlar üzərində əməllər və bu əməllərin münasibətli verilənlər bazaları üçün əhəmiyyəti barədə məlumat verməyə çalışacağam.