İlişkisel veritabanlarının Codd ve SQL'den ACID ve ERP'ye uzanan net bir tarihi; neden çoğu iş uygulamasını desteklediklerini ve hangi noktalarda yetersiz kaldıklarını açıklıyor.
“İş uygulaması”, günlük operasyonları yürütmeye yarayan her sistemdir: sipariş alma, fatura düzenleme, müşteri takibi, stok yönetimi, tedarikçilere ödeme ve geçen haftanın (veya bu sabahın) raporlanması. İster satın alma ve finansı yöneten bir ERP, ister satış faaliyetlerini düzenleyen bir CRM olsun, bu uygulamaların hepsinin ortak bir gereksinimi vardır: sayılar ve kayıtlar gerçeğe uymalı.
İlişkisel veritabanı, bilgiyi tablolarda saklar—daha sıkı kuralları olan elektronik tablolar gibi düşünün. Her tablonun satırları (bireysel kayıtlar) ve sütunları (müşteri adı, sipariş tarihi veya fiyat gibi alanlar) vardır. Tablolar, anahtarlar kullanılarak birbirine bağlanır: Customers tablosundaki bir müşteri kimliği Orders tablosunda referans alınabilir, böylece sistem hangi siparişin hangi müşteriye ait olduğunu bilir.
Bu yapı basit görünse de güçlüdür: birçok kişi ve süreç aynı anda veriye dokunsa bile iş uygulamasının veriyi düzenli tutmasını sağlar.
İlişkisel veritabanları, iş uygulamaları için birkaç pratik nedenle standart temel haline geldi:
İlişkisel sistemlerin güçlü yönleri—özellikle veri bütünlüğü ve güvenilir işlemler—açık ama esneklik ve ölçeklendirme konusunda takasları vardır. Neden klasik OLTP işlerine çok uygun olduklarını, alternatiflerin nerelerde öne çıktığını ve yönetilen bulut veritabanları ile yeni veri ihtiyaçlarının neleri değiştirdiğini ele alacağız.
İlişkisel veritabanları yaygınlaşmadan önce, çoğu iş verisi bir yamalı dosya düzeninde yaşıyordu: paylaşılan sürücülerdeki elektronik tablolar, muhasebe araçlarından dışa aktarılan düz metin dosyaları ve tedarikçiler ya da dahili geliştiriciler tarafından oluşturulmuş özel dosya formatları.
Bu, şirket küçükken ve sadece birkaç kişinin erişimine ihtiyaç duyduğunda işe yarıyordu. Ancak satış, finans ve operasyonlar aynı bilgiye bağımlı oldukça dosya tabanlı depolama çatlamaya başladı.
Birçok kuruluş şunlara dayanıyordu:
En büyük sorun sadece rahatsızlık değildi—güveniydi. Aynı müşteri üç farklı yerde hafifçe farklı ad, adres veya ödeme koşullarıyla görünebiliyordu.
Güncellemeler tutarsızdı çünkü her kopyanın değiştirilmesi insanların hatırlamasına bağlıydı. Yeni bir telefon numarası satış tablosunda güncellenebilir ama faturalamada güncellenmeyebilirdi; bu da ödemelerin kaçmasına veya sevkiyat gecikmelerine neden oluyordu.
Raporlama zordu çünkü dosyalar “hangi müşterilerin gecikmiş faturası ve açık siparişi var” gibi sorular için tasarlanmamıştı. Cevaplamak manuel aramalar, uzun tablo formülleri zincirleri veya dosya düzenleri değiştiğinde bozulan özel betikler gerektiriyordu.
Dosyalar eşzamanlı düzenlemeleri iyi yönetmez. Aynı kaydı güncelleyen iki kişi birbirinin çalışmalarını üzerine yazabilir ve bir dosyayı “kilitlemek” genellikle herkesin beklemesi anlamına geliyordu. Ağ üzerinde dosyalar büyüdükçe performans da düşüyordu.
Şirketlerin, verilerin geçerli kalmasını sağlayan kurallara sahip ortak bir gerçek kaynağına ve güvenilir güncellemelere (değişikliklerin ya tamamen gerçekleşmesi ya hiç gerçekleşmemesi) ihtiyacı vardı. Bu baskı ilişkisel veritabanlarının ortaya çıkmasına ve “belgelerde veri”den “yönetilen bir sistem olarak veri”ye geçişe zemin hazırladı.
1970'te IBM araştırmacısı Edgar F. "Ted" Codd, ilişkisel modeli önerdi—şirketlerin veriyi saklama ve kullanma şeklini yeniden şekillendiren bir fikir. Atılım yeni bir depolama cihazı veya daha hızlı bir bilgisayar değildi. Değişen iş ihtiyaçları karşısında veriyi tutarlı şekilde yönetmeyi sağlayacak daha basit bir düşünme biçimiydi.
İlişkisel modelin merkezinde basit bir kavram vardır: bilgiyi ilişkiler halinde düzenleyin; bugün çoğu kişinin bildiği adıyla tablolar. Bir tablo satırlar (kayıtlar) ve sütunlar (alanlar) içerir. Müşteriler bir tabloda, faturalar başka bir tabloda, ürünler başka bir tabloda olur.
Güçlü kılan tek şey tablo formatı değildi—onu çevreleyen kurallarydi:
Bu yapı verinin doğrulanmasını, birleştirilmesini ve yanlışlıkla çelişmeye düşmesini zorlaştırdı.
Erken sistemler sıklıkla iş kurallarını ve veri formatlarını uygulamanın içine "pişirirdi". Yazılımı değiştirirseniz dosyaları okuma yöntemi bozulabilirdi. Dosya formatını değiştirirseniz uygulamanın bir kısmını yeniden yazmanız gerekebilirdi.
İlişkisel model temiz bir ayrımı teşvik etti: veritabanı veriyi ve bütünlüğünü yönetir; uygulamalar veriyi iyi tanımlanmış işlemlerle ister ve günceller.
Bu ayrım önemlidir çünkü işletmeler nadiren durağandır. Fiyatlandırma kuralları değişir, müşteri alanları evrimleşir ve raporlama gereksinimleri artar. İlişkisel veritabanı ile birçok değişiklik veritabanı şemasında veya sorgularda yapılabilir, tüm uygulamayı yeniden inşa etmeye gerek kalmaz.
Veri tablolar içinde tutarlı kurallarla saklandığında daha taşınabilir ve dayanıklı hale gelir:
Bu yüzden ilişkisel model iş yazılımları için doğal bir uyum sağladı: dağınık, uygulamaya özgü veriyi yıllar boyunca büyümeye ve değişime dayanabilecek düzenli bir sisteme dönüştürdü.
İlişkisel veritabanları iş dünyasında güven kazandı çünkü veriye güvenilir bir “kimlik” ve kayıtları bağlamanın kontrollü bir yolunu verdiler. Bu kimlik anahtartır—bağlantılar ise ilişkiler.
Birincil anahtar, bir tablodaki satırı benzersiz olarak tanımlar. Customers tablosunda bu CustomerID olabilir.
Customers(CustomerID, Name, Email)Orders(OrderID, CustomerID, OrderDate, Total)Burada CustomerID, müşterinin adı gibi değişebilecek bir şey değil; benzersiz ve sabit bir tanımlayıcıdır.
Yabancı anahtar, başka bir tablodaki bir birincil anahtara referans veren alandır. Orders tablosundaki CustomerID, Customers.CustomerID'ye işaret eder.
Bu yapı, müşteri detaylarını her siparişte tekrar etmeyi önler. Name ve Email gibi alanları her sipariş satırına kopyalamak yerine bir kere saklayıp siparişleri doğru müşteriye bağlarsınız.
Veritabanı tabloların nasıl ilişkilendirileceğini bildiği için onları join yaparak günlük soruları yanıtlayabilirsiniz:
Böylece aynı gerçeklerin birden çok kopyasını tutmak yerine sorgu zamanı birleştirme ile eksiksiz sonuçlar elde edersiniz.
İlişkisel veritabanları referans bütünlüğü uygulayabilir: bir sipariş, var olmayan bir müşteriye referans veremez. Bu, yetim kayıtları (geçerli müşterisi olmayan siparişler) önler ve bağlantıları kıracak kazara silmeleri engeller.
Anahtarlar, ilişkiler ve bütünlük kuralları uygulandığında raporlar operasyonlarla çelişmeyi bırakır. Toplamlar çoğaltılmış müşteri satırları yüzünden değişmez ve destek ekipleri eksik veya eşleşmeyen kimliklerden kaynaklanan “gizemli hataların” peşinden koşmak yerine asıl işe odaklanır.
Normalizasyon temelde aynı gerçeğin birden çok kopyasını önleyecek şekilde veriyi yapılandırmaktır. Bu, aynı bilginin birden fazla yerde kopyalanmasının neden olduğu senkronizasyon sapmalarını azaltır.
Bir iş uygulamasında siparişleri sakladığınızı düşünün. Her sipariş satırı müşteri adresini içeriyorsa, adres tekrar tekrar yazılır. Müşteri taşındığında herkesin geçmiş ve gelecek sipariş kayıtlarını güncellemesi gerekir (ya da uygulama hangi satırların güncelleneceğini tahmin etmeli). Birini atlarsanız, raporlarda aynı müşteri için iki farklı “gerçek” görünür.
Normalizasyon ile müşterinin adresini genellikle Customers tablosunda bir kez saklarsınız, ardından her sipariş müşteri kimliğiyle referans verir. Artık tek bir yer güncellendiğinde her sipariş tutarlı kalır.
Bazı yapı taşları çoğu iş sisteminde görülür:
order_status: “Pending”, “Shipped”, “Cancelled”). Yazım hatalarını azaltır ve değişiklikleri kontrol altına alır.OrderItems tablosu bunları temiz şekilde bağlar.Daha fazla normalizasyon genelde tutarlılığı artırır, ama daha fazla tablo ve daha fazla join demektir. Aşırı normalizasyon bazı sorguları yazmayı zorlaştırabilir ve yavaşlatabilir—bu yüzden ekipler genellikle “temiz yapı” ile uygulamanın raporlama ve performans ihtiyaçları arasında bir denge kurar.
İlişkisel veritabanları sadece veriyi düzenli saklamakla kalmadı—aynı zamanda onu ortak bir şekilde sorgulamayı sağladı. SQL (Structured Query Language), tabloları sorgulamak için ortak bir dil sunarak her rapor için özel programlar yazma ihtiyacını azalttı.
SQL yaygınlaşmadan önce, veri sorgulama genellikle satıcıya özgü komutlar veya sadece birkaç kişinin anlayabildiği tek seferlik betikler gerektiriyordu. Standart bir sorgu dili bu sürtüşmeyi azalttı. Analistler, geliştiriciler ve raporlama araçları aynı temelde veritabanıyla konuşabiliyordu.
Bu standartlaşma ekipler arasındaki sürtüşmeyi azalttı. Finans için yazılmış bir sorgu operasyon tarafından tekrar kullanılabiliyordu. Bir raporlama aracı farklı veritabanlarına minimal değişiklikle bağlanabiliyordu. Zamanla SQL becerileri işler ve sektörler arasında taşınabilir hale geldi—bu da yayılmasını hızlandırdı.
SQL, gerçek iş sorularına yakın olduğu için parlıyor:
Bunlar temelde filtreleme, sıralama, gruplayıp ilişkili verileri birleştirme sorularıdır—SQL tam da bunun için tasarlandı.
SQL yaygınlaştıkça etrafında bir ekosistem oluştu: BI panoları, zamanlanmış raporlar, elektronik tablo bağlayıcıları ve daha sonra veri ambarları ile ETL araçları. Şirketler özel analitik sistemler ekleseler bile, operasyonel veri ile karar verme arasındaki köprü çoğunlukla SQL olarak kaldı—çünkü herkesin güvendiği bir dildi.
Bir iş uygulaması "güvenilir" hissettiriyorsa, genellikle veritabanının değişiklikleri güvenli bir şekilde yönetebilmesindendir—özellikle para, stok ve müşteri taahhütleri söz konusuysa.
Bir çevrimiçi sipariş hayal edin:
Bir işlem, bu güncellemelerin hepsini bir iş birimi olarak ele alır. Bir yerde hata olursa (ödeme reddedildi, sistem çöktü, stokta yok), veritabanı geri alarak kayıtları temiz ve tutarlı bırakabilir—"ödenmiş ama sipariş yok", negatif stok veya eksik fatura gibi durumlar olmaz.
İşletmeler ilişkisel veritabanlarına güven duyar çünkü çoğu ACID davranışını destekler—temel kurallar kaydı güvenilir kılar:
İş yazılımında birçok kişi aynı anda çalışır: satış temsilcileri teklif verir, depodakiler sipariş toplar, finans kapanışı yapar, destek iadeler uygular. Güçlü eşzamanlılık kontrolü yoksa iki kişi son ürünü satabilir veya birbirinin düzenlemelerini üzerine yazabilir.
Veri bütünlüğü pratikte şu demektir: finansal toplamlar tutar, stok sayıları gerçekliği yansıtır ve uyumluluk raporlaması ne olduğunuzu ve ne zaman yaptığınızı izlenebilir biçimde gösterir. Bu yüzden RDBMS "kayıt sistemi" verileri için varsayılan yerdir.
Çoğu iş uygulaması her tıklamada "Bu çeyrekte ne oldu?" sorusunu yanıtlamaya çalışmaz. Genellikle basit, sık işleri yapar: fatura oluştur, sevkiyat durumunu güncelle, stoğu rezerve et veya ödeme kaydet. Bu modele OLTP (Online Transaction Processing) denir—gün boyunca birçok küçük okuma ve yazma.
OLTP'de amaç hızlı, tutarlı etkileşimlerdir: "bu müşteriyi bul", "bu satırı ekle", "bu siparişi öde olarak işaretle". Sorgular genellikle verinin küçük bir bölümüne dokunur ve hızlı dönmelidir.
Analitik iş yükleri farklıdır: daha az sorgu ama çok daha ağır olanlar—toplamalar, geniş aramalar ve büyük tarih aralıklarında joinler. Birçok kuruluş OLTP'yi RDBMS'de tutar ve analitiği ayrı sistemlerde veya replikalarda çalıştırır, böylece günlük operasyonlar yavaşlamaz.
İndeks, bir tablonun içeriği için içindekiler dizini gibi düşünülebilir. customer_id = 123 filtresini ararken veritabanı tüm satırları okumak yerine doğrudan eşleşen satırlara atlayabilir.
Bedel: indekslerin bakımı gerekir. Her ekleme/güncelleme bir veya daha fazla indeksi de güncelleyebilir; bu yüzden çok fazla indeks yazmaları yavaşlatır ve depolamayı artırır. Sanat, en çok aranan ve join yapılan alanları indekslemektir.
Veri ve trafik arttıkça ilişkisel veritabanları sorgu planlaması (sorguyu verimli şekilde yürütme yolları seçme), kısıtlar (veriyi geçerli tutup temizleme projelerini pahalı hale getirmeme) ve yedekleme ile zaman noktasına geri alma gibi operasyonel araçlara dayanır. Bu "sıkıcı" özellikler genellikle günlük sistemlerin güvenilir kalmasını sağlar.
Sık kullanılan filtreler/joinler için eksik indeks klasik problemdir: 10k satırdayken hızlı olan sayfalar 10M olduğunda yavaşlar.
Uygulama kalıpları da önemlidir. N+1 sorguları (öğe listesini çekmek için bir sorgu, sonra her öğe için detay çekmek üzere bir sorgu daha) veritabanını boğabilir. Ve gereksiz joinler—"her ihtimale karşı" birçok tabloyu birleştirmek—gereksiz işi tetikler. Sorguları amaçlı tutmak ve gerçek üretim benzeri verilerle ölçmek genellikle en büyük kazançları getirir.
ERP ve CRM, ilişkisel veritabanlarını sadece popüler oldukları için benimsemedi—tablolar, anahtarlar ve ilişkilerin zorladığı tutarlılığa ihtiyaçları vardı.
Çoğu temel iş süreci yapılandırılmış ve tekrarlanabilirdir: bir müşteri sipariş verir, fatura düzenlenir, ödeme kaydedilir, ürün toplanır, sevk edilir ve iade edilir. Her adım doğal olarak satırlarda ve sütunlarda tanımlanabilecek varlıklara (müşteriler, ürünler, faturalar, ödemeler, çalışanlar, konumlar) karşılık gelir.
İlişkisel tasarım ayrıca çapraz kontrolleri kolaylaştırır. Bir fatura gerçek bir müşteri olmadan var olamaz; bir sevkiyat satırı gerçek bir ürüne referans vermeli; bir ödeme faturaya bağlanmalıdır. ERP sistemleri (finans, tedarik, stok) ve CRM yazılımları (hesaplar, kişiler, fırsatlar, destek kayıtları) bu "bu şununla ilişkili olmalı" kurallarına dayanır.
Kuruluşlar büyüdükçe bir seçimle karşılaştılar:
Her iki yaklaşım da açık şemalardan faydalanır: alanlar ve ilişkiler belirli olduğunda müşteri kimlikleri, ürün kodları ve muhasebe boyutlarını senkronize etmek daha kolaydır.
ERP ve CRM tedarikçileri ilişkisel temellerde uzlaşınca işletmeler beceri taşınabilirliği kazandı. SQL bilen bir analisti işe almak ve operasyon ekiplerini standart raporlar çalıştırmaya eğitmek, tescilli sorgu araçlarını öğretmekten daha kolay oldu.
Bu standartlaşma uzun vadeli maliyetleri düşürdü: daha az özel veri çıktısı, daha çok yeniden kullanılabilir raporlama kalıbı ve yöneticiler, danışmanlar ve iç ekipler arasında daha basit işler devri. Birçok şirket için bu, ilişkisel veritabanlarını teknik bir tercihten operasyonel bir varsayılan haline getirdi.
İlişkisel veritabanları sadece veri modellemesiyle kazanmadı—aynı zamanda kuruluşların üretim sistemlerini nasıl yürüttüğüne de uydu. Erken dönemden itibaren RDBMS ürünleri planlı yedeklemeler, kullanıcı rolleri, sistem katalogları, loglar ve üretim verilerini güvenli ve hesap verebilir tutmayı pratik hale getiren araçlarla geldi.
Bir iş veritabanı, kurtarılabilme yeteneği kadar güvenilirdir. RDBMS araçları tam yedekler, artımlı yedekler ve işlem günlükleri kullanarak zaman noktasına geri alma gibi yaklaşımları standartlaştırdı. Bu, ekiplerin geri yükleme prosedürlerini test edebilmesini, belgelerle desteklemesini ve olaylarda tekrarlanabilir şekilde uygulamasını sağladı—bunun önemi bordro, faturalama, stok ve müşteri kayıtları için kritiktir.
Ayrıca izleme operasyonun normal bir parçası haline geldi: depolama büyümesini, yavaş sorguları, kilitlenme yarışını ve replikasyon sağlığını takip etmek. Sorunlar ölçüldüğünde yönetilebilir hale gelir.
Çoğu RDBMS platformu erişim kontrolünü birinci sınıf özellik olarak sundu. Paylaşılan bir parolayı vermek yerine yöneticiler hesap oluşturur, bunları rollere ayırır ve veritabanı, tablo veya hatta satır seviyesinde izinler verir (sisteme bağlı olarak).
İki yönetim temeli özellikle önemlidir:
Bu yapı, uyumluluk çabalarını günlük işi sürekli istisnalar haline getirmeden destekler.
RDBMS denetimi—loglar, sistem tabloları ve bazen yerleşik denetim özellikleri aracılığıyla—"kimin neyi, ne zaman değiştirdiğini" yanıtlamaya yardımcı olur. Bu hata ayıklama, güvenlik soruşturmaları ve düzenlenmiş iş akışları için değerlidir.
Değişiklik tarafında ise olgun ekipler tekrarlanabilir göçler kullanır: şemayı değiştiren betikler versiyon kontrolünde gözden geçirilir ve ortamlar arasında tutarlı uygulanır. Onaylar ve geri alma planlarıyla birleştiğinde bu, gece yarısı yapılan acil düzeltmelerin raporlamayı veya entegrasyonları sessizce bozma riskini azaltır.
Yönetim uygulamaları işletmelerin standartlaştırabileceği kalıplara evrildi: replikasyon yedeklilik için, failover yüksek erişilebilirlik için ve bir veri merkezinin (veya bulut bölgesinin) tamamının kaybolabileceği varsayılarak düzenlenen felaket kurtarma kurulumları. Bu operasyonel yapı taşları ilişkisel veritabanlarını temel sistemler için güvenli bir varsayılan haline getirdi.
Bulut hizmetleri ilişkisel veritabanlarını ortadan kaldırmadı; daha çok bunları nasıl çalıştırdığımızı değiştirdi. Sunucu satın almak, veritabanı yazılımı kurmak ve bakım pencerelerini planlamak yerine birçok şirket, sağlayıcının operasyonel işleri üstlendiği yönetilen RDBMS hizmetlerini kullanıyor.
Yönetilen ilişkisel veritabanları genellikle otomatik yedeklemeler, zaman noktasına geri alma (hata öncesi anahtar bir anahtar noktasına dönme), yerleşik yamalama ve izleme içerir. Birçok iş uygulaması için bu, daha az gece yarısı kurtarma tatbikatı ve daha öngörülebilir felaket planlaması anlamına gelir.
Ölçeklendirme de daha esnek hale geldi. CPU, bellek ve depolamayı birkaç ayarla artırmak genellikle donanım göçünden daha kolaydır. Bazı platformlar ayrıca raporlamayı ve ağır aramaları sipariş girişi veya müşteri desteğini yavaşlatmadan yürütmek için okuma replikalarını destekler.
Replikasyon, veritabanının kopyalarını eş tutmak demektir. Yüksek erişilebilirlik, birincil başarısız olduğunda bekleyen bir kopyanın devreye girmesini sağlar. Bu, ödemelerin alınması, sevkiyatların kaydedilmesi veya stok güncellemelerinin devam etmesi gereken sistemler için önemlidir.
İşletmeler küresel kullanıcılara hizmet verdikçe gecikme gerçek bir sorun olur: müşteriler uzaklaştıkça her istek daha yavaş hissedilir. Aynı zamanda mikroservisler ve olay odaklı sistemler, tek bir "büyük uygulamayı" birçok küçük hizmete böler; her hizmetin kendi veri ihtiyaçları ve sürüm döngüleri olur.
Birçok ekip çekirdek kayıtlar (müşteriler, faturalar, bakiyeler) için RDBMS'i korur ve belirli işler için başka araçlar ekler—metin aramalar için arama motorları, hız için önbellekler veya geniş raporlama için analitik ambarlar. Bu, veri bütünlüğünün önemli olduğu yerlerde RDBMS'i tutarken yeni performans ve entegrasyon ihtiyaçlarını karşılamayı sağlar. Tutarlılık hakkında daha fazla bilgi için ilgili blog yazılarına bakabilirsiniz.
Pratikte, bu aynı zamanda ekiplerin yeni dahili araçlar inşa etme şeklini de biçimlendiriyor. Koder.ai gibi platformlar “ilişkisel çekirdek + modern uygulama” yaklaşımını benimser: sohbet arayüzüyle React ön yüzleri, Go backend'ler ve PostgreSQL destekli kayıt sistemleri oluşturabilir, ardından anlık görüntüler ve geri alma ile şemalar, göçler veya iş akışları değiştiğinde güvenle yineleyebilirsiniz.
İlişkisel veritabanları her iş yükü için mükemmel değildir. Güçlü yanları—güçlü yapı, tutarlılık ve öngörülebilir kurallar—verinin veya kullanım deseninin tablolarla iyi uyuşmadığı durumlarda kısıtlayıcı olabilir.
Bazı senaryolar RDBMS modeline ters olabilir:
NoSQL sistemleri, esnek veri şekillerini depolamayı ve yatay ölçeği kolaylaştırdığı için popüler oldu. Birçokları tutarlılık garantilerinin veya sorgu zenginliğinin bir kısmını ödün vererek daha basit dağıtım, daha hızlı yazmalar veya kolay şema evrimi elde eder—bu, belirli ürünler, analitik boru hatları ve yüksek hacimli olay yakalama için kullanışlıdır.
Modern iş yığını şu kombinasyonları sık kullanır:
Para, sipariş, stok, müşteri hesapları veya açık kurallar ve güvenilir güncellemeler gerektiren bir şeyi takip ediyorsanız, RDBMS genellikle en güvenli başlangıç noktasıdır. Alternatifleri yalnızca iş yükü gerçekten onları gerektirdiğinde kullanın—sadece trend olduğu için değil.
İş yazılımlarında müşteriler, siparişler, faturalar, ödemeler ve stok gibi öğeler için tek bir gerçek kaynak gerekir.
İlişkisel veritabanları, birçok kullanıcı ve süreç aynı anda okuma/yazma yaptığında kayıtları tutarlı tutacak şekilde tasarlanmıştır—böylece raporlar ile operasyonlar uyuşur ve "sayılar" uzlaşır.
İlişkisel veritabanı, verileri kurallı bir şekilde saklayan tablolar (satırlar ve sütunlar) kullanır.
Tabloları birbirine bağlamak için anahtarlar kullanılır (örneğin Orders.CustomerID Customers.CustomerID'ye referans verir) böylece veritabanı ilgili kayıtları kopyalamadan güvenilir şekilde ilişkilendirebilir.
Dosya tabanlı depolama, birden çok departmanın aynı verilere ihtiyaç duyduğu durumlarda yetersiz kalır.
Yaygın sorunlar şunlardır:
Birincil anahtar (primary key), bir satırı tekil ve sabit şekilde tanımlayan bir kimliktir (ör. CustomerID).
Yabancı anahtar (foreign key), başka bir tablodaki bir birincil anahtara işaret eden alandır (ör. Orders.CustomerID -> Customers.CustomerID).
Birlikte, "gizemli bağlantıları" önler ve veriyi güvenilir şekilde birleştirip sorgulamanızı sağlar.
Referans bütünlüğü, veritabanının geçerli ilişkileri zorunlu kılması demektir.
Pratikte bunun sağladıkları:
Normalizasyon, aynı gerçeği birden çok yerde depolamamayı hedefleyen tablo tasarımıdır.
Sık görülen örnek: müşterinin adresini Customers tablosunda bir kez saklayıp, siparişlerde CustomerID ile referans verirsiniz. Böylece tek bir güncelleme her yerde geçerli olur ve "kopyalar arasındaki sapma" azalır.
SQL, iş verilerini standart bir şekilde sorgulanabilir kıldı; satıcıdan bağımsız ortak bir dil oluşturdu.
Filtreleme, gruplayıp özetleme ve tabloları birleştirme gibi işlemler SQL ile doğrudan yapılabildiği için finans, operasyon ve raporlama gibi ekiplerin işini kolaylaştırdı.
Bir işlem (transaction), birden çok güncellemeyi tek bir bütün olarak ele alır: ya hepsi başarılı olur ya hiçbiri.
Sipariş akışında bu; sipariş oluşturma, ödemenin kaydı ve stoktan düşme gibi adımların tek seferde güvenle yapılmasını sağlar. Bir yerde hata olursa veritabanı eski temiz haline döndürebilir.
OLTP (Online Transaction Processing), birçok küçük, hızlı okuma/yazma işleminden oluşan günlük iş yüklerini tanımlar.
İlişkisel veritabanları, indeksler, eşzamanlılık kontrolü ve öngörülebilir sorgu yürütme gibi özelliklerle bu tip iş yükleri için uygundur—bu sayede çekiş, fatura, güncelleme gibi temel işler günlük yük altında güvenli çalışır.
İlişkisel veritabanları şu durumlarda zorlanabilir:
Birçok ekip hibrit bir yaklaşım kullanır: RDBMS kaynak veri olarak kalır; arama, önbellek veya analitik için uzmanlaşmış sistemler eklenir.