Veritabanı yönetim sistemlerine giriş

Veritabanı dersi, dönemin geri kalanının dilini burada öğrendiğin bir giriş haftasıyla başlar. Sınavda bu hafta genelde tanım, sınıflandırma ve “hangisi?” sorularıyla çıkar: şema mı örnek mi, fiziksel mi mantıksal bağımsızlık mı, DDL mi DML mi, ACID’in hangi harfi. Kısa ama puan kaçırması kolay sorular. Aklında tutman gereken beş şey:

1. DBMS = veri + o veriye erişen programlar topluluğu. Amaç veriyi hem kolay hem güvenli tutmak.
2. Şema (schema) tasarımdır, örnek (instance) o anki veridir. Şema nadiren, örnek sürekli değişir.
3. Üç seviye: dış (external), mantıksal (logical), fiziksel (physical). Aradaki bağımsızlık iki türlüdür.
4. DDL yapıyı, DML veriyi değiştirir.
5. Transaction ya tamamen olur ya hiç olmaz. ACID bunu dört özellikle anlatır.

Dönem boyunca kullanacağımız veritabanı

Bütün haftalarda aynı küçük üniversite veritabanını kullanacağız. Böylece ER diyagramı, ilişkisel cebir, SQL ve normalizasyon aynı tablolar üzerinde konuşulacak ve her sorgunun sonucunu elle kontrol edebileceksin. Altı tablo var:

• department(dept_name, building, budget)
• instructor(inst_id, name, dept_name, salary)
• student(stu_id, name, dept_name, tot_cred)
• course(course_id, title, dept_name, credits)
• teaches(inst_id, course_id)
• takes(stu_id, course_id, grade)

Bu hafta sadece student tablosuna bakmamız yeterli:

Gizem’in bölümü henüz belli değil, bu yüzden NULL. Bu satır SQL haftasında bize çok iş görecek.

Dosya sistemi yerine neden DBMS?

Veritabanları yaygınlaşmadan önce kurumlar veriyi işletim sisteminin dosyalarında tutardı. Her bölüm kendi dosyasını ve kendi programını yazardı. Buna dosya işleme sistemi (file-processing system) denir. Bu yaklaşımın sınavda sayılması beklenen sorunları şunlar:

DBMS bu sorunların her birine merkezi bir çözüm getirir. Örneğin bütünlük kısıtları şemada bir kez yazılır ve DBMS her ekleme sırasında kontrol eder:

INSERT INTO course VALUES ('CS999', 'Test', 'CS', 9);     -- credits 1..6 olmalı
INSERT INTO student VALUES ('S9', 'Ilke', 'PHYS', 0);    -- PHYS bölümü yok
INSERT INTO student VALUES ('S1', 'Kopya', 'CS', 0);     -- S1 zaten var

CHECK constraint failed: credits BETWEEN 1 AND 6
FOREIGN KEY constraint failed
UNIQUE constraint failed: student.stu_id

Üç satırın üçü de reddedildi. Hiçbir uygulama programı bu kontrolleri yazmak zorunda kalmadı.

Veri modelleri

Veri modeli (data model), veriyi, veriler arası ilişkileri, anlamı ve kısıtları tarif etmek için kullanılan kavramlar bütünüdür. Derste karşına çıkacak olanlar:

• İlişkisel model (relational model): Veri tablolarda (relation) tutulur. Bugün en yaygın model, dersin merkezi. 3. haftada ayrıntısı var.
• Varlık-ilişki modeli (entity-relationship, ER): Tasarım aşamasında kullanılan, varlıklar ve aralarındaki ilişkilerle düşünen model. 2. hafta.
• Nesne tabanlı model (object-based): Nesne yönelimli programlamadaki kalıtım, kapsülleme gibi fikirleri veriye taşır.
• Yarı yapılandırılmış model (semi-structured): Aynı türdeki kayıtların farklı alanları olabilir. JSON ve XML bunun örneği.
• Tarihsel olarak ağ (network) ve hiyerarşik (hierarchical) modeller de vardı, bugün nadir.

Şema ve örnek

Programlamadan bir benzetme: şema (schema) bir değişkenin tip tanımı, örnek (instance) o değişkenin o anki değeri gibidir.

• student(stu_id, name, dept_name, tot_cred) bir şemadır. Kolonların adları, tipleri, anahtarlar, kısıtlar.
• Yukarıdaki 7 satırlık tablo, şu anki örnektir.

Bir satır eklediğinde örnek değişir, şema aynı kalır. Doğrulamada INSERT sonrası satır sayısı 7’den 8’e çıktı, kolon sayısı 4 olarak kaldı. Şemayı değiştirmek için ALTER TABLE gibi bir DDL komutu gerekir ve bu nadir yapılan bir iştir.

TUZAK · “schema” iki anlamda kullanılır. Bazen tek bir tablonun yapısı (relation schema), bazen tüm veritabanının tasarımı (database schema) kastedilir. Sınavda bağlamdan anla. Her iki durumda da karşıtı “instance”tır.

Üç seviyeli mimari ve veri bağımsızlığı

DBMS, kullanıcıyı ayrıntılardan korumak için veriyi üç soyutlama seviyesinde tarif eder:

   external (view) seviyesi     danışman ekranı   |  muhasebe ekranı   |  ...
              |                    (her kullanıcı grubu verinin bir parçasını görür)
   logical (conceptual) seviyesi   tüm tablolar, kolonlar, ilişkiler, kısıtlar
              |
   physical (internal) seviyesi    dosyalar, bloklar, index'ler, kayıt düzeni

• Fiziksel seviye (physical level): Veri diskte nasıl duruyor? Heap dosyası mı, sıralı dosya mı, hangi kolonda B+ ağacı var?
• Mantıksal seviye (logical level): Hangi veri var ve aralarında ne ilişki var? student, course, takes tabloları ve kısıtları. DBA ve tasarımcı bu seviyede çalışır.
• Dış seviye (view level): Belirli bir kullanıcının gördüğü kısım. Örneğin danışman sadece öğrencinin adını ve bölümünü görür, notları göremez.

Seviyeler arası eşlemeler (mapping) sayesinde bir seviyedeki değişiklik üsttekini bozmaz. Buna veri bağımsızlığı (data independence) denir.

İki örneği de gerçekten çalıştırdık. İndex eklenmeden önce SQLite sorgu planı tüm tabloyu tarıyordu, sonra index kullandı, ama sonuç satırları aynı kaldı:

SELECT name FROM student WHERE tot_cred > 40
plan önce : SCAN student
plan sonra: SEARCH student USING INDEX idx_cred (tot_cred>?)
sonuç (iki durumda da): Ada, Cem, Defne

Mantıksal bağımsızlık için student tablosu student_core ve student_credit diye ikiye bölündü, ardından ikisini birleştiren student adlı bir view tanımlandı. Eski sorgu hiç değiştirilmeden aynı sonucu verdi:

CREATE VIEW student AS
  SELECT c.stu_id, c.name, c.dept_name, k.tot_cred
  FROM student_core c JOIN student_credit k USING (stu_id);

SELECT name FROM student WHERE dept_name = 'CS';

Ada
Bora
Ece

TUZAK · hangisi daha zor? Mantıksal veri bağımsızlığını sağlamak fiziksel olana göre daha zordur. Çünkü uygulamalar doğrudan tablo ve kolon adlarına bağlıdır. Bir kolonu silersen hiçbir view onu geri getiremez.

Veritabanı dilleri: DDL ve DML

SQL tek bir dildir ama komutları iki gruba ayrılır:

DDL’in çıktısı veri sözlüğüne (data dictionary) yazılır. Bu, “veri hakkında veri” (metadata) tutan özel bir tablolar topluluğudur. DBMS her sorgudan önce oraya bakar.

DML iki tarzda olabilir. Prosedürel (procedural) DML’de “veriyi nasıl bulacağını” adım adım sen söylersin. Bildirimsel (declarative) DML’de sadece “ne istediğini” söylersin, nasıl bulunacağına DBMS karar verir. SQL bildirimseldir:

SELECT stu_id, name FROM student WHERE tot_cred > 40;

S1 | Ada
S3 | Cem
S4 | Defne

Bu sorguda hangi index’in kullanılacağını, satırların hangi sırayla okunacağını yazmadık. Bunu sorgu işlemcisi (query processor) seçti. 12. ve 13. haftalar tam olarak bu seçimin nasıl yapıldığını anlatıyor.

Transaction ve ACID

Transaction (işlem), mantıksal olarak tek bir iş sayılan işlemler dizisidir. Klasik örnek para transferi: A’dan çık, B’ye ekle. İkisi birlikte olmalı. DBMS’in her transaction için verdiği dört söz:

Atomikliği SQLite’ta denedik. Hesaplar A = 500, B = 200 ve kısıt balance >= 0. Transaction önce B’ye 700 ekliyor, sonra A’dan 700 düşmeye çalışıyor:

BEGIN
UPDATE account SET balance = balance + 700 WHERE acc = 'B'   -- başarılı, B = 900
UPDATE account SET balance = balance - 700 WHERE acc = 'A'   -- CHECK hatası (A = -200 olurdu)
ROLLBACK
sonuç: A = 500, B = 200

İlk UPDATE başarılı olduğu hâlde ROLLBACK onu da geri aldı. Geçerli bir 300’lük transfer ise COMMIT ile tamamlandı: A = 200, B = 500 ve toplam 700 korundu.

Kullanıcılar ve DBMS’in parçaları

Bir veritabanıyla dört tür insan konuşur:

• Naive kullanıcı: Hazır arayüzleri kullanır. Ders kayıt sayfasından ders seçen öğrenci.
• Uygulama programcısı (application programmer): O arayüzleri yazar. SQL’i program içinden çağırır.
• Sophisticated kullanıcı: Doğrudan sorgu yazar ya da analiz araçları kullanır. Veri analisti.
• Veritabanı yöneticisi (DBA, database administrator): Şemayı tanımlar, fiziksel düzeni ve index’leri seçer, yetki verir, yedek alır, performansı izler.

DBMS’in içinde ise üç ana parça vardır. Depolama yöneticisi (storage manager) veriyi diske yazıp okur, tampon (buffer) yönetimini yapar. Sorgu işlemcisi (query processor) SQL’i ayrıştırır, en ucuz planı seçer ve çalıştırır. Transaction yöneticisi (transaction manager) eşzamanlılık kontrolü ve çökme sonrası kurtarma (recovery) ile ACID’i sağlar.

Sık yapılan hatalar