Normalizacja.

Slides:



Advertisements
Podobne prezentacje
Indeksy w bazie danych Oracle
Advertisements

S – student, P – przedmiot, W – wykładowca
Relacyjny model danych
Wprowadzenie do systemów baz danych
MS Access 2000 Relacje Piotr Górczyński 2005.
Relacyjny model danych
Komponenty bazy danych Baza danych Jest to uporządkowany zbiór powiązanych ze sobą danych charakterystycznych dla pewnej klasy obiektów lub zdarzeń,
WPROWADZENIE DO BAZ DANYCH
MS Access 2000 Normalizacja Paweł Górczyński 2005.
MS Access 2000 Tworzenie tabel Piotr Górczyński 2005.
Dynamiczne struktury danych 1
Normalizacja : Głównym celem projektowania bazy przeznaczonej dla systemu relacyjnego jest właściwa reprezentacja danych, związków i więzów. W identyfikowaniu.
Projektowanie relacyjnych baz danych
Modele baz danych - spojrzenie na poziom fizyczny
Dr inż. Andrzej Macioł Bazy danych dr inż. Andrzej Macioł
Bazy danych – model relacyjny
Język SQL (Structured Query Language) DDL (Data Definition Language)
Projektowanie struktury logicznej (schematu) relacyjnych baz danych
Zadania Bazy danych.
Teoria relacyjnych baz danych
Bazy Danych II prowadzący: mgr inż. Leszek Siwik
Zależności funkcyjne.
PROJEKTOWANIE TABEL W PROGRAMIE: ACCESS
DIAGRAMY ER 2 (ENTITY-RELATIONSHIP DIAGRAMS 2) Ćwiczenia 2.
Bazy danych.
Bazy danych podstawowe pojęcia
Systemy baz danych Wykład 1
Budowanie tabel i relacji
Informatyka Relacyjne bazy danych.
RELACYJNE BAZY DANYCH, SCHEMAT RELACJI, SELEKCJA, PROJEKCJA
Andrzej Macioł Bazy danych – model relacyjny – cz. 1 Andrzej Macioł
SQL - Structured Query Language
Wybrane zagadnienia relacyjnych baz danych
WPROWADZENIE DO BAZ DANYCH
Relacyjne bazy danych Tworzenie bazy danych Marzena Nowakowska Katedra Informatyki Stosowanej, WZiMK, PŚk p C dostęp do materiałów:
Model relacyjny.
Komendy SQL do pracy z tabelami i bazami
ZWIĄZKI MIĘDZY KLASAMI KLASY ABSTRAKCYJNE OGRANICZENIA INTERFEJSY SZABLONY safa Michał Telus.
Bazy danych – model relacyjny – cz. 2
Bazy danych - podstawowe pojęcia
Projektowanie bazy danych
Łódź 2008 Banki danych WYKŁAD 2 dr Łukasz Murowaniecki T-109.
Michał Krawczykowski kl. IIIB
Podstawowe informacje
Definiowanie kluczy w tabelach RBD
Model obiektowy bazy danych
Slajd 1© J.Rumiński Jacek Rumiński  Bazy danych Kontakt: Katedra Inżynierii Biomedycznej, pk. 106, tel.: , fax: ,
Treści multimedialne - kodowanie, przetwarzanie, prezentacja Odtwarzanie treści multimedialnych Andrzej Majkowski informatyka +
Projektowanie relacyjnych baz danych – diagramy związków encji
Komendy SQL do pracy z danymi
Projektowanie bazy danych z użyciem diagramów UML Obiektowe projektowanie relacyjnej bazy danych Paweł Jarecki.
Bazy danych Podstawy relacyjnych baz danych Autor: Damian Urbańczyk.
Projektowanie bazy danych biblioteki szkolnej
Projektowanie postaci formularza:
BAZY DANYCH MS Access.
Modelowanie model związków encji
Bazy Danych Wprowadzenie
BAZY DANYCH ZAAWANSOWANE MECHANIZMY Microsoft Access Adrian Horzyk
Bazy danych. Baza danych (database) – magazyn danych – informacji powiązanych tematycznie, umożliwiający ich wyszukiwanie według zadanych kryteriów Baza.
Temat: Tworzenie bazy danych
Relacje Marcin Wojnowski.
Indeksy.
Nieprawidłowo zaprojektowana tabela
Technologie informacyjne w administracji publicznej
Treści multimedialne - kodowanie, przetwarzanie, prezentacja Odtwarzanie treści multimedialnych Andrzej Majkowski informatyka +
Technologie informacyjne w administracji publicznej
Modele baz danych - spojrzenie na poziom fizyczny
Zapis prezentacji:

Normalizacja

Pierwsza postać normalna Jedynymi relacjami dozwolonymi w modelu relacyjnym są relacje spełniające następujący warunek: każda wartość w relacji, tj. każda wartość atrybutu w każdej krotce, jest wartością atomową (wartością nie rozkładalną) (lPN) oznacza, że tabela nie zawiera powtarzających się grup informacji, co znaczy, że każda kolumna jest wartością skalarną (atomową), a nie macierzą lub listą czy też czymkolwiek, co posiada własną strukturę

Relacja nie znormalizowana Pracownik Języki Jan Kowalski angielski – słabo, niemiecki - dobrze Adam Kot rosyjski – bardzo dobrze

Relacja nie znormalizowana Pracownik Znajomość języków Język Poziom Jan Kowalski angielski słabo niemiecki dobrze Adam Kot rosyjski bardzo dobrze

Relacja nie znormalizowana Relację "przed normalizacją" zdefiniowano na dwóch dziedzinach: Pracownik i Znajomość Języków Elementami dziedziny Znajomość Języków są również relacje (zdefiniowane na dziedzinach Język i Poziom) Relacja jest z punktu widzenia definicji relacją dwuczłonową, ale nie wszystkie jej dziedziny są proste (dziedzina prosta to taka, której wszystkie elementy są atomowe)

Relacja znormalizowana Pracownik Język Poziom Jan Kowalski angielski słabo niemiecki dobrze Adam Kot rosyjski bardzo dobrze

Relacja znormalizowana Relacja jest relacją trójczłonową, której wszystkie dziedziny są proste, jest więc znormalizowana Powodem tego jest uproszczenie struktury danych, które z kolei powoduje uproszczenie operatorów w subjęzyku danych Uproszczenia te nie ograniczają w niczym możliwości reprezentowania obiektów

Relacja znormalizowana - nieporozumienia Pracownik Imię dziecka Data ur. dziecka Kowalski Ania 01.01.2000 Jaś 15.03.2001 Kot Patrycja 20.10.2001 Filemon 30.07.2003

Relacja znormalizowana - nieporozumienia Praco-wnik Imię dziecka1 Data ur. dziecka1 Imię dziecka2 Data ur. dziecka2 Kowal-ski Ania 01.01.2000 Jaś 15.03.2001 Kot Patrycja 20.10.2001 Filemon 30.07.2003

Pierwsza postać normalna Przedmiot Prowadzący Student Ocena matematyka prof. Lis Jak Kot 2,0 Ewa Osa 3,0 Adam Struś 5,0

Pierwsza postać normalna Powtarzająca się grupa danych to podzbiór relacji zawierający co najmniej dwa atrybuty, posiadająca własny klucz prosty, w którym istnieją powtarzające się krotki Powtarzanie się takich samych krotek wymuszone jest faktem, że mamy do czynienia z grupą dla której część atrybutów jest strukturą a nie wartością skalarną

Pierwsza postać normalna Przedmiot Student Ocena matematyka Jak Kot 2,0 Ewa Osa 3,0 Adam Struś 5,0 Przedmiot Prowadzący matematyka prof. Lis

Anomalie przy usuwaniu, wstawianiu i aktualizacji – baza klientów systemu CRM

Anomalie przy usuwaniu Po usunięciu informacji o firmie P H U „Żagiel” tracimy informacje o branży „Handel” (Opis)

Anomalie przy wstawianiu Wstawienie informacji nowym kliencie wymaga wpisania opisu branży mimo, że opis już istnieje

Anomalie przy aktualizacji Zmiana opisu „Usług krawieckich” musi być dokonana w czterech miejscach

Druga postać normalna Relacja jest w drugiej postaci normalnej, jeśli każdy atrybut tej relacji nie wchodzący w skład żadnego klucza potencjalnego jest w pełni funkcyjnie zależny wyłącznie od wszystkich podrelacji klucza głównego

Ta relacja nie jest w drugiej postaci normalnej

Ta relacja nie jest w drugiej postaci normalnej bo: kluczem w relacji jest podzbiór atrybutów Id Firmy i Nazwa branży bo powtórzenie krotki o dwóch identycznych wartościach tych atrybutów wskazywałoby na powtórne przypisanie tej samej branży tej samej firmie atrybut Nazwa zależy funkcjonalnie od atrybutu Id Firmy a nie zależy od atrybutu Nazwa branży (może być wiele firm w każdej z branż)

Relacja po dekompozycji

Trzecia postać normalna Relacja jest w trzeciej postaci normalnej, jeśli: jest w drugiej postaci normalnej żaden atrybut nie będący kluczem nie jest funkcjonalnie związany z żadnym innym atrybutem nie będącym również kluczem

Ta relacja nie jest w trzeciej postaci normalnej Pracownik PESEL KodPocztowy Miejscowość Województwo Jan Kowalski 12345678911 32-082 Bolechowice małopolskie Adam Kot 98977796666 30-150 Kraków Ewa Lis 76281976372

Zależność funkcjonalna przechodnia Niech X, Y i Z będą trzema rozłącznymi podzbiorami atrybutów danej relacji Z jest przechodnio funkcjonalnie zależny od X, jeśli Z jest funkcjonalnie zależny od Y i Y jest funkcjonalnie zależny od X natomiast X nie jest zależny od Y i Y nie jest zależny od Z

Forma normalna Boyce-Codd’a Jest uzupełnieniem trzeciej postaci normalnej i jest niezbędna w przypadku gdy atrybuty będące kandydatami na klucze są: wielokrotne, złożone, nakładające się na siebie

Forma normalna Boyce’a-Codd’a Relacja jest w postaci Boyce-Codd’a jeżeli dla każdej nietrywialnej zależności między podzbiorami relacji zbiór będący wyznacznikiem jest zbiorem identyfikującym tej relacji Zależność X →Y jest trywialna jeżeli Y jest podzbiorem X Definicja BCNF zastępuje definicje, pierwszej, drugiej i trzeciej formy normalnej dodatkowo je poszerzając

Forma normalna Boyce-Codd’a IdPracownika Zawód Wykształcenie Stawka 1 ślusarz podstawowe 5,20 tokarz zawodowe 5,30 2 5,50 3 4 kluczem w relacji jest podzbiór IdPracownika, Zawód lub IdPracownika, Wykształcenie zależność Zawód, Wykształcenie  Stawka jest funkcjonalna i nietrywialna a Zawód, Wykształcenie nie jest zbiorem identyfikującym

Forma normalna Boyce-Codd’a IdStudenta Seminarium Opiekun 1 marketing Kowalski kadry Kozłowski 2 Janowski 3 4 informatyka Macioł ponieważ opiekun może mieć tylko jedno seminarium to kluczem w relacji jest podzbiór IdStudenta, Seminarium lub IdStudenta, Opiekun zależność Opiekun  Seminarium jest funkcjonalna i nietrywialna a Opiekun nie jest zbiorem identyfikującym

Czwarta forma normalna Relacja jest w czwartej formie normalnej wtedy i tylko wtedy, gdy jest w trzeciej postaci normalnej i nie zawiera wielowartościowej zależności atrybutów

Więzi Więź (ang. relationship) to powiązanie pomiędzy parą tabel. Istnieje ona wtedy, gdy dwie tabele są połączone przez klucz podstawowy i klucz obcy. Każda więź jest opisywana przez typ więzi istniejący między dwoma tabelami, typ uczestnictwa oraz stopień uczestnictwa tych tabel

Typy więzi jeden-do-jednego (jeżeli pojedynczemu rekordowi z pierwszej tabeli przyporządkowany jest najwyżej jeden rekord z drugiej tabeli i na odwrót)

Więź jeden-do-jednego

Typy więzi jeden-do-wielu (jeżeli pojedynczemu rekordowi z pierwszej tabeli może odpowiadać jeden lub więcej rekordów z drugiej, ale pojedynczemu rekordowi z drugiej tabeli odpowiada najwyżej jeden rekord z tabeli pierwszej)

Więź jeden-do-wielu

Więzi identyfikujące Klucz obcy, który jest składnikiem złożonego klucza głównego w relacji zależnej określany jest mianem klucza obcego głównego (Primary Foreign Key) a tak zbudowana więź więziom identyfikującą

Więź jeden-do-wielu (identyfikująca)

Obcy klucz główny (IdPracownika) Rok Miesiac IdPracownika LiczbaGodzin 2005 01 1 160 2 150 02 140 Taki wiersz nie może się pojawić

Więź wiele-do-wielu (dane) IdAgregatu Agregat Data IdPracownika Nazwisko Godziny 1 Piła 10.03.05 Kowalski 4 2 Lis Tokarka 3 Kot 8 11.03.05 6

Więź wiele-do-wielu Na jednym agregacie mogą pracować różni pracownicy, np. na agregacie Piła 10. marca pracowało dwóch pracowników Jeden pracownik może pracować na wielu agregatach, np. Kowalski pracował 10. marca na Pile i Tokarce)

Więź wiele-do-wielu

Więź wiele-do-wielu (po rekonstrukcji) IdAgregatu Data IdPracownika Godziny 1 10.03.05 4 2 3 8 11.03.05 6

Typy uczestnictwa obowiązkowy (jeśli w pierwszej tabeli muszą znajdować się pewne rekordy zanim zaczniemy wprowadzać rekordy do tabeli drugiej) opcjonalny (jeśli wprowadzanie rekordów do tabeli drugiej nie wymaga istnienia żadnych rekordów w tabeli pierwszej). Stopień uczestnictwa określa minimalną i maksymalną liczbę rekordów w jednej tabeli, które można powiązać z pojedynczym rekordem w tabeli drugiej.

Opcjonalny typ uczestnictwa

Klucz sztuczny Klucz stworzony wyłącznie dla potrzeb więzi w celu zastąpienia złożonego klucza głównego

Klucz złożony...

...zastąpiony kluczem sztucznym

Klucz złożony...

...zastąpiony kluczem sztucznym

Klucz sztuczny Klucz sztuczny może być wykorzystany do kodowania atrybutów tekstowych (w niektórych przypadkach także liczbowych) o powtarzających się wartościach, dla których można utworzyć listę Użycie klucza sztucznego wymaga stworzenia dodatkowej tabeli (słownika) pozwalającego na „rozkodowanie” klucza

Przykłady normalizacji

Powtarzająca się grupa danych

Klucz w grupie

To nie jest pole elementarne

to też jest powtarzająca się grupa danych bo za miesiąc będzie tak:

brak dobrego kandydata na klucz grupy i dlatego wprowadzamy klucz sztuczny

wartość netto = liczba jednostek * cena kwota VAT = wartość netto * stawka wartość brutto = wartość netto + kwota Vat tego nie trzeba pamiętać

to też jest powtarzająca się grupa danych, bo tabela może wyglądać tak:

brak dobrego kandydata na klucz grupy i dlatego wprowadzamy klucz sztuczny i wykonujemy dekompozycję

to też jest powtarzająca się grupa danych, w której kluczem jest rodzaj usługi i dlatego trzeba tablicę zdekomponować:

to nie są powtarzające się grupy danych, ale powtarzające się dane, które warto przechowywać w słownikach:

można nie używać sztucznych kluczy ale należy wówczas zadbać o integralność poprzez zapewnienie kaskadowej aktualizacji: on update cascade on delete cascade

kluczem jest podzbiór: nr faktury, usługa, strefa czasowa, kierunek cena zależy funkcyjnie od podzbioru klucza: usługa, strefa czasowa, kierunek stawka VAT zależy funkcyjnie od podzbioru klucza: usługa

kluczem w prawej tabeli jest id usługi tabela nie jest w trzeciej postaci normalnej bo cena zależy funkcyjnie od zbioru: id usługi, strefa czasowa, kierunek

lewa tabela pozornie nie jest w trzeciej postaci normalnej ale zauważmy, że id rodzaju usługi, strefa czasowa i kierunek to też klucz