Veritabanı Yönetim Sistemi (DBMS)

Merhabalar, DBMS’in temel kavramlarını, işlevlerini ve farklı türlerini keşfederken, öğrendiğim bilgileri pekiştirip anladığım şekilde sizlerle paylaşacağım. Veri yönetimindeki bu güçlü sistemlerin ardında yatan temel prensipleri birlikte inceleyeceğiz.

Candidate Key (Aday Anahtar)

• Candidate key değeri her tuple için benzersiz ve non-null olmalıdır.

Bir tabloda birincil anahtar olma potansiyeline sahip olan sütun veya sütun grubudur.

Örneğin, şirketteki ehliyeti olan insanların bilgilerini içeren bir tablo düşünelim.

Buradaki tabloda Candidate Key’ler: Calisan_no, Tc_no, Ehliyet_no olduğunu söyleyebiliriz çünkü her biri benzersizdir ve null olamaz. Ayrıca, bu tüm Candidate Key’ler “Prime Attributes” olarak adlandırılır. “Non-prime Attributes” olarak ise Calisan_isim niteliğini örnek gösterebiliriz.

Primary key (Birincil Anahtar)

Eğer Candidate Key’i kavradıysak bahsettiğimiz Candidate Key’ler arasından bir tanesini seçtiğimizi düşünebiliriz.

• Primary Key de aynı şekilde benzersiz ve non-null olmalıdır.
• Dolayısıyla bir Candidate Key’imiz varsa bu key otomatik olarak Primary Key’imizdir.
• Candidate Key’den farklı olarak sadece bir tane Primary Key’imiz olabilir.
• Yukarıdaki tabloya bakarak örnek verecek olursak Ehliyet_no bizim için Primary Key olabilir.

Alternate Key (Alternatif Anahtar)

Alternate Key, Candidate Key’ler üzerinden seçilen Primary Key’in alternatifleridir.

• Yukarıda Primary Key olarak belirlediğimiz Ehliyet_no için Tc_no ve Calisan_no bizim için Alernate Key’dir.

Super Key

Bir tuple’ı benzersiz bir şekilde tanımlayabilen attribute kümesi Süper Key olarak bilinir.

Buradaki tabloya bakarak Super Key’leri birlikte bulalım:

“Calisan_no” bir Super Key’dir çünkü benzersizdir.

“Calisan_no, Calisan_isim” de aynı zamanda Super Key’dir. Çünkü Calisan_no değeri 10 olup Calisan_isim değeri Ahmet olan bir kişi olamaz, küme olarak benzersizdir.

Aynı şekilde “Ehliyet_no, Sehir” de bir Super Key’dir.

Her Candidate Key aynı zamanda bir Super Key’dir.

Foreign Key (Yabancı Anahtar)

Türkiye’de yaşayan biri Amerika’ya gittiğinde, Amerikalılara göre yabancı olarak kabul edilir. Foreign Key buna benzerdir.

Tablomuzun bir sütunu, başka bir tablonun Primary Key’ini tuttuğunu düşünelim. İşte bu Foreign Key olur.

Şimdi buradaki tablolar arasındaki ilişkiyi inceleyecek olursak

Departman (DeptNo, DName, Sehir)

Calisan (CalisanNo, CalisanIsim, DeptNo)

DeptNo var oluş noktası Departman Tablosu olduğundan Departman Tablosu Parent Table, Calisan Tablosu ise bu durumda Child Table olur.

Entity Relationship Model (ER Model)

Veri tabanlarının tasarımını görselleştirmek ve organize etmek için kullanılan bir kavramsal modeldir.

ER modelini Entities, Relationships ve Attributes olmak üzere 3 başlık altında inceleyeceğiz.

Entity (Varlık)

Entity, bir nesne veya veri bileşenidir. Örneğin, bir “Öğrenci”, “Öğretmen” veya “Ders” birer Entitydir. Bir ER diyagramında dikdörtgen olarak gösterilir.

Entity Set (Varlık Kümesi)

Aynı türden entitylerin topluluğudur. Örneğin, tüm öğrenciler “Öğrenciler” entity set’ini oluşturur.

Weak Entity (Zayıf Varlık) ve Strong Entity(Güçlü Varlık)

Strong Entity, yukarıda bahesttiğim Primary Key ile ilişkilidir. Primary Key olan Entity olarak açıklayabiliriz.

Weak Entity, kendi başına benzersiz olamayan ve başka bir entitye bağımlı olan entitydir. ER diyagramında iç içe çift dikdörtgen olarak gösterilir.

Attribute (Nitelik)

Attribute, bir entity’in özelliğini tanımlar. Bir tabloda sütunları attributes, satırlari tuple olarak ifade ediyoruz.

Key Attribute (Anahtar Nitelik)

Key attribute, entity set içerisinden benzersiz olan ve onları diğer entitylerden ayıran attribute’lerdir.

Simple Attribute (Basit Nitelik)

Simple Attribute, daha basit bileşenlere ayrılamayan özniteliktir. Örneğin, “Yaş” bir Simple Attribute’dir çünkü daha basit parçalara ayrılamaz.

Composite Attribute (Bileşik Nitelik)

Küçük parçalara ayırılabilen Attribute’lere denir.

Single valued attribute (Tek Değerli Nitelik)

Her Entity örneği için yalnızca tek bir değer alacak attribute denir.

Örnek: Yaş.

Multi-valued Attribute (Çok Değeri Olan Nitelik)

Birden fazla değer alabilen attributedir.

Örnek: Telefon Numarası, Email adresi.

Stored Attribute (Depolanan Nitelik)

Kalıcı olarak saklanması gereken bir attribute.

Örnek: Öğrencinin isimi, Doğum tarihi.

Derived Attribute (Türetilmiş Nitelik)

Başka bir attribute ile hesaplanan veya türetilen bir attribute.

Örnek: Yaş.

Şuanki Yıl — Doğum yılı yapılarak türetilebilir.

Relationship (İlişki)

Entity’ler arasındaki ilişkiye Relationship denir. Relationship için gösterimi elmas sembolüdür.

Örneğin, şirket için çalışan işçi. Şirket kendi başında bir Entity, aynı şekilde işçi de bir Entitydir.

Weak Relationship (Zayıf İlişki)

Weak entity ile bağlanan ilişkidir. Örneğin, banka hesabı ile banka Weak Relationship icerisindedir.

Degree of relationship (İlişkinin Derecesi)

Bir ilişkinin derecesi, ilgili Entity türlerinin sayısıdır. n-ary ilişkisi n. derece için genel formdur. Özel durumlar olarak unary, binary ve ternary. Dereceler sırasıyla 1, 2 ve 3 tür.

Cardinality (Kardinalite)

İki entity arasındaki ilişkinin sayısal niteliğidir.

İlişikiler, aşağıda bulunan dört olası bağlantıyı kurabilir:

1. One to one (Bire bir) (1:1) ilişki
2. One to many (Birden Çoğa) (1:M)
3. Many to one (Çoktan bire) (M:1)
4. Many to many (Çoktan çoğa) (M:M)

Bu bağlantının maksimum ve minimum değerleri ilişkinin kardinalitesi olarak adlandırılır.

1) One to one ( 1 : 1 ) Relationship

Bir entitiy’in tek bir örneği başka bir entity’in tek bir örneği ile ilişkilendirilir.

Örneğin, bir kişinin tek pasaportu vardır ve bir pasaport tek kişiye verilir.

2) One to many ( 1 : M ) Relationship

Entity’in tek bir örneği başka bir entity’in birden fazla örneği ile ilişkili olması.

Örneğin, müşterinin çok sayıda sipariş vermesi.

3) Many to one ( M : 1 ) Relationship

Bir entity’in birden fazla örneği, başka bir entity’in tek bir örneği ile ilişkilidir.

Örneğin, birçok öğrenci tek bir üniversitede eğitim görebilir.

4) Many to many ( M : M ) Relationship

Bir entity’in birden fazla örneği, başka bir entity’in birden fazla örneği ile ilişkilidir.

Örneğin, bir öğrenci birçok projede görevlendirilebilir ve bir proje birçok öğrenci tarafından yapılabilir.

Functional Dependency (Fonksiyonel Bağımlılık)

Functional Dependency, bir veritabanı tablosunda bir niteliğin (attribute) başka bir niteliği belirlediği bir ilişkiyi tanımlar. Functional Dependency, veritabanı tasarımında ve normalizasyon sürecinde önemli bir rol oynar.

Aşağıya daha iyi anlamak için bir soru bırakıyorum:

Sorunun cevabı aşağıdaki konu başlığının altında.

Trivial Functional Dependency (Trivial Fonksiyonel Bağımlılık)

X niteliği, Y niteliğinin bir alt kümesiyse, bu bağımlılık trival bir fonksiyonel bağımlılıktır.

Örnek:

A → A, ABC → BC, {Calisan_id Calisan_isim} → Calisan_id

Yukarıdaki sorunun cevabı B şıkkı.

Non-Trivial Functional Dependency (Non-Trivial Fonksiyonel Bağımlılık)

X niteliği, Y niteliğinin bir alt kümesi değilse, bu bağımlılık non-trivial bir fonksiyonel bağımlılıktır.

Örnek: A → B, ABC → DE, Calisan_id → Calisan_isim

Full Functional Dependency (Tam Fonksiyonel Bağımlılık)

X niteliği, Y niteliğine bağımlıysa ve Y’nin herhangi bir alt kümesine bağımlı değilse, bu Tam Fonksiyonel Bağımlılıktır.

Örnek:

Partial Functional Dependency (Kısmi Fonksiyonel Bağımlılık)

X niteliği, Y niteliğine bağımlı ve Y’nin bir alt kümesine de bağımlıysa, bu Kısmi Fonksiyonel Bağımlılıktır.

Örnek:

Inference Rules (Çıkarım Kuralları)

Fonksiyonel bağımlılıklarda (functional dependencies) çıkarım kuralları (inference rules), verilen bağımlılık kümelerinden yeni bağımlılıkların türetilmesine olanak tanır.

Reflexivity Rule

Y, X’in bir alt kümesiyse (Y ⊆ X), o zaman X, Y’yi fonksiyonel olarak belirler (X → Y).

Örnek:

{A, B, C} → {B, C} Başlık, Yazar → Başlık

Augmentation Rule

X Y’yi belirliyorsa, X ile Z’nin birleşimi, Y ile Z’nin birleşimini belirler.

X → Y ise, o zaman XZ → YZ.

Örnek: R(ABCD)

A → B ise, o zaman AC → BC.

Transitive Rule

Bir zincirleme bağımlılık ilişkisidir.

X → Y ve Y → Z ise, o zaman X → Z.

{A} → {B} ve {B} → {C} ise, o zaman {A} → {C}.

Union Rule

Bağımlılıkların birleştirilmesini sağlar.

X → Y ve X → Z ise, o zaman X → YZ.

Decomposition Rule

Birleşik bağımlılıkların ayrılmasını sağlar.

X → YZ ise, o zaman X → Y ve X → Z.

Normalization

Normalization, veritabanındaki verilerin düzenlenmesi işlemidir. verilerin tekrarlamasını (redundancy) ve tutarsızlıkları (inconsistencies) azaltmak, veri bütünlüğünü (data integrity) sağlamak amacıyla kullanılan bir süreçtir.

Veritabanı tabloları, belirli normal formlara (normal forms) uyarak normalize edilir. Her bir normal form, belirli bir dizi kurala uymayı gerektirir.

First Normal Form (1NF)

1NF’de her tablo hücresi yalnızca tek bir değer içermeli ve her sütun benzersiz bir isime sahip olmalıdır. Multivalued attribute ve composite attribute 1NF’de yer almaz.

Örnek: CALISAN tablosu

0NF Table

Bu tabloda bulunan CALISAN_TEL ve CALISAN_EMAIL hücresinde birden fazla değer bulunuyor. Bu sebeple buradaki tablo 1NF değildir.

Eğer bu tabloyu 1NF tablosuna dönüştürmek istersek ne yapabiliriz bir bakalım:

1NF Table

Bu sayede birden fazla değere sahip hücreleri kaldırmış oluruz.

Second Normal Form (2NF)

1NF şartlarını sağlamaktadır ve anahtar olmayan her niteliğin Primary Key’e bağlı olmasını gerektirerek, gereksiz verileri ortadan kaldırır.

Bir örnek üzerinden ilerleyerek anlamaya çalışalım:

Hasta_ilaclari tablosu 2NF tablosuna uygun değil çünkü 1NF’in şartlarını karşılasa bile her nitelik Primary Key’e bağlı değildir (PFD). Bu tabloyu 2NF’e uygun hale getirmek ve tekrar eden değerleri azaltmak için PFD’leri ayıralım.

2NF Table

Third Normal Form (3NF)

2NF’in şartlarını sağlar ve non-prime attributes için Transitive Dependency’nin olmaması gerekir.

A → B ve B → C ise A → C Transitive Dependency olarak isimlendirilir. 2NF ilişkilerinin 3NF’ye normalleştirilmesi, Transitive Dependency’lerin kaldırılması ile mümkündür.

Bu tablodaki ilişki OGR_NO → OGR_SEHIR ve OGR_SEHIR → OGR_ULKE

Dolayısıyla OGR_NO → OGR_ULKE Transitive Dependency’dir. Bu 3NF’e aykırıdır. 3NF’e dönüştürmek için ilişkiyi şu şekilde ayrıştıracağız:

Boyce-Codd Normal Form (BCNF)

BCNF aslinda 3NF’in daha gelişmiş halidir. Herhangi bir ilişkinin BCNF olması için öncelikle 3NF şartlarını karşılaması gerekmektedir. Diğer kural ise bir X → Y ilişkisinde, X bir Super Key olmalıdır.

BCNF in DBMS

Aşağıdaki tablo ile bir örnek yapalım:

FD’s = OGR_ID → OGR_BOLUM, OGR_KURS → {BOLUM_NO, OGR_KURS_NO}

Candidate Key’s = {OGR_ID, OGR_KURS}

Yukarıda sunulan tablo BCNF’de değildir, çünkü görebileceğimiz gibi ne OGR_ID ne de OGR_KURS bir Super Key değildir.

Bu tabloyu BCNF haline getirmek için tabloyu ayıralım.

Tabloları ayırdıktan sonra artık BCNF haline gelmiş olur, çünkü Super Key koşulu artık sağlanıyor.