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.

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) 7.9 dan 7.13 e kadar olan şekiller, varlık takımlarını veya uzantıları göstererek ilişki türlerinde varlık türlerinin katılım örneklerini göstermektedir.(varlık kümesinde bireysel varlık örneklerini ve ilişki kümelerinde bireysel ilişki örneklerini.) ER diyagramları örnekler yerine temsil şemaları üzerine yoğunlaşır. Bu veritabanı tasarımı daha kullanışlıdır çünkü varlık kümelerinin içeriği ise sık sık değişirken veritabanı şeması nadiren değişir. Ek olarak, çok daha küçük olduğundan şema görüntülemek için daha kolaydır. Şekil 7.2 ER diyagramı olarak COMPANY ER database şemasını gösterir. Bundan sonra tam olarak ER diyagramı gösterimini inceleyeceğiz. EMPLOYEE, DEPARTMENT and PROJECT gibi varlık türleri dikdörtgen kutular içinde gösterilir. WORKS_FOR, MANAGES, CONTROLS, ve WORKS_ON gibi ilişki türleri, düz çizgi ile belirtilmiş katılımcı varlık türleri ile bağlantılanmış elmas şeklindeki kutularda gösterilir. Nitelikler oval gösterilmiştir ve her nitelik kendi varlık türü veya ilişki türüne düz bir çizgi ile bağlanır. Birleşik niteliğin bileşen nitelikleri oval olarak gösterilen birleşik niteliğe bağlanır. Örneğin EMPLOYEE in Name niteliği gibi. DEPARTMENT in Location niteliği gibi çok değerli nitelikler çift oval içinde gösterilir. Anahtar niteliklerin altı çizilidir. Türetilmiş (Derived) nitelikler noktalı oval içinde gösterilmiştir. DEPARTMENT ın Number_of_employees niteliği gibi. Zayıf varlık türleri çift dikdörtgen ve bunların ilişkileri de çift elmas ile ayrıt edilir. Örnek olarak; DEPENDENT varlığı ve DEPENDENTS_OF ilişkisi. Zayıf varlığın kısmi anahtarı kesik çizgi ile belirtilir. Katılım kısıtı içinse kısmi katılım tek çizgi ile total katılım çift çizgi ile belirtilir.Şekil 7.2 de, SUPERVISION ilişkisi için rol adı gösterilir. Çünkü aynı EMPLOYEE varlığı ilişkide 2 farklı rol oynar. Supervisor de supervisee de EMPLOYEE varlığından gelir. 1:N lik ilişkiye sahiptir, supervisee rolündeki her çalışan bir supervisore sahipken supervisor rolündeki her bir çalışan birden fazla çalışanı yönetir.

Şekil 7.14 ER diyagramları için kuralları ve şekilleri özetlemektedir. 3.7.2. Şema Yapılarının Doğru İsimlendirilmesi (Proper Naming of Schema Constructs) Bir veritabanı şemasını tasarlarken, varlık türleri, nitelikleri, ilişki türleri ve özellikle rolleri için isim seçimi her zaman kolay değildir. Varlık türleri için çoğul olanlardan çok tekil isimler seçilmelidir. Çünkü varlık türü adı o varlık tipine ait her bir varlık için de geçerlidir. ER diyagramlarında, ilişki ve varlık türlerinin adları hepsi büyük harfle, nitelik isimleri ilk harf büyük harfle ve rol isimleri küçük harfle yazıldı. 3.7.3. ER Kavramsal Tasarımı için Tasarım Seçenekleri (Design Choices for ER Conceptual Design) Miniworldde varlık, nitelik ve ilişki çeşidinin modellenmesine karar verilmesi bazen zordur. Bu bölümde, yapının seçilebilmesi için bazı kısa yönergeler verilmiştir. Genel olarak, şema tasarım sürecini, ilk tasarım oluşturulduktan sonra en uyguna ulaşana kadar tekrarlanan iteratif geliştirme süreci olarak düşünmek gerekir. Sık kullanılan iteratif geliştirme teknikleri şöyledir;

Bir konsept ilk olarak bir nitelik olarak modellenebilir ve sonra ilişki içine dahil edilebilir.Çünkü niteliğin başka bir varlığı referans ettiği belirlenmiştir. Bu nitelik fazlalığı ve tekrarı önlemek için varlık türünden çıkarılmalıdır. Benzer şekilde, çeşitli varlık türlerinde olan bir nitelik bağımsız varlık türüne terfi ettirilebilir. Örneğin, varsayalım ki bir UNIVERSITY databaseinde STUDENT, INSTRUCTOR, ve COURSE gibi çeşitli varlık türlerinin her biri initial tasarımda Department niteliğine sahiptir. Tasarımcı, Dept_name niteliğine sahip ve 3 varlıkla (STUDENT, INSTRUCTOR, and COURSE) ilişkili DEPARTMENT varlığını oluşturmayı tercih edecektir.Diğer DEPARTMENT'in nitelik/ilişkileri daha sonra keşfedilebilir. Dept_name niteliği olan DEPARTMENT varlığı initial design de varsa ve sadece STUDENT varlığı ile bağlantılıysa önceki case'e göre ters bir geliştirme uygulanabilir. 3.7.4. ER Diyagramları için Alternatif Notlar (Alternative Notations for ER Diagrams) ER diyagramlarını göstermek için birçok alternatif şematik gösterimler vardır. Bölüm 7.8, biz sınıf diyagramları için kavramsal nesne modelleme için bir standart olarak ileri sürülmüş Unified Modeling Language (Birleştirilmiş Modelleme Dili)(UML) notasyonu tanıtacağız. Bu bölümde, ilişkilerde önem oranının (1:1, 1:N, M:N) ve tek çift çizgi gösteriminin yerine kullanılacak yapısal kısıtlamalar belirtmek için alternatif bir ER notasyonu tarif edeceğiz. Bu gösterim, bir ilişki türü R içinde bir varlık türü E'nin her katılımcısıyla 0 ≤ min ≤ max ve max ≥ 1 şartını sağlayan bir çift tamsayı (min, max) ile ilişkilendirilmesini içerir. Buradaki bu sayılar çifti Edeki her varlık e için olduğu anlamına gelir. e zaman içindeki herhangi bir noktada R de en az min en çok max ilişki örneğine katımak zorundadır. Bu methodda min=0 kısmi katılımı, min>0 total katılımı ifade eder.

Şekil 7.15 de COMPANY database şeması (min, max) notasyonu kullanılarak gösterilmiştir. Genellikle ya önem oranı/tek-çift çizgi notasyonu veya (min, max) notasyonu kullanılır. (Min, max) notasyonu daha hassas olduğundan yüksek derecede ilişkisi türleri için bazı yapısal kısıtlamalar belirtmek için kullanabiliriz. Ancak, Bölüm 7.9 ele alındığı gibi, daha yüksek derece ilişkileri için bazı temel kısıtlar belirtmek için yeterli değildir. Şekil 7.15 COMPANY database scheması için tüm rol isimlerini gösterir. 3.8. Diğer Notların Örnekleri; UML Class Diyagramları (Example of Other Notation:UML Class Diagrams) UML metodolojisi yazılım tasarımında yaygın olarak kullanılır ve bu amaç için birçok çeşit diyagram barındırır. Burada kısaca UML sınıf diyagramları temellerini sunup ER diyagramları ile karşılaştırmasını yapacağız. Bazı açılardan, sınıf diyagramları ER diyagramlarının alternatif bir gösterimi olarak kabul edilebilir.

Şekil 7.16da COMPANY ER şemasının UML sınıf diyagramları ile nasıl gösterilebileceğini göstereceğiz. ER modelindeki varlık çeşitleri şekil 7.16da sınıf olarak modellenmiştir. UML sınıf diyagramları, (ER varlık türüne benzer) üç bölüm içeren bir kutu şeklinde gösterilir: üst kısım (varlık türü adına benzer) sınıf adını verir; orta bölüm niteliklerini içermektedir; ve son bölümde sınıfının (bir varlık kümesinde özgün varlıklara benzer) özgün nesnelere uygulanabilir operationlarını içerir. Bu operationlar ER diyagramlarında belirtilmemiştir. Şekil 7.16daki EMPLOYEE sınıfını düşündüğümüzde, nitelikleri Name,Ssn, Bdate, Sex, Address, and Salary'dir. Tasarımcı isteğe bağlı olarak bir niteliğin domainini belirtebilir, İsim:Açıklama şeklinde. Şekil 7.16da EMPLOYEE'nin Name, Sex ve Bdate nitelikleri bunun için örneklendirilebilir. Bileşik nitelik yapılandırılmış bir domain olarak modellenmiştir. Örnek olarak EMPLOYEEnin name niteliği. Çok değerli nitelik ayrı bir sınıf olarak modellenmiştir. Örnek olarak LOCATION sınıfı. İlişki türlerine UML terminolojisinde ortaklık ilişki örneğine link (bağlantı) denir. Bir ikili ortaklık katılımcı sınıflarla (varlık tipleri) bir çizgi ile bağlanır ve isteğe bağlı olarak bir isim alabilir. Link niteliği kesik bir çizgi ile ortaklık hattına bağlı bir kutu içine yerleştirilir.

Bölüm 7.7.4 açıklanan (min, max) notasyonu UML terminolojisinde multiplicities (çeşitlilik) olarak isimlendirilirken ilişki kısıtlamaları belirtmek için kullanılır. Multiplicities (min, max) notasyonunda belirtilir ve yıldız (*) katılımda maksimum limitinin olmadığını gösterir. Ancak, Bölüm 7.7.4 açıklanan notasyonu ile karşılaştırıldığında, multiplicities ilişkinin karşılıklı iki ucuna yerleştirilir. UML'de tek yildiz 0...* 'ın multiplicity'sini gösterirken, tek 1 1.....1 'ın multiplicity'sini gösterir. UML'de özyenilemeli (recursive) ilişkiye reflexive ortaklık denir ve Şekil 7.15 rol adları yerleştirilmesi ile karşılaştırıldığında, multiplicity gibi rol isimleri ortaklıkların karşılıklı uçlarında yer alır. UML'de, ilişkilerin iki türü vardır: ortaklık ve yığın. (association and aggregation) Yığın bütün nesneler ve bileşen parçaları arasındaki ilişkiyi temsil ediyor ve ayrı bir şematik gösterimi vardır. Şekil 7.16da, departmanın konumu ve projenin tekil konumu bir yığın olarak modellenmiştir. Ortaklık ve yığın farklı özelliklere sahip değildir ancak kullanmak için hangi ilişki çeşidinin seçileceği öznel bir konudur. UML de tek yönlü ve çift yönlü ortaklıklar (ya da yığınlar) birbirinden ayırt edilir. Tek yönlü durumda, sınıfları birleştiren hat, ilgili nesnelere erişmek konusunda tek yön gerektiğini belirtmek için ok ile gösterilir. Hiçbir ok gösterilmezse, çift yönlü durum olduğu varsayılır.Örneğin, her zaman DEPARTMENT nesnesinden başlayarak bir departmanın yöneticisine ulaşmayı bekler, MANAGES ortaklığını temsil eden EMPLOYEE'den DEPARTMENT'a doğru bir okla ortaklık hattı çizeriz. Buna ek olarak, düzenli hale gelmesi için ilişki örnekleri belirtilebilir. Örneğin, WORKS_FOR ortaklığı (ilişkisi) aracılığıyla her departmana bağlı çalışan objeleri kendi maaş niteliği değerine göre düzenlenmesi gerektiğini belirtebiliriz. Ortaklık (ilişki) isimleri UML'de isteğe bağlıdır ve ilişki nitelikleri ortaklık /yığın temsil eden bir kesikli çizgi ile bağlanan bir kutu içinde gösterilir. (Şekil 7.16da Start_date ve Hours )

Bölüm 7.1 de anlatıldığı gibi her sınıfta verilen operationlar uygulamanın işlevsel gerekliliklerinden türetilmiştir. Şekil 7.16 'de gösterildiği gibi, bir sınıfın özgün objelere uygulanması beklenen mantıksal operationlar için başlangıçta operation isimlerini belirtmek genellikle yeterlidir. Tasarımın tanımlandığı zamanki gibi, her operation için değişken türleri veya fonksiyonel açıklamalar gibi daha fazla ayrıntı eklenebilir. UML de zayıf varlıklar, nitelikli ortaklık olarak adlandırılan yapılar kullanılarak modellenir; bu tanımlanan ilişkiyi ve kısmi anahtarı temsil edebilir. Bu şekil 7.16 da DEPENDENT sınıfı ve nitelikli EMPLOYEE ortaklığı ile örneklendirilmiştir. UML terminolojisinde kısmi anahtar Dependent_name discriminatorin (ayırt edici) olarak adlandırılır. Çünkü değeri aynı EMPLOYEEye bağlı obje ortaklığını ayırt etmesini sağlar. Nitelikli ortaklıklar zayıf varlıkların modellenmesi ile sınırlı değildir, bunlar UMLdeki diğer durumları modellemek için de kullanılabilir. 3.9. İkiden Yüksek Dereceli İlişki Çeşitleri (Relationship Types of Degree Higher than Two) Bölüm 7.4.2'de katılımcı varlık türlerinin sayısı gibi bir ilişki türü derecesini tanımlamış ve derecesi binary ve three ternary (üçlü) ilişki türü olarak adlandırmıştık. Bu bölümde binary ilişki türüne karşı yüksek derece ilişki türü seçmemiz gerektiği zamanlar olduğundan binary ve yüksek dereceden ilişkilerin farklarını ve yüksek dereceli ilişkilerin kısıtlarının nasıl belirleneceğini inceleyeceğiz.

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) Ternary (üçlü) ilişki türü için ER diyagramı gösterimi şekil 7.17(a)da gösterilmiştir. Şekil 7.10 varlık seti / ilişki seti veya örnek düzeyinde gösterilen SUPPLY ilişki türü için şema gösterir. SUPPLY'ın ilişki seti, SUPPLIER'ın s, PART'ın p, PROJECT'ın j olduğu (s,j,p) ilişki örneklerinin setidir. Genel olarak, ER diyagramında n derece ilişki türü R, her bir katılımcı ilişki çeşidine bağlanan n edge (üstünlük/kıyı/şiddet)ye sahiptir. Şekil 7.17 (b) üç binary ilişki çeşidi CAN_SUPPLY, USES, and SUPPLIES. için ER diyagramı gösterir. Genel olarak, bir üçlü ilişki tipi, üç binary ilişki tipine göre farklı bilgiler temsil eder. CAN_SUPPLY, USES, and SUPPLIES şeklinde üç binary ilişki tipini göz önüne alalım.CAN_SUPPLY, SUPPLIER and PART'ın arasında (s,p) örneği içerir; USES, PROJECT and PART arasında proje jnin part p kullandığı (j,p) örneği içerir; SUPPLIES, SUPPLIER and PROJECT arasında s tedarikçisinin parça sağladığı j proje (s,j) örneği içerir.

CAN_SUPPLY, USES ve SUPPLIES'daki üç ilişki örneğinin (s, p), (j, p) ve (s, j) varlığı, (s,j,p) örneğinin üçlü ilişki SUPPLY da olduğu anlamına gelmez. Çünkü anlamı farklıdır. Genellikle, belirli bir ilişki türünün hangi ilişki derecesi ile temsil edileceğine yada daha küük derecelere bölünebilir olup olmadığına karar vermek zordur. Tasarımcı bu karara bilimi veya belirli durumların anlamlarını temel almalıdır. eğer bunlar başka anlamları temsil eder ve uygulama içinde olması zorunlu ise, çözüm üçlü ilişkinin yanı sıra birden fazla ikili ilişki de içerebilir. Bazı veritabanı tasarım araçları sadece binary ilişkiye izin veren ER modeli çeşitlerini temel alabilir. Bu durumda, SUPPLY gibi ternary ilişki çeşidi, kısmi anahtarı olmayan üç tanımlanmış ilişkili zayıf varlık ile temsil edilmelidir. Üç katılımcı varlık çeşidi (SUPPLIER, PART, and PROJECT) hep birlikte varlık çeşidi sahibi olurlar. (Şekil 7.17(c)) Bu nedenle, şekil 7.17(c)de SUPPLY zayıf varlığı, SUPPLIER, PART, and PROJECT varlığının kombinasyonu olarak tanımlanmıştır. Ternary ilişkiyi, yapay veya vekil anahtarlı bir gerçek (regular) va.rlık ile temsil etmek de mümkündür. Bu örnekte, anahtar nitelik Supply_id regular bir varlık türü dönüşen supply varlık türünde kullanılmalıdır. N:1 lik üç binary ilişki çeşidi SUPPLY ile bağlantılıdır. Bir başka örnek, Şekil 7.18 gösterilmiştir. Ternary ilişki türü OFFERS, belirli bir dönem boyunca dersi veren eğitmenler hakkında bilgi verir. Böylece ilişki örneği (i,s,c) içerir. i ; INSTRUCTOR (dersi veren), c; COURSE (ders), s; SEMESTER (dönem). Şekil 7.18 de gösterilen üç ikili ilişki türleri aşağıdaki anlamlara sahiptir:

CAN_TEACH, dersi hocaya; TAUGHT_DURING dönemi hocaya; OFFERED_DURING, dönemi derse bağlayan ilişkidir. Bu ternary ve binary ilişki farklı bilgiler temsil eder, fakat bazı kısıtları ilişkiler arasında tutmak gerekir. Örneğin, örnek (i,s) TAUGHT_DURING içinde, örnek (s,c) OFFERED_DURING içinde, (i,c) CAN_TEACH içinde olmazsa, ilişki örneği (i,s,c) OFFERS'ın içinde olmamalıdır. TAUGHT_DURING and OFFERED_DURING'ın örneklerinin varlığını OFFERSdaki örnekten çıkarabiliriz, fakat CAN_TEACH örneğini çıkaramayız. Bu nedenle TAUGHT_DURING and OFFERED_DURING gereksizdir ve kaldırılabilir. Genelde üç binary ilişki ternary ilişkinin yerini almamasına rağmen, belirli kısıtlar altında bu yapılabilir. Bizim örneğimizde CAN_TEACH ilişkisi 1:1liktir. (bir dersin bir hocası bir hocanın bir dersi olur.Burada herkes bir ders anlatıyormuş.) Sonra ternary ilişki OFFERS çıkarılabilir çünkü üç ikili ilişkiden CAN_TEACH, TAUGHT_DURING, and OFFERED_DURING den bu çıkarılabilir. Şema tasarımcısı, binary mi ternary mi ilişki çeşidinin gerekli olduğuna karar vermek için her özel durumun anlamını analiz etmelidir. İlişki türünü tanımlayan ternary (or n-ary) zayıf bir varlık türü olmasının mümkün olduğuna dikkat edin. Bu durumda, zayıf varlık türü, çeşitli varlık türleri sahibi olabilir. Örneği şekil 7.9da verilmiştir. Bu örnek, çeşitli şirketlerin iş görüşmesi kayıtlarını tutan database'in bir kısmını gösterir.İş bulma kurumunun bir parçası olabilir. Bu gereksinimlerde, aday aynı şirketle birden fazla görüşmede bulunur. Farklı departmanlarla veya ayrı görüşmeler olarak, fakat bir görüşmenin üzerinden teklif sunulur. Burada INTERVIEW, CANDIDATE and COMPANY'nın parent olduğu ve kısmi anahtarı Dept_date olan zayıf varlığı temsil eder. INTERVIEW varlığı, aday, şirket ve görüşmenin yapıldığı departman ve tarihin kombinasyonu tarafından tanımlanır.

3.9.2. Ternary (yada Yüksek Dereceli) İlişki üzerindeki Kısıtlar Constraints on Ternary (or Higher-Degree) Relationships Orada n-li ilişkiler üzerinde yapısal kısıtlar belirlemek için iki gösterim vardır ve bunlar farklı kısıtlamalar belirtir.Üçlü ya da daha yüksek derece ilişkisine yapısal kısıtlamalar belirtmek için önemli ise her ikiside kullanılır. İlk gösterimde Şekil 7.2 görüntülenen binary ilişkilerin önem oranı gösterimine dayanır. Şekil 7.17deki SUPPLY ilişkisinin kısıtı açıklayalım. SUPPLY ilişki seti, (s, j, p) ilişki örneğinin setidir. Kısıtın belirli bir proje-part kombinasyonu için var olduğunu varsayalım; sadece supplier kullanılacaktır. (bir tedarikçi belirli bir parçayı belirli proje için tedarik eder.) Bu durumda SUPPLIER 1, PROJECT ve PART M ve N önem derecesine sahip olur. Şekil 7.17. Bu, belirli bir (j, p) kombinasyonu, ilişki kümesinde en fazla bir kere görünebileceği kısıtını belirtir. Çünkü her (PROJECT,PART) kombinasyonunu benzersiz şekilde tekil bir tedarikçi belirler. Bu nedenle, herhangi bir ilişki örneği (s,j,p), (j,p) nin anahtar olduğu (j,p) kombinasyonu tarafından ilişki setinde benzersiz şekilde tanımlanır. Bu gösterimde, 1 olarak belirtilen katılımcılar ilişki kümesi için tanımlama anahtarın bir parçası olmak zorunda değildir. İkinci gösterim Şekil 7.15de binary ilişki için (min, max) gösterimine dayanır. (min, max) katılım, her bir varlığın en az min en çok max kadar ilişki setine katılmasını belirtir.