Normalizacja schematów relacji

Podobne dokumenty
Normalizacja. Pojęcie klucza. Cel normalizacji

PLAN WYKŁADU BAZY DANYCH ZALEŻNOŚCI FUNKCYJNE

Systemy baz danych. Notatki z wykładu

Pojęcie zależności funkcyjnej

Cel normalizacji. Tadeusz Pankowski

Normalizacja baz danych

BAZY DANYCH. Anomalie. Rozkład relacji i normalizacja. Wady redundancji

Pierwsza postać normalna

Jak wiernie odzwierciedlić świat i zachować występujące w nim zależności? Jak implementacja fizyczna zmienia model logiczny?

030 PROJEKTOWANIE BAZ DANYCH. Prof. dr hab. Marek Wisła

BAZY DANYCH NORMALIZACJA BAZ DANYCH. Microsoft Access. Adrian Horzyk. Akademia Górniczo-Hutnicza

Definicja bazy danych TECHNOLOGIE BAZ DANYCH. System zarządzania bazą danych (SZBD) Oczekiwania wobec SZBD. Oczekiwania wobec SZBD c.d.

KaŜdemu atrybutowi A przyporządkowana jest dziedzina Dom(A), czyli zbiór dopuszczalnych wartości.

Projektowanie Systemów Informacyjnych

Wykład II Encja, atrybuty, klucze Związki encji. Opracowano na podstawie: Podstawowy Wykład z Systemów Baz Danych, J.D.Ullman, J.

Zależności funkcyjne

Normalizacja baz danych

Bazy danych. Andrzej Grzybowski. Instytut Fizyki, Uniwersytet Śląski

Normalizacja relacyjnych baz danych. Sebastian Ernst

Autor: Joanna Karwowska

Relacyjny model baz danych, model związków encji, normalizacje

BAZY DANYCH NORMALIZACJA BAZ DANYCH. Microsoft Access. Adrian Horzyk. Akademia Górniczo-Hutnicza

Bazy danych. Andrzej Łachwa, UJ, /15

Pierwsza postać normalna

Pożyczkobiorcy. Anomalia modyfikacji: Anomalia usuwania: Konta_pożyczkowe. Anomalia wstawiania: Przykłady anomalii. Pożyczki.

Związki pomiędzy tabelami

Normalizacja tabel POSTACIE NORMALNE TABEL

Normalizacja relacji

Technologia informacyjna

Relacyjne Bazy Danych Andrzej M. Borzyszkowski. Projekt bazy danych normalizacja. PJATK/ Gdańsk. Dwie metodologie. Formalne zasady projektowe

Plan wykładu. Problemy w bazie danych. Problemy w bazie danych BAZY DANYCH. Problemy w bazie danych Przykład sprowadzenia nieznormalizowanej SQL

Relacyjny model danych

Bazy danych 3. Normalizacja baz danych

Bazy danych 2. Zależności funkcyjne Normalizacja baz danych

Bazy Danych i Usługi Sieciowe

Wykład 2. Relacyjny model danych

Normalizacja schematów logicznych relacji

Zależności funkcyjne pierwotne i wtórne

Bazy danych. Algebra relacji

1 Wstęp do modelu relacyjnego

Technologie baz danych

Bazy danych Teoria projektowania relacyjnych baz danych. Wykła. Wykład dla studentów matematyki

Zależności funkcyjne c.d.

Baza danych. Baza danych to:

1 Przygotował: mgr inż. Maciej Lasota

Instytut Mechaniki i Inżynierii Obliczeniowej Wydział Mechaniczny technologiczny Politechnika Śląska

Projektowanie relacyjnych baz danych

Postać normalna Boyce-Codd (BCNF)

WYKŁAD 1. Wprowadzenie do problematyki baz danych

Bazy danych. Plan wykładu. Zależności funkcyjne. Wykład 2: Relacyjny model danych - zależności funkcyjne. Podstawy SQL.

Bazy danych 3. Normalizacja baz danych (c.d.)

Posługiwanie się tabelami

Systemy baz danych. mgr inż. Sylwia Glińska

Model relacyjny. Wykład II

BAZY DANYCH model relacyjny. Opracował: dr inż. Piotr Suchomski

Plan wykładu. Problemy w bazie danych. Problemy w bazie danych BAZY DANYCH

Relacyjne bazy danych. Normalizacja i problem nadmierności danych.

Bazy danych i usługi sieciowe

PODSTAWY BAZ DANYCH 2009/ / Notatki do wykładu "Podstawy baz danych"

domykanie relacji, relacja równoważności, rozkłady zbiorów

Projektowanie bazy danych przykład

Przykłady normalizacji

Tadeusz Pankowski Definicja. Definicja

Bazy danych. Andrzej Łachwa, UJ, /15

Literatura. Bazy danych s.1-1

Informatyka Ćwiczenie 10. Bazy danych. Strukturę bazy danych można określić w formie jak na rysunku 1. atrybuty

Uzupełnij pola tabeli zgodnie z przykładem poniżej,

Baza danych. Modele danych

Tworzenie bazy danych na przykładzie Access

Księgarnia PWN: Michael J. Hernandez Bazy danych dla zwykłych śmiertelników

PLAN WYKŁADU BAZY DANYCH MODEL DANYCH. Relacyjny model danych Struktury danych Operacje Integralność danych Algebra relacyjna HISTORIA

Technologia Informacyjna

Bazy danych 1. Wykład 5 Metodologia projektowania baz danych. (projektowanie logiczne)

Normalizacja schematu bazy danych. Radosław Fijołek Paweł Romanowski Paweł Trzos

Model relacyjny bazy danych

Algebra Boole a i jej zastosowania

WPROWADZENIE DO BAZ DANYCH

BAZY DANYCH algebra relacyjna. Opracował: dr inż. Piotr Suchomski

Krzysztof Kadowski. PL-E3579, PL-EA0312,

Dekompozycja w systemach wyszukiwania informacji

Bazy danych wykład trzeci. trzeci Modelowanie schematu bazy danych 1 / 40

INFORMATYKA GEODEZYJNO- KARTOGRAFICZNA Relacyjny model danych. Relacyjny model danych Struktury danych Operacje Oganiczenia integralnościowe

Podstawowe zagadnienia z zakresu baz danych

Bazy danych w sterowaniu

Podstawowe pakiety komputerowe wykorzystywane w zarządzaniu przedsiębiorstwem. dr Jakub Boratyński. pok. A38

Bazy danych. Plan wykładu. Podzapytania - wskazówki. Podzapytania po FROM. Wykład 5: Zalenoci wielowartociowe. Sprowadzanie do postaci normalnych.

Rozpatrzymy bardzo uproszczoną bazę danych o schemacie

BAZA DANYCH. Informatyka. ZESPÓŁ SZKÓŁ ELEKTRYCZNYCH Prowadzący: inż. Marek Genge

RBD Relacyjne Bazy Danych Więzy realcji

Matematyka dyskretna. Andrzej Łachwa, UJ, /10

Bazy danych. Zasady konstrukcji baz danych

Diagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji

Projektowanie baz danych

Metoda eliminacji Gaussa. Autorzy: Michał Góra

Modelowanie hierarchicznych struktur w relacyjnych bazach danych

Wykład 1. Na początku zajmować się będziemy zbiorem liczb całkowitych

2017/2018 WGGiOS AGH. LibreOffice Base

Autor: Joanna Karwowska

Programowanie dynamiczne

77. Modelowanie bazy danych rodzaje połączeń relacyjnych, pojęcie klucza obcego.

Transkrypt:

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 12 602-031-09 Rzodkiewka 1,40 zł Marczak Michał Łódzka 12 602-031-09 Groszek zielony 8,20 zł Krysiak Jerzy Zielona 2 602-099-22 Śmietana 18% 3,10 zł Krysiak Jerzy Zielona 2 602-031-09 Masło śmietankowe 3,20 zł Marczak Michał Łódzka 12 602-099-22 Fasolka żółta 9,30 zł Pasikowski Jan Poznańska 3 603-345-17 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 0102 2003/04/02 2003/04/08 CATCU Lipowa 5 Wrocław 65-127 0109 2003/04/28 2003/04/30 Mar-Trans Łódzka 3 Toruń 91-023 0110 2003/05/07 2003/05/12 Krakus Kraka 7 Kraków 02-342 0114 2003/05/29 2003/06/04 CATCU Lipowa 5 Wrocław 65-127 Rysunek. Relacja nieznormalizowana 1

4. Bezstratna dekompozycja Relacja Faktury NrZamówienia KodKlienta DataZamówienia DataWymagana 0102 010 2003/04/02 2003/04/08 0109 019 2003/04/28 2003/04/30 0110 031 2003/05/07 2003/05/12 0114 010 2003/05/29 2003/06/04 Relacja Klienci KodKlienta NazwaFirmy Adres Miasto KodPocztowy 010 CATCU ul. Lipowa 5 Wrocław 65-127 019 Mar-Trans ul. Łódzka 3 Toruń 91-023 031 Krakus ul. Kraka 7 Kraków 02-342 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

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 0102 2009/05/02 3 barszczyk czerwony, 1 flaki, 4 kotlet schabowy, 4 herbata 108,30 zł 0109 2009/05/06 4 pizza klasyczna, 4 pepsi 89,60 zł 0110 2009/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 SYG0010509 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

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 0102 2009/05/02 barszczyk czerwony flaki kotlet schabowy herbata 0109 2009/05/06 pizza klasyczna pepsi 0110 2009/05/12 zupa grzybowa befsztyk kawa lody czekoladowe 3 1 4 4 4 4 2 2 2 2 16,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 0102 2009/05/02 barszczyk czerwony 3 16,20 zł 0102 2009/05/02 flaki 1 9,30 zł 0102 2009/05/02 kotlet schabowy 4 68,00 zł 0102 2009/05/02 herbata 4 14,80 zł 0109 2009/05/06 pizza klasyczna 4 74,60 zł 0109 2009/05/06 pepsi 4 14,00 zł 0110 2009/05/12 zupa grzybowa 2 15,40 zł 0110 2009/05/12 befsztyk 2 36,40 zł 0110 2009/05/12 kawa 2 12,80 zł 0110 2009/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

Relacje w pierwszej postaci normalnej po zastosowaniu techniki dekompozycji Nr_zamówienia Data_zamówienia 0102 2009/05/02 0102 2009/05/02 0102 2009/05/02 0102 2009/05/02 0109 2009/05/06 0109 2009/05/06 0110 2009/05/12 0110 2009/05/12 0110 2009/05/12 0110 2009/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

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 165-23-87 NP0087 Piwo Okocim Browary Okocim Napoje 54-09-12 RY0309 Szprot w oleju Korab Ryby 87-09-34 SL1003 Czekolada deserowa Goplana Słodycze 165-23-87 RY0299 Sałatka rybna Korab Ryby 87-09-34 SL1004 Czekolada gorzka Goplana Słodycze 165-23-87 Ł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

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 165-23-87 Browary Okocim 54-09-12 Korab 87-09-34 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 00-994 2 Tyska 14 Okocim 12-654 3 Lipowa 2 Ustka 32-987 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

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 10102 KR003 Łódzkie Nowak Jan 10109 KR003 Łódzkie Nowak Jan 10110 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

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 00-994 Retrex Toruńska 14 Bydgoszcz Kujawsko-Pomorskie 12-654 Korab Lipowa 2 Ustka Zachodniopomorskie 32-987 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 00-994 Bydgoszcz Kujawsko-Pomorskie 12-654 Ustka Zachodniopomorskie 32-987 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

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

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 2400 2007 Nowak Marta 2400 2007 Nowak Marek 2700 2008 Nowak Marta 2700 2008 Kowalski Michał 2500 2007 Kowalski Michał 2900 2008 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

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

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