Veritabanı Tasarım Aşamaları
Bir veritabanı sıfırdan tasarlanırken belirli aşamalardan geçilir. Bu süreç soyut gereksinimlerden başlar, somut fiziksel yapıya kadar iner.
Gereksinim Toplama (Requirements)
Veritabanını kullanacak kişilerin veri ihtiyaçları belirlenir. Hangi veriler saklanacak, hangi sorgular yapılacak, hangi operasyonlar çalışacak — bunların hepsi bu aşamada toplanır. Henüz hiçbir teknik karar verilmez.
Conceptual Design (Kavramsal Tasarım)
Bir data model seçilir (örneğin ER modeli) ve gereksinimler bu modelin kavramlarıyla ifade edilir. Ortaya çıkan conceptual schema, kurumun işlevsel gereksinimlerini (functional requirements) gösterir. Bu aşamada hâlâ belirli bir DBMS'e bağlı değiliz.
Logical Design (Mantıksal Tasarım)
Kavramsal şema, kullanılacak DBMS'in veri modeline (örneğin ilişkisel model) dönüştürülür. ER diyagramındaki entity ve relationship'ler tablolara (relation schemas) çevrilir.
Physical Design (Fiziksel Tasarım)
Veritabanının fiziksel düzeni belirlenir: dosya organizasyonu, index yapıları, partitioning gibi performans-odaklı kararlar bu aşamada verilir.
Entity-Relationship (ER) Model'e Giriş
ER modeli, bir kurumu (enterprise) entity'ler ve bunlar arasındaki relationship'ler koleksiyonu olarak modeller. 1976'da Peter Chen tarafından önerilmiştir ve veritabanı kavramsal tasarımının en yaygın aracıdır.
Entity (Varlık): Kurumda var olan ve diğer nesnelerden ayırt edilebilen bir "şey" ya da "nesne". Örneğin belirli bir öğrenci, belirli bir ders, belirli bir şirket.
Relationship (İlişki): Birden fazla entity arasındaki bir bağlantı ya da ilişki. Örneğin bir öğrencinin bir danışmanla (instructor) olan "advisor" ilişkisi.
Attribute (Nitelik): Bir entity'yi tanımlayan özellik. Örneğin bir öğrencinin ID, name, tot_cred attribute'ları.
ER modelinin üç temel kavramı vardır:
Entity Sets
Aynı türdeki entity'lerin kümesi. ER diyagramında dikdörtgen ile gösterilir.
Relationship Sets
Entity'ler arasındaki ilişkilerin kümesi. ER diyagramında elmas (diamond) ile gösterilir.
Attributes
Entity ya da relationship'i tanımlayan özellikler. Dikdörtgenin içinde listelenir.
ER modelinin güçlü yönü, bir ER Diagram (ERD) aracılığıyla veritabanının genel mantıksal yapısını görsel ve anlaşılır biçimde ortaya koyabilmesidir.
Entity Sets (Varlık Kümeleri)
Entity Nedir?
Bir entity, gerçek dünyada var olan ve diğer nesnelerden ayırt edilebilen herhangi bir şeydir. Soyut ya da somut olabilir:
- Somut: Belirli bir kişi, bina, araba
- Soyut: Belirli bir şirket, belirli bir tatil, belirli bir ders
Entity Set Nedir?
Bir entity set, aynı türden ve aynı özellikleri paylaşan entity'lerin kümesidir. Örneğin tüm öğrenciler bir entity set oluşturur; tüm dersler başka bir entity set oluşturur.
Bir entity set'teki entity'ler aynı attribute'lara sahip olmalıdır, ancak bu attribute'ların değerleri farklı olabilir. Örneğin tüm öğrencilerin ID, name ve tot_cred attribute'ları vardır ama her öğrencinin bu değerleri farklıdır.
Primary Key (Birincil Anahtar)
Attribute değerlerinin bir alt kümesi, entity set içindeki her üyeyi benzersiz biçimde tanımlıyorsa bu alt küme o entity set için bir primary key adayıdır. Hiçbir iki entity, primary key attribute'larında aynı değerlere sahip olamaz.
instructor = (ID, name, salary)
student = (ID, name, tot_cred)
course = (course_id, title, credits)
-- Altı çizili attribute → primary key
ER Diyagramında Entity Set Gösterimi
Entity set'ler dikdörtgenle gösterilir. Attribute'lar dikdörtgenin içinde listelenir. Primary key olan attribute'ların altı çizilir.
Attribute (Nitelik) Türleri
Her attribute'un bir domain'i (izin verilen değerler kümesi) vardır. Örneğin semester attribute'unun domain'i {Fall, Winter, Spring, Summer} olabilir.
1. Simple vs. Composite Attributes
Daha küçük parçalara bölünemeyen attribute. Örneğin salary, age.
Alt parçalara (component attributes) bölünebilen attribute. Örneğin name → first_name + middle_initial + last_name.
2. Single-valued vs. Multivalued Attributes
Her entity için tek bir değer tutar. Örneğin bir öğrencinin ID'si tek bir değerdir.
Bir entity için birden fazla değer tutabilir. Örneğin bir kişinin birden fazla telefon numarası olabilir: phone_numbers. ER diyagramında süslü parantez {} ya da çift oval ile gösterilir.
3. Derived Attributes
Başka attribute'lardan hesaplanabilen attribute. Örneğin date_of_birth bilgisi varsa age bundan türetilebilir. ER diyagramında parantez () ile gösterilir: age().
ER Diyagramında Karmaşık Attribute Gösterimi
Relationship Sets (İlişki Kümeleri)
Relationship Nedir?
Bir relationship, birden fazla entity arasındaki bir bağlantıdır. Örneğin öğrenci 44553 (Peltier) ile eğitimci 22222 (Einstein) arasındaki advisor ilişkisi.
Relationship Set Nedir?
Bir relationship set, n ≥ 2 entity içeren matematiksel bir ilişkidir. Daha formal ifadeyle:
-- burada (e₁, e₂, …, eₙ) bir relationship'tir
Örnek: (44553, 22222) ∈ advisor
ER Diyagramında Relationship Gösterimi
Relationship set'ler elmas (diamond) şekliyle gösterilir. İlgili entity setleri bağlayan çizgilerle elmasın köşelerine bağlanır.
Relationship Set'lerde Attribute
Bir relationship set'in de attribute'ları olabilir. Örneğin advisor relationship set'ine öğrencinin danışmanla ne zaman çalışmaya başladığını gösteren bir date attribute'u eklenebilir.
Roles ve Degree of Relationship Sets
Roles (Roller)
Bir relationship set'teki entity set'lerin aynı olması zorunlu değildir. Bir entity set, bir ilişkide birden fazla kez yer alabilir — bu durumda her oluşumun oynadığı rolü belirtmek için role label'lar kullanılır.
course entity set'i, prereq ilişkisinde iki farklı rolle katılır: course_id (o ders) ve prereq_id (ön koşul ders). Aynı tablo kendi kendisiyle ilişkilendirilmiştir.
Degree (Derece) of a Relationship Set
Bir relationship set'e katılan entity set sayısına degree denir.
Binary Relationship (Derece 2)
İki entity set arasındaki ilişki. Veritabanı sistemlerindeki relationship set'lerin büyük çoğunluğu binary'dir.
Ternary Relationship (Derece 3)
Üç entity set arasındaki ilişki. Örneğin öğrencilerin, projeler üzerinde, bir eğitimcinin rehberliğinde çalışması: proj_guide(instructor, student, project).
Mapping Cardinality Constraints
Mapping cardinality, bir entity'nin bir relationship aracılığıyla kaç tane başka entity ile ilişkilendirilebileceğini ifade eder. Binary relationship set'ler için dört tür vardır.
Directed line (→) = "one" tarafı | Undirected line (—) = "many" tarafı
1. One-to-One (1:1)
A'daki bir entity, B'deki en fazla bir entity ile ilişkilidir; B'deki bir entity, A'daki en fazla bir entity ile ilişkilidir.
Örnek: Bir eğitimci en fazla bir öğrenciye danışmanlık yapabilir; bir öğrencinin en fazla bir danışmanı olabilir.
2. One-to-Many (1:N)
A'daki bir entity, B'deki sıfır veya daha fazla entity ile ilişkilidir; B'deki bir entity ise A'daki en fazla bir entity ile ilişkilidir.
Örnek: Bir eğitimci birden fazla öğrenciye (0 dahil) danışmanlık yapabilir; bir öğrencinin ise en fazla bir danışmanı (instructor) olabilir.
3. Many-to-One (N:1)
A'daki bir entity, B'deki en fazla bir entity ile ilişkilidir; B'deki bir entity ise A'daki sıfır veya daha fazla entity ile ilişkilidir. One-to-Many'nin tam tersidir.
4. Many-to-Many (N:M)
Her iki taraftaki entity'ler de birden fazla karşı entity ile ilişkilendirilebilir.
Örnek: Bir eğitimci birden fazla öğrenciye danışmanlık yapabilir; bir öğrencinin de birden fazla danışmanı olabilir.
Daha Karmaşık Kardinalite Gösterimi: l..h Notasyonu
Bir çizgiye minimum ve maksimum kardinalite eklenebilir: l..h biçiminde. Burada l minimum, h maksimum değeri gösterir.
0..*→ 0 veya daha fazla (sınırsız)1..1→ tam olarak 1 (total participation + one)1..*→ en az 1, sınırsız üst
l..h notasyonunda çizginin hangi tarafta olduğuna dikkat edin. Sol kenardaki 0..* ifadesi, instructor'ın 0 veya daha fazla öğrenciyle ilişkili olduğunu gösterir — bu, instructor tarafının "many" olduğu anlamına gelir. Ters yorumlamak yaygın bir hata kaynağıdır.
Total ve Partial Participation
Entity set'teki her entity, relationship set'teki en az bir ilişkiye katılmak zorundadır. ER diyagramında çift çizgi ile gösterilir.
Örnek: Her öğrencinin bir danışmanı olmak zorundaysa, student'ın advisor'a katılımı total'dir.
Entity set'teki bazı entity'ler hiçbir ilişkiye katılmayabilir. ER diyagramında tek çizgi ile gösterilir.
Örnek: Bir eğitimcinin danışmanlık yapma zorunluluğu yoksa, instructor'ın advisor'a katılımı partial'dir.
Primary Keys (Birincil Anahtarlar)
Primary key, entity ve relationship'lerin nasıl ayırt edileceğini belirtir. Üç farklı bağlamda ele alınır.
Entity Set'ler için Primary Key
Bireysel entity'ler tanım gereği birbirinden farklıdır. Ancak veri tabanı perspektifinden bu farklılık attribute değerleriyle ifade edilmek zorundadır. Bir entity set'teki hiçbir iki entity, tüm attribute'larda aynı değerlere sahip olamaz. Bir entity'yi benzersiz kılan attribute alt kümesine key denir; tasarımcının seçtiği key'e primary key denir.
Relationship Set'ler için Primary Key
Bir relationship set'teki ilişkileri birbirinden ayırt etmek için, ilişkiye katılan entity set'lerin primary key'leri kullanılır.
R ilişkisi E₁, E₂, …, Eₙ entity set'lerini içeriyorsa, R'nin primary key'i bu entity set'lerinin primary key'lerinin birleşimidir (union). Eğer R'nin kendi attribute'ları da varsa bunlar da primary key'e dahil edilir.
Kardinaliteye Göre Primary Key Seçimi
| Kardinalite | Primary Key Seçimi |
|---|---|
| Many-to-Many | Her iki tarafın primary key'lerinin birleşimi (minimal superkey) |
| One-to-Many | "Many" tarafının primary key'i yeterlidir |
| Many-to-One | "Many" tarafının primary key'i yeterlidir |
| One-to-One | Her iki tarafın primary key'i de minimal superkey'dir; ikisinden biri seçilebilir |
advisor relationship set'inin primary key'i: instructor.ID ve student.ID'nin birleşimi. Ancak bu ilişki many-to-one ise (bir öğrencinin tek danışmanı varsa), student.ID tek başına yeterlidir.
Weak Entity Sets (Zayıf Varlık Kümeleri)
Bazı entity'ler, yalnızca kendi attribute'larıyla benzersiz biçimde tanımlanamaz. Bu tür entity'lere weak entity denir.
Varlığı başka bir entity'ye (identifying entity) bağımlı olan entity set'tir. Kendi başına bir primary key'i yoktur; bunun yerine identifying entity'nin primary key'i ve ekstra attribute'lar (discriminator) bir araya gelir.
Weak entity olmayan, yani kendi primary key'ine sahip olan her entity set.
Somut Örnek
Bir section (ders bölümü) entity'sini düşünün. Bir bölümü benzersiz tanımlamak için course_id, semester, year ve sec_id bilgilerine ihtiyaç vardır. Ancak course_id aslında ilgili course entity'sinin bilgisidir.
Çözüm: section'ı weak entity set olarak tanımlarız. section'ın kendi attribute'ları: sec_id, semester, year. Tam primary key ise course'un primary key'ini (course_id) de içerir.
Aynı identifying entity'ye bağlı weak entity'leri birbirinden ayıran attribute kümesi. ER diyagramında kesikli altçizgi ile gösterilir.
ER Diyagramında Weak Entity Gösterimi
- Weak entity set → çift dikdörtgen
- Identifying relationship → çift elmas
- Discriminator → kesikli altçizgi
section'ın tam primary key'i: (course_id, sec_id, semester, year). Burada course_id identifying entity course'dan gelmektedir.
ER Diyagram Sembolleri Özeti
| Sembol | Anlamı |
|---|---|
| Dikdörtgen (tek) | Strong entity set |
| Dikdörtgen (çift) | Weak entity set |
| Elmas (tek) | Relationship set |
| Elmas (çift) | Identifying relationship set (weak entity için) |
| Attribute: normal metin | Simple attribute |
| Attribute: girintili alt metin | Composite attribute'un bileşeni |
Attribute: { } içinde | Multivalued attribute |
Attribute: ( ) sonunda | Derived attribute |
| Attribute: altı çizili (düz) | Primary key attribute |
| Attribute: altı çizili (kesikli) | Discriminator (weak entity'nin partial key'i) |
| Tek çizgi (—) | Partial participation veya "many" tarafı |
| Çift çizgi (═) | Total participation |
| Yönlü çizgi (→) | "one" tarafı (cardinality constraint) |
| Hollow arrow (⇒) | ISA ilişkisi (generalization/specialization) |
l..h etiketi | Minimum ve maksimum kardinalite |
Reduction to Relation Schemas (ER'den İlişkisel Şemaya)
ER diyagramı tamamlandıktan sonra, bu kavramsal tasarım ilişkisel (relational) şemaya dönüştürülür. Bu süreç birkaç kuralı takip eder.
Temel Dönüşüm Kuralları
Her strong entity set → bir relation
Entity set'in tüm attribute'larıyla aynı adda bir tablo oluşturulur.
Her relationship set → bir relation
İlişkinin primary key'lerini ve varsa kendi attribute'larını içeren bir tablo oluşturulur.
Weak entity set özel durumdur
Weak entity set, identifying entity'nin primary key'ini de içerecek şekilde bir tabloya dönüştürülür.
Composite Attributes
Composite attribute'lar için bileşen attribute'ların her biri ayrı bir sütun olur; composite attribute'un kendisi için ayrı sütun açılmaz. Önek karışıklığa yol açmıyorsa kaldırılabilir.
instructor(ID, first_name, middle_initial, last_name,
street_number, street_name, apt_number,
city, state, zip, date_of_birth)
Multivalued Attributes
Bir multivalued attribute için ayrı bir tablo (schema) oluşturulur. Bu tabloda entity'nin primary key'i ve multivalued attribute yer alır.
inst_phone = (ID, phone_number)
-- Örnek veri:
(22222, 456-7890)
(22222, 123-4567) ← aynı instructor, iki satır
Redundancy of Schemas (Şema Fazlalığı)
Many-to-one veya one-to-many ilişkilerinde, "many" tarafı total participation gösteriyorsa, ilişki için ayrı tablo açmak yerine "many" tarafının tablosuna ekstra sütun eklenir.
instructor = (ID, name, salary, dept_name)
-- dept_name → department tablosuna foreign key
-- stud_dept relationship set yerine:
student = (ID, name, tot_cred, dept_name)
Bu sayede inst_dept ve stud_dept için ayrı tablolar gereksiz hale gelir.
One-to-one ilişkilerde her iki taraf da "many" gibi davranabilir, yani ekstra sütun her iki tabloya da eklenebilir. Partial participation varsa, null değerler kullanılabilir.
Weak Entity'nin Şemaya Dönüşümü
Weak entity set'in identifying relationship'ini temsil eden şema zaten weak entity tablosunda mevcut olduğundan, bu ilişki için ayrı tablo açılmaz (redundant olur).
section = (course_id, sec_id, semester, year)
-- sec_course için ayrı tablo açılmaz → zaten dahil
Foreign Key Constraints
Şemalar birleştirildiğinde, orijinal relationship set'te var olacak foreign key kısıtlamaları da hedef tabloya taşınır.
→ dept_name references department(dept_name)
student = (ID, name, tot_cred, dept_name)
→ dept_name references department(dept_name)
advisor = (s_ID, i_ID)
→ s_ID references student(ID)
→ i_ID references instructor(ID)
department = (dept_name, building, budget)
Extended ER Features: Specialization & Generalization
Specialization (Uzmanlaşma)
Specialization, yukarıdan aşağıya (top-down) bir tasarım sürecidir. Bir entity set içindeki alt gruplar tespit edilir ve bunlar daha spesifik (alt düzey) entity set'ler olarak modellenir.
- Alt düzey entity set, üst düzey entity set'in tüm attribute'larını miras alır (attribute inheritance).
- Ek olarak kendine özgü attribute'lara veya relationship'lere sahip olabilir.
- Bu ilişki ISA ilişkisi olarak adlandırılır (örn: "instructor IS A person").
- ER diyagramında içi boş ok başı (hollow arrow) ile gösterilir; ok, spesifik entity'den genel entity'ye bakar.
Overlapping vs. Disjoint Specialization
Bir entity, birden fazla alt entity set'e ait olabilir. ER diyagramında iki ayrı ok kullanılır.
Örnek: Bir kişi hem employee hem student olabilir.
Bir entity, en fazla bir alt entity set'e ait olabilir. ER diyagramında tek ok kullanılır.
Örnek: Bir çalışan ya instructor'dır ya secretary, ikisi birden olamaz.
Generalization (Genelleştirme)
Generalization, specialization'ın tam tersidir: aşağıdan yukarıya (bottom-up) bir süreçtir. Ortak özelliklere sahip birden fazla entity set, daha üst düzey tek bir entity set altında birleştirilir. ER diyagramında gösterim biçimi aynıdır; kavramsal yön farklıdır.
Total vs. Partial Generalization/Specialization
Üst düzey entity set'teki her entity, alt düzey entity set'lerden birine ait olmak zorundadır. ER'de "total" etiketi ve kesikli çizgi ile gösterilir.
Üst düzey entity set'teki bir entity, hiçbir alt entity set'e dahil olmayabilir. Gösterim için ek etiket gerekmez.
Specialization'ın Şemaya Dönüşümü
İki yöntem vardır:
Üst düzey entity için bir tablo. Her alt düzey entity için, üst düzeyin primary key'i + yerel attribute'lar içeren ayrı tablolar. Dezavantaj: Bir çalışan hakkında bilgi almak iki tabloyu birleştirmeyi gerektirir.
Her entity set için, hem yerel hem miras alınan tüm attribute'larla bir tablo. Dezavantaj: Hem öğrenci hem çalışan olan kişiler için name, street, city gibi bilgiler tekrar tekrar saklanır (redundancy).
person = (ID, name, street, city)
student = (ID, tot_cred)
employee = (ID, salary)
-- Yöntem 2:
person = (ID, name, street, city)
student = (ID, name, street, city, tot_cred)
employee = (ID, name, street, city, salary)
Design Issues (Tasarım Sorunları)
İyi bir ER tasarımı için dikkat edilmesi gereken başlıca ilkeler şunlardır:
1. Redundancy'den Kaçının
Aynı bilgiyi hem entity attribute'u hem de relationship üzerinden saklamak israf ve tutarsızlık riskidir. Örneğin student entity'sine dept_name attribute'u ekleyip aynı zamanda bir stud_dept relationship de tanımlamak redundant'tır. Relationship üzerinden zaten bu bilgiye ulaşılabilir; attribute kaldırılmalıdır.
2. Weak Entity Set Kullanımını Sınırlayın
Weak entity set, ancak gerçekten gerekli olduğunda kullanılmalıdır. Her entity'ye uygun bir primary key belirlenebiliyorsa strong entity set tercih edilir.
3. Entity mi, Attribute mi?
Bir kavramın entity mi yoksa attribute mu olacağına karar vermek zordur. Genel kural: eğer o kavram hakkında ek bilgi saklamak gerekiyorsa veya birden fazla değer alabiliyorsa entity olarak modellenmesi daha uygundur.
phone: Birden fazla telefon numarası olabilir; konum (location) gibi ek bilgi de saklanabilir → ayrı entity set uygundur.
name (bir instructor'ın adı): Kendi başına bağımsız bir varlık değildir → entity olarak modellemek gerekmez, attribute yeterlidir.
4. Entity mi, Relationship mi?
İki entity arasındaki bir eylemi ya da bağlantıyı temsil etmek için genellikle relationship set tercih edilir. Relationship'in kendisine ait attribute'lar varsa (örneğin başlangıç tarihi), bu attribute'lar relationship'e eklenir. Ancak bu attribute'ları kullanarak ek sorgular yapılacaksa ayrı bir entity olarak modellenmesi düşünülebilir.
5. Binary mi, Non-Binary mi?
Her non-binary ilişki teorik olarak binary ilişkilere dönüştürülebilir, ancak n-ary ilişki setleri bazı durumlarda daha açıklayıcıdır. Bazı ilişkiler doğal olarak non-binary'dir (örn: proj_guide). Öte yandan bir parents ternary ilişkisi, "yalnızca anne biliniyorsa" gibi kısmi bilgilere izin verdiğinden iki binary ilişkiyle daha iyi modellenebilir.
6. Relationship Attribute'larının Yerleşimi
Bir relationship attribute'u, ilişkinin "many" tarafındaki entity'ye taşınabilir. Örneğin one-to-many advisor ilişkisindeki date, student entity'sine advisor_since olarak eklenebilir. Ancak many-to-many ilişkilerde bu mümkün değildir; attribute relationship'te kalmak zorundadır.
Slayttaki üç temel tasarım ilkesi: (1) Redundancy'den kaçın. (2) Weak entity set kullanımını sınırla. (3) Attribute yeterliyse entity kullanma.