Veritabanı Nedir? Tablolardan Sorguya Veri Yönetimi

Veritabanı ile DBMS arasındaki görev farkı

Veritabanı, verilerin düzenlenmiş hâlde bulunduğu yapıdır. Örneğin bir okul sistemindeki öğrenciler, dersler ve notlar; bir mağaza sistemindeki ürünler, müşteriler ve siparişler veritabanında tutulabilir. Veritabanı tek başına yalnızca 'bilgi deposu' olarak düşünülmemelidir; verinin hangi düzende saklanacağı ve nasıl bulunacağı da tasarımın parçasıdır.

DBMS, yani veritabanı yönetim sistemi, bu yapıyla çalışan yazılım katmanıdır. Yeni kayıt ekleme, mevcut kaydı bulma, değiştirme ve silme gibi işlemler DBMS aracılığıyla yürütülür. Kullanıcının ekranda gördüğü web veya mobil arayüz ise çoğu zaman doğrudan veritabanının kendisi değildir. İstemci uygulama bir istek gönderir, arka uç bu isteği işler ve uygun veriyi DBMS üzerinden alır.

Bu ayrım önemlidir: 'Veritabanı veriyi saklar' ifadesi yapıyı; 'DBMS veritabanını yönetir' ifadesi ise yönetim yazılımını anlatır. Kaynaklarda veritabanının organize ve yapılandırılmış bir sistem olduğu, DBMS'nin de verileri düzenleme ve işleme görevini üstlendiği vurgulanır.

İlişkisel veritabanında satır, sütun ve kayıt nasıl okunur?

İlişkisel veritabanlarında bilgiler genellikle tablolarla düzenlenir. Kaynak 3'te de belirtildiği gibi bu model, verileri satır-sütun mantığıyla organize eder.

Bir tablonun sütunları, hangi özelliklerin tutulacağını gösterir. Örneğin Urunler tablosunda urun_id, ad, fiyat ve stok sütunları bulunabilir. Her satır ise tek bir ürüne ait kaydı temsil eder. urun_id gibi bir alan, kayıtları birbirinden ayırt etmek için kullanılabilir. Böylece 'kırmızı defter' ifadesiyle belirsiz bir arama yapmak yerine belirli bir kayıt ve onun özellikleri üzerinden işlem yapılır.

Örnek bir tablo şöyle düşünülebilir:

Urunler

• 101 | Matematik Defteri | 45 TL | 12
• 102 | Geometri Kalemi | 18 TL | 0
• 103 | Fen Bilimleri Kitabı | 90 TL | 7

Buradaki dört sütun sırasıyla ürün kimliği, ürün adı, fiyat ve stok bilgisini temsil eder. Bir büyüklüğü yorumlarken yalnızca değerine bakmak yeterli değildir; hangi sütuna ait olduğunu ve hangi koşulla karşılaştırıldığını da bilmek gerekir. Örneğin stok değeri 0 olan ürün için 'kayıt yok' değil, 'ürün kayıtlı ancak stokta bulunmuyor' sonucu çıkarılır.

Birden fazla tablo kullanıldığında tablolar arasında ilişkiler kurulabilir. Örneğin Musteriler tablosu müşteriyi, Siparisler tablosu siparişi, SiparisDetaylari tablosu da siparişteki ürünleri tutabilir. Bu yaklaşım, aynı müşteri veya ürün bilgisinin her sipariş satırında tekrar tekrar yazılmasını azaltmaya yardımcı olur; ancak ilişkinin doğru alanlar üzerinden kurulması gerekir.

Bir veritabanı işlemi ekrandan sonuca nasıl ulaşır?

Bir uygulamadaki işlem basit görünse de arka planda birkaç aşama bulunur. İlk aşamada kullanıcı bir veri girişi yapar veya arama ölçütü belirler. Örneğin mağaza sayfasında stokta bulunan ürünlerin listelenmesi istenir.

İkinci aşamada uygulamanın arka uç kısmı bu isteği veritabanı yönetim sistemine iletir. İstek, belirli sütunları ve koşulları belirtir: ürün adı, fiyat ve stok alanları alınacak; stok değeri 0'dan büyük olan kayıtlar seçilecektir.

Üçüncü aşamada DBMS, veritabanındaki uygun kayıtları bulur ve sonucu uygulamaya döndürür. Uygulama da sonucu kullanıcı arayüzünde gösterir. Bu nedenle veritabanı, web uygulamasının görünen sayfasıyla aynı şey değildir. Web uygulamasının ne olduğunu ve bu yapının arka uçla ilişkisini anlamak için web uygulamalarının çalışma biçimine bakılabilir.

Aynı mantık ekleme ve güncelleme için de geçerlidir. Yeni ürün kaydedildiğinde yeni bir kayıt oluşturulur. Fiyat değiştiğinde ilgili ürün kaydının fiyat alanı güncellenir. Ürün satıldığında ise stok bilgisi yeni duruma göre değiştirilir. Değişiklik yalnızca ekranda yapılır ve kalıcı veri kaynağına aktarılmazsa kullanıcı sayfayı yenilediğinde eski bilgiyle karşılaşabilir.

Bu süreçte erişim yetkisi de önemlidir. Her kullanıcıya tüm kayıtları değiştirme izni verilmesi gerekmez. Örneğin bir müşterinin ürün fiyatını değiştirmesi beklenmezken, yetkili personelin ürün bilgilerini güncellemesine izin verilebilir. Burada ayrıntılı güvenlik mimarisi kullanılan DBMS ve uygulamaya göre değişir; temel fikir, veriye erişimin işlem türüne ve kullanıcı rolüne göre sınırlandırılmasıdır.

Veri bütünlüğü neden yalnızca 'doğru kayıt' anlamına gelmez?

Veri bütünlüğü, verinin yalnızca mevcut olmasını değil, anlamlı ve birbiriyle çelişmeyecek biçimde tutulmasını ifade eder. Örneğin aynı ürünün bir tabloda 90 TL, başka bir tabloda 95 TL görünmesi kullanıcıya hangi fiyatın geçerli olduğunu belirsiz bırakır.

Bütünlük için önce alanların anlamı netleştirilmelidir. Fiyat alanı parasal bir değeri, stok alanı mevcut adet bilgisini, urun_id ise ürünü ayırt eden kimliği göstermelidir. '12' değerinin stok mu, satış adedi mi olduğu belirtilmemişse sayı tek başına işe yaramaz.

İkinci olarak aynı olayın birden fazla kaynağa gereksiz biçimde yazılması dikkat ister. Bir müşterinin adresi birçok sipariş satırında tekrarlandığında müşteri adresi değiştiğinde eski kayıtların bir kısmı güncellenmeyebilir. Bu tür tasarım sorunları, verinin farklı yerlerde farklılaşmasına yol açabilir. Tabloların görevlerini ayırmak ve ilişkileri açık kurmak bu riski azaltır.

Üçüncü olarak silme ve güncelleme işlemlerinin kapsamı kontrol edilmelidir. Bir ürünün stokunu güncellemek, ürünün tüm kaydını silmek anlamına gelmez. Benzer şekilde bir müşterinin siparişini silmek, müşterinin hesabını da otomatik olarak silmeyi gerektirmeyebilir. Bu karar, uygulamanın veri modeline ve iş kuralına bağlıdır.

Veritabanlarının önemli olmasının nedeni yalnızca hız değildir. Kaynaklarda hız, düzenli sorgulama, veri bütünlüğü ve büyük iş verilerini işleyebilme gibi amaçlar öne çıkar. Ancak 'milyonlarca kaydı her durumda aynı hızla işler' gibi bir sonuç çıkarılmamalıdır; performans, veritabanı yapısına, sorgulara, donanıma ve kullanılan sisteme bağlıdır.

Çözümlü örnek: stokta bulunan ürünleri seçme

Verilenler: Urunler tablosunda şu üç kayıt olsun:

• 101 | Matematik Defteri | 45 TL | stok 12
• 102 | Geometri Kalemi | 18 TL | stok 0
• 103 | Fen Bilimleri Kitabı | 90 TL | stok 7

İstenen: Stokta bulunan ürünleri listelemek.

Çözüm adımları:

1. Önce 'stokta bulunma' koşulunu sayısallaştırırız. Bu örnekte stokta bulunan ürün için stok değerinin 0'dan büyük olması gerekir: $stok > 0$.
2. Her satırın stok değerini koşulla karşılaştırırız. Matematik Defteri için $12 > 0$ olduğundan kayıt seçilir.
3. Geometri Kalemi için $0 > 0$ yanlış olduğundan kayıt seçilmez. Bu ürün veritabanında vardır; yalnızca mevcut stok miktarı yoktur.
4. Fen Bilimleri Kitabı için $7 > 0$ olduğundan kayıt seçilir.

Sonuç:

• Matematik Defteri — 45 TL — stok 12
• Fen Bilimleri Kitabı — 90 TL — stok 7

Bu örnekte kritik nokta, 'kayıt var' ile 'stok var' ifadelerinin farklı olmasıdır. Ürün tablosunda üç satır bulunur; stok filtresinden sonra iki satır sonuç olarak döner. İstenirse fiyat da ayrıca karşılaştırılabilir. Örneğin stokta bulunan ve fiyatı 50 TL'den düşük ürün koşulu $stok > 0$ ve $fiyat < 50$ olur. Bu durumda yalnızca Matematik Defteri seçilir.

Çözümlü örnek: ATM işleminde hangi veriler değişir?

Verilenler: Bir hesabın işlem öncesi bakiyesi 1.000 TL olsun. ATM'den 250 TL çekilmek isteniyor. İşlem için hesap sahibinin kimliği doğrulanmış ve çekilecek tutarın bakiye içinde olduğu varsayılıyor.

Çözüm adımları:

1. DBMS önce doğru hesap kaydını bulmalıdır. Bunun için hesap numarası veya sisteme göre başka bir benzersiz kimlik kullanılır.
2. Hesabın mevcut bakiyesi kontrol edilir: 1.000 TL, çekilmek istenen 250 TL'den büyüktür.
3. İşlem başarılı kabul edilirse yeni bakiye hesaplanır: $yeni\\ bakiye = 1.000 - 250 = 750\\ TL$.
4. Hesap bakiyesi güncellenir. Uygulamanın tasarımına bağlı olarak işlem geçmişine ayrıca 250 TL'lik çekim kaydı eklenebilir.
5. ATM, işlem sonucunu kullanıcıya gösterir ve para verme sürecini yürütür.

Sonuç: Hesap bakiyesi 750 TL olur; işlem geçmişi tutuluyorsa çekim hareketi de ayrı bir kayıt olarak saklanır.

Bu örnek, tek bir sayının değiştirilmesinden fazlasını gösterir. Hesap kaydının doğru seçilmesi, bakiyenin kontrol edilmesi ve işlem sonucunun tutarlı biçimde kaydedilmesi gerekir. Bakiye güncellenip işlem geçmişi kaydedilmezse veya işlem geçmişi kaydedilip bakiye değişmezse sistemin iki bölümünde çelişki oluşabilir. Gerçek bankacılık sistemlerinin ayrıntıları kullanılan yazılım ve güvenlik süreçlerine göre değişir; burada yalnızca veritabanı işlem mantığı gösterilmiştir.

Sık yapılan hatalar ve karıştırılan kavramlar

1. Veritabanını dosya klasörü sanmak: Dosya depolama ile yapılandırılmış veri yönetimi aynı şey değildir. İlişkisel veritabanlarında kayıtlar belirli sütunlar ve satırlar içinde tutulur; diğer veritabanı türlerinde veri modeli ve sorgulama biçimi değişebilir.

2. Veritabanı ile DBMS'yi eş anlamlı kullanmak: Veritabanı verinin düzenidir; DBMS bu düzen üzerinde işlem yapan yönetim katmanıdır.

3. Her veritabanını ilişkisel kabul etmek: Satır-sütun düzeni özellikle ilişkisel veritabanı modelinin temel özelliğidir. 'Veritabanı' genel bir kavramdır; ilişkisel yapı bunun bir türüdür.

4. Kayıt sayısını performansın tek ölçütü sanmak: Bir sistemin hızlı olup olmadığı yalnızca veri miktarına bakılarak belirlenemez. Sorgunun yapısı, veri düzeni ve kullanılan altyapı da etkilidir.

5. Sıfır ile boş değeri karıştırmak: Stok değerinin 0 olması ürünün kayıtlı fakat mevcut olmadığını anlatabilir. Boş değer ise bilginin girilmemiş veya uygulanamaz olduğunu gösterebilir; bu ikisinin anlamı tasarıma göre farklıdır.

6. Silinen verinin otomatik olarak geri geleceğini düşünmek: Geri yükleme, önceden alınmış yedeklere ve sistemin kurtarma olanaklarına bağlıdır. Yedekleme yapılmadıysa geri dönüş garanti edilemez.

7. Excel ile veritabanını yalnızca veri miktarıyla ayırmak: Excel tek başına basit listeler için kullanılabilir; veritabanı ise yapılandırılmış sorgular, ilişkili kayıtlar ve çok kullanıcılı uygulama ihtiyaçları için tasarlanır. Hangi aracın uygun olduğu veri modeline ve kullanım amacına bağlıdır.