Relacja jeden-do-wielu w bazie danych występuje, gdy każdy rekord w Tabeli A może mieć wiele połączonych rekordów w Tabeli B, ale każdy rekord w Tabeli B może mieć tylko jeden odpowiadający rekord w Tabeli A.
Relacja jeden-do-wielu w bazie danych jest najczęstszym projektem relacyjnej bazy danych i stanowi sedno dobrego projektu.
Bazy danych mogą również implementować relacje jeden-do-jednego i wiele-do-wielu.
Przykład relacji jeden-do-wielu
Rozważ relację między nauczycielem a kursami, które prowadzą. Nauczyciel może uczyć wielu klas, ale kurs nie będzie miał takiej samej relacji z nauczycielem.
Dlatego dla każdego rekordu w tabeli Nauczyciele może być wiele rekordów w tabeli Kursy. Ten przykład ilustruje relację jeden-do-wielu: jeden nauczyciel do wielu kursów.
Dlaczego nawiązanie relacji jeden-do-wielu jest ważne
Aby przedstawić relację jeden-do-wielu, potrzebujesz co najmniej dwóch tabel. Zobaczmy dlaczego.
Zgodność z projektem pierwszej formy normalnej
Być może stworzyliśmy tabelę, w której chcemy zapisać nazwę i nauczane kursy. Możemy zaprojektować tabelę Nauczyciele i Kursy w następujący sposób:
| ID_nauczyciela | Nazwa_nauczyciela | Kurs |
|---|---|---|
| Nauczyciel_001 | Carmen | Biologia |
| Nauczyciel_002 | Weronika | Matematyka |
| Nauczyciel_003 | Jorge | Angielski |
Co jeśli Carmen prowadzi dwa lub więcej kursów? W przypadku tego projektu mamy dwie opcje. Moglibyśmy dodać to do istniejącego rekordu Carmen w następujący sposób:
| ID_nauczyciela | Nauczyciel_Imię | Kurs |
|---|---|---|
| Nauczyciel_001 | Carmen | Biologia, matematyka |
| Nauczyciel_002 | Weronika | Matematyka |
| Nauczyciel_003 | Jorge | Angielski |
Jednak powyższy projekt jest nieelastyczny i może powodować problemy podczas wstawiania, edytowania lub usuwania danych. Utrudnia to wyszukiwanie danych.
Ten projekt narusza również pierwszą zasadę normalizacji bazy danych, First Normal Form (1NF), która stanowi, że każda komórka tabeli powinna zawierać pojedynczy, dyskretny fragment danych.
Druga reguła postaci normalnej
Inną alternatywą projektową może być dodanie drugiego rekordu dla Carmen:
| Nauczyciel_ID | Nauczyciel_Imię | Kurs |
|---|---|---|
| Nauczyciel_001 | Carmen | Biologia |
| Nauczyciel_001 | Carmen | Matematyka |
| Nauczyciel_002 | Weronika | Matematyka |
| Nauczyciel_003 | Jorge | Angielski |
To podejście jest zgodne z 1NF, ale nadal jest słabym projektem bazy danych, ponieważ wprowadza nadmiarowość i może niepotrzebnie rozsadzać dużą bazę danych. Co ważniejsze, dane mogą stać się niespójne.
Na przykład, co się stanie, jeśli imię Carmen się zmieni? Ktoś pracujący z danymi może zaktualizować swoje imię i nazwisko w jednym rekordzie i nie zaktualizować go w drugim rekordzie.
Ten projekt narusza standard Second Normal Form (2NF), który jest zgodny z 1NF i musi również unikać nadmiarowości wielu rekordów. Reguła 2NF osiąga to poprzez rozdzielanie podzbiorów danych w wielu tabelach i tworzenie relacji między nimi.
Jak zaprojektować bazę danych z relacjami jeden-do-wielu
Aby zaimplementować relację jeden-do-wielu w tabeli Nauczyciele i Kursy, podziel je na dwie i połącz je za pomocą klucza obcego.
Tutaj usunęliśmy kolumnę Kurs w tabeli Nauczyciele:
| Nauczyciel_ID | Nauczyciel_Imię |
|---|---|
| Nauczyciel_001 | Carmen |
| Nauczyciel_002 | Weronika |
| Nauczyciel_003 | Jorge |
A oto tabela Kursy. Zwróć uwagę, że jego klucz obcy, Teacher_ID, łączy kurs z nauczycielem w tabeli Nauczyciele:
| ID_kursu | Nazwa_kursu | ID_nauczyciela |
|---|---|---|
| Kurs_001 | Biologia | Nauczyciel_001 |
| Kurs_002 | Matematyka | Nauczyciel_001 |
| Kurs_003 | Angielski | Nauczyciel_003 |
Opracowaliśmy relację między tabelą Nauczyciele a tabelą Kursy za pomocą klucza obcego. Ten układ mówi nam, że Carmen uczy zarówno biologii, jak i matematyki, a Jorge uczy angielskiego.
Widzimy, jak ten projekt pozwala uniknąć ewentualnych zwolnień, umożliwia poszczególnym nauczycielom prowadzenie wielu kursów i wdraża relację jeden-do-wielu.
