Düzgün tasarlanmış bir veritabanı güncel ve doğru bilgilere erişmenizi sağlar. Veritabanıyla çalışırken hedeflerinize ulaşmanız için doğru tasarım kritik önem taşıdığından, zaman ayırıp iyi bir tasarımın temel ilkelerini öğrenmek anlamlı bir yatırım olacaktır. Sonunda, ihtiyaçlarınıza uygun ve değişikliği kolayca kabul edebilecek bir veritabanı elde etme olasılığınız çok daha yüksektir.
Bu makalede, bir masaüstü veritabanı planlama yönergeleri sağlanır. Hangi bilgilere ihtiyacınız olduğuna, bu bilgileri uygun tablo ve sütunlara nasıl böleceğinize ve bu tabloların birbirleriyle nasıl ilişkili olacağına karar vermeyi öğreneceksiniz. İlk masaüstü veritabanınızı oluşturmadan önce bu makaleyi okumalısınız.
Bu makalede
Bilinmesi gereken bazı veritabanı terimleri
Access bilgilerinizi tablolar halinde düzenler: bir muhasebecinin panelini veya elektronik tabloyu anımsatan satır ve sütun listeleri. Basit bir veritabanında yalnızca bir tablonuz olabilir. Çoğu veritabanı için birden fazla veritabanı gerekir. Örneğin, ürünlerle ilgili bilgileri depolayan bir tablonuz, siparişlerle ilgili bilgileri depolayan başka bir tablonuz ve müşterilerle ilgili bilgileri içeren başka bir tablonuz olabilir.
Doğru adlandırma açısından, her satıra kayıt ve her sütuna alan adı verilir. Kayıt, bir öğe hakkındaki bilgileri bir araya getirmenin anlamlı ve tutarlı bir yoludur. Alan, tek bir bilgi öğesi, her kayıtta gösterilen bir öğe türüdür. Örneğin, Ürünler tablosunda her satır veya kayıt, tek bir ürünle ilgili bilgiyi barındırır. Her sütun veya alan, söz konusu ürünle ilgili ad veya fiyat gibi çeşitli bilgileri barındırır.
İyi veritabanı tasarımı nedir?
Veritabanı tasarım sürecinde yol gösteren bazı ilkeler vardır. Birinci ilke, yinelenen bilgilerin kötü olduğudur çünkü gereksiz veriler olarak da bilinen bu tür bilgiler, alanı boşa harcar, hata ve tutarsızlık olasılığını artırır. İkinci ilke, bilgilerin doğru ve eksiksiz olması önemlidir. Veritabanınızda doğru olmayan bilgiler varsa, veritabanından bilgi getiren tüm raporlar da doğru olmayan bilgiler içerecektir. Sonuç olarak, söz konusu raporlara dayanarak alınan kararlar yanlış yönlendirilmiş kararlar olur.
Dolayısıyla, iyi bir veritabanı tasarımı:
-
Gereksiz verileri azaltmak için, bilgilerinizi konu tabanlı tablolara böler.
-
Tablolardaki bilgileri gerektiği gibi birleştirmek için Access'e gereken bilgileri sağlar.
-
Bilgilerinizin doğruluğunu ve bütünlüğünü desteklemeye ve bundan emin olmaya yardımcı olur.
-
Veri işleme ve raporlama gereksinimlerinize uyum sağlar.
Tasarım süreci
Tasarım süreci aşağıdaki adımlardan oluşur:
-
Veritabanınızın amacını belirleme
Bu işlem diğer adımlara hazırlanmanıza yardımcı olur.
-
Gerekli bilgileri bulma ve düzenleme
Veritabanına kaydetmek isteyebileceğiniz ürün adı ve sipariş numarası gibi tüm bilgi türlerini toplayın.
-
Bilgileri tablolara bölme
Bilgi öğelerinizi Ürünler veya Siparişler gibi ana birimlere veya konulara bölün. Her konu bir tablo olur.
-
Bilgi öğelerini sütunlara dönüştürme
Her tabloda hangi bilgileri depolamak istediğinize karar verin. Her öğe bir alana dönüşür ve tabloda bir sütun olarak görüntülenir. Örneğin, Çalışanlar tablosu Soyadı ve İşe Giriş Tarihi gibi alanlar içerebilir.
-
Birincil anahtarları belirtme
Her tablonun birincil anahtarını seçin. Birincil anahtar, her satırı benzersiz olarak tanımlamak için kullanılan bir sütundur. Buna örnek olarak Ürün Kimliği veya Sipariş No verilebilir.
-
Tablo ilişkilerini ayarlama
Her tabloya bakın ve bir tablodaki verilerin diğer tablolardaki verilerle ilişkisine karar verin. Gerekirse, ilişkileri netleştirmek için tablolara alanlar ekleyin veya yeni tablolar oluşturun.
-
Tasarımınızı iyileştirme
Tasarımınızı hatalar açısından çözümleyin. Tabloları oluşturun ve örnek veriler için birkaç kayıt ekleyin. Tablolardan istediğiniz sonuçları alıp alamadığınıza bakın. Tasarımda gereken ayarlamaları 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 veri normalleştirme kuralları uygulayın. Tablolarda gereken ayarlamaları yapın.
Veritabanınızın amacını belirleme
Veritabanının amacını, nasıl kullanmayı planladığınızı ve kimlerin kullanacağını bir kağıda yazmak iyi bir yöntemdir. Örneğin ev ofis biçimindeki işletmeniz için küçük bir veritabanı söz konusuysa, şöyle bir şey yazabilirsiniz: "Müşteri veritabanında posta ve rapor oluşturma amaçlı müşteri bilgileri listesi vardır." Kurumsal ortamlarda genellikle olduğu gibi, veritabanı daha karmaşıksa veya birçok kişi tarafından kullanılıyorsa, amacını açıklayan metin bir paragraf veya daha uzun olabilir ve herkesin veritabanını ne zaman ve nasıl kullanacağını içermelidir. Bunun ardındaki fikir, tasarım süreci boyunca başvurulabilecek, iyi hazırlanmış bir görev bildirimine sahip olmaktır. Böyle bir bildirimin olması, karar alırken hedeflere odaklanmanıza yardımcı olur.
Gerekli bilgileri bulma ve düzenleme
Gerekli bilgileri bulmak ve düzenlemek için, var olan bilgilerden yola çıkın. Örneğin, satın alma siparişlerini bir deftere kaydediyor veya müşteri bilgilerini dosya dolabında saklanan kağıt formlarda tutuyor olabilirsiniz. Bu belgeleri bir araya getirin ve gösterilen her bilgi türünü (örneğin, bir formda işaretlediğiniz her kutuyu) listeleyin. Mevcut formlarınız yoksa, bunun yerine müşteri bilgilerini kaydetmek için bir form tasarlamanız gerektiğini hayal edin. Forma hangi bilgileri koyarsınız? İşaretlenmesi için hangi kutuları oluşturursunuz? Bu öğelerden her birini tanımlayın ve listeleyin. Örneğin, şu anda müşteri listesini kartoteks kartlarında tuttuğunuzu varsayalım. Bu kartların incelenmesi, her kartta müşteri adı, adres, şehir, bölge, posta kodu ve telefon numarası bulunduğunu gösterebilir. Bu öğelerden her biri tabloda potansiyel bir sütunu temsil eder.
Bu listeyi hazırlarken, ilk seferde mükemmel yapmak için uğraşmayın. Onun yerine, aklınıza gelen her öğeyi listeleyin. Veritabanını başka biri kullanacaksa, onların da fikirlerini alın. Listede daha sonra ince ayarlamalar yapabilirsiniz.
Ardından, veritabanını kullanarak oluşturmak istediğiniz rapor veya posta gönderisi türlerini düşünün. Örneğin, bölgelere göre satışları gösteren bir ürün satış raporu veya ürün envanter düzeylerini gösteren bir envanter özeti raporu oluşturmak isteyebilirsiniz. Ayrıca, bir satış etkinliğini duyurmak veya indirim önermek için müşterilere gönderilecek mektup formları oluşturmak da isteyebilirsiniz. Raporu kafanızda tasarlayın ve neye benzeyeceğini düşünün. Rapora hangi bilgileri alabilirsiniz? Bu bilgileri listeleyin. Oluşturmayı düşündüğünüz mektup formu ve diğer tüm raporlar için aynı şeyi yapın.
Oluşturmak isteyebileceğiniz raporlar ve posta gönderileri üzerinde düşünmek, veritabanınızda bulunmasına gerek duyacağınız öğeleri belirlemenize yardımcı olur. Örneğin, müşterilere düzenli e-posta güncelleştirmelerini kabul etme (veya geri çevirme) izni verdiğinizi ve kabul eden kişilerin listesini yazdırmak istediğinizi varsayalım. Bilgilerin kaydını oluşturmak için, müşteri tablosuna “E-posta gönder” sütunu eklersiniz. Her müşteri için, alanı Evet veya Hayır değerine ayarlayabilirsiniz.
Müşterilere e-posta iletileri gönderme gereksinimine bağlı olarak, kayda bir öğe daha eklemek gerekir. Müşterinin e-posta iletileri almak istediğini öğrendikten sonra, bu iletilerin gönderileceği e-posta adresini de öğrenmelisiniz. Dolayısıyla her müşteri için bir e-posta adresi kaydınız da olmalıdır.
Her raporun veya çıktı listesinin bir prototipini oluşturmak ve raporu oluşturmak için hangi öğelerin gerekeceğini göz önünde bulundurmak mantıklıdır. Örneğin, bir form mektubunu incelediğinizde birkaç şey aklınıza gelebilir. Selamlama başlatan "Bay", "Bayan" veya "Ms." dizesi gibi düzgün bir selamlama eklemek istiyorsanız, bir selamlama öğesi oluşturmanız gerekir. Ayrıca, genellikle "Sayın Bay Smith" ile bir mektup başlatabilirsiniz, "Sayın. Bay Sylvester Smith". Bu, genellikle soyadını addan ayrı depolamak istediğinizi gösterir.
Anımsamanız gereken önemli bir nokta, her bilgi öğesini kullanılabilir en küçük parçalarına ayırmanız gerektiğidir. Ad söz konusu olduğunda, soyadını kullanıma hazır hale getirmek için ad bilgisini iki parçaya ayırırsınız: Ad ve Soyadı. Örneğin, müşterinin soyadını ayrı depolamanız raporu soyadına göre sıralamanıza yardımcı olur. Genel olarak, bir bilgi öğesine göre sıralamak, aramak, hesaplamak veya raporlamak isterseniz bu öğeyi kendi alanına koymalısınız.
Veritabanının yanıtlamasını istediğiniz soruları düşünün. Örneğin, tanıtılan ürününüzden geçen ay kaç adet satış yaptınız? En iyi müşterileriniz nerede yaşıyor? En çok satan ürününüzün sağlayıcı kim? Bu soruları önceden düşünmek, kayda alınacak ek öğeleri belirlemenize yardımcı olur.
Bu bilgileri topladıktan sonra, sonraki adıma geçmeye hazır olursunuz.
Bilgileri tablolara bölme
Bilgileri tablolara bölmek için, ana birimleri veya konuları seçin. Örneğin, bir ürün satış veritabanına alınacak bilgileri bulduktan ve düzenledikten sonra, ilk liste şöyle görünebilir:
Burada gösterilen önemli birimler ürünler, sağlayıcılar, müşteriler ve siparişlerdir. Dolayısıyla, şu dört tabloyla başlamak anlamlı olur: ürünler hakkındaki bilgileri içeren tablo, sağlayıcılar hakkındaki bilgileri içeren tablo, müşteriler hakkındaki bilgileri içeren tablo ve siparişler hakkındaki bilgileri içeren tablo. Bunlar listenin tamamını oluşturmasa da, iyi bir başlangıç noktasıdır. İyi çalışan bir tasarım elde edene kadar bu listeyi geliştirmeye devam edebilirsiniz.
İlk öğe listesini ilk kez gözden geçirdiğinizde, önceki çizimde gösterilen dört tablo yerine bunların tümünü tek tabloya yerleştirmek cazip gelebilir. Burada, bunun neden iyi bir fikir olmadığını öğreneceksiniz. Aşağıda gösterilen tablo üzerinde biraz düşünün:
Buradaki durumda, her satırda hem ürün hem de sağlayıcısı hakkında bilgi bulunmaktadır. Aynı sağlayıcının birçok ürünü olabileceğinden, sağlayıcı ad ve adres bilgilerinin birkaç kez tekrarlanması gerekir. Bu işlem gereksiz yer kullanır. Sağlayıcı bilgilerini ayrı bir Sağlayıcılar tablosuna yalnızca bir kez kaydetmek ve bu tabloyla Ürünler tablosu arasında bağlantı oluşturmak çok daha iyi bir çözümdür.
Bu tasarımla ilgili diğer bir sorun ise sağlayıcıyla ilgili bilgileri değiştirmeniz gerektiğinde ortaya çıkar. Örneğin, sağlayıcının adresini değiştirmeniz gerektiğini varsayalım. Bu bilgi birçok yerde bulunduğundan, adresi bir yerde değiştirip diğer yerlerde değiştirmeyi unutabilirsiniz. Sağlayıcının adres bilgisini tek bir yere kaydetmek bu sorunu çözer.
Veritabanınızı tasarlarken, her zaman her olguyu tek bir kez kaydetmeye çalışın. Aynı bilgileri, örneğin belirli bir sağlayıcının adresini birden çok yerde tekrarladığınızı fark ederseniz, bu bilgileri ayrı tabloya yerleştirin.
Son olarak, Coho Winery tarafından sağlanan tek bir ürün olduğunu ve ürünü silmek, ancak sağlayıcının ad ve adres bilgilerini saklamak istediğinizi varsayalım. Sağlayıcının bilgilerini kaybetmeden ürün kaydını nasıl silersiniz? Silemezsiniz. Çünkü her kayıtta hem ürünle hem de sağlayıcıyla ilgili birçok bilgi bulunduğundan, diğerlerine dokunmadan sadece birini silemezsiniz. Bu bilgileri ayrı tutmak için, bir tabloyu iki tabloya bölmeniz gerekir: bir tablo ürün bilgileri için ve bir tablo da sağlayıcı bilgileri için. Bir ürün kaydı silindiğinde, yalnızca ürünle ilgili bilgiler silinmeli, sağlayıcıyla ilgili olanlar ise silinmemelidir.
Tabloda temsil edilen konuyu seçtiğinizde, artık bu tablodaki sütunlarda yalnızca bu konuyla ilgili bilgiler depolanmalıdır. Örneğin, ürün tablosunda yalnızca ürün bilgileri bulunmalıdır. Sağlayıcı adresi ürünle değil sağlayıcıyla ilgili bir bilgi olduğundan, bu sağlayıcı tablosuna ait bir bilgidir.
Bilgi öğelerini sütunlara dönüştürme
Tablodaki sütunları belirlemek için, tabloda kaydedilen konu hakkında hangi bilgileri izlemeniz gerektiğine karar verin. Örneğin, Müşteriler tablosu için başlangıç olarak Ad, Adres, Şehir-Bölge-Posta Kodu, E-posta gönder, Hitap ve E-posta adresi iyi bir sütun listesi olacaktır. Tablodaki her kayıt aynı sütun kümesini içerir; dolayısıyla her kayıt için Ad, Adres, Şehir-Bölge-Posta Kodu, E-posta gönder, Hitap ve E-posta adresi bilgilerini depolayabilirsiniz. Örneğin, adres sütununda müşterilerin adresleri yer alır. Her kayıtta bir müşteriyle ilgili veriler ve adres alanında da bu müşterinin adresi bulunur.
Her tablo için ilk sütun kümesini belirledikten sonra sütunları daha da daraltabilirsiniz. Örneğin, müşteri adını iki ayrı sütun olarak depolamak mantıklıdır: ad ve soyadı; böylece yalnızca bu sütunlarda sıralama, arama ve dizin oluşturma yapabilirsiniz. Benzer şekilde, adres aslında beş ayrı bileşenden oluşur: adres, şehir, eyalet, posta kodu ve ülke/bölge ve bunları ayrı sütunlarda depolamak da mantıklıdır. Örneğin, duruma göre bir arama, filtreleme veya sıralama işlemi gerçekleştirmek istiyorsanız, durum bilgilerinin ayrı bir sütunda depolanması gerekir.
Ayrıca, veritabanının yalnızca yurt içi bilgilerini mi içereceğine yoksa hem yurt içi hem de uluslararası bilgilerin mi bulunacağına karar vermelisiniz. Örneğin, uluslararası adresleri depolamayı planlıyorsanız, İl sütunu yerine Bölge sütununu kullanmanız daha iyi olur çünkü böyle bir sütun hem illeri hem de başka ülkelerin bölgelerini barındırabilir. Benzer şekilde, uluslararası adresleri depolayacaksanız Zip Kodu yerine Posta Kodu kullanmak daha mantıklı olacaktır.
Aşağıdaki listede, sütunlarınızı belirlerken yararlanabileceğiniz birkaç ipucu gösterilir.
-
Hesaplanan verileri eklemeyin
Çoğu durumda, hesaplama sonuçlarını tablolarda depolamamanız gerekir. Bunun yerine, sonucu görmek istediğinizde Access'in hesaplamaları yapmasını sağlayabilirsiniz. Örneğin, veritabanındaki her ürün kategorisi için sipariş edilen birimlerin alt toplamını gösteren bir Sipariş Edilen Ürünler raporu olduğunu varsayalım. Öte yandan, hiçbir tabloda Sipariş Edilen Birimler alt toplam sütunu olmasın. Bunun yerine, Ürünler tablosunda her ürünün sipariş edilen birimlerinin depolandığı bir Sipariş Edilen Birimler sütunu bulunsun. Siz raporu her yazdırdığınızda, Access bu verileri kullanarak alt toplamı hesaplar. Alt toplamın kendisi tabloda depolanmamalıdır.
-
Bilgileri en küçük mantıksal parçalar halinde depolayın
Tam adları içeren veya ürün adlarıyla birlikte ürün açıklamalarını da içeren tek bir alan kullanmak cazip gelebilir. Bir alanda birden çok türde bilgiyi bir araya getirirseniz, daha sonra tek tek olguları almak zor olacaktır. Bilgileri mantıksal parçalara ayırmaya çalışın; örneğin, ad ve soyadı için veya ürün adı, kategorisi ve açıklaması için ayrı alanlar oluşturun.
Her tabloda sütunları iyileştirdikten sonra, tabloların birincil anahtarlarını seçebilirsiniz.
Birincil anahtarları belirtme
Her tablo, bu tabloda depolanan her satırı benzersiz olarak tanımlayan sütun (veya sütunlar kümesi) içermelidir. Bu genellikle çalışan kimlik numarası veya seri numarası gibi benzersiz bir kimlik numarasıdır. Veritabanı terminolojisinde, bu bilgiler tablonun birincil anahtarı olarak adlandırılır. Access, birincil anahtar alanlarını, birden çok tablodan aldığı verileri hızla ilişkilendirmek ve verileri sizin için bir araya getirmek için kullanır.
Bir tablo için zaten kataloğunuzdaki her ürünü benzersiz olarak tanımlayan bir ürün numarası gibi benzersiz bir tanımlayıcınız varsa, bu tanımlayıcıyı tablonun birincil anahtarı olarak kullanabilirsiniz; ancak yalnızca bu sütundaki değerler her kayıt için her zaman farklı olacaktır. Birincil anahtarda yinelenen değerler olamaz. Örneğin, adlar benzersiz olmadığından kişilerin adlarını birincil anahtar olarak kullanmayın. Aynı tabloda aynı ada sahip iki kişi kolayca olabilir.
Birincil anahtarın her zaman bir değeri olmalıdır. Bir sütunun değeri herhangi bir noktada atanmamış veya bilinmiyor (değer eksik) durumuna gelebiliyorsa, bu sütun birincil anahtar bileşeni olarak kullanılamaz.
Her zaman, değeri değişmeyecek bir birincil anahtar seçmelisiniz. Birden çok tablo kullanan bir veritabanında, bir tablonun birincil anahtarı diğer tablolarda başvuru olarak kullanılabilir. Birincil anahtar değişirse, bu değişiklik anahtara başvurulan her yere uygulanmalıdır. Değişmeyecek bir birincil anahtar kullanmak, birincil anahtarın ona başvuran diğer tablolarla eşitliğinin bozulma olasılığını azaltır.
Çoğunlukla, birincil anahtar olarak rastgele oluşturulan benzersiz bir numara kullanılır. Örneğin, her siparişe benzersiz bir sipariş numarası atayabilirsiniz. Sıra numarasının tek amacı siparişi tanımlamaktır. Bir kez atandıktan sonra hiçbir zaman değiştirilmez.
Aklınıza iyi bir birincil anahtar oluşturacak bir veya birden çok sütun gelmiyorsa, veri türü Otomatik Sayı olan bir sütunu kullanmayı düşünebilirsiniz. Otomatik Sayı veri türünü kullandığınızda, Access sizin için otomatik olarak bir değer atar. Bu tür bir tanıtıcı bilgi vermez; temsil ettiği satırı açıklayıcı türde hiçbir bilgi içermez. Bilgi içermeyen tanıtıcılar birincil anahtar olarak kullanmak için idealdir çünkü bunlar değişmez. Bir satır hakkında bilgi içeren birincil anahtarın (telefon numarası veya müşteri adı gibi) değişme olasılığı daha yüksektir, çünkü bir olguya işaret eden bilgilerin kendisi değişebilir.
1. Otomatik Sayı veri türüne ayarlanmış bir sütun çoğunlukla iyi bir birincil anahtar oluşturur. İki ürün kimliği aynı olamaz.
Bazı durumlarda, birlikte tablonun birincil anahtarını oluşturması için iki veya daha çok alan kullanabilirsiniz. Örneğin, siparişlerin satır öğelerini depolayan Sipariş Ayrıntıları tablosu birincil anahtarında şu iki sütunu kullanıyor olabilir: Sipariş No ve Ürün Kimliği. Birincil anahtar birden çok sütun kullanıyorsa, buna bileşik anahtar da denir.
Ürün satış veritabanı için, tabloların her birinde birincil anahtar işlevi görecek bir Otomatik Sayı sütunu oluşturabilirsiniz: Ürünler tablosu için ÜrünKimliği, Siparişler tablosu için SiparişNo, Müşteriler tablosu için MüşteriKimliği ve Sağlayıcılar tablosu için SağlayıcıKimliği.
Tablo ilişkilerini oluşturma
Artık bilgilerinizi tablolara böldüğünüze göre, bilgileri yeniden anlamlı yöntemlerle bir araya getirmenin bir yolunu bulmanız gerekir. Örneğin aşağıdaki form çeşitli tablolardan bilgiler içerir.
1. Bu formdaki bilgilere kaynaklık edenler: Müşteriler tablosu...
2. ...Çalışanlar tablosu...
3. ...Siparişler tablosu...
4. ...Ürünler tablosu...
5. ...ve Sipariş Ayrıntıları tablosu.
Access, bir ilişkisel veritabanı yönetim sistemidir. İlişkisel veritabanında, bilgilerinizi birbirinden ayrı, konu tabanlı tablolara bölersiniz. Ardından, bilgileri gerektiği gibi bir araya getirmek için tablo ilişkilerini kullanırsınız.
Bire çok ilişkisi oluşturma
Şu örneği düşünün: Ürün siparişleri veritabanında Sağlayıcılar ve Ürünler tabloları var. Bir sağlayıcı herhangi bir sayıda ürün sağlıyor olabilir. Yani Sağlayıcılar tablosunda gösterilen her sağlayıcı için, Ürünler tablosunda gösterilen birçok ürün bulunabilir. Dolayısıyla, Sağlayıcılar tablosuyla Ürünler tablosu arasında bire çok ilişki vardır.
Veritabanı tasarımınızda bir-çok ilişkisini temsil etmek için birincil anahtarı ilişkinin "bir" tarafında tutup, bunu ilişkinin "çok" tarafında ek sütun veya sütunlar olarak tabloya ekleyin. Örneğin buradaki durumda, Sağlayıcılar tablosundan Sağlayıcı Kimliği sütununu Ürünler tablosuna eklersiniz. Access böylece, her ürünün doğru sağlayıcısını belirlemek için Ürünler tablosundaki sağlayıcı kimliği numarasını kullanabilir.
Ürünler tablosundaki Sağlayıcı Kimliği sütunu yabancı anahtar olarak adlandırılır. Yabancı anahtar, başka bir tablonun birincil anahtarıdır. Ürünle tablosunda Sağlayıcı Kimliği sütununun yabancı anahtar olmasının nedeni, bu sütunun aynı zamanda Sağlayıcılar tablosunun birincil anahtarı olmasıdır.
Birincil anahtar/yabancı anahtar çiftleri oluşturarak birbiriyle ilgili tabloları birleştirme işlemine temel sağlamış olursunuz. Hangi tabloların ortak bir sütunu paylaşması gerektiğinden emin değilseniz, bire çok ilişkiyi belirlemek bu ilişkiye katılan iki tablonun gerçekten de paylaşılan bir sütuna ihtiyacı olduğundan emin olmanızı sağlar.
Çoka çok ilişki oluşturma
Ürünler tablosuyla Siparişler tablosu arasındaki ilişkiyi düşünün.
Tek bir siparişte birden fazla ürün olabilir. Diğer yandan, 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. Ayrıca, Ürünler tablosundaki her kayıt için Siparişler tablosunda da birçok kayıt olabilir. Bu tür ilişkilere, "çoka çok" ilişki adı verilir çünkü her ürün için birden çok sipariş olabileceği gibi, her sipariş için de birden çok ürün olabilir. Tablolarınız arasındaki çoka çok ilişkileri algılamak için ilişkinin her iki tarafını da dikkate almanın önemli olduğunu unutmayın.
İki tablonun konuları (siparişler ve ürünler) arasında çoka çok ilişki vardır. İşte bu sorun oluşturur. Sorunu anlamak için, Ürün Kimliği alanını Siparişler tablosuna ekleyerek iki tablo arasında ilişki oluşturmaya çalıştığınızda neler olabileceğini düşünün. Sipariş başına birden çok ürün olabilmesi için, Siparişler tablosunda sipariş başına birden çok kaydınızın bulunması gerekir. Tek bir siparişle ilgili her satır için yinelenen sipariş bilgileriniz olabilir ve sonuçta hatalı verilere yol açabilecek verimsiz bir tasarım elde edilir. Sipariş No alanını Ürünler tablosuna eklediğinizde de aynı sorunla karşılaşırsınız; Ürünler tablosunda her ürün için birden çok kaydınız olabilir. Bu sorunu nasıl çözersiniz?
Yanıt, çoka çok ilişkisini iki tane bire çok ilişkisine ayıran ve çoğunlukla birleşim tablosu olarak adlandırılan üçüncü bir tablo oluşturmaktır. İki tablonun her birinden birincil anahtarları üçüncü tabloya eklersiniz. Sonuç olarak, üçüncü tabloda ilişkinin her örneğinin kayıtları yer alır.
Sipariş Ayrıntıları tablosundaki her kayıt, siparişteki bir satır öğesini temsil eder. Sipariş Ayrıntıları tablosunun birincil anahtarı iki alandan oluşur: Siparişler tablosuyla Ürünler tablosunun yabancı anahtarları. Bu tablonun birincil anahtarı olarak tek başına Sipariş No alanını kullanmak işe yaramaz çünkü bir siparişin birden çok satır öğesi olabilir. Sipariş No siparişteki her satır öğesi için yinelenir, dolayısıyla bu alan benzersiz değerler içermez. Tek başına Ürün Kimliği alanını kullanmak da işe yaramaz, çünkü birçok farklı siparişte aynı ürün bulunabilir. Ama iki alan birlikte, her zaman her kayıt için benzersiz bir değer oluşturur.
Ürün satış veritabanında, Siparişler tablosuyla Ürünler tablosu birbiriyle doğrudan ilişkili değildir. Bunun yerine, aralarında Sipariş Ayrıntıları tablosu üzerinden dolaylı bir ilişki vardır. Siparişlerle ürünler arasındaki çoka çok ilişki, veritabanında iki adet bire çok ilişkiyle gösterilir:
-
Siparişler tablosuyla Sipariş Ayrıntıları tablosu arasında bire çok ilişki vardır. Her siparişin birden çok satır öğesi olabilir, ama her satır öğesi tek bir siparişle bağlantılıdır.
-
Ürünler tablosuyla Sipariş Ayrıntıları tablosu arasında bire çok ilişki vardır. Her ürünle ilişkilendirilmiş birçok satır öğesi olabilir, ama her satır öğesi tek bir ürüne işaret eder.
Sipariş Ayrıntıları tablosundan, belirli bir siparişteki tüm ürünleri belirleyebilirsiniz. Ayrıca, belirli bir ürünün tüm siparişlerini de belirleyebilirsiniz.
Sipariş Ayrıntıları tablosunu bir araya getirdikten sonra, tablo ve alan listesi aşağıdakine benzer görünebilir:
Bire bir ilişki oluşturma
Bir diğer ilişki türü de bire bir ilişkidir. Örneğin, çok seyrek ihtiyacınız olacak veya yalnızca birkaç ürün için geçerli olan bazı özel ek bilgileri kaydetmeniz gerektiğini varsayalım. Bilgiler pek sık gerekmeyeceği için ve bilgilerin Ürünler tablosunda depolanması bunların geçerli olmadığı her üründe boş alan bırakacağı için, bunları ayrı bir tabloya yerleştiriyorsunuz. Ürünler tablosunda olduğu gibi, birincil anahtar olarak Ürün Kimliği'ni kullanıyorsunuz. Bu ek tabloyla Ürün tablosu arasında bire bir ilişki vardır. Ürün tablosundaki her kayıt için, ek tabloda eşleşen tek bir kayıt bulunur. Böyle bir ilişki tanımladığınızda, her iki tablonun da ortak bir alanı paylaşması gerekir.
Veritabanınızda bire bir ilişki gerektiğini fark ettiğinizde, iki tablodaki bilgileri tek tabloya yerleştirip yerleştiremeyeceğinizi düşünün. Herhangi bir nedenle, belki de çok fazla boş alan kalmasına neden olacağı için bunu yapmak istemiyorsanız, aşağıdaki listede tasarımınızda ilişkiyi nasıl göstereceğiniz açıklanır:
-
İki tablonun konusu aynıysa, büyük olasılıkla her iki tabloda da aynı birincil anahtarı kullanıp ilişkiyi ayarlayabilirsiniz.
-
İki tablonun farkı birincil anahtarları olan farklı konuları varsa, tablolardan birini (herhangi birini) seçin ve onun birincil anahtarını diğer tabloya yabancı anahtar olarak ekleyin.
Tablolar arasındaki ilişkilerin belirlenmesi, doğru tablolara ve sütunlara sahip olduğunuzdan emin olmanıza yardım eder. Bire bir veya bire çok ilişki söz konusu olduğunda, ilişkiye katılan tablolar ortak bir veya birden çok sütunu paylaşmalıdır. Çoka çok ilişki söz konusu olduğunda, ilişkiyi göstermek için üçüncü bir tablo gerekir.
Tasarımı iyileştirme
İhtiyacınız olan tabloları, alanları ve ilişkileri aldıktan sonra, tablolarınızı oluşturup örnek verilerle doldurmanız ve şu bilgilerle çalışmayı denemeniz gerekir: sorgular oluşturma, yeni kayıtlar ekleme vb. Bunu yapmak olası sorunları vurgulamanıza yardımcı olur; örneğin, tasarım aşamasında eklemeyi unuttuğunuz bir sütun eklemeniz gerekebilir veya yinelemeyi kaldırmak için iki tabloya bölmeniz gereken bir tablonuz olabilir.
Veritabanını kullanarak istediğiniz yanıtları alıp alamadığınıza bakın. Formlarınızla raporlarınızın taslaklarını oluşturun ve beklediğiniz verileri gösterip göstermediklerine bakın. Gereksiz veri yinelemeleri olup olmadığını denetleyin ve yineleme bulursanız, bunu ortadan kaldırmak için tasarımınızda değişiklik yapın.
İlk veritabanınızı denerken, büyük olasılıkla geliştirilebilecek noktalar keşfedersiniz. İşte denetleyebileceğiniz birkaç nokta:
-
Unuttuğunuz sütunlar var mı? Varsa, bu bilgiler var olan tablolardan birine mi ait? Bu bilgi başka bir konuyla ilgiliyse, başka bir tablo oluşturmanız gerekebilir. İzlemeniz gereken her bilgi için bir sütun oluşturun. Söz konusu bilgi başka sütunlardan hesaplanamıyorsa, büyük olasılıkla bunun için bir sütuna ihtiyacınız vardır.
-
Var olan alanlardan hesaplanabildiği için aslında gereksiz olan alanlar var mı? Bir bilgi öğesi var olan diğer sütunlardan hesaplanabiliyorsa (örneğin, perakende fiyatından hesaplanan indirimli fiyat), çoğunlukla yeni sütun oluşturmak yerine böyle hesaplamak daha iyidir.
-
Tablolarınızdan birine sürekli yinelenen bilgiler mi giriyorsunuz? Öyleyse, büyük olasılıkla tabloyu bire çok ilişkisi olan iki tabloya bölmeniz gerekiyordur.
-
Birçok alanı olan, sınırlı sayıda kaydı olan ve tek tek kayıtlarda birçok boş alanı olan tablolarınız mı var? Öyleyse, tabloyu daha az alanı ve daha çok kaydı olacak şekilde yeniden tasarlamayı düşünün.
-
Her bilgi öğesi, kullanılabilir en küçük parçalarına bölünmüş mü? Bir bilgi öğesini kullanarak raporlama, sıralama, arama veya hesaplama yapmanız gerekiyorsa, o öğeyi kendi sütununa yerleştirin.
-
Her sütun tablonun konusu hakkında bir bilgi içeriyor mu? Bir sütun tablonun konusu hakkında bilgi içermiyorsa, başka bir tabloya aittir.
-
Tablolar arasındaki tüm ilişkiler ortak alanlarla veya üçüncü bir tabloyla gösteriliyor mu? Bire bir ve bire çok ilişkiler için ortak sütunlar gerekir. Çoka çok ilişkiler ise üçüncü bir tabloyu gerektirir.
Ürünler tablosunu geliştirme
Ürün satış veritabanındaki her ürünün içecekler, çeşniler veya deniz ürünleri gibi genel bir kategori altında olduğunu varsayalım. Ürünler tablosunda her ürünün kategorisini gösteren bir alan bulunabilir.
Veritabanınızın tasarımını inceledikten ve geliştirdikten sonra, kategorinin adıyla birlikte açıklamasını da depolamaya karar verdiğinizi varsayalım. Ürünler tablosuna bir Kategori Açıklaması alanı eklerseniz, kategori kapsamındaki her ürün için kategori açıklamalarını yinelemeniz gerekir ve bu iyi bir çözüm değildir.
Kendi tablosu ve kendi birincil anahtarıyla kategorileri veritabanında izlenecek yeni bir konu yapmak, daha iyi bir çözüm olur. Ardından, Kategoriler tablosunun birincil anahtarını Ürünler tablosuna yabancı anahtar olarak ekleyebilirsiniz.
Kategoriler tablosuyla Ürünler tablosu arasında bire çok ilişkisi olur: bir kategori birden çok ürün içerebilir ama bir ürün yalnızca bir kategoriye ait olabilir.
Tablo yapılarınızı gözden geçirirken, yinelenen grupları saptamak için tetikte olun. Örneğin, aşağıdaki sütunları olan bir tablo düşünün:
-
Ürün Kimliği
-
Ad
-
Ürün Kimliği1
-
Ad1
-
Ürün Kimliği2
-
Ad2
-
Ürün Kimliği3
-
Ad3
Burada her ürünün, diğerlerinden yalnızca ürün adının sonuna eklenen bir sayıyla ayrılan, yinelenen sütun grupları vardır. Bu şekilde numaralandırılmış sütunlar gördüğünüzde, tasarımınızı yeniden gözden geçirmelisiniz.
Bu tür bir tasarımın çeşitli kusurları vardır. Başlangıç olarak, sizi ürün sayısına bir üst sınır belirlemeye zorlar. Bu sınırı aştığınız anda, tablo yapısında yeni bir sütun grubu eklemeniz gerekir ve bu önemli bir yönetim görevidir.
Diğer bir sorun, ürün sayısı üst sınırının altında ürünü olan sağlayıcıların gereksiz bazı alanları olmasıdır, çünkü ek sütunlar boş bırakılacaktır. Böyle bir tasarımın en ciddi kusuru, tabloyu ürün kimliğine veya adına göre sıralama veya dizine alma gibi birçok görevin gerçekleştirmesini zorlaştırmasıdır.
Yinelenen gruplar gördüğünüz her noktada tasarımı iyice gözden geçirip tablonun ikiye bölünüp bölünemeyeceğine dikkat edin. Yukarıdaki örnekte, biri sağlayıcılar ve diğeri de ürünler için olmak üzere iki tablo kullanmak ve bunları sağlayıcı kimliğiyle bağlamak daha iyi olur.
Normalleştirme kurallarını uygulama
Tasarımınızda bir sonraki adım olarak veri normalleştirme uygulayabilirsiniz (bazen doğrudan normalleştirme kuralları olarak adlandırılır). Bu kuralları kullanarak tablolarınızın doğru yapılandırılıp yapılandırılmadığını görebilirsiniz. Veritabanı tasarımınıza kurallar uygulama işlemi, veritabanını normalleştirme veya yalnızca normalleştirme olarak adlandırılır.
Normalleştirme en çok, bilgi öğelerinizin tümünü gösterdikten ve bir başlangıç tasarımı elde ettikten sonra uygulandığında yararlı olur. Amaç, bilgi öğelerinizi uygun tablolara böldüğünüzden emin olmanıza yardım etmektir. Normalleştirme, başlangıç olarak tüm doğru öğelere sahip olduğunuzdan emin olmanızı sağlayamaz.
Kuralları sırayla uygular, her adımda tasarımınızın "normal formlar" olarak bilinen noktalardan birine ulaştığından emin olursunuz. Birinci normal formdan beşinci normal forma kadar, yaygın olarak kabul edilen beş normal form vardır. Bu makalede ilk üçü forma kadar ayrıntılar verilmiştir, çünkü veritabanı tasarımlarının çoğunluğunda gereken yalnızca bunlardır.
Birinci normal form
İlk normal formda, tablodaki her satır ve sütun kesişiminde bir değer listesi değil tek bir değer bulunduğu belirtilir. Örneğin, içine birden çok Fiyat eklediğiniz bir Fiyat alanınız olamaz. Satır ve sütunların kesişimini bir hücre olarak düşünürseniz, her hücrede tek değer bulunabilir.
İkinci normal form
İkinci normal form, anahtar olmayan her sütunun birincil anahtarın yalnızca bir bölümüne değil tamamına tümüyle bağımlı olmasını gerektirir. Bu kural, birden çok sütundan oluşan bir birincil anahtarınız olduğunda geçerlidir. Örneğin, şu sütunlardan oluşan bir tablonuz olduğunu ve bu tabloda Sipariş No ile Ürün Kimliği'nin birincil anahtarı oluşturduğunu varsayalım:
-
Sipariş No (birincil anahtar)
-
Ürün Kimliği (birincil anahtar)
-
Ürün Adı
Bu tasarım ikinci normal formu ihlal eder, çünkü Ürün Adı sütunu Ürün Kimliği'ne bağımlıdır ama 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 sütun, başka bir tabloya (Ürünler) aittir.
Üçüncü normal form
Üçüncü normal forma göre, anahtar olmayan her sütunun birincil anahtarın tamamına bağımlı olması gerektiği gibi, anahtar olmayan sütunların birbirinden bağımsız olması da gerekir.
Başka bir deyişle, anahtar olmayan her sütun birincil anahtara bağımlı olmalı ve başka hiçbir şeye bağımlı olmamalıdır. Örneğin, aşağıdaki sütunlardan oluşan bir tablonuz olduğunu varsayalım:
-
Ürün Kimliği (birincil anahtar)
-
Ad
-
ÖPF
-
İndirim
İndirim'in önerilen perakende fiyatına (ÖPF) bağımlı olduğunu varsayalım. Bu tablo üçüncü normal formu ihlal eder, çünkü anahtar olmayan İndirim sütunu anahtar olmayan bir diğer sütuna (ÖPF) bağımlıdır. Sütun bağımsızlığı, anahtar olmayan bir sütunun diğer hiçbir sütunu etkilemeden değiştirilebileceği anlamına gelir. ÖPF alanındaki değeri değiştirirseniz İndirim de buna göre değişeceğinden, bu kural ihlal edilmiş olur. Bu durumda, İndirim sütunu ÖPF'nin birincil anahtar olduğu başka bir tabloya taşınmalıdır.
