Məlumatların denormalizasiyası nümunələri və onun nəticələri

Normalizasiya bəzi problemləri həll edir, amma bəzən başqa problemlər yaradır, xüsusilə performans məsələsində. Bu gün biz səni qaranlıq (bəzən də işıqlı) sənətə — denormalizasiyaya aparacağıq. Bəli, sən normalizasiya qaydalarını poza bilərsən... amma ağılla!

Denormalizasiya — normalizasiyanın əks prosesidir. Əgər normalizasiya cədvəlləri ayrıca məntiqi obyektlərə bölürsə və artıq məlumatı minimuma endirirsə, denormalizasiya məlumatları yenidən birləşdirir ki, performans artsın. Denormalizasiya adətən yüksək yüklənmə və tez-tez mürəkkəb sorğular icra olunanda, çoxlu cədvəllərin join edilməsi sistemi ləngidəndə istifadə olunur.

Demək olar ki, denormalizasiya — məlumatların təmizliyi ilə sorğuların sürəti arasında kompromisdir.

Denormalizasiyanı nə vaxt istifadə etməli?

Hər bir alət kimi, denormalizasiyanın nə vaxt uyğun olduğunu bilmək vacibdir. O, aşağıdakı hallarda tətbiq olunur:

1. Tez-tez istifadə olunan sorğular yavaşlayır. Əgər sistemdə böyük yüklənmə varsa və eyni sorğular (məsələn, ümumi hesabatlar və aggregat-lar) tez-tez icra olunursa, çoxlu cədvəllərin join edilməsi xeyli vaxt aparır. Denormalizasiya belə join-lərin sayını azaldır.

2. Analitik tapşırıqlar və statistika. Analitik sistemlərdə (məsələn, BI — Business Intelligence) tez-tez böyük həcmdə məlumat analizi tələb olunur. Belə hallarda denormalizasiya "əvvəlcədən hazırlanmış" məlumatlar hesabına işləməni sürətləndirir.

3. Mürəkkəb sorğular. Əgər bir sorğunu icra etmək üçün beş, on və ya daha çox cədvəl join etmək lazımdırsa, bu, bazanın işini xeyli ləngidə bilər. Denormalizasiya sorğuların strukturunu sadələşdirir.

4. Join-lərin sayı artıq məntiqi keçib. Əgər sənin sorğunda 25 cədvəl JOIN ilə birləşirsə, bəlkə də yanaşmanı dəyişmək vaxtıdır.

Denormalizasiya nümunələri

Nümunə 1: Onlayn mağaza. Normalizə olunmuş onlayn mağaza bazasında belə cədvəllər ola bilər:

1. customers — müştərilər haqqında məlumat.
2. orders — sifarişlər haqqında info.
3. products — məhsullar haqqında məlumat.
4. order_items — sifarişə daxil olan məhsullar.

Məlumat almaq üçün sorğu təxminən belə olacaq:

SELECT
    c.customer_name,
    o.order_date,
    p.product_name,
    oi.quantity
FROM 
    customers c
JOIN 
    orders o ON c.customer_id = o.customer_id
JOIN 
    order_items oi ON o.order_id = oi.order_id
JOIN 
    products p ON oi.product_id = p.product_id
WHERE 
    c.customer_id = 42;

Amma təsəvvür elə ki, bizim onlayn mağaza gündə yüz minlərlə sifariş emal edir. Bu sorğu çoxlu join-lərə görə çox yavaş işləyəcək.

Həll: denormalizasiya.

Gəlin tez-tez istifadə olunan məlumatlar üçün ayrıca cədvəl yaradaq:

CREATE TABLE order_summary AS
SELECT 
    c.customer_id,
    c.customer_name,
    o.order_id,
    o.order_date,
    p.product_id,
    p.product_name,
    oi.quantity
FROM 
    customers c
JOIN 
    orders o ON c.customer_id = o.customer_id
JOIN 
    order_items oi ON o.order_id = oi.order_id
JOIN 
    products p ON oi.product_id = p.product_id;

İndi məlumat lazım olanda, sadəcə order_summary cədvəlinə sorğu atırıq:

SELECT * FROM order_summary WHERE customer_id = 42;

Nümunə 2: Analitika sistemi. Təsəvvür elə, sən tədbir biletləri satan şirkətin bazası ilə işləyirsən. Belə cədvəllər var:

1. events — tədbirlər haqqında info.
2. sales — bilet satışları haqqında məlumat.

Əgər analitiklər hər tədbir üzrə bir biletin orta gəliri barədə hesabat qurmaq istəyirsə, normalizə olunmuş struktur səni hər dəfə aggregat sorğu yazmağa məcbur edir:

SELECT
    e.event_name,
    AVG(s.price) AS avg_ticket_price
FROM 
    events e
JOIN 
    sales s ON e.event_id = s.event_id
GROUP BY 
    e.event_name;

Bu sorğu çox yavaş ola bilər, xüsusilə satışlar milyonlarla sətrdirsə.

Həll: denormalizasiya. Aggregat məlumatlar üçün ayrıca cədvəl yaradaq:

CREATE TABLE event_summary AS
SELECT 
    e.event_id,
    e.event_name,
    COUNT(s.sale_id) AS ticket_count,
    SUM(s.price) AS total_revenue,
    AVG(s.price) AS avg_ticket_price
FROM 
    events e
JOIN 
    sales s ON e.event_id = s.event_id
GROUP BY 
    e.event_id, e.event_name;

İndi hesabatlar aggregat səviyyədə daha sürətli işləyəcək:

SELECT
    event_name, 
    avg_ticket_price 
FROM 
    event_summary;

Denormalizasiyanın nəticələri

Denormalizasiya əlbəttə ki, sorğuları sürətləndirə bilər, amma bu — bütün problemləri həll edən sehrli çubuq deyil. Əgər bu addımı atsan, aşağıdakılarla qarşılaşa bilərsən.

Birinci — məlumatların təkrarlanması. Eyni info bir neçə yerdə saxlananda, bazanın ölçüsü tez artır və işləmək çətinləşir.

İkinci — məlumatları yeniləmək indi daha çətindir. Təsəvvür elə, səndə müştəri haqqında info customers cədvəlində var, bir də order_summary cədvəlində surəti var. Əgər müştəri adını və ya ünvanını dəyişsə, hər iki yerdə yeniləmək lazımdır. Unutsan — səhv yaranır, çünki məlumatlar artıq uyğun gəlmir.

Üçüncü — belə artıq məlumatlara görə asanlıqla çaşmaq və səhv etmək olur. Bu, bir sənədin müxtəlif versiyaları kimi — bəzən başa düşmək çətin olur ki, hansı versiya düzgündür.

Və nəhayət, belə bazanı dəstəkləmək və inkişaf etdirmək daha çətindir. Bütün məlumat surətlərinin sinxron qalması üçün xüsusi trigger-lər və ya script-lər yazmaq lazım gələcək. Bu isə developer-lər üçün əlavə işdir.

Qısası, denormalizasiya — ağılla istifadə olunmalı bir alətdir, bütün üstünlüklərini və mənfi tərəflərini bilmək lazımdır.

2

Tapşırıq

SQL SELF, səviyyə, dərs

Bağlanıb

Mövcud məlumatlar əsasında denormalizə olunmuş cədvəlin yaradılması

Mövcud məlumatlar əsasında denormalizə olunmuş cədvəlin yaradılması

Açıq

1

Sorğu/viktorina

, səviyyə, dərs

Əlçatan deyil

Verilənlərin normallaşdırılması

Verilənlərin normallaşdırılması

Açıq