Bazy danych 3. Normalizacja baz danych



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

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

Bazy danych 3. Zależności funkcyjne Normalizacja relacyjnych baz danych

Normalizacja. Pojęcie klucza. Cel normalizacji

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

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

Pojęcie zależności funkcyjnej

Cel normalizacji. Tadeusz Pankowski

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

Normalizacja relacyjnych baz danych. Sebastian Ernst

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

Bazy danych. Andrzej Łachwa, UJ, /15

Systemy baz danych. Notatki z wykładu

Technologie baz danych

Projektowanie relacyjnych baz danych

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

Projektowanie Systemów Informacyjnych

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

Bazy Danych i Usługi Sieciowe

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

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

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

Zależności funkcyjne

WYKŁAD 1. Wprowadzenie do problematyki baz danych

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

Pierwsza postać normalna

Zależności funkcyjne pierwotne i wtórne

Bazy danych 2. Algebra relacji Zależności funkcyjne

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

Normalizacja baz danych

1 Przygotował: mgr inż. Maciej Lasota

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

Autor: Joanna Karwowska

Bazy danych 6. Przykłady

Bazy danych i usługi sieciowe

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

Normalizacja schematów logicznych relacji

Związki pomiędzy tabelami

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

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

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

Projektowanie baz danych

Bazy danych Wykład zerowy. P. F. Góra

Zależności funkcyjne c.d.

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

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

Pierwsza postać normalna

Baza danych. Modele danych

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

Technologia informacyjna

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

Bazy Danych i Usługi Sieciowe

Normalizacja baz danych

Baza danych. Baza danych to:

Wykład 2. Relacyjny model danych

Bazy danych TERMINOLOGIA

Wstęp do metod numerycznych Eliminacja Gaussa Równania macierzowe. P. F. Góra

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

Microsoft Access materiały pomocnicze do ćwiczeń cz. 1

Normalizacja Projektowanie Diagramy encji. Bazy Danych i Systemy informacyjne Wykład 7. Piotr Syga

Bazy danych. Andrzej Łachwa, UJ, /15

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

Postać normalna Boyce-Codd (BCNF)

Relacyjny model danych

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

Normalizacja relacji

Program wykładu. zastosowanie w aplikacjach i PL/SQL;

MS Access Projektowanie c.d. i kwerendy

WPROWADZENIE DO BAZ DANYCH

Zadanie 1. Suma silni (11 pkt)

Projektowanie bazy danych przykład

Program nauczania. Systemy baz danych. technik informatyk

Tadeusz Pankowski Definicja. Definicja

Hurtownie danych a transakcyjne bazy danych

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

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

BAZY DANYCH model związków encji. Opracował: dr inż. Piotr Suchomski

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

Konstruowanie Baz Danych Wprowadzenie do projektowania. Normalizacja

Bazy danych. Zasady konstrukcji baz danych

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

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

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

Bazy danych wykład trzeci. trzeci Przekształcenie modelu ER na model relacyjny 1 / 19

Podstawowe pojęcia dotyczące relacyjnych baz danych. mgr inż. Krzysztof Szałajko

Transformacja modelu ER do modelu relacyjnego

S y s t e m y. B a z D a n y c h

Wstęp 5 Rozdział 1. Podstawy relacyjnych baz danych 9

Technologia Informacyjna

Bazy Danych. Projektowanie. Normalizacja. Krzysztof Regulski WIMiIP, KISiM, B5, pok. 408

Normalizacja tabel POSTACIE NORMALNE TABEL

Krzysztof Kadowski. PL-E3579, PL-EA0312,

Bazy danych 11. Algorytmy złaczeń. P. F. Góra

Projektowanie hurtowni danych i modelowanie wielowymiarowe

Bazy danych 6. Klucze obce. P. F. Góra

Dazy Banych. Michał Rusnarczyk

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

SIMR 2016/2017, Analiza 2, wykład 1, Przestrzeń wektorowa

Diagramy związków encji. Laboratorium. Akademia Morska w Gdyni

Układy równań liniowych

Transkrypt:

Bazy danych 3. Normalizacja baz danych P. F. Góra http://th-www.if.uj.edu.pl/zfs/gora/ 2011/12

Pierwsza postać normalna Tabela jest w pierwszej postaci normalnej (1PN), jeżeli 1. Tabela posiada klucz. 2. Wszystkie składowe krotek sa atomowe. Można powiedzieć, że pierwsza postać normalna jest warunkiem tego, żeby w ogóle można było mówić o sytemie relacyjnym. Warunek posiadania klucza jest równoważny temu, że tabela jest zbiorem krotek. Copyright c 2010-12 P. F. Góra 3 2

Atomowość danych Atomowość danych oznacza, że składowych krotek nie można podzielić. Warunek atomowości uniemożliwia to, żeby składowymi krotek były złożone struktury danych, takie jak tablice, listy itp. W zasadzie wymóg atomowości nakazuje dzielić też atrybuty, które można podzielić, na części logicznie niepodzielne. Na przykład zamiast atrybutu Imię i Nazwisko, powinniśmy mieć dwa atrybuty: Imię, Nazwisko. Można sobie jednak wyobrazić sytuacje, w których taki podział byłby niepotrzebny lub niewskazany. O ile zatem pierwsza postać normalna z cała pewnościa wyklucza złożone struktury danych, o tyle interpretacja pojęcia można podzielić może niekiedy zależeć od natury samych danych, które reprezentować ma konstruowana przez nas baza danych. Rozważmy na przykład nazwy osobowe z Chin czy Korei. Copyright c 2010-12 P. F. Góra 3 3

Anomalie baz danych Redundancja ta sama informacja jest niepotrzebnie przechowywana w kilku krotkach. Anomalia modyfikacji informacja zostanie zmodyfikowana w pewnych krotkach, a w innych nie. Która informacja jest wówczas prawdziwa? Anomalia usuwania usuwanie części informacji powoduje utratę innej informacji, której nie chcielibyśmy stracić. Anomalia dołaczania wprowadzenie pewnej informacji jest możliwe tylko wtedy, gdy jednocześnie wprowadzamy jakaś inna informację, która może być obecnie niedostępna. Celem normalizacji baz danych jest unikanie powyższych anomalii. Copyright c 2010-12 P. F. Góra 3 4

Bezstratne złaczenie Normalizację baz danych (powyżej 1PN) przeprowadza się dzielac tabele wertykalnie na tabele potomne. Tabele te jednak musza pozwalać na pełne odtworzenie wyjściowej informacji po dokonaniu złaczenia. Niedopuszczalne jest także, aby złaczenia kreowały informację fałszywa. Dekompozycję tabeli R na tabele R 1, R 2,..., R n nazywamy dekompozycja bezstratnego złaczenia (ze względu na pewien zbiór zależności funkcyjnych), jeśli naturalne złaczenie R 1, R 2,..., R n jest równe tabeli R. Copyright c 2010-12 P. F. Góra 3 5

Dekompozycja tabeli R na dwie tabele R 1, R 2 jest dekompozycja bezstratnego złaczenia, jeśli spełniony jest jeden z dwu warunków (symbol oznacza zależność funkcyjna): lub (R 1 R 2 ) (R 1 \R 2 ) (R 1 R 2 ) (R 2 \R 1 ) Innymi słowy, wspólna część atrybutów R 1, R 2 musi zawierać klucz kandydujacy R 1 lub R 2. Copyright c 2010-12 P. F. Góra 3 6

Przykład negatywny Przypuśćmy, że w pewnej tabeli przechowujemy informację na temat studentów zapisujacych się na kurs baz danych. Przykładowa instancja tabeli mogłaby wygladać tak: T 0 NrStudenta NrKursu DataZapisu Sala Prowadzacy 1010057 K202 01.10.2011 A1 Góra 1010132 K203 01.10.2011 A2 Łachwa 1015678 K202 01.10.2011 A2 Łachwa 1020159 K204 04.10.2011 A1 Góra 1026789 K205 11.10.2011 C2 Oramus Copyright c 2010-12 P. F. Góra 3 7

Rozbijamy tę tabele na dwie, dzielac je wzdłuż kolumny DataZapisu. T 1 NrStudenta NrKursu DataZapisu 1010057 K202 01.10.201 1010132 K203 01.10.2011 1015678 K202 01.10.2011 1020159 K204 04.10.2011 1026789 K205 11.10.2011 T 2 DataZapisu Sala Prowadzacy 01.10.2011 A1 Góra 01.10.2011 A2 Łachwa 01.10.2011 A2 Łachwa 04.10.2011 A1 Góra 11.10.2011 C2 Oramus Copyright c 2010-12 P. F. Góra 3 8

Dokonujemy złaczenia tabel T 1 i T 2. Okazuje się, że dzielenie pierwotnej tabeli wzdłuż kolumny DataZapisu to był kiepski pomysł. Otrzymujemy T 1 T 2 T 0 NrStudenta NrKursu DataZapisu Sala Prowadzacy 1010057 K202 01.10.2011 A1 Góra 1010132 K203 01.10.2011 A1 Góra 1015678 K202 01.10.2011 A1 Góra itd Zaznaczone krotki nie występuja w pierwotnej tabeli. Na skutek podziału tabeli nie spełniajacego warunku bezstratnego złaczenia, utraciliśmy informację o tym, kto kogo uczy. Copyright c 2010-12 P. F. Góra 3 9

Druga postać normalna Tabela jest w drugiej postaci normalnej (2PN), jeżeli 1. Tabela jest 1PN. 2. Wszystkie atrybuty niekluczowe zależa funkcyjnie od pełnego klucza. Atrybuty niekluczowe maja zależeć od pełnego klucza, a nie od jego podzbioru właściwego (który nie musi być kluczem!). Wszystkie tabele 1PN, które maja klucze jednokolumnowe, sa automatycznie 2PN. Copyright c 2010-12 P. F. Góra 3 10

Przykład Załóżmy, że zależności funkcyjne pomiędzy pewnymi atrybutami maja postać A, B C, A D. Poniższa tabela (podkreślenia oznaczaja klucz) A B C D a 1 b 1 c 1 d 1 a 1 b 2 c 2 d 1 a 1 b 3 c 3 d 1 a 2 b 1 c 4 d 2 nie jest 2PN, gdyż atrybut D zależy tylko od atrybutu A, a więc od części klucza, nie od całego klucza. Zauważmy jednocześnie, że wartość d 1 przechowywana jest niepotrzebnie w trzech różnych krotkach. Copyright c 2010-12 P. F. Góra 3 11

Po rozbiciu powyższej tabeli na dwie tabele będace w 2PN, wartość d 1 przechowywana jest tylko w jednej krotce. A B C a 1 b 1 c 1 a 1 b 2 c 2 a 1 b 3 c 3 a 2 b 1 c 4 A D a 1 d 1 a 2 d 2 Proszę pomyśleć, że w poczatkowym przykładzie d 1 mogłoby występować nie w 3, ale w 300 lub w 3000 krotek. Copyright c 2010-12 P. F. Góra 3 12

Trzecia postać normalna Tabela jest w trzeciej postaci normalnej (3PN), jeżeli 1. Tabela jest 2PN. 2. Dla wszystkich atrybutów tabeli zachodzi: Jeżeli A 1, A 2,..., A n A m, to albo {A 1, A 2,..., A n } jest nadkluczem, albo A m jest elementem innego klucza. Trzecia postać normalna jest postacia najczęściej występujac a w zastosowaniach praktycznych. Druga część warunku definicyjnego ( albo A m jest elementem innego klucza ) ma znaczenie tylko wówczas, gdy w tabeli występuja zależności cykliczne (lub częściowe zależności cykliczne). Copyright c 2010-12 P. F. Góra 3 13

Zależności przechodnie Jeżeli w tabeli nie występuja zależności cykliczne, powiada się, że 3PN zakazuje wsytępowania zależności przechodnich. Istotnie, przyjmijmy, że spełnione sa zależności funkcyjne A B, B C, A C; ostatnia z tych zależności wynika z dwu pierwszych na zasadzie przechodniości. Następujaca tabela A B C jest 2PN, ale nie jest 3PN, gdyż zachodzi zależność B C, zaś atrybut B nie jest nadkluczem. Sprowadzenie do 3PN oznacza rozbicie powyższej tabeli na dwie tabele: A B B C Copyright c 2010-12 P. F. Góra 3 14

Przykład Niech zależności funkcyjne będa takie, jak na poprzednim ekranie. Rozważmy następujac a instancję pierwszej tabeli: A B C a 1 b 1 c 1 a 2 b 1 c 1 a 3 b 1 c 1 a 4 b 2 c 2 Copyright c 2010-12 P. F. Góra 3 15

Wielkość c 1 przechowywana jest w trzech krotkach. Po sprowadzeniu do 3PN A B a 1 b 1 a 2 b 1 a 3 b 1 a 4 b 2 B C b 1 c 1 b 2 c 2 wartość c 1 przechowywana jest tylko w jednej krotce. Copyright c 2010-12 P. F. Góra 3 16

Cykliczne zależności funkcyjne Przykładem cyklicznych zależności funkcyjnych jest A B, B C, C A. W takiej sytuacji atrybuty A, B, C sa sobie równoważne określenie wartości jednego z nich, jednoznacznie ustala wartość dwu pozostałych. Każda z trzech tabel A B C A B C A B C jest 3PN, gdyż co prawda występuja zależności przechodnie, ale atrybuty niekluczowe sa elementami innych kluczy (de facto sa innymi kluczami). Copyright c 2010-12 P. F. Góra 3 17

Uwaga! Przy cyklicznych zależnościach funkcyjnych jak poprzednio, tabele rozbite w taki sposób: A B B C C A technicznie rzecz biorac także sa 3PN, a nie zawieraja zależności przechodnich. Jednak taki projekt nie zapobiega redundancji, przeciwnie, wymusza ja, gdyż każda wartość każdego z atrybutów A, B, C jest przechowywana dwa razy. Projekty z poprzedniej strony sa z tego względu zdecydowanie lepsze. Copyright c 2010-12 P. F. Góra 3 18

Procedura postępowania 1. Dany jest zbiór atrybutów, które chcemy reprezentować, i zbiór zależności funkcyjnych pomiędzy atrybutami. 2. Znajdujemy bazę minimalna zbioru zależności funkcyjnych. 3. Majac bazę minimalna, sumujemy zależności funkcyjne o takich samych lewych stronach i dla każdej wysumowanej zależności tworzymy tabelę z odpowiednia lewa strona zależności jako kluczem. Taki sposób postępowania prowadzi do projektu bazy, w której tabele sa 3PN. Copyright c 2010-12 P. F. Góra 3 19

Procedura szukania bazy minimalnej 1. Każdy atrybut musi występować z lewej lub z prawej strony jednej zależności funkcyjnej w zbiorze. 2. Jeśli jakaś zależność funkcyjna jest właczona do zbioru, nie wszystkie zależności funkcyjne potrzebne do jej wyprowadzenia moga występować w tym zbiorze. 3. Jeśli jakaś zależność funkcyjna zostaje wyłaczona ze zbioru, zależności funkcyjne potrzebne do jej wyprowadzenia musza zostać doń dołaczone. Jeżeli w zbiorze zależności funkcyjnych występuja (częściowe) cykle, może istnieć więcej niż jedna baza minimalna. Copyright c 2010-12 P. F. Góra 3 20

Postać normalna Boyce a-codda Tabela jest w postaci normalnej Boyce a-codda (BCNF, PNBC), jeżeli 1. Tabela jest 2PN. 2. Dla każdej zależności nietrywialnej, jeżeli A 1, A 2,..., A n A m, to zbiór {A 1, A 2,..., A n } jest nadkluczem. PNBC jest silniejsza wersja 3PN. Każda tabela będaca PNBC jest także 3PN, ale wynikanie odwrotne nie musi zachodzić. Copyright c 2010-12 P. F. Góra 3 21

Do czego dażymy? Przeprowadzajac normalizację bazy danych, staramy się jednocześnie spełnić trzy warunki: 1. Bezstratne złaczenie. 2. Zachowanie wszystkich zależności funkcyjnych. 3. PNBC. Czy zawsze jest to możliwe? Copyright c 2010-12 P. F. Góra 3 22

Rozważmy tabelę A B C z następujacymi zależnościami funkcyjnymi: C A A, B C (Na przykład: A nazwa banku, B nazwisko klienta uprawnionego do personal banking, C nazwisko bankiera. Pierwsza zależność mówi, że każdy bankier pracuje w określonym banku, druga, że każdego uprawnionego klienta w danym banku obsługuje określony bankier. Ale klient może mieć konta w więcej niż jednym banku... ) Copyright c 2010-12 P. F. Góra 3 23

Powyższa tabela nie jest PNBC, gdyż C nie może być nadkluczem. Jednak żadne rozbicie na dwie tabele dwuatrybutowe albo nie zachowuje kompletu zależności funkcyjnych, albo nie jest dekompozycja bezstratnego złaczenia, albo jedno i drugie. W tej sytuacji zadowalamy się niższa postacia normalna. Zachowanie kompletu zależności funkcyjnych oraz bezstratność złaczeń musza mieć priorytet! Nie każda tabelę daje się znormalizować do PNBC. Copyright c 2010-12 P. F. Góra 3 24

Normalizacja a wydajność Normalizacja baz danych dostarcza mechanizmu pozwalajacego unikać anomalii. Ma to jednak swoja cenę: Dostęp do danych w bazie znormalizowanej może być wolniejszy, gdyż RDBMS musi wykonywać złaczenia. Dlatego w wielkich bazach danych zoptymalizowanych na odczyt (na przykład w hurtowniach danych) często rezygnuje się z wyższych postaci normalnych, przechowujac dane w tabelach 1PN. To także ma swoja cenę: Wprowadzajac dane do takich tabel lub modyfikujac istniejace dane należy dołożyć szczególnej staranności, aby nie dopuścić do anomalii usuwania lub dołaczania, a szczegónie do anomalii modyfikacji (redundancja jest w tego typu bazy niejako wbudowana). Copyright c 2010-12 P. F. Góra 3 25