Normalizasyon — Aynı Bilgi Neden Tek Yerde Durmalı?

Bir arkadaşının telefon numarasını, ona gönderdiğin her davetiyenin köşesine yazdığını düşün. Numara değişince bütün davetiyeleri tek tek bulup düzeltmen gerekir. Birini unutursan, iki farklı numara elinde kalır.

Aynı bilgi, üç yerde

Havale satırına müşterinin adını ve telefonunu da yazarsan, aynı müşteri her havalesinde bir kez daha kaydedilir. Bilgi tekrar ettikçe, onu her yerde aynı tutma işi de sana kalır.

Bu tekrarın yol açtığı üç klasik soruna anomali denir. Hepsinin kökü aynıdır: iki ayrı şey, müşteri ve havale, tek bir satırda yaşıyor.

Üç anomali

Güncelleme anomalisi: bir kopyayı değiştirip ötekileri unutursun. Silme anomalisi: bir havaleyi silerken müşteriyi kaybedersin. Ekleme anomalisi: havalesi olmayan bir müşteriyi kaydedemezsin.

Normalizasyon?Terimin tanımını açnormalizasyonAynı bilginin veritabanında tek bir yerde durması için veriyi tablolara bölmek. Müşterinin adı her siparişte değil, müşteri tablosunda bir kez yazılır.Sözlükte gör → bu üçünü birden çözer: müşteriler kendi tablosunda, havaleler kendi tablosunda durur. Havale, müşteriye bir foreign key?Terimin tanımını açforeign keyBir tablodaki kolonun başka bir tablonun anahtarına işaret etmesi. Veritabanı, işaret edilen satırın gerçekten var olduğunu garanti eder.Sözlükte gör → ile işaret eder.

Bedeli bir JOIN

Normalize edilmiş tasarımda havaleleri müşteri adıyla listelemek için iki tabloyu birleştirirsin. Anahtar kolonları indeksliyse bu JOIN çoğu zaman ucuzdur.

Okuma çok ağırsa ve bir alan nadiren değişiyorsa, onu bilerek kopyalamak, yani denormalizasyon?Terimin tanımını açdenormalizationOkumayı hızlandırmak ya da o anın gerçeğini saklamak için bir bilgiyi bilerek kopyalamak. Asıl kaynak tek yerde kalır, kopya oradan güncellenir.Sözlükte gör →, mantıklı olabilir. Ama doğru kaynak yine tek yerde kalır ve kopya oradan güncellenir.

Kendin gör

1. Varsayılanla oynat. Tek tabloda telefonu güncelledin, iki satır eski kaldı.
2. İşi “tek havalesini sil” yap. Müşteri 9 havaleyle birlikte kayboldu.
3. “Yeni müşteriyi kaydet” seç. Tek tabloda havalesiz müşteriye yer yok.
4. Tasarımı iki tabloya çevir. Üç sorun da kayboldu; rapor için bir JOIN geldi.

Tuzaklar

Geçmişi normalize etmek. Havale anındaki adres ya da fiyat, o anın gerçeğidir. Müşterinin bugünkü adresine bağlarsan eski dekontlar değişir; bu bilgi havaleye kopyalanmalıdır.

Kopyanın sahibini unutmak. Denormalize ettiğin bir alanı iki yerde güncellersen iki doğru kaynak yaratırsın. Kopya yalnızca asıl kaynaktan güncellenir.

Gereğinden fazla bölmek. Her küçük alanı ayrı tabloya koymak, her okumayı beş JOIN’e çevirir. Birlikte değişen ve birlikte okunan bilgiler aynı tabloda kalabilir.

Aşağıdaki örnek bir bankanın havale şemasından: müşteri tek yerde, havale ona bağlı, havale anındaki alıcı adı bilinçli olarak kopyalanmış.

1
create table customers (
2
    id     bigint primary key,
3
    name   varchar(120) not null,
4
    phone  varchar(20)  not null
5
);
6

7
create table transfers (
8
    id              bigint primary key,
9
    customer_id     bigint         not null references customers (id),
10
    amount          numeric(19, 2) not null,
11
    created_at      timestamp      not null,
12
    -- Deliberate copy: the receipt shows the payee as it was at that moment.
13
    payee_name      varchar(120)   not null
14
);
15

16
create index transfers_customer_idx on transfers (customer_id);

1
-- One join over an indexed key: the price of storing each fact once.
2
select t.id, c.name, t.amount, t.created_at
3
  from transfers t
4
  join customers c on c.id = t.customer_id
5
 where t.created_at >= :from
6
 order by t.created_at desc;

1
-- One row, and every transfer sees the new number.
2
update customers set phone = :phone where id = :customerId;

Kendini sına