lab4.md

Laboratorium 4

"Quidquid latine dictum, altum videtur"

---

Z tego laboratorium przygotowujesz sprawozdanie. Przygotowujesz je na zajęciach, a przy ich zakończeniu wysyłasz na adres podany na końcu tej instrukcji. Instrukcja dla wszystkich jest taka sama.

Pracę wykonujesz w grupach dwuosobowych. Dobierz sobie współpracownika. Na liście obecności zaznacz numer grupy (dwie osoby - jeden numer grupy).

Rzeczy oznaczone tak, jak poniżej, dotyczą tego, co masz zawrzeć w sprawozdaniu. Na przykład:

Zapisz swoje imię, nazwisko, adres e-mail, kierunek i rok studiów
oraz grupę laboratoryjną i numer albumu.

Wykonujesz ten wariant zadania, jaki jest numer grupy. Na przykład wariant,
który obecnie czytasz, ma numer $lp$.

Podaj również numer zajęć laboratoryjnych (nr 4).

Mogą być to też pytania, na które w sprawozdaniu udzielisz odpowiedzi. Możesz pomagać sobie wyszukiwarką internetową, oraz zabrać głos w dyskusji, jeśli się jakaś wywiąże.

Bazy relacyjne

Relacyjne bazy danych (ang. relational database management systems, RDBMS, może bardziej poprawnie system zarządzania relacyjną bazą danych), to pewien pomysł na przechowywanie danych. Pomysł ten polega na rozbiciu naszego świata w szereg takich obiektów, bytów (w żargonie bazodanowców encji, od ang. entity czyli w zasadzie byt), które będzie można wygodnie umieścić w tabelach. Obiekt taki charakteryzuje się tym, że ma swoją pewną tożsamość, po której to tożsamości będziemy go potem identyfikować i po tejże się do niego odwoływać.

Na przykład: tworząc bazę danych do celów poboru podatków w Jaśnie Oświeconej III Rzplitej, potrzebujemy listy podatników. Żeby uprościć nieco sprawę, załóżmy że rzeczona baza dotyczyć będzie tylko osób fizycznych (słowem będzie bazą PIT, od ang. personal income tax, podatek dochodowy od osób fizycznych), czyli obywateli.

Jaka cecha obywatela stanowi jego dobrą tożsamość? Imię i nazwisko niezbyt - Janów Kowalskich mamy wszak ilość znaczną. Może imię, nazwisko i data urodzenia? Też niedobrze, wszak możemy wyobrazić sobie sytuację, w której dwóch Janów Kowalskich urodziło się w tym samym dniu. Jest to dużo bardziej prawdopodobne, niż się wam wydaje. 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). 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ąż. Klucz podstawowy 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.

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ą 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
• 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.

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
• Numer telefonu (może być pusty)

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ą. W epoce baz danych NoSQL 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.

Istotne w kluczu podstawowy jest to, że w danej tabeli istnieć może tylko jeden rekord o tym kluczu. Nie jest możliwe wstawienie dwóch - mamy więc podstawowy system zapobiegający sytuacjom niemożliwym, na przykład istnieniu dwóch różnych osób o identycznym PESEL-u.

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, tak więc tej typologii rekomendowałbym się nauczyć na egzamin.

Na przyszłych laboratoriach będziemy korzystać z PostgreSQL oraz jego typów. Ponieważ istnieje tabela konwersji typów 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 lub inaczej ERD. Na egzaminie najpewniej będzie (jeśli będzie) jej wariant w postaci notacji kruczej stopki.

Użyj Google i naucz się rysować diagramy ERD w maksymalnie 15 minut. 
Narysuj diagram ERD dla tabel Obywatel i Adres.

Jeśli chcemy zamodelować relację "jedna encja posiada inne" najlepiej to zrobić właśnie na dwóch tabelach. Gdybyśmy chcieli stworzyć tabelę pt. "czy obywatel rozliczył podatek", możemy zrobić tabelę CzyRozliczyłPodatek, która wyglądać będzie mniej więcej tak:

• PESEL obywatela
• Rok fiskalny
• Czy rozliczone?

Przy czym pola PESEL i rok fiskalny stanowić będą klucz podstawowy, zaś sam PESEL - klucz obcy. Jest to dobry wybór na tożsamość tego pola, bo przecież jedna osoba rozliczyć za dany rok może się tylko raz ( albo tak myślimy). Jak tu widzimy, klucz podstawowy może się również składać z klucza obcego - bo czemu nie.