İlişkisel veritabanı teorisinde geçen ve ilişkisel bir veri tabanının hafızayı daha verimli kullanması için geliştirilen normal şekillerden üçüncüsüdür. Bir veri tabanı tasarlanırken veya daha sonradan normalleştirilebilir yani normal form kurallarına uyması sağlanabilir. Bu sayede veritabanının daha az yer kaplaması sağlanmış olur. Ancak bazı durumlarda yerden fedakarlık yapılarak hız ön plana çıkar. Bu durumda normalleştirilmiş bir veritabanının bozulması (denormalization) gerekir. Veritabanımızın üçüncü normal şekle uyması için iki temel kural vardır;
- İkinci normal şekle uymalıdır.
- Bir tablodaki aday anahtar olmayan hiç bir kolon diğer herhangi bir kolunu tanımlayamamalıdır.
Not! Yukarıdaki ikinci şart ile kastedilen şey bir tablodaki anahtarın diğer tüm kolonları tek başına tanımlayabilmesi ama anahtar olmayan bir kolonun diğer herhangi bir kolonu tanımlayamamasıdır.
Örnek:
Çalışanlar Tablosu
id İsim Soyisim Yaş Departman Dahili Tel
1 Berkay Demirel 24 Bilgi İşlem 144
2 Ali Veli 33 Bilgi İşlem 144
3 Mehmet Ahmet 25 Muhasebe 145
Bu tasarımda id bilgisi anahtardır. Id bilgisi isim, soyisim, yaş, departman ve dahili tel bilgilerini tanımlar yani id bilgisini bildiğimiz bir kişinin bu bilgilerine ulaşabiliriz. Diğer bilgilerden örnek olarak isim bilgisi diğer bilgileri tanımlayamaz yani Berkay isminde iki çalışan olduğunu düşünürsek bu çalışanların soyisim, yaş, departman ve dahili tel bilgileri farklı olabilir. Berkay ismini bildiğimizde hangi Berkay çalışanını aradığımızı bilemeyiz. Ancak bu tabloda dahili tel bilgisi departman bilgisini tanımlar ve aynı şekilde departman bilgiside dahili tel bilgisini tanımlar. Yani dahili tel bilgisini bildiğimizde departman bilgisinide öğrenebiliriz. Elimizde 144 dahili tel bilgisi olduğunu düşünürsek bu bilgiden departmanın bilgi işlem olduğunu öğrenebiliriz. Bu yüzden bu iki bilgi arasında fonksiyonel bağımlılık vardır denir ve üçüncü normal forma uymaz.
Çalışanlar Tablosu
İsim Soyisim Yaş Departman
Berkay Demirel 24 144
Ali Veli 33 144
Mehmet Ahmet 25 145
Departman Tablosu
Departman Dahili Tel
Bilgi İşlem 144
Muhasebe 145
Yukarıda görüldüğü üzere bu tasarım hem birinci hem ikinci hem de üçüncü normal forma uyar.
İlişkisel veritabanı teorisinde geçen ve ilişkisel bir veri tabanının hafızayı daha verimli kullanması için geliştirilen normal şekillerden ikincisidir. Bir veri tabanı tasarlanırken veya daha sonradan normalleştirilebilir yani normal form kurallarına uyması sağlanabilir. Bu sayede veritabanının daha az yer kaplaması sağlanmış olur. Ancak bazı durumlarda yerden fedakarlık yapılarak hız ön plana çıkar. Bu durumda normalleştirilmiş bir veritabanının bozulması (denormalization) gerekir. Veritabanımızın ikinci normal şekle uyması için iki temel kural vardır;
- Birinci normal şekle uymalıdır.
- Bir satırı tek başına tanımlayabilecek bir candidate key olmalıdır.
Örnek:
Çalışanlar Tablosu
İsim Soyisim Yaş Departman Dahili Tel
Berkay Demirel 24 Bilgi İşlem 144
Ali Veli 33 Bilgi İşlem 144
Mehmet Ahmet 25 Muhasebe 145
Bu tabloya baktığımızda birinci normal şekle uymadığını görürüz çünkü kişi departman ve dahili tel bilgisi farklı kişiler için tekrar ediyor. İlk önce birinci normal şekle uygun hale getirmek için departman bilgilerini ayrı bir tabloda tutabiliriz.
Çalışanlar Tablosu
İsim Soyisim Yaş Departman
Berkay Demirel 24 144
Ali Veli 33 144
Mehmet Ahmet 25 145
Departman Tablosu
Departman Dahili Tel
Bilgi İşlem 144
Muhasebe 145
Yukarda görüldüğü üzere tasarım birinci normal şekle uygun hale getirildi. Departman talosuna bir id (anahtar) bilgisini eklememizin nedeni dahili tel numarasının zaten her bir satır için farklı olacağıdır. Burada dikkat edilmesi gereken şey her bilgi bir satırı tek başına ifade edebiliyor olsa bile o bilginin anahtar olarak kullanılamayacağıdır. Örneğin kişinin e-posta adreside herkes için farklıdır ancak bu bilgi anahtar olarak kullanılmamalıdır. Çünkü bu bilgi bir sayıya göre hafıza daha fazla yer kaplar ve ilişki kuralacak her iki tabloda da bulunması gerektiğinden gereksiz olacaktır. Bu yüzden genelde anahtarlar sayısal değer olarak tutulurlar. Ayrıca anahtarlar üzerinde indeks oluşturulduğundan sayısal değerler kullanılması çok daha uygun olacaktır. Burada dahili tel vereceğimiz id bilgisi gibi hem sayısal bir değer olduğundan hem de id bilgisi gibi çok büyük bir sayısal değerden oluşmadığından dolayı (örnek olarak 30 haneli bir sayısal değerin de anahtar olarak kullanılması çok uygun değildir) id bilgisi olarak kullanılabilir.
Bu tasarımın ikinci normal şekle uyması için ikinci şart olan bir candidate key belirlenmesi gerekir. Yukarıdaki tasarımda çalışanlar tablosundaki her satırı tanımlayan bir anahtar yoktur.
Çalışanlar Tablosu
id İsim Soyisim Yaş Departman
1 Berkay Demirel 24 144
2 Ali Veli 33 144
3 Mehmet Ahmet 25 145
Departman Tablosu
Departman Dahili Tel
Bilgi İşlem 144
Muhasebe 145
Yukarıdaki tasarımı incelediğimizde ikinci normal şekle uygun halde olduğunu görebiliriz. Çalışanlar tablosu için id, departman tablosu içi dahili tel bilgisini anahtar olarak belirledik ve bu bilgiler bulundukları satırı tek başına tanımlayabiliyorlar. Ayrıca bu tasarım birinci normal şekle de uyduğu için ikinci normal şekle uyduğunu söyleyebiliriz.
İlişkisel veritabanı teorisinde geçen ve ilişkisel bir veri tabanının hafızayı daha verimli kullanması için geliştirilen normal şekillerden en ilkelidir. Bir veri tabanı tasarlanırken veya daha sonradan normalleştirilebilir yani normal form kurallarına uyması sağlanabilir. Bu sayede veritabanının daha az yer kaplaması sağlanmış olur. Ancak bazı durumlarda yerden fedakarlık yapılarak hız ön plana çıkar. Bu durumda normalleştirilmiş bir veritabanının bozulması (denormalization) gerekir. Veritabanımızın ilk normal şekle uyması için iki temel kural vardır;
- Veritabanında bulunan ilişkili tabloların aralarında ilişki (bağlantı, join) kurulabilir şekilde tasarlanması.
- Tablolarda veri tekrarı bulunmaması.
Örnek:
Bir telefon defteri uygulaması tasarladığımızı düşünelim. Tablomuzda isim, soyisim ve telefon bilgilerini tutuyor olalım. Tablomuzdaki bir satır şu şekilde olabilir;
İsim Soyisim Telefon
Berkay Demirel 5454444444
Buraya kadar her şey normal gözüksede eğer bir kişinin ikinci telefonu varsa ve biz bu bilgiyi veritabanına eklemek istersek o zaman bir satır daha eklememiz gerekir. Bu durumda veritabanımız şu şekilde olur;
İsim Soyisim Telefon
Berkay Demirel 5454444444
Berkay Demirel 5453333333
Burada görüldüğü üzere bir kişinin iki telefonu var ve bu bilgi veritabanında saklanabiliyor ancak verilerimiz tekrar ediyor. Bu durumu tablomuza telefon2 adlı bir kolon ekleyerek çözebilirdik ancak ya sayısını bilmediğimiz kadar veri girişi olacaksa ne olacağıdır. Yani kişilerin 3. ve 4. telefon bilgileride varsa ne olacak her seferinde yeni bir kolon mu ekleyeceğiz. Diyelim ki kolon ekledik ve problemi çözdük. Bu durumda da tek bir telefonu olan kişilerin 2. 3. ve 4. telefon bilgisi kolonları boş kalacak ve hafıza gereksiz yer kaplayacaklar. Bu durumun en iyi çözümü telefon bilgisini ayrı bir tabloda tutmak ve bu iki tablo arasında ilişki kurmaktır.
Kişi Tablosu
id İsim Soyisim
1 Berkay Demirel
2 Ali Veli
Telefon Tablosu
id Telefon
1 5454444444
1 5453333333
2 5452222222
Yukarıda görüldüğü üzere Berkay Demirel'in telefon numaralarına erişmek sitediğimizde kişinin id bilgisini kullanarak telefon tablosundan telefon bilgilerini getirebiliriz. Bu şekilde bir tasarım yaparak veritabanımızı birinci normal forma uygun hale getirdik.
Not! Bu şekilde verilerimizi iki tabloya bölmek bize hafıza olarak kazanç sağlar. Eğer daha hızlı erişim istiyorsak denormalization yapılarak veriler tek tabloda tutulabilir.
Verilerin büyümesi ve karmaşıklaşması ile birlikte 1980'lerin sonunda geleneksel ER Modelini veritabanı modellemesi için kullanmak gittikçe zorlaşmıştır. Bu nedenle, mevcut ER Modelin ile karmaşık uygulamaları daha iyi ele almayı sağlamak için bazı iyileştirmeler veya geliştirmeler yapılmıştır. Bu geliştirmeler ile birlikte mevcut ER Modeline üç yeni kavram eklenmiştir. Bunlar;
- Generalization
- Specialization
- Aggregration
Generalization
Generalization, iki düşük seviyeli varlığın daha yüksek seviyeli bir varlık oluşturmak için birleştiği aşağıdan yukarıya bir yaklaşımdır. Generalization'da, yüksek seviyeli varlık daha yüksek seviyeli varlık oluşturmak için diğer düşük seviyeli varlıklar ile birleştirilebilir.
Daha çok Süper Sınıf ve Alt Sınıf sistemine benzeen bu yaklaşımın tek farkı aşağıdan yukarıya doğru olmasıdır. Dolayısıyla varlıklar daha genel bir varlık oluşturmak üzere birleştirilir, başka bir deyişle, alt sınıflar bir süper sınıf oluşturmak için birleştirilir.
Örneğin, birikim ve cari hesap türleri varlıkları genelleştirilebilir ve her ikisini de kapsayan, hesap adında bir varlık yaratılabilir. Bu alt tablonun ortak özellikleri ana tabloya eklenir ve alt tablolara o tablolara özel bilgiler eklenir. Örnek verecek olursak hesap numarası ortaktır ve hesap tablosuna koyulabilir ancak birikim tablosunun kendine ait özelliği olan vade bilgisi birikim hesap türüne ait tabloya eklenir.
Specialization
Specialization, Generalization'ın tam tersidir denilebilir. Bir üst seviye varlığın iki alt seviye varlığa bölünebileceği yukarıdan aşağıya doğru olan bir yaklaşımdır.
Örneğin eski ve yeni tüm öğrencileri bir tabloda tutmak yerine öğrenci bilgilerini mevcut öğrenciler ve eski öğrenciler adında iki tabloya bölebiliriz.
Aggregration
Aggregration, iki varlık arasındaki ilişkinin tek bir varlık olarak değerlendirildiği bir süreçtir.
Yukarıdaki şemada, kurs merkezi ve kurs arasındaki ilişki başka bir varlık olan ziyaretçi ile ilişki içinde olan bir varlık olarak hareket etmektedir. Yani kurs almak isteyen kişiler kurs bilgisine veya kurs merkezi bilgisine doğrudan erişemeyecek bu iki bilginin birleşimine erişebilecektir. Örneğin kurs almak isteyen kişi modeli kadıköy şubesi bilgisine erişemeyecek veya veritabanı kursu bilgisine erişemeyecektir. Ancak bu kişi modeli kadıköy şubesindeki veritabanı kursu bilgisine erişebilecektir.
Normalizasyon, veritabanımızın verileri daha verimli tutmasını sağlayan kurallar setidir. Normalizasyon ile veritabanındaki tekrarlı veriler ortadan kalkar, veri tutarlılığı artar ve çoğu zaman veritabanı işlemleri hızlanır. Ayrıca veritabanı üzerinde yapılan silme ve güncelleme gibi işlemlerde oluşabilecek zorluklar veya problemler ortadan kalkar.
Normalizasyon, veritabanlarına seviyelerle uygulanır. Bir veritabanının normal formlardan herhangi birine uygun olduğunu söyleyebilmek için, söz konusu normal formun tüm kriterlerini eksiksiz yerine getiriyor olması şarttır.
Basitçe tanımlamak gerekirse, normal formlar normalizasyon seviyeleridir. Bu seviyeler gereksiz veri tekrarlarını ne derecede engellediği ve tutarlılığı ne kadar sağladığına bağlı olarak derecelendirilir. Seviye yükseldikçe veri tutarlılığı artar, veri tekrarı düşer.
Normalizasyon seviyeleri 1NF (Birinci Normal Form), 2NF, 3NF, BCNF(Boyce-Codd Normal Form, 3.5NF'de denir), 4NF şeklinde adlandırılır ve yukarı doğru devam eder. Ancak daha yukarı normalizasyon seviyeleri çok nadiren kullanılır çünkü çoğu zaman uygulanması mümkün olmayabilir.
- Birinci Normal Şekil (First Normal Form - 1NF)
- İkinci Normal Şekil (Second Normal Form - 2NF)
- Üçüncü Normal Şekil (Third Normal Form - 3NF)
- Boyce Codd Normal Form (BCNF)
- Dördüncü Normal Şekil (Fourth Normal Form - 4NF)
Super Key
İlişkisel veritabanlarında var olan bir anahtar çeşidi olan super key bir satırı temsil eden kolonlara denir. Örnek verecek olursak bir kişi tablosunda kişilerin adı, soyadı ve telefon bilgisi birleşerek bir kişiyi temsil edebilir. Bu üç kolon birleşerek bir super key oluşturabilir. Aynı şekilde kişinin adı, soyadı, telefonu ve adreside bir kişiyi temsil edebileceği için bu dört kolon da bir super key olur. Bu şekilde bir kişiyi temsil edebilecek tüm kolonların kombinasyonları super key olabilir.
Candidate Key
İlişkisel veritabanlarında var olan bir anahtar çeşidi olan candidate key alt kümesi bir super key olmayan candidate key'lere denir. Örnek verecek olursak yukarıda kişinin adı, soyadı, telefonu ve adresi bir kişiyi temsil edebilir bu yüzden super key olabilir demiştik ancak bu dört kolon bir candidate key değildir. Çünkü kişinin ad, soyad ve telefon bilgileride bir super key'dir. Bir super key'in candidate key olması için hiç bir alt kümesi super key olmamalıdır. Kişinin ad, soyad ve telefon bilgileri de bir super key olabilir çünkü telefon bilgiside bir kişiyi tek başına tanımlamak için yeterlidir. Her kişinin telefon bilgisi ayrı olacağı için ve bu key'in alt kümelerinden hiç biri super key olmayacağı için(tek elemanlı bir küme olduğu için zaten alt kümesi yoktur ancak olabilirdi de) telefon bilgisi bir candidate key'dir.
Primary Key
İlişkisel veritabanlarında var olan bir anahtar çeşidi olan primary key bir tablodaki her kaydı temsil edebilecek bizim seçtiğimiz bir candidate key'dir. Örnek verecek olursak kişilerin telefon bilgisi veya tc kimlik bilgisi her kişi için ayrıdır. Bu iki bilgiden birisini primary key olarak seçebiliriz ve daha sonra bir kişinin bilgilerine erişmek için seçtiğimiz bu primary key bilgisini kullanırız. Primary key'lerin özellikleri şunlardır;
- Birden fazla kolonun birleşiminden oluşabilirler.
- Tabloda sadece bir tane primary key olabilir.
- Null değer içeremezler.
- Primary key olan kolona veya kolonların birleşimine farklı satırlarda aynı bilgiler girilemez.
Foreign Key
İlişkisel veritabanlarında var olan bir anahtar çeşidi olan foreign key iki tabloyu birbirine bağlamamızı sağlayan bir key çeşididir. Foreign key, başka bir tablodaki primary key bilgisine karşılık gelen bilgidir. Örnek verecek olursak kişi bilgileri tablosu ile adres tablosu düşünecek olursak kişi tablosu ana tablo adres tablosu alt tablo olur. Ana tablodaki primary key bilgisi ile alt tablodaki froign key bilgisi aynı bilgilerdir. Bu iki tablodaki key'ler aynı olan veriler birbiri ile ilişkilidir denir ve birleştirilerek kullanılabilir.
- Bire bir
- Bire çok
- Çoka çok
İlişkisel veritabanındaki ilişkilere geçmeden önce bilinmesi gereken çok önemli iki kavram vardır.
- Birincil Anahtar (Primary Key): Tablolarda benzersiz kayıtlar elde etmemizi sağlayan sütuna verilen addır.
- İkincil Anahtar (Foreign Key): Bir tabloda benzersiz kayıt oluşturmayı sağlayan sütunun diğer tabloda bir sütun olarak bulunmasına denir.
Bire Bir İlişki Türü
Eğer bir tablodaki verinin diğer tabloda ilişkili olduğu veri bir tane ise bu iki tabloda bire bir ilişki var demektir. Örnek verecek olursak kişiler tablosunun ilişkili olduğu kimlik bilgileri tablosu arasında bire bir ilişki vardır. Burada dikkat edilmesi gereken her kimlik bilgisi için de bir kişinin olması gerektiğidir. Yani bir kişinin kimlik bilgileri bir tane olmalı ve her kimlik bilgisi için bir kişi olmalıdır. Bu durumda iki tablo arasında bire bir ilişki kurulur.
SQL'de ise bu ilişkiler iki tablonun primary key bilgileri karşılaştırılarak kurulur. Yani örnek verecek olursak kişiler tablosundaki kisi_id ile kimlik bilgileri tablosundaki kisi_id bilgileri aynı olan kayıtlar ilişkilidir denilebilir.
Bire Çok İlişki Türü
Eğer bir tablodaki verinin diğer tabloda ilişkili olduğu veri birden çok ise bire çok ilişki var demektir. Örnek verecek olursak kişiler tablosunun ilişkili olduğu araç bilgileri tablosu arasında bire çok ilişki vardır. Yani bir kişinin araç bilgileri birden çok olabilir, kişinin birden çok aracı bulunabilir. Burada dikkat etmemiz gereken ikinci konu ise araç tablosunun kişi tablosu ile ilişkisidir. Yani her aracında bir sahibinin olması gerektiğidir. Eğer bir aracın birden çok sahibi olsaydı burada bire çok ilişki olacaktı. Çünkü hem bir kişinin birden çok arabası olabiliyor olacaktı hem de her arabanın birden çok sahibi olacaktı. Ancak bir arabanın bir sahibinin olacağını düşündüğümüz için burada bire çok ilişki vardır. Bu yüzden bu iki tablo arasında bire çok ilişki kurmamız gerekir.
SQL'de ise bu ilişkiler birinci tablonun primary key bilgisi ile ikinci tablonun foreing key bilgisi arasında karşılaştırma yapılarak kurulur. Yani örnek verecek olursak kişiler tablosundaki kisi_id bilgisi ile araçlar tablosuna ekleyeceğimiz kisi_id adlı foreing key bilgisi karşılaştırılarak ilişkili kayıtlar bulunur.
Çoka Çok İlişki
İlişkisel veritabanında olmasını istemediğimiz ilişki türüdür. Bu ilişki türü normalizasyon ile bire çok ilişkilere dönüştürülür. Bu ilişki türü eğer birinci tablodaki bir verinin ikinci tabloda ilişkili olduğu birden çok veri varsa ve aynı şekilde ikinci tablodaki bir verinin de birinci tabloda ilişkili olduğu birden çok veri varsa ortaya çıkar. Örnek verecek olursak kişi tablosu ile adres tablosudur. Bir kişinin birden çok adresi olabileceği gibi bir adreste de birden çok kişi yaşayabilir.
SQL'de bu ilişki iki tablo arasına bir tablo ekleyerek gerçekleştirilir. Bu şekilde çoka çok ilişki iki adet bire çok ilişkiye dönüştürülür. Örnek verecek olursak kişiler tablosundaki kişi_id bilgisi ile adres tablosundaki adres_id bilgileri ayrı bir tabloda da tutulur. Bu şekilde kişiler ve adres tabloları arasında doğrudan bir ilişki olmaz bu iki tabloda araya eklediğimiz tablo ile ilişkili olur. Araya eklediğimiz tabloya adres kaydı dersek kişiler tablosundaki bir kişinin birden çok adres kaydı olacaktır ancak her adres kaydı sadece bir kişi ile ilişkili olacaktır. Aynı şekilde adres tablosu ile adres kaydı tablosu arasında da bire çok ilişki olur. Adres tablosundaki her adresin birden çok adres kaydı olabileceği gibi adres kaydı tablosundaki her adres kaydı bilgisinin bir adresi olacaktır. Bu örnekte bir kişinin adres bilgisine erişmek istediğimizde önce o kişinin adres kaydı bilgilerini bulmamız gerekir. Daha sonra her adres kaydı bilgisi için adres bilgisini bulabiliriz. Bu şekilde bir kişinin adres bilgilerini getirebiliriz. Aynı şekilde her adres için o adresin adres kayıt bilgilerini getirebiliriz. Daha sonra her adres kaydı bilgisinin ilişkili olduğu kişi bilgilerini getirerek o adreste yaşayan kişileri bulabiliriz.
Veritabanı tasarımında en sık kullanılan tekniklerden bir tanesi olan ER(Entity Relationship) modeli,ilişkisel veritabanı yaklaşımının temelini oluşturmaktadır. ER modeli oluşturulacak veritabanı nesneleri arasında ilişki kurarak,nesnelerin özelliklerini ortaya koyar. Bir ER modelinde 3 temel kavram yer alır.
- Varlık(Entity)
- Nitelik(Attiribute)
- İlişki(Relationship)
Varlık(Entity)
Varlık(Entity),veritabanında oluşturulacak nesneleri temsil eden yapılardır.Genel olarak veritabanında bu nesnelere tablolar örnek verilebilir.Programlama alanında ise sınıflar(class) varlıklara birer örnektir.ER diyagramlarının temelini varlıklar oluşturur.
Nitelik(Attiribute)
Nitelik(Attiribute),ER varlıklarının sahip olduğu her bir alana verilen yapılardır.Varlıkların sahip olduğu parçaları oluşturan bileşenlere denir.Veritabanı alanında örnek olarak tablo sütünları verilebilir.Programlama alanında ise sınıf üye değişkenleri(class member variable) bunun için birer örnektir.
İlişki(Relationship)
İlişki(Relationship),varlıklar arasında kurulan fiziksel ve mantıksal bağlantıları temsil eden yapılara denir.ER diyagramlarında varlıkları arasındaki ilişkileri tanımlar.
ER Diagramları Nasıl Oluşturulur?
Bir veritabanı tasarımında gerekli analizler yapıldıktan sonra ER diyagramı oluşturulur.Bir ER diyagramında ilk olarak Varlıklar belirlenir. Daha sonra her varlığın nitelikleri belirlenir. Belirlenen nitelikler arasında oluşturulan primary key nitelik altı çizili şekilde belirtilir. Bu işlemler yapıldıktan sonra varlıklar arasında ilişkiler oluşturulur. Daha sonra çizilen bu ER diagramın normalizasyon kurallarına uygunluğu incelenir. Uygun olmayan kısımlar düzeltilerek ER diagramı tamamlanır.
- Varlıklar belirlenir.
- Varlıkların nitelikleri belirlenir.
- Varlıklar arasındaki ilişkiler belirlenir.
- ER diyagramı çizilir.
- Tasarlanan ER diyagramı gerekli normalizasyon filtresinden geçirilir.
- Gerekirse ER tasarımı tekrardan çizilir.
Kullanıcı Yetkilendirme
Sql tablolarımızı birden fazla kullanıcı kullanabilir ve bu kullanıcıların tablolar üzerinde tüm işlemleri yapmasını genelde istemeyiz. Bu gibi durumlarda kullanıcılara yetkiler tanımlayarak tablolar üzerinde yaptıkları işlemleri sınırlayabiliriz.
Tablolar Üzerinde Hangi İşlemler İçin Yetki Tanımlanabilir?
- Read (Tablodan veri okuma)
- Insert (Tabloya veri yazma)
- Update (Tablodaki verileri güncelleme)
- Delete (Tablodaki verileri silme)
- Index (Tablo üzerinde index tanımlayabilme)
- Resources (Tablolar üzerinde ilişki tanımlayabilme)
- Alteration (Tablonun değiştirilmesi)
- Drop (Tablonun silinmesi)
Tablo Üzerinde Nasıl Yetki Tanımlanır?
GRANT yetki ON tablo_adi TO kullanicilar
Örnek:
GRANT delete ON ogrenciler TO Berkay, Ahmet
Not: Yetki alanında 'all privileges' ifadesi kullanılarak tüm yetkiler tanımlanabilir.
Verilen Yetkiler Nasıl Geri Alınır?
Verilen yetkilerin geri alınması için revoke ifadesi kullanılır.
REVOKE yetki ON tablo_adi FROM kullanicilar
Örnek:
REVOKE delete ON ogrenciler FROM Berkay
Rol Tanımlama
Genellikle veritabanı üzerinde işlem yapan kullanıcıların benzer yetkileri olur. Yani aynı işi yapan birden çok kişi olabilir. Örnek verecek olursak veritabanı üzerinden veri okuyarak rapor oluşturan onlarca kişi olabilir. Bu gibi durumlarda her kullanıcı için ayrı ayrı yetki tanımlaması yapmak yerine rol tanımlaması yapılabilir. Bu rollere yetki tanımlaması yapılabilir ve kullanıcılara yetki vermek yerine rol verilebilir.
Rol Tanımlama Nasıl Yapılır?
CREATE ROLE rol_ismi (Rol Oluşturma)
GRANT yetki ON tablo_adi TO rol_adi (Role Yetki Atama)
GRANT rol_adi TO kullanicilar (Role Kişi Atama)
Örnek:
CREATE ROLE raporlama_yapanlar
GRANT select ON siparisler TO raporlama_yapanlar
GRANT raporlama_yapanlar TO Berkay, Ahmet, Ali
Rol Tanımından yetki Nasıl Silinir?
REVOKE yetki FROM rol_adi
Rol Tanımı Nasıl Silinir?
DROP ROLE rol_adi
View Üzerine Rol Tanımlaması Yapılabilir mi?
View üzerine rol tanımlaması yapmak mümkündür. Tablo adı yerine view adı yazılarak view üzerine rol tanımlaması yapılabilir.
Örnek:
SELECT CustomerID, COUNT(*) AS "Satış Sayısı",
RANK() OVER(ORDER BY COUNT(*) DESC) AS "Rank ile Sıralama",
ROW_NUMBER() OVER(ORDER BY COUNT(*) DESC) AS "Normal Sıralama",
DENSE_RANK() OVER(ORDER BY COUNT(*) DESC) AS "Dense_Rank ile Sıralama"
FROM Sales.SalesOrderHeader
GROUP BY CustomerID
ORDER BY COUNT(*) DESC;
Not! Görsel http://www.ismailgursoy.com.tr sitesinden alıntıdır.
Veritabanı tablolarında bazı olaylar meydana geldiğinde çalışan küçük kod parçalarına trigger denir. Bu olaylar insert, update ve delete işlemleridir.
Trigger Ne Zaman Kullanılır?
- Değişiklikleri takip etmek,
- Birincil anahtar üretmek,
- Karmaşık iş kurallarını gerçekleştirmek,
- E-posta atmak gibi olayları otomatik olarak yapmak,
- Standart hata mesajlarının dışında bir hata mesajı elde etmek,
- Veritabanı erişimlerini takip edebilmek,
- Nesnede meydana gelebilecek değişiklikleri takip ve engellemektir.
- After Triggerler: After triggerler, kendiyle ilişkili işlem gerçekleştikten hemen sonra ateşlenir. Sadece tablolar için tanımlanabilir.
- Instead Of Triggerler: Belirlenen işlem gerçekleşirken devreye girer ve kendi içinde tanımlanan komutları icra etmeye başlar. Yani, belirlenen işlemin yerine geçer. After tetikleyicileri sadece tablolar için tanımlanabilirken Instead Of tetikleyicileri hem tablolar için hem de view’ler için tanımlanabilirler.
CREATE TRIGGER trigger_adi
ON tablo_adi
AFTER veya INSTEAD OF (INSERT veya UPDATE veya DELETE)
AS
Sql ifadeler
Trigger silmek:
drop trigger trigger_adı
Örnek:
create trigger InsertTrigger
on urunler
after insert
as
print ('insert trigger tetiklendi...')