Zależność funkcyjną, której prawa strona zawiera kilka atrybutów

można zastąpić zbiorem zależności o pojedynczych prawych stronach

Operacja ta jest oczywiście odwracalna.

Przykład: A→B⁢C można zastąpić przez A→B i A→C.

Uwaga:Nie wolno rozbijać lewych stron zależności!

Jeśli w przykładowym ZOO każdy zwierzak nazywa się inaczej, to dla relacji Zwierz(imie,gatunek,waga,wiek) zachodzi zależność: imie → gatunek

Jeśli przyjęto (raczej naturalną) zasadę ,,Żadne dwa wykłady nie odbywają się o tej samej godzinie w tej samej sali”, to mamy zależność funkcyjną godzina sala → wykład

Jak określa się zależności dla danej relacji? Jedynie przez odpytanie użytkowników.

Nie należy natomiast liczyć na to, że wykryjemy je na podstawie zawartości tabeli w bazie danych. W takiej tabeli może być pozornie spełniona pewna zależność, która przestanie zachodzić za pięć minut (po dodaniu do tabeli nowych wierszy)! W ten sposób można jedynie upewnić się, że podana zależność nie zachodzi.

Skąd się biorą klucze? Na ogół są wyznaczane z zależności funkcyjnych.

Czasem jednak otrzymane w ten sposób klucze obejmują zbyt wiele kolumn, co jest w praktyce niewygodne. Wprowadza się wtedy arbitralnie tzw. klucze sztuczne), dodając do relacji R nowy atrybut K⁢S jako klucz. Oznacza to nałożenie dodatkowej zależności funkcyjnej

gdzie A1,A2,…,An są atrybutami relacji R

Pewne zależności można wyprowadzić z innych. Przykład: jeśli zachodzi

i zachodzi

to musi zachodzić

Można to sprawdzić z definicji. Inny sposób to skorzystać z reguł wnioskowania Armstronga.

Jeśli U⊆V+, to zachodzi zależność funkcyjna V→U. Klucz jest to więc taki minimalny zbiór atrybutów, że jego domknięcie jest zbiorem wszystkich atrybutów relacji.

Dla przykładu policzymy domknięcie atrybutu A z naszego przykładu

1. Krok bazowy: A+ := A

2. Indukcja: ponieważ A→B i A⊆A+, to A+ := A+∪B = A⁢B

3. Indukcja: ponieważ B→C i B⊆A+, to A+ := A+∪C = A⁢B⁢C

Wniosek: ponieważ C⊆A+, więc zachodzi A→C.

Spróbujmy innego przykładu. Dla zbioru zależności

domknięciem A,B+ jest A,B,C,D,E, ponieważ

Reguły wnioskowania Armstronga służą do wyprowadzania zależności z innych zależności.

Jeden z celów, który staramy się osiągnąć podczas projektowania schematu bazy danych to unikanie redundancji (nadmiarowości). Redundancja oznacza, że niektóre informacje są zapisane w bazie danych wielokrotnie. Prowadzi to do anomalii podczas modyfikacji i usuwania

• Anomalia modyfikacji: informacja zostaje uaktualniona tylko w niektórych miejscach

  • Przykład: zmiana adresu studenta na nowy, jeśli informacja o studencie i jego adresie trzymana jest w kilku miejscach.

• Anomalia usuwania: wraz z usunięciem ostatniego wiersza szczegółowego znika informacja ogólna

  • Gdyby informacje o adresie studenta trzymać przy przedmiotach, na które jest zarejestrowany, to po zakończeniu sesji (a przed nową rejestracją) adres ten by zniknął.

Obejrzyjmy przykład złego projektu i jego konsekwencje. Przypuśćmy, że mamy relację Zwierzaki(gatunek,imie,waga,kontynent) z następującymi zależnościami

Przykładowa zawartość takiej relacji

Występuje redundancja, ponieważ wartości dla ??? można łatwo odgadnąć (czy jak kto woli wyznaczyć) na podstawie zależności.

Dotychczas formalnie zdefiniowano pięć (poziomów) postaci normalnych, choć tylko trzy pierwsze są powszechnie używane podczas projektowania baz danych.

Postacie normalne są ponumerowane kolejno, ale istnieje postać pośrednia BCNF między 3 i 4 poziomem. Postacie o wyższych numerach automatycznie (z definicji) spełniają warunki dla niższych postaci, dlatego relacja w drugiej postaci normalnej jest automatycznie w pierwszej postaci normalnej.

Odwrotne wynikanie oczywiście nie zachodzi; drugą postać normalną otrzymujemy z pierwszej po nałożeniu dodatkowego warunku.

Proces normalizacji polega na dekompozycji tabel aż do otrzymania pożądanej postaci.

Warunkiem pierwszej postaci normalnej jest to, by każdy atrybut w relacji przyjmował tylko wartości niepodzielne. Przez wartości niepodzielne rozumiemy takie pojedyncze wartości, jak używane w atrybutach ,,numer klienta” czy ,,nazwisko klienta”.

Relacja w pierwszej postaci normalnej nie może zawierać atrybutu, w którym można upakować kilka wartości, np. odddzielając je przecinkami.

Daty można traktować jako wartości niepodzielne lub tworzyć oddzielne atrybuty dla dnia, miesiąca i roku.

Aby stwierdzić, czy relacja będąca w pierwszej postaci normalnej jest także w drugiej, należy określić klucze relacji.

Każdej wartości klucza powinien jednoznacznie odpowiadać pojedynczy wiersz w tabeli. Na przykład dla relacji Zamówienie_klienta kluczem może być numer_zamówienia.

Warunkiem na drugą postać normalną jest to, aby każdy niekluczowy atrybut zależał funkcyjnie od całego klucza. Niedozwolone są więc tzw. zależności częściowe.

Uwaga: przypominamy, że kluczy może być kilka!

Dla sprawdzenia, czy relacja będąca w drugiej postaci normalnej jest także w trzeciej, bada się zależności między atrybutami niekluczowymi.

Atrybuty niekluczowe powinny zależeć funkcyjnie wyłącznie od klucza i niczego więcej. Wykluczamy w ten sposób zależności przechodnie.

Bardziej restrykcyjna niż trzecia postać normalna jest postać normalna Boyce-Codda, lecz jest ona rzadziej wykorzystywana w aplikacjach komercyjnych.

Relacja R jest w tej postaci, jeśli jest w 1NF oraz dla każdej nietrywialnej zależności X→Y zachodzącej w R, lewa strona zależności X jest nadkluczem.

W odróżnieniu od 3NF sprowadzenie do BCNF nie gwarantuje zachowania zależności funkcyjnych przy rozkładzie.

Popatrzmy na inną definicję 3NF, lepiej pokazującą różnicę między nią a BCNF.

Dekomponując relację R do BCNF pozbywamy się kolejno zależności naruszających ją. Przedtem należy zminimalizować zbiór zależności, ale pominiemy ten etap.

1. Dla relacji R wybierz ze zbioru zależności F zależność X→Y naruszającą BCNF (jeśli nie ma takiej, to relacja jest już w BCNF).

2. Oblicz X+

   • Będzie zawierać tylko część atrybutów R, bo inaczej X byłoby nadkluczem.

3. Zastąp R dwoma relacjami o schematach

   • R1=X+

   • R2=R-X+-X

4. Zrzutuj zbiór zależności F na nowe relacje.

5. Powtarzaj dopóki relacje nie będą w BCNF.

Czasem zależności powodują kłopoty przy przejściu do BCNF. Weźmy tabelę Gdzie(adres,miasto,kod-pocztowy) i dwie zależności

Mamy tu dwa klucze: {adres,miasto} oraz {adres,kod-pocztowy}. Ale zależność kod-pocztowy → miasto narusza postać BCNF, czyli musimy dokonać dekompozycji na dwie tabele

Popatrzmy jednak na poniższy (ciut złośliwy) przykład

Pozornie wszystko jest w porządku (żadna zależność nie jest naruszona), ale po złączeniu będzie już inaczej

Naruszona jest zależność adres miasto → kod-pocztowy.

Takie kłopotliwe układy zależności nie są rzadkie, popatrzmy na inny przykład zależności dla fikcyjnej sieci kin

Pierwsza z nich jest oczywista: każde kino znajduje się tylko w jednym mieście. Druga może wynikać z prowadzonej ,,polityki” wyświetlania, aby kina w tym samym mieście nie konkurowały ze sobą filmami. Skutek jest taki sam jak poprzednio.

W większości baz danych wystarcza dekompozycja do trzeciej postaci normalnej. Mogą jednak czasem występować anomalie wstawiania, powodowane zależnością wielowartościową.

Będzie tak między innymi wtedy, gdy pewne dwa niekluczowe atrybuty przyjmują dla każdej wartości innego atrybutu tylko po kilka wybranych wartości, niezależnie od innych atrybutów.

Na przykład na seminariach korzysta się z kilku książek. Każde seminarium ma tylko jedną nazwę, ale może mieć kilku prowadzących. Należy wówczas dokonać dekompozycji na dwie osobne relacje: prowadzący seminaria oraz teksty do seminariów, w przeciwnym razie wypadałoby umieścić w relacji dla danego seminarium wszystkie kombinacje prowadzących i książek.