ZAWODNIK

Normalizacja: 1NF, 2NF i 3NF na jednym przykładzie

INF.03 · teoria
autor: redakcja · 07.09.2026 · aktualizacja: 08.09.2026
Czym jest normalizacja, jak wyglądają pierwsza, druga i trzecia postać normalna na jednym przykładzie sklepowego arkusza i jak rozpoznać postać normalną tabeli pokazanej w pytaniu. Lekcja 7.4 kursu INF.03.

[ INF.03: PYTANIA Z TEGO DZIAŁU ]

Przejrzyj pytania: bazy-danychĆwicz dział: bazy-danych
Nor­ma­li­za­cja to proces or­ga­ni­zo­wa­nia danych w bazie, po­le­ga­ją­cy na wy­eli­mi­no­wa­niu nad­mia­ro­wych danych oraz nie­spój­nych za­leż­no­ści: dzie­lisz jedną wielką tabelę na kilka mniej­szych tak, żeby każda in­for­ma­cja była za­pi­sa­na raz i żeby zmiana jednej rzeczy wy­ma­ga­ła po­praw­ki w jednym miej­scu. Na eg­za­mi­nie pi­sem­nym wraca w dwóch kształ­tach: py­ta­nie o samą de­fi­ni­cję i py­ta­nie z ry­sun­kiem tabeli, w którym trzeba po­wie­dzieć, w której po­sta­ci nor­mal­nej ta tabela jest. Cała lekcja idzie za jednym przy­kła­dem: arkusz kal­ku­la­cyj­ny sklepu za­mie­nia się krok po kroku w bazę z pię­cio­ma ta­be­la­mi.

Arkusz, od któ­re­go za­czy­na­my

Sklep przez rok pro­wa­dził za­mó­wie­nia w ar­ku­szu kal­ku­la­cyj­nym. Jeden wiersz to jedno za­mó­wie­nie, wszyst­ko w jednej tabeli.
[ ARKUSZ PRZED NORMALIZACJĄ ]
nr
klient
miasto
kod
te­le­fo­ny
pro­duk­ty
ceny
10
Anna
Kraków
30-001
600100100, 600100101
Mo­ni­tor 24
650
11
Anna
Kraków
30-001
600100100, 600100101
Kla­wia­tu­ra, Mysz
120, 45
12
Piotr
Gdańsk
80-001
500200200
Kabel HDMI
25
Taka struk­tu­ra z jedną tabelą to model jed­no­rod­ny, zwany też pła­skim. Działa, dopóki wier­szy jest kil­ka­na­ście. Przy kilku ty­sią­cach za­czy­na się psuć, i to w sposób, który pod­sta­wa pro­gra­mo­wa i eg­za­min na­zy­wa­ją po imie­niu.

Nad­mia­ro­wość i trzy ano­ma­lie

Re­dun­dan­cja (redundancy, nad­mia­ro­wość) to ta sama in­for­ma­cja za­pi­sa­na w bazie więcej niż raz. Tutaj widać ją gołym okiem: imię Anny, jej miasto, kod pocz­to­wy i oba te­le­fo­ny po­wta­rza­ją się w każdym jej za­mó­wie­niu. Zaj­mo­wa­nie miej­sca to naj­mniej­szy pro­blem. Gorsze są trzy ano­ma­lie, czyli sy­tu­acje, w któ­rych zwykła ope­ra­cja na danych psuje bazę.
  • ›
    Ano­ma­lia ak­tu­ali­za­cji: Anna prze­pro­wa­dza się do Gdyni, więc trzeba po­pra­wić miasto w KAŻDYM jej wier­szu. Jeżeli jeden zo­sta­nie po­mi­nię­ty, baza twier­dzi jed­no­cze­śnie, że Anna miesz­ka w Kra­ko­wie i w Gdyni. To jest wła­śnie nie­spój­ność z de­fi­ni­cji nor­ma­li­za­cji.
  • ›
    Ano­ma­lia wsta­wia­nia: do sklepu za­pi­su­je się nowy klient, który jesz­cze nic nie kupił. Nie ma go gdzie wpisać, bo wiersz ist­nie­je tylko razem z za­mó­wie­niem.
  • ›
    Ano­ma­lia usu­wa­nia: ktoś kasuje zwró­co­ne za­mó­wie­nie 12. Razem z nim znika jedyny ślad po Pio­trze: jego miasto, kod i te­le­fon.
Za wszyst­ki­mi trzema stoi jedno po­ję­cie. Za­leż­ność funk­cyj­na (functional dependency) to sy­tu­acja, w której znając war­tość jednej ko­lum­ny, znasz war­tość dru­giej. Znając numer za­mó­wie­nia, znasz jego klien­ta. Znając klien­ta, znasz jego miasto. Znając kod pocz­to­wy, znasz miasto. Nor­ma­li­za­cja polega na tym, żeby każdą taką za­leż­ność za­pi­sać w osob­nej tabeli, w której lewa strona za­leż­no­ści jest klu­czem głów­nym.

1NF: jedna war­tość w jednym polu

Pierw­sza postać nor­mal­na (1NF) wymaga trzech rzeczy: każde pole ma do­kład­nie JEDNĄ war­tość (ato­mo­wość), nie ma po­wta­rza­ją­cych się grup kolumn w ro­dza­ju telefon1, telefon2, telefon3, a tabela ma klucz główny. Arkusz łamie pierw­szy wa­ru­nek w trzech ko­lum­nach naraz: telefony, produkty i ceny trzy­ma­ją listy roz­dzie­lo­ne prze­cin­ka­mi.
Listę roz­bi­ja się na wier­sze albo na osobną tabelę. Pro­duk­ty i ceny idą na wier­sze: jedno za­mó­wie­nie zaj­mu­je teraz tyle wier­szy, ile ma po­zy­cji. Te­le­fo­ny wy­cho­dzą do wła­snej tabeli, bo z za­mó­wie­niem nie mają nic wspól­ne­go.
nr
klient
miasto
kod
pro­dukt
cena
ilosc
10
Anna
Kraków
30-001
Mo­ni­tor 24
650
1
11
Anna
Kraków
30-001
Kla­wia­tu­ra
120
2
11
Anna
Kraków
30-001
Mysz
45
1
12
Piotr
Gdańsk
80-001
Kabel HDMI
25
3
Sam nr nie jest już klu­czem głów­nym, bo numer 11 stoi w dwóch wier­szach. Wiersz iden­ty­fi­ku­je do­pie­ro para nr i produkt, czyli klucz zło­żo­ny. Obok po­wsta­je druga tabela, w której jeden wiersz to jeden numer te­le­fo­nu:
klient
numer
Anna
600100100
Anna
600100101
Piotr
500200200
Ko­lum­na klient zmieni się w klient_id, kiedy klien­ci do­sta­ną własną tabelę z nu­me­ra­mi. Tabela jest w 1NF, a mimo to Anna nadal siedzi w trzech wier­szach. Nad­mia­ro­wość zo­sta­ła, więc to nie koniec.

2NF: za­leż­ność od całego klucza

Druga postać nor­mal­na (2NF) to 1NF plus wa­ru­nek: każdy atry­but nie­klu­czo­wy zależy od CAŁEGO klucza głów­ne­go, a nie od jego części. Do­ty­czy wy­łącz­nie tabel z klu­czem zło­żo­nym, bo tylko taki klucz ma części. Tabela z klu­czem jed­no­ko­lum­no­wym, która jest w 1NF, jest już w 2NF.
Klucz to tutaj nr plus produkt. Spraw­dza­my po kolei każdą po­zo­sta­łą ko­lum­nę:
Ko­lum­na
Od czego na­praw­dę zależy
Wnio­sek
klient, miasto, kod
od samego nr
za­leż­ność od części klucza, do wy­nie­sie­nia
cena
od samego produkt
za­leż­ność od części klucza, do wy­nie­sie­nia
ilosc
od nr i produkt razem
zo­sta­je na miej­scu
Ko­lum­ny za­leż­ne od części klucza wy­pro­wa­dza się do tabel, w któ­rych ta część jest klu­czem głów­nym. Po­wsta­ją trzy tabele za­miast jednej:
zamowienie(nr PK, klient, miasto, kod) produkt(id PK, nazwa, cena, kategoria) pozycja(zamowienie_id, produkt_id, ilosc) klucz główny złożony
Pro­duk­ty prze­sta­ły być tek­stem wpi­sy­wa­nym za każdym razem od nowa i stały się słow­ni­kiem z wła­sny­mi nu­me­ra­mi, więc pozycja wska­zu­je na nie klu­czem obcym produkt_id. Skoro sklep opi­su­je też, do jakiej grupy towar należy, ko­lum­na kategoria trafia do produkt razem z nazwą i ceną. Zmiana ceny mo­ni­to­ra to teraz jedno po­le­ce­nie UPDATE na jednym wier­szu.

3NF: koniec za­leż­no­ści prze­chod­nich

Trze­cia postać nor­mal­na (3NF) to 2NF plus wa­ru­nek: żaden atry­but nie­klu­czo­wy nie zależy od innego atry­bu­tu nie­klu­czo­we­go. Taka za­leż­ność „na dwa skoki" nazywa się za­leż­no­ścią prze­chod­nią.
W tabeli zamowienie klu­czem jest nr. Ko­lum­ny miasto i kod nie mówią nic o za­mó­wie­niu, mówią o klien­cie: znając nr, znasz klient, a znając klient, znasz jego miasto. Klient wy­cho­dzi więc do wła­snej tabeli, a w za­mó­wie­niu zo­sta­je po nim klucz obcy.
Ta sama reguła działa piętro niżej. W tabeli klient miasto zależy od kodu pocz­to­we­go, a nie od numeru klien­ta: kod 30-001 to zawsze Kraków. Pu­ry­sta wy­nie­sie to do tabeli kod_pocztowy(kod PK, miasto). W małych bazach, także w tych z ar­ku­szy eg­za­mi­na­cyj­nych, zwykle zo­sta­wia się miasto przy klien­cie i na tym po­prze­sta­je, bo osobna tabela na kody pocz­to­we wymaga utrzy­my­wa­nia całego ich spisu. Tak samo z ka­te­go­rią: jeżeli ka­te­go­ria ma własne dane, na przy­kład opis albo stawkę po­dat­ku, robi się z niej tabela kategoria, a produkt do­sta­je kategoria_id.
klient(id PK, imie, miasto, kod) telefon(id PK, klient_id FK, numer) produkt(id PK, nazwa, cena, kategoria) zamowienie(id PK, klient_id FK) pozycja(zamowienie_id FK, produkt_id FK, ilosc)
Po lewej jedna tabela zamowienia_arkusz z powtórzonymi danymi klienta i produktami wpisanymi po przecinku, po prawej cztery tabele po normalizacji połączone strzałkami po kluczach
To jest do­kład­nie sche­mat bazy sklep, na której stoi cały dział o SQL, z jednym uprosz­cze­niem: tam zamowienie trzyma produkt_id i ilosc bez­po­śred­nio, bez tabeli pozycja, bo w kursie jedno za­mó­wie­nie ma jeden pro­dukt. Taka baza ma wszyst­kie cechy re­la­cyj­nej bazy danych: dane siedzą w ta­be­lach, każdy wiersz iden­ty­fi­ku­je klucz główny o war­to­ści uni­kal­nej i różnej od NULL, tabele wiążą klucze obce, a każda in­for­ma­cja jest za­pi­sa­na w jednym miej­scu.
Wy­ko­naj za­py­ta­nie, które składa trzy tabele z po­wro­tem w jeden arkusz, i po­rów­naj wynik z tabelą z po­cząt­ku lekcji:
[ SQL ]
baza: sklep
zapytanie
169/4000
Otwórz w placu zabaw ›
Złą­cze­nia opi­su­je lekcja o JOIN, a same klucze i re­la­cje lekcje o en­cjach i klu­czach oraz o re­la­cjach i dia­gra­mach E/R.

Kiedy prze­stać dzie­lić

Po­sta­ci nor­mal­nych jest więcej: po 3NF idzie postać Boyce'a i Codda (BCNF), a za nią 4NF i 5NF. Do eg­za­mi­nu INF.03 po­trzeb­ne są trzy pierw­sze i ich nazwy w ko­lej­no­ści.
W drugą stronę działa de­nor­ma­li­za­cja, czyli świa­do­me cof­nię­cie części po­dzia­łu. Kla­sycz­ny przy­kład jest w tym samym skle­pie: cena pro­duk­tu z czasem się zmie­nia, a fak­tu­ra sprzed roku ma po­ka­zy­wać cenę sprzed roku, więc do tabeli pozycja ko­piu­je się cenę z chwili zakupu. For­mal­nie to nad­mia­ro­wość, w prak­ty­ce jedyny sposób na cenę hi­sto­rycz­ną.
Pu­łap­ka: de­nor­ma­li­za­cja jest wy­jąt­kiem, któ­re­go na eg­za­mi­nie się nie zga­du­je. Gdy py­ta­nie brzmi „jak po­win­na wy­glą­dać ta baza", ocze­ki­wa­ną od­po­wie­dzią jest baza znor­ma­li­zo­wa­na do trze­ciej po­sta­ci nor­mal­nej.

Na eg­za­mi­nie

Py­ta­nie pi­sem­ne po­ka­zu­je jedną tabelę z danymi i pyta, co można po­wie­dzieć o jej nor­ma­li­za­cji. Zadaj sobie trzy py­ta­nia, zawsze w tej ko­lej­no­ści:
  • 1.
    Czy w któ­rymś polu jest lista war­to­ści po prze­cin­ku albo czy po­wta­rza się grupa kolumn (telefon1, telefon2)? Jeżeli tak, tabela nie jest nawet w 1NF.
  • 2.
    Czy klucz główny jest zło­żo­ny i któraś ko­lum­na zależy tylko od jego części? Jeżeli tak, tabela jest w 1NF, ale nie w 2NF.
  • 3.
    Czy któraś ko­lum­na nie­klu­czo­wa zależy od innej ko­lum­ny nie­klu­czo­wej, na przy­kład miasto od kodu pocz­to­we­go? Jeżeli tak, tabela jest w 2NF, ale nie w 3NF.
Pierw­sze „nie" kończy spraw­dza­nie: tabela jest w tej po­sta­ci, przed którą się za­trzy­ma­łeś. Dwa po­zo­sta­łe kształ­ty pytań to de­fi­ni­cja („proces eli­mi­nu­ją­cy nad­mia­ro­we dane i nie­spój­ne za­leż­no­ści" to nor­ma­li­za­cja) i py­ta­nie o po­je­dyn­czy wa­ru­nek: ato­mo­wo­ści pól wymaga pierw­sza postać nor­mal­na, a za­leż­ność prze­chod­nią usuwa trze­cia.
W za­da­niu prak­tycz­nym nor­ma­li­za­cji się nie prze­pro­wa­dza, bo baza z ar­ku­sza jest już po­dzie­lo­na na tabele i podana razem ze sche­ma­tem re­la­cji. Warto jednak wie­dzieć, skąd ten po­dział się wziął: wła­śnie dla­te­go dane jed­ne­go za­mó­wie­nia leżą w trzech ta­be­lach i dla­te­go jedna z kwe­rend musi „wy­ko­rzy­sty­wać re­la­cję", czyli łączyć tabele po kluczu obcym.
Pu­łap­ka: ko­lej­ność etapów pro­jek­to­wa­nia bazy z pytań eg­za­mi­na­cyj­nych brzmi: okre­śle­nie zbioru danych, po­dział na tabele, okre­śle­nie kluczy pod­sta­wo­wych, okre­śle­nie re­la­cji. Nor­ma­li­za­cja siedzi w kroku drugim i trze­cim, a nie na końcu.

Ściąga

Postać
Wa­ru­nek
Sygnał, że tabela go łamie
Co zrobić
1NF
jedna war­tość w polu, brak po­wta­rza­ją­cych się grup kolumn, jest klucz główny
war­to­ści po prze­cin­ku w ko­mór­ce, ko­lum­ny telefon1 i telefon2
rozbić listę na osobne wier­sze albo na osobną tabelę
2NF
1NF plus każda ko­lum­na nie­klu­czo­wa zależy od całego klucza
klucz zło­żo­ny, a ko­lum­na zależy tylko od jednej jego części
wy­nieść tę ko­lum­nę do tabeli, w której ta część jest klu­czem głów­nym
3NF
2NF plus brak za­leż­no­ści prze­chod­nich
ko­lum­na nie­klu­czo­wa zależy od innej nie­klu­czo­wej, miasto od kodu
wy­nieść obie do osob­nej tabeli, zo­sta­wić klucz obcy
Pobierz ściągę PDF

[ W TYM DZIALE ]

poprzednia: Relacje 1:1, 1:N, N:M i diagramy E/R: Chen, krucza stopka, UMLnastępna: SZBD: MySQL i MariaDB, PostgreSQL, SQLite, MS SQL; XAMPP i phpMyAdminspis działu: Bazy danych: projektowanie

[ INF.03: INNE ARTYKUŁY ]

Hub INF.03Zakres materiałuBazy danych i SQL na egzaminie INF.03CSS na egzaminie INF.03Formularze HTML na egzaminie INF.03Grafika i multimedia na egzaminie INF.03HTML na egzaminie INF.03pokaż więcej (39)
ZAWODNIK
egzamin zawodowy INF.02 · INF.03 · INF.04
Serwer Discord›
Egzaminy zawodowe IT/Matury/Studia
@yastor
Polityka prywatnościRegulamin
© 2026 Zawodnik · by Yastor
Arkusze i zasady oceniania pochodzą z CKE. Serwis nie jest powiązany z Centralną Komisją Egzaminacyjną.