Relacje bazy danych – jak określić?
Wstęp
Jak zapewne wiesz mamy trzy typy relacji:
- jeden do jednego,
- jeden do wielu,
- wiele do wielu
Brzmi trywialnie, jednak czasami przy projektowaniu bazy danych ciężko nam określić jakiej relacji użyć. W tym artykule pragnę podsunąć Wam kilka sposobów jakie stosuję przy projektowaniu relacji i atrybutów baz danych.
Na początku: „Zen bazy danych”
Żeby zaprojektować dobrze bazę danych musisz ze skupieniem uświadomić sobie w jakim celu projektujesz bazę, kto będzie jej użytkownikiem, jakie są jego potrzeby. Użytkownikami bazy danych mogą być zarówno ludzie (projektanci, administratorzy, operatorzy) jak i programy (systemy komputerowe) lub urządzenia peryferyjne. Już na starcie projektowania musisz pamiętać, że:
„Prawidłowo zaprojektowana baza danych nie powinna zawierać żadnych zbędnych danych i powtórzeń, powinna natomiast umożliwiać efektywną pracę zaimplementowanego systemu”
Wczesny proces projektowania bazy danych nazywa się analizą wymagań. Na początku bardzo ważne jest poznać dobrze rzeczywistość w której będzie działać baza danych, oszacować koszty, określić cele przedsięwzięcia i związki z projektowaną bazą danych.
Encje i atrybuty
W kolejnym etapie należy podać definicje encji (tabel). Do opisania encji potrzebujemy: nazwy (zawsze rzeczownik) , krótkiego opisu encji, listy atrybutów, klucza głównego, kluczy kandydujących oraz charakteru encji silna (żeby istnieć nie potrzebuje innych encji) lub słaba (jest zależna od innych encji, nie może sama istnieć).
Bardzo ważnym elementem jest ustalenie typu danych oraz czy może być NULL dla każdego atrybutu encji. W tym celu polecam zrobić tabelkę:
Atrybuty dla encji STUDENT. (Na tym etapie nie ustalać klucza obcego):
Klucze kandydujące: student_id, pesel
Klucz główny: Nr
Charakter encji: encja silna
Zastanów się nad relacjami, dobierz odpowiednie klucze
Jak ustalić relację? Jak dobrać klucz obcy? Jeśli czegoś nie wiesz zawsze zadawaj sobie pytania, polecam tą metodę. Jednak teraz chcę sprzedać Wam moje HACKI jak ustalam relację i jak dobieram klucz obcy.
Na początek dobranie relacji. Jako, że najlepiej jest pokazać praktykę to ustalmy sobie pary do naszej wcześniejszej tabeli STUDENT
- STUDENT – LEGITYMACJA
- POKÓJ AKADEMICKI – STUDENT
- STUDENT – WYKŁAD
Zadawaj sobie pytania !
STUDENT – LEGITYMACJA
Czy student może mieć wiele aktywnych legitymacji, czy tylko jedną ? ODP – Jedną
Czy na jedną legitymację może być zaaresztowanych wiele studentów, czy tylko jeden? ODP – Jeden
Więc relacja jeden do jednego. Jeśli chodzi o klucz obcy to ustal go tam gdzie Tobie wygodniej.
POKÓJ AKADEMICKI – STUDENT
Czy student może być przydzielony do wielu pokoi, czy do jednego ? ODP – Jednego
Czy w jednym pokoju może mieszkać wiele studentów, czy tylko jeden? ODP – Wielu
Więc relacja jeden do wielu. Jeśli chodzi o klucz obcy to ustal go po stronie wielu.
STUDENT – WYKŁAD
Czy student może być przypisany do wielu wykładów, czy do jednego ? ODP – Wielu
Czy na jeden wykład może być przypisanych wiele studentów, czy tylko jeden? ODP – Wielu
Więc relacja wiele do wielu. Jeśli chodzi o klucz obcy to tworzymy specjalną tabelę łączącą, która zawiera klucze obce do tabeli STUDENT oraz WYKŁAD.
ER Diagram
Kolejnym krokiem jest stworzenie diagramu encji. Polecam tutaj platformę lucidchart.com . Można tam tworzyć dowolne diagramy. Dodatkowo zostały wydane filmiki instruktażowe na Youtube:
- Entity Relationship Diagram (ERD) Tutorial – Part 1
- Entity Relationship Diagram (ERD) Tutorial – Part 2
Przydatne strony
Jeśli chcesz poćwiczyć lub poczytać o SQL zapraszam do:
Na blogu polecam materiały z baz danych:
- Złączenia JOIN – Pojmij podstawy SQL !- zobacz
- Użycie GROUP BY – SQL– zobacz
- Klucze baz danych – całkowity przewodnik– zobacz
- Lista umiejętności Inżyniera danych (Data engineer)– zobacz
- Projektowanie bazy danych według zasady DRY– zobacz
Ostatecznie w zamian za dostarczoną treść, proszę więcej uśmiechu w cyfrowym świecie! 😉
