Örnek sorular
Data ModelingZorluk 2
Bir veri modelinde PRIMARY KEY, UNIQUE ve FOREIGN KEY kısıtlarının rolleri nasıl farklılaşır?
- aPRIMARY KEY ve UNIQUE ikisi de satırı tanımlar; FOREIGN KEY referans verilen satırın verisinin kopyasını tutar
- bPRIMARY KEY satırın ana tanımlayıcısıdır; UNIQUE alternatif teklik sağlar; FOREIGN KEY başka bir tablonun anahtarına bağlar✓
- cÜçü de kendi tablosunda teklik zorunlu kılar ve hiçbiri NULL değere izin vermez
- dPRIMARY KEY ve FOREIGN KEY her zaman aynı kolon olmalıdır; UNIQUE yalnızca bir index ipucudur
Açıklama:Primary key seçilen ana tanımlayıcıdır (tablo başına bir tane, unique + NOT NULL); UNIQUE alternatif/aday anahtarlarda teklik sağlar ve NULL'a izin verebilir; foreign key başka bir tablonun anahtarını referans alarak referential integrity zorunlu kılar. Foreign key referans verilen veriyi kopyalamaz (a); UNIQUE salt index ipucu değil gerçek bir kısıttır ve NULL'a izin verebilir, bu yüzden (c) ve (d) yanlıştır.
Data ModelingZorluk 2
Natural key ile surrogate key arasındaki farkı en iyi ne tanımlar?
- aNatural key sistem tarafından üretilir; surrogate key ise gerçek dünya verisinden alınır
- bSurrogate key her zaman composite olmalıdır, natural key ise her zaman tek kolondur
- cNatural key'ler join'de daha hızlıdır çünkü hiçbir zaman index'lenmeleri gerekmez
- dNatural key anlamlı bir gerçek dünya özniteliğidir; surrogate key sistemin ürettiği yapay bir değerdir✓
Açıklama:Natural key var olan anlamlı veriyi kullanır (ör. ISBN, email); surrogate key ise iş anlamı olmayan yapay bir değerdir (ör. otomatik üretilen integer veya UUID). (a) ikisini ters çevirir, surrogate key'ler genelde tek kolondur ve composite olmak zorunda değildir (b), natural key'ler de her anahtar gibi index gerektirir (c).
Data ModelingZorluk 2
Composite primary key nedir?
- aAynı anda iki tablo boyunca otomatik artan bir primary key
- bYedek görevi görsün diye ikinci bir kolona kopyalanan bir primary key
- cİki veya daha fazla kolondan oluşan ve kombinasyonu unique olması gereken bir primary key✓
- dKolonlarından en az biri doluysa NULL olabilen bir primary key
Açıklama:Composite key birkaç kolonu birlikte kullanır; teklik her kolonda ayrı ayrı değil kombinasyonda zorunlu kılınır. Junction tablolarda yaygındır, ör. (student_id, course_id). Primary key'in hiçbir parçası NULL olamaz, bu yüzden (d) yanlıştır; ne yedek kopyadır (b) ne de tablolar arası auto-increment (a).
Data ModelingZorluk 1
Birinci normal form (1NF) neyi şart koşar?
- aHer kolon tek bir atomik değer tutar; liste veya tekrar eden grup olmaz✓
- bHer tablo en fazla üç kolonla sınırlıdır
- cTüm metin kolonları sabit uzunluklu CHAR tipinde saklanır
- dHer tablo başka bir tabloyla en az bir foreign-key ilişkisine katılır
Açıklama:1NF çok değerli ve tekrar eden kolonları yasaklar: her hücre tek bir atomik değer tutar ve tekrar eden grup bulunmaz. Kolon sayısı (b), fiziksel CHAR saklama (c) ve ilişki zorunluluğu (d) normal formlarla ilgisizdir.
Data ModelingZorluk 3
order_items(order_id, product_id, quantity, product_name) tablosunun composite primary key'i (order_id, product_id) ve product_name yalnızca product_id'ye bağlı. Sorun ve çözümü nedir?
- a1NF'i ihlal eder çünkü product_name tekrar eder; her değeri kendi satırına ayır
- bTransitive dependency ile 3NF'i ihlal eder; quantity'yi başka tabloya taşı
- c2NF'i ihlal eder: product_name anahtarın bir parçasına partial dependency'dir; bir products tablosuna taşı✓
- dHiçbir normal form'u ihlal etmez; geniş bir sipariş satırı tablosu her zaman kabul edilebilir bir tasarımdır
Açıklama:2NF, anahtar olmayan her kolonun composite key'in tamamına bağlı olmasını ister. product_name yalnızca anahtarın parçası olan product_id'ye bağlıdır — partial dependency — dolayısıyla product_id ile anahtarlanan bir products tablosuna aittir. Değerler atomiktir, yani 1NF sorunu değildir (a) ve partial dependency, 3NF'in ele aldığı transitive dependency'den farklıdır (b).
Data ModelingZorluk 3
employees(emp_id, name, dept_id, dept_name) tablosunun tek kolonluk primary key'i emp_id. Burada dept_name, dept_id'ye; dept_id de emp_id'ye bağlı. Bu nedir ve 3NF ne öngörür?
- aPartial dependency; emp_id tek anahtar olduğu için zaten çözülmüştür
- bMulti-valued dependency; çözümü için fourth normal form (4NF) gerekir
- cSorun yok, çünkü dept_id primary key olmadığı sürece dept_name kalabilir
- dTransitive dependency; dept_name'i dept_id ile anahtarlanan bir departments tablosuna taşı✓
Açıklama:dept_name, anahtara bağlı olan anahtar-olmayan bir kolona (dept_id) bağlıdır — transitive dependency; 3NF bunu dept_name'i bir departments tablosuna taşıyarak giderir. Tek kolonluk anahtarda partial dependency olmaz (a) ve bu, 4NF gerektiren multi-valued değil, functional/transitive bir sorundur (b).