diff --git a/README.md b/README.md
index 37454e313e9ad84255749af8296f6af46ccb18ed..e8f6f9cceb4118c03e351c21b827893d4d461dcc 100644
--- a/README.md
+++ b/README.md
@@ -29,5 +29,6 @@ montowane przy użyciu [Docker](https://www.docker.com/), środowiska integracji
 systemu kontroli wersji [Git](https://git-scm.com/) oraz konwertera Markdown-PDF [pandoc](http://pandoc.org/).
 
 Wcześniej był [Vagrant](https://www.vagrantup.com) ale mi się wylały kondensatory w zasilaczu i Vagrantowa maszyna zmarła [*].
+Vagrantfile zostaje.
 
 Instrukcja Copyright (c) 2017 Piotr Maślanka. [Niektóre](/LICENSE.md) prawa zastrzeżone.
\ No newline at end of file
diff --git a/src/lab4.md b/src/lab4.md
index 28ac2066293687a55d869578ffb4f918b02fa6b7..613ec2797b0f2e607e6e61f76c15a06de6879d46 100644
--- a/src/lab4.md
+++ b/src/lab4.md
@@ -39,14 +39,77 @@ Takie _tożsamości_, lub lepiej **klucze podstawowe** (ang.
 _primary keys_) mogą również składać się z kilku cech (lub lepiej **pól**, ang. _fields_).
 
 Wydaje się po dłuższych deliberacjach że dobrym kluczem podstawowym będzie tu PESEL obywatela. Ryzyko pomyłki
-z innym obywatelem jest minimalne (chyba że aktualnie jesteśmy komornikiem). Takie rozwiązanie od kilku lat
+z innym obywatelem jest minimalne (chyba że aktualnie jesteśmy komornikiem). Dzięki takiej _tożsamości_
+ możemy potem kazać bazie chociażby _zmień nazwisko osobie legitymującej się numerem PESEL 95101810106_
+ bez ryzyka pomyłki, w razie gdyby zmieniła nazwisko z racji wyjścia za mąż. Pole podstawowe przywiązuje
+ nasz wiersz w bazie do konkretnego obiektu istniejącego w rzeczywistości.
+
+Takie rozwiązanie od kilku lat
 już zastosowano, dzięki czemu ilość druków NIP-7 w obrocie znacznie spadła, a Panowie zapewne do swojego
-rocznego rozliczenia podatkowego nie wpisywali żadnych NIP-ów, bo wystarczył PESEL.
+rocznego rozliczenia podatkowego nie wpisywali żadnych NIP-ów, bo wystarczył PESEL. 
 
 Pominę tu pytanie jaki klucz podstawowy należy zastosować do konkretnego, rocznego rozliczenia podatkowego,
 gdyż ze względu na 
 [mnogość możliwych sposobów rozliczeń przewidzianych stosowną ustawą](http://isap.sejm.gov.pl/Download;jsessionid=DEE94711477213D50C7A580724D3176C?id=WDU19910800350&type=3)
-stanowi to Bardzo Dobre Pytanie. **Zwalniam z zaliczenia jak ktoś ma dobry i wyczerpujący pomysł**
+stanowi to Bardzo Dobre Pytanie. **Zwalniam z zaliczenia jak ktoś ma dobry i wyczerpujący pomysł**.
+
+Tak czy inaczej, wypiszmy kilka sensownych _pĂłl_ w takiej tabeli od obywateli:
+
+* Imię
+* Nazwisko
+* Adres zameldowania: miasto
+* Adres zameldowania: kod pocztowy
+* Adres zameldowania: ulica i numer budynku oraz lokalu
+* Adres korespondencyjny: miasto
+* Adres korespondencyjny: kod pocztowy
+* Adres korespondencyjny: ulica i numer budynku oraz lokalu
+* PESEL
+* Data urodzin
+
+Od razu zauważyć możemy, że trzymanie dwóch _adresów_. nie jest takim dobrym pomysłem. Analityczny umysł
+zauważyć może, że adres jest pewnym _bytem samym w sobie_. Możemy więc stworzyć osobną tabelę do przechowywania adresów.
+ 
+Powstaje z kolei bardzo dobre pytanie, co stanowi _tożsamość_ danego adresu. Czasem, gdy nie mamy dobrego
+pomysłu na tożsamość możemy zażyczyć sobie, aby baza danych stworzyła osobną tożsamość dla danego wiersza.
+Później, gdy będziemy dodawać rekord, baza poinformuje nas o tym identyfikatorze.
+
+Musimy jednak uważać! Dla potrzeb bazy dwa identycznie wpisane adresy będą _różnymi_, ponieważ bedą miały
+różne identyfikatory (chyba że nie poinformujemy o tym bazy). Czasem jednak możemy to przecierpieć.
+
+Spróbujmy więc odseparować obywatela od adresu. Otrzymamy zapewne coś takiego:
+
+**Obywatel**:
+* Imię
+* Nazwisko
+* Adres zameldowania - ID adresu
+* Adres korespondencyjny - ID adresu
+* PESEL (**klucz podstawowy**)
+* Data urodzin
+
+**Adres**:
+* Identyfikator adresu (**klucz podstawowy**, **generowany automatycznie**)
+* Miasto
+* Kod pocztowy
+* Ulica i numer lokalu/budynku
+
+Można sprzeczać się, że taki podział nie miał najmniejszego sensu. To możliwe. W każdym razie to co zrobiliśmy
+teraz nazywa się [normalizacją](https://pl.wikipedia.org/wiki/Normalizacja_bazy_danych). W epoce baz danych 
+[NoSQL](https://msdn.microsoft.com/pl-pl/dn912483.aspx) staje się ona coraz bardziej zagadnieniem jedynie akademickim,
+jednak mam wrażenie że będzie na egzaminie.
+
+Identyfikatory generowane przez bazę najczęściej są rosnącymi liczbami dodatnimi i **nie powtarzają się**,
+nawet gdybyśmy skasowali wiersz. Ma to sens. W końcu gdybyśmy prowadzili policyjną kartotekę dowodów rzeczowych,
+a ktoś w piśmie wspomniał o dowodzie o określonym identyfikatorze, a w międzyczasie ten dowód został zniszczony ze względu na koniec sprawy,
+to teraz jego papier mógłby się odwoływać do *istniejącego dowodu w innej sprawie*, a nie po prostu do *niczego*.
+Byłoby to katastrofalne w skutkach, a błąd programisty mógłby kosztować kogoś pozbawienie wolności. 
+
+
+
+
+
+
+
+