Bu gün biz bir daha, amma indi daha detallı şəkildə, vacib bir mövzuya baxacağıq: normallaşdırmanın üstünlükləri və çatışmazlıqları. Beləliklə, bu konseptlərin real həyatda necə tətbiq olunduğunu daha yaxşı başa düşəcəksən. Hazır ol, başlayırıq!
Məlumatların artıq olmasının aradan qaldırılması
Cədvəldəki məlumatlar normallaşdırılmayıbsa, eyni informasiyanın müxtəlif sətrlərdə təkrarlandığını görə bilərsən. Məsələn, sifarişlər cədvəlində hər sifariş üçün müştərinin ünvanı təkrarlana bilər. Normallaşdırma belə təkrarlanmaları aradan qaldırır, ümumi məlumatları ayrıca cədvəllərə köçürür.
Nümunə:
-- Normallaşdırmadan əvvəl
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_name TEXT,
customer_address TEXT,
order_date DATE
);
-- Normallaşdırmadan sonra
CREATE TABLE customers (
customer_id SERIAL PRIMARY KEY,
customer_name TEXT,
customer_address TEXT
);
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY,
customer_id INT REFERENCES customers(customer_id),
order_date DATE
);Niyə bu vacibdir? Daha az təkrarlanan məlumat deməkdir ki, səhv ehtimalı da azdır. Əgər müştərinin ünvanı dəyişsə, sadəcə bir yerdə məlumatı yeniləmək kifayətdir.
Məlumatların bütövlüyünün təmin olunması
Məlumatlar məntiqi cədvəllərə bölünəndə, onların əlaqələrini idarə etmək asan olur. Xarici açarlardan istifadə avtomatik olaraq məlumatların bütövlüyünü qorumağa kömək edir. Məsələn, sifarişlər cədvəlində istinad olunan bir müştərini təsadüfən silə bilməzsən.
Nümunə:
-- Xarici açar təmin edir ki, müştəri silinəndə əlaqəli sifarişlər də silinsin
ALTER TABLE orders
ADD CONSTRAINT fk_customer FOREIGN KEY (customer_id)
REFERENCES customers(customer_id)
ON DELETE CASCADE;
Əmin ola bilərsən ki, məlumat bazasının strukturu "yetim" məlumatların yaranmasına imkan verməyəcək.
Yeniləmələrin sadələşdirilməsi
Baza normallaşdırılanda, yeniləmələr asan və daha az səhvlə olur. Müştəri nümunəsinə qayıdaq — əgər müştəri ünvanını dəyişirsə, sadəcə bir cədvəldə onun sətrini yeniləyirsən. Normallaşdırılmamış cədvəllərdə isə, bəzi sətrlərdə ünvanı yeniləməyi unuda bilərsən və nəticədə məlumatlar uyğunsuz olar.
Anomaliyaların minimallaşdırılması
Əlavə anomaliyaları: Normallaşdırılmamış cədvəldə elə vəziyyət ola bilər ki, artıq məlumat olmadan yeni sətir əlavə edə bilmirsən. Məsələn, müştərinin adı məlum olmayana qədər sifariş əlavə etmək mümkün deyil.
Yeniləmə anomaliyaları: Məlumatları yeniləyərkən səhvlər yarana bilər. Məsələn, bir sətrdə müştərinin adını dəyişirsən, amma başqa sətrdə köhnə ad qalır.
Silinmə anomaliyaları: Sətrin silinməsi vacib məlumatın itirilməsinə səbəb ola bilər. Məsələn, sifarişi siləndə, əgər bu məlumatlar bir cədvəldədirsə, müştərinin adı da silinir.
Məlumatların həcminin azaldılması
Normallaşdırma çox vaxt məlumat bazasının ölçüsünü azaldır, çünki təkrarlanan məlumatlar aradan qalxır. Bu, böyük həcmli informasiyanın saxlanması üçün vacibdir.
Normallaşdırmanın çatışmazlıqları
1. Məlumat bazasının strukturunun mürəkkəbliyi
Zaman keçdikcə normallaşdırma nəticəsində məlumat bazasının strukturu çox mürəkkəb ola bilər, minlərlə (!) əlaqəli cədvəldən ibarət olur. Belə hallarda əvvəllər bir cədvəldə olan məlumatı əldə etmək üçün çoxsaylı JOIN ilə mürəkkəb SQL-sorğuları yazmaq lazım gəlir.
Mürəkkəblik nümunəsi:
-- Məhsullar və kateqoriyalar üzrə detallarla sifariş məlumatını əldə etmək üçün sorğu
SELECT
o.order_id,
o.order_date,
c.customer_name,
p.product_name,
cat.category_name,
oi.quantity,
oi.unit_price
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
JOIN categories cat ON p.category_id = cat.category_id;
Cədvəllərin və əlaqələrin sayı artdıqca, sorğuların icra müddəti də xeyli arta bilər.
2. Tez-tez birləşdirmələrdə performansın azalması
Cədvəllərin tez-tez birləşdirilməsi (JOIN) resurs baxımından ağır ola bilər, xüsusilə cədvəllər böyükdürsə və indeks yoxdursa. Analitik sistemlərdə, milyonlarla sətrin emalı tələb olunan sorğularda, normallaşdırma performans baxımından ciddi problemlər yarada bilər.
3. Denormallaşdırma üçün əlavə əməliyyatlara ehtiyac
Əgər normallaşdırılmış məlumat bazası analitik məqsədlər üçün istifadə olunursa, analitik sorğuları sürətləndirmək üçün onu müvəqqəti denormallaşdırmaq lazım gəlir. Bu, məlumatların aqreqasiyası üçün VIEW və ya cədvəllərin yaradılmasını əhatə edə bilər.
Nümunə:
-- Analitika üçün denormallaşdırılmış görünüş
CREATE VIEW orders_with_customers AS
SELECT
o.order_id,
o.order_date,
c.customer_name,
c.customer_address
FROM
orders o
JOIN
customers c ON o.customer_id = c.customer_id;
4. Yüksək giriş baryeri
Yeni başlayanlar üçün normallaşdırma çətin görünə bilər. Bütün məlumatların bir cədvəldə olduğu əvəzinə, bir neçə cədvəllə işləmək və onların əlaqələrini başa düşmək lazımdır. Bu, xüsusilə komanda məlumat bazalarında yüksək səviyyədə təcrübəyə malik deyilsə, inkişafı ləngidə bilər.
5. Bəzən artıq məlumat faydalıdır
Real layihələrdə bəzən performansı artırmaq üçün artıq məlumatları saxlamaq daha sərfəlidir. Məsələn, əgər tətbiq tez-tez yalnız mürəkkəb birləşmə ilə əldə olunan məlumatlardan istifadə edirsə, onları bir cədvəldə saxlamaq daha yaxşıdır.
GO TO FULL VERSION