Varlık-ilişki (ER) modeli

Veritabanı tasarımı koddan önce kağıt üzerinde başlar. Varlık-ilişki modeli (entity-relationship model, ER) gerçek dünyayı “hangi şeyler var, birbirlerine nasıl bağlı” diye resmetmenin standart yolu. Vizede iki tip soru çıkar: bir senaryodan ER diyagramı çizmek, ya da verilen diyagramdan kardinalite, katılım, anahtar okumak. Bu sayfa boyunca derste kullandığımız üniversite veritabanını (student, instructor, course, department, takes, teaches) ER olarak kuracağız.

Altın kurallar:

1. Varlık = isim, ilişki = fiil. “Öğrenci dersi alır”: student ve course varlık, takes ilişki.
2. Öznitelik türünü sor: bölünür mü (composite), birden çok değeri var mı (multivalued), hesaplanır mı (derived)?
3. Kardinalite ve katılım ayrı şeyler. Kardinalite “en fazla kaç”, katılım “en az bir tane zorunlu mu”.
4. Anahtarı olmayan varlık zayıftır ve sahibine total katılımla bağlanır.
5. Örnek veri kuralı ispatlamaz. Kardinaliteyi iş kuralı belirler.

Varlık ve varlık kümesi

Bir varlık (entity), diğerlerinden ayırt edilebilen tek bir nesnedir: öğrenci Ada, ders CS305, CS bölümü. Aynı özellikleri paylaşan varlıkların toplamı varlık kümesidir (entity set): tüm öğrenciler student kümesini oluşturur. Programlamadaki benzetmeyle varlık kümesi sınıf, varlık nesnedir.

Her varlık öznitelikleriyle (attribute) tanımlanır. Bir özniteliğin alabileceği değerler kümesine domain denir: tot_cred için 0 ile 240 arası tam sayılar gibi. Varlıkları birbirinden ayıran öznitelik(ler) anahtardır (key); student için stu_id.

Öznitelik türleri

Türetilmiş öznitelik saklanmaz, istendiğinde hesaplanır. 2005-11-02 doğumlu bir öğrenci 2026-10-01’de 20 yaşındadır: yıl farkı 21, ama doğum günü henüz gelmedi. age’i saklasaydın her yıl güncellemek gerekirdi; date_of_birth hiç değişmez. Bu yüzden saklanan temel veri, türetilen hesaplanır.

Bu derste kullanacağımız metin notasyonu (Silberschatz’ın kutulu notasyonuna yakın) şöyle:

+------------------------+
| student                |
+------------------------+
| _stu_id_               |     _x_   : birincil anahtar (altı çizili)
| name                   |     girintili : bileşik özniteliğin parçaları
|    first_name          |
|    last_name           |
| date_of_birth          |
| { phone }              |     { }   : çok değerli
| age ( )                |     ( )   : türetilmiş
+------------------------+

TUZAK · çok değerli ile bileşik karışır. name iki parçadan oluşur ama her öğrencinin tek adı var: bileşik. phone tek parçalı ama birden çok değeri olabilir: çok değerli. Soru “birden fazla” diyorsa multivalued, “parçalardan oluşur” diyorsa composite.

İlişkiler, derece ve roller

İlişki (relationship), varlıklar arasındaki bağdır: “Ada CS305’i alıyor”. Aynı türden ilişkilerin kümesi ilişki kümesidir (relationship set): takes. İlişkiye katılan varlık kümesi sayısı derecedir (degree). Üniversite modelinde ilişkilerin çoğu ikili (binary):

student ---- < takes > ---- course          (binary, öznitelik: grade)
instructor ---- < teaches > ---- course     (binary)
instructor ---- < advisor > ---- student    (binary)
instructor ---- < inst_dept > ---- department

Bir varlık kümesi aynı ilişkiye iki kez katılabilir. Örneğin prereq ilişkisi course’u course’a bağlar: CS201’in ön koşulu CS101. Burada hangi tarafın ne olduğunu rol (role) isimleri söyler: course_id rolü ve prereq_id rolü. Böyle ilişkilere recursive ilişki denir.

İlişkinin de özniteliği olabilir. takes üzerindeki grade öğrenciye de derse de ait değil, ikisinin çiftine ait. M:N bir ilişkinin özniteliği bu yüzden ilişkide kalır.

Ternary ilişkiler

Bir hoca, bir öğrenciye belirli bir projede rehberlik ediyorsa üç varlığı bağlayan proj_guide(instructor, student, project) ilişkisi gerekir. Bunu üç ikili ilişkiye bölmek cazip görünür ama bilgi kaybettirir:

proj_guide üçlüleri:  (I1,S1,P1) (I1,S2,P2) (I2,S1,P2)
ikili parçalar:       IS={I1S1, I1S2, I2S1}  SP={S1P1, S2P2, S1P2}  IP={I1P1, I1P2, I2P2}
geri birleştir:       (I1,S1,P1) (I1,S1,P2) (I1,S2,P2) (I2,S1,P2)
sahte üçlü:           (I1,S1,P2)   I1 ile S1 P2'de birlikte değildi

Eşleme kardinalitesi (mapping cardinality)

Kardinalite, bir varlığın ilişki üzerinden en fazla kaç varlıkla eşleşebileceğini söyler.

Örnek veride S1 dört ders alıyor, CS101’i dört öğrenci alıyor: takes iki yönde de “birçok”, M:N. teaches ise örnekte bir hocaya en çok iki ders, bir derse en çok bir hoca düşüyor. Bu veri 1:N ile uyumlu. Ama bir dersin iki hocası olması gerçek bir üniversitede mümkünse tasarım M:N olmalı.

TUZAK · veriye bakıp kardinalite okumak. Örnek tablo bir kısıtı ispat edemez, sadece çürütebilir. Tabloda her ders tek hocalı diye “1:N’dir” diyemezsin. Sınav “bu veriyle tutarlı mı” diye soruyorsa veriye bak; “kardinalite nedir” diyorsa senaryodaki kurala bak.

Silberschatz notasyonunda ok (-->) “en çok bir” tarafını gösterir, düz çizgi “birçok”. Başka kitaplar 1 ve N harfleri ya da kaz ayağı (crow’s foot) kullanır. Sınavda hangi notasyonla çizildiğine bak.

Katılım ve min..max gösterimi

Katılım (participation) “en az bir” sorusudur.

• Total katılım: kümedeki her varlık en az bir ilişkide yer alır. Her hocanın bir bölümü olmak zorunda: instructor, inst_dept’e total katılır. Çift çizgiyle çizilir.
• Partial katılım: bazı varlıklar hiçbir ilişkide olmayabilir. Örnek veride S6 (Firat) hiç ders almamış, BI100’ü kimse vermiyor, I6 (Yildiz) hiç ders vermiyor. Yani student’ın takes’e, course’un teaches’e, instructor’ın teaches’e katılımı kısmi.

Kardinaliteyi ve katılımı tek gösterimde birleştirmenin yolu min..max etiketleridir. Çizginin üstüne yazılan l..h, o varlığın ilişkide en az l, en çok h kez görünebileceğini söyler.

instructor --1..1-- < inst_dept > --0..*-- department
   her hoca tam bir bölümde          bir bölümde sıfır ya da çok hoca

student --0..*-- < takes > --0..*-- course

min = 1 total katılım, min = 0 partial katılım demektir. max = 1 “en çok bir”, * sınırsız.

Zayıf varlıklar (weak entity sets)

Bir dersin şubelerini (section) düşün: CS101’in Fall 2026’daki 1 ve 2 numaralı şubeleri, MA101’in Fall 2026’daki 1 numaralı şubesi. sec_id = 1 tek başına bir şube belirtmez, çünkü birçok dersin 1 numaralı şubesi var. Section’ın kendi başına yeten anahtarı yok: zayıf varlık kümesi (weak entity set).

• Zayıf varlığı tanımlayan güçlü varlık sahip (owner, identifying entity set): course.
• Bağlayan ilişki tanımlayıcı ilişki (identifying relationship): sec_course. Çift baklava ile çizilir.
• Zayıf varlığı sahibi içinde ayırt eden öznitelikler ayırt edici (discriminator, partial key): {sec_id, semester, year}. Kesik altı çizgiyle gösterilir.
• Zayıf varlığın birincil anahtarı = sahibin PK + discriminator = {course_id, sec_id, semester, year}.

+===============+                   +-----------+
|| section     ||====<< sec_course >>----| course    |
|| - sec_id -  ||                   | _course_id_|
|| - semester -||                   +-----------+
|| - year -    ||
+===============+
  çift kutu: zayıf varlık   çift baklava: tanımlayıcı ilişki   çift çizgi: total katılım

Zayıf varlık sahibine her zaman total katılır ve ilişki sahip tarafında “bir” olur: her şube tam olarak bir derse aittir. Doğrulamada ders silinince şubelerinin de silindiğini (ON DELETE CASCADE) gördük. Şube sahibisiz yaşayamaz.

İPUCU · ne zaman zayıf varlık? Varlığın anlamı tamamen başka bir varlığa bağlıysa (sipariş satırı, bina içindeki oda, dersin şubesi) ve kendi doğal anahtarı yoksa zayıf yap. Kendine özgü bir kimlik numarası verirsen (section_id gibi) artık güçlü varlık olur.

Specialization, generalization, aggregation

Bazı varlık kümelerinin alt grupları ayrı öznitelikler taşır. person genel küme, student (tot_cred) ve instructor (salary) alt kümeler. Yukarıdan aşağı düşünürsen specialization, alt kümelerden ortak üst kümeye çıkarsan generalization. Diyagramda ISA üçgeniyle gösterilir; alt küme üst kümenin tüm özniteliklerini miras alır (attribute inheritance).

İki bağımsız kısıt var:

Aggregation, bir ilişkinin kendisini varlıkmış gibi başka bir ilişkiye bağlamaktır. Örneğin proj_guide ilişkisini bir kutu içine alıp eval_for ilişkisiyle evaluation varlığına bağlarsın: “bu hoca-öğrenci-proje üçlüsünün değerlendirmesi”. Kutuyu almadan yapmak için dörtlü bir ilişki gerekirdi ve gereksiz tekrar olurdu.

Tasarım kararları

• Varlık mı öznitelik mi? Telefonu sadece numara olarak tutuyorsan öznitelik. Telefona tip, konum gibi kendi bilgileri eklenecekse varlık yap.
• Varlık mı ilişki mi? Kayıt (enrollment) kendi bilgisini (tarih, ücret) taşıyorsa ve başka şeylere bağlanacaksa varlık olabilir. Sadece “kim neyi aldı” ise ilişki yeter.
• Gereksizlik (redundancy): instructor’da dept_name özniteliği ve ayrıca inst_dept ilişkisi tutma. Bilgi zaten ilişkide, ikisi çelişebilir.
• Ternary mi ikili mi? Üçlü bilgi gerçekten birlikteyse (hangi hoca hangi öğrenciye hangi projede) ternary. Yukarıdaki sahte üçlü örneği bunun nedeni.

Sık yapılan hatalar