Verilənlər bazasının normallaşdırılması nədir (və qaydaları nə vaxt pozmaq olar)?
Verilənlər bazasının normallaşdırılması latın dilində səslənən qaydalarla — birinci normal forma, ikinci normal forma və s. — dolu akademik mövzu kimi tanınır, lakin onun əsasında duran ideya xoş təsir bağışlayacaq qədər praktikdir: verilənləri elə təşkil edin ki, eyni fakt heç vaxt iki yerdə saxlanılmasın, çünki bu baş verən andan həmin iki yer gec-tez bir-birinə zidd düşəcək.
Normallaşdırmanın həll etdiyi əsas problem
Hər bir sətirdə sifarişlə yanaşı müştərinin tam adını və e-poçt ünvanını birbaşa saxlayan cədvəl təsəvvür edin. Müştəri e-poçtunu yeniləsə, indi onun adı keçən bütün sifariş sətirlərini yeniləməlisiniz — və hətta birini buraxsanız, verilənləriniz səssizcə ziddiyyətli olur: eyni verilənlər bazasında iki fərqli «həqiqət» yaşayır. Normallaşdırma bunu müştəri məlumatlarını bir yerdə (müştərilər cədvəlində) saxlamaqla və onlara lazım olan hər yerdən ID vasitəsilə istinad etməklə həll edir.
Normal formalar — jarqonsuz
- Birinci normal forma: hər sütunda bir sahəyə sıxışdırılmış siyahı yox, bir dəyər saxlanılır. Vergüllə ayrılmış üç nömrənin yazıldığı «phone_numbers» sütunu bu qaydanı pozur.
- İkinci normal forma: hər qeyri-açar sütun ilkin açarın bir hissəsindən yox, tamamından asılıdır — əsasən kompozit açarlı cədvəllər üçün aktualdır.
- Üçüncü normal forma: qeyri-açar sütunlar bir-birindən deyil, yalnız açardan asılıdır. Müştərinin şəhərini poçt indeksindən müəyyən etmək mümkündürsə, hər ikisini birbaşa saxlamaq onların gec-tez bir-birinə zidd düşməsinə yol açır.
Praktikada yaxşı layihələndirilmiş sistemlərin əksəriyyəti üçüncü normal formanı hədəfləyir və orada dayanır. Bundan o yanası əsasən dərsliklərdə mövcuddur, canlı mühitdəki real sxemlərdə yox.
Normallaşdırma nə verir
Təsadüfən sinxronluğunu itirə biləcək təkrarlanan faktlar olmadan ardıcıl verilənlər, eyni dəyərləri sətirlər boyu təkrarlamadığınız üçün daha az yaddaş sərfi və daha asan yeniləmələr — faktı bir yerdə dəyişin və ona edilən hər istinad dəyişikliyi avtomatik əks etdirsin.
Ciddi normallaşdırma nə vaxt baha başa gəlməyə başlayır
Bunun bədəli sorğuların mürəkkəbliyidir. Çoxlu kiçik cədvələ paylanmış yüksək dərəcədə normallaşdırılmış verilənlər çox vaxt sadə bir suala cavab vermək üçün belə altı cədvəli birləşdirmək deməkdir və hər birləşmənin (join) real performans bədəli var. Oxuma əməliyyatlarının üstünlük təşkil etdiyi sistemlərdə — hesabat panellərində, analitikada, yazmaqdan qat-qat tez-tez sorğu göndərdiyiniz hər yerdə — bu bədəl həqiqətən əhəmiyyətli ola bilər.
Məhz burada qəsdən denormallaşdırma meydana çıxır: daha sürətli oxuma müqabilində baha başa gələn birləşmələrdən qaçmaq üçün bəzi verilənləri bilərəkdən təkrarlamaq. Bu, dizayn qüsuru deyil, qanuni və geniş yayılmış strategiyadır — şərtlə ki, təsadüf deyil, şüurlu kompromis olsun. Bir çox real sistem əsas tranzaksiya verilənlərini normallaşdırır, sonra isə xüsusi olaraq hesabatlar və ya idarəetmə panelləri üçün oxumaya optimallaşdırılmış denormallaşdırılmış nüsxə saxlayır.
Praktik nəticə
Standart olaraq normallaşdırın — xüsusən də ardıcıllığın həqiqətən vacib olduğu verilənlər üçün: pul, anbar qalığı, heç vaxt səssizcə özü ilə ziddiyyət təşkil etməməli olan hər şey. Denormallaşdırmanı isə bilərəkdən və yalnız birləşmələrin yaratdığı real performans problemini həqiqətən ölçdüyünüz yerdə edin. Əvvəlcə ölçmədən bu kompromisi hər hansı istiqamətdə təxmin etmək sxemlərin ya səmərəli sorğulanması mümkünsüz olan, ya da incə şəkildə sinxronluğunu itirmiş verilənlərlə dolu hala düşməsinə səbəb olur. Konkret məhsulun real oxuma və yazma nümunələri üçün bu balansı düzgün qurmaq gördüyümüz fərdi proqram təminatı və infrastruktur işlərinin əsasını təşkil edir.