Wprowadzenie
Na dzisiejszych zajęciach kontynuujemy zagadnienia związane z diagramem związków encji. Poruszymy tematykę relacji pomiędzy encjami oraz ich ograniczeniami.
Constraints
Ograniczenia, opisują reguły dla danych w tabeli, w celu zapewniania ich wiarygodności i dokładności. Poniżej znajduje się przykładowa lista ograniczeń, które są wykorzystywane w PostgresSQL:
- Check - jeden z najbardziej generycznych typów ograniczeń. Jego celem jest zapewnienie że wartość danej kolumny spełni warunek logiczny
- Not null - ograniczenie, wskazujące że wartość w danej tabeli nie może być nullem
- Unique - wartość występująca w kolumnie, musi być unikalna wobec innych wierszy w tej kolumnie
- Primary key - klucz główny, wskazujący że wartość w kolumnie jest identyfikatorem krotki
- Foreign key - klucz obcy, wskazuje że kolumna musi pasować do wartości w kolumnie innej tabeli
Relacje
Relacjami nazywami związki pomiędzy encjami. Mogą być one definiowane na za pomocą par kolumn, grup kolumn oraz przy pomocy tabel assocjacyjnych.
Crows foot notation / Martin notation
Jest to notacja, wykorzystywana do modelowania relacji w diagramie związków encji. Przybiera ona formę linii łączącymi dwie tabele. W zależności od typu relacji, zakończona jest ona linią pojedynczą, bądź też tzw. ptasią stopką. W notacji, relacje obowiązkowe oznaczone są znakiem |, a opcjonalne o.
One-to-one
Relacja jeden do jednego jest wtedy, kiedy rekord jednej tabeli powiązany jest tylko z jednym rekordem drugiej tabeli. Związki jeden to jednego, w diagramach ERD, oznaczamy jedną pojedynczą linią. Są one rzadko spotykane/używane.
Przykładem obowiązkowej (mandatory) relacji jeden do jednego (1:1), jest przykład powiązania tabeli kraj ze stolicą. Kraj może mieć tylko jedną stolicę, a stolica tylko jeden kraj.
Drugą opcją powiązań one-to-one, jest relacja opcjonalna (optional, 1:0..1). Przykładem takiej relacji może być powiązanie tabeli mieszkania z adresem. Mieszkanie musi mieć przypisane adres, natomiast sam adres nie musi być przypisany do mieszkania.
One to many
Relacje jeden do wielu (1:N), należą do najpopularniejszych. Oznaczają one, związek w którym jeden rekord w jednej tabeli (często nazywany tabelą parent), jest powiązany z kilkoma rekordami w drugiej (child) tabeli. W diagramach związków encji, relacje one-to-many oznaczone są poprzez jedną pojedynczą linię, zakończoną tzw. ptasią stopką.
Przykładem opcjonalnej relacji jeden do wielu (1:0..N) jest relacja klient-zamówienia. Klient może mieć wiele zamówień, natomiast zamówienie przypisane jest tylko do pojedynczego klienta. Z kolei nowy klient, nie musi mieć przypisanego żadnego zamówienia, jeśli takiego nie złożył.
Przykładem obowiązkowej relacji jeden do wielu (1:1..N) jest relacja pomiędzy tabelami uczeń i klasa. Uczeń zawsze chodzi do jednej klasy, natomiast klasa ma wielu uczniów.
Many to many
Relacja many-to-many, czyli wiele do wielu, jest najtrudniejszą i najbardziej podchwytliwą do zaprezentowania. Relacje ta dochodzi do skutku, w momencie kiedy wiele rekordów jednej tabeli, ma związek z wieloma rekordami drugiej. W diagramach ERD, many-to-many oznaczone jest jedną pojedynczą linią rozpoczynającą się i konczącą tzw. ptasią stopką.
Jednym z najprostszych relacji many-to-many jest przykład związku, jaki może być pomiędzy tabelami, reprezentującymi prowadzącego zajęcia oraz przedmioty uczelniane. Prowadzący może uczyć wielu przedmiotów, jak i dany przedmiot może mieć wielu prowadzących.
Relacje many-to-many nie są idealne. Gdyby pozostawić je tak, jak w powyższym przykładzie, dane zostałyby powielone. Jeśli istniałby prowadzący, który uczy trzech przedmiotów, to byłby on wymieniony w tabeli aż trzy razy, za każdym razem dla innego przedmiotu. Te podejście, gryzie się z zasadami dobrego projektowania bazy danych. Zaczyna pojawiać się redundancja, dane nie są unikalne. Rozwiązaniem tego problemu są tzw. tabele asocjacyjne. Są one swoistym łącznikiem relacji wiele do wielu. Tabele te rozwiązują problem poprzez zastąpienie relacji many-to-many na kilka relacji one-to-many.
Tabela asocjacyjna, tak jak w powyższym przykładzie, przyjmuje za atrybuty tabeli, identyfikatory encji, które jednocześnie są kluczami głównymi i obcymi. Nazwy tych tabel, zazwyczaj powstają poprzez połączenie nazw tabel, pomiędzy którymi występuje mapowana relacja wiele do wielu.
Zadania
- Dla dowolnego tematu, zaprojektuj w programie draw.io diagramy ERD przedstawiające:
- relację one-to-one (1:1 lub 1:0..1)
- relację one-to-many (1:1..N)
- relację one-to-many (1:0..N)
- relację many-to-many (1..N:1..N lub 0..N:0..N)
Diagramy powinny zawierać uzupełnione atrybuty tabel wraz typem danych oraz oraz z ograniczeniami (constraints). Gotowe diagramy, zapisz w formacie HTML. Opublikuj je na swoim Githubie, w stworzynym na poprzednich zajęciach repozytorium. Prace, powinny znajdować się w folderze lab02 (uprzednio utwórz ten folder)
- Wróć do skryptu z pierwszych laboratoriów. Znajdziesz tam przykład diagramu ERD dla aplikacji wynajmuju mieszkań. Przenieś ją do draw.io zakładając że:
- Apartament może mieć wiele zdjęć, a zdjęcie jedno mieszkanie
- Wynajmujący może mieć wiele mieszkań, ale mieszkanie jednego wynajmującego
- Najemca może mieć jedno mieszkanie i mieszkanie jednego najemce
- Mieszkanie może mieć tylko jeden adres i adres może ale nie musi być przypisany do mieszkania
- Wynajmujący oraz najemca mogą być przypisani tylko do jednego konta
- Konto może być przypisane tylko do jednego adresu, ale adres do wielu kont
Gotowy diagram wyeksportuj do HTML i zapisz na GitHubie.