Veritabanı tasarımı temel bilgileri
Düzgün tasarlanmış bir veritabanı, güncel ve doğru bilgilere erişiminizi sağlar. Doğru tasarım, veritabanı çalışmalarınıza yönelik hedeflerinizi başarmanız açısından son derece önemli olduğu için düzgün tasarım ilkelerini öğrenmek adına gerekli zaman yatırımını yapmak akıllıca olacaktır. Bunun neticesinde gereksinimlerinizi karşılayan ve değişen koşullara kolaylıkla uyum sağlayan bir veritabanı elde edebilirsiniz.
Bu makalede veritabanı planlaması ile ilgili yönlendirici bilgiler verilmektedir. Hangi bilgilere gereksinim duyduğunuza, bu bilgileri uygun tablo ve sütunlara nasıl böleceğinize ve bu tabloların birbirleri ile nasıl ilişkilendirileceğine karar vermeyi öğreneceksiniz. İlk veritabanınızı oluşturmadan önce bu makaleyi okumanız gerekir.
Bilinmesi gereken bazı veritabanı terimleri
Microsoft Office Access 2007, bilgilerinizi tablolar halinde düzenler: Muhasebeci formunu veya Microsoft Office Excel 2007 çalışma sayfasını hatırlatan satır ve sütun listeleri sunar. Basit bir veritabanı yalnızca tek tablolu olabilir. Veritabanlarının çoğunda daha fazla tabloya gerek duyabilirsiniz. Örneğin, ürün bilgilerinin toplandığı için bir tablonuz, sipariş bilgilerinin toplandığı başka bir tablonuz ve müşteriler hakkında bilgilerin toplandığı daha başka bir tablonuz olabilir.

Her satır kayıt, her sütun alan olarak da adlandırılabilir. Kayıt herhangi bir şey hakkındaki bilgileri birleştirmenin anlamlı ve tutarlı bir yoludur. Alan ise tek bilgi öğesidir (her kayıtta görüntülenen öğe türü). Örneğin, Ürünler tablosunda her satır veya kayıt tek bir ürün hakkında bilgiler içerir. Her sütun veya alan da, bu ürünle ilgili ürün adı veya fiyatı gibi bilgiler içerir.
Düzgün veritabanı tasarımı nedir?
Veritabanı tasarımı işlemine belli ilkeler yön verir. İlk ilkeye göre bilgilerin yinelenmesi (gereksiz veri olarak da bilinir) kötüdür; çünkü bunlar gereksiz alan kaplar, hata ve tutarsızlık olasılığını artırır. İkinci ilkeye göre bilgilerin doğru ve tam olması önemlidir. Veritabanınızda yanlış bilgiler varsa, veritabanından bilgi alan raporlar da yanlış bilgi içerecektir. Sonuç olarak, bu raporlar esasında alacağınız kararlar yanlış bilgilere dayanacaktır.
Bu nedenle düzgün bir veritabanı tasarımı aşağıdakileri gerçekleştirir:
· Gereksiz verileri azaltmak için bilgilerinizi konulara göre oluşturulmuş tablolara böler.
· Gerektikçe tablolardaki bilgileri birleştirmek üzere Access’e ihtiyaç duyduğu bilgileri sunar.
· Bilgilerinizin doğruluğunu ve tutarlılığını sağlar ve destekler.
· Veri işleme ve raporlama gereksinimlerinizi birbirleriyle uyumlu hale getirir.
Tasarım işlemi
Tasarım işlemi aşağıdaki adımlardan oluşur:
· Veritabanınızın amacını belirleme
Geri kalan adımlara hazırlanmanıza yardımcı olur.
· Gerekli bilgileri bulma ve düzenleme
Ürün adı ve sipariş numarası gibi veritabanına kaydetmek isteyebileceğiniz tüm bilgi türlerini toplayın.
· Bilgileri tablolara bölme
Bilgilerinizi, Ürünler veya Siparişler gibi başlıca konulara veya varlıklara göre bölün. Bundan sonra her konu tabloya dönüşür.
· Bilgi öğelerini sütunlara dönüştürme
Her tabloda hangi bilgileri depolamak istediğinize karar verin. Her öğe bir alana dönüşüp tabloda sütun olarak görüntülenir. Örneğin, Çalışanlar tablosunda Soyadı ve İşe Alınma Tarihi gibi alanlar olabilir.
· Birincil anahtarları belirtme
Her tabloya ait birincil anahtarı seçin. Birincil anahtar, her satırı kendine özgü tanımlamak için kullanılan sütundur. Ürün No veya Sipariş No buna örnek olarak verilebilir.
· Tablo ilişkilerini kurma
Her tabloya bakıp, bir tablodaki verilerin başka tablolardaki verilerle nasıl ilişkilendirileceğine karar verin. Gerektiğinde, ilişkileri netleştirmek için tablolara alan ekleyin veya yeri tablolar oluşturun.
· Tasarımınızı ayrıntılandırma
Tasarımınızı hatalar için analiz edin. Tablolar oluşturup örnek verilerden oluşan yeni kayıtlar ekleyin. Tablolardan istediğiniz sonuçları elde edip etmediğinizi kontrol edin. Gerektiğinde tasarımda ayarlar yapın.
· Normalleştirme kurallarını uygulama
Tablolarınızın doğru yapılandırılıp yapılandırılmadığını görmek için normalleştirme kurallarını uygulayın. Gerektiğinde tablolarda ayarlar yapın.
Veritabanınızın amacını saptama
Veritabanı amaçlarını kağıda dökmek akıllıca olacaktır (amacı, nasıl kullanılmasını beklediğiniz ve kimlerin kullanacağı gibi). Ev ofisinde kullanılan küçük bir veritabanı için “Müşteri veritabanı, posta ve rapor hazırlamak amacıyla müşteri bilgileri listesini içerir” gibi basit bir ibare yazabilirsiniz. Genellikle kurumsal ortamlarda olduğu gibi veritabanı daha karmaşıksa veya birden fazla kişi tarafından kullanılıyorsa, veritabanının amacı kolaylıkla bir veya birden fazla paragraf şeklinde açıklanabilir ve burada her kişinin veritabanını nasıl ve ne şekilde kullanacağı belirtilmelidir. Amaç, tüm tasarım süreci boyunca başvurulabilecek, düzgün geliştirilmiş görev deyimlerine sahip olmaktır. Bu tür deyimler sayesinde karar alırken hedeflerinize odaklanabilirsiniz.
Gerekli bilgileri bulma ve düzenleme
Gerekli bilgileri bulmak ve düzenlemek için var olan bilgilerinizle başlayın. Örneğin, sipariş formlarını hesap defterine kaydetmek isteyebilir veya müşteri bilgilerini kağıt formlar halinde dosya dolabında tutmak isteyebilirsiniz. Bu bilgileri toplayıp gösterilen her tür bilgiyi listeleyin (örneğin, formda doldurduğunuz her kutu). Var olan formunuz yoksa, bunun yerine müşteri bilgilerini kaydetmek üzere form tasarlamanız gerektiğini düşünün. Bu forma hangi bilgileri koyardınız? hangi doldurma kutularını oluştururdunuz? Bu öğelerin her birini tanımlayıp listeleyin. Örneğin, müşteri listesini dizin kartlarında tutmakta olduğunuzu düşünelim. Bu kartlar incelendiğinde de her birinde müşteri adı, adresi, şehri, eyaleti, posta kodu ve telefon numarası olduğu görülür. Bu öğelerin her biri tablodaki olası sütunlardır.
Bu listeyi hazırlarken, ilk deneyiminizde mükemmeli yakalama konusunda aceleci olmayın. Bunun yerine, aklınıza geldikçe öğeleri listeleyin. Bu veritabanını başkaları da kullanacaksa onların da fikirlerini alın. Listedeki ince ayarı daha sonra yaparsınız.
Ardından, veritabanından oluşturmak istediğiniz rapor veya posta türlerine karar verin. Örneğin, satışları bölgelere göre gösteren bir satış raporu veya ürün stok düzeylerini gösteren özet stok raporları oluşturmak isteyebilirsiniz. Diğer yandan bir satış olayını veya promosyonları haber veren, müşterilere gönderilecek mektup formları da oluşturabilirsiniz. Raporu kafanızda tasarlayın ve neye benzeyeceğini hayal edin. Bu rapora hangi bilgileri koyardınız? Her öğeyi listeleyin. Aynısını mektup formu ve oluşturmayı düşündüğünüz diğer rapor için de yapın.

Oluşturmak istediğiniz raporları ve postaları önceden düşünmeniz, veritabanınızda ihtiyaç duyacağınız öğeleri belirlemenize yardımcı olabilir. Örneğin, müşterilerin düzeli e-posta güncelleştirmelerini alma (veya almama) konusunda karar verebilmesini sağlayacağınızı ve karar verilenleri de liste halinde yazdırmak istediğinizi düşünelim. Bu bilgileri kaydetmek için müşteri tablosuna “E-posta gönder” sütunu ekleyebilirsiniz. Her müşteri için alanı Evet veya Hayır olarak ayarlayabilirsiniz.
Müşterilere e-posta gönderme gereksinimi başka bir öğenin kaydedilmesini gerektirir. Müşterinin e-posta iletisi almak istediğini öğrendikten sonra bunları göndereceğiniz e-posta adresini de öğrenmeniz gerekir. Bu nedenle, her müşteri için bir e-posta adresi kaydetmeniz gerekir.
Her çıktı listesinin ve raporun örneğini oluşturmak ve rapor hazırlamak için hangi öğelere ihtiyaç duyacağınıza karar vermek akıllıca olacaktır. Örneğin, bir mektup formu incelediğinizde aklınıza birkaç şey gelebilir. Örneğin bir kutlama mektubunu “Sayın Bay” veya “Sayın Bayan” gibi bir selamlamayla başlatmak istiyorsanız bir selamlama öğesi oluşturmanız gerekir. Ayrıca, mektuba “Sayın. Bay Haluk Kocak” yerine “Sayın Bay Kocak” ile başlamak isteyebilirsiniz. Böylece, adı soyadından farklı olarak depolamak istediğiniz anlaşılır.
Unutulmaması gereken en önemli nokta, her bilgi parçasını, kullanılabilir en küçük parçalara bölmeniz gerektiğidir. Ad örneğinde olduğu gibi, soyadını kullanıma hazır tutmak için adı iki bölüme ayırabilirsiniz: Ad ve Soyadı. Örneğin raporu soyadına göre sıralamak, müşteri soyadının ayrı depolanmasına yardımcı olur. Genellikle, öğe bilgilerini esas alan bir sıralama, arama, hesaplama veya raporlama yapmak istiyorsanız bu öğeyi kendi alanına koymanız gerekir.
Veritabanının yanıtlamasını istediğiniz soruları düşünün. Örneğin, geçtiğimiz kaç promosyonlu ürününüzün satışını sonlandırdınız? En iyi müşterileriniz nerede oturuyor? En çok satan ürünlerinizin üreticisi kim? Bu soruların yanıtlarının tahmin edilmesi, kaydedilecek diğer öğeler için doğru bir başlangıç noktası sunar.
Bu bilgileri topladıktan sonra , artık bir sonraki adıma hazırsınız demektir.
Bilgileri tablolara bölme
Bilgileri tablolara bölmek için başlıca varlıkları veya konuları seçin. Örneğin, ürün satış veritabanı için bilgi bulup düzenlendikten sonra ilk liste aşağıdaki gibi görünebilir:

Burada gösterilen başlıca varlıklar ürün, üretici, müşteri ve sipariştir. Bu nedenle, bu dört tabloyla başlamak akıllıca olabilir: Bunlardan biri ürünlerle, biri üreticilerle, biri müşterilerle, biri siparişlerle ilgili olgular içindir. Bu şekilde liste tamamlanmasa da başlamak için iyi bir noktadır. İşe yarayan bir tasarım elde edene kadar bu listeyi ayrıntılandırmaya devam edebilirsiniz.
İlk öğe listenizi gözden geçirdiğinizde, önceki örnekte gösterildiği gibi dört tablo yerine bunların tümünü tek tabloya koymak isteyebilirsiniz. Burada neden bunun kötü bir fikir olduğunu öğreneceksiniz. Bir an düşünün, burada gösterilen tablo:

Bu durumda, her satırda hem ürün, hem de üretici hakkında bilgiler vardır. Aynı üreticiden gelen birçok ürününüz olabileceğinden, üretici ad ve adres bilgilerinin birçok kez yinelenmesi gerekir. Bu da disk alanınızı gereksiz yere doldurur. Ayrı bir Üreticiler tablosuna üretici bilgilerinin bir kez kaydedilip bu tablonun Ürünler tablosuyla bağlantılandırılması çok daha iyi sonuç verir.
Bu tasarımla ilgili ikinci bir sorunsa üretici hakkındaki bilgileri değiştirmeniz gerektiğinde ortaya çıkar. Birçok yerde görüntülendiğinden dolayı adresi bir yerde yanlışlıkla değiştirip, diğer yerlerde değiştirmeyi unutabilirsiniz. Üretici adresinin tek yere kaydedilmesi bu sorunu çözer.
Veritabanınızı tasarlarken, her olguyu yalnızca bir kez kaydetmeye çalışın. Belli bir üreticinin adresi gibi aynı bilgiyi birden fazla yerde yinelediğinizi fark ederseniz bilgiyi farklı bir tabloya koyun.
Son olarak, Asma Şarapçılık’ın sağladığı tek bir ürün olduğunu varsayalım; bu ürünü silmek, ancak üretici ad ve adres bilgilerini tutmak istiyorsunuz. Üretici bilgilerini kaybetmeden ürün kaydını nasıl silerdiniz? Bunu yapamazsınız. Her kayıtta üreticiyle ilgili olguların yanı sıra ürünle ilgili olgular da bulunduğundan, birini silmeden diğerini silemezsiniz. Bu olguları ayrı tutmak için bir tabloyu ikiye bölmeniz gerekir: Bir tablo ürün bilgileri, diğer tablo da üretici bilgileri içindir. Bir ürün kaydının silinmesi yalnızca ürünle ilgili olguları silerken üreticiyle ilgili olguları silmez.
Tablonun temsil ettiği konuyu seçtikten sonra bu tablodaki sütunların yalnızca konu hakkındaki olguları depolaması gerekir. Örneğin, ürün tablosunda yalnızca ürünlerle ilgili olguların depolanması gerekir. Üretici adresi üreticiyle ilgili bir olgu olup, ürünle ilgili bir olgu olmadığından üretici tablosuna aittir.
Bilgi öğelerini sütunlara dönüştürme
Tabloda sütunları saptamak için, tabloda kayıtlı konuyu izlemek üzere hangi bilgiye gerek duyduğunuza karar verin. Örneğin, Müşteriler tablosu için Ad, Adres, Şehir-Eyalet-Posta kodu, E-posta gönder, Selamlama ve E-posta adresi başlangıç olarak iyi bir sütun listesi oluşturur. Tablodaki kayıtlarda aynı sütun kümesi vardır; böylece her kayıt için Ad, Adres, Şehir-Eyalet-Posta kodu, E-posta gönder, Selamlama ve E-posta adresi bilgileri depolanabilir. Örneğin, adres sütununda müşteri adresleri vardır. Her kayıtta tek müşteri hakkında veri bulunur, adres alanında ise bu müşteriye ait adres vardır.
Her tablo için başlangıç sütun kümesini saptadıktan sonra sütunları daha fazla ayrıntılandırabilirsiniz. Örneğin, müşteri adını iki ayrı sütunda depolamak anlamlı olabilir: Ad ve soyadı; böylece bu sütunlara göre sıralayabilir, arayabilir ve dizin oluşturabilirsiniz. Benzer olarak, adres de adres, şehir, eyalet, posta kodu ve ülke/bölge öğelerini içeren beş ayrı bileşenden oluşur; bunları da ayrı sütunlarda depolamak akıllıca olabilir. Bir arama gerçekleştirmek istiyorsanız, örneğin eyalet bilgilerinin ayrı bir sütunda depolanmasına gerek duyduğunuzda işleme eyalete göre filtre ve sıralama uygulayın.
Veritabanınızın yalnızca yerel kaynaklı mı, yoksa uluslararası kaynakları da içerir biçimde mi olacağına karar vermeniz gerekebilir. Örneğin, uluslararası adresler depolamayı planlıyorsanız Eyalet yerine Bölge sütunu oluşturmanız daha akla yakındır; böylece hem yerel eyaletleri, hem de başka ülke/bölgelerdeki yerleri bu sütuna koyabilirsiniz. Benzer olarak, uluslararası adresleri depolayacaksanız Alan Kodu yerine Posta Kodu kullanmak daha iyi olur.
Aşağıdaki listede sütunları saptama için ipuçları veriliyor.
· Hesaplanan verileri dahil etmeyin
Çoğu durumda, tablolarda hesaplama sonucunu depolamanız gerekmez. Bunun yerine, bu sonucu görmek istediğinizde Access’in hesapları gerçekleştirmesini sağlayabilirsiniz. Örneğin, bu veritabanında her ürün kategorisi için siparişteki birimlerin bir alt toplamını görüntüleyen Siparişteki Ürünler raporu olduğunu düşünelim. Ancak, tablolarda Siparişteki Birimler alt toplamı sütunu olmasın. Bunun yerine, Ürünler tablosunda her ürün için siparişteki birimleri depolayan Siparişteki Birimler sütunu olsun. Bu verileri kullanarak, raporu her yazdırışınızda Access alt toplamı hesaplar. Alt toplamın kendisinin tabloda depolanması gerekmez.
· Bilgileri en küçük mantıksal parçalar halinde depolama
Tam ürün adları veya ürün tanımlamaları ile birlikte ürün adları için tek alanınız olmasını isteyebilirsiniz. Birden fazla bilgi türünü tek alanda birleştirirseniz, daha sonra birbirinden bağımsız olguları almanız zor olacaktır. Bilgileri mantıksal parçalara bölmeyi deneyin; örneğin ad ve soyadı için veya ürün adı, kategori ve tanım için ayrı alanlar oluşturun.

Veri sütunlarını her tabloda ayrıntılandırdıktan sonra, artık her tablonun birincil anahtarını seçmeye hazırsınız.
Birincil anahtarları belirtme
Her tabloda, tabloda depolanan her satırı benzersiz bir şekilde tanımlayan bir sütun veya sütun kümesi olması gerekir. Bu çoğunlukla, çalışan no veya seri numarası gibi benzersiz bir kimlik numarasıdır. Veritabanı terminolojisinde bu bilgi tablonun birincil anahtarı olarak adlandırılır. Access birincil anahtar alanlarını birden fazla tablodaki verileri hemen ilişkilendirmek ve verileri sizin adınıza bir araya getirmek için kullanır.
Kataloğunuzdaki her ürünü benzersiz olarak tanımlayan ürün numarası gibi tanımlayıcılar tablonuzda zaten varsa, bu tanımlayıcıyı tablonuzun birincil anahtarı olarak kullanabilirsiniz; ancak bu sütundaki değerlerin her zaman, her kayıt için farklı olması gerekir. Birincil anahtarda, yinelenen değerleriniz olamaz. Örneğin, adlar benzersiz olmadığından kişi adlarını birincil anahtar olarak kullanmayın. Aynı adda iki kişinin tablonuzda yer alma olasılığı çok yüksektir.
Birincil anahtarda her zaman bir değer olması gerekir. Bazı noktalarda sütun değeri atanmamış veya bilinmeyense (eksik değer), birincil anahtarda bileşen olarak kullanılamaz.
Her zaman değeri değişmeyen bir birincil anahtar seçmeniz gerekir. Birden fazla tablonun kullanıldığı veritabanında, bir tablonun birincil anahtarı diğer tablolarda başvuru olarak kullanılabilir. Birincil anahtar değişirse, anahtarın başvuru olarak alındığı her yerde de değişikliğin uygulanması gerekir. Değişmeyecek birincil anahtar kullanılması, birincil anahtarın, kendisine başvuran diğer tablolarla uyumsuzlaşma olasılığını azaltır.
Çoğunlukla, rasgele benzersiz bir sayı birincil anahtar olarak kullanılır. Örneğin, her siparişe benzersiz bir sipariş numarası atayabilirsiniz. Sipariş numarasının tek amacı siparişi tanımlamaktır. Atandıktan sonra, bir daha değişmez.
Aklınızda iyi bir birincil anahtar olacak sütun veya sütun kümesi yoksa Otomatik Sayı veri türüne sahip sütun kullanmayı dikkate alın. Otomatik Sayı veri türünü kullandığınızda Access otomatik olarak size bir değer atar. Böyle bir tanımlayıcının gerçekliği yoktur; kendisini temsil eden satırları açıklayan gerçek bilgileri yoktur. Gerçekliği olmayan tanımlayıcılar değişmeyeceklerinden birincil anahtar olarak kullanılmak için idealdir. Satır hakkında olguların (telefon numarası veya müşteri adı gibi) yer aldığı birincil anahtar, gerçekliği olan bilgilerin kendileri değişebileceğinden değişmeye daha yakındır.

Otomatik Sayı veri türünde sütun kümesi çoğunlukla iyi bir birincil anahtar oluşturur. Aynı numaraya sahip iki ürün olmaz.
Bazı durumlarda, iki veya daha fazla alanın birlikte tablonun birincil anahtarını oluşturmasını isteyebilirsiniz. Örneğin, sipariş için belirtilen öğeler depolayan Sipariş Ayrıntıları tablosunun, birincil anahtarında iki sütun kullanması gerekebilir: Sipariş No ve Ürün No. Birincil anahtar, birden fazla sütun kullandığında, bileşik anahtar olarak da adlandırılır.
Ürün satış veritabanı için, tabloların her birinde birincil anahtar olarak hizmet vermek üzere Otomatik Sayı sütunu oluşturabilirsiniz: Ürünler tablosu için Ürün No, Siparişler tablosu için Sipariş No, Müşteri tablosu için Müşteri No, Üreticiler tablosu için Üretici No.

Tablo ilişkilerini oluşturma
Bilgileri tablolara böldükten sonra sıra bilgileri anlamlı bir şekilde yeniden birleştirmek için gereken yolu bulmaya geldi. Örneğin, aşağıdaki formda farklı tablolardan bilgiler vardır.

Bu formdaki bilgilere kaynaklık edenler: Müşteriler tablosu…
…Çalışanlar tablosu…
…Siparişler tablosu…
…Ürünler tablosu…
…ve Sipariş Ayrıntıları tablosu.
Access, bir ilişkisel veritabanı yönetimi sistemidir. İlişkisel veritabanında bilgileri ayrı, konu tabanlı tablolara bölersiniz. Ardından da tablo ilişkilerini, bilgileri gerektikçe bir araya getirmek için kullanırsınız.
Bir-çok ilişkisi oluşturma
Şu örneği dikkate alalım: Ürün siparişleri veritabanında Üreticiler ve Ürünler tabloları. Üretici çok sayıda ürün sağlayabilir. Bunun sonucu olarak Üreticiler tablosunda temsil edilen üretici, Ürünler tablosunda birçok ürünle temsil edilebilir. Bu nedenle, Üreticiler tablosuyla Ürünler tablosu arasındaki ilişki bir-çok ilişkisidir.

Veritabanı tasarımınızda bir-çok ilişkisi temsil etmek için birincil anahtarı ilişkinin “bir” tarafında tutup, bunu ilişkinin “çok” tarafına ek sütun veya sütunlar olarak ekleyin. Örneğin buradaki durumda, Üreticiler tablosundaki Üretici No sütununu Ürünler tablosuna ekliyorsunuz. Bundan sonra Access, her ürüne ait doğru üreticiyi bulmak için Ürünler tablosunda üretici numarasını kullanacaktır.
Ürünler tablosundaki Üretici No yabancı anahtar olarak adlandırılır. Yabancı anahtar başka bir tablonun birincil anahtarıdır. Ürünler tablosundaki Üretici No sütunu, Üreticiler tablosunda da birincil anahtar olduğundan yabancı anahtardır.

Birincil anahtar ve yabancı anahtar çiftleri oluşturarak birleşen ilgili tablolar için temel sunarsınız. Hangi tabloların ortak sütun paylaşması gerektiğinden emin değilseniz, bir-çok ilişkisini tanımlamanız ilgili iki tablo için aslında paylaşılan bir sütun gerekmesini sağlayacaktır.
Çok-çok ilişkisi oluşturma
Ürünler tablosu ve Siparişler tablosu arasında ilişkiye karar verin.
Tek bir siparişte birden fazla ürün olabilir. Diğer taraftan, tek bir ürün birçok siparişte görülebilir. Bu nedenle, Siparişler tablosundaki her kayıt için Ürünler tablosunda birçok kayıt bulunabilir. Buna benzer biçimde, Ürünler tablosundaki her kayıt için Siparişler tablosunda da birçok kayıt olabilir. Bu tür ilişkilere, ürün için birçok sipariş, sipariş için de birçok ürün olabildiğinden çok-çok ilişki adı verilir. Tablolarınız arasında çok-çok ilişkilerini algılamak için ilişkinin her iki tarafını da dikkate almanın önemli olduğunu unutmayın.
İki tablonun (siparişler ve ürünler) konuları çok-çok ilişkisine sahiptir. Bu da sorun oluşturur. Sorunu anlamak için, Siparişler tablosuna Ürün No ekleyerek iki tablo arasında ilişki kurmanın ne sorun oluşturacağı üzerinde düşünün. Sipariş başına birden fazla ürününüzün olması için Siparişler tablosunda sipariş başına birden çok kaydınızın olması gerekir. Tek siparişle ilişkili her satır için sipariş bilgilerini yinelemeniz gerekebilir; bu da doğru olmayan verilere neden olabilecek etkisiz bir tasarım ortaya çıkarır. Ürünler tablosuna Sipariş No alanı eklediğinizde de aynı sorunla karşılaşırsınız; bu da Ürünler tablosunda her ürün için birden çok kaydınız olmasına neden olur. Bu sorunu nasıl çözebilirsiniz?
Bunun yanıtı çoğunlukla birleşim tablosu adı verilen üçüncü bir tablo oluşturmaktır; bu tabloyla çok-çok ilişkisi iki bir-çok ilişkisine bölünür. Birincil anahtarı bu iki tablonun her birinden üçüncü tabloya ekleyin. Sonuç olarak, üçüncü tablo ilişkinin her oluşumunu veya örneğini kaydeder.

Sipariş Ayrıntıları tablosundaki her kayıt siparişteki bir belirtilen öğeyi gösterir. Sipariş Ayrıntıları tablosunun birincil anahtarı, Siparişler tablosundan ve Ürünler tablosundan alınan yabancı anahtarlarla, iki alandan oluşur. Sipariş No alanının tek başına kullanılması bu tabloda birincil anahtar görevini gerçekleştirmez; bunun nedeni tek siparişin birçok belirtilen öğesi olabilmesidir. Sipariş No, siparişte her belirtilen öğe için yinelenir; bu nedenle alanda benzersiz birimler olmaz. Ürün No alanının yalnız kullanılması da, tek ürün birçok farklı siparişte görünebileceğinden, işe yaramaz. Ancak, bu iki alan birlikte her zaman her kayıt için benzersiz bir değer oluşturur.
Ürün satışı veritabanında Siparişler tablosu ve Ürünler tablosu birbirleriyle doğrudan ilişkili değildir. Bunun yerine dolaylı olarak Sipariş Ayrıntıları tablosuyla ilişkilidir. Siparişler ve ürünler arasındaki çok-çok ilişkisi, iki bir-çok ilişkisi kullanılarak veritabanında temsil edilir:
· Siparişler tablosu ve Sipariş Ayrıntıları tablosunda bir-çok ilişkisi vardır. Her siparişte birden çok belirtilen öğe olabilir; ancak her belirtilen öğe yalnızca bir siparişle bağlantılıdır.
· Ürünler tablosu ve Sipariş Ayrıntıları tablosunda bir-çok ilişki vardır. Her üründe kendisiyle ilişkili birçok belirtilen öğe olabilir; ancak her belirtilen öğe yalnızca bir ürünü temsil eder.
Sipariş Ayrıntıları tablosundan belirli bir siparişteki ürünlerin tümünü saptayabilirsiniz. Belirli bir ürüne yönelik siparişlerin tümünü de saptayabilirsiniz.
Sipariş Ayrıntıları tablosunu birleştirdikten sonra, tablolar ve alanlar listesi buradaki gibi görünebilir:

Bir-bir ilişkisi oluşturma
Diğer bir ilişki türü bir-bir ilişkisidir. Örneğin, size nadiren gereken veya yalnızca az sayıda ürüne uygulanan bazı özel destek ürün bilgilerine gerek duyduğunuzu varsayalım. Bu bilgilere çok sık ihtiyaç duymamanız ve bilgilerin Ürünler tablosunda depolanması ve geçerli olmadığı her ürün için boş alan kaplaması nedeniyle bunu ayrı bir tabloya yerleştirirsiniz. Ürünler tablosunda olduğu gibi, birincil anahtar olarak Ürün No kullanırsınız. Bu destek tablosu ve Ürünler tablosu arasındaki ilişki bir-bir ilişkisidir. Ürünler tablosundaki her kayıt için destek tablosunda tek eşleşen kayıt vardır. Böyle bir ilişkiyi tanımladığınızda her iki tablonun da ortak bir alanı paylaşması gerekir.
Veritabanınızda bir-bir ilişkisine gerek olduğunu tespit ettiğinizde, iki tablodan elde edilecek bilgileri tek tabloda birleştirip birleştiremeyeceğinize karar verin. Belki de çok fazla boş alanla sonuçlanabileceği gibi bazı nedenlerle bunu yapmak istemezseniz, aşağıdaki listede ilişkiyi nasıl göstermeniz gerektiği açıklanmaktadır:
· İki tabloda aynı konu varsa, her iki tablodaki aynı birincil anahtarı kullanarak ilişkiyi kurabilirsiniz.
· İki tabloda farklı birincil anahtarlarla farklı konular varsa tablolardan birini seçip (herhangi birini) birincil anahtarını yabancı anahtar olarak diğer tabloya ekleyin.
Tablolar arasındaki ilişkinin saptanması doğru tablolarınız ve sütunlarınız olmasını sağlamanıza yardımcı olur. Bir-bir veya bir-çok ilişkisi olduğunda, ilgili tablolarda ortak sütun veya sütunların paylaşılması gerekir. Çok-çok ilişkisi olduğunda üçüncü bir tablonun ilişkiyi göstermesi gerekir.
Tasarımı ayrıntılandırma
Gerekli tablolara, alanlara ve ilişkilere sahip olduktan sonra örnek veriler oluşturup tablolarınızı bunlarla doldurmanız ve bilgilerle çalışmayı (sorgu oluşturma, yeni kayıt ekleme, vb.) denemeniz gerekir. Böylece olası sorunlara (tasarım aşamasında eklemeyi unuttuğunuz bir sütunu eklemeniz gerekebilir veya yinelemeyi kaldırmak için iki tabloya bölmeniz gereken bir tablonuz olabilir) dikkat çekilebilir.
İstediğiniz yanıtları almak için veritabanını kullanıp kullanamadığınıza bakın. Formlarınızın ve raporlarınızın kaba taslaklarını oluşturun ve beklediğiniz verileri gösterip göstermediğine bakın. Gereksiz veri yinelemelerini arayın, bunları bulduğunuzda elemek için tasarımınızı değiştirin.
İlk veritabanınızı denerken, geliştirilmesi gereken alanlar olduğunu fark edebilirsiniz. Aşağıda kontrol edilebilecek birkaç nokta gösterilmektedir:
· Sütun mu unuttunuz? Unuttuysanız, bilgiler var olan tablolara mı ait? Farklı bir şeyle ilgili bir bilgiyse, başka bir tablo oluşturmanız gerekebilir. İzlemeniz gereken her bilgi öğesi için bir sütun oluşturun. Bilgi diğer sütunlardan hesaplanamıyorsa, bunun için yeni bir sütun oluşturmanın zamanı gelmiştir.
· Var olan alanlardan hesaplanabildiği için gereksiz olan sütun var mı? bir bilgi öğesi var olan sütunlardan hesaplanabiliyorsa (perakende fiyatından hesaplanan indirimli fiyat gibi) , çoğunlukla bunu yapıp yeni sütun oluşturmaktan kaçınmak daha iyidir.
· Tablolarınızdan birine sürekli aynı bilgiyi mi giriyorsunuz? Durum böyleyse, tabloyu bir-çok ilişkisi olan iki tabloya bölmeniz gerekebilir.
· Çok fazla alanı olan tablolarınız, kısıtlı sayıda kaydınız, bağımsız kayıtlarda çok fazla boş alanınız mı var? Bu durumda tablonuzu daha az alan, daha fazla kayıt kapsayacak biçimde yeniden tasarlamayı düşünün.
· Her bilgi öğesi en küçük kullanışlı parçalarına bölünmüş mü? Bir bilgi öğesini raporlamanız, sıralamanız, aramanız veya hesaplamanız gerekiyorsa bu öğeyi kendi sütununa koyun.
· Her sütunda tablo konusu hakkında olgu var mı? Sütunda tablo konusu hakkında bilgi yoksa bu sütun farklı bir tabloya aittir.
· Tablolar arasındaki tüm ilişkiler ortak alanlarda mı, yoksa üçüncü bir tablo da mı gösterilmiş? Bir-bir ve bir-çok ilişkileri için ortak sütunlar gerekir. Çok-çok ilişkileri için üçüncü tablo gerekir.
Ürünler tablosunu ayrıntılandırma
Ürün satışı veritabanındaki her ürünün içecek, baharat veya deniz mahsulü gibi genel bir kategori altında yer aldığını varsayalım. Ürünler tablosunda her ürünün kategorisini gösteren bir alan olabilir.
Veritabanı tasarımını inceleyip ayrıntılandırdıktan sonra, kategoriyi adı ve açıklaması ile birlikte depolamaya karar verdiğinizi düşünelim. Ürünler tablosuna Kategori Açıklaması alanı eklerseniz bu kategori altında yer alan her ürün için kategori açıklamasını yinelemeniz gerekir; bu pek de iyi bir çözüm sayılmaz.
Kategorileri kendi tablosu ve kendi birincil anahtarıyla veritabanı için izlenecek yeni bir konu haline getirmek daha iyi bir çözümdür. Artık Kategoriler tablosundan birincil anahtarı yabancı anahtar olarak Ürünler tablosuna ekleyebilirsiniz.
Kategoriler ve Ürünler tablolarında bir-çok ilişkisi vardır: Kategoride birden fazla ürün olabilse de, ürün yalnızca bir kategoriye ait olabilir.
Tablo yapılarınızı gözden geçirdiğinizde, yinelenen gruplara dikkat edin. Örneğin, aşağıdaki sütunların bulunduğu bir tablo olduğunu düşünün:
· Ürün No
· Ad
· ÜrünNo1
· Ad1
· ÜrünNo 2
· Ad2
· ÜrünNo3
· Ad3
Burada her ürün, yalnızca sütun adının sonuna eklenen bir sayıyla diğerlerinden farklılaştırılmış, yinelenen sütunlar grubudur. Bu şekilde numaralandırılmış sütunlar gördüğünüzde tasarımınızı yeniden ziyaret etmeniz gerekir.
Böyle bir tasarımda birçok eksiklik vardır. Yeni başlayanlar için, ürün numaralarına bir üst sınır koymanız için sizi zorlar. Bu sınırı aşar aşmaz, tablo yapısına yeni sütun grubu ekleme işlemini gerçekleştirmeniz gerekir, bu ise başlıca yönetici görevidir.
Diğer bir sorun da, en yüksek sayıda üründen daha az ürünü olan bu üreticilerin, ek sütunlar boş kalacağından, bazı alanları boş yere işgal etmesidir. Böyle bir tasarımdaki en ciddi eksiklik, ürün numarası veya ada göre tablo sıralaması veya dizin oluşturma işlemleri gibi birçok görevin gerçekleştirilmesini zorlaştırmasıdır.
Yinelenen grupları her görüşünüzde tasarımı tabloyu ikiye bölmeyi göz önünde bulundurarak bir kez daha yakından gözden geçirin. Yukarıdaki örnekte biri üreticiler, diğeri de ürünler için olmak üzere üretici numarasıyla bağlantılı iki tablo kullanmak daha iyidir.
Normalleştirme kurallarını uygulama
Tasarımınıza bir sonraki adım olarak veri normalleştirme kurallarını (bazen normalleştirme kuralları olarak adlandırılır) uygulayabilirsiniz. Tablolarınızın doğru yapılandırılıp yapılandırılmadığını görmek için bu kuralları kullanırsınız. Veritabanı tasarımınıza kural uygulama işlemine veritabanını normalleştirme veya yalnızca normalleştirme adı verilir.
Tüm bilgi öğelerini gösterdikten ve başlangıç tasarımına ulaştıktan sonra normalleştirme en kullanışlı öğedir. Buradaki yaklaşım, bilgileri uygun tablolara bölmeniz için size yardımcı olmaktır. Ancak normalleştirme, başlangıç için tüm doğru bilgilere sahip olmanızı sağlayamaz.
Kuralları birbiri ardına uygulayın, her adımda tasarımınızın “normal formlar” olarak bilinenlerden birine ulaşmasını sağlayın. İlk normal formadan beşinci normal forma kadar genel kabul gören beş normal form bulunmaktadır . Veritabanı tasarımlarının çoğu için gerekli olan her şeyi sundukları için bu makalede ilk üç formdan söz edilecektir.
İlk normal form
İlk normal form tablodaki her satır ve sütun kesişiminde tek değer olduğunu, hiçbir zaman değerler listesi olmadığını belirtir. Örneğin, birden fazla Fiyat koyabileceğiniz Fiyat adlı bir alanınız olamaz. Her satır ve sütun kesişimini bir hücre gibi düşünürseniz, her hücre ancak tek bir değer taşıyabilir.
İkinci normal form
İkinci normal form için anahtar olmayan her sütunun, birincil anahtarın yalnızca bir parçasına değil tamamına bağımlı olması gerekir. Bu kural, birincil anahtarınız birden çok sütundan oluştuğunda uygulanır. Örneğin, Sipariş No ve Ürün No’nun birincil anahtar olduğu aşağıdaki sütunların yer aldığı bir tablonuz olduğunu varsayalım:
· Sipariş No (birincil anahtar)
· Ürün No (birincil anahtar)
· Ürün Adı
Bu tasarım ikinci normal formu ihlal eder, çünkü Ürün Adı Ürün No’ya bağımlıdır ancak Sipariş No’ya bağımlı değildir, dolayısıyla birincil anahtarın tamamına bağımlı değildir. Ürün Adı’nı tablodan kaldırmanız gerekir. Bu başka bir tabloya (Ürünler) aittir.
Üçüncü normal form
Üçüncü normal form için yalnızca anahtar olmayan her sütunun tüm birincil anahtara bağımlı olması değil, anahtar olmayan bu sütunların birbirlerinden de bağımsız olması gerekir.
Diğer bir deyişle anahtar olmayan her sütunun birincil anahtara bağımlı, birincil anahtar dışında hiçbir şeye de bağımlı olmaması gerekir. Örneğin, aşağıdaki sütunların yer aldığı bir tablonuz olduğunu varsayalım:
· ÜrünNo (birincil anahtar)
· Ad
· ÖPF
· İndirim
İndirim’in önerilen perakende fiyata (ÖPF) bağımlı olduğunu varsayalım. Anahtar olmayan sütunlardan İndirim sütunu, başka bir anahtar olmayan sütuna, ÖPF’ye bağımlı olduğundan, bu tablo üçüncü normal formu ihlal eder. Sütun bağımsızlığı, anahtar olmayan bir sütunu başka bir anahtar olmayan sütunu etkilemeden değiştirebileceğiniz anlamına gelir. ÖPF alanında bir değer değiştirdiğinizde, İndirim de buna bağlı olarak değişir; bu da kuralı ihlal eder. Buradaki durumda İndirim’in, ÖPF’ye anahtar olandan farklı bir tabloya taşınması gerekir.
|