Relacyjny model danych

Dawno, dawno temu, kiedy dinozaury były wielkie... a dokładniej w 1970 roku, pewien gość o imieniu Edgar Codd stwierdził, że chaos w danych już dawno przestał być twórczym nieporządkiem i bardziej przypomina czarną dziurę, która pożera czas i zasoby. Edgar długo myślał i wymyślił sposób, jak to wszystko ogarnąć, a przy okazji — położył fundament pod cały świat, gdzie dane układają się w schludne tabelki, jak książki na półce w idealnej bibliotece. Wiersze, kolumny, porządek — i żadnego "jakoś to będzie" czy "no przecież wszystko jasne".

Relacyjny model opiera się na przedstawieniu danych w postaci tabel, gdzie każda tabela składa się z wierszy i kolumn. Intuicyjnie wszystko jasne: wiersze to rekordy, kolumny to właściwości lub atrybuty rekordu. Takie podejście ułatwia przetwarzanie i manipulowanie danymi.

Wyobraź sobie, że składasz zamówienie w sklepie internetowym. Żeby to zamówienie zostało poprawnie obsłużone i dostarczone, system musi uwzględnić mnóstwo szczegółów: kim jesteś (klient), jaką firmę kurierską wybrałeś, gdzie dostarczyć i jak śledzić status paczki.

Gdyby wszystkie te informacje były trzymane w jednej wielkiej tabeli, byłby totalny chaos: dane by się powtarzały, ciężko byłoby je aktualizować, a jeszcze trudniej — szybko znaleźć potrzebne info. Relacyjne podejście pomaga wprowadzić porządek, rozdzielając informacje między tabele, które mogą się wymieniać danymi.

Na tym schemacie masz przykład organizacji danych dla procesu śledzenia dostaw:

• Klienci - tutaj trzymane są informacje o każdym kliencie – z unikalnym Numerem Klienta.
• Firmy kurierskie - ta tabela zawiera listę firm, które mogą realizować dostawę, z ich unikalnym Numerem Firmy.
• Dostawa zamówienia - to centralna, łącząca tabela. Każdy wiersz to jedna konkretna dostawa. Zawiera swój Numer Dostawy, a także odnosi się do klienta, firmy kurierskiej, może odnosić się do konkretnego zamówienia, daty i aktualnego statusu.

Strzałki pokazują, jak rekordy z tabeli Dostawa zamówienia są powiązane z rekordami w tabelach Klienci i Firmy kurierskie.

Przykładowa tabela Dostawa zamówienia:

Zalety takiego podejścia:

• Informacje o klientach lub firmach kurierskich są przechowywane tylko raz, co pozwala uniknąć powtórzeń w każdym osobnym rekordzie dostawy.
• Powiązania przez unikalne numery (nazywane też kluczami) pomagają zagwarantować, że nie będzie np. dostaw bez istniejącego klienta albo przez nieistniejącą firmę.
• Łatwo łączyć dane z różnych tabel, żeby uzyskać złożone raporty lub konkretne zestawienia.
• Zmiana danych odbywa się w jednym miejscu i od razu jest widoczna we wszystkich powiązanych operacjach (np. numer telefonu firmy kurierskiej).

Struktura relacyjnej bazy danych

Sercem relacyjnej bazy danych są tabele. Każda tabela ma:

• Nazwę (Table Name), żebyśmy mogli ją zidentyfikować — na przykład customers.
• Zestaw kolumn (Columns/Attributes), które określają właściwości obiektu.
  • Przy nazywaniu kolumn, które służą jako unikalne numery (klucze główne), często używamy wzorca nazwa_id. Sufiks _id oznacza tutaj "identifier". Przykład: Numer Klienta staje się customer_id.
  • Na przykład, dla tabeli customers: mogą to być customer_id, first_name, email i tak dalej.
• Dane w wierszach (Rows/Records) - jeden wiersz w tabeli customers: będzie zawierał pełne informacje o jednym konkretnym kliencie (101, Alex Song itd.).

Przykład tabeli — customers:

Klucze tabel

Żeby jednoznacznie określić każdy wiersz w tabeli, używa się klucza głównego (Primary Key, PK). To kolumna (albo kilka), której wartości są unikalne dla każdego wiersza i nie mogą być puste. Wyobraź sobie to jako unikalny numer dla każdego rekordu, np. customer_id w naszej tabeli customers: jednoznacznie identyfikuje każdego klienta.

Klucz główny jest jak paszport, a dokładniej — jego numer: jest unikalny dla każdego obiektu. I pomaga uniknąć problemów z rekordami o tych samych danych.

Do tworzenia powiązań między tabelami używa się klucza obcego (Foreign Key, FK). To kolumna w jednej tabeli, która odnosi się do klucza głównego w innej tabeli. Klucze obce to "mosty" między tabelami. Często nazwa kolumny klucza obcego jest taka sama jak nazwa klucza głównego, do którego się odnosi. Na przykład, w tabeli deliveries kolumna customer_id będzie kluczem obcym, przechowującym wartości z kolumny customer_id tabeli customers, łącząc w ten sposób dostawę z klientem.

To znany nam schemat, ale teraz przedstawiony w bardziej realistycznej formie.

• Tabela customers zawiera informacje o klientach; jej klucz główny to customer_id.
• Tabela delivery_services przechowuje dane o firmach kurierskich; jej klucz główny to service_id.
• Tabela orders (pokazana dla kompletności, bo jest do niej odniesienie order_id z tabeli dostaw) służy do informacji o zamówieniach, z kluczem głównym order_id.
• Tabela deliveries jest centralna do śledzenia operacji dostawy. Ma:
  • Własny klucz główny: delivery_id.
  • Trzy klucze obce do tworzenia powiązań:
    • customer_id (FK): łączy dostawę z konkretnym klientem z tabeli customers.
    • service_id (FK): łączy dostawę z wybraną firmą z tabeli delivery_services.
    • order_id (FK): łączy dostawę z odpowiednim zamówieniem z tabeli orders.
  • Pole created_date wskazuje na datę i godzinę utworzenia rekordu dostawy.

Takie użycie kluczy głównych i obcych zapewnia spójność danych. System nie pozwoli utworzyć rekordu dostawy, jeśli podany customer_id albo order_id nie istnieje w odpowiednich tabelach i pozwala elastycznie pobierać powiązane informacje.

Zalety relacyjnego modelu

Relacyjny model ma sporo konkretnych plusów, które sprawiają, że jest liderem wśród innych podejść:

1. Prosta struktura. Tabele z kolumnami i wierszami są czytelne i proste.
2. Elastyczność w pracy z danymi. Możesz łatwo dodawać nowe dane lub je zmieniać, nie psując spójności.
3. Wsparcie dla złożonych zapytań. Dzięki SQL możesz pobierać dane z wielu tabel, łączyć je, filtrować i robić praktycznie wszystko, czego wymaga twoje zadanie. Na przykład, znaleźć wszystkich studentów zapisanych na konkretny kurs — prościzna!
4. Spójność danych przez klucze. Użycie kluczy głównych i obcych gwarantuje, że dane w bazie będą zgodne. Nie możesz np. dodać rekordu o studencie na kursie, jeśli taki kurs nie istnieje.

Relacyjny model danych to fundament współczesnych baz danych. Jest prosty, potężny i świetnie nadaje się do przechowywania uporządkowanych danych. Jak powiedział Edgar Codd: "Porządkuj albo giń!" (no, powiedział to trochę inaczej, ale sens jest mniej więcej taki...). W następnym wykładzie dowiesz się, czym relacyjny model różni się od innych typów baz danych (np. NoSQL) i gdzie najlepiej je stosować.