Numer ID artykułu: 283878 - Zobacz jakich produktów dotyczą zawarte w tym artykule porady.
Ten artykuł został opublikowany wcześniej pod numerem PL283878
Poziom podstawowy: wymagana znajomość interfejsu użytkownika na komputerach mających jednego użytkownika.

Wersja tego artykułu dla programu Microsoft Access 2000: 209534.
Wersja tego artykułu dla programu Microsoft Access 95 lub Microsoft Access 97: 100139.
Rozwiń wszystko | Zwiń wszystko

Na tej stronie

Streszczenie

W tym artykule wyjaśniono terminologię dotyczącą normalizacji bazy danych dla początkujących. Podczas omawiania projektu relacyjnej bazy danych przydaje się podstawowa znajomość tej terminologii.

UWAGA Firma Microsoft udostępnia też emisję internetową WebCast z omówieniem podstaw normalizacji bazy danych. Aby wyświetlić tę emisję WebCast, odwiedź następującą witrynę firmy Microsoft w sieci Web:
http://support.microsoft.com/servicedesks/webcasts/wc060600/wc060600.asp?fr=1

Więcej informacji

Opis normalizacji

Normalizacja to proces organizowania danych w bazie danych. Obejmuje to tworzenie tabel i ustanawianie relacji między tymi tabelami zgodnie z regułami zaprojektowanymi w celu zarówno ochrony danych, jak i zapewnienia większej elastyczności bazy danych przez wyeliminowanie nadmiarowości i niespójnych zależności.

Nadmiarowe dane zajmują dodatkowe miejsce na dysku i przyczyniają się do problemów z konserwacją. Gdy trzeba zmienić dane istniejące w więcej niż jednym miejscu, dane we wszystkich tych lokalizacjach należy zmienić w dokładnie taki sam sposób. Zmiana adresu klienta jest znacznie łatwiejsza, gdy te dane są przechowywane tylko w tabeli Klienci i nigdzie indziej w bazie danych.

Co to jest „niespójna zależność”? Użytkownik intuicyjnie zagląda do tabeli Klienci, aby sprawdzić adres określonego klienta, ale nie zajrzy tam, aby sprawdzić wynagrodzenie pracownika dzwoniącego do tego klienta. Wynagrodzenie pracownika jest powiązane z pracownikiem (zależne od niego), więc powinno zostać przeniesione do tabeli Pracownicy. Niespójne zależności utrudniają dostęp do danych, ponieważ może brakować ścieżki do odnalezienia danych.

Istnieje kilka reguł normalizacji bazy danych. Każda reguła jest nazywana „postacią normalną”. Jeśli pierwsza reguła jest przestrzegana, o bazie danych mówi się, że jest w pierwszej postaci normalnej. Jeśli pierwsze trzy reguły są przestrzegane, o bazie danych mówi się, że jest w trzeciej postaci normalnej. Chociaż są możliwe inne poziomy normalizacji, trzecia postać normalna jest uważana za najwyższy poziom niezbędny dla większości aplikacji.

Tak jak w przypadku wielu formalnych reguł i specyfikacji, rzeczywiste scenariusze nie zawsze umożliwiają doskonałą zgodność. Normalizacja wymaga zwykle dodatkowych tabel i niektórzy klienci mogą uważać to za niewygodne. W razie decyzji o naruszeniu jednej z trzech pierwszych reguł normalizacji należy upewnić się, że aplikacja przewiduje wszelkie ewentualne problemy, na przykład nadmiarowe dane i niespójne zależności.

Do poniższych opisów dołączono przykłady.

Pierwsza postać normalna

  • Wyeliminuj powtarzające się grupy w poszczególnych tabelach.
  • Utwórz osobną tabelę dla każdego zestawu powiązanych danych.
  • Zidentyfikuj każdy zestaw powiązanych danych za pomocą klucza podstawowego.
Nie należy używać wielu pól w jednej tabeli do przechowywania podobnych danych. Na przykład aby można było śledzić pozycję magazynową mogącą pochodzić z dwóch źródeł, rekord magazynu może zawierać pola na kod pierwszego dostawcy i na kod drugiego dostawcy.

Co się stanie po dodaniu trzeciego dostawcy? Dodanie pola nie jest rozwiązaniem. Wymagałoby zmodyfikowania programu i tabeli, a ponadto nie jest sprawną metodą dodawania kolejnych dostawców. Zamiast tego najlepiej jest umieścić wszystkie informacje o dostawcach w osobnej tabeli o nazwie Dostawcy, a następnie połączyć magazyn z dostawcami za pomocą klucza numeru pozycji albo połączyć dostawców z magazynem za pomocą klucza kodu dostawcy.

Druga postać normalna

  • Utwórz osobne tabele dla zestawów wartości dotyczących wielu rekordów.
  • Powiąż te tabele za pomocą klucza obcego.
Rekordy nie powinny zależeć od niczego innego niż klucz podstawowy tabeli (jeśli jest to niezbędne, klucza złożonego). Rozważmy na przykład adres klienta w systemie księgowym. Adres jest potrzebny w tabeli Klienci, ale także w tabelach Zamówienia, Wysyłka, Faktury, Rozrachunki z odbiorcami i Pobory należności. Zamiast przechowywać adres klienta w osobnym wpisie w każdej z tych tabel, należy przechowywać go w jednym miejscu, w tabeli Klienci lub w osobnej tabeli Adresy.

Trzecia postać normalna

  • Wyeliminuj pola, które nie zależą od klucza.
Wartości w rekordzie, które nie stanowią części klucza rekordu, nie powinny znajdować się w danej tabeli. Ogólnie w każdym przypadku, w którym zawartość grupy pól może dotyczyć więcej niż jednego rekordu w tabeli, należy rozważyć umieszczenie tych pól w osobnej tabeli.

Na przykład w tabeli Rekrutacja pracowników można uwzględnić nazwę i adres uniwersytetu kandydata. Ale do wysyłek grupowych potrzebna jest pełna lista uniwersytetów. Jeśli informacje o uniwersytetach są przechowywane w tabeli Kandydaci, nie można utworzyć listy uniwersytetów bez bieżących kandydatów. Należy utworzyć osobną tabelę Uniwersytety i połączyć ją z tabelą Kandydaci za pomocą klucza kodu uniwersytetu.

WYJĄTEK: stosowanie się do trzeciej postaci normalnej, chociaż teoretycznie pożądane, nie zawsze jest praktyczne. Jeśli jest używana tabela Klienci i trzeba wyeliminować wszelkie możliwe zależności między polami, należy utworzyć osobne tabele dla miast, kodów pocztowych, przedstawicieli handlowych, klas klientów oraz wszelkich innych czynników, które mogą zostać zduplikowane w wielu rekordach. W teorii warto stosować normalizację. Jednak stosowanie wielu małych tabel może pogorszyć wydajność lub spowodować przekroczenie dozwolonej liczby otwartych plików lub pojemności pamięci.

Niekiedy lepszym rozwiązaniem jest stosowanie trzeciej postaci normalnej tylko do danych często zmienianych. Jeśli pozostają jakieś pola zależne, projekt aplikacji powinien wymagać od użytkownika zweryfikowania wszystkich powiązanych pól po zmianie jednego z nich.

Inne postacie normalizacji

Czwarta postać normalna, nazywana też postacią BCNF (Boyce Codd Normal Form), i piąta postać normalna istnieją, ale rzadko są brane pod uwagę w rzeczywistych projektach. Zignorowanie tych reguł może skutkować projektem niedoskonałym, ale nie powinno wpływać na działanie.

Normalizowanie przykładowej tabeli

W ramach tych czynności przedstawiono proces normalizowania fikcyjnej tabeli studentów.
  1. Tabela nieznormalizowana:

    Zwiń tę tabelęRozwiń tę tabelę
    Nr studentaOpiekunPokój opiekunaZajęcia 1Zajęcia 2Zajęcia 3
    1022Czarnecki412101-07143-01159-02
    4123Borkowski216201-01211-02214-01
  2. Pierwsza postać normalna: brak powtarzających się grup

    Tabele powinny mieć tylko dwa wymiary. Ponieważ jeden student może mieć kilka rodzajów zajęć, zajęcia powinny być wymienione w osobnej tabeli. Pola Zajęcia 1, Zajęcia 2 i Zajęcia 3 w powyższych rekordach sygnalizują problemy z projektem.

    W arkuszach kalkulacyjnych często jest używany trzeci wymiar, ale w tabelach nie powinno to mieć miejsca. Inną metodą przestawienia tego problemu jest relacja jeden-do-wielu: nie należy umieszczać strony „jeden” i strony „wielu” tej relacji w tej samej tabeli. Zamiast tego należy utworzyć inną tabelę w pierwszej postaci normalnej przez wyeliminowanie powtarzającej się grupy (Zajęcia nr), tak jak to pokazano poniżej:

    Zwiń tę tabelęRozwiń tę tabelę
    Nr studentaOpiekunPokój opiekunaNr zajęć
    1022Czarnecki412101-07
    1022Czarnecki412143-01
    1022Czarnecki412159-02
    4123Borkowski216201-01
    4123Borkowski216211-02
    4123Borkowski216214-01
  3. Druga postać normalna: wyeliminowanie danych nadmiarowych

    W powyższej tabeli dla każdej wartości Nr studenta występuje wiele wartości Nr zajęć. Wartości Nr zajęć nie są funkcjonalnie zależne od klucza podstawowego Nr studenta, więc ta relacja nie jest w drugiej formie normalnej.

    W poniższych dwóch tabelach pokazano drugą formę normalną:

    Studenci:

    Zwiń tę tabelęRozwiń tę tabelę
    Nr studentaOpiekunPokój opiekuna
    1022Czarnecki412
    4123Borkowski216


    Rejestracja:

    Zwiń tę tabelęRozwiń tę tabelę
    Nr studentaNr zajęć
    1022101-07
    1022143-01
    1022159-02
    4123201-01
    4123211-02
    4123214-01
  4. Trzecia postać normalna: wyeliminowanie danych, które nie zależą od klucza

    W ostatniej tabeli wartości Pokój opiekuna są funkcjonalnie zależne od atrybutu Opiekun. Rozwiązaniem jest przeniesienie tego atrybutu z tabeli Studenci do tabeli Wykładowcy, jak pokazano poniżej:

    Studenci:

    Zwiń tę tabelęRozwiń tę tabelę
    Nr studentaOpiekun
    1022Czarnecki
    4123Borkowski


    Wykładowcy:

    Zwiń tę tabelęRozwiń tę tabelę
    NazwiskoPokójWydział
    Czarnecki41242
    Borkowski21642
Uwaga: Niniejszy artykuł, przeznaczony do „SZYBKIEJ PUBLIKACJI”, został utworzony bezpośrednio przez organizację pomocy technicznej firmy Microsoft. Zawarte w nim informacje są udostępniane „w stanie takim, w jakim są” w odpowiedzi na pojawiające się problemy. W wyniku przyspieszonego trybu udostępniania materiały mogą zawierać błędy typograficzne i mogą zostać poprawione w dowolnym momencie bez uprzedzenia. Więcej informacji można znaleźć w Warunkach użytkowania.

Właściwości

Numer ID artykułu: 283878 - Ostatnia weryfikacja: 30 lipca 2013 - Weryfikacja: 1.0
Informacje zawarte w tym artykule dotyczą:
  • Microsoft Office Access 2007
  • Microsoft Office Access 2003
  • Microsoft Access 2002 Standard Edition
Słowa kluczowe: 
kbinfo kbdesign kbdatabase kbhowto KB283878

Przekaż opinię

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com