Neden her şey tek tabloda değil?
Her siparişin içine müşterinin adını, şehrini, e-postasını tekrar tekrar yazsaydık: veri şişer, müşteri adres değiştirdiğinde yüzlerce satırı güncellememiz gerekir ve tutarsızlık kaçınılmaz olur. İlişkisel tasarım her bilgiyi bir kez saklar ve anahtarlarla bağlar.
İlişki türleri
| Tür | Örnek | Nasıl kurulur? |
|---|---|---|
| Bire-çok (1:N) | Bir müşterinin çok siparişi olur | orders.customer_id → customers.customer_id |
| Çoka-çok (N:M) | Bir siparişte çok ürün, bir ürün çok siparişte | Ara tablo: order_items (order_id, product_id) |
| Bire-bir (1:1) | Bir çalışanın bir özlük dosyası | Aynı anahtarı paylaşan iki tablo |
| Kendine referans | Çalışanın yöneticisi de bir çalışandır | employees.manager_id → employees.emp_id |
Anadolu Market şeması
customers (customer_id PK)
└─< orders (order_id PK, customer_id FK)
└─< order_items (item_id PK, order_id FK, product_id FK) >─┐
products (product_id PK) ────────────────────────────────────────────┘
departments (dept_id PK) ─< employees (emp_id PK, dept_id FK, manager_id FK → emp_id)
─< işareti “bire-çok” demektir. JOIN, bu okları takip ederek tabloları birleştirmektir.
Derinleş: ilişkileri veriyle doğrulamak
Bir ilişkinin türünü varsaymak yerine sorgula. “Her siparişin en fazla bir değerlendirmesi var mı?” sorusu bire-bir mi bire-çok mu olduğunu söyler:
SELECT MAX(n) AS en_fazla_degerlendirme FROM (SELECT order_id, COUNT(*) AS n FROM lk_ratings GROUP BY order_id) t;
Sonuç 1 ise ilişki siparişten değerlendirmeye bire-birdir (ya da değerlendirme yoktur). Benzer biçimde öksüz kayıtları (karşılığı olmayan yabancı anahtar) NOT EXISTS ile ara.