Normalizacja schematów relacji

Transkrypt

1 Normalizacja schematów relacji 1. Przykład złego schematu relacji Rozważmy schemat relacji: Dostawcy = { Nazwa_dostawcy, Adres_dostawcy, Nazwa_towaru, Cena } i przykładową jej zawartość: NazwaDostawcy AdresDostawcy TelefonDostawcy NazwaTowaru Cena Marczak Michał Łódzka Rzodkiewka 1,40 zł Marczak Michał Łódzka Groszek zielony 8,20 zł Krysiak Jerzy Zielona Śmietana 18% 3,10 zł Krysiak Jerzy Zielona Masło śmietankowe 3,20 zł Marczak Michał Łódzka Fasolka żółta 9,30 zł Pasikowski Jan Poznańska Chleb 2,00 zł 2. Anomalie złego schematu relacji Dlaczego powyższy schemat jest zły? Można zaobserwować następujące cztery niekorzystne zjawiska: redundancja adres dostawcy powtarza się dla każdego dostarczanego towaru, anomalie przy modyfikacji uaktualniony adres w jednym rekordzie pozostaje niezmieniony w innych, anomalie przy wstawianiu trudno wstawić dostawcę bez towarów; towar wchodzi w skład klucza nie może być wartością pustą (NULL), anomalie przy usuwaniu usuwając informacje o wszystkich towarach dostarczonych przez dostawcę (który może zmienić profil produkcji) usuwamy informację o samym dostawcy. Przyczynę trudności można wyjaśnić w następujący sposób: w powyższym schemacie mamy do czynienia ze złączeniem dwóch różnych rodzajów obiektów (encji), które byłoby lepiej określić jako osobne relacje: Dostawcy = { Nazwa_dostawcy, Adres_dostawcy} Towary = { Nazwa_dostawcy, Nazwa_towaru, Cena } 3. Bezstratna dekompozycja Model relacyjny pozwala sprzęgać ze sobą relację na różne sposoby za pomocą łączenia atrybutów. Proces uzyskiwania w pełni znormalizowanego modelu danych wymaga usunięcia redundancji poprzez dzielenie relacji w taki sposób, aby uzyskane w efekcie relacje mogły być znowu połączone bez straty żadnej informacji. Jest to reguła bezstratnej dekompozycji. Np. relacja pokazana na poniższym rysunku może być podzielona na dwie relacje przedstawione poniżej. NrZamówienia DataZamówienia DataWymagana NazwaFirmy Adres Miasto KodPocztowy /04/ /04/08 CATCU Lipowa 5 Wrocław /04/ /04/30 Mar-Trans Łódzka 3 Toruń /05/ /05/12 Krakus Kraka 7 Kraków /05/ /06/04 CATCU Lipowa 5 Wrocław Rysunek. Relacja nieznormalizowana 1

2 4. Bezstratna dekompozycja Relacja Faktury NrZamówienia KodKlienta DataZamówienia DataWymagana /04/ /04/ /04/ /04/ /05/ /05/ /05/ /06/04 Relacja Klienci KodKlienta NazwaFirmy Adres Miasto KodPocztowy 010 CATCU ul. Lipowa 5 Wrocław Mar-Trans ul. Łódzka 3 Toruń Krakus ul. Kraka 7 Kraków Użycie dwóch relacji eliminuje redundancję w zakresie adresów, a przy tym nadal pozwala wyszukiwać adresy klientów (za pomocą atrybutu KodKlienta, który jest przechowywany w zestawie rekordów Klienci, jak i Faktury). 5. Proces normalizacji Włożono wiele wysiłku w poszukiwanie procedur ulepszania schematów. Najważniejszą z nich jest procedura normalizowania schematów. Otóż analiza zależności funkcyjnych między atrybutami kluczowymi a pozostałymi atrybutami umożliwia stwierdzanie posiadania przez schemat pewnych pożądanych właściwości. W schematach złych może ona wykazać istnienie anomalii. Anomalie te mogą być usuwane przez rozkładanie schematów relacyjnych na schematy bardziej elementarne. Proces ten nazywany jest procesem normalizacji i został zaproponowany już przez samego twórcę modelu relacyjnego, tj. przez E.F.Codda. Reguły normalizacji są narzędziami do porządkowania struktury danych. Kolejne postacie normalne określają w coraz to ściślejszy sposób strukturę relacji. Każda następna postać stanowi rozszerzenie poprzedniej i ma na celu zapobieżenie pewnym rodzajom anomaliom towarzyszących aktualizacji. Należy pamiętać, że postacie nie są przepisami na tworzenie poprawnych modeli danych. Model danych może być idealnie znormalizowany, a mimo to nie pozwalać na udzielenie odpowiedzi na zadawane pytania. Może też udzielać tych odpowiedzi, ale tak wolno i nieporadnie, że zbudowany na jego podstawie system bazy danych będzie bezużyteczny. Jeśli jednak model danych jest znormalizowany to znaczy zgodny z regułami struktury relacyjnej istnieje duża szansa, że będzie to efektywny i wydajny model danych. 6. Pierwsza postać normalna Relacja jest w pierwszej postaci normalnej, jeśli domeny zdefiniowane dla jej atrybutów są skalarne (atomowe, proste). Jest to jednocześnie najprostsze, jak i najtrudniejsze pojęcie w modelowaniu danych. O wartości a DOM(A) powiemy, ze jest wartością skalarną, jeśli nie jest ani zbiorem, ani ciągiem elementów należących do zbioru {DOM(A) : A U}, tj. do sumy domen atrybutów. 2

3 Inaczej o relacji powiemy, iż jest w pierwszej postaci normalnej, jeśli każde przecięcie jej wiersza i kolumny zawiera jedną i tylko jedną wartość, tj. wartość skalarną. PRZYKŁAD. Relacja nieznormalizowana Nr_zamówienia Data zamówienia Pozycje Kwota /05/02 3 barszczyk czerwony, 1 flaki, 4 kotlet schabowy, 4 herbata 108,30 zł /05/06 4 pizza klasyczna, 4 pepsi 89,60 zł /05/12 2 zupa grzybowa, 2 befsztyk, 2 kawa, 2 lody czekoladowe 81,20 zł W relacji pokazanej na powyższym rysunku atrybut Pozycje zawiera oczywiście kilka wartości (zbiór wartości) i w związku z tym relacja ta nie jest w pierwszej postaci normalnej. 7. Problem wartości skalarnej Problem z ustaleniem czy atrybut jest skalarny cz y też nie, wcale nie jest tak prosty jakby to mogłoby się wydawać. Przykład. Nr_pracownika Pracownik Data urodzenia Adres N032 prof. dr hab. Michał Nowaczyk 1961/09/02 Warszawa, ul. Śniadeckich 5 m.21 D009 inż. Adam Dąbrowski 1967/10/16 Łódź, ul. Tatrzańska 1 m.12 S010 dr hab. Marta Sterlińska 1965/07/22 Łódź, ul. Lipowa 5 m.4 Na pierwszy rzut oka można by stwierdzić, iż choćby kolumna Pracownik nie zawiera wartości skalarnych. Tym niemniej, może okazać się, iż w pewnym kontekście są one proste. To samo można powiedzieć o kolumnie Adres. UWAGA. Należy zawsze rozpatrywać atomowość danych przechowywanych kolumnie w konkretnym kontekście. W jednym kontekście dane te mogą być skalarne, a w innych już nie. Kłopotliwą domeną są daty. Składają się one z trzech różnych elementów: dnia, miesiąca i roku. Jeśli system posługuje się datą wyłącznie, a przynajmniej głównie, jako pojedynczą wartością, jest ona skalarna. Jeśli jednak system musi się często odwoływać do poszczególnych składników daty, lepiej będzie przechowywać je jako oddzielne atrybuty. Innym częstym źródłem problemów z wartościami nieskalarnymi są kody i flagi. Wiele firm nadaje rozpatrywanym przez nie sprawom i tematom sygnatury, które są wartościami wyliczanymi. Np. zapis SYG może oznaczać pierwszą sprawę w maju 2009 roku. 8. Dwie techniki sprowadzania relacji do pierwszej postaci normalnej przy powtarzaniu się grup wartości I SPOSÓB tzw. spłaszczanie tabeli Usuwamy powtarzające się grupy wartości poprzez przeniesienie odpowiednich danych do pustych kolumn w wierszach zawierających powtarzające się dane. Inaczej mówiąc, wypełniamy puste miejsca, powielając w nich niepowtarzające się dane, tam gdzie istnieje taka potrzeba. To postępowanie jest zwykle nazywane spłaszczaniem tabeli. Wynikowa tabela, którą otrzymamy, zawiera teraz skalarne wartości na przecięciu każdego wiersza i każdej kolumny. Zgodnie z definicją, taka relacja jest w pierwszej postaci normalnej. 3

4 Technika ta wprowadza do wynikowej relacji pewną redundancję, która może z niej być usunięta w następnych etapach procesu normalizacji. II SPOSÓB bezstratna dekompozycja Usuwamy powtarzające się grupy wartości poprzez umieszczenie powtarzających się danych wraz z kopią oryginalnego atrybutu (atrybutów) klucza w oddzielnej relacji. W nowej relacji wyznaczamy klucz główny. W niektórych przypadkach może okazać się konieczne zastosowanie tej techniki więcej niż raz, aż do mementu wyeliminowania wszystkich powtórzeń. 9. Przykład zastosowania techniki spłaszczania tabeli w celu sprowadzenia relacji do pierwszej postaci normalnej Relacja nieznormalizowana Nr_zamówienia Data_zamówienia Potrawa Ilość Kwota /05/02 barszczyk czerwony flaki kotlet schabowy herbata /05/06 pizza klasyczna pepsi /05/12 zupa grzybowa befsztyk kawa lody czekoladowe ,20 zł 9,30 zł 68,00 zł 14,80 zł 74,60 zł 14,00 zł 15,40 zł 36,40 zł 12,80 zł 16,60 zł Relacja w pierwszej postaci normalnej po zastosowaniu techniki spłaszczania tabeli Nr_zamówienia Data_zamówienia Potrawa Ilość Kwota /05/02 barszczyk czerwony 3 16,20 zł /05/02 flaki 1 9,30 zł /05/02 kotlet schabowy 4 68,00 zł /05/02 herbata 4 14,80 zł /05/06 pizza klasyczna 4 74,60 zł /05/06 pepsi 4 14,00 zł /05/12 zupa grzybowa 2 15,40 zł /05/12 befsztyk 2 36,40 zł /05/12 kawa 2 12,80 zł /05/12 lody czekoladowe 2 16,60 zł 10. Przykład zastosowania techniki dekompozycji w celu sprowadzenia relacji do pierwszej postaci normalnej Rozważmy powyżej przedstawioną relację nieznormalizowaną. Metodą techniki dekompozycji sprowadzamy ją do pierwszej postaci normalnej uzyskując relację przedstawiona poniżej 4

5 Relacje w pierwszej postaci normalnej po zastosowaniu techniki dekompozycji Nr_zamówienia Data_zamówienia /05/ /05/ /05/ /05/ /05/ /05/ /05/ /05/ /05/ /05/12 Nr_zamówienia Potrawa Ilość Kwota 0102 barszczyk czerwony 3 16,20 zł 0102 flaki 1 9,30 zł 0102 kotlet schabowy 4 68,00 zł 0102 herbata 4 14,80 zł 0109 pizza klasyczna 4 74,60 zł 0109 pepsi 4 14,00 zł 0110 zupa grzybowa 2 15,40 zł 0110 befsztyk 2 36,40 zł 0110 kawa 2 12,80 zł 0110 lody czekoladowe 2 16,60 zł 11. Pełna i częściowa zależność funkcyjna DEFINICJA. Niech X i Y będą rozłącznymi zbiorami atrybutów. Mówimy, że Y jest w pełni funkcyjnie zależny od X lub, że istnieje pełna zależność funkcyjna z X do Y, jeśli Y jest zależny funkcyjnie od X i nie jest zależny od żadnego właściwego podzbioru zbioru X. DEFINICJA. Niech X i Y będą rozłącznymi zbiorami atrybutów. Mówimy, że Y jest częściowo funkcyjnie zależny od X lub, że istnieje częściowa zależność funkcyjna z X do Y, jeśli Y jest zależny funkcyjnie od X i jeśli w X istnieje atrybut, po usunięciu którego zależność ta nadal zachodzi. PRZYKŁAD. Rozważmy następującą zależność funkcyjną {KodDostawcy, NazwaDostawcy} AdresDostawcy Nietrudno zauważyć, iż zbiór atrybutów {KodDostawcy, NazwaDostawcy} jednoznacznie wyznacza wartość atrybutu AdresDostawcy. Nie jest to jednak pełna zależność funkcyjna, gdyż atrybut AdresDostawcy jest zależny także od podzbioru zbioru atrybutów {KodDostawcy, NazwaDostawcy}, a mianowicie od atrybutu KodDostawcy. A zatem w przypadku rozważanej zależności funkcyjnej mamy do czynienia z zależnością częściową DEFINICJA. Wyznacznikiem nazywamy atrybut lub zbiór atrybutów, od których w pełni zależy funkcyjnie inny atrybut. 12. Druga postać normalna Relacja jest w drugiej postaci normalnej, jeśli jest w pierwszej postaci normalnej i każdy jej niekluczowy atrybut jest w pełni funkcyjnie zależny od klucza głównego tej relacji. 5

6 Bardziej ogólna definicja drugiej postaci normalnej ma następującą postać: Schemat relacyjny R = (U,F) jest w drugiej postaci normalnej, jeśli jest w pierwszej postaci normalnej i każdy niekluczowy atrybut A U jest w pełni funkcyjnie zależny od każdego klucza tego schematu. Jak wynika z powyższej definicji nie jest możliwy przypadek: W postępowaniu mającym na celu sprowadzenie relacji do drugiej postaci normalnej należy brać pod uwagę następujące fakty: relacja jest już w drugiej postaci normalnej, jeśli jej każdy klucz jest jednoelementowy, przeprowadzenie relacji do drugiej postaci normalnej nie jest procesem jednoznacznym, tzn. dla relacji może istnieć wiele równoważnych informacyjnie układów przekształcenia jej do drugiej postaci normalnej. 13. Przykład sprowadzania relacji do drugiej postaci normalnej PRZYKŁAD. Rozważmy następujący schemat relacyjny R = (U, F), gdzie U = {NRProdukt, NazwaProdukt, NazwaDostawcy, NazwaKategorii, NrTelefonDostawcy}, F = {NRP NP, NRP NK, NP NK, ND NTD}. Kluczem jest zbiór atrybutów K:= { NRP, ND }. Niech R będzie relacją o schemacie relacyjnym R = (U, F) określoną następująco: NRProduktu NazwaProduktu NazwaDostawcy NazwaKategorii NrTelefonDostawcy SL1005 Czekolada mleczna Goplana Słodycze NP0087 Piwo Okocim Browary Okocim Napoje RY0309 Szprot w oleju Korab Ryby SL1003 Czekolada deserowa Goplana Słodycze RY0299 Sałatka rybna Korab Ryby SL1004 Czekolada gorzka Goplana Słodycze Łatwo zauważyć, iż rozważany schemat relacyjny nie nie jest w drugiej postaci normalnej 2NP, ponieważ niekluczowy atrybut NrTelefonuDostawcy zależy tylko od pola NazwaDostawcy, a nie od całego klucza złożonego. Taka sytuacja jest źródłem redundancji, a ta z kolei może powodować kłopoty z utrzymaniem spójności bazy danych. Ponieważ dla każdej relacji R INST(R) mamy, iż R = R[ND, NTD] R[NRP, ND, NP, NK] 6

7 w ten sposób uzyskujemy dwa schematy relacyjne R 1 = ( { ND, NTD }, {ND NTD} ) oraz R 2 = ( { NRP, ND, NP, NK }, {NRP NP, NRP NK, NP NK} ) odpowiednio z kluczami { ND } i { NRP }. Jest to rozkład bez straty danych. A zatem dla rozważanej relacji lepszym rozwiązaniem jest jej rozbicie na dwie poniższe relacje NazwaDostawcy NrTelefonuDostawcy NrProduktu NazwaProduktu NazwaDostawcy NazwaKategorii Goplana Browary Okocim Korab SL1005 Czekolada mleczna Goplana Słodycze NP0087 Piwo Okocim Browary Okocim Napoje RY0309 Szprot w oleju Korab Ryby Obie relacje przedstawione powyżej są w 2PN. Logicznie chodzi o to, aby nie reprezentować dwóch różnych encji (Produkty i Dostawcy) w ramach jednej relacji. Rozdzielenie ich nie tylko eliminuje redundancję, ale również pozwala przechować informacje niemożliwe inaczej do zgromadzenia. W powyższym przykładzie informacje o dostawcach mogą być zapisywane jeszcze przed uzyskaniem jakichkolwiek danych dotyczących ich produktów. W poprzednim przykładzie byłoby to niemożliwe, gdyż żaden ze składników klucza głównego nie może być pusty. 14. Przypadki kłopotliwe Jeśli chodzi o fakt wykazania, czy rozważana relacja jest w drugiej postaci normalnej, to pewne problemy może stwarzać odpowiednie zrozumienie ograniczeń, z jakimi mamy do czynienia w modelowanym fragmencie rzeczywistości. Otóż taką kłopotliwą sytuacją bywa mylenie ograniczeń, które mogą istnieć w danym momencie, z tymi, które będą obowiązywać zawsze. PRZYKŁAD. Rozważmy relację i postarajmy stwierdzić, czy jest w drugiej postaci normalnej. KodDostawcy Adres Miasto KodPocztowy 1 Warszawska 6 Warszawa Tyska 14 Okocim Lipowa 2 Ustka Relacja pokazana na powyższym rysunku zakłada, że dostawca może mieć tylko jeden adres, co może być prawdą na dzień dzisiejszy, ale niekoniecznie musi obowiązywać w przyszłości. 15. Zależność tranzytywna (przechodnia) DEFINICJA. Zbiór atrybutów Z jest tranzytywnie zależny od zbioru atrybutów X w schemacie relacyjnym R = (U, F), jeśli: X Z =, ( Y U) { (X Y = Z Y = ) [( X Y ) F + ( Y X ) F + ( Y Z) F + ] }. (X Y ) F + (Y X) F + (Y Z) F + 7

8 UWAGA. Założenie o rozłączności zbiorów atrybutów X, Y i Z jest istotne i nie można go pominąć. Gdyby je pominąć, to przykładowo dla zbiorów atrybutów X, Y i Z takich, iż Z Y X istniałyby zależności funkcyjne X Y, Y Z, X Z, a zatem zależność tranzytywna istniałaby automatycznie pomiędzy dowolną parą takich zbiorów, co nie jest zbyt interesującym przypadkiem. Zależność tranzytywną można również określić następująco: DEFINICJA. Jeśli X, Y, Z są zbiorami atrybutów relacji, takimi, że X Y, Y Z, to mówimy, że zbiór Z jest tranzytywnie zależny od X poprzez Y, pod warunkiem, że zbiór X nie jest funkcyjnie zależny od zbioru Y lub zbioru Z. 16. Trzecia postać normalna Relacja jest w trzeciej postaci normalnej, jeśli jest w drugiej postaci normalnej i żaden jej niekluczowy atrybut nie jest tranzytywnie zależny od klucza głównego tej relacji. Bardziej ogólna definicja trzeciej postaci normalnej ma następującą postać: Schemat relacyjny R = (U, F) jest w trzeciej postaci normalnej, jeśli jest w drugiej postaci normalnej i żaden zbiór atrybutów niekluczowych nie jest tranzytywnie zależny od żadnego klucza schematu R. A zatem w pewnym uproszczeniu można by powiedzieć, że: Relacja jest w trzeciej postaci normalnej, jeśli jest w drugiej postaci normalnej, a ponadto wszystkie atrybuty niekluczowe są wzajemnie niezależne. UWAGA. W każdym schemacie relacyjnym będącym w 3PN między atrybutami niekluczowymi nie ma zależności funkcyjnych. 17. Przykład relacji, która nie jest w trzeciej postaci normalnej Przykład. Weźmy jako przykład firmę, która ma tylko jednego sprzedawcę w danym województwie. Rozważmy schemat relacyjny R =(U, F), gdzie U = {NrZamówienia, KodKlienta, Województwo, Sprzedawca } F = { W S, NZ KK, KK W, S NZ, NZ W } z kluczem K: = { NZ }. Niech R będzie relacją o schemacie R := (U, F) określoną następująco: NrZamówienia KodKlienta Województwo Sprzedawca KR003 Łódzkie Nowak Jan KR003 Łódzkie Nowak Jan BS145 Małopolskie Klimczyk Janina Ponieważ S NZ NZ W, to S W, tzn. zbiór { W } jest funkcyjnie zależny od zbioru { S }. W relacji pokazanej na powyższym rysunku istnieje zależność między atrybutami Województwo i Sprzedawca, zaś żaden z nich nie jest sensownym kluczem kandydującym tej relacji. A zatem relacja nie jest w trzeciej postaci normalnej. Dla każdej relacji R INST(R) mamy R = R[NZ, KK] R[KK, W] R[S, W] tzn. uzyskaliśmy trzy schematy relacyjne będące w 3PN R 1 := ({ NZ, KK }, { NZ KK }), R 2 = ({ KK, W }, { KK W }), R 3 = ({ S, W }, {W S, S W }) Jest to rozkład bez straty danych. 8

9 18. Przypadki kłopotliwe PRZYKŁAD. Rozważmy następującą relację i odpowiedzmy na pytanie, czy jest ona w trzeciej postaci normalnej? NazwaFirmy Adres Miasto Województwo KodPocztowy Trasco Warszawska 6 Warszawa Mazowieckie Retrex Toruńska 14 Bydgoszcz Kujawsko-Pomorskie Korab Lipowa 2 Ustka Zachodniopomorskie W większości przypadków wartość pola KodPocztowy oparta jest na wartościach pól Miejscowość i Województwo. A zatem relacja pokazana na powyższym rysunku nie jest ściśle biorąc w trzeciej postaci normalnej. Poniżej pokazane są dwie relacje, które są już w trzeciej postaci normalnej. NazwaFirmy Adres Miasto Województwo Trasco Warszawska 6 Warszawa Mazowieckie Retrex Toruńska 14 Bydgoszcz Kujawsko-Pomorskie Korab Lipowa 2 Ustka Zachodniopomorskie Miasto Województwo KodPocztowy Warszawa Mazowieckie Bydgoszcz Kujawsko-Pomorskie Ustka Zachodniopomorskie Te dwie relacje są już technicznie bardziej poprawne, ale w rzeczywistości jedyną płynącą z tego korzyścią jest możliwość automatycznego wyszukiwania kodu pocztowego w momencie wprowadzania nowych rekordów. W ten sposób użytkownik zaoszczędza kilka uderzeń w klawisze przy wprowadzaniu nowych rekordów. Oczywiście ma to znaczenie, jeśli chodzi o pracę użytkownika, ale są dużo lepsze sposoby zaimplementowania tego typu funkcjonalności takie, które nie powodują dodatkowego sprzęgania relacji przy każdym odwołaniu do adresu. UWAGA: To wyłącznie od semantyki modelu zależy, w jaki sposób i kiedy należy implementować trzecią postać normalną. Przypadek tworzenia oddzielnych relacji powinien mieć miejsce tylko wtedy, gdy dana encja jest istotna dla modelu, gdy dane często zmieniają się lub gdy ma to zalety natury technicznej. Kody pocztowe zmieniają się, ale dość rzadko i nie są najistotniejsze dla większości systemów. 19. Wady trzeciej postaci normalnej Trzecia postać normalna nie wyklucza przypadku relacji, w której atrybuty kluczowe mogą być zależne funkcyjnie: pomiędzy sobą, od atrybutów niekluczowych, od części pewnego klucza, do którego nie należą. Dlatego też w trzeciej postaci normalnej może istnieć niepełna i tranzytywna zależność atrybutów kluczowych, która może być źródłem redundancji, a w konsekwencji pewnych anomalii. 20. Postać normalna Boyce a-codda Schemat relacyjny R = (U, F) jest w postaci normalnej Boyce a-codda wtedy i tylko wtedy, gdy z istnienia zależności funkcyjnej X Y F + dla Y U X wynika, że X U F +. Jak wynika z powyższej definicji, schemat relacyjny jest w postaci normalnej Boyce a-codda, jeśli od zbioru atrybutów X jest funkcyjnie zależny jakikolwiek atrybut rozłączny z X, to od X są zależne funkcyjnie wszystkie inne 9

10 atrybuty w tym schemacie. Stąd wynika, iż wszystkie zależności funkcyjne w schemacie relacyjnym będącym w postaci normalnej Boyce a-codda są determinowane przez klucze. Inaczej można powiedzieć, iż relacja jest w postaci normalnej Boyce a-codda, jeśli każdy wyznacznik jej zależności funkcyjnej jest kluczem w tej relacji. Jak wynika z tej definicji, aby sprawdzić, czy rozważana relacja jest w postaci normalnej Boyce a-codda należy znaleźć wszystkie wyznaczniki zależności i sprawdzić, czy są one kluczami kandydującymi. Postać normalna Boyce a/codda, traktowana jako odmiana trzeciej postaci normalnej, dotyczy szczególnego rodzaju relacji z wieloma kluczami kandydującymi. W praktyce, aby móc zastosować postać normalną Boyce a/codda, muszą być spełnione następujące warunki: relacja musi mieć co najmniej dwa klucze kandydujące, co najmniej dwa klucze kandydujące muszą być kluczami złożonymi, klucze kandydujące muszą mieć wspólne atrybuty. Różnica pomiędzy trzecią postacią normalną a postacią normalną Boyce a-codda polega na tym, iż zależność funkcyjna X Y jest dopuszczalna w trzeciej postaci normalnej, o ile Y jest atrybutem klucza głównego oraz X nie jest kluczem kandydującym. Natomiast postać normalna Boyce a-codda dopuszcza taką zależność, wtedy gdy atrybut X jest kluczem kandydującym. W ten sposób postać normalna Boyce a-codda jest silniejsza niż trzecia postać normalna. 21. Przykład relacji w trzeciej postaci normalnej, która nie jest w postaci Boyce a/codda PRZYKŁAD. Rozważmy schemat relacyjny R = (U, F), gdzie U = {KodDostawcy, NazwaDostawcy, NRProduktu, NazwaProduktu, CenaJednostkowa} F = { KD ND, KD NRP, {ND, NRP} KD, NRP NP, NRP CJ } Niech R będzie relacją o schemacie relacyjnym R = (U, F), która została zaprezentowana na poniższym rysunku KodDostawcy NazwaDostawcy NrProduktu NazwaProduktu CenaJednostkowa 1 Goplana 15 Czekolada mleczna 2,10 zł 2 Browary Okocim 63 Piwo Okocim 2,50 zł 3 Korab 42 Szprot w oleju 3,10 zł Ponieważ postać normalna Boyce a/codda określa przede wszystkim, że nie mogą istnieć zależności funkcjonalne między kluczami kandydującymi, musimy zidentyfikować wszystkie klucze kandydujące relacji. Powyższa relacja ma następujące klucze kandydujące: {KD, NRP}, {KD, NP}, {ND, NRP}, {ND, NP}. Nietrudno zauważyć, iż istnieje zależność funkcyjna {KD} {ND}, co jest niedopuszczalne w postaci normalnej Boyce a/codda. A zatem rozważany schemat relacyjny nie jest w PNB-C. 22. Przekształcenie relacji w trzeciej postaci normalnej do postaci Boyce a/codda Relacja z przykładu zostanie teraz przekształcona do postaci normalnej Boyce a/codda. W wyniku tego powstaną dwie relacje Dostawcy i Produkty, które są już w postaci normalnej Boyce a/codda. Dostawcy KodDostawcy NazwaDostawcy 1 Goplana 2 Browary Okocim 3 Korab Produkty KodDostawcy NrProduktu NazwaProduktu CenaJednostkowa 1 15 Czekolada mleczna 2,10 zł 2 63 Piwo Okocim 2,50 zł 3 42 Szprot w oleju 3,10 zł 10

11 23. Zależność wielowartościowa Definicja. Niech dana będzie relacja R(U), X, Y U i Z: = U XY. Mówimy, że w R spełniona jest zależność wielowartościowa X >> Y, gdy spełniony jest jeden z równoważnych warunków: a) ( x R[X])( y, y R[Y])( z,z R[Z]) {[(x y z R) (x y z R)] [(x y z R) (x y z R)] } b) R = R[XY] R[XZ] Uwaga. Każda zależność funkcyjna X Y F + jest zależnością wielowartościową, tzn. mamy X >> Y. Spełniony jest warunek konieczny rozkładu bez straty danych (punkt b). Uwaga. Zależności X >> U i X >> spełnione są w każdej relacji R(U). Istotnie, mamy R = R[XY] R[XZ], gdzie Z =, Y = U, R = R[XY] R[XZ], gdzie Z = U X, Y = Nazywamy je trywialnymi zależnościami wielowartościowymi. 24. Przykład zależności wielowartościowych, które nie są zależnościami funkcyjnymi PRZYKŁAD. Rozważmy jako relację R relację PracownikDzieckoZarobki: R: Pracownik ImieDziecka Zarobki Rok Nowak Marek Nowak Marta Nowak Marek Nowak Marta Kowalski Michał Kowalski Michał W powyższym przykładzie zakładamy, że atrybut Pracownik jednoznacznie identyfikuje pracownika oraz atrybut ImieDziecka jednoznacznie identyfikuje dziecko pracownika. Widać, iż wymienieni pracownicy pracowali w określonych latach. Ze względu na brak bezpośredniego związku pomiędzy dziećmi pracownika a latami jego pracy oraz zarobkami, w celu zapewnienia spójności relacji musimy utworzyć oddzielną krotkę dla każdej kombinacji dziecka pracownika oraz jego zarobkami i rokiem. To połączenie przedstawia zależność wielowartościową w relacji PracownikDzieckoZarobki. Mówiąc inaczej, bezpośrednią przyczyną pojawienia się zależności wielowartościowej w tej relacji jest występowanie w niej dwóch niezależnych związków jeden do wielu. Nietrudno zauważyć, iż zależnościami wielowartościowymi spełnionymi w rozważanej relacji są P >> ID i P >> ZR. Istotnie, w relacji R z każdą wartością, np. Nowak, atrybutu P jest związany pewien, jednoznacznie określony i niezależny od kontekstu, zbiór wartości atrybutu ID w rozważanym przypadku (Marek, Marta). Niezależny od kontekstu oznacza, iż każda z wartości tego zbioru występuje w pewnej krotce zarówno z kombinacją (Nowak, 2400, 2007), jak i z kombinacją (Nowak, 2700, 2008) wartości atrybutów {P, Z, R}, jak ma to miejsce w przypadku drugiej z wymienionych zależności wielowartościowych. Zauważmy, iż uwzględnienie zależności wielowartościowej P >> ID jako podstawy rozkładu relacji R, prowadzi do dwóch projekcji 11

12 Nietrudno zauważyć, iż w powyższych relacjach występują zależności funkcyjne: 25. Czwarta postać normalna w R 1 : ID P, zaś w R 2 : PR Z. Czwarta postać normalna stanowi teoretyczną podstawę reguły, która intuicyjnie jest dość oczywista: niezależne powtarzające się grupy nie powinny występować w tej samej relacji. Załóżmy np., że produkty sprzedawane przez firmę TMarket pod własną marką pochodzą od różnych dostawców, mają różnej wielkości opakowania i każdy z dostawców ma w ofercie wszystkie wielkości opakowań. Zupełnie nieznormalizowana wersja relacji Produkty dla takiej firmy mogłaby wyglądać jak na poniższym rysunku: NazwaProduktu NazwaDostawcy WielkośćOpakowania Fasola Jaś Agrotex ¼ kg, ½ kg, 1 kg Rodzynki sułtańskie Bartex ¼ kg, ½ kg, 1 kg Ser półtłusty Mlekovita ¼ kg, ½ kg, 1 kg Relacja nieznormalizowana 26. Sprowadzanie relacji do czwartej postaci normalnej Pierwszym krokiem w normalizowaniu rozważanej relacji jest wyeliminowanie nieskalarnego atrybutu WielkośćOpakowania. Poprawiona w ten sposób relacja pokazana jest na poniższym rysunku. NazwaProduktu NazwaDostawcy WielkośćOpakowania Fasola Jaś Agrotex ¼ kg Fasola Jaś Agrotex ½ kg Fasola Jaś Agrotex 1 kg Rodzynki sułtańskie Bartex ¼ kg Rodzynki sułtańskie Bartex ½ kg Rodzynki sułtańskie Bartex 1 kg Ser półtłusty Mlekovita ¼ kg Ser półtłusty Mlekovita ½ kg Ser półtłusty Mlekovita 1 kg Relacja w postaci Boyce a/codda Zaskakujące, ale relacja z powyższego rysunku jest w postaci normalnej Boyce a/codda, gdyż cała jest kluczem. Widać w niej jednak wyraźnie obecność redundancji, a pilnowanie integralności danych może być utrapieniem. Rozwiązanie tych problemów leży w koncepcji par zależności wielowartościowych i w czwartej postaci normalnej. Para zależności wielowartościowych to dwa wzajemnie niezależne zbiory atrybutów. Na powyższym rysunku widoczną zależnością wielowartościową jest {NazwaProduktu} {WielkośćOpakowania} {NazwaDostawcy}, co należy czytać Produkt określa wiele rozmiarów opakowań i dostawców. Czwarta postać normalna mówi, nieformalnie, że zależności wielowartościowe muszą być rozbite na oddzielne relacje, jak to jest pokazane na poniższym rysunku. NazwaProduktu Fasola Jaś Fasola Jaś Fasola Jaś Rodzynki sułtańskie Rodzynki sułtańskie Rodzynki sułtańskie Ser półtłusty Ser półtłusty Ser półtłusty WielkośćOpakowania ¼ kg ½ kg 1 kg ¼ kg ½ kg 1 kg ¼ kg ½ kg 1 kg NazwaProduktu Fasola Jaś Rodzynki sułtańskie Ser półtłusty NazwaDostawcy Agrotex Bartex Mlekovita 12

13 Jak wynika z przykładu relacje zawierające wielowartościowe zależności powinny być dekomponowane w celu ich sprowadzenia do czwartej postaci normalnej. 27. Piąta postać normalna Piąta postać normalna ma zastosowanie tylko w wyjątkowo rzadkich przypadkach zależności sprzężeń. Zależność sprzężeń określa więzy o charakterze cyklicznym: Jeśli encja1 jest sprzężona z encją2, encja2 jest sprzężona z encją3, a encja3 jest sprzężona z encją1, to wszystkie trzy encje muszą obowiązkowo występować w tej samej krotce Mówiąc językiem bardziej zrozumiałym, jeśli {Dostawca} dostarcza {Produkt}, {Klient} zamawia ten {Produkt} i {Dostawca} dostarcza coś {Klientowi}, to {Dostawca} dostarcza ten {Produkt} {Klientowi}. W świecie rzeczywistym nie jest to jednak poprawne wnioskowanie. {Dostawca} może dostarczać {Klientowi} cokolwiek nie musi to być koniecznie {Produkt}. Zależność sprzężeń istnieje tylko wtedy, gdy obowiązuje dodatkowy warunek mówiący o tym, ze podane wnioskowanie jest poprawne. W takiej sytuacji nie wystarczy użyć pojedynczej relacji o atrybutach {Dostawca, Produkt, Klient}, gdyż spowodowałoby to problemy z aktualizacją. Dostawca Produkt Klient Agrotex Groszek zielony Nowak Jan Bartex Rodzynki sułtańskie Krysiak Marek Istotnie, np. wstawienie do relacji pokazanej na powyższym rysunku krotki { Krakus, Groszek zielony, Krysiak Marek } wymagałoby wstawienia dodatkowej krotki { Agrotex, Groszek zielony, Krysiak Marek }, gdyż w modelu pojawiłoby się nowe sprzężenie - Groszek zielony z Krysiak Marek. Dekompozycja relacji na trzy oddzielne relacje (DostawcaProdukt, ProduktKlient i DostawcaKlient) eliminuje ten problem, ale powoduje z kolei inny: w celu odtworzenia oryginalnej relacji konieczne staje się sprzężenie wszystkich trzech relacji składowych. Próba sprzężenia tylko dwóch z nich spowoduje uzyskanie niepoprawnej informacji. Z punktu widzenia projektanta systemu jest to sytuacja zatrważająca, gdyż nie istnieje żadna samoistna metoda wymuszenia sprzężenia trzech tabel oprócz nałożenia zabezpieczeń. Co więcej, jeśli użytkownik będzie zmuszony w jakiejś sytuacji utworzyć tymczasowy zbiór wynikowy, będzie się on wydawał całkiem sensowny i jest mało prawdopodobne, aby patrząc na niego użytkownik zdołał wykryć błąd. Na szczęście cykliczna zależność sprzężeń występuje tak rzadko, że w większości przypadków tego typu niebezpieczeństwa można spokojnie ignorować. 28. Ilustracja graficzna zależności między postaciami normalnymi 1PN 2PN 3PN B-C 4PN 5PN 13