Relacyjny model baz danych – mały przewodnik

Wprowadzenie do modeli baz danych

Zanim zagłębimy się w szczegóły modelu relacyjnego, warto zrozumieć, czym w ogóle jest model bazy danych. W najprostszych słowach, model bazy danych to teoretyczna koncepcja, która określa, w jaki sposób dane są przechowywane, organizowane i jak można nimi manipulować. To zbiór zasad i struktur, które definiują logiczną budowę bazy danych. Wybór odpowiedniego modelu ma kluczowe znaczenie dla wydajności, skalowalności i integralności systemu informatycznego.

Na przestrzeni lat powstało wiele modeli baz danych, a każdy z nich miał swoje mocne i słabe strony. Oto kilka przykładów, aby pokazać, jak ewoluowały i czym różnią się od modelu relacyjnego:

• Model hierarchiczny: Jeden z najstarszych modeli, w którym dane są zorganizowane w strukturę drzewiastą. Każdy „potomek” ma dokładnie jednego „rodzica”. Przypomina to system plików w komputerze. Był szybki w przypadku zapytań podążających ścieżką hierarchii, ale bardzo nieelastyczny, gdy trzeba było tworzyć relacje poza tą strukturą.
• Model sieciowy: Ewolucja modelu hierarchicznego, która pozwalała na bardziej złożone relacje. W tym modelu rekord mógł mieć wielu „rodziców”, co eliminowało część ograniczeń poprzednika. Struktura przypominała graf, co jednak czyniło ją skomplikowaną w zarządzaniu i nawigacji.
• Model obiektowy: Powstał w odpowiedzi na potrzeby programowania obiektowego. Dane są w nim przechowywane jako obiekty, czyli instancje klas, które zawierają zarówno dane (atrybuty), jak i metody (operacje na danych). Świetnie sprawdza się w systemach, gdzie dane mają złożoną strukturę i zachowanie.
• Model NoSQL (nierelacyjny): To raczej kategoria modeli niż jeden konkretny model. Obejmuje bazy dokumentowe (np. MongoDB), klucz-wartość (np. Redis), kolumnowe (np. Cassandra) i grafowe (np. Neo4j). Powstały z myślą o obsłudze ogromnych ilości danych (Big Data), elastyczności schematu i skalowalności horyzontalnej, często kosztem niektórych gwarancji transakcyjnych znanych z modelu relacyjnego.

Czym jest relacyjny model baz danych?

Relacyjny model baz danych, zaproponowany przez Edgara F. Codda w 1970 roku, zrewolucjonizował świat technologii. Jego siła tkwi w prostocie i solidnych podstawach matematycznych, opartych na teorii zbiorów i logice predykatów. W modelu tym wszystkie dane są reprezentowane w postaci relacji, które dla użytkownika końcowego wyglądają jak proste, dwuwymiarowe tabele.

Główną ideą jest oddzielenie logicznej struktury danych od ich fizycznej implementacji. Użytkownik nie musi wiedzieć, jak i gdzie dane są zapisane na dysku. Interesuje go jedynie logiczny schemat – jakie są tabele, jakie mają kolumny i jakie są między nimi powiązania. Dzięki temu model relacyjny jest niezwykle elastyczny i łatwy w użyciu.

Idea modelu relacyjnego:

+----------------------+      +------------------------+
|      Logiczna        |      |       Fizyczna         |
|   Reprezentacja      |      |     Implementacja      |
| (Tabele, Relacje)    |  <-->| (Pliki, Indeksy, etc.) |
+----------------------+      +------------------------+
          ^
          |
      Użytkownik
      (Widzi tylko tabele)

Podstawowe pojęcia w modelu relacyjnym

Aby w pełni zrozumieć ten model, musimy poznać jego fundamentalne komponenty:

• Encja: To obiekt lub pojęcie z realnego świata, o którym chcemy przechowywać informacje. Może to być osoba (np. Student, Pracownik), miejsce (np. Miasto), przedmiot (np. Książka) lub zdarzenie (np. Wypożyczenie). W bazie danych encje są zazwyczaj reprezentowane przez tabele.
• Atrybut: To właściwość lub cecha opisująca encję. Dla encji „Student” atrybutami mogą być Imię, Nazwisko, NumerIndeksu. W tabeli atrybuty stają się kolumnami.
• Relacja (Tabela): To zbiór powiązanych ze sobą danych, przedstawiony w formie tabeli składającej się z wierszy i kolumn. Każda tabela w bazie danych reprezentuje zbiór podobnych encji.
• Krotka (Wiersz/Rekord): To pojedynczy wpis w tabeli, reprezentujący jedną, konkretną instancję encji. Na przykład, jeden wiersz w tabeli „Studenci” to dane jednego, konkretnego studenta.
• Domena: To zbiór wszystkich dopuszczalnych wartości dla danego atrybutu. Na przykład, domena dla atrybutu „Płeć” może być zbiorem {‚Mężczyzna’, ‚Kobieta’}, a dla „Wiek” zbiorem liczb całkowitych od 0 do 120.

Struktura Tabeli (Relacji)

       +--------------------------------------------------+
       | Tabela: Studenci (Reprezentacja encji "Student") |
       +------------------+-------------+-----------------+
       |   id_studenta    |     imie    |    nazwisko     |  <-- Atrybuty (Kolumny)
       +------------------+-------------+-----------------+
|----> |        1         |     Jan     |    Kowalski     |  <-- Krotka (Wiersz)
|      +------------------+-------------+-----------------+
|      |        2         |    Anna     |     Nowak       |  <-- Krotka (Wiersz)
Krotki +------------------+-------------+-----------------+
|      |        3         |    Piotr    |   Zieliński     |  <-- Krotka (Wiersz)
|----> +------------------+-------------+-----------------+

Kluczowe zasady modelu relacyjnego

Model relacyjny opiera się na kilku żelaznych zasadach, które gwarantują spójność i integralność danych. Najważniejsze z nich to:

• Klucz główny (Primary Key): Każda tabela musi posiadać klucz główny. Jest to jedna lub więcej kolumn, których wartość jednoznacznie identyfikuje każdy wiersz w tabeli. Wartości w kolumnie klucza głównego nie mogą się powtarzać i nie mogą być puste (NULL).
• Klucz obcy (Foreign Key): To kolumna (lub zestaw kolumn) w jednej tabeli, która jest kluczem głównym w innej tabeli. Klucze obce służą do tworzenia powiązań (relacji) między tabelami. Dzięki nim możemy zapewnić, że np. do tabeli „Wypożyczenia” nie da się wpisać książki, która nie istnieje w tabeli „Książki”.
• Integralność encji: Ta zasada, realizowana przez klucz główny, mówi, że każdy wiersz w tabeli musi być unikalnie identyfikowalny.
• Integralność referencyjna: Ta zasada, realizowana przez klucze obce, zapewnia, że relacje między tabelami są zawsze spójne. Każda wartość klucza obcego musi odpowiadać istniejącej wartości klucza głównego w powiązanej tabeli, albo być NULL (jeśli jest to dozwolone).

Relacja między tabelami za pomocą kluczy

+---------------------------+    +---------------------------------------+
| Tabela: Autorzy           |    | Tabela: Ksiazki                       |
+-------------+-------------+    +----------+---------------+------------+
| **id_autora** | nazwisko  |    | **id_ksiazki** |  tytul | *id_autora* | <-- Klucz obcy
+-------------+-------------+    +----------+--------------+-------------+
|      1      | Sienkiewicz |    |     101        | "Coś"  |     1       |
|      2      |    Prus     |    |     102        |"Lalka" |     2       |
+-------------+-------------+    +----------+--------------+-------------+
       ^                                                 |
       |                                                 |
       +-------------------------------------------------+
                  (Relacja jeden-do-wielu)

Tworzenie modelu relacyjnego – przykład praktyczny

Przejdźmy przez prosty przykład tworzenia modelu dla małej biblioteki. Chcemy przechowywać informacje o książkach, autorach i czytelnikach.

Krok 1: identyfikacja encji i atrybutów

Nasze główne encje to: Autor, Książka i Czytelnik. Określmy ich atrybuty:

• Autor: id_autora, imie, nazwisko, data_urodzenia
• Książka: id_ksiazki, tytul, rok_wydania, id_autora (powiązanie z autorem)
• Czytelnik: id_czytelnika, imie, nazwisko, email

Krok 2: tworzenie tabel w SQL

Teraz przełóżmy nasz projekt na konkretne polecenia SQL. Użyjemy kluczy głównych (PRIMARY KEY) z automatycznym numerowaniem (AUTO_INCREMENT) oraz klucza obcego (FOREIGN KEY) do połączenia książek z autorami.

Tabela autorzy

CREATE TABLE Autorzy (
    id_autora INT AUTO_INCREMENT PRIMARY KEY,
    imie VARCHAR(50) NOT NULL,
    nazwisko VARCHAR(100) NOT NULL,
    data_urodzenia DATE
);

Tabela czytelnicy

CREATE TABLE Czytelnicy (
    id_czytelnika INT AUTO_INCREMENT PRIMARY KEY,
    imie VARCHAR(50) NOT NULL,
    nazwisko VARCHAR(100) NOT NULL,
    email VARCHAR(100) UNIQUE
);

Tabela ksiazki

CREATE TABLE Ksiazki (
    id_ksiazki INT AUTO_INCREMENT PRIMARY KEY,
    tytul VARCHAR(255) NOT NULL,
    rok_wydania INT,
    id_autora INT,
    FOREIGN KEY (id_autora) REFERENCES Autorzy(id_autora)
);

Krok 3: wstawianie i odpytywanie danych

Wstawmy przykładowe dane i zobaczmy, jak działają relacje.

Wstawianie danych (CLI)

-- Wstawianie autorów
INSERT INTO Autorzy (imie, nazwisko, data_urodzenia) VALUES ('Henryk', 'Sienkiewicz', '1846-05-05');
INSERT INTO Autorzy (imie, nazwisko, data_urodzenia) VALUES ('Bolesław', 'Prus', '1847-08-20');

-- Wstawianie książek
INSERT INTO Ksiazki (tytul, rok_wydania, id_autora) VALUES ('W pustyni i w puszczy', 1911, 1);
INSERT INTO Ksiazki (tytul, rok_wydania, id_autora) VALUES ('Lalka', 1889, 2);
INSERT INTO Ksiazki (tytul, rok_wydania, id_autora) VALUES ('Quo Vadis', 1896, 1);

Zapytanie o książki i ich autorów

Dzięki relacji możemy łatwo połączyć dane z obu tabel za pomocą operacji JOIN.

SELECT
    k.tytul,
    k.rok_wydania,
    a.imie,
    a.nazwisko
FROM
    Ksiazki k
JOIN
    Autorzy a ON k.id_autora = a.id_autora;

Wynik zapytania (CLI)

+--------------------------+-------------+----------+-------------+
| tytul                    | rok_wydania | imie     | nazwisko    |
+--------------------------+-------------+----------+-------------+
| W pustyni i w puszczy    |        1911 | Henryk   | Sienkiewicz |
| Lalka                    |        1889 | Bolesław | Prus        |
| Quo Vadis                |        1896 | Henryk   | Sienkiewicz |
+--------------------------+-------------+----------+-------------+

Podsumowanie

Relacyjny model baz danych, mimo upływu lat, pozostaje fundamentem dla większości systemów transakcyjnych na świecie. Jego siła leży w matematycznej precyzji, prostocie opartej na tabelach oraz gwarancjach spójności danych (ACID). Chociaż modele NoSQL zyskują na popularności w specyficznych zastosowaniach (np. Big Data, systemy czasu rzeczywistego), model relacyjny jest i jeszcze długo będzie niezastąpiony tam, gdzie liczy się integralność, niezawodność i elastyczność w odpytywaniu danych. Zrozumienie jego podstawowych koncepcji – encji, atrybutów, relacji i kluczy – jest absolutną podstawą dla każdego, kto chce profesjonalnie zajmować się bazami danych.