Build it!

src/lab4.md

@@ -41,7 +41,7 @@ _primary keys_) mogą również składać się z kilku cech (lub lepiej **pól**
 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). 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
+ bez ryzyka pomyłki, w razie gdyby zmieniła nazwisko z racji wyjścia za mąż. Klucz podstawowy przywiązuje
  nasz wiersz w bazie do konkretnego obiektu istniejącego w rzeczywistości.
 
 Takie rozwiązanie od kilku lat
@@ -65,6 +65,14 @@ Tak czy inaczej, wypiszmy kilka sensownych _pól_ w takiej tabeli od obywateli:
 * Adres korespondencyjny: ulica i numer budynku oraz lokalu
 * PESEL
 * Data urodzin
+* Numer telefonu
+
+I teraz parę kwestii nazewniczych. Odnosząc się do tego konkretnego przykładu:
+* Nazwę pola, wraz z jego typem i przeznaczeniem w konkretnej tabeli nazywamy **kolumną**
+* Reprezentację obywatela w tej tabeli nazywamy **wierszem**
+* Konkretną cechę konkretnego obywatela nazywamy **polem**
+
+Numeru telefonu obywatel posiadać nie musi. Każdy bieszczadzki zakapior ma prawo do  
 
 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.
@@ -86,6 +94,7 @@ Spróbujmy więc odseparować obywatela od adresu. Otrzymamy zapewne coś takieg
 * Adres korespondencyjny - ID adresu
 * PESEL (**klucz podstawowy**)
 * Data urodzin
+* Numer telefonu (**może być pusty**)
 
 **Adres**:
 
@@ -105,14 +114,30 @@ a ktoś w piśmie wspomniał o dowodzie o określonym identyfikatorze, a w międ
 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. 
 
+Kolumnę, która stanowi klucz podstawowy w innej tabeli - czyli odnosi się do innej tabeli - nazywamy **kluczem obcym** 
+(ang. _foreign key_). W naszej tabeli _Obywatel_ mamy dwa klucze obce - oba odnoszą się do tabeli
+_Adres. Ponieważ wielu obywatelom przypisać można jeden adres, istnieje więc relacja **wiele-do-jednego**
+między tabelami *Obywatel* i *Adres*. 
 
+Po co stosuje się takie wyróżnienia? Otóż możemy bazę poinformować o istnieniu takiej relacji. Wtedy pilnować
+ona będzie spójności, czyli jeśli spróbujemy skasować adres, pod którym ktoś jednak zamieszkuje, baza
+odmówi wykonania takiego polecenia (i dobrze).
 
+Opisując kolumny w tabeli musimy również podać typ tego, co będziemy tam przechowywać. Typy zależą już
+od konkretnego oprogramowania RDBMS z którego korzystamy. Na WEiI PRz istnieje parcie na
+[Oracle Database](https://docs.oracle.com/cd/E11882_01/server.112/e41085/sqlqr06002.htm#SQLQR959), tak
+więc tej typologii rekomendowałbym się nauczyć na egzamin.
 
+Na przyszłych laboratoriach będziemy korzystać z [PostgreSQL](https://pl.wikipedia.org/wiki/PostgreSQL)
+oraz jego typów. Ponieważ istnieje [tabela konwersji typów](http://www.sqlines.com/oracle-to-postgresql) między tymi bazami, radzę
+myśleć w typach Oracle, a w locie dopasowywać sobie to do PostgreSQL. O typach PostgreSQL można zapomnieć
+po odesłaniu ostatniej instrukcji.
 
-
-
-
-
+Projektując bazę danych, dobrze jest ją sobie narysować. Służy do tego [diagram związków encji](https://pl.wikipedia.org/wiki/Diagram_zwi%C4%85zk%C3%B3w_encji)
+ lub inaczej ERD. Na egzaminie najpewniej będzie (jeśli będzie) jej wariant w postaci [notacji kruczej stopki](https://pl.wikipedia.org/wiki/Diagram_zwi%C4%85zk%C3%B3w_encji).
+ 
+    Narysuj diagram ERD dla tabel Obywatel i Adres.
+