30 Ağu 2025·8 dk
Edgar F. Codd’un İlişkisel Modeli: Neden SQL İş Dünyasını Kazandı
Edgar F. Codd'un ilişkisel modeli veriyi tablolara, anahtarlara ve kurallara dönüştürdü—iş uygulamalarını güçlendiren SQL veritabanlarının yolunu açtı.
Edgar F. Codd'un ilişkisel modeli veriyi tablolara, anahtarlara ve kurallara dönüştürdü—iş uygulamalarını güçlendiren SQL veritabanlarının yolunu açtı.
En basit haliyle ilişkisel model, bilgiyi tablolar (Codd'un dediği gibi “relations”) olarak saklar ve bu tablolar paylaşılan değerler aracılığıyla bağlanabilir.
Bir tablo düzenli bir ızgaradır:
İşler veriyi izole tutmaz. Bir satış bir müşteri, bir ürün, bir fiyat, bir satış elemanı ve bir tarihle ilişkilidir—her biri farklı hızlarda değişir ve farklı ekiplerin sorumluluğundadır. Erken sistemler bu ayrıntıları sıkı bağlı, değiştirmesi zor yapılarda saklardı. Bu durum raporlamayı yavaş, değişiklikleri riskli ve “basit soruları” beklenmedik şekilde pahalı hale getiriyordu.
İlişkisel model daha net bir yaklaşım sundu: farklı kavramlar için ayrı tablolar tutun ve cevap gerektiğinde bunları bağlayın. Müşteri bilgilerini her fatura kaydında çoğaltmak yerine müşterileri bir kez saklayıp faturalar tarafından referans verirsiniz. Bu çelişkileri azaltır (aynı müşterinin iki farklı yazımı) ve güncellemeleri daha öngörülebilir kılar.
İyi tanımlanmış tablolar ve bunları bağlama kurallarını vurgulayarak model yeni bir beklenti belirledi: veritabanı büyüdükçe tutarsızlığı engellemeye yardımcı olmalı—özellikle birçok insan ve sistem aynı anda yazıyorsa.
Codd'un modeli bir sorgu dili değildi, ama ilham verdi. Eğer veriler ilişkili tablolarda duruyorsa, şuna ihtiyacınız olur:
Bu yol SQLe çıktı; SQL modeli günlük ekiplerin iş verilerine soru sorması ve tekrarlanabilir, denetlenebilir cevaplar alması için pratik bir yola dönüştürdü.
İlişkisel modelden önce birçok kuruluş önemli bilgileri dosyalar içinde saklardı—genellikle uygulama başına bir dosya. Bordro kendi kayıtlarına, envanter başka birine ve müşteri hizmetleri yine başka bir “müşteri” versiyonuna sahipti. Her sistem izole çalışıyordu ve bu izolasyon öngörülebilir acılar yarattı.
Erken veri işleme genellikle tek amaçlı özel dosya formatları ve bunları okuyacak programlar etrafında kuruluydu. Verinin yapısı (her alanın nerede olduğu, kayıtların nasıl sıralandığı) onu okuyan koda sıkı sıkıya bağlıydı. Bu, küçük değişikliklerin bile—yeni bir alan ekleme, ürün kategorisi yeniden adlandırma, adres formatını değiştirme—birden çok programın yeniden yazılmasını gerektirebileceği anlamına geliyordu.
Ekipler tek bir gerçek kaynağı kolayca paylaşamadıkları için veriyi kopyalıyorlardı. Müşteri adresleri satış dosyalarında, gönderim dosyalarında ve faturalama dosyalarında yer alabilirdi.
Bir adres değiştiğinde her kopya güncellenmeliydi. Eğer bir sistem gözden kaçtıysa tutarsızlıklar ortaya çıkıyordu: faturalar yanlış yere gidiyordu, gönderimler gecikiyordu ve destek temsilcileri kullandıkları ekrana bağlı olarak farklı “gerçekleri” görüyordu. Veri temizliği projeleri tek seferlik bir çözüm yerine tekrarlayan işler haline geliyordu.
İş kullanıcıları hâlâ iş soruları soruyordu—“Hangi müşteriler X ürünü satın aldı ve sonra geri iade etti?”—ama bunlara yanıt vermek birlikte çalışmak üzere tasarlanmamış dosyaları birleştirmeyi gerektiriyordu. Ekipler sık sık tek seferlik rapor çıktıları oluşturuyor, bu da daha fazla kopya ve uyumsuzluk fırsatı yaratıyordu.
Sonuç: raporlama döngüleri yavaştı ve “hızlı sorular” mühendislik işi haline gelmişti.
Kuruluşların birçok uygulamanın güvenebileceği paylaşılan verilere, daha az tutarsızlığa ve daha az çoğaltmaya ihtiyacı vardı. Ayrıca her seferinde temeli yeniden inşa etmeden yeni sorular sorabilmenin bir yoluna ihtiyaçları vardı. Bu boşluk Codd'un temel fikrini hazırladı: veriyi uygulamaya bağımlı olmayan, tutarlı bir şekilde tanımlayın, böylece sistemler değişirken doğru bilgiyi bozmadan evrilebilsin.
Edgar F. Codd, IBM'de uzun yıllar çalışan bir İngiliz bilgisayar bilimcisiydi ve kuruluşların bilgiyi verimli saklayıp geri almasını nasıl iyileştirebilecekleri üzerinde çalıştı. 1960'larda çoğu “veritabanı” sistemi daha çok dikkatle yönetilen dosya dolaplarına benziyordu: veri sıkı, önceden tanımlanmış yapılarda saklanıyor ve bu yapıları değiştirmek genellikle uygulamaların yeniden yazılmasını gerektiriyordu. Bu kırılganlık, işletmeler büyüdükçe ve gereksinimler değiştikçe ekipleri rahatsız ediyordu.
1970'te Codd, başlığı uzun bir makale yayımladı—“A Relational Model of Data for Large Shared Data Banks”—ve şaşırtıcı derecede basit bir fikir önerdi: veriyi ilişkili tablolar olarak temsil edin ve bunları sorgulayıp birleştirmek için resmi bir işlem kümesi kullanın.
Genel olarak makale şunu savundu:
Codd önerisini matematikle (küme teorisi ve mantık) temellendirdi. Bu akademik gösterişten ibaret değildi—veritabanı tasarımına açık, test edilebilir bir temel verdi. Resmi bir modelle bir sorgunun doğru olup olmadığını, iki sorgunun eşdeğerliğini ve sonuçları değiştirmeden yürütmeyi nasıl optimize edeceğinizi akıl yürütmek mümkündür. İş yazılımları için bu, sistemler ölçeklendikçe ve evrildikçe daha az sürpriz anlamına gelir.
O zamanlar birçok sistem geliştiricilerin önceden tanımlanmış yollar boyunca veriye “navigasyon” yaptığı hiyerarşik veya ağ modellerine dayanıyordu. Codd'un yaklaşımı bu zihniyete meydan okudu: veritabanı ağır işi yapmalı. Uygulamaların depolama düzenini bilmesine gerek yok; istenen sonucu tarif etmeliler ve veritabanı verimli bir yol bulmalı.
Bu ayrım SQL ve yıllar içinde değişen ürün gereksinimlerinin üstesinden gelebilecek veritabanlarının zeminini hazırladı.
Codd'un ilişkisel modeli basit bir fikrinden başlar: gerçekleri relations—çoğu kişinin tablo olarak gördüğü yapılar—şeklinde saklayın, ancak bunları “akıllı elektronik tablolar” gibi değil, veriyi kesin biçimde tanımlayan araçlar olarak ele alın. Bir relation, işletmenizin önem verdiği şeyler hakkında bir dizi bildirimi saklar: müşteriler, siparişler, ödemeler, ürünler, gönderimler.
Bir relation bir tür gerçek desenini temsil eder. Örneğin bir Orders relation “bir siparişin bir ID'si, bir tarihi, bir müşterisi ve bir toplamı vardır” gibi bilgiyi yakalayabilir. Önemli nokta, her relation'ın açıkça tanımlanmış bir anlamı olması ve her sütunun bu anlamın parçası olmasıdır.
Bir satır (Codd'un dediği gibi tuple) o gerçeğin belirli bir örneğidir: belirli bir sipariş. İlişkisel modelde satırların doğuştan bir “pozisyonu” yoktur. 5. satır özel değildir—önemli olan değerler ve onları tanımlayan kurallardır.
Bir sütun (bir öznitelik) relation içindeki belirli bir özelliktir: OrderDate, CustomerID, TotalAmount. Sütunlar sadece etiket değildir; hangi tür değerin kabul edildiğini tanımlar.
Bir domain, bir öznitelik için izin verilen değer kümesidir—OrderDate için tarihler, TotalAmount için pozitif sayılar ya da Status için sınırlı bir kod listesi (ör. Pending, Paid, Refunded) gibi. Domainler belirsizliği azaltır ve "12/10/25" formatlarını karıştırmak veya sayısal alanlara "N/A" koymak gibi ince hataları engeller.
"İlişkisel" terimi, gerçeklerin relation'lar arasında nasıl bağlanabileceğini ifade eder (müşteriler ile siparişler gibi) ve aynı bilgiyi her yerde çoğaltmadan faturalama, raporlama, denetim, müşteri desteği gibi ortak iş görevlerini mümkün kılar.
Tablolar kendi başlarına faydalıdır, ama iş verileri hangi müşterinin hangi siparişi verdiği, hangi ürünlerin olduğu ve ne kadar ücretlendirildiği gibi gerçek bağlantılar olmadan anlamlı değildir. Anahtarlar bu bağlantıları güvenilir hale getiren mekanizmadır.
Bir birincil anahtar bir satırı benzersiz tanımlayan sütun (veya sütun setidir). Bunu bir satırın "isim etiketi" olarak düşünebilirsiniz. Önemli bölüm stabilitedir: isimler, e-postalar ve adresler değişebilir; dahili bir ID değişmemelidir.
İyi bir birincil anahtar yinelenen veya belirsiz kayıtları önler. İki müşteri aynı ada sahip olsa bile PK onları ayırt eder.
Bir yabancı anahtar başka bir tablonun birincil anahtarını saklayan bir sütundur. İlişkiler bu şekilde tüm kaydı kopyalamadan temsil edilir.
Örneğin satışı şöyle modelleyebilirsiniz:
customer_id PK, name, email)order_id PK, customer_id FK → customers.customer_id, order_date)order_item_id PK, order_id FK → orders.order_id, product, quantity, price)Yabancı anahtar kısıtlamaları bir tür koruma işlevi görür. Şunları engellerler:
customer_idye işaret eden bir sipariş.Pratik anlamda, anahtarlar ve kısıtlamalar ekiplerin raporlara ve iş akışlarına güvenmesini sağlar. Veritabanı ilişkileri zorunlu kıldığında, faturalama, karşılamalar ve müşteri desteği gibi alanlarda daha az hata ortaya çıkar—çünkü veri sessizce imkansız durumlara sürüklenemez.
Normalizasyon, aynı gerçek birçok yerde saklandığında verinin çelişkiye kaymasını engelleyen ilişkisel modelin yöntemidir. Aynı gerçek birden fazla yerde saklandığında bir kopyayı güncelleyip diğerini unutmaya meyilli olunur. Bu, faturaların yanlış adrese gitmesi, raporların uyuşmaması veya bir müşterinin bir ekranda “inaktif” diğerinde “aktif” görünmesiyle sonuçlanır.
Pratik düzeyde normalizasyon şu yaygın sorunları azaltır:
Ayrıca ekleme anomalilerini (yeni bir müşteri ekleyebilmek için sipariş olması gerekmesi) ve silme anomalilerini (son siparişi silmenin tek müşteri bilgisini silmesi) önler.
Ağır teoriye gerek yok:
Birinci Normal Form (1NF): her alan atomik olsun. Bir müşterinin birden çok telefon numarası varsa bunları tek bir hücreye sıkıştırmayın; ayrı bir tablo (veya ayrı satırlar) kullanın, böylece her değer temizce aranıp güncellenebilir.
İkinci Normal Form (2NF): bir tablonun kimliği birden fazla sütuna bağlıysa (kompozit anahtar), anahtar olmayan detaylar tüm anahtara bağlı olsun. Bir sipariş satırı, o satırın miktarını ve fiyatını saklamalı, müşteri adresini değil.
Üçüncü Normal Form (3NF): yan gerçekleri ayırın. Bir tablo CustomerId ve CustomerCity saklıyorsa şehir genellikle müşteri tablosunda olmalıdır; her siparişte kopyalanmamalıdır.
Daha fazla normalizasyon genellikle daha fazla tablo ve daha fazla join anlamına gelir. Bu tutarlılığı artırır, ama raporlamayı karmaşıklaştırabilir ve bazen performansı etkileyebilir. Birçok ekip çekirdek varlıklar (müşteriler, ürünler, faturalar) için 3NF hedefler, sonra okuma ağırlıklı paneller için ölçümler gerekçelendirdiğinde seçici denormalizasyon uygular—ama bir otorite kaynağını birincil anahtar / yabancı anahtar ilişkileriyle korur.
İlişkisel cebir ilişkisel modelin arkasındaki “matematik”tir: bir tabloyu başka bir tabloya dönüştürmek için kullanılan küçük, kesin bir işlem kümesi.
Bu kesinlik önemlidir. Kurallar netse sorgu sonuçları nettir. Filtrelediğinizde, yeniden şekillendirdiğinizde veya verileri birleştirdiğinizde ne olacağını tahmin edebilirsiniz—belirsiz veya belgelenmemiş davranışlara güvenmeden.
İlişkisel cebir bileşenleri birleştirilebilir inşa blokları tanımlar. Önemlilerden üçü:
Select: istediğiniz satırları seçin.
Örnek: “Sadece geçen ayın siparişleri” veya “Sadece Fransa'daki müşteriler.” Aynı sütunları tutarsınız ama satır sayısını azaltırsınız.
Project: istediğiniz sütunları seçin.
Örnek: “Müşteri adı ve e-posta göster.” Mantıksal olarak aynı satırları tutarsınız ama gereksiz sütunları atarsınız.
Join: farklı tablolardaki ilişkili gerçekleri birleştirin.
Örnek: “Her siparişe müşteri bilgilerini ekle,” shared identifier (örn. customer_id) kullanarak. Çıktı, ayrı saklanan alanları bir araya getiren yeni bir tablodur.
İş verisi doğal olarak konulara ayrılır: müşteriler, siparişler, faturalar, ürünler, ödemeler. Bu ayrım her gerçeği bir kez saklamayı sağlar (uyumsuzlukları önler), fakat cevaplar genellikle bu gerçekleri yeniden birleştirmeyi gerektirir.
Join'ler bu yeniden birleştirmeyi anlamlı şekilde yapmanın resmi yoludur. Müşteri isimlerini her sipariş satırına kopyalamak yerine isimleri bir kerede saklar ve rapor için join yaparsınız.
İlişkisel cebir satır kümeleri üzerinde tanımlandığı için her adımın beklenen çıktısı iyi sınırlanmıştır:
Bu kavramsal yapı SQL'in pratik olmasını sağlayan omurgadır: sorgular rastgele veri çekimi değil, iyi tanımlanmış dönüşüm dizileri haline gelir.
Codd'un ilişkisel modeli ne anlama geldiğini (relations, keys, operations) tarif etti ama insanların günlük kullanım için rahatça başvuracağı bir yol önermedi. SQL bu boşluğu doldurdu: ilişkisel fikirleri analistler, geliştiriciler ve veritabanı ürünlerinin paylaşabileceği pratik, okunabilir bir dile dönüştürdü.
SQL ilişkisel cebirden esinlenmiştir, ancak Codd'un orijinal teorisinin kusursuz bir uygulaması değildir.
Önemli bir fark SQL'in eksik veya bilinmeyen değerleri nasıl ele aldığıdır. Klasik ilişkissel teori iki değerli mantığa dayanırken SQL NULL ekler ve üç değerli mantık ortaya çıkar. Bir başka fark: teoride kümelerle çalışılır (kopya yok), oysa SQL tabloları açıkça engellenmediği sürece tekrar eden satırlara izin verebilir.
Bu farklara rağmen SQL temel vaadi korudu: sonucu tarif edersiniz (declarative), veritabanı uygulanabilir bir yol bulur.
Codd 1970'te temel makalesini yayımladı. 1970'lerde IBM, ilişkisel veritabanının gerçek iş yükleri için yeterince iyi performans gösterebileceğini ve yüksek seviyeli sorgu dilinin verimli yürütme planlarına derlenebileceğini gösteren System R gibi erken prototipler geliştirdi.
Eş zamanlı olarak akademik ve ticari çabalar SQL'i ilerletti. 1980'lerin sonlarına doğru SQL standardizasyonu (ANSI/ISO) vendorların ortak bir dilde uzlaşmasını sağladı—her ürün kendi uzantılarını korusa da.
SQL, soru sorma maliyetini düşürdü. Her rapor için özel program yazmak yerine ekipler soruları doğrudan ifade edebildi:
GROUP BY ile bölge ve aya göre satışlarİş yazılımları için SQL'in join ve toplama kombinasyonu bir kırılma noktasıydı. Finans ekibi faturaları ödemelerle uzlaştırabilir; ürün ekibi dönüşüm hunilerini analiz edebilir; operasyon ekibi envanter ve karşılama durumunu izleyebilir—hepsi aynı paylaşılan, yapılandırılmış veri modeli üzerinde sorgu yaparak.
Bu kullanılabilirlik ilişkisel modelin araştırma dünyasından çıkarak günlük bir araç olmasının büyük bir nedenidir.
İş sistemleri güvene bağlıdır. Bir veritabanı sadece veriyi saklamakla kalmamalı—doğru bakiye, doğru envanter sayımları ve güvenilir bir denetim izi korumalıdır; özellikle birçok kişi sistemi aynı anda kullanırken.
Bir işlem, bir dizi değişikliği tek bir iş operasyonu olarak gruplar. Düşünün: “100$ transfer et”, “bir siparişi gönder”, veya “bir bordro çalıştır”. Bunların her biri birçok tabloyu ve satırı etkiler.
Ana fikir topluca ya tamamlanma ya da hiç olmama davranışıdır:
Böylece paranın bir hesaptan çıktığı ama diğerine ulaşmadığı ya da sipariş kaydı olmadan envanterin azaldığı durumlar önlenir.
ACID, işletmelerin güvendiği garantilerin kısa adıdır:
Birlikte, kısıtlamalar (PK, FK, check'ler) geçersiz durumların kaydedilmesini engeller; işlemler ise tablodaki ilgili güncellemelerin birlikte gelmesini sağlar.
Pratikte: bir sipariş kaydedilir, satır öğeleri kaydedilir, envanter azaltılır ve bir denetim günlüğüne giriş yazılır—ya hepsi olur ya hiçbiri. Bu kombinasyon SQL veritabanlarının ölçekle güvenilir iş yazılımlarını desteklemesini sağlar.
SQL veritabanları “trend oldukları” için değil—çoğu kuruluşun zaten düşündüğü ve çalıştığı biçime uydukları için yayıldı. Bir şirkette tekrar eden, yapılandırılmış şeyler çoktur: müşteriler, faturalar, ürünler, ödemeler, çalışanlar. Her birinin açık bir özellik kümesi vardır ve birbirleriyle öngörülebilir biçimde ilişkilenir. İlişkisel model bu gerçeğe iyi uyum sağlar: bir müşteri birçok siparişe sahip olabilir, bir siparişin satır öğeleri vardır, ödemeler faturalarla uzlaştırılır.
İş süreçleri tutarlılık ve izlenebilirlik etrafında kuruludur. Finans “Hangi faturalar ödenmemiş?” diye sorduğunda veya destek “Bu müşterinin hangi planı var?” diye baktığında cevap her araçta aynı olmalıdır. İlişkisel veritabanları olguları bir kez saklayıp her yerde referans verilecek şekilde tasarlanmıştır; bu da maliyetli yeniden çalışmaları azaltır.
SQL yaygınlaştıkça etrafında bir ekosistem oluştu: raporlama araçları, BI panoları, ETL boru hatları, konektörler ve eğitim. Bu uyumluluk benimsemeyi kolaylaştırdı. Veriniz ilişkisel bir veritabanındaysa, çoğu raporlama ve analiz iş akışına özel yapıştırıcı kod yazmadan bağlanmak genellikle kolaydır.
Uygulamalar hızla değişir—yeni özellikler, yeni arayüzler, yeni entegrasyonlar. İyi tasarlanmış bir şema dayanıklı bir kontrat gibidir: hizmetler ve ekranlar değişse bile çekirdek tablolar ve ilişkiler verinin anlamını sabit tutar. Bu istikrar SQL veritabanlarının güvenilir merkez olmasının büyük bir nedenidir.
Şemalar sadece veriyi düzenlemekle kalmaz—rolleri netleştirir. Ekipler “Müşteri”nin ne olduğunu, hangi alanların zorunlu olduğunu ve kayıtların nasıl bağlandığını kabul edebilir. Birincil ve yabancı anahtarlarla sorumluluklar açıkça belirir: kim kayıt oluşturur, kim güncelleyebilir ve iş boyunca ne korunmalıdır.
İlişkisel veritabanları yerini güvenilirlik ve öngörülebilirlik ile kazandı, ama her iş yükü için en iyi seçenek değiller. SQL sistemlerine yönelik birçok eleştiri aslında tek bir aracın her işe uydurulmasına dair eleştiridir.
İlişkisel şema bir kontrattır: tablolar, sütunlar, tipler ve kısıtlamalar “geçerli veri”nin ne olduğunu tanımlar. Bu paylaşılan anlayış için mükemmeldir ama ürün hâlâ evrilirken ekipleri yavaşlatabilir.
Haftalık yeni alanlar yayıyorsanız, migrationlar, backfill'ler ve dağıtımlar koordine etmek bir darboğaz olabilir. İyi araçlarla bile şema değişiklikleri planlama gerektirir—özellikle tablolar büyükse veya sistemler 7/24 çevrimiçi kalmak zorundaysa.
“NoSQL” ilişkisel fikre reddiyeden çok belirli ağrılara yanıt olarak doğdu:
Bu sistemlerin birçoğu sıkı tutarlılıktan veya zengin join yeteneklerinden vazgeçerek hız, esneklik veya dağıtım avantajı elde etti.
Çoğu modern yapı polyglot'tur: çekirdek iş kayıtları için ilişkisel veritabanı; içerik ve analiz için event stream, arama indeksi, cache veya belge deposu gibi diğer depolar. İlişkisel model gerçek kaynağı olmaya devam ederken diğer depolar okuma-ağır veya uzmanlaşmış sorgular için hizmet eder.
Seçerken odaklanın:
İyi bir varsayılan, çekirdek veriler için SQL; sonra ilişkisel modelin açıkça sınır koyduğu yerlerde alternatifleri eklemektir.
Codd'un ilişkisel modeli sadece tarih değil—iş verilerini daha güvenilir, değiştirilebilir ve raporlanabilir kılan alışkanlıklar setidir. Uygulamanız birçok depolama sistemi kullanıyorsa bile ilişkisel düşünce tarzı “kayıt sistemleri” (siparişler, faturalar, müşteriler, envanter) için güçlü bir varsayılan olmaya devam eder.
İşinizin önem verdiği gerçek dünya isimlerini tablolar olarak modelleyerek başlayın (Customers, Orders, Payments) ve bunları ilişkilerle bağlayın.
Erken acıyı önleyecek birkaç kural:
CustomerPhones yerine phone1, phone2, phone3).Bu ilkeleri gerçek bir ürüne dönüştürüyorsanız, şema niyetini ve uygulama kodunu hizalı tutacak araçlar yardımcı olur. Örneğin, Koder.ai bir sohbet isteminden React + Go + PostgreSQL uygulaması üretebilir; bu, normalize edilmiş bir şemayı hızla prototiplemeyi kolaylaştırır ve veritabanını doğruluk kaynağı olarak tutarken kaynak kodu dışa aktarmanıza izin verir.
Veriniz güçlü doğruluk garantilerine ihtiyaç duyuyorsa sorun:
Cevabınız sıkça “evet” ise ilişkisel veritabanı genelde en basit yoldur.
“SQL ölçeklenemez” demek fazla geneldir. SQL sistemleri indeksler, cache, read replica'lar ve gerektiğinde sharding ile ölçeklenir. Çoğu ekip gerçek veritabanı sınırlarına ulaşmadan önce modelleme ve sorgu sorunlarıyla karşılaşır.
“Normalizasyon her şeyi yavaşlatır” de tamamıyla doğru değildir. Normalizasyon anomalileri azaltır; performans indeksler, sorgu tasarımı ve ölçümlere dayalı seçici denormalizasyonla yönetilir.
Codd ekiplerine paylaşılan bir kontrat verdi: veriler ilişkili tablolarda düzenlenir, iyi tanımlanmış işlemlerle değiştirilir ve kısıtlamalarla korunur. Bu kontrat, günlük yazılımın yıllarca evrilse bile temel soruları yanıtlayabilmesini sağlar: “ne oldu, ne zaman ve neden?”
İlişkisel model verileri tablolar (relations) olarak saklar ve şunlardan oluşur:
Ana faydası, ayrı tabloların paylaşılan kimlikler aracılığıyla bağlanabilmesidir, böylece her gerçeği tek bir yerde tutup gerektiğinde raporlar ve iş akışları için birleştirebilirsiniz.
Dosya tabanlı sistemler veri düzenini uygulama koduna sıkı sıkıya bağlardı. Bu pratik sorunlar yaratıyordu:
İlişkisel veritabanları veri tanımını tek bir uygulamaya bağımlı olmaktan çıkarıp, çapraz sorgulamayı rutin hale getirdi.
Bir birincil anahtar (PK) tablodaki her satırı benzersiz şekilde tanımlar ve zaman içinde sabit kalmalıdır.
Pratik öneriler:
customer_id).Bir yabancı anahtar (FK), değerleri başka bir tablodaki birincil anahtarla eşleşmesi gereken kolondur. Bu, ilişkileri tüm kaydı kopyalamadan temsil etmenin yoludur.
Örnek desen:
orders.customer_id → customers.customer_idFK kısıtlamaları etkinse veritabanı şu durumları engelleyebilir:
Normalizasyon, her gerçeği mümkün olduğunca bir kere depolayarak tutarsızlıkları azaltmayı amaçlar. Bu sayede ortaya çıkan sorunlar:
Çoğu ekip çekirdek varlıklar için hedefler; sonra ölçümler haklı çıkardığında seçici olarak denormalizasyon yaparlar.
İyi bir 1NF kuralı: bir alan, bir değer. phone1, phone2, phone3 gibi kolonlar eklemek yerine bunları ilişkisel bir tabloya ayırın:
customer_phones(customer_id, phone_number, type)Bu, telefon numaralarını aramayı, doğrulamayı ve güncellemeyi kolaylaştırır.
İlişkisel cebir, sorguların arkasındaki temel işlemleri tanımlar:
Günlük kullanım için cebri yazmanız gerekmez, ama bu kavramlar SQL sonuçlarını anlamanıza ve yanlış join'lerden kaçınmanıza yardımcı olur.
SQL, ilişkisel fikirleri kullanılabilir hâle getirerek insanların sonuçları deklaratif şekilde tanımlamasını sağladı: sonucu tarif edersiniz, veritabanı yürütme planını seçer.
Pratik kazanımlar:
GROUP BY)SQL, Codd'un teorisini tam olarak uygulamasa da ilişkisel tablolar üzerinde güvenilir sorgulama iş akışını korudu.
SQL ile saf ilişkisel model arasındaki önemli farklardan bazıları:
NULL üç değerli mantık (true/false/unknown) getirir; bu filtreleri ve join'leri etkiler.Bunun pratik sonucu: kullanımında dikkatli olun ve gerekli yerlerde benzersizliği zorunlu kılın.
İlişkisel bir veritabanı kullanın eğer paylaşılan iş kayıtlarında güçlü doğruluk gerekiyor ise.
Pratik kontrol listesi:
NULLCevabınız çoğunlukla “evet” ise ilişkisel veritabanı genelde en basit yoldur. İhtiyaç belli ise NoSQL veya özel depoları ekleyin ama bir kayıt sistemi tutarlı kalsın.