Normalizacja tabel POSTACIE NORMALNE TABEL
Projektowanie bazy danych- podstawowe reguły 1. Do opisu encji stosuje się oddzielną tabelę. Każdej encji odpowiada 1 tabela. Atrybutowi odpowiada kolumna. Dla każdego atrybutu określa się typ informacji. 2. Do opisu każdego dwustronnego związku między encjami można użyć oddzielnej tabeli. Kolumny tabeli są tworzone z kluczy encji należących do związku. 3. Zapis związku jeden do jednego lub wiele do jednego może być umieszczony w dodatkowych kolumnach tabel pozostających w związku ( nie trzeba tworzyć oddzielnej tabeli do opisu tego związku). W przypadku związku jeden do jednego kolumna ta może znaleźć się w dowolnej tabeli, w przypadku związku wiele do jednego musi znaleźć się w tabeli ze strony wiele. Dołączona kolumna zawiera klucz encji, z którą zachodzi związek. 4. Związek wiele do wielu opisuje się w oddzielnej tabeli, której kolumny tworzone są z kluczy encji należących do związku. 5. Jeśli klucze w tabeli opisującej związek składają się z wielu atrybutów lub są długie należy zastąpić je kluczami sztucznymi.
Normalizację stosuje się, aby sprawdzić czy zaprojektowane tabele mają prawidłową strukturę. Proces normalizacji rozpoczynamy, gdy zostanie utworzony wstępny projekt tabel. Pozwala ona określić, czy informacje przewidziane w projekcie bazy danych zostały przydzielone do właściwych tabel. Natomiast nie da odpowiedzi na pytanie, czy projekt bazy danych jest prawidłowy. Korzyści płynące z normalizacji tabel są następujące: zlikwidowanie problemu powtarzania danych, optymalizacja objętości bazy, optymalizacja efektywności obsługi bazy danych, minimalizacja zagrożenia błędami przy wprowadzaniu danych Stosowane są cztery reguły normalizacji, ale w większości projektów baz danych wystarczy sprawdzić trzy pierwsze. Dla każdej z nich stosowane są określenia: pierwsza postać normalna (I PN) druga postać normalna (II PN) trzecia postać normalna (III PN)
Pierwsza postać normalna (I PN) Usuwanie listy wartości Opisuje jeden obiekt Wartości elementów są elementarne Posiada klucz główny Kolejność wierszy dowolna Przed normalizacją: Po normalizacji:
Przykład tabela studenci: nieznormalizowana Imię Nazwisko miejscowość/powiat/województwo Ewa Nowak Gdańsk / gdański /pomorskie Andrzej Lipski Pcim /myślenicki /małopolskie Jan Kowalski Wieliczka/ wielicki/ małopolskie Barbara Mucha Cisna / leski /podkarpackie Dokonujemy normalizacji tabeli do I postaci normalnej Imię Nazwisko miejscowość powiat województwo Ewa Nowak Gdańsk gdański pomorskie Andrzej Lipski Pcim myślenicki małopolskie Jan Kowalski Wieliczka wielicki małopolskie Barbara Mucha Cisna leski podkarpackie
Księgarnia internetowa : tabela zamówienia Czy tabela jest w I PN? Nazwisko klienta Imię Adres Telefon Tytuł książki Liczba Cena Nowak Marek Pcim 34-220 Lalka 2 20,00 zł Kowalski Adam Wronki 22-018 Balladyna, Tango 1 15,00 zł Górecki Grzegorz Poznań 54-320 Przedwiośnie 1 21,00 zł Zan Marcin Gdańsk 11-560 Dziady 2 40,00 zł
Tabela nie jest w I postaci normalnej ponieważ występuje lista wartości Nazwisko klienta Imię Adres Kod pocztowy Tytuł książki Liczba Cena Nowak Marek Pcim 34-220 Lalka 2 20,00 zł Kowalski Adam Wronki 22-018 Balladyna, Tango 1 15,00 zł Górecki Grzegorz Poznań 54-320 Przedwiośnie 1 21,00 zł Zan Marcin Gdańsk 11-560 Dziady 2 40,00 zł Tabela poniżej jest w I PN. W polu Tytuł książki występują pojedyncze wartości Nazwisko klienta Imię Adres Kod pocztowy Tytuł książki Liczba Cena Nowak Marek Pcim 34-220 Lalka 2 20,00 zł Kowalski Adam Wronki 22-018 Balladyna 1 15,00 zł Kowalski Adam Wronki 22-018 Tango 1 15,00 zł Górecki Grzegorz Poznań 54-320 Przedwiośnie 1 21,00 zł Zan Marcin Gdańsk 11-560 Dziady 2 40,00 zł
Druga postać normalna (II PN) Likwidowanie powtarzających się danych Jest w pierwszej postaci normalnej Każde z pól niewchodzących w skład klucza podstawowego zależy od całego klucza, a nie od jego części. Ta reguła służy do sprawdzenia, czy w tabeli i bazie danych nie dochodzi do redundacji, czyli niepotrzebnego powtarzania danych. Druga postać normalna powstaje w wyniku utworzenia oddzielnych tabel dla zestawów wartości, odnoszących się do wielu rekordów, a następnie powiązania tak powstałych tabel za pomocą klucza zewnętrznego(obcego).
Magazyn Nazwa produktu Producent Kod klienta Nazwa klienta Telefon Ilość TV Telewizor 40 cali Sharp KKO Oskar Kowalski 734 121 323 1 DVD Odtwarzacz DVD Sony KTI Irena Tobola 722180 752 2 DVD Odtwarzacz DVD Philips KKO Oskar Kowalski 734 121 323 3 KAM Kamera Sony KKB Beata Kasprzyk 514 345 765 2 Cześć danych w tabeli powtarza się. Powstająca w wyniku redundancji nadmiarowość jest zjawiskiem niekorzystnym, gdyż powoduje niepotrzebny wzrost objętości bazy danych. Nadmiarowość dotyczy pól:magazyn, Nazwa produktu, kod i nazwa klienta,telefon,producent. Sprawa skomplikuje się, gdy Irena Tobola zmienia nazwisko na Kania. W wyniku takiej zmiany trzeba będzie zmieniać wszystkie pola wszystkie wiersze, w których występuje Irena Tobola. Kolejnym problemem będzie jak zapisać produkt, który nie został jeszcze zakupiony. Taka postać tabeli oznacza, że towar można dopisać tylko wtedy, gdy ktoś go kupi. Aby uniknąć opisanych powyżej problemów należy znormalizować tabelę. Należy podzielić ją na tyle tabel, ile obiektów i działań potrzeba opisać. W tym wypadku trzy: klienci, towary, sprzedaż czyli w wyniku normalizacji otrzymamy trzy tabele
Tabela w I postaci normalnej Kod towaru Nazwa produktu Producent Kod klienta Nazwa klienta Telefon Ilość TV Telewizor 40 cali Sharp KKO Oskar Kowalski 734 121 323 1 DVD Odtwarzacz DVD Sony KTI Irena Tobola 722180 752 2 DVD Odtwarzacz DVD Sony KKO Oskar Kowalski 734 121 323 3 KAM Kamera Sony KKB Beata Kasprzyk 514 345 765 2 Podsumowując: w wyniku normalizacji do II postaci normalnej otrzymamy trzy tabele. Kod towaru Kod klienta Ilość TV KKO 1 DVD KTI 2 DVD KKO 3 KAM KKB 2 Kod klienta Nazwa klienta Telefon KKO Oskar Kowalski 734 121 323 KTI Irena Tobola 722180 752 KKB Beata Kasprzyk 514 345 765 Kod towaru Nazwa produktu Producent TV Telewizor 40 cali Sharp DVD Odtwarzacz DVD Sony KAM Kamera Sony
Tabela jest w I postaci normalnej KLUCZ PODSTAWOWY Nazwisko klienta Imię Miejscowość Kod pocztowy Tytuł książki Liczba Cena Nowak Marek Pcim 34-220 Lalka 2 20,00 zł Kowalski Adam Wronki 22-018 Balladyna 1 15,00 zł Kowalski Adam Wronki 22-018 Tango 1 15,00 zł Górecki Grzegorz Poznań 54-320 Przedwiośnie 1 21,00 zł Zan Marcin Gdańsk 11-560 Lalka 2 20,00 zł Normalizujemy do II postaci normalnej Tabela 1 Tabela 1 nie jest w II postaci normalnej ponieważ tylko kolumna liczba egzemplarzy zależy od całego klucza, kolumny miejscowość, kod pocztowy oraz cena zależą od części klucza Nazwisko klienta Imię Miejscowość Kod pocztowy Nazwisko klienta Tytuł książki Liczba Tytuł książki Cena Nowak Marek Pcim 34-220 Nowak Lalka 2 Lalka 20,00 zł Kowalski Adam Wronki 22-018 Kowalski Balladyna 1 Balladyna 15,00 zł Górecki Grzegorz Poznań 54-320 Zan Marcin Gdańsk 11-560 Tabela 2 Kowalski Tango 1 Górecki Przedwiośnie 1 Zan Dziady 2 Tabela 3 Tango Przedwiośnie 15,00 zł 21,00 zł Tabela 4
Trzecia postać normalna (III PN) Eliminowanie danych, które nie zależą od klucza. Jest w drugiej postaci normalnej Każde z pól niewchodzących w skład klucza podstawowego niesie informację bezpośrednio o kluczu i nie odnosi się do żadnego innego pola Przed normalizacją: Po normalizacji: Pytanie: Jakiej należałoby dokonać modyfikacji tabel z poprzedniego slajdu, aby tabele były w III postaci normalnej?
Przykład : Tabela faktury - tabela jest w I postaci normalnej: Klucz podstawowy Nazwisko klienta Imię klienta Miejsce zam. NIP NR faktury Data wystawienia Nowicki Adam Przemyśl 7781029219 1/2018 3-01-2018 Kowal Marek Warszawa 8960006804 2/2018 5-01-2018 Kowal Marek Warszawa 8960006804 3/2018 6-01-2018 Bagińska Anna Szczecin 8131096298 4/2018 6-01-2018 Pol Aleksander Katowice 9590788263 5/2018 8-01-2018 Pol Aleksander Katowice 9590788263 6/2018 9-01-2018 wartości w tych kolumnach odnoszą się do pól nazwisko i imię klienta NR faktury Data wystawienia Nazwisko klienta Normalizacja tabeli faktury do III postaci normalnej: Nazwisko klienta Imię klienta Miejsce zam. NIP Nowicki Adam Przemyśl 7781029219 Kowal Marek Warszawa 8960006804 Bagińska Anna Szczecin 8131096298 Pol Aleksander Katowice 9590788263 1/2018 3-01-2018 Nowicki 2/2018 5-01-2018 Kowal 3/2018 6-01-2018 Kowal 4/2018 6-01-2018 Bagińska 5/2018 8-01-2018 Pol 6/2018 9-01-2018 Pol
Bibliografia: 1. Kwalifikacja E14 Tworzenie baz danych i administrowanie bazami Jolanta Pokorska 2. Bazy danych dla zwykłych śmiertelników Michael J.Hernandez