Projektowanie koncepcyjne – model ER (Entity-Relationship)
Analiza wymagań użytkownika
Każdy projekt bazy danych zaczyna się od zrozumienia czego oczekuje użytkownik. Bez tego łatwo stworzyć system, który jest poprawny technicznie, ale bezużyteczny w praktyce.
Przykład 1 – biblioteka
Biblioteka chce mieć system, który przechowuje dane o:
- książkach (tytuł, autor, rok wydania, ISBN),
- czytelnikach (imię, nazwisko, numer karty bibliotecznej),
- wypożyczeniach (jaka książka, który czytelnik, kiedy wypożyczona i kiedy oddana).
Przykład 2 – sklep internetowy
Sklep potrzebuje informacji o:
- klientach (imię, adres, e-mail),
- produktach (nazwa, cena, kategoria),
- zamówieniach (który klient, jakie produkty, kiedy złożono, status zamówienia).
👉 Zwróć uwagę:
- w bibliotece najważniejszy jest związek wypożyczeń,
- w sklepie – związek zamówień.
Już na tym etapie widać, że kluczowe są powiązania, a nie tylko same dane.
Diagramy encja–związek
Model ERD (Entity–Relationship Diagram) pozwala w przejrzysty sposób przedstawić jakie obiekty istnieją w systemie i jak są ze sobą powiązane.
- Encje rysujemy jako prostokąty.
- Przykład: „Student”, „Książka”, „Zamówienie”.
- Atrybuty zapisujemy jako elipsy i łączymy z encją.
- „Student” → Imię, Nazwisko, NrIndeksu.
- Związki przedstawiamy jako romby.
- „Student” \(\to\) „Wypożycza” \(\to\) „Książka”.
Przykład wizualny do opowiedzenia:
- Wyobraźcie sobie trzy prostokąty: „Student”, „Książka” i „Bibliotekarz”.
- Łączymy je rombem „Wypożycza”.
- Dodajemy atrybuty: do studenta „NrIndeksu”, do książki „ISBN”, a do związku „Data wypożyczenia”.
👉 Dzięki temu widzimy nie tylko obiekty, ale i relacje między nimi.
⸻
Typy związków
Związek 1:1 (jeden do jednego)
- Każdy obiekt jednej encji odpowiada najwyżej jednemu obiektowi drugiej encji.
- Przykład: każdy człowiek ma jedno unikalne PESEL.
Związek 1:N (jeden do wielu)
- Jeden obiekt encji A może być powiązany z wieloma obiektami encji B, ale nie odwrotnie.
- Przykład: jeden wykładowca prowadzi wiele kursów, ale każdy kurs ma dokładnie jednego prowadzącego.
Związek N:M (wiele do wielu)
- Jeden obiekt encji A może być powiązany z wieloma obiektami encji B i odwrotnie.
- Przykład: studenci zapisują się na wiele kursów, a każdy kurs realizowany jest przez wielu studentów.
Mini-case: kino
- Encje: „Film”, „Widz”, „Seans”.
- Widzowie mogą oglądać wiele filmów, a każdy film może być oglądany przez wielu widzów. To klasyczne N:M.
Atrybuty proste, złożone, wielowartościowe
- Atrybut prosty – nie da się go podzielić: „Data urodzenia”, „PESEL”.
- Atrybut złożony – składa się z mniejszych: „Adres” → „Ulica”, „Kod pocztowy”, „Miasto”.
- Atrybut wielowartościowy – może mieć wiele wartości dla jednej encji: „Numery telefonów” dla jednego studenta.
👉 To ważne, bo w późniejszym projektowaniu relacyjnym atrybut wielowartościowy często trzeba przekształcić w oddzielną tabelę.
Przykład:
- Student może mieć wiele adresów e-mail.
- W modelu ER narysujemy atrybut „Email” jako elipsę podwójną.
- W modelu relacyjnym – stworzymy tabelę „AdresyEmail” powiązaną z tabelą „Studenci”.
Przykłady całościowe
Na koniec możemy omówić kilka kompletnych mini-systemów, żeby pokazać różne rodzaje encji, związków i atrybutów.
Przykład A – System rezerwacji hotelu
- Encje: „Pokój”, „Gość”, „Rezerwacja”.
- Związki: Gość „rezerwuje” Pokój.
- Atrybuty: Rezerwacja ma datę początku, datę końca i status.
Przykład B – Uczelnia
- Encje: „Student”, „Kurs”, „Wykładowca”.
- Związki: Student „zapisuje się na” Kurs, Wykładowca „prowadzi” Kurs.
- Atrybuty: Student – imię, nazwisko, nr indeksu. Kurs – nazwa, punktacja ECTS.
Przykład C – Sklep internetowy
- Encje: „Klient”, „Produkt”, „Zamówienie”.
- Związki: Klient „składa” Zamówienie, Zamówienie „zawiera” Produkt.
- Atrybuty: Produkt – cena, opis; Zamówienie – data, status.
⸻
Podsumowanie
- Projektowanie bazy danych zaczynamy od analizy wymagań użytkownika.
- Model ER pozwala uporządkować wiedzę w postaci encje–atrybuty–związki.
- Wyróżniamy związki 1:1, 1:N, N:M oraz atrybuty proste, złożone i wielowartościowe.
- Diagram ERD to narzędzie komunikacji – łączy świat użytkownika ze światem projektanta i programisty.