|
[ Pobierz całość w formacie PDF ]
.Rozważmy ponownie przykład tabeli FAKTURA.Gdyby jej klucz główny składałsię z kolumn NrMagazynu i Nr Faktury, to przechowywanie nazwy magazynuw każdym wierszu tej tabeli byłoby naruszeniem drugiej postaci normalnej.Kolumna NazwaMagazynu nie byłaby jednoznacznie identyfikowana przez obiekolumny klucza głównego.Byłaby zależna od kolumny NrMagazynu, ale nie odkolumny NrFaktury.Dlatego nazwę magazynu należy pobierać w razie potrzeby Projektowanie baz danych w modelu klient/serwer 179z oddzielnej tabeli, korzystając ze złączenia, a nie przechowywać na stałe w tabeliFAKTURA.Trzecia postać normalnaAby tabela przyjęła trzecią postać normalną, każda z jej kolumn musi byćcałkowicie zależna od klucza głównego i niezależna od pozostałych kolumn.A zatem tabela musi spełniać warunki drugiej postaci normalnej, a ponadto każdakolumna, nie będąca kluczem, musi być niezależna od pozostałych kolumnniekluczowych.Powróćmy do przykładu tabeli FAKTURA.Załóżmy, że jej kluczem głównymnadal są kolumny Nr Magazynu i Nr Faktury.W tabeli występuje ponadtokolumna Nr Klienta, która nie jest kluczem.Jeśli w tej samej tabeli występowałabykolumna Nazwa Klienta, to tabela nie spełniłaby warunków trzeciej postacinormalnej.Kolumny Nr Klienta i Nazwa Klienta są bowiem wzajemnie zależne.Zmiana numeru klienta musiałaby pociągać za sobą zmianę w kolumnie NazwaKlienta i odwrotnie.Dlatego kolumna Nazwa Klienta powinna znalezć sięw oddzielnej tabeli (np.KLIENT), a jej zawartość powinna być pobierana w raziepotrzeby za pomocą odpowiedniego złączenia.UWAGA:Rozszerzona definicja trzeciej postaci normalnej, zwana postacią normalnąBoyce'a - Codda (BCNF, Boyce-Codd Normal Form) zawiera dodatkowy warunek:każda kolumna, od której zależna jest jakakolwiek inna kolumna, musi byćkluczem unikalnym.Zbiory kolumn, które mogą w sposób jednoznacznyidentyfikować wiersze, nazywane są kluczami potencjalnymi.Klucz główny tabeliwybierany jest spośród kluczy potencjalnych.W tabeli znormalizowanej dopostaci BCNF kolumna może być zależna tylko od klucza potencjalnego.Postaćnormalna BCNF jest zatem szczególnym przypadkiem trzeciej postaci normalnej,dopuszczającym zależności pomiędzy kolumnami-kluczami potencjalnymi orazinnymi kolumnami, nie będącymi kluczami.Należy podkreślić, że występowanietakich zależności nie stanowi naruszenia trzeciej postaci normalnej, gdyż kolumnyzależne są wyłącznie od kluczy potencjalnych.Klucze takie jednoznacznieidentyfikują wiersze, podobnie jak klucz główny tabeli.A zatem rozróżnieniemiędzy zależnością od klucza głównego i od klucza potencjalnego jest problememczysto akademickim - oba rodzaje kluczy jednoznacznie identyfikują wierszetabeli.Nie należy przywiązywać szczególnie dużej wagi do powyższego rozszerzeniadefinicji trzeciej postaci normalnej.Zgodność z klasyczną definicją trzeciej postacinormalnej jest powszechnie przyjętym kryterium normalizacji.Nie należy brać poduwagę różnic, które nie mają praktycznego znaczenia. 180 Część ICzwarta postać normalnaCzwarta postać normalna eliminuje wielowartościowe zależności międzykolumnami.O zależności wielowartościowej mówimy wówczas, gdy jednakolumna nie identyfikuje jednoznacznie drugiej, a jedynie zawęża ją do zbiorupredefiniowanych wartości.Przyjrzyjmy się tabeli TENANT (najemca)przykładowego systemu RENTMAN.Dla uproszczenia dyskusji załóżmy, żejedyną informacją o pracodawcy (Employer) najemcy będzie jego nazwa(pomijamy adres, itp.).W tabeli TENANT znajdzie się zatem atrybut Employer.Jeśli jeden najemca ma kilku pracodawców (bo jest np.pracoholikiem i pisujeksiążki po nocach), to w tabeli TENANT musi znalezć się kilka wierszy,związanych z tym samym najemcą.Wiersze te będą niemal identyczne - będą sięróżnić jedynie wartością atrybutu Employer.Relacja między kolumną Employer a każdą inną kolumną tabeli TENANT będziezależnością wielowartościową.Każdej wartości w kolumnie TenantNoodpowiadać będzie kilka różnych wartości z kolumny Employer.W praktycezałożenie, że jeden najemca może mieć kilku pracodawców, może okazać sięprzydatne.Ponadto czasami celowe będzie sporządzenie listy wszystkichnajemców, zatrudnionych u danego pracodawcy.W takim przypadku, chcączachować zgodność z warunkami czwartej postaci normalnej, należałoby utworzyćoddzielną tabelę, której jedyną funkcją byłoby przechowywanie danych o relacjachmiędzy najemcami a pracodawcami.W idealnym przypadku tabela taka składałabysię z dwóch kolumn: TenantNo (nr najemcy) i Employer (pracodawca).Obiekolumny tworzyłyby jeden, złożony klucz główny.Chcąc uzyskać kompletinformacji o danym najemcy, należałoby wykonać złączenie tabeli TENANTz nową tabelą na podstawie wspólnej kolumny TenantNo.W rzeczywistych aplikacjach nierzadko można natrafić na tabele, którychkonstrukcja narusza warunki czwartej postaci normalnej.Dekompozycja encji,sięgająca poza trzecią postać normalną, prowadzi czasami do powstania bardzoskomplikowanego modelu, którego implementacja uznawana jest za nieopłacalną.Piąta postać normalnaPiąta postać normalna zdefiniowana jest jako postać bazy danych, w którejwszystkie tabele, które mają więcej niż dwa klucze potencjalne i dają się rozbićbez utraty danych, powinny zostać podzielone na osobne tabele, po jednej dlakażdego klucza potencjalnego.Istnieje kilka powodów, dla których piąta postaćnormalna występuje niezmiernie rzadko.Po pierwsze, w praktyce trudno jestnatrafić na tabelę, w której więcej niż dwa zestawy kolumn jednoznacznieidentyfikowałyby wiersze.Po drugie, silna dekompozycja może doprowadzić dopowstawania niedokładnych złączeń, np.generujących nowe wiersze.W rzeczywistych aplikacjach piąta postać normalna niemal nie występuje.Zostałatutaj wspomniana wyłącznie dla zachowania kompletności opisu. Projektowanie baz danych w modelu klient/serwer 181O konieczności zachowania umiaru w normalizacjiPrzystępując do normalizacji bazy danych należy zachować ostrożność i nieprzekroczyć granicy opłacalności.Zbyt daleko posunięta normalizacja może miećfatalny wpływ na wydajność.Można by, na przykład, rozważyć utworzenieoddzielnej tabeli do przechowywania informacji o pracodawcach.Obecnieinformacje te pamiętane są w tabeli TENANT.W istocie kolumny Employeri EmployerAddress są w oczywisty sposób zależne, co jest naruszeniemwarunków trzeciej postaci normalnej.Jakie jednak byłyby realne korzyściz utworzenia oddzielnej tabeli na dane o pracodawcach? Dane te prawdopodobniesą istotne wyłącznie w odniesieniu do określonego najemcy.Firmy, będącejużytkownikiem systemu RENTMAN, nie interesuje lista najemców, zatrudnionychu wybranego pracodawcy.Załóżmy ponadto, że nie występuje w praktyce potrzebaprzechowywania danych o więcej niż jednym pracodawcy każdego najemcy.Wreszcie sensowne wydaje się założenie, że nigdy nie zajdzie potrzebawprowadzania globalnych zmian w danych o pracodawcach.Biorąc pod uwagępowyższe założenia, można stwierdzić, że wydzielanie osobnej tabeli na danepracodawców byłoby jedynie stratą czasu.Zdarzają się również sytuacje, w których żądaną wydajność można uzyskać tylkoprzez świadomą, ograniczoną denormalizację.Jest to szczególnie prawdopodobnew przypadku aplikacji, które przetwarzają bardzo duże zbiory danych.Rozważmy,na przykład, aplikację, która dziennie musi przetworzyć setki tysięcy dowodówpłatności kartą kredytową.Każdy dowód płatności zawiera m.in [ Pobierz całość w formacie PDF ] |
Archiwum
|