Sayfalar

İlişkisel Veri Tabanı Dizaynı

      Çalıştığım kurumlarda işe alım görüşmelerinde çoğu kez değerlendirme kurullarında yer aldım. Yeni mezun adayları değerlendirmek için başvurduğum yöntemlerden biri yazılım sürecini nasıl algıladıklarını değerlendirmektir. Konu kurumsal yazılımlar  olunca, yazılım yaşam döngünüzde en önemli faktörlerden biri,doğal olarak veri modelinizi nasıl oluşturduğunuzdur. Sonuçta kurumsal yazılımınızın hayatı sona erdiğinde ve emekliye ayrılması gündeme geldiğinde dahi ortada kalacak tek şey oluşmuş verilerdir. Hal böyleyken katıldığım görüşmelerde bana veri modelini oluştururken nelere dikkat ettiğini anlatabilen aday sayısı dramatik bir şekilde az. Bunu kendimce çeşitli sebeplere bağlamakla beraber, durumun piyasa olan etkisinden de biraz bahsetmek isterim. Özellikle danışmanlığa başladığım günden  beri farklı veri modelleri ile karşılaştım.  Yüzlerce kolondan oluşan, normalizasyondan son derece uzak, OLTP için hazırlanmış veri modelleri beni ilk başlarda korkuttuysa da, durumun son derece yaygın olduğunu sonradan anladım. Nacizhane bir tavsiye olarak özellikle IT yöneticilerine, OLTP sistemlerinde  için kavrayamadıkları veri tabanı modelleri,  kolonlarının sonunu göremedikleri  tablolar  ile karşılaşıyorlar ise acil tedbirlere başvurmalarını öneririm. 

   Aşağıdaki yazıyı Internet üzerinden erişilebilir kaynaklara bir yenisini daha eklemek ve belki de bu yolla bir kişiye olsun faydasının dokunmasını umarak burada yayınlıyorum. Bu yazının konusu özellikle veri tabanı dizaynı sırasında kavramsal ve mantıksal modelin hazırlanmasıdır. Diğer bazı  konulara  bilgi vermek ve konunun bütünlüğü açısından , kısaca değinilmiştir.

Esen Kalın



VERİ TABANI SİSTEMLERİNİN ORTAYA ÇIKIŞI


         Veri tabanı yönetim sistemlerin ortaya çıkışından önce kullanılan klasik dosya sistemlerinde , veri kümeleri fiziksel olarak ayrı ayrı dosyalara saklanmaktaydı.Kavramsal düzeyde bu dosyalar arasında bir ilişki kurulabilmesine rağmen , bu ilişkilerin kontrolünün veri dosyalarını  kullanacak her programa ayrı ayrı  uygulanması gerekliydi.Bu da dosyaları kullanacak her programın veri bütünlüğünü ve doğruluğunu bozmaması gerektiği anlamına gelmekteydi.

Benzer şekilde  aynı anda birden çok dosyayla çalışan programların dosyaları yönetiş biçimi olduça güçtü.Sözgelimi programınızın başında kullanıcağınız bütün dosyaları açmak , sonunda da doğru bir şekilde kapamak zorundaydınız.


     Bütün bunlar programların yazımını oldukça güç kılıyor ve sıklıkla hatalar yaşanabiliyordu.Yaşanan bu ve bunun gibi sıkıntılar yüzünden programlar ile veri arasındaki bu sıkı ilişkiyi biraz soyutlamak gereği ortaya çıktı.Bu sıkıntıları çözmek içinde veri tabanı sistemleri doğdu.



Veri tabanları ayrı ayrı bulunan dosyaları kendi havuzu içersinde toplandı.Programlar tek tek dosyalar yerine artık veri tabanına bağlanıp isteklerini veri tabanı üzerinden karşıladılar.Programlarla veri tabanının konuşması için özel bir dil geliştirildi.(SQL)

Veri tabanı, kısaca tanımını yapmak gerekirse, uygulama sistemlerince kullanılmak üzere belirli ortamlara saklanmış birbirleriyle ilişkili veriler topluluğudur.Tabi veri tabanının üzerinde havuzdaki verilerin yönetimiyle sorumlu bir veri tabanı yönetim sistemi bulunur.(Database management system) .Bu iki kavram sıklıkla beraber anılırlar.

Veri tabanı yönetim sisteminin temel görevlerine gözatıcak olursak :
• Security (Güvenlik)
Kullanıcı yönetimi , veri tabanına bağlanmak isteyen kullanıcının tanımlanmış haklarına uygun şekilde davranmasını sağlamak vs
• Integrity (Bütünlük /Doğruluk)
Verilerin beklenmeyen durumlarda bozulması , yanlış veri girişinin önlenmesi , beklenmeyen durumlarda verinin tamiri , kaynak paylaşımının düzenlenmesi (veri üzerinde aynı anda birden fazla değişiklik yapılmasını önlemek) gibi
• Time Sharing (Zaman paylaşımı)
Veri tabanını üzerinden yapılan işlemlere belli zaman aralıklarıyla cevap verilmesi , kullanıcılara işlemci zamanının paylaştırılması vs.



VERİ TABANI SİSTEMLERİNİN SINIFLANDIRILMASI

Veri tabanı konusunda genel bir bilgilendirmeden sonra veri tabanları üzerinde verinin nasıl saklandığına gelmek gerekir.Veri tabanları veriyi saklama biçimlerine göre çeşitli katagorilere ayrılırlar. Bunlardan bazıları:

1- Hierarchical (Hiyerarşik )
2-Multidimensional (Çokboyutlu )
3-Relational (İlişkisel)

Hierarchical (Hiyerarşik )
Bu modelde veriler ağaç yapısında dururlar.Bir parent-chield iişkisi vardır.Aşağıda yayımcı – yazar – kitap ilişkisinin hiyerarşik modelde nasıl gösterildiği örneklenmiştir.
Hiyerarşik modelde ebeveyn’in girişi yapılmadan çocukların girişi yapılamaz.Eğer bir ebeveyn silinmek zorunda kalınırsa ilgili tüm çocuklar da silinir.
Ağ modeli (network model) hiyerarşik modelin geliştirilmiş halidir. 1960’ların sonunda hiyerarşik modelde bazı iyileştirmeler öngörülerek hazırlanmıştır.


Multidimensional (Çokboyutlu )
Datawarehouse ve OLAP gibi uygulamalar multidimensional modeli populer hale getirmiştir.Multidimensional modelde temel veri yapısı array (dizin)’dir.Genelliklede data iki boyutlu arrayler (matrix) halinde durur.Temel gaye analiz için gerekli veriye hızlı ve kolay bir şekilde erişmektir.


Multidimensional modelde iki boyut’dan daha fazla boyut’da olabilir.Bu modelde veri sorgulanmak için pek çok kolaylık sunmasına rağmen , verinin kaydı oldukça zordur.

Relational (İlişkisel)

Relational model (ilişkisel model) 1970’lerin başında E. F. Codd tarafından önerilmiştir.İlişkisel data modeli ticari veri tabanı yönetim sistemlerinin temel taşı durumundadır.Bu modelde veriler tablolar halinde durur.Her tablo kolonlar ve satırlardan oluşur.Kolonlar tablonun tanımlanması sırasında belirlenirler , satırlar ise tablo içersine girişi yapılan verileri belirtir.




İlişkisel model bundan sonra da bu yazı da üzerinde durulacak modeldir.



VERİ TABANI DİZAYNI

Bir veri tabanının inşası sırasında en önemli adım veri modelinin hazırlanmasıdır.Gerekli veri tabanı yönetim sisteminin seçilmesi , kurulması , fiziksel kaynaların atanması gibi işlemler işin en kolay yanıdır.Çok para verip Oracle veri tabanı yönetim sistemi almanız mükemmel bir veri tabanına sahip olduğunuz anlamına gelmez. Veri tabanınızda verilerin nasıl duracağını , veriler arasındaki ilişkileri , özeliklleri vs. belirlemek oldukça kapsamlı bir iştir.Veri tabanının oluşturulması için gerekli adımları sıralıyacak olursak :

1. İhtiyaç Analizi
2. Kavramsal modelinin hazırlanması
3. Mantıksal modelin hazırlanması
4. Fiziksel modelin hazırlanması
5. Modelin uyarlanması

şeklinde sayabiliriz.

Bu yazının konusu kavramsal ve mantıksal modelin hazırlanmasıdır.Diğer konulara sadece bilgi vermek açısından , kısaca değinilecektir.


İhtiyaç Analizi
    İş ihtiyaçlarının belirlenmesi ve neyin hazırlanacağının belirlenmesidir diyebiliriz.Tüm gereksinimler iyice anlaşılmadan ve üzerinde iyice tartışılmadan hazırlanan bir veri tabanı , eğer çok basit değilse mutlaka pek çok eksik içerecektir.

İhtiyaçların sağlıklı bir şekilde ortaya dökülmesi için kabaca şu adımlardan geçilir:

1. Gerekli kaynaklardan bilginin toplanması
2. İstenen sistemin uygun bir modelleme tekniği ile modellenmesi
3. Model üzerinde tarafların uzlaşma sağlanması

İyi hazırlanmış bir model ile tam olarak ne yapıldığını ve ne yapılmak istendiğini gösterebilir ve anlayabilirsiniz. İhtiyaç analizi sayesinde sistemde oluşacak tüm fonksiyonları, sistemde yer alan nesneleri ve ilişkilerini görebilirsiniz.


KAVRAMSAL MODELİN HAZIRLANMASI

Kavramsal model aslında nesne-ilişki gösteriminin (entity-relationship diagram ) hazırlanmasıdır diyebiliriz.Bu model genel database modelinden bağımsızdır.Örneğin bu modelde primary key , foreign key , index gibi şeyler bulunmaz.Ve ilerde bahsedilecek olan normalizasyon henüz bu modelde yapılmamıştır. Bu noktada bazı terimleri vermek yerinde olucaktır.

Nesne (Entity) : Var olan ve birbirinden ayrılabilen herşeye nesne denir.Örneğin ağaç , kuş , uçak , müşteri , çalışan vs. Nesne genel bir kavram olup aslında bir kümeyi belirler.Örneğin Uçak bir nesne tanımı THY’nin 1001 nolu Boeign tipi yolcu uçağı ise o kümenin içindeki bir üyedir (instance) .

Nitelik (Attribute) : Var olan her nesne diğerinden nitelikleriyle ayrılabilir.Örneğin bir müşteri nesnesini ele alıcak olursak adı , müşteri numarası gibi bilgiler nesnenin niteliklerini oluşturur.

Anahtar (Key) : Anahtar bir nesne içinde bir üyeyi diğerinden ayırmaya yarayan bir ya da birden fazla niteliğin adlandırılmasıdır.

İlişki (Relation) : İlişki bir nesne ile diğeri arasındaki bağlantının , etkileşim ya da ortaklığın tanımlanmasıdır.Örneğin “personeller belli departmanlara bağlı olarak çalışırlar” kuralı personel nesnesi ile departman nesnesi arasında bir ilişkidir.

Nesne-ilişki diyagramı (Entity Relationship diagram) : Kısaca nesneler ve ilişkilerini gösteren grafiksel bir sunum şeklidir.Kısaca ERD diye de anılır.

Nesne ve Niteliklerinin Tanımlanması 

Kavramsal modelin hazırlanmasının ilk aşaması nesnelerin tanımlanmasıdır.Nesne bir kişi , yer , düşünce , aktivite veya işi ilgilendiren olaylar olabilir.Nesneler tanımlanırken önceden hazırlanan sistem modelinden , görüşmelerden veya raporlardan yararlanılabilir.Nesneler elde edildikten sonra nitelikleri tanımlanır.Bir nitelik şu değerleri alabilir

-Serbest bir değer
-Null değer (hiçbirşey)
-Bir değer gurubu içinden bir değer
-Türetilmiş değer

      Null değerin iki anlamı vardır.Ya o nesne örneği için alacağı değer bilinmiyordur ya da o örnek o nitelik için herhangi bir değere sahip değildir.Örneğin müşteri bilgilerinde tutulan kızlık soyadı erkek müşteriler için hiçbir anlam ifade etmez , yoktur.Erken müşteriler için bu nitelik NULL değerini alır.
Bazen tanımlanan iş kuralları ya da doğal kurallar sonucu nitelikler belli bir değer gurubu içinde kalmak durumunda kalırlar.Örneğin cinsiyet niteliği sadece erkek ya da kadın olarak seçilebilir ya da il kodu türkiye için sadece 1 ile 81 arasındaki tamsayılar olabilir gibi.Bu gibi doğal ya da sanal değer gurupları belli bir nitelik alanı (attribute domain) oluştururlar.

   Türetilmiş değer diğer niteliklerin işlenmesiyle oluşan bir değerdir.( ortalama değer ya da toplam gibi.)
Kavramsal modelde bu noktadan sonraki adım anahtarların belirlenmesi olucaktır.


Anahtarların Belirlenmesi

   Anahtar bir nesne içinde üyelerin diğerinden ayrılmasını ve o üyenin tanımlanması sağlayan nitelik ya da niteliklerdir.

    Elimizde bir müşteri nesnesi olduğunu düşünelim ve isim , telefon numarası , adres niteliklerine sahip olduğunu varsayalım.Eğer her müşteri ayrı bir telefon numarasına sahipse telefon numarası key olabilir ya da her müşterinin adı diğerinden değişikse müşteri adı da anahtar olabilir.

Mantıksal düzeyde sadece potensiyel ana anahtarların (primary key ) belirlenmesi yeterlidir.Bunlar aday anahtar (candidate keys) olarak adlandırılırlar.

     Belirlenen aday anahtarları oluşturan nitelikler mutlaka bir değer taşımak zorundadır.Başka bir deyişle NULL değer alamazlar.Bunun dışında aday anahtarlar nesne üyeleri arasında her üye için farklı bir değer almak zorunda , yani bir anahtar yalnız bir üyeyi tanımlamaladır.Örneğin aynı telefona sahip iki müşteri varsa telefon numarası bir anahtar olarak tanımlanamaz .
      Bazen bir nitelik ile bir anahtar elde edilemeyen durumlarda birden fazla nitelik bir araya gelerek bir anahtar da oluşturabilir.Buna bileşik anahtar (composite key) denir.

    Bazen hiçbir niteliğin üyeleri ayırdetmeye yaramadığı durumlarda yapay anahtar (artifical key) ‘e ihtiyaç duyabilirsiniz.Örneğin örneğini verdiğimiz müşteri nesnesi için müşteri numarası diye yapay bir nitelik oluşturup anahtar olarak tanımlayabilirsiniz.

Nesne ve Niteliklerin Gösterimi

Nesne ve niteliklerin grafiksel gösterimi bu aşamadan itibaren dizayn çalışmalarında oldukça yardımcı olucağından diyagram oluşturmaya başlamakta büyük fayda vardır.Aşağıdaki şekilde üç nesnenin yer aldığı bir diyagram gösterilmiştir.Altı çizili nitelikler anahtar alanlardır.




İş Kurallarının Gösterilmesi

Veri tabanları aslında sadece verinin saklanması değil aynı zamanda bir takım iş kurallarının saklanması ve uygulanması görevini de sürdürürler.Bu yüzden veri modeli çıkartılırken bir takım iş kuralları da modelde yer alır.
İş kuralları kavramsal modelde çeşitli şekillerde yer alırlar.
Nitelikler üstünde nitelik aralıkları (ranges) bir niteliğin alabileceği değer alanını belirler . Yine nitelikler üzerinde kısıtlamalar (constraints ) yani diğer bir niteliğe göre durumunu tanılayabilirsiniz.Bitiş tarihinin , başlangıç tarihinden büyük olması gibi.
Derlenmiş veriler (Derived Dat) üzerinde zaten doğal olarak bir takım iş kuralları yer almaktadır.Derlenmiş veriler diğer niteliklerin verilerinin işlenmesiyle oluşur.Örneğin toplam yada ortalama değerler gibi.
İlişkiler (Relationships) de iş kurallarının modele yansıtılmasının bir diğer yoludur.İlişkiler adı üzerinde nesneler arasındaki ilişkileri tanımlar.Bu sayede örneğin kitap nesnesinde tanımlanmamış bir kitabın , kitap satış listesinde yer almaması gibi bir kuralı tanımlayabilirsiniz.Bundan sonraki bölüm bu konu üzerinde duracaktır.

Nesneler Arası İlişkiler (Relationships between entities) 

İlişkişkiler bize nesnelerin diğerleriyle nasıl çalıştığını gösterir.Nesneler arasında çok çeşitli ilişki tipleri olarbilir.Anlamak için örneklendirecek olursak:

Bağımlılık(Dependence) Bir nesnenin varolması bir diğerinin varolmasına bağlıdır ve kendi başına tam bir anlam ifade etmez.Örneğin müşteri telefonu nesnesi müşteri tanımlanmamışsa bir anlam ifade etmez.
Düzenleme(Composition) Bir nesne diğerini düzenler.Örneğin araç nesnesi şasi , motor ,gövde nesneleri ile düzenlenir.
Ürün(Production) Bir nesne diğerini üretir yaratır yada üretir.Örneğin kitap nesnesinin olabilmesi için onu üretecek bir yazar nesnesine ihtiyaç vardır.
Üyelik(Membership) Bir nesne kendinden daha büyük bir sınıfın üyesidir.Örneğin çalışan nesnesi departman nesnesinin bir üyesidir.
Kullanma(Use) Bazen bir nesne diğer bir nesne yi kullanır yada onun özelliklerine ihtiyaç duyar.Örneğin proje nesnesi , çalışan nesnesini kullanır.

Peki ilişkilerin mantıksal model içindeki özellikleri nelerdir.Bunu tanımlamak için bir örnek üzerinden gidelim.Örneğin personel ve departman nesnelerini ele alalım.Bu iki nesne arasındaki ilişki “personel bir departmana bağlı olarak çalışır “ şeklindedir.Bu ilişkinin özelliğini belirlemek için iki soru gereklidir :

“Bir departmanın kaç çalışanı olabilir ? “
“Bir personel kaç departmanda çalışabilir ?”

• Eğer her iki soruya da bir cevabı verilmişse bu birebir (1-1) bir ilişkiyi tanımlar.Örneğin bir departmanın bir personeli olabilir ve bir çalışan bir deparmanda çalışabilir
• Eğer iki sorundan birine bir diğerine birden fazla bir değer söylenmişse bu bire –çoklu ilişkiyi gösterir (1-m).Örneğin bir departmanda birden fazla personel çalışır fakat bir personel yalnız bir departmanda çalışabilir.
• Eğer her iki soruyada birden büyük bir değerle cevap verilmişse bu çoklu-çoklu (m-m) ilişkiyi gösterir.Örneğin bir departmanda birden fazla personel çalışabilir ve bir personel birden fazla departmanda çalışabilir durumu

İlişkinin iki tarafına bakıcak olursak her bir nesne için ilişki sadece iki durum alabilir.Birli ya da çoklu .İlişki tanımlanırken , tüm seçenekler sadece yukardaki kadar değildir.Örneğin bir personel departmana bağlı olarak ya da bağımsız olarak çalışabilir gibi bir durum da söz konusu olabilir.İlişkinin nesne açısından birli yada çoklu olmasına göre seçenekleri de şöyle sıralayabiliriz.

• Kesinlikle bir (Exactly one) Birli ilişkide ilişkinin mutlaka kurulması durumudur.(personel kesinlikle bir departmana bağlı olmalıdır)
• En çok bir (At most one) Birli ilişkide mutlaka bir bağımlılık aranmaması durumudur.(Bir personel bir departmana bağlı yada bağımsız olarak çalışabilir)
• En az bir (At least one) Çoklu ilişkide mutlaka bir ilişki kurulması durumudur.(Bir departman kurulması için mutlaka en az bir personel gereklidir.)
• Herhangi bir sayıda (Any Number) Çoklu ilişkide mutlaka ilişkinin aranmaması durumudur.(Bir departman kurulması için mutlaka yer alıcak eleman gerekmez)


İlişki türleri ve seçeneklerini açıkladığımıza göre bunların nesne ilişki diyagramında (ERD) nasıl gösterildiğine geçebiliriz.


Bu noktada kullanacağınız araç ve modelleme tipine göre modelleme elemanları arasında küçük farklılıklar olabileceğini belirtmeliyiz. Yukarıdaki listede seçeneklerle beraber ilişkilerin gösterimi yer almaktadır.Konuyu ele alırken kullandığımız örnek ise aşağıdaki gibi gösterilir.


Örneği okuyacak olursak diyagramdan “Personel en çok bir departmanda çalışabilir ve departmanların birden fazla çalışanı olabilir” ve “Personeller departman bağlı olarak çalışmak zorundadır.Departmanlar ise mutlaka bir personele sahip olmak zorunda değildir” anlamları çıkar.
Yukarda verilen basit ilişki örneğinin yanı sıra daha karmaşık ilişki örnekleri de bulunmaktadır.Bunları şöyle sınıflandırabiliriz:

• Yinelemeli ilişkiler (Recursive relationships)
• Supertip-Alttip ilişkileri (Supertype-subtype relationships)
• Bağımlılık ilişkileri (Dependent relationships)
• Kompleks ilişkiler (complex relationships)


Yinelemeli ilişkiler bir nesnenin kendiyle olan ilişkisidir.Örneğin personel’ler aynı zaman da bir yöneticiye bağlı olarak çalışmaktadır.Fakat yönetici kendisi de bir personeldir.Bu ilişki şu şekilde gösterebilir:




Şekilde “personel bir başka personele bağlı olabilir (opsiyonel) ve bir personele bağlı birden fazla personel olabilir (opsiyonel NULL dahil) “ ilişkisi gösterilmiştir.
Daha iyi anlaşılması açısından bir örnek daha verebiliriz.Vatandaş nesnesinde evlilik ilişkisini ele alalım.Bu ilişki her iki taraf açısından da opsiyonel (en çok bir ) durumdur.




Nesne ilişki diyagramında kolaylık ve gösterim açısından bazen bir nesnenin eşini (synonym) yaratarak da kullanabilirsiniz.İstenirse yinelemeli ilişkiler de aynı şekilde çalışılarak daha rahat gösterilebilir.



Supertip-Alttip İlişkileri (yada miras (inheritance) ilişkileri ) bir nesnenin bağlı olduğu nesnenin alt gurubu olması ya da ondan türemesi örneğinde geçerlidir.
Örneğin satış personeli , personel nesnesinin bir alt gurubunu oluşturur.Genel olarak personel niteliklerine sahip ve onun bir alt kolu olmasına rağmen bazı kendine özgü nitelikleri de vardır.(Satış tutarı gibi)


     Miras ilişkisinin gösterimi yukarıda örneklenmiştir.Yukarıdaki örnek “satış personeli de bir çeşit personeldir “ şeklinde okunabilir. (Bu yüzden supertype –subtype olarak adlandırılmıştır.)
      Miras ilişkisi aslında bire bir ilişkidir.Miras ilişkisi tanımlanırken çocuk nesne , ana nesnenin tüm özelliklerini ya da tanımlayıcı niteliğini miras alabilir.Burada ipucu olarak belirtmek gerekirse supertip’ten bağımsız bir alttip yaratmak istiyorsanız tüm nitelikleri miras almanız , eğer bir bağımlık yaratmak istiyorsanız sadece tanımlayıcı (anahtar) niteliği referans almanız gerekir.

       Bu ilişki türünde birden fazla alttip yaratılabilir.Supertip’in üyelerinin eğer sadece bir alt tip de yer alması isteniyorsa ortaklığa kapalı (mutually exclusive) alttipler yaratılabilir.Bunu diagramdaki küçük çarpı işaretiyle gösterebilirsiniz.


Bağımlılık İlişkileri bir nesnenin diğerine bağımlı olarak yaratıldığı bir ilişki türüdür.Ana nesne aynı zamanda alt nesneyi de kısmen tanımlar.Ebeveyn olmadan çocuk tek başına var olamaz.Örneğin müşteri hesabı ve müşteri nesnelerini ele alalım.Bir müşteri hesabının müşteri olmadan olması imkansızdır.




Kompleks ilişkiler üç ya da daha fazla nesne arasında olan ilişkilerdir.Ve her ilişki çokludur.
Bir şirket düşünelim.Bu şirketin çalışanları çeşitli rollere sahip olsunlar .Fakat her role sahip olabilmek için de rolle ilişkili kurslara katılmak gereksin.Aynı zamanda bir rol için de birden fazla kurs gerekebilsin.Bu durumun gösterimi şu şekilde olacaktır.




         Fakat bu gösterim bazı hatalara yol açabilir.Örneğin personel ile kurs arasındaki tek ilişki personelin kurslara katılması değildir.Aynı zamanda kursunda verilmesi için personele de ihtiyacı vardır.
Bu durumda kursu veren mühendis ile , kurs almaya gelen mühendis birbirinden ayrılamaz.Bu durumu çözmek için ara bir nesne yaratılır.(Bir rol için kurs alan personel).



Kompleks ilişkiler için bir başka gösterim şekli de ilişkinin üzerinde nitelik tanımlamaktır.Başka bir deyişle iki nesne arasındaki ilişki nitelikle belirlenir.


Fakat bu method pekçok modelleme aracı tarafından desteklenmez.




Kavramsal Modelin Tamamlanması

Kavramsal modelin tamamlanması için modelin standard kontrolü ve gerçeğe uygunluğunun tescili gereklidir.Modelin gerçeğe uygunluğu sistem kabulü için tarafların bir araya gelimesi ve model üzerinde anlaşılması ile olur.
Fakat bu adımdan önce modelin doğruluğunun sınanması ve standarda uygunluğunun kontrol edilmesi gerekir.Kavramsal modelin kurallara uygunluğu şu şekilde sınanabilir.

• İki nesne arasında birden fazla ilişki tanımlanmamış olmalıdır
• Dairesel bağımlılıklar ve iki nesne arasında aynı bağımlılıklar olmamalıdır
• Dengelenmiş 1:1 ilişkiler kaldırılmış olmalıdır
• Hiçbir nesne bir diğer nesnenin aday anahtarını içermemelidir
• Yinelemeli ilişki içeren bir nesnenin başka bir nesneyle mutlaka ilişkisi olmalıdır

Bu kontrollerden sonra modelde direk olmayan ilişkiler ve bileşik nitelikler olup olmadığına dikkat edilmeli ve bu durumlardan kaçınılmalıdır.Kontrollere biraz açıklık getirmek ve örneklemek yerinde olucaktır.

Öncelikle aynı iki nesne arasında birden fazla ilişkinin bulunması kavramsal modelin esaslarıyla bağdaşmaz.Eğer kavramsal model doğru şekilde hazırlandıysa fazla ilişkiler olmamalıdır.Eğer böyle bir gereksinim varsa , tanımlanması unutulmuş nesne ( yada alttip) var olabilir.Bu durum kontrol edilip düzeltilmelidir.

İkinci kural olarak iki nesne arasında aynı bağımlılık olamaz.Bir nesne eğer var olmak için diğerinin üyesine ihtiyaç duyuyorsa , diğer nesne de varolmak için öbürüne ihtiyaç duyamaz.Örneğin bir departmanın kurulması için illa bir personele ve bir personelin alınması için illa bir departmana ihtiyaç duyulamaz.Çünkü açıkça bu durumda her ikisi de olamaz.

Benzer bir şekilde ikiden fazla nesne arasında da dairesel bağımlılık yaratılmamalıdır.





Yukarıdaki örnekte olduğu gibi bir ilişki aynı şekilde hiçbir nesnenin olamaması sonucunu doğurur.Yukarıdaki daire de en az bir nesne bağımlı olmamalıdır ki diğer nesneler de var olabilsin.

Dengelenmiş 1:1 ilişkiden kasıt 1:1 ilişkilerde her iki nesne içinde ilişkinin aynı şeçenekle yaratılmış olmasıdır.











Eğer ilişki iki taraf içinde kesinlikle bir şeklinde tanımlanmışsa her iki nesne de var olamaz.Bu durum genellikle bir nesnenin yanlışlıkla iki parçaya ayrılmış olmasından kaynaklanır.(Ya da iş tarifi hatalıdır)

Eğer iki taraf için de en fazla bir durumu var ise bu durum aslında bir nesnenin diğerinin alt tipi olduğunu bir göstergesidir ya da modelde henüz gösterilmemiş bir süper tip vardır ve her iki nesne de birer alttip ‘dir.

         Nesnelerin diğer nesnelerin aday anahtarlarını içermemeleri konusuna gelince ilişki bağımlılık veya supertip-alttip şeklikde değilse muhtemelen yanlış tanımlanmış nitelikler sözkonusudur.Kavramsal modelde dış anahtar (foreign key) tanımı yoktur.Ve ilişkiler de kavramsaldır.

              Direk olmayan ilişkiler ise gereksizdir.Bu tip ilişkiler zaten sağlanmış olan birşeyin tekrarıdır.Örneğin departmanların altında çalışma gurupları ve guruplara bağlı çalışan personellerin olduğunu düşünelim.

                Bu durumda yukarıdaki gösterimde personel ile departman arasındaki ilişki kesinlikle gereksizdir.Bunun yerine aşağıdaki model daha doğrudur.



           Bileşik niteliklerdense mümkün olduğunca kaçınmak gereklidir.Bileşik nitelikden (composite attributes) kasıt birden fazla niteliğin , tek bir nitelik altında toplanmasıdır.Örneğin adres bilgisi sokak adresi , şehir , posta kodu gibi niteliklerin birleşmesinden oluşsun.Bu durum daha sonra hem kuralların tanımlanması , hemde verinin işlenmesinde çok çeşitli sorunlara yol açıcaktır.Örneğin 5 numerik karakter’den oluşan posta kodunun gerçektende böyle yazılabilmesi için çok fazla efor sarf etmeniz gerekecektir.

      Tüm bu kontroller ve incelemelerden sonra oluşturulan nitelik alanları (attribute domain) ve nitelik tanımları dikkatlice gözden geçirilmeli , ilerde değişiklik gösterebilecek nitelikler buna uygun olarak tanımlanmalıdır.Örneğin fiyat alanları enflasyon sonucu bir sene sonra yetersiz hale gelmemelidir.


MANTIKSAL MODELİN HAZIRLANMASI

Mantıksal model , kavramsal modelin fiziksel modele uyarlanmaya hazır hale getirilmiş halidir.Fiziksel model için kavramsal modeldeki nesne kavramları tablolar haline getirilir , tablolara anahtarlar atanır ve bunlar üzerinden ilişkiler yabancı anahlar şekline çevrilir.Normalizasyon adımlarından geçilerek mantıksal model tamamlanır.


Nesnelerin Tablolar Haline Çevrilmesi
Mantıksal model içinde , kavramsal modelde hazırlanmış olan nesneler artık tablolar halinde düşünülür.














Yukarıdaki ERD’de yeralan nesnelerin tablolara dönüştürülmüş hali şöyledir.

YAYINCI

Yayinci No

Adi
Telefonu
Adresi
4680
Adam Yayınları
212-4456824
Yeniyol sk 5 Besiktas
32110
Can Yayınları
216-5534668
Duru sk 12/3 Acıbadem

           Tablo başlık ve vücut olmak üzere iki kısımdan oluşur.Başlık tablo adı ve kolonlardan , vücut kısmı ise satırlardan oluşur.Bir tablo vücut kısmında aynı iki satır olamaz.Benze şekilde başlık kısmında da aynı iki kolon adı bulunamaz.Bu tablonun herhangi bir satırının , herhangi bir kolonu yalnız bir değer alabilir.
         Bir nesne bu kurallara uyduğunda ilişkisel modelle de tanışmış sayılır.Satırlar özel bir dizilişte değildirler , bu nedenle de tablo içindeki sıra numarasına göre tanımlanamazlar.Sonuç olarak ana anahtar (primary key) satır üzerinde işlem yapabilmek için tek güvenli yoldur.Ana anahtar tablonun her satırını tanımlayabilen kolon yada kolonlardan oluşur.

1. Normal Form 

    Normalizasyon beş adımda modele uygulanan bir süreçtir.Daha geniş tanımı daha sonraki konularda ele alınacaktır.
Eğer tablonun her bir satırının , her bir kolonu yani eğer tek bir değer taşıyorsa birinci normal form oluşmuş demektir.Diğer bir deyişle bir hücre iki niteliği bir arada barındırmamalıdır.Yani ad ve telefon gibi iki ayrı nitelik aynı hücrede yer almaz. Bu özellik aynı zamanda atomik olarak adlandırılır.Çünkü daha küçük hücreler yaratılamaz.
Genellikle üç çeşit nitelik 1. Normal forma geçerken sorun çıkarır:
1. Bileşik nitelikler (composite attributes)
Birden fazla alanın birleşmesinden oluşmuş bu tip kolonlar atomik hale çevrilmelidir.Örneğin konteyner numarası niteliği firma numarası ve ürün numarası gibi alanlardan oluşuyorsa bu alanlar ayrılar ayrı kolonlar oluşturulmalıdır.
2. Çoğul nitelikler (plural attributes)
Bazen bir nitelik birden fazla değer alabilir.Örneğin telefon numarası niteliği bir müşterinin birden fazla telefonu olabilmesinden dolayı çoğul bir nitelik oluşturur.Bu durumda ya birden fazla kolon yaratılarak (telefon 1 , telefon 2 …) sorun giderilir , ya da telefon numaraları için ayrı bir nesne yaratılarak (müşteriye bağımlı) çözüm üretilir.Bu durumda ikinci bir tablo da oluşturulur.
3. Kompleks veri tipindeki nitelikler
Video klip , vektor grafikleri gibi veriler karmaşık veri tiplerindedirler.Bunlar üzerinde atomik olup olmamaları üzerine tartışma yürütülebilir.Örneğin eğer bir video klibin tek tek sahnelerine ihtiyaç duyulmuyorsa klip atomik sayılabilir , aksi halde sahne sahne parçalanarak atomik hale getirilmelidir.

Ana Anahtar (Primary Key) Atanması

Bu aşamada aşağıdaki kriterlere uyan aday anahtarlardan biri ana anahtar olarak seçilir.
1. Tanımlanabilir bir değere sahip olmalıdır(Null içermemelidir)
2. Sürekli olmalıdır (Değeri değişmemelidir)
3. Minimal olmalıdır (Mümkün olduğu kadar az veri içermelidir)
4. Şifrelenmiş değer içermemelidir
5. Bütün database kullanıcıları tarafından erişilebilir olmalıdır

Eğer bu kurallara uygun bir anahtar bulunamıyorsa o zaman yapay bir anahtar oluşturulabilir.Bunun dışında eğer bulunan anahtarlar çok büyük veri içeriyorsa yada içerdikleri veri eğer hassas ve gizli tutulması gereken birşeyse o zaman da yapay anahtar oluşturulabilir.
Bunlar dışında kavramsal model oluşturulurken değinilen anahtar oluşturma kriterleri unutulmamalıdır.En önemli kriter anahtarın tablo boyunca kendini tekrar etmemesidir.

Yabancı Anahtar (Foreign Key)

Ana anahtar nesne üyelerinin , mantıksal modelde tablo satırlarının tanımlanmasında kullanıldığına göre , kavramsal modelde tanımlanan ilişkilerin , mantıksal modelde bu anahtarlar üzerinden tanımlanması gerekir.
Bir nesnenin diğer bir nesneyle ilişki kurması ancak ana anahtar üzerinden olabileceğinden , tablonun ilişkide bulunduğu diğer tablo yada tabloların anahtarını da içermesi gerekir.Bir tablonun ilişkiyi tanımlamak üzere içerdiği diğer tablo anahtarına yabancı anahtar (foreign key) denir.Yabancı anahtar aynı zamanda tablolar arası ilişki de tanımlar.
Yabancı anahtarın aldığı değerler mutlaka referans alınan tablo içinde bulunurlar.Aksi taktirde veri tabanı yöneticisi böyle bir veri girişine izin vermez.Bu durumun tek istisnası yabancı anahtar için tanımlanan kolonların NULL değer alabileceğini belirtmektir.Bu durum 1:1 ilşkide en çok bir ve M:1 ilişkide herhangi bir sayıda seçeneklerinin aktarılmasında kullanılır.









         Yukarıda görüleceği üzere yazar tablosu yayinci tablosunun ana anahtarını kendi kolonları arasına almıştır.Yayinci_no yazar tablosundaki yabancı anahtardır.

       Supertip-alttip ilişkisinin mantıksal modele taşınması sırasında yapılacak şey alttip’in süper tip ile aynı ana anahtara sahip olması ve ana anahtarın aynı zamanda yabancı anahtar da olmasıdır.









Kavramsal modeldeki bağımlılıkların taşınması sırasında ise bağımlı olunan nesnenin ana anahtarının bağımlı nesnenin ana anahtarında yer alması ve bileşik anahtar oluşturulması şeklinde bir yol izlenir.








Çoklu : Çoklu İlişkilerin Taşınması

Çoklu:Çoklu ilişkiler mantıksal modele olduğu gibi taşınamazlar.Tablonun bir satırında diğer tabloyla ilgili yalnızca bir tane anahtar bulunabileceğinden bunun çözümü ancak ara tablolar yaratılmasıyla mümkün olur.





Yaratılan ara tabloda her iki tablonunda primary key’I referans alınarak bu sorun çözümlenir.



Diğer İlişki Tipleri
Kompleks ilişki tipleri daha evvelden kavramsal model içinde çoklu:çoklu ilişkiyi çözmüş olduğundan , ara nesne için yaratılan tabloda referans tabloların anahtarları foreign key ve bileşik ana anahtar olarak tanımlanarak taşınır.
Yinelemeli ilişkilerin taşınmasında ise tablonun ana anahtarının başka bir kolon adıyla yaratılarak yabancı anahtar oluşturulması gerekir.


NORMALİZASYON

Daha evvelde bahsettiğimiz gibi normalizasyon beş adımdan oluşan bir süreçtir.Bu adımlar aslında kolonların doğru yerde yer alıp almadığını , ek tablolar gerekip gerekmediğini tespit eden , kısaca modeli en efektif hale getirmemizi sağlayan bir yoldur.Adımları kısaca tarif edecek olursak

1NF Eğer tablonun her kolonunun , her satırı tek bir tip veri tutuyorsa 1. Normal formdadır.Her hücre atomik olmalıdır.


2NF Eğer tablonun her kolonu ana anahtara fonksiyonel bağımlıysa ikinci normal formdadır.Örneğin aşağıdaki örneği ikinci normal forma getirebilmek için Resmin tutulacağı ikinci bir tabloya ihtiyaç vardır.



Başka bir örnek de bileşik anahtar dan verilebilir.



Bu tablonun 2NF uyması için yine iki tabloya ayrılması gerekmektedir.Başka bir deyişle bağımlılık ana anahtara göre olmak zorunda olduğundan , tablo buna uygun olarak bölünür.
2NF’un temel amacı farklı fonksiyonlar için erişilecek veri sayısını en aza indirmektir.Örneğin yukardaki örnekte 2NF ‘a uyulmaması halinde Eyalet adına erişmek için gereksiz pekçok veri okunacakdı.



3NF üçüncü normal form için tablonun anahtarı ile kolonları arasında geçişli bağımlılık kalmamalıdır.Tüm kolonlar direk olarak anahtara bağlı olmalıdır.


Örnekte katalog tablonun anahtarı olduğu halde renk aslında ürün koduna bağımlıdır. Katalog ile renk arasında ürün üzerinden geçişli bağımlılık vardır.Bir ürünün rengini bulabilmek burada son derece gereksiz veri okumaya yol açıcaktır.Bu durumdan kurtulmak için tablo bölünerek 3NF’a uygunluk sağlanır.



Boyce/Codd Normal Form 3NF’in içinde bir adım sayılmasına rağmen yukardaki işlemler sonucu henüz model BCNF’e dönüşmüş değildir.3NF içinde aslında tüm geçişli bağımlıklarda kaldırılmasına rağmen , tablo henüz yeterince normalize olmuş değildir.Carlo Zaniolo 3NF’u şu şekilde tanımlar .
R bir tablo olsun.Bu tablo içinde X bir gurup nitelik ve A da sadece tek bir niteliği temsil etsin.Eğer A’nın X’e fonksiyonel bağımlılığı var ise (X => A) , R tablosu 3NF’a uymak için aşağıdaki şartlardan en az birine uymalıdır:

• X kümesi A’yı kapsamalıdır
• X kümesi R’nin en az bir aday anahtarını içermelidir
• A tablonun bir aday anahtarı tarafından kapsanmalıdır

     BCNF ile 3NF’in farkı BCNF’in üçüncü maddeye izin vermemesidir.
Başka bir deyişle birden fazla bileşik aday anahtar içeren tablolarda , eğer aday anahtarların içerdiği ortak bir nitelik var ise , bu iki aday anahtarın niteliklerinden herhangi biri diğer aday anahtarlardan birine fonksiyonel olarak bağımlı olamaz.


Şekilde A + B bileşik aday anahtar ve B + C bileşik aday anahtar göstermekte A => C bağımlılığı bulunmaktadır.Bu durum 3NF ‘e uygun olabileceği halde BCNF’e uygun değildir.
Bunu bir örnekle gösterelim.

KOMİTE
Komite Adı
Element
Atom No
Yıllık Toplantı
Ticaret
Altın
79
6
Madencilik
Bakır
29
2
Enerji
Uranyum
92
4
Finans
Altın
79
5

Tablonun aday anahtarları şu şekilde olsun :


Tablo bu haliyle 3NF’a uygundur.Tablo üzerindeki bağımlılıkları şu şekilde listeleyebiliriz:

Element + Komite adı => Yıllık Toplantı

Atom No + Komite adı => Yıllık Toplantı

Element <= => Atom No

           Burada BCNF’e uymayan son bağımlılıktır.Ve tablo yeterince normalize edilmemiştir.Bunun zararlarına şu şekilde örnek gösterebiliriz:

            Eğer 79 ‘nolu elementin adı değişirse bütün tablo aranacak ve pek çok kayıt okunduktan sonra adı değişecektir.Ya da eğer madencilik komitesini silerseniz 29 nolu elementi de kaybedersiniz.
           Çözüm için bağımlılığın olduğu kayıtların başka bir tabloya çıkarılması yeterlidir.Bu durumda aşağıdaki şekilde iki tablo oluşacaktır.

KOMİTE
Komite Adı
Atom No
Yıllık Toplantı
Ticaret
79
6
Madencilik
29
2
Enerji
92
4
Finans
79
5

ELEMENT
Atom No
Element
79
Altın
29
Bakır
92
Uranyum
79
Altın

      BCNF’den sonra aslında pek çok durum için normalizasyon tamamlanmış sayılır.Aşağıdaki durumlarda normalizasyon tamamlanmıştır

• Eğer tablo 3 ya da daha az kolona sahipse
• Eğer tabloda hiç bileşik aday anahtar kalmamışsa
• Eğer tabloda en az bir aday anahtar bileşik değilse otomatikman 4NF tamamlanmıştır.Direk 5NF işlemlerine başlanabilir

           Genellikle yapay anahtar kullanımı 3NF’dan sonra 4NF’u da geçmenizi sağlar.Çünkü yapay anahtarlar bileşik değildirler.Özellikle şu tablolar 4NF ve 5NF’a ihtiyaç duyarlar:

• Ana anahtarın bütün niteliklerin birleşmesiye oluşturulduğu tablolar
• Ortak çalışılan tablolar.Çoğul : çoğul ve karmaşık ilişkilerin çözümünde yaratıldığı gibi.
• Çoğul nitelikler için yaratılan ek tablolar

4NF ‘de tablo üzerindeki çoğuldeğerli bağımlılıklar (multivalued dependencies) çözülür.Çok değerli bağımlılıklar direk bir fonksiyonel bağımlılık olmamasına rağmen bir fonksiyonel bağımlılık yaratırlar.Örneğin aşağıdaki müşteri dağılım tablosuna bakalım.
Bölge
Satış Temsilcisi
Müşteri
Ege
Ahmet
Selçuk Gıda Market
Ege
Ahmet
Özkan Otel
Ege
Ahmet
Gerçek Tur. İşletme
Ege
Cem
Selçuk Gıda Market
Ege
Özhan
Kocaman Market
Marmara
Cem
Güleli Market
Marmara
Cem
Moralı Tic.
Marmara
Selim
Çınar Market
Marmara
Selim
Moralı Tic.

        Tabloda bir bölgede bulunan müşterilere hizmet veren satış temsilcileri gösterilmiştir.Aynı zamanda bir satış temsilcisi birden fazla bölgede de görev yapabilmektedir.
        Yukarıdaki tabloda hiçbir fonksiyonel bağımlılık olmaması rağmen aynı zamanda hatırı sayılı bir gereksizlik de vardır.Örneğin yeni bir müşteri tanımı için iki satır gerekebileceği gibi , satış temsilcisinin ismini değiştirmek için üçden fazla satır üzerinde değişiklik gerekebilir.
Yukarıdaki tabloda bir çift kolonun ve bir veri kümesi arasında bağımlılık vardır.Örneğin Ege bölgesi ve Ahmet isimli satış temsilcisi bir müşteri kümesini gösterirken Marmara bölgesi ve Moralı Tic bir gurup satış temsilcini göstermektedir.

          Eğer her A ve B nitelik çifti için bir C niteliği kümesinden bahsediliyorsa ve aynı zamanda aşağıdaki şartlarda varsa A ile C arasında çoğul bağımlılık vardır :

• A ve B nitelik çifti aynı olduğunda , her zaman aynı C kümesi alınabiliyorsa
• C’nin değeri A’nın değerine bağımlıysa
• C’nin değeri B’nin değerine bağımlı değilse

Çoğuldeğerli bağımlılık çift okla gösterilir.

Bölge =>> Müşteri

Çoğuldeğerli bağımlılığın doğası gereği eğer
     A =>> C şeklide bir bağımlılık varsa , aynı zamanda A =>> B şeklinde de bir bağımlılık vardır.

Müşteri dağılım tablosu için bu şu şekilde gösterilebilir:

Bölge > Satış Temsilcisi

Bu yüzden genellikle çoğul bağımlılıklar şu şekilde gösterilir:

Bölge =>> Satış Temsilcisi | Müşteri

Tablo 4NF için bölünerek iki tablo ortaya çıkarılır.Bölünme için şu formül kullanılır:

                                  IF A =>> B | C THEN A => B AND A => C

 
Bölge
Satış Temsilcisi
Ege
Ahmet
Ege
Cem
Ege
Özhan
Marmara
Cem
Marmara
Selim


Bölge
Müşteri
Ege
Özkan Otel
Ege
Gerçek Tur. İşletme
Ege
Selçuk Gıda Market
Ege
Kocaman Market
Marmara
Güleli Market
Marmara
Moralı Tic.
Marmara
Çınar Market

Eğer ortaya çıkan tabloların satır sayıları ve üzerinde yapılacak işlemler denenirse 4NF’un faydaları kolayca ortaya çıkar.


5NF ise birleşmiş bağımlılıkların (join dependency) ortadan kaldırılmasıdır.Şimdiye kadarki çözümlerde genellikle tablo ikiye bölünerek sorun giderildi.Fakat bazı durumlarda tablo ikiye bölündüğünde mevcut ilişkileri korunamazken üç ya da daha fazla tabloya ayrılarak ilişkiler korunabilir.
          Bozulmadan üç yada daha fazla tabloya bölünen tablolar birleşmiş bağımlılıklar üretir.Bu da aynı zamanda tablonun üç yada daha fazla nesne ile ilişkisinin olmasını gerektirir.Problem genellikle komplex ilişkilerde karşımıza çıkar.
               Örneğin bir senfoni orkestrası düşünelim.Bu orkestra Beethoven eserlerini seslendirdikleri bir dizi konser veriyor olsunlar.Müzisyenler birden fazla enstruman çalabilsin.Senfonilerin seslendirilebilmesi için birden fazla enstruman gereksin.Müzisyenler konserlerde sadece uzmanı oldukları enstrumanları çalsınlar.Bu durumu şu ER diyagramı ile gösterelim.



Burada problem konserde müzisyenlerin her enstrumanı çalabilecekleri izleniminin yaratılması ve buna izin verilmesidir.Problem 5NF’a göre düzenlenerek problem giderilir.Bunun için tekrar kavramsal modele dönülüp aşağıdaki şekilde bir düzenleme yapılır.





NORMALİZASYONUN AVANTAJLARI
     Normalizasyon adımlarını tanımladıktan sonra , bu sürecin bize genel olarak sağladığı sonuçları listelersek :

• Gereksizliklerin Azaltılması
         Normalizasyon yapılmamış tablolar üzerinde sıkça veri tekrarı görülür.Normalizasyon verinin en az tekrarını ve gereksiz tekrarın ortadan kaldırılmasını garanti eder.
• NULL ihtiyacının en aza indirilmesi
          NULL genellikle numerik verilerin kullanımında sıkça problem yaratır.Örneğin toplam ya da ortalama almak gibi.NULL aynı zamanda henüz belirlenememiş bir supertip’in belirtisidir.
• Çevrilebilirlik
         Normalizasyon da sıkça bir tabloyu bölmek zorunda kalırsınız.Tablolar yeniden düzenlendiğinde orjinal veri kaybolmaz ve sahte veri üretilmez.


DİZAYNIN TAMAMLANMASI

Dizaynın tamamlanması için mantıksal dizaynın hazırlanmasından sonra kalan iki süreç fiziksel dizaynın hazırlanması ve modelin uyarlanmasıdır yani hayata geçirilmesidir. Fiziksel dizayn veri tabanında kullanılacak saklama aygıtlarının tamamlanması , tabloların üzerinde performans için indexlerin yaratılması , tabloların aygıtlara atanması vb. süreçleri içerir.  Modelin uyarlanması ise artık herşeyiyle hazır olan modelden bir veri tabanı yaratılmasıdır diyebiliriz.Bu süreçler seçilen veri tabanı yönetim sistemi ile oldukça ilişkilidir.
               Bu süreçler ele aldığımız konunun dışına taştığı için bu kadar bahsetmek yeterlidir.Bu aşamada en çok söz sahibi olan veri tabanı yöneticileridir.Bu süreçler veri tabanının yaşam döngüsü içersinde en çok dinamiklik gösteren , oldukça değişikliğe ve yeniliğe uğrayan süreçlerdir.

1 yorum:

  1. Hocam çok güzel ve anlaşılır bir anlatım yapmışsınız, paylaşımınız için çok teşekkür ederim.

    YanıtlaSil