Bazy Danych
Zajęcia 5
Normalizacja *
Diagramy ERD
Wejdź w MSSQL Management Studio i wybierz Database Diagrams. Utwórz i zobacz jak wygląda diagram dla bazy, z której korzystamy na zajęciach.
Przeczytaj o rodzajach relacji między tabelami na :
ENCJA jest rzeczą lub obiektem mającym dla nas znaczenie, rzeczywistym bądź wyobrażonym, o którym informacje muszą być znane lub przechowywane. Graficzną reprezentacją ENCJI jest prostokąt z nazwą ENCJI zapisaną w liczbie pojedynczej.
ZWIĄZEK jest nazwanym, istotnym powiązaniem pomiędzy dwiema encjami. Związki przedstawiają zależności zachodzące pomiędzy obiektami. Każdy zwiazek ma dwa końce, z których każdy ma przypisane następujące artybuty [nazwę;liczebność (jak wiele);opcjonalność (opcjonalny czy wymagany)]. Związek jest reprezentowany za pomocą linii łączącej dwie encje.
Pierwsza kreska (lub kółko) oznacza opcjonalność lub wymaganie związku. Druga określa liczebność.
Encje i związki:
ATRYBUT jest dowolnym szczegółem służącym do kwalifikowania, identyfikowania, klasyfikowania, określania ilości lub wyrażania stanu encji.
Jak utworzyć ERD?
1. Ustalić encje i określić ich nazwy (rzeczowniki).2. Dla każdej encji ustalić jej atrybuty i dziedziny tych atrybutów (przymiotniki, cechy).3. Dla każdej encji określić, jakie atrybuty pełnią funkcję klucza głównego.4. Ustalić związki, jakie zachodzą między encjami, określić ich liczebność (czasowniki).5. Wyeliminować jako niepożądane związki wieloznaczne (N-N).6. Uzupełnić encje o klucze obce pozwalające zrealizować w praktyce związki jednoznaczne.7. Określić więzy integralności nałożone na dane w bazie danych.
Paintlike program do rysowania diagramów:
Normalnizacja
Normalizacja zmaga się z problemem posiadania tych samych danych w wielu komórkach. Problem z ich uaktualnianiem (konieczność aktualizacji wszystkich wystąpień), usuwaniem (tracimy informacje o kliencie przy usunięciu zamówień), wprowadzaniem (żeby wprowadzić klienta musi istnieć zamówienie).
Rozwiązanie to dekompozycja, czyli podział na wiele tabel. Proces normalizacji relacji można traktować jako proces, podczas którego schematy relacji posiadające pewne niepożądane cechy są dekomponowane na mniejsze schematy relacji o pożądanych własnościach.
Postulat normalizacji daje się także wyrazić w następujący sposób:
Każdy fakt przechowywany w bazie danych powinien być wyrażalny w niej tylko na jeden sposób.
1NF
Mówimy, że schemat relacji R znajduje się w pierwszej postaci normalnej (1NF), jeżeli wartości atrybutów są atomowe (niepodzielne).
Innymi słowy nie ma atrybutów typu zbiorowego np. Kraj,Miasta->Polska,{Poznań, Kraków, Warszawa}. Rozwiązanie to podział na dwie tabele Kraje i Miasta i dodanie w miastach klucza do tabeli Kraje.
Inny przypadek to gdy dane się powtarzają np. dla relacji Osoba, Adres, Telefon jeżeli dana osoba ma dwa numery telefonów, to musielibyśmy dodać dwa wpisy i powtórzyc dane, lepiej podzielić tabele na dwie Osoba, Adres, Osoba, Telefon.
2NF
Mówimy, że dana relacja r o schemacie R jest w drugiej postaci normalnej (2NF), jeżeli jest (1NF) żaden atrybut tej relacji nie jest częściowo funkcyjnie zależny od żadnego z kluczy relacji r.
Innymy słowy jeżeli relacja ma parę kluczy, to żaden z atrybutów nie zależy jedynie od jednego z nich. Np. Id_produktu, Id_magazynu, Adres_magazynu, Liczba_produktów_w_magazynie, Nazwa produktu. W tym wypadku Adres zalezy tylko od Id_magazynu a Nazwa produktu tylko od jego Id.
3FN
Dana relacja r o schemacie R jest w trzeciej postaci normalnej (3NF) jeżeli jest (2NF) i każdy z atrybutów relacji zależy tylko od wartości klucza.
Np dla tabeli zawierającej dane: Nazwisko (klucz), Wydział, Uczelnia. Uczelnia zależy zarówno od nazwiska jak i od Wydziału. Rozwiązaniem jest w tym wypadku podział na dwie tabele Nazwisko, Wydział i Wydział, Uczelnia.
Podsumowanie
"Requiring existence of "the key" ensures that the table is in 1NF; requiring that non-key attributes be dependent on "the whole key" ensures 2NF; further requiring that non-key attributes be dependent on "nothing but the key" ensures 3NF. Both 2NF and 3NF are concerned equally with all candidate keys of a table and not just any one key."
4NF
Mówimy, że relacja r o schemacie R jest w czwartej postaci normalnej (4NF) jeżeli kazda relacja X->Y jest trywialna (Y jest elementem X) albo X jest kluczem relacji. Inaczej mówiąc schemat relacji jest w czwartej postaci normalnej jeśli nie ma w nim zależności wielowartościowych.
To znaczy np. dla tabeli Loty, dzień, Typ_samolotu nie mamy 4NF gdyż kluczem relacji jest cała trójka. Stąd relacja Lot -> dzien nie jest trywialna (ten sam numer lotu dla różnych dni, wiele lotów dziennie), ani sam lot nie jest kluczem. Problemem jest to, że jeżeli pojawia się nowy typ samolotu dla danego dnia to musimy updatować wszystkie dni. Rozwiązaniem jest podział na dwie tabele Lot, dzień i Lot, Typ.
Projekt
Projekt musi zawierać co najmniej 7 tabel i 5 relacji. Co najmniej 2 relacje muszą być relacjami x - wiele.
Wymagania dokumentacja:
Opis bazy danych 20%Opis specjalnych zależności 20%Opis tabel 20%Diagram bazy danych 20%Opis raportów 20%
Punktacja :
Dokumentacja 50%Skrypt 20%Złożoność raportów 20%Dane przykładowe 10%
Zadanie Domowe
Termin wykonania zadania: Niedzieli 19.11.2017 do godziny 24.00.
Wykonać zadanie 4 na schemacie umieścić atrybuty i oznaczenia kluczy głównych i obcych.
Rozwiązania proszę przesłać przez stronę:
Logujemy się jak na komputery Wydziałowe, przesyłamy plik (jeden wspólny dla wszystkich) z rozwiązaniami.
UWAGA! Rozwiązania można przesłać tylko raz.
- *
Wykorzystano materiały z
http://wazniak.mimuw.edu.pl/index.php?title=BD-2st-1.2-w05.tresc-1.1-Slajd5
http://visuastudio-vbnet.blog.pl/2013/01/17/35/
http://jjakiela.prz.edu.pl/erd.htm