ITBlog

1. geneza i rewolucyjna idea modeli relacyjnego

Przełom w dziedzinie baz danych nastąpił w 1970 roku dzięki pracy Edgara F. Codda, który zaproponował model relacyjny. Było to radykalne odejście od modeli nawigacyjnych (hierarchicznego i sieciowego), które wymagały od programistów pisania złożonego kodu opisującego, jak dotrzeć do danych. Codd oparł swój model na solidnych fundamentach matematycznych – teorii zbiorów i logice predykatów – co pozwoliło na stworzenie podejścia deklaratywnego.

Głównym celem była niezależność danych: oddzielenie logicznej struktury danych od ich fizycznej reprezentacji. W modelu relacyjnym użytkownik określa co chce uzyskać, a system zarządzania bazą danych (RDBMS) sam znajduje optymalny sposób, aby te dane pobrać. Dane i relacje między nimi są reprezentowane w jednolity, prosty sposób: jako zbiór tabel.

2. podstawowe komponenty modelu relacyjnego

Model relacyjny posługuje się precyzyjną terminologią, która ma swoje odpowiedniki w praktycznej implementacji.

Właściwości relacji (tabeli)

• Nazwa relacji jest unikalna w obrębie bazy danych.
• Każdy atrybut ma unikalną nazwę w obrębie relacji.
• Wszystkie wartości w danej kolumnie pochodzą z tej samej domeny.
• Każda krotka jest unikalna; nie mogą istnieć dwa identyczne wiersze.
• Kolejność krotek (wierszy) i atrybutów (kolumn) nie ma znaczenia z punktu widzenia teorii.
• Wartości atrybutów są atomowe – niepodzielne (co jest podstawą Pierwszej Postaci Normalnej).

3. klucze – fundament identyfikacji i relacji

Klucze to atrybuty (lub ich zestawy) o specjalnym znaczeniu, które służą do unikalnej identyfikacji wierszy i tworzenia powiązań między tabelami.

• Superklucz (Superkey): Dowolny zbiór atrybutów, którego wartości jednoznacznie identyfikują każdą krotkę w relacji. Np. w tabeli studentów superkluczem może być {PESEL}, ale także {PESEL, Imię}.
• Klucz kandydujący (Candidate Key): To minimalny superklucz, czyli taki, z którego nie można usunąć żadnego atrybutu bez utraty właściwości unikalności. W tabeli studentów zarówno {PESEL}, jak i {NumerAlbumu} mogą być kluczami kandydującymi.
• Klucz główny (Primary Key): Jeden z kluczy kandydujących, wybrany przez projektanta bazy jako główny identyfikator krotek. Musi spełniać dwa warunki: unikalność i brak wartości NULL.
• Klucz obcy (Foreign Key): Atrybut (lub zbiór atrybutów) w jednej tabeli, który odwołuje się do klucza głównego w innej tabeli. Jest to mechanizm, za pomocą którego model relacyjny tworzy powiązania między danymi.
• Klucz alternatywny (Alternate Key): Każdy klucz kandydujący, który nie został wybrany jako klucz główny.

4. więzy integralności – gwarancja spójności danych

Model relacyjny definiuje zestaw reguł, zwanych więzami integralności, które zapewniają poprawność i spójność danych w bazie.

Integralność encji (entity integrity)

Reguła: Żaden atrybut wchodzący w skład klucza głównego nie może przyjmować wartości NULL.
Cel: Gwarantuje, że każdy wiersz w tabeli ma unikalny identyfikator i jest jednoznacznie rozróżnialny.

Integralność referencyjna (referential integrity)

Reguła: Jeśli w tabeli A istnieje klucz obcy, to jego wartość musi być albo równa wartości istniejącego klucza głównego w tabeli B, albo musi wynosić NULL (jeśli jest to dozwolone).
Cel: Zapobiega istnieniu „osieroconych” rekordów, czyli np. rekordu zamówienia, który odwołuje się do nieistniejącego klienta.

Integralność domeny (domain integrity)

Reguła: Wartość każdego atrybutu musi być zgodna z jego predefiniowaną domeną (typem danych, formatem, zakresem).
Cel: Zapewnia, że dane są poprawne i sensowne. Realizowane jest to przez:

• Typy danych: np. INTEGER, DATE, VARCHAR(100).
• Ograniczenie NOT NULL: Wartość w kolumnie nie może być pusta.
• Ograniczenie CHECK: Wartość musi spełniać określony warunek, np. CHECK (Cena > 0).
• Ograniczenie DEFAULT: Przypisuje domyślną wartość, jeśli żadna nie zostanie podana.

5. przykład praktyczny w SQL

Zobaczmy, jak teoria przekłada się na praktykę. Tworzymy dwie tabele: Dzialy i Pracownicy, powiązane relacją jeden-do-wielu.

-- Tabela Dzialy (strona "1" w relacji 1:N)
CREATE TABLE Dzialy (
    ID_Dzialu CHAR(3) PRIMARY KEY,  -- Klucz główny, wymusza integralność encji
    Nazwa_Dzialu VARCHAR(50) NOT NULL UNIQUE,
    Lokalizacja VARCHAR(50)
);

-- Tabela Pracownicy (strona "N" w relacji 1:N)
CREATE TABLE Pracownicy (
    ID_Pracownika INT PRIMARY KEY, -- Klucz główny
    Nazwisko VARCHAR(100) NOT NULL,
    Stanowisko VARCHAR(50),
    Pensja DECIMAL(10, 2) CHECK (Pensja >= 3000), -- Integralność domeny
    ID_Dzialu_FK CHAR(3), -- Kolumna dla klucza obcego

    -- Definicja więzu integralności referencyjnej
    CONSTRAINT fk_pracownik_dzial
        FOREIGN KEY (ID_Dzialu_FK) 
        REFERENCES Dzialy(ID_Dzialu)
        ON DELETE SET NULL  -- Jeśli dział zostanie usunięty, pracownikom ustaw NULL
        ON UPDATE CASCADE   -- Jeśli ID działu się zmieni, zaktualizuj je u pracowników
);
            

W powyższym przykładzie:

• ID_Dzialu i ID_Pracownika to klucze główne.
• ID_Dzialu_FK w tabeli Pracownicy to klucz obcy, który tworzy relację z tabelą Dzialy.
• DBMS nie pozwoli na dodanie pracownika z ID_Dzialu_FK, które nie istnieje w tabeli Dzialy.
• Ograniczenie CHECK pilnuje, aby pensja nie była niższa niż minimalna.

Podsumowanie

Model relacyjny zrewolucjonizował świat baz danych, wprowadzając matematyczną precyzję, prostotę i niezależność danych. Jego podstawowe koncepcje – relacje, atrybuty, krotki oraz, co najważniejsze, klucze i więzy integralności – stanowią do dziś fundament większości systemów informatycznych. Zrozumienie tych zasad jest absolutnie kluczowe do poprawnego projektowania, implementowania i wykorzystywania relacyjnych baz danych.