3. Varlık-İlişki Modelini kullanarak Veri Modelleme (Data Modeling Using the Entity-Relationship (ER) Model) 3.1. Database’in Tasarımı için Yüksek seviye Kavramsal Veri Modeli Kullanımı (Using High-Level Conceptual Data Models for Database Design) 3.2. Basit Database Uygulaması (A Sample Database Application) 3.3. Varlık Çeşitleri, Varlık Kümeleri, Nitelikler, ve Anahtarlar (Entity Types, Entity Sets, Attributes, and Keys) 3.3.1. Varlıklar, Nitelikler (Entities and Attributes) 3.3.2. Varlık Çeşitleri, Varlık Kümeleri, Anahtarlar ve Değer Kümeleri (Entity Types, Entity Sets, Keys, and Value Sets) 3.3.3. Şirket Database’in İlk Kavramsal Tasarımı (Initial Conceptual Design of the COMPANY Database) 3.4. İlişki Çeşitleri, İlişki Kümeleri, Rolleri ve Yapısal Kısıtlar (Relationship Types, Relationship Sets, Roles, and Structural Constraints) 3.4.1. İlişki Türleri, Kümeleri ve Örnekleri (Relationship Types, Sets, and Instances) 3.4.2. İlişki Dereceleri, Rol İsimleri ve Kendine Dönen İlişki (Relationship Degree, Role Names, and Recursive Relationships)

3.4.3. Binary İlişki Çeşitleri üzerindeki Kısıtlar (Constraints on Binary Relationship Types) 3.4.4. İlişki Çeşitlerinin Nitelikleri (Attributes of Relationship Types) 3.5. Zayıf Varlık Çeşitleri (Weak Entity Types) 3.6. Şirket Database’i için ER Tasarımının İrdelenmesi (Refining the ER Design for the COMPANY Database) 3.7. ER Diyagramları, Tasarım Sorunları (ER Diagrams, Naming Conventions and Design Issues) 3.7.1. ER Diyagramları için Notlar (Summary of Notation for ER Diagrams) 3.7.2. Şema Yapılarının Doğru İsimlendirilmesi (Proper Naming of Schema Constructs) 3.7.3. ER Kavramsal Tasarımı için Tasarım Seçenekleri (Design Choices for ER Conceptual Design) 3.7.4. ER Diyagramları için Alternatif Notlar (Alternative Notations for ER Diagrams) 3.8. Diğer Notların Örnekleri; UML Class Diyagramları (Example of Other Notation:UML Class Diagrams) 3.9. İkiden Yüksek Dereceli İlişki Çeşitleri (Relationship Types of Degree Higher than Two) 3.9.1. Binary ve Ternary (1,2,3) (yada Yüksek Dereceli) İlişki arasındaki Seçim (Choosing between Binary and Ternary (or Higher-Degree) Relationships) 3.9.2. Ternary (yada Yüksek Dereceli) İlişki üzerindeki Kısıtlar Constraints on Ternary (or Higher-Degree) Relationships

3. Varlık-İlişki Modelini kullanarak Veri Modelleme (Data Modeling Using the Entity-Relationship (ER) Model) Kavramsal modelleme başarılı bir veritabanı uygulaması tasarımında çok önemli bir aşamadır. Genellikle veritabanı uygulaması, belirli bir veritabanını ve veritabanı sorguları ve güncellermeleri uygulayan ilişkili programları niteler. Örneğin, Bank veritabanı uygulaması. Müşterinin para yatırma ve çekme gibi veritabanı güncellemeleri içeren işlemler ile müşteri hesaplarını izler. Bu programlar, formlar ve menüler içeren ve son kullanıcılar için kullanıcı dostu grafik arayüzleri (GUI) kullanan uygulamalar sunar.Bu nedenle, veritabanı uygulamasının önemli bir kısmı bu uygulama programlarının tasarımı, uygulanması ve test edilmesidir. Geleneksel olarak, uygulama programlarının tasarım ve testi veritabanı tasarımı yerine yazılım mühendisliğinin bir bölümü olarak kabul edilmiştir. Birçok yazılım tasarım aracında, yazılım mühendisliği metodolojileri ve veritabanı tasarım metodolojileri iç içedir. .Bu bölümde, kavramsal veritabanı tasarımı sırasında veritabanı yapıları ve kısıtlamalar üzerinde yoğunlaşarak geleneksel yaklaşımı takip edeceğiz. Uygulama programlarının tasarımı genelde yazılım mühendisliği derslerinin içeriğidir. Popüler bir üst düzey kavramsal veri modeli olan Varlık-İlişki (ER) modelinin modelleme kavramlarını sunacağız. ER modelinin temel veri yapıları kavramlarını ve kısıtlamalarını tanımlayıp, veritabanı uygulamaları için kavramsal şemaların tasarımında kullanımlarını tartışacağız. Bir de ER diyagramları olarak da bilinen ER modeli ile ilişkili şematik gösterimini sunacağız. Unified Modeling Language (Birleşik Modelleme Dili) (UML) gibi nesne modelleme metodolojileri veritabanı ve yazılım tasarımında giderek daha popüler hale gelmektedir. Bu metodolojiler yazılım modüllerinin ve çeşitli diyagramlar kullanarak bunların etkileşimlerinin detaylı tasarımını belirtmek için veritabanı tasarımının bir adım ötesine geçer. Bu metodolojilerin önemli bir kısmı ER şemalarına sınıf diyagramları gibi birçok yönden benzer.Sınıf diyagramları, objeler üzerinde işlemler ve ek olarak veri tabanı şema yapısı belirtir.

3.1. Database’in Tasarımı için Yüksek seviye Kavramsal Veri Modeli Kullanımı (Using High-Level Conceptual Data Models for Database Design) Şekil 7.1 veritabanı tasarım sürecinin basitleştirilmiş genel bakışını gösterir. İlk adım gereksinim toplama ve analizini gösterir. Bu adım sırasında, veritabanı tasarımcıları olası veritabanı kullanıcılarını anlamak için onlarla görüşür ve onların veri gereksinimlerini dökümante eder. Bu adımın sonucu kullanıcıların gereksinimlerinin kısaca yazılı kümesidir. Veri gereksinimlerini belirleme işlemine paralel olarak uygulamanın fonksiyonel gereksinimlerini de belirlemek yararlı olacaktır. Yazılım tasarımında, fonksiyonel istekleri belirlemek için veri akış diyagramı, dizi diyagramlar, senaryolar ve diğer tekniklerin kullanımı yaygındır. Gereksinimler toplanıp ve analiz edildikten sonra, bir sonraki adım üst düzey bir kavramsal veri modeli kullanılarak, veritabanı için kavramsal bir şema oluşturmaktır. Bu adım kavramsal tasarım olarak adlandırılır. Kavramsal şema, kullanıcıların veri gereksinimlerinin kısa bir açıklamasıdır ve varlık türlerinin,ilişkilerin ve kısıtlamaların ayrıntılı açıklamalarını içerir ve bu üst düzey veri modeli tarafından sağlanan kavramlar kullanılarak ifade edilir. Bu kavramlar uygulama detaylarını içermediği için, genellikle daha kolay anlamak ve teknik olmayan kullanıcılar ile iletişim kurmak için de kullanılabilir.

3.2. Basit Database Uygulaması (A Sample Database Application) Üst düzey kavramsal şema, tüm kullanıcıların veri gereksinimlerinin karşılamak ve bu gereksinimlerle çatışmamak için bir referans olarak kullanılabilir. Bu yaklaşım, depolama ve uygulama detaylarıyla ilgilenmeden, veritabanı tasarımcılarının verinin özelliklerinin belirlenmesine yoğunlaşmasını sağlar. Kavramsal şema tasarımı sırasında veya sonrasında, temel veri modeli işlemleri fonksiyonel analiz sırasında belirlenen üst düzey kullanıcı sorguları ve işlemleri belirtmek için kullanılır. Bu aynı zamanda kavramsal şemanın tüm fonksiyonel gereksinimleri karşıladığını doğrulamak için hizmet vermektedir. Eğer bazı fonksiyonel gereksinimler initial şema kullanılarak belirlenemez ise kavramsal şemada yapılan değişiklikler devreye girer. Veritabanı tasarımdaki sonraki adım DBMS kullanılarak veritabanının gerçek uygulamaya geçirilmesidir. En güncel ticari DBMSler bir uygulama veri modeli kullanır.- örneğin; ilişkisel veya nesne-ilişkisel veritabanı model - Böylece kavramsal şema üst seviye veri modelinden uygulama veri modeline dönüştürülür. Bu adım mantıksal tasarım ya da veri modeli mapping denir; sonuç DBMSin uygulama veri modelinde bir veritabanı şemasıdır. Veri modeli mappingi genellikle veritabanı tasarım araçları içinde otomatik veya yarı otomatiktir. Son adım veritabanı dosyalarını belirlemek için dahili depolama yapıları, dosya organizasyonu, indeksler, erişim yolları boyunca fiziksel tasarım parametreleridir. Bu çalışmalara paralel olarak, uygulama programları tasarlanmış ve üst seviye işlem özelleştirmelere karşılık gelen veritabanı işlemleri olarak uygulamıştır. Bu bölümde kavramsal şema tasarımı için sadece temel ER modeli kavramlarını sunacağız. 3.2. Basit Database Uygulaması (A Sample Database Application) Bu bölümde COMPANY adında ER modeli kavramının ve şema tasarımında kullanımının örneklendirilmesi için basit bir veritabanı uygulaması inceleyeceğiz. Veritabanı için veri gereksinimlerini listeleyecek ve ER modelinin modelleme kavramını sunmak için adım adım kavramsal şema oluşturacağız. COMPANY veritabanı şirketin elemanlarını, departmanlarını ve projelerini inceler.

Gereksim toplamasından ve analizinden sonra, veritabanı tasarımcısı miniworldün tanımlarını yapar. Şirket departmanlardan oluşur. Her departman unique (tekil) bir isme, unique bir numaraya sahiptir. Departmanlar her biri tekil isime, tekil numaraya ve tek bir konuma sahip birçok projeyi kontrol eder. Her bir çalışanın ismi, sosyal güvenlik numarası, adresi, maaşı, cinsiyeti ve doğum tarihi depolanır. Her çalışan bir bölüme aittir fakat aynı departmanın kontrol etmediği çeşitli projeler üzerinde çalışabilir. Bir çalışanın hangi proje üzerinde haftada ne kadar çalıştığını izleyebiliriz.Her bir çalışanın yine çalışan olarak sayılan yöneticisi vardır. Sigorta bilgilerini oluşturmak için her bir çalışanın bağımlılığını takip etmeliyiz. Bu yüzden bağımlılık altında ilk isim, cinsiyet, doğum tarihi ve ilişki gibi bilgiler tutulur. Şekil 7.2de şema, database uygulaması için ER diyagramları olarak bilinen grafiksel gösterimi vasıtasıyla nasıl görüntülenebilir olduğunu gösterir. 3.3. Varlık Çeşitleri, Varlık Kümeleri, Nitelikler, ve Anahtarlar (Entity Types, Entity Sets, Attributes, and Keys) 3.3.1. Varlıklar, Nitelikler (Entities and Attributes) ER modelini temsil eden basit nesne entitydir. (nesne) Bu nesne gerçek dünya da bağımsız bir varlıktır. Belli bir kişi, araba, ev veya çalışan gibi fiziksel bir varlık olabileceği gibi, şirket, iş, üniversite dersi gibi kavramsal varlıklar da olabilir. Her varlık belirli özelliklere sahiptir. Örneğin çalışan varlığı çalışanın adı, yaşı, adresi, maaş ve işi gibi niteliklere sahip olabilir.

Her bir varlığı tarif eden nitelik değerleri veritabanında depolanmış verinin önemli bir parçası haline gelir. Şekil 7.3 iki varlık ve onların niteliklerinin değerlerini gösterir. EMPLOYEE varlığı e1 dört niteliğe sahiptir. Name, Address, Age, and Home_phone nitelikleri sırasıyla ‘John Smith,’ ‘2311 Kirby, Houston, Texas 77001’, ‘55’, and ‘713-749-2630’ değerlerini alır. COMPANY varlığı c1 3 niteliğe sahiptir; Name, Headquarters, and President; nitelikleri sırasıyla ‘Sunco Oil’, ‘Houston’, and ‘John Smith değerlerini alır. ER modelinde niteliklerin birkaç çeşidi ortaya çıkar: karmaşığa karşı basit, çok değerliliğe karşı tek değerlilik ve türetilmişe karşılık depolanmış. İlk olarak bu nitelik çeşitlerini tanımlayacağız ve örnekler aracılığıyla kullanımı göstereceğiz.Daha sonra bir nitelik için Null (boş) değerinin kavramını tartışacağız. Simple (Atomic) versus Composite Attributes (Birleşiğe karşılık Basit Nitelik);Birleşik nitelikler daha küçük, basit ve bağımsız anlamlarla nitelendirilebilecek alt parçalara bölünebilirler. Örneğin, Şekil 7.3 gösterilen EMPLOYEE varlığının Address niteliği değerleri '2311 Kirby', 'Houston', 'Texas' ve '77001.' olan STREET_ADDRESS, City, State ve Zip gibi 3 alt parçalara bölünebilir. Bölünebilir olmayan niteliklere basit veya atomic nitelik de denir.Birleşik nitelikler bir hiyerarşi oluşturabilirler; örneğin STREET_ADDRESS 3 basit bileşen niteliğine daha bölünebilirler; Number, Street, and Apartment_number. Şekil 7.4 da gösterilmiştir. Birleşik niteliğin değeri basit niteliklerin değerlerinin bileşimidir.

Single-Valued versus Multivalued Attributes (Çok Değerliğe Karşı Tek Değerli Nitelik); Çoğu nitelikler belirli bir varlık için tek bir değere sahip olur ki buna single-valued (tek değerli) denir. Örneğin yaş her personel için tekil değerli bir niteliktir.Bazı durumlarda nitelik değerleri birden fazla olabilir.Örneğin bir kişinin birden fazla üniversite derecesi olabilir. Bunlara multivalued (çok değerli) denir. Stored versus Derived Attributes (Türetilmişe Karşılık Sabitlenmiş Nitelik); Bazı durumlarda, 2 veya daha fazla değer ilişkili olabilir. Örneğin, kişinin niteliklerinden yaş ve doğum tarihi. Yaş değeri bugünün ve doğum tarihinin değerinden hesaplanır. Burada yaş derived (Türetilmiş) bir değerdir. Fakat doğum tarihi stored (sabitlenmiş) bir değerdir. Null Values; Bazı durumlarda, belirli bir varlık için bir nitelik uygulanabilir bir değere sahip olmayabilir. Örneğin müstakil bir ev için daire numarası, üniversite mezunu olmayan biri için lisans derecesi null değerini alır. Burada unutmamak gerekir ki; 0 (o da bir değerdir) veya boş bırakmak veritabanı mantığına uygun değildir. Complex Attribute (Karmaşık Nitelik); Genelde birleşik ve çok değerli nitelikler içi içe olabilir. Parantez arasında birleşik niteliğin bileşenleri gurplanmış şekilde yer alabilir ve birbirinden virgül ile ayrılabilir veya { } içinde gösterilebilir. Şekil 7.5. de gösterildiği gibi, örneğin, bir kişi birden fazla konuta sahipse ve eğer her ikamet tek bir adres ve birden fazla telefon bulundurursa, bir kişi için bir Address_phone niteliği belirtilebilir.

3.3.2. Varlık Çeşitleri, Varlık Kümeleri, Anahtarlar ve Değer Kümeleri (Entity Types, Entity Sets, Keys, and Value Sets) Entity Types and Entity Sets (Varlık Çeşitleri, Varlık Kümeleri); Bir veritabanı, genellikle benzer varlıkların gruplarını içerir. Örneğin yüzlerce çalışanı istihdam eden şirket her çalışanla ilgili benzer bilgileri saklamak ister. Bu çalışanların varlıkları aynı nitelikleri paylaşır fakat her varlık her nitelik için kendi değerini taşır. Şekil 7.6 da 2 varlık çeşidi gösterilir; EMPLOYEE and COMPANY ve her biri için niteliklerinin bazılarının listesi. Herhangi bir zamanda veritabanındaki belirli bir varlık çeşideki tüm varlıkların koleksiyonuna entity set (varlık kümesi) denir ; varlık kümesi genellikle varlık türü ismi ile de anılabilir. Örneğin; EMPLOYEE hem varlık türü hem de tüm mevcut çalışanların kümesidir. Şekil 7.2den hatırlanacağı gibi ER diyagramlarında varlık çeşitleri, varlık türünün ismini çevreleyen dikdörtgen kutu ile temsil edilir. Nitelikler ise oval daire içine alınır ve varlığa düz bir çizgi ile bağlanır. Birleşik nitelikler bileşenleri ile düz çizgi ile bağlanır. Çok değerli nitelikler çift oval ile gösterilir.

Şekil 7.7 (a) bir ARABA varlık türünü gösterir. Key Attributes of an Entity Type (Varlık Türünün Anahtar Niteliği); varlık üzerinde önemli kısıtlar nitelikler üzerindeki anahtar yada benzersizlik (key or uniqueness) kısıtlarıdır. Varlık türü genellikle, varlık setindeki her bir varlık için farklı değerler alan bir veya daha fazla niteliğe sahiptir. Anahtar nitelik olarak adlandırılan nitelik ve onun değeri niteliği benzersizce tanımlar, ona kimlik sağlar.Şekil 7.6 da isim niteliği COMPANYnin anahtarıdır. Çünkü aynı isimli 2 şirket olamaz yani isim uniquedir (benzersizdir). PERSON varlık çeşidi için anahtar nitelik SSNdir. (Social Security Number) (Sosyal Güvenlik Numarası) Bazen birkaç nitelik bir anahtar oluşturur. Tabi burada nitelik değerlerinin birleşimi her bir varlık için farklı olmalıdır.Yani her bir bileşen unique özelliğini korumalıdır. Lüzumsuz nitelikler bu anahtara dahil edilmemelidir. Şekil 7.7(a)da gösterildiği gibi her bir anahtar oval içindedir ve altı çizilidir. Value Sets (Domains) of Attributes(Niteliğin Değer Seti): Her basit nitelik değer kümesi veya değer domaini (alanı) ile ilişkilidir.Şekil 7.6 da, izin verilmiş yaş aralığı 16-70 ise EMPLOYEE varlığının yaş niteliğinin değer seti 16-70 integerdır.Benzer şekilde İsim niteliğinin değer kümesi boşluk karakteri ile ayrılmış alfabe karakterleridir.

Değer setleri ER diyagramları görüntülenmez ve genellikle bir çok programlama dilinde integer, string,float gibi basit veri çeşitleri kullanılarak belirtilir. Matematiksel olarak, değer kümesi V olan ve varlık seti E olan A niteliği E den power set P(V)ye giden bir fonksiyon olarak tanımlanır. A: E P(V) Varlık e için nitelik Anın değeri A(e) şeklinde belirtilir. Bir önceki tanım hem tek değerli ve çok değerli nitelikleri hatta null değerini de kapsar. Bir NULL değeri boş küme ile temsil edilir. Tek değerli nitelikler için ve E'deki her varlık e için A(e) singleton set (Tek elemanlı küme) olmak zorundadır.Oysa birden çok değerli niteliklerde sınırlama/zorunluluk yoktur. Birleşik nitelik A için, değer seti V P( ),P( ),…, P( ) dan oluşan kartezyen çarpımın power setidir. Burada , ,…. , basit bileşen niteliklerinin değer setidir.

3.3.3. Şirket Database’in İlk Kavramsal Tasarımı (Initial Conceptual Design of the COMPANY Database) Şimdi Bölüm 7.2 açıklanan gereksinimlerine göre, COMPANY veritabanı için varlık türlerini tanımlayabiliriz. Burada birkaç varlık türleri ve bunların özelliklerini tanımladıktan ve ilişki kavramını tanıttıktan sonra bölüm 7.4teki tasarımı geliştireceğiz. Bölüm 7.2'de sıralanan gereksinimlere göre, dört varlık türü tanımlayabiliriz. İsim, Numara, Konum, Yönetici, Yönetici_başlama_zamanı nitelikleri ile birlikte DEPARTMENT varlığı. Sadece Konum niteliği çok değerliklidir. Unique olduklarından İsim ve Numara niteliğini ayrı ayrı anahtar nitelik olarak seçebiliriz, fakat Numarayı seçmek beklenendir. İsim, Numara, Konum ve Kontrol eden_departman nitelikleri ile birlikte PROJECT varlığı. İsim ve Numara anahtar olabilirler. İsim, Ssn, Cinsiyet; Adres, Maaş, Doğum_tarihi, Departman ve Yöneticisi gibi niteliklerle beraber EMPLOYEE varlığı. İsim ve Adres birleşik nitelik olabilir. Çalışan, Departman_adı, cinsiyet, Doğum_tarihi ve İlişki gibi niteliklerle birlikte DEPENDENT varlığı. Şimdiye kadar, ne çalışanın birçok proje üzerinde çalışabileceğini ne de her bir projede haftalık ne kada çalıştığını betimlememiştik. Bu özellik, Bölüm 7.2 üçüncü gereksinimin bir parçası olarak listelenmişti ve bu EMPLOYEE'nin basit bileşenli (Proje,Saat) Works_on denilen birçok değerli bileşik niteliği ile temsil edilebilir. Alternatif olarak, PROJECT 'nin basit bileşenli (Çalışan,Saat) Workers denilen birçok değerli bileşik niteliği ile temsil edilebilir. (Basit bileşen/ bileşik nitelik ?????) Genellikle Şekil 7.8 deki ilk alternatif seçilir. EMPLOYEE'nin isim niteliği muhtemelen kullanıcıları ile görüşmeden sonra birleşik nitelik olarak gösterilir.

3.4. İlişki Çeşitleri, İlişki Kümeleri, Rolleri ve Yapısal Kısıtlar (Relationship Types, Relationship Sets, Roles, and Structural Constraints) Şekil 7.8 de çeşitli varlık türleri arasında çok sayıda kesin ilişkiler vardır. Aslında, bir varlık çeşidinin niteliği başka bir varlık çeşidini refere ettiğinde bazı ilişkiler doğar. Örneğin DEPARTMENT'ın yönetici niteliği EMPLOYEE varlığında deparmanı yöneten bir çalışana işaret eder. PROJECT varlığının Kontrol Departmanı niteliği bir departmanı işaret eder. EMPLOYEE varlığının departman niteliği DEPARTMENT varlığı ile ilişkilidir.ER Modelinde bu referanslar birer nitelik gibi düşünülmemelidir, bunlar birer ilişkidir. Bu ayrımın detaylarını ilerleyen bölümlerde vereceğiz. 3.4.1. İlişki Türleri, Kümeleri ve Örnekleri (Relationship Types, Sets, and Instances) n tane varlık çeşidi ile R ilişki çeşidi arasında ortaklık/ilişki kümesi tanımlar. Varlık türleri ve varlık kümeleri bahsedildiğinde, ilişki türü ve onların ilişki kümeleri aynı ismi alır: R. Matematiksel olarak, olmak üzere ; ilişki seti R, relationship instance (ilişki durumu/örneği) lerin bir kümesidir. Burada her n tane bireysel varlığı birleştirir/ ortaklık kurar ve deki her varlık varlık seti nin bir üyesidir. Çünkü ilişki seti, arasında matematiksel bir ilişkidir. Alternatif olarak; varlık seti nin kartezyen çarpımının alt kümesi olarak da tanımlanabilir. Her bir varlık çeşidi ilişki çeşidi R içinde ortak olur; benzer olarak her bir bireysel varlıklar ilişki örneği içinde ortak olur. R’deki her bir ilişki durumu varlıkların bir ortaklığıdır. Buradaki ortaklık her bir varlık çeşidinden bir adet içerir. Her bir ilişki örneği , deki varlık ortaklığının mini world'deki durumu ile ilişkili olduğunu gösterir. Örneğin EMPLOYEE ve DEPARTMENT varlıkları arasındaki WORKS_FOR ilişki çeşidini düşünebiliriz. Bu ilişki her çalışan ile departmanı ilişkilendirir. WORKS_FOR ilişki kümesindeki her ilişki örneği, bir EMPLOYEE varlığı ve bir DEPARTMENT varlığını ilişkilendirir.

Şekil 7. 9 bunu örneklendirir Şekil 7.9 bunu örneklendirir. Mini worlde uygun olarak, çalışanları departmanı için, çalışanları departmanı için, çalışanları için çalışır. ER diyagramında, ilişki çeşitleri baklava biçimindeki kutular ile gösterirlir. Bunlar düz çizgilerle varlık çeşidini gösteren dikdörtgen kutulara bağlanır. İlişki ismi baklava kutusunun içinde belirtilir. Şekil 7.2’de de görülebilir. 3.4.2. İlişki Dereceleri, Rol İsimleri ve Kendine Dönen İlişki (Relationship Degree, Role Names, and Recursive Relationships) Degree of a Relationship Type (İlişki Tipinin Derecesi) ; İlişki tipinin derecesi ortaklık kuran varlık tiplerinin sayısıdır. Bu nedenle WORKS_FOR ilişkisi 2. decedendir. 2 dereceli ilişki tipine binary (ikili), 3 dereceli ilişki tipine ternary (üçlü) denir. Şekil 7.10 da gösterilen ve ternary ilişkiye örnek SUPPLY ilişkisidir. Burada her bir ilişki örneği 3 varlık ile ilişkildir- supplier s (tedarikçi), part p (parça), project j-s tedarikçisi p parçasını j projesine tedarik eder.

Relationships as Attributes (Nitelik olarak İlişki); 3. 3 Relationships as Attributes (Nitelik olarak İlişki); 3.3.3 bölümünde anlatıldığı gibi, bazen nitelikler bakımından binary ilişki düşünmek uygun olabilir. Şekil 7.9 daki WORKS_FOR ilişkisi ve EMPLOYEE varlığının Departman niteliği düşünebilir. Burada her EMPLOYEE varlığı için departmanın değeri, DEPARTMENT varlığını refere eder. Bu nedenle, departman niteliği için değer seti DEPARTMENT varlık setini oluşturur. Aslında bu şekil 7.8 de EMPLOYEE varlık çeşidinin initial tasarımını belirlediğimizde yaptığımızdır. Ancak nitelik olarak binary ilişkiyi düşündüğümüz zaman iki opsiyona sahibiz; bu örnekte alternatif, DEPARTMENT varlık çeşidinin çok değerli çalışan niteliğinin düşünülmesidir. Bu çalışan niteliğinin değer kümesi, EMPLOYEE varlık setinin power setidir. EMPLOYEE nin departman veya DEPARTMENTin çalışan niteliklerinin her biri WORKS_FOR ilişki çeşidini temsil edebilir. Eğer her ikisi de temsil ediyorsa, her biri bir diğerinin tersi olarak kısıt alır. Role Names and Recursive Relationships (Rol isimleri ve Yinelemeli İlişkiler); Bir ilişki türüne katılan her varlık türü ilişkisinde belli bir rol oynar. Rol isimleri bu rolü tanımlamaya ve ilişkiyi açıklamaya yardımcı olur. Tüm katılımcı varlık türlerinin farklı olduğu ilişki türlerinde, rol isimleri teknik olarak gerekli değildir.Çünkü her bir katılımcı varlık çeşidi ismi, rol ismi olarak kullanılabilir. Ancak bazı durumlarda aynı varlık türü bir ilişki türünde farklı rollerde birden çok kez katılır. Bu gibi durumlarda rol ismi, her katılımcı varlığın oynadığı rolün anlamınının ayırt edilmesinde önemli hale gelir. Böyle ilişki türlerine özyinelemeli ilişki denir. SUPERVISION ilişki çeşidinde çalışan ve supervisor ilişkilendirilir. Buradaki çalışan ve supervisor varlıkları, EMPLOYEE varlık setinin bir üyesidir. Bu nedenle, EMPLOYEE varlık çeşidi SUPERVISION'a 2 kez katılmış olur: bir kez supervisor rolünde (yönetici), bir kez de supervisee (alt çalışan). SUPERVISIONdaki her bir ilişki örneği , supervisor ve supervisee olarak rol alan 2 çalışan varlığına ve 'ya katılır.

Şekil 7.11 de, 1 bağlantı çizgisinde supervisor rolü, 2 bağlantı çizgisinde supervisee rolü belirtilir. Çünkü , ve ‘ü supervize eder (yönetir/yönlendirir), , ve ‘yi, , ve ü yönlendirir. Bu örnekte, her bir ilişki örneği 1 veya 2 bağlantı çizgisinden biriyle bağlanmak zorundadır. 3.4.3. Binary İlişki Çeşitleri üzerindeki Kısıtlar (Constraints on Binary Relationship Types) İlişki çeşitleri genellikle ilişki setine katılacak varlıkların olası kombinasyonlarını sınırlayan bazı kısıtlamalara sahiptir. Şekil 7.9 da, eğer şirket bazı kurallara sahipse örneğin her bir çalışan bir departmana bağlı olmak zorunda gibi, biz bu kısıtları şemada belirtmeyi tercih ediyoruz. Binary ilişki kısıtlarını iki ana başlıkta inceleyeceğiz. Cardinality Ratios for Binary Relationships (Binary ilişki için Önem Oranları ); Binary ilişki için önem oranı, ilişki örneğine katılan varlıkların maksimum sayısını gösterir. Örneğin, WORKS_FOR binary ilişki çeşidinde DEPARTMENT:EMPLOYEE 'un önem oranı 1:N'dir. Bunun anlamı; her bir departman N sayıda çalışana sahip olabilirken, her bir çalışan yalnızca bir departmana bağlı olabilir. Mümkün olan önem oranları 1:1, 1:N, N:1 ve M:N dir. Şekil 7.12 de, 1:1 ilişki örneği, departman varlığı ile yönetici olarak çalışanları bağlayan MANAGES ilişkisidir.

Bu, bir çalışanın yalnızca bir bölümü yönetebileceği ve bir bölümün ancak bir yöneticisi olabileceği miniworld kısıtını temsil eder. Şekil 7.13 deki, WORKS_ON ilişki çeşidinde oran M:N'dir. Çünkü miniworld kuralı gereği bir çalışan birden fazla projede çalışabilir ve bir proje birden fazla çalışana sahip olabilir. Participation Constraints and Existence Dependencies (Katılım Kısıtları ve Varoluş Bağımlılığı); Katılım kısıtı ilişki örneğine katılan varlıkların minimum sayısıdır. Minimum önem kısıtı denir. İki katılım kısıtı çeşidi; total ve partial (toplam ve kısmi) kısıtlar örneklendirilmiştir. Eğer şirket politikası gereği her çalışan bir departmana bağlı olmalı kuralı varsa, çalışan varlığı en az bir WORKS_FOR ilişki örneğinde yer alır.(Şekil 7.9) WORKS_FOR da EMPLOYEE katılımı total katılım/ ortaklık olarak adlandırılır. Bunun anlamı, çalışan varlıklarının total kümesindeki her varlık WORKS_FOR ile departman varlığına bağlantı yapmak zorundadır. Total katılım varlığın bağımlılığı olarak da adlandırılır. Şekil 7.12 de, her bir çalışanın bir departmanı yöneteceğini çıkaramayız. MANAGES ilişki çeşidindeki EMPLOYEEnin katılımı kısmidir.Bunun anlamı çalışan varlık kümesinin bir kısmı MANAGES ile departman varlığının bir kısmı ile ilişkilidir, fakat tamamı ile değil. ER diyagramlarında total katılım, ilişkiye katılan varlıkların bağladığı çift çizgi ile gösterilir. Kısmi katılım ise tek çizgi ile gösterilir. (Şekil 7.2)

3.5. Zayıf Varlık Çeşitleri (Weak Entity Types) 3.4.4. İlişki Çeşitlerinin Nitelikleri (Attributes of Relationship Types) İlişki türleri de varlık türleri gibi benzer nitelikleri sahip olabilir. Örneğin çalışanın bir proje üzerinde haftada kaç saat çalıştığının kaydı için WORKS_ON ilişkisi saat niteliğini içerir. (Şekil 7.13) Başka bir örnek ise yöneticinin hangi tarihte departmanı yönetmeye başladığının belirtilmesi için Start_date niteliğinin MANAGES ilişkisinde bulunmasıdır. (Şekil 7.12) 1:1 veya 1:N lik ilişki çeşidinin niteliği, ilişkiye katılan varlık çeşidinden birine geçebilir. Örneğin, MANAGES ilişkisi için Start_date niteliği EMPLOYEE veya DEPARTMENT dan birine ait olabilir. Fakat kavramsal olarak MANAGES'a aittir. Bunun nedeni MANAGES 1:1lik ilişki olmasıdır.Böylece her departman ve çalışan en fazla bir ilişki örneğine katılır. Böylece Start_date niteliğinin değeri ya katılan departman varlığı tarafından ya da katılan çalışan varlığı tarafından ayrı ayrı belirtilir. 1:N lik ilişki çeşidi için, ilişki niteliği sadece ilişkinin N'lik tarafındaki varlığa geçebilir. Örneğin şekil 7.9 da, WORKS_FOR ilişkisi Start_date niteliğine sahipse, bu nitelik EMPLOYEE varlığının bir niteliği olabilir. Çünkü burada her bir çalışan bir departmanda çalışabilir.WORKS_FOR içinde en fazla bir ilişki örneği bulunabilir. 1:1 lik ve 1:N lik ilişkide, ilişki niteliğinin nerede olacağı kararı şema tasarımcısı tarafından belirlenir. M:N lik ilişki için, bazı nitelikler tekil varlıklar yerine ilişki örneğine katılan varlıkların kombinasyonu tarafından belirlenir. Bazı nitelikler ilişki nitelikleri gibi belirlenmelidir. Örnek olarak M:N lik WORKS_ON ilişkisinin saat niteliği verilebilir.(Şekil 7.13) 3.5. Zayıf Varlık Çeşitleri (Weak Entity Types) Kendi anahtar niteliğe sahip olmayan varlık çeşidi zayıf varlık olarak adlandırılır. Buna karşılık anahtar niteliğe sahip olan varlık türü güçlü varlık olarak adlanır. Zayıf varlıklar diğer varlık çeşitlerinden belirli varlıklarla ilişkilendirerek tanımlanır. Bu zayıf varlıkların ilişkilerine de zayıf ilişkiler denir. Bu ilişkideki baskın tarafa parent (ebeveyn) varlık denirken, sonradan tanımlanmış varlığa child (çocuk) varlık denir. Şekil 7.2 de Dependent varlığı EMPLOYEE den üretilmiş bir zayıf (çocuk) varlıktır. Her bir çalışana bağlı sigortalanacak aile üyelerini (dependentlerini) gösterir.

Zayıf varlık çeşidi her zaman total katılım kısıtıdır Zayıf varlık çeşidi her zaman total katılım kısıtıdır. Ancak tersi her zaman doğru değildir. Total katılım kısıtı zayıf varlık sonucunu vermez. Örneğin, DRIVER_LICENSE varlığı PERSON varlığı ile ilişkilendirilmeden var olamaz. Buna rağmen kendi anahtarına sahiptir (Lİcense_number) bu nedenle zayıf varlık değildir. EMPLOYEE ile 1:N ilişkili DEPENDENT varlığı düşünülsün.(Şekil 7.2) Bizim örneğimizde, DEPENDENT varlığının isim niteliği (dependentin ilk ismi), doğum tarihi, cinsiyet ve ilişki (çalışan ile olan).İki farklı çalışanın iki dependenti isim, doğum tarihi, cinsiyet ve ilişki gibi niteliklerde aynı değerlere sahip olabilir, fakat onlar hala ayrı varlıklardır. Zayıf varlık tipi normalde zayıf varlığı benzersiz şekilde tanımlayan kısmi anahtara sahiptir. Bizim örneğimizde, aynı çalışanın iki dependentinin aynı ismi olmadığını varsayarsak, DEPENDENT varlığının isim niteliği kısmi anahtardır. ER diyagramlarında, zayıf varlık çeşidi ve onun tanımlayıcı ilişkisi çift çizgi ile belirtilir.(Şekil 7.2) Kısmi anahtar kesik yada noktalı çizgi çekilerek belirtilir. Zayıf varlık çeşidi bazen kompleks (bileşik, çoklu değer) nitelik olarak temsil edilebilir. Yukarıdaki örnekte, EMPLOYEE için isim,doğum tarihi, cinsiyet ve ilişki niteliklerine sahip çok değerli Dependent niteliğini belirtebilirdik.Yani ayrı varlık olarak değil de EMPLOYEE varlığına bağlı bir çok değerli nitelik olarak belirtebilirdik. Bu temsil seçimi database tasarımcısı tarafından yapılır. 3.6. Şirket Database’i için ER Tasarımının İrdelenmesi (Refining the ER Design for the COMPANY Database) Şekil 7.8 deki database tasarımını daha iyi irdelemeye çalışacağız. Her ilişki çeşidinin önem oranı ve katılım kısıtı 7.2 bölümündeki gereksinim listesine göre belirlenmiştir. Örneğimizde aşağıdaki ilişki çeşitleri belirlenmiştir;

MANAGES, EMPLOYEE ve DEPARTMENT arasında 1:1 lik bir ilişkidir MANAGES, EMPLOYEE ve DEPARTMENT arasında 1:1 lik bir ilişkidir. EMPLOYEE kısmi bir katılımcıdır. DEPARTMENT katılımcısının ne olduğu gereksinimlerden pek anlaşılmaz. Bu yüzden userlara soru sorulup bu konuda bir iş kuralı olup olmadığı öğrenilmelidir.(Her departmanın bir yöneticisi olmak zorunda mıdır?) Start_date niteliği bu ilişki çeşidine bağlanabilir. WORKS_FOR, EMPLOYEE ve DEPARTMENT arasında 1:N lik bir ilişkidir. İkisi de total katılımlıdır. CONTROL , DEPARTMENT ve PROJECT arasında 1:N lik bir ilişkidir. PROJECT total katılımlı fakat DEPARTMENT kısmi katılımlıdır. Çünkü bazı departmanlar proje yürütmezler. SUPERVISION, EMPLOYEE ve EMPLOYEE arasında 1:N lik bir ilişkidir. Burada biri supervisee, biri supervisor rolündedir. İkisi de kısmi katılımlıdır, çünkü her çalışan supervisore sahip olmayacağı gibi her çalışan da supervisor olmayabilir. WORKS_ON, EMPLOYEE ve PROJECT M:N lik bir ilişkidir. Hours niteliğine sahiptir. İkisi de total katılımlıdır. DEPENDENTS_OF, EMPLOYEE ve DEPARTMENT 1:N lik bir ilişkidir. EMPLOYEE kısmi, DEPARTMENT total katılımlıdır. Bu altı tanımı yaptıktan sonra Şekil 7.8 deki şekilde varlıklara tanımlanmış olan nitelikleri ilişkiler bazında irdeleyeceğiz. DEPARTMENT dan Manager ve Manager_start_date; PROJECT ten Controlling_department; EMPLOYEE den Department, Works_on, Supervisor; DEPENDENT den Employee.