Wyobraź sobie, że masz zaprojektować bazę danych dla biblioteki szkolnej. Wiesz, że są w niej książki, czytelnicy i wypożyczenia. Ale zanim zaczniesz cokolwiek tworzyć w SQL, musisz najpierw zrozumieć, jak te elementy są ze sobą powiązane.
Do tego służą modele baz danych – czyli graficzne przedstawienia danych i ich relacji.
Co to jest model bazy danych?
Model bazy danych to mapa, która pokazuje:
- jakie dane chcemy przechowywać,
- jakie są ich powiązania,
- oraz jak będą wyglądały tabele w bazie.
Inaczej mówiąc, to plan budowy bazy danych – zanim ją stworzymy w SQL, musimy wiedzieć, co i jak połączyć.
Dlaczego to takie ważne?
Jeśli od razu zaczniesz tworzyć tabele „na oko”, szybko pogubisz się w tym, co z czym się łączy.
Model pozwala:
- zobaczyć zależności między danymi,
- zapobiec powielaniu informacji,
- i uniknąć błędów przy projektowaniu bazy.
1. Model ER (Entity–Relationship)
Model ER to jeden z najprostszych i najczęściej używanych modeli do projektowania baz danych.
Skrót pochodzi od słów:
- Entity – encja (czyli obiekt, rzecz, o której przechowujemy dane),
- Relationship – relacja (czyli powiązanie między encjami).
Podstawowe elementy modelu ER
| Symbol | Nazwa | Znaczenie |
|---|---|---|
| 🟦 | Encja | Obiekt, o którym chcemy przechowywać dane (np. KSIĄŻKA, CZYTELNIK). |
| 🔵 | Atrybut | Cecha encji (np. tytuł, autor, rok wydania). |
| 🔶 | Relacja | Związek między encjami (np. „CZYTELNIK wypożycza KSIĄŻKĘ”). |
Przykład
Wyobraźmy sobie trzy encje:
- KSIĄŻKA (tytuł, autor, rok_wydania)
- CZYTELNIK (imie, nazwisko, numer_karty)
- WYPOŻYCZENIE (data_wypożyczenia, data_zwrotu)
A między nimi takie relacje:
- CZYTELNIK wypożycza KSIĄŻKĘ
- WYPOŻYCZENIE łączy CZYTELNIKA z KSIĄŻKĄ
Schemat można zapisać symbolicznie:
[CZYTELNIK]──(wypożycza)──[KSIĄŻKA]
│ │
│ │
└──────[WYPOŻYCZENIE]────┘
Rodzaje relacji
- Jeden do jednego (1:1)
Przykład: Każdy uczeń ma jedną legitymację szkolną, i każda legitymacja należy do jednego ucznia.
→ Uczeń ↔ Legitymacja - Jeden do wielu (1:N)
Przykład: Jeden czytelnik może wypożyczyć wiele książek, ale każda książka w danym momencie może być wypożyczona tylko przez jednego czytelnika.
→ Czytelnik ↔ Książki - Wiele do wielu (M:N)
Przykład: Wiele uczniów może brać udział w wielu kursach.
→ Uczeń ↔ Kurs
(w praktyce realizowane za pomocą dodatkowej tabeli, np.uczestnictwa)
2. Model UML (Unified Modeling Language)
Model UML to bardziej ogólny język graficzny – używany nie tylko do baz danych, ale także do projektowania aplikacji, klas i relacji między nimi.
W kontekście baz danych używa się diagramu klas, który bardzo przypomina model ER, ale jest nieco bardziej „techniczny”.
Elementy diagramu UML
Każda encja (klasa) ma formę prostokąta podzielonego na trzy części:
-------------------------
| KSIĄŻKA |
-------------------------
| id_ksiazki |
| tytul |
| autor |
| rok_wydania |
-------------------------
| +getTytul() |
| +setAutor() |
-------------------------
- Górna część – nazwa encji (np. KSIĄŻKA)
- Środkowa część – atrybuty (czyli kolumny tabeli)
- Dolna część – metody (w bazach danych zwykle pomijane, ale używane w programowaniu obiektowym)
Przykład relacji UML
Załóżmy, że mamy takie klasy:
- Czytelnik
- Książka
- Wypożyczenie
Relacje między nimi wyglądają tak:
[Czytelnik] 1───* [Wypożyczenie] *───1 [Książka]
To oznacza:
- jeden czytelnik może mieć wiele wypożyczeń,
- każda książka może być wypożyczona wiele razy,
- ale jedno konkretne wypożyczenie dotyczy jednej książki i jednego czytelnika.
Różnice między ER a UML
| Cecha | Model ER | Model UML |
|---|---|---|
| Zastosowanie | głównie bazy danych | bazy danych i programowanie obiektowe |
| Sposób zapisu | encje i relacje | klasy i asocjacje |
| Poziom szczegółowości | prostszy | bardziej techniczny |
| Cel | pokazanie powiązań danych | projektowanie systemu jako całości |
Podsumowanie
Modele baz danych to mapy świata danych.
Pozwalają zobaczyć, jakie obiekty istnieją w systemie i jak są ze sobą połączone.
- Model ER skupia się na danych – kto, co, z czym jest powiązany.
- Model UML pokazuje także, jak system działa i jak dane są przetwarzane w aplikacji.
Dzięki tym modelom łatwiej zaprojektować bazę danych logicznie i uniknąć błędów przy jej tworzeniu w SQL.