Jak działa relacyjna baza danych?

Od rzeczywistości do modelu

Wyobraź sobie sklep internetowy. Obsługuje klientów, sprzedaje produkty i przyjmuje zamówienia. W opisie potrzeb biznesowych szukamy encji: rodzajów obiektów, o których chcemy zapisywać informacje. Klient i produkt to dwie różne encje. Konkretny klient, np. Ala, jest wystąpieniem encji Klient.

Atrybut opisuje cechę, np. imię klienta lub cenę produktu. W prostym projekcie relacyjnym encję odwzorowujemy jako tabelę, a atrybut jako kolumnę. Relacja w matematycznym modelu relacyjnym oznacza zbiór krotek; w codziennym języku bazodanowym słowo „relacja” bywa też używane na określenie powiązania tabel. Warto rozróżniać te znaczenia.

Tabela, wiersz, kolumna i dziedzina

Tabela produkty ma trzy kolumny. Każdy wiersz zawiera wartości opisujące jeden produkt. Dziedzina to dopuszczalny zbiór wartości atrybutu; opisuje ją typ wraz z regułami biznesowymi. Sama liczba dziesiętna dopuszcza wartości ujemne, ale cena sprzedaży może mieć dodatkowy warunek cena >= 0.

Ta tabela ma cztery rekordy i trzy kolumny. Jej liczność to 4, a stopień relacji to 3. Nie pomyl liczby wierszy z liczbą pól w strukturze. Nagłówki nie są rekordem danych.

W relacyjnym modelu kolejność krotek nie ma znaczenia. W SQL bez ORDER BY kolejność wyniku również nie jest gwarantowana. SQL dopuszcza ponadto powtarzające się wiersze wyniku, jeśli nie zażądasz usunięcia duplikatów — to praktyczna różnica względem matematycznego zbioru.

Dlaczego nie jedna wielka tabela?

Gdy wpiszesz pełne dane klienta przy każdej pozycji zamówienia, powielisz informacje. Zmiana jego danych będzie wymagała poprawek w wielu miejscach. Jeden pominięty rekord spowoduje sprzeczność. Dlatego rozdzielamy różne fakty:

• klienci: id, imie, miasto, email;
• produkty: id, nazwa, cena;
• zamowienia: id, klient_id, data, status;
• pozycje: zamowienie_id, produkt_id, ilosc.

Połączenie tabel nie polega na ich fizycznym sklejeniu. Zapytanie JOIN może zbudować wynik z pasujących rekordów, pozostawiając strukturę przechowywania bez zmian. O kluczach i liczebnościach powiązań będzie następna lekcja.

Spójność nie powinna zależeć tylko od formularza

Użytkownik może wprowadzić dane przez stronę, import pliku albo skrypt. Jeżeli kontrolę umieścisz wyłącznie w formularzu, inna droga może ją ominąć. Dlatego SZBD egzekwuje ograniczenia:

• PRIMARY KEY — identyfikacja rekordu;
• NOT NULL — wartość jest obowiązkowa;
• UNIQUE — wymagana unikalność według reguł silnika;
• FOREIGN KEY — poprawność odwołania do powiązanego rekordu;
• CHECK — warunek na dane, np. ilość większa od zera.

Typ, ograniczenie i walidacja aplikacji uzupełniają się. Nie wszystkie reguły, np. złożone limity zależne od wielu rekordów, dają się zapisać pojedynczym CHECK. Liczy się też wersja silnika — np. historyczne wersje MySQL traktowały CHECK inaczej niż współczesne.

Ten sam model w różnych silnikach

Projekt logiczny może być podobny, ale fizyczne polecenie CREATE TABLE nie musi być identyczne. W tej lekcji projektujesz model; nie potrzebujesz jeszcze wykonywać SQL.

Ćwiczenia

1. Biblioteka ma książki, czytelników i wypożyczenia. Wypisz trzy encje i po trzy sensowne atrybuty.
2. Czy dodanie nowego produktu zmienia schemat czy dane? A dodanie kolumny masa?
3. Co jest nie tak z kolumną telefony zawierającą tekst „111,222,333”, jeśli aplikacja ma wyszukiwać i sprawdzać każdy numer osobno?

Powiązanie z INF.03.4: pojęcia i projektowanie relacyjnych baz danych. Źródło zakresu: podstawa programowa ORE. Następnie: klucze, relacje i diagram E/R.