Varlık ilişkisel Modelleme
Varlık ilişkisel (ER) modeli için geliştirilen önemli bir teori, işlevsel bağımlılık (FD) kavramını içerir. Bu eğitimin amacı, veriler arasındaki ilişkilere dair anlayışınızı geliştirmek ve pratik veritabanı tasarımına yardımcı olacak yeterli formalizmi kazanmaktır.
Kısıtlamalar gibi, FD'ler de uygulama alanının semantiğinden çıkarılır. Esasen, işlevsel bağımlılıklar bireysel niteliklerin nasıl ilişkili olduğunu açıklar. FD'ler bir ilişki içindeki nitelikler arasında bir tür kısıtlamadır ve iyi bir ilişkisel şema tasarımına katkıda bulunur. Bu bölümde şu konulara bakacağız:
- İşlevsel bağımlılığın temel teorisi ve tanımı
- Normalleştirme olarak da adlandırılan şema tasarımlarını iyileştirme metodolojisi
İlişkisel Tasarım ve Yedeklilik
Genel olarak, iyi bir ilişkisel veritabanı tasarımı gerekli tüm nitelikleri ve ilişkileri yakalamalıdır. Tasarım bunu minimum miktarda depolanmış bilgi ve gereksiz veri olmadan yapmalıdır.
Veritabanı tasarımında fazlalık genellikle istenmeyen bir durumdur çünkü güncellemelerden sonra tutarlılığın korunmasında sorunlara neden olur. Bununla birlikte, artıklık bazen performans iyileştirmelerine yol açabilir; örneğin, verileri bağlamak için birleştirme yerine artıklık kullanılabildiğinde. Birleştirme, iki ilgili tabloya dayalı olarak bilgi edinmeniz gerektiğinde kullanılır.
Aşağıdaki şekli düşünün: 1313131 numaralı müşteri iki kez görüntülenir, bir kez hesap no. A-101 ve tekrar A-102 hesabı için. Bu durumda, müşteri numarası gereksiz değildir, ancak tablo ile silme anormallikleri vardır. Ayrı bir müşteri tablosuna sahip olmak bu sorunu çözecektir. Ancak, bir şube adresi değişirse, birden fazla yerde güncellenmesi gerekecektir. Müşteri numarası tabloda olduğu gibi bırakılsaydı, bir şube tablosuna ihtiyacınız olmazdı ve birleştirme gerekmezdi ve performans artardı.
Yerleştirme Anomalisi
Bir tabloya tutarsız bilgiler eklediğinizde bir ekleme anomalisi oluşur. Yeni bir kayıt eklediğimizde, örneğin aşağıdaki şekildeki hesap no. Şekil 10.2'deki A-306 gibi, şube verilerinin mevcut satırlarla tutarlı olup olmadığını kontrol etmemiz gerekir.
Güncelleme Anomalisi
Aşağıdaki şekildeki Round Hill şubesi gibi bir şube adres değiştirirse, bu şubeye atıfta bulunan tüm satırları güncellememiz gerekir. Mevcut bilgilerin yanlış bir şekilde değiştirilmesine güncelleme anomalisi denir.
Silme Anomalisi
Silinmemesi gereken öznitelikler içerebilecek bir kaydı sildiğinizde silme anomalisi oluşur. Örneğin, aşağıdaki şekildeki Downtown şubesindeki A-101 hesabı gibi bir şubedeki son hesapla ilgili bilgileri kaldırırsak, tüm şube bilgileri kaybolur.
A-101 satırının silinmesiyle ilgili sorun, Downtown şubesinin nerede olduğunu bilmememiz ve 1313131 müşterisiyle ilgili tüm bilgileri kaybetmemizdir. Bu tür güncelleme veya silme sorunlarından kaçınmak için orijinal tabloyu, her tablonun diğer tablolarla minimum örtüşmeye sahip olduğu birkaç küçük tabloya ayırmamız gerekir.
Her banka hesabı tablosu, aşağıdaki şekilde gösterildiği gibi, Şube veya Müşteri gibi yalnızca bir varlık hakkında bilgi içermelidir.
Bu uygulamanın takip edilmesi, şube bilgileri eklendiğinde veya güncellendiğinde bunun sadece bir kaydı etkilemesini sağlayacaktır. Böylece, müşteri bilgileri eklendiğinde veya silindiğinde, şube bilgileri yanlışlıkla değiştirilmeyecek veya yanlış kaydedilmeyecektir.
Örnek: çalışan proje tablosu ve anomaliler
Aşağıdaki şekilde bir çalışan proje tablosu örneği gösterilmektedir. Bu tablodan şunu varsayabiliriz:
- EmpID ve ProjectID bileşik bir PK'dır.
- Proje Kimliği Bütçeyi belirler (örneğin, Proje P1'in 32 saatlik bir bütçesi vardır).
Şimdi, aşağıdaki adımlar sırasında bu tabloda meydana gelebilecek bazı olası anormalliklere bakalım.
- Eylem: Satır ekle {S85,35,P1,9}
- Problem: Çelişen bütçelere sahip iki kuple var
- Eylem: Tuple'ı sil {S79, 27, P3, 1}
- Sorun: Adım #3, P3 projesi için bütçeyi siler
- Eylem: S75, 32, P1, 7} çiftini {S75, 35, P1, 7} olarak güncelle
- Sorun: Adım #5, P1 projesinin bütçesi için farklı değerlere sahip iki tuple oluşturur
- Çözüm: Aşağıdaki şekilde gösterildiği gibi Projeler ve Çalışanlar için ayrı birer tablo oluşturun.
Anomaliler Nasıl Önlenir
Anormallik içermeyen tablolar oluşturmaya yönelik en iyi yaklaşım, tabloların normalleştirilmesini sağlamaktır ve bu da işlevsel bağımlılıkları anlayarak gerçekleştirilir. FD, bir tablodaki tüm özniteliklerin o tabloya ait olmasını sağlar. Başka bir deyişle, fazlalıkları ve anormallikleri ortadan kaldıracaktır.
Örnek: ayrı Proje ve Çalışan tabloları
Ayrı Proje ve Çalışan tabloları kullanarak verileri ayrı tutarak:
- Bir bütçe değiştirilirse hiçbir anormallik yaratılmayacaktır.
- Atanmış çalışanı olmayan projeler için kukla değerlere gerek yoktur.
- Bir çalışanın katkısı silinirse, önemli veriler kaybolmaz.
- Bir çalışanın katkısı eklenirse hiçbir anormallik oluşmaz.
| Alıştırmalar |
1. Normalleştirme aşağıdaki şekil Yukarıdaki şekil Soru 1 için tablo, A. Watt tarafından hazırlanmıştır. 2. Çevrimiçi bir film kiralama hizmeti için mantıksal bir ERD oluşturun (çoktan çoğa ilişki olmaksızın). İş kurallarınızın temel alması gereken işlemlerin aşağıdaki açıklamasını kullanın: Çevrimiçi film kiralama hizmeti, film başlıklarını türlerine göre sınıflandırır: komedi, western, klasik, bilim kurgu, çizgi film, aksiyon, müzikal ve yeni sürüm. Her tür birçok olası başlık içerir ve bir tür içindeki çoğu başlık birden fazla kopya halinde mevcuttur. Örneğin, aşağıdaki özete dikkat edin: TÜR BAŞLIK Musical My Fair Lady (Kopya 1) My Fair Lady (Kopya 2) Oklahoma (Kopya 1) Oklahoma (Kopya 2) Oklahoma (Kopya 3) etc. 3. Hangi üç veri anomalisinin veri fazlalığının sonucu olması muhtemeldir? Bu tür anomaliler nasıl ortadan kaldırılabilir? Ayrıca bkz Ek; Örnek ERD Alıştırmaları |
Atıf
Veritabanı Tasarımı'nın bu bölümü (aksi belirtilmedikçe resimler dahil) Nguyen Kim Anh tarafından yazılan Relational Design Theory adlı eserin Creative Commons Attribution License 3.0 lisansı altında lisanslanmış türevidir.
Önceki Ders: Bütünlük Kuralları ve Kısıtlamalar
Sonraki Ders: Fonksiyonel Bağımlılıklar
Yorumlar
Yorum Gönder