Veritabanı Şeması Nedir?

“Şema” kelimesinin iki kullanımı

Gündelik kullanımda veritabanı şeması, verinin bütün yapısını ifade eder: tablolar, sütunlar, tipler, ilişkiler, kısıtlar, indeksler ve görünümler (view). Bazı veritabanlarında ise SCHEMA ayrıca bir isim alanıdır. PostgreSQL'de tablolar public.orders veya billing.invoices gibi şemalar altında gruplanır ve yetkiler şema bazında verilebilir; MySQL'de ise SCHEMA, DATABASE ile eş anlamlıdır. Bir de karıştırılmaması gereken üçüncü anlam vardır: SEO'da “schema” denildiğinde genellikle Schema.org sözlüğüyle yazılan yapılandırılmış veri kastedilir ve bunun veritabanı yapısıyla ilgisi yoktur.

İş kuralları şemada yaşar

İyi bir şema yalnızca veriyi saklamaz, hangi verinin geçerli olduğunu da söyler. Aşağıdaki tanımdaki her satır bir iş kuralıdır:

CREATE TABLE invoices (
  id           bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  customer_id  bigint NOT NULL REFERENCES customers (id),
  number       text NOT NULL UNIQUE,
  currency     char(3) NOT NULL DEFAULT 'TRY',
  amount       numeric(12,2) NOT NULL CHECK (amount >= 0),
  status       text NOT NULL CHECK (status IN ('draft', 'issued', 'paid', 'void')),
  issued_at    timestamptz
);

• Birincil anahtar her faturayı tekil olarak tanımlar; yabancı anahtar var olmayan bir müşteriye fatura kesilmesini engeller.
• UNIQUE aynı fatura numarasının iki kez kullanılmasını, CHECK negatif tutarı ve tanımsız durumları reddeder.
• Para için numeric seçilmesi bilinçlidir: kayan noktalı tipler (float) ondalık değerleri tam temsil edemez ve kuruş hataları üretir.
• timestamptz zamanı saat dilimi bilgisiyle saklar; farklı saat dilimlerindeki sunucu ve kullanıcılar aynı anı aynı şekilde yorumlar.

Bu kuralların uygulama kodunda da bulunması doğaldır, ama son savunma hattı veritabanıdır: başka bir servis, elle çalıştırılan bir betik veya hatalı bir sürüm de aynı kurallara takılır.

Normalizasyon ve bilinçli denormalizasyon

Normalizasyonun özü, her bilginin tek bir yerde durmasıdır. Müşterinin şehrini her sipariş satırına kopyalamak, şehir değiştiğinde kayıtların bir kısmının güncellenip bir kısmının eski kalması riskini doğurur. Bu yüzden müşteri bilgisi kendi tablosunda tutulur, siparişler ona anahtarla başvurur. Ancak her tekrar hata değildir. Siparişteki teslimat adresi, müşteri sonradan taşınsa bile sipariş anındaki hâliyle kalmalıdır; bu bir kopya değil, tarihsel bir kayıttır. Okuma performansı için yapılan denormalizasyon (ör. bir ürünün yorum sayısını ayrı bir sütunda tutmak) da meşrudur, yeter ki kopyanın nasıl güncel tutulacağı açıkça tasarlansın.

“Şemasız” veritabanı diye bir şey yok

İlişkisel veritabanları şemayı yazma anında uygular (schema-on-write). Birçok NoSQL sistemi ise kayıtları önceden tanımlı bir yapı olmadan kabul eder ve “şemasız” diye anılır. Oysa şema ortadan kalkmaz, uygulama koduna taşınır: kodun bir dokümanda hangi alanların bulunacağını varsayması da bir şemadır. Fark, bu şemayı kimin denetlediğidir. Aynı koleksiyonda üç farklı biçimde kaydedilmiş doküman, raporlama sırasında ortaya çıkan klasik bir sorundur. Bazı doküman veritabanları bu yüzden isteğe bağlı şema doğrulaması sunar.

Şemayı yaşatmak

• Şemayı elle değil, depoda sürümlenen veritabanı migrasyonlarıyla değiştirin; böylece her ortam aynı yapıya sahip olur.
• İsimlendirmede tutarlı olun: tablo adlarında tekil veya çoğul, sütunlarda snake_case gibi bir kural seçip her yerde uygulayın.
• Bir ORM kullanılıyorsa model tanımları ile gerçek şemanın ayrışmadığını CI'da düzenli olarak kontrol edin.
• Sorgulanan ve birleştirilen sütunlara gereken indeksleri şema tasarımının parçası olarak düşünün; sonradan eklemek büyük tablolarda daha zahmetlidir.