Faculty of Engineering and Architecture Computer Engineering Department LAB 1 WORKSHEET DATABASE DESIGN Küçük uygulamalarda veritabanı tasarımcıları uygulama gereksinimlerini hemen anlayabilir ve oluşturulacak ilişkileri, attributelere ve ilişkideki kısıtlara direkt karar verebilir. Ama bu gibi direkt tasarımlar gerçek dünya uygulamaları için zordur. Çünkü gerçek dünya uygulamaları bir hayli komplekstir. Veritabanı tasarımcısı uygulama kullanıcısı ile görüşerek uygulama gereksinimlerini anlar ve onu kullanıcının anlayabileceği high level formatta gösterir. Daha sonra high level gösterimi low level tasarıma dönüştürür. ER Model Veritabanının tüm mantıksal yapısını gösteren veritabanı tasarımını yapmamızı sağlayan veri modelidir. E-R model gerçek dünya kavramlarını, anlamlarını ve etkileşimlerini kavramsal modele eşlemede kullanılır. Bu kullanışlılığından dolayı birçok veritabanı tasarım aracı ER model konseptini çizmektedir. ER data model in üç temel konsepti vardır : entity kümesi, relationship kümesi ve attributeler. Entitiy Kümesi Gerçek dünyadaki diğer tüm nesnelerden ayrılabilen şey ya da nesne dir. Örneğin üniversitedeki her bir insan bir entity dir. Bir entity bir dizi özelliğe sahiptir ve bazı özelliklerin değerleri entity i
unique olarak tanımlayabilir. Örneğin person insanı unique olarak tanımlayan bir person_id attribute üne sahip olabilir. Böylelikle person_id 1230 üniversitedeki sadece belirli bir insanı belirtir. Entity set aynı tipteki aynı özellikleri ya da attributeleri paylaşan entity kümesidir. Örneğin verilen bir üniversitedeki hocaların hepsi instructor entity kümesinde tanımlanabilir. Entityler ayrık olmak zorunda değillerdir. Örneğin üniversitedeki tüm insanları person entity kümesinde tanımlarsak bir person entity si instructor entity ya da student entity ya da ikisi ya da hiçbiri olabilir. Bir entity bir küme attribute tarafından gösterilebilir. Attributeler her bir entity için sahip olduğu tanımlayıcı bir özelliktir. Örneğin instructor entity için olası attributeler ID,name,dept_name ve salary. Gerçek hayattaki uyguamalar için bu attributeler attırılabilir. Bir entity her bir attribute ü için bir değere sahiptir. Örneğin instructor entity ID attribute ü için 12121 değerine sahip olabilirken name attribute ü için Esra değerine sahip olabilir. Aynı isimde birden fazla instructor olabileceği için ID attribute ü bir instructor ı unique olarak tanımlayabilir. Bir veritabanı aynı tipte entity barındıran entity setlerinden oluşan bir koleksiyondur denilebilir. Simple (atomic) Attribute : Bölünmeyen attributeler. Composite Attribute : Örneğin bir address attribute ü 3 simple attribute e ayrılabilir. Number, Street, Apartment_number gibi. Composite attributeler atomic attributelerin birleşimiyle oluşur. Entity Attribute Multi valued Attribute Key : Attribute değeri entity e has bir değerse yani key olabilecek nitelikte ise Attribüte ismi altı çizili olarak gösterilir. Yani aşağıdaki resme göre her departmanın isminin ve numarasının farklı olacağı ve bir departman numarasının ve bir departman isminin yalnızca ve yalnızca bir departmana ait olacağı bilgisini elde ederiz.
Relatonship : Birçok entity arasındaki ilişkidir. Örneğin Arda adlı öğrenci ile Esranr adlı öğretmen arasında danışmanlık yapmak ilişkisi kurulabilir. Bir relationship descriptive attributes adı verilen attributelere sahip olabilir. Öğretmen öğrenci arasındaki danışmanlık yapmak ilişkisini düşünelim. Bu ilişkiye öğretmenin ne zaman öğrenciye danışman olduğunu belirten bir date attribute ü eklenebilir. Relation Degree of Relationship : İlişkiye katılan entity type sayısıdır. Aşağıdaki örnekte görüldüğü gibi WORKS_FOR ilişkisine 2 entity type bağlanmıştır. WORKS_FOR un derecesi binary dir. Eğer 3 entity tyape bağlanmış olsaydı ilişkinin derecesi ternary olacaktı.
Şekil X İlişki isimleri entitylerin oynadıkları role name i belirler. Yukardaki örnek için konuşulacak olursa EMPLOYEE entitysinin işçi rolü oynadığı ve departmanın ise işveren rolü oynadığı söylenebilir. Recursive relationship : Eğer bir entity ie diğer bir entity arasında farklı rollerde ilişkiler varsa bu ilişki recursive ilişki olarak tanımlanır. Burada role isimleri hayati önem taşımaktadır. Constraints İlişkiye katılan entitylerin genellikle olası kısıtlı kombinasyonları mevcuttur. Bu kıstılar ilişkinin bize gösterdiği küçük dünya durumundan çıkarılır. Şekil X e bakılacak olursa bir işçinin yalnızca bir departmanda çalışabileceği ve departmanda da N tane çalışanın olabileceği gösterilmektedir. Cardinality ratio Entity nin o ilişkiye katılabileceği maksimumu sayıyı gösterir. Yine Şekil X teki örneğe bakacak olursak DEPARTMENT : EMPLOYEE cardinality ratio su 1:N olarak gösterilir. Daha önce de ifade ettiğimiz gibi 1 DEPARTMENT N işçi ile ilişkilendirilebilirken işçi sadece 1 department ile ilişkilendirilebilir. 1. One-to-One : A kümesindeki bir entity B kümesinden en fazla bir entity ile eşlenebilir. Aynı şekilde B kümesinden bir entity ise kümesinden en fazla 1 tane entity ile eşlenebilir. Şekil Y de gösterildiği gibi bir departmanı yalnızca bir çalışan yönetirken, bir departman yalnızca bir çalışan tarafından yönetilir.
Şekil Y 2. One-to-Many : A kümesindeki bir entity B kümesinden 0 ya da daha fazla entity ile eşlenebilirken, B kümesinden bir entity A kümesinden en fazla bir entity ile eşlenir. Şekil Z de görüldüğü gibi bir lisede N tane öğrenci okuyabilirken bir öğrenci en fazla bir lisede okuyabilmektedir. Şekil Z
3. Many-to-One : Bu ilişki one-to-many nin yön değiştirmiş hâli diyebiliriz. A kümesindeki bir entity B kümesinden en fazla bir entity ile eşlenebilir. Oysa B kümesindeki bir entity A kümesinden 0 ya da daha fazla entity ile eşlenebilir. Şekil M ye bakılacak olursa bir öğrenci en fazla bir tane lise ile eşlenebilir. Yani birçok öğrenci aynı lisede okuyabilir ama iki tane lisede okuyamaz. Bir lise bir den fazla öğrenci ile eşlenebilir. Şekil M 4. Many-to-Many : A kümesindeki bir entity B kümesinden 0 ya da daha fazla entity ile eşlenebilirken, B kümesinden bir entity de A kümesinden 0 ya da daha fazla entity ile eşlenebilir. Şekil K dan anlaşılacağı üzere bir işçi birden fazla projede çalışabilmektedir.
Şekil K Total Participation : Eğer bir entity en az bir entity ile ilişkilendirilmek zorunda ise o entity denir. Örneğin bir şirketin Her bir işçi en az bir departmanda çalışmak zorundadır ilkesi olsun. Bu durumda employee entity sinin çalışma ilişkisinde total katılımı sağlanmalıdır. Total participation çift çizgi ile gösterilir. Weak entity type : Kendi key attribute ü bulunmayan entity typelardır. Ait olduğu entity type olmadan weak entity type ifade edilemez. Yani ait olduğu entity type yoksa weak entity type da yoktur. Tersi olan regular entity typelar strong entity type olarak adlandırılır. Weak type her zaman total participation a sahiptir. Aşağıdaki örnekte görüldüğü gibi Parent entity si olmadan Child entity si olamaz. Parent entity sine bağımlıdır. Bir ailede aynı isimli çocuk olmayacağını düşünürsek Cname attribute ü tek bir kişiyi ifade ediyor diyebiliriz. O hâlde Cname attribute üne partial key diyebiliriz.
Örnek : Bir şirket için ER diagram çıkarıyoruz. Öncelikle EMPLOYEE bir nesnedir ve onu entity olarak tanımlayabiliriz. Şirkette departmanlar olacaktır. Onu da DEPARTMENT entity olarak tanımlıyoruz. EMPLOYEE için özellikler tanımlayabiliriz. Çalışanın sosyal sigorta numarası, birinci adı, ikinci adı, soyadı, cinsiyeti, doğum tarihi, cinsiyeti, maaşı ve adresi tutulabilir. Bu özellikler EMPLOYEE entity type ına attribute olarak tanımlanabilir. DEPARTMENT objesi için Adı, numarası, lokasyonları özellikleri tanımlanabilir. Departmanı yönetme ilişkisini nasıl gösterebileceğimizi düşünelim. Bir departmanın sadece bir yöneticisi olur. Tüm çalışanlar yönetici olmak zorunda değildir. O zaman yönetme ilişkisine Employee parçalı olarak katılım sağlayacaktır. Ama her bir departman yönetilmek zorundadır. O zaman Department bu ilişkiye total olarak katılmak zorundadır. Yönetme ilişkisinde de çalışanın yönetmeye başlama zamanını göstermek istiyoruz. O zaman bu özelliği de ilişkinin attribute ü olarak tanımlayabiliriz.
Tüm çalışanlar sadece bir departmanda çalışacaklar. Yani çalışanlar kümesinde boşta kalan çalışan olmamalı. Aynı şekilde çalışanı olmayan departman da olmamalı. Bir departmanın çok sayıda çalışanı olabilir. O hâlde departman için çalışma ilişkisi tanımlanabilir. Yukarıdaki şekli bu bilgiler eşliğinde genişletelim. Departmanların kontrol ettiği projeler olacaktır. Bir departman N tane projeyi kontrol edebilir. Kontrol edilmeyen proje olmayacaktır. O hâlde projeler ilişkiye tam katılım sağlayacaktır. Projenin adı ve numarası olacaktır. Her bir projenin kendine has ismi ve numarası vardır. O hâlde bunlar birer key özelliği taşırlar.
Bazı çalışanların danışmanı olacaktır. Danışmanı varsa sadece bir tane danışmanı olacaktır çalışanın. Bir çalışan birden fazla projede çalışabilir. Bir projenin de birden fazla çalışanı olabilir. Tüm elemanlar projede çalışmalıdır. Tüm projelerin de elemanı olmalıdır. O hâlde iki tarafın da ilişkiye tam katılımı sağlanmalıdır. Aynı zamanda çalışanın projede çalışma saati de kaydedilmelidir.
Çalışanın bakmakla yükümlü olduğu kişiler vardır. Bunlar DEPENDENT entity type ı altında tanımlanabilir. DEPENDENT ların ad, cinsiyet, doğum tarihi ve çalışan ile ilişkisi attributeleri olabilir. Bir çalışanın birden fazla baktığı kişi olabilir ve çalışan olmadığı zaman bu kişilerin kurum için önemi yoktur. O hâlde DEPENDENT ı weak entity type olarak tanımlayabiliriz. Weak entity typelar ilişkiye tam katılım sağlamak zorundalardır.
Şimdi bu ER diyagramının UML ni çıkaralım. Entityler bir dikdörtgende gösterilecektir. Dikdörtgen ikiye ayrılacaktır. Üst kısma entity name yazılır, ikinci bölüme ise attributeler yazılır. Composite attributeler iç kısma yazılır. Sayı limitleri gereksinimlerden yola çıkılarak bulunur. Örneğin Bir çalışan sadece bir departmanda çalışmka zorunda. O hâlde Works_for ilişkinin Department kısmına en az ve en çok eşleneceği değer 1 anlamında 1..1 kısıtı yazılır. Departmanın da en az bir elemanı en fazla da N tane elemanı olacağından diğer kısım ise 1..* olarak gösterilir. Manages ilişkisine bakılacak olursa her bir çalışanın departman yönetme zorunluluğu yoktur. Manages ilişkisinin Department kısmı 0..1 olacaktır. Bunun anlamı bir çalışan hiçbir departmanı yönetmiyor olabilir yönetiyorsa şayet en fazla bir departmanı yönetecektir. Departman is en az ve en fazla bir kişi tarafından yönetilecektir. EER Modeling Specilization Bir entity set bazı alt grup entityler içerebilir. Bu alt gruplar set içerisindeki entitylerden bazı yönlerde ayrılırlar. Örneğin bir alt entity entity setindeki diğer entitylerin sahip olmadığı bazı attributelere sahip olabilir. Örneğin student entity si ms student, phd student olarak 2 sınıfa ayrılabilir. Entity setteki alt grupların dizayn edilmesine specialization denir. Specilaziton ER diyagramda ucu boş ok ile gösterilir. (hollow arrow head) Bu ilişkiye ISA relationship denir. Object oriented dersinde görülen is a ilişkisidir. Yani ms student is a student. Aşağıdaki şekilde disjoint gösterim mevcuttur.
Genarilization Specilizationda farkı aşağıdan yukarı doğru tasarım yapmadır. ISA ilişkisi üst düzey bir varlık türü ile bunun alt türleri arasında kurulan özel bir ilişkidir. ISA ilişkisinde üst düzey varlığın nitelikleri kalıtım yoluyla alt düzey varlık türlerine geçer.
Aggregation ER diyagramda ilişkiler arasındaki ilişkiler gösterilemez. Ternary bağlantılarda veritabanında gereksiz tekrarlar mevcuttur. Aşağıdaki örneği düşünelim. ÇALIŞAN, PROJE ve MAKİNE varlık kümeleri arasındaki üçlü ÇPM ilişkisini düşünelim. ÇPM ilişki kümesindeki *ç,p,m+ üçlüsü çalışan ç'nin p projesinde çalıştığını ve bu proje için m makinesini kullandığını gösterecektir. Bu ilişki hangi çalışanın hangi projelerde çalıştığını ve hangi çalışanın hangi proje için hangi üretim makinesini ne kadar süre kullandığını gösterecektir. Bu ilişkinin uygun bir düzenleme olmadığı görülmektedir. Nedenleri:
Çalışanlar ile projeler arasındaki görevlendirme bilgisi makine kullanımından bağımsız yapılamamaktadır. Bir çalışanın bir projedeki görevlendirme bilgisi, kullanılan makine sayısı kadar tekrarlanmaktadır. Bu üçlü ilişki hem gereksiz tekrarlar içerir, hem de istenmeyen durumlara yol açabilir. Bu nedenle bu üçlü ilişki yerine iki tane ikili ilişki kullanmak daha uygun bir çözümdür. ER diyagramında iki ilişki arasında bağlantı kurulamaz. Daha önce yapılan tanıma göre ikili ilişki iki varlık kümesi arasında kurulur. Kümeleme kavramı varlık kümeleri ve aralarındaki ilişkinin kümelenmesini ve bu kümenin bir varlık kümesi gibi düşünülmesini sağlar. Böylece ÇALIŞAN ve PROJE varlık kümeleri ile aralarındaki ÇALIŞTIĞI ilişkisi kümelenir; KULLANDIĞI ilişkisi ise bu küme ile MAKİNE varlık kümesi arasında kurulur.