3 poziomy spójności relacyjnej bazy danych

Wstęp

Niewystarczająca jakość danych prowadzi do nieprawdziwych informacji, a w konsekwencji do błędnych decyzji. Czy faktura może nie mieć odbiorcy? Czy data urodzenia może być z przyszłości? Czy numer VAT może mieć dziewięć cyfr? Spójność danych oznacza ich zgodność z faktami. Dane muszą być prawdziwe, aktualne i dokładne. W relacyjnym modelu zapewniane jest na poziomie kolumny, tabeli oraz związków.

Publikacja w formie wideo

Projektując relacyjną bazę danych odkrywasz i katalogujesz obowiązujące w organizacji reguły biznesowe. Implementując bazę danych w konkretnym motorze wykorzystujesz jego mechanizmy do odwzorowania skatalogowanych reguł. W bazie danych nazywane są więzami integralności. Dzięki nim to relacyjny motor będzie dbał o jakość wstawianych do bazy danych. Niezależnie czy pochodzą z Twojej aplikacji, są wprowadzane ręcznie czy importowane z innego systemu.

Spójność na poziomie kolumny

Najniższym poziomem na którym relacyjny motor bazy danych dba o spójność danych jest kolumna. Definiując kolumnę musisz jawnie określić jej podstawowe elementy:

  • typ danych mówi jakie dane możesz wstawić do kolumny oraz jakie operacje na nich wykonać
  • znacząca nazwa kolumny umieszcza dane w kontekście. Jest unikalnym w skali bazy danych opisem zawartych w kolumnie danych

Część podstawowych elementów definicji kolumny nie jest wymagana w składni. Gdy pominięte motor bazy danych przyjmie ich domyślne wartości. Są to:

  • długość typu – ile cyfr dla liczbowego ile, liter dla typu tekstowego, precyzja dla datoczasowego
  • unikalność danych – więz integralności UNIQUE
  • dozwolenie braku wartości – więz integralności NULL/NOT NULL
  • wartość domyślna – klauzula DEFAULT

Długość typu liczbowego określa minimalną i maksymalną wielkość liczby. Długość typu tekstowego określa maksymalną ilość znaków wstawianego napisu. Długość typu datoczasowego określa precyzję jego najmniejszej jednostki.

Unikalność danych zapewnia, że wartości w określonej kolumnie nie powtarzają się w żadnym wierszu tabeli. Można także stosować reguły weryfikujące unikalność zestawów wartości obejmujących wiele kolumn.

Określając, czy brak wartości jest dozwolony oraz definiując wartość domyślną, decydujesz, jak motor bazy danych ma postępować w przypadku braku wartości dla wstawianych danych. Możesz pozwolić na NULL lub ustawić domyślną wartość dla kolumny.

Przykład jak więzem integralności CHECK precyzujesz zakres dozwolonych wartości.

Ustalając typ i jego długość niejawnie precyzujesz zakres danych. Na przykład chcesz przechowywać w bazie danych oceny. Możliwe wartości ocen to liczby całkowite od 0 do 10. Z uwagi na to, że 10 to liczba dwucyfrowa decydujesz się stworzyć kolumnę 'ocena’ typu liczbowego o wielkości 2. Taki typ umożliwi wstawienie do bazy danych wartości od -99 do 99. Wstawienie danych spoza zakresu czyli liczby większej niż 10 lub mniejszej niż 0 doprowadziłoby do utraty spójności. Aby zabezpieczyć bazę przed taką ewentualnością warto zdefiniować regułę według której motor bazy danych sprawdzi czy wprowadzane dane mieszczą się w zakresie.

Można także stosować reguły weryfikujące wartości z wielu kolumn. Reguła przestrzegana jest w momencie wstawiania danych do kolumny.

Spójność na poziomie tabeli

Tabela dba o spójność danych na poziomie całych wierszy. Dzięki kluczowi głównemu zapewnia, że w tabeli nie ma zduplikowanych wierszy. Inną rolą klucza głównego jest jednoznaczna identyfikacja każdego wiersza tabeli. Na poziomie tabeli dbasz o jak najmniejszą redundancję danych. Redundancja danych to te same dane w więcej niż jednej kolumnie jednej lub wielu tabel. Minimalny poziom redundancji jest niezbędny aby powiązać ze sobą dane znajdujące się w różnych wierszach. Jest to jedyne usprawiedliwione zastosowanie. Każdy inny przypadek jest błędem w projekcie bazy danych prowadzącym do anomalii mogących skutkować utratą spójności danych.

Ilustracja uzasadnionej i nieuzasadnionej redundancji danych.

Tabela reprezentuje pojedynczy byt, którym może być obiekt lub zdarzenie. Na przykład:

  • tabela książka nie zawiera danych o autorze
  • nazwa tabeli jednoznacznie i czytelnie opisuje przechowywane dane: tabela nazywa się książka zamiast k
  • tabela nie zawiera kolumn wieloczęściowych. Np.: telefon1, telefon2 czy adres1, adres2
  • tabela nie zawiera kolumn wielowartościowych jak kategorie czy języki
  • tabela nie zawiera kolumn o wyliczanych wartościach. Mianowicie zamiast składowania wieku składujesz datę urodzenia

Reguły przestrzegane są na etapie projektowania w momencie doboru kolumn do tabeli oraz w momencie wstawiania do niej wiersza.

Spójność na poziomie związku

W związki wchodzą zawsze wiersze z jedynie dwóch zbiorów. W rzeczywistości oba mogą być wieloelementowe. W relacyjnej bazie danych jeden zbiór zawsze jest jednoelementowy. Aby spełnić ten warunek związek dwóch wieloelementowych zbiorów musi zostać rozbity na dwa związki gdzie jeden zbiór jest jednoelementowy, a drugi wielo. Wiersze mogą znajdować się w tej samej lub w dwóch różnych tabelach. Związek opisany jest definicją klucza obcego. Czyli klucz obcy jednego lub wielu wierszy może przyjąć jedynie wartość istniejącą w kluczu głównym innego wiersza.

Na podstawie tych definicji motor bazy danych wie, które wartości są główne, a które zależne. Dba o spójność poprzez wymuszenie odpowiedniej kolejności wstawiania i usuwania powiązanych danych. Na przykład do bazy danych musi zostać wstawiony kierownik zanim przypisze mu się podwładnych. Czyli nie może być podwładnych bez kierownika. Muszą istnieć dane klienta zanim można wystawić mu fakturę. Czyli nie może istnieć faktura bez odbiorcy. Musi istnieć książka zanim czytelnik będzie mógł ją wypożyczyć.

Ilustracja związków wierszy znajdujących się w 2 tabelach.

Gdy chodzi o kasowanie powiązanych danych motor dopilnuje odwrotnej kolejności. Dopiero po wykasowaniu wierszy zależnych pozwoli na wykasowanie wiersza nadrzędnego. Czyli najpierw należy wykasować wiersze zawierające kopię klucza głównego w kluczu obcym, a dopiero później wiersz źródłowy klucza głównego. Proces możesz zautomatyzować definiując klucz obcy z regułą CASCADE. W takim przypadku usunięcie wiersza nadrzędnego skutkować będzie automatycznym usunięciem wierszy zależnych.

Takie zachowanie niekoniecznie odpowiada regułom przetwarzania danych w organizacji. Jest całkiem prawdopodobne, że organizacja nie chce zwalniać wszystkich podwładnych kontynuującego karierę poza strukturami organizacji kierownika. Firmie nie wolno kasować faktur tylko dlatego, że straciła klienta, ich odbiorcę. A biblioteka może chcieć zachować historię czytelnika nawet gdy pozbyła się książki, którą kiedyś czytał. Aby odwzorować zasady działania organizacji wykorzystujesz reguły usuwania dostępne w wybranym motorze i jego implementacji języka SQL. Oprócz CASCADE dysponujesz jeszcze RESTRICT czyli uniemożliwieniem usunięcia wiersza nadrzędnego gdy istnieją zależne. Komenda zwróci błąd. Zazwyczaj jest to domyślna reguła.

Ilustracja działania klauzuli ON DELETE RESTRICT. Nie pozwoli na usunięcie wiersza nadrzędnego gdy istnieje zależny.

W przypadku reguły SET NULL wiersz nadrzędny zostanie usunięty natomiast odpowiadające mu wartości klucza obcego w wierszach zależnych zostaną ustawione na NULL. W takim przypadku należy pamiętać aby kolumny wchodzące w skład klucza obcego dozwalały NULL.

Podobnie działa reguła SET DEFAULT. Z tą różnicą, że zamiast NULL kolumny klucza obcego wierszy zależnych zostaną wypełnione wartością zdefiniowaną jako domyślna dla danej kolumny. W tym przypadku podczas tworzenia tabeli trzeba pamiętać o definicji wartości domyślnej dla kolumn.

Reguła NO ACTION uniemożliwi usunięcie wiersza nadrzędnego. Nie zwróci błędu jeśli istnieje wyzwalacz, po angielsku trigger, obsługujący usuwanie. Trzeba pamiętać, że motory baz danych mają zaimplementowaną różną liczbę przewidzianych standardem SQL reguł.

Podobnymi w działaniu regułami ON UPDATE można obsłużyć modyfikację wartości klucza głównego wiersza nadrzędnego. Modyfikacje wartości klucza głównego choć technicznie możliwe są niezalecane. Nie wszystkie motory baz danych mają zaimplementowane reguły ON UPDATE.

Reguły przestrzegane są w momencie wstawiania i usuwania wartości wiążących wiersze.

Podsumowanie

Dziękuję za obejrzenie niniejszego materiału. Wiesz z niego, że rolą osoby projektującej relacyjną bazę danych jest sumienne rozpoznanie obowiązujących w organizacji reguł przetwarzania danych, a następnie odpowiednie zastosowanie zasad projektowania bazy danych do odwzorowania skatalogowanych reguł.

  • Na poziomie kolumny dbasz aby w bazie danych znalazły się jedynie potrzebne dane, zapisane we właściwej postaci.
  • Na poziomie tabeli dbasz o właściwe pogrupowanie danych z kolumn w zestawy zwane wierszami, brak duplikacji oraz identyfikację wierszy przy pomocy klucza głównego.
  • Na poziomie związków dbasz o odwzorowanie zależności pomiędzy wierszami przy pomocy kluczy obcych.

Niech zmora redundancji nigdy Cię nie dotknie. A jeśli chcesz aby Twoje dane nigdy nie były zduplikowane to koniecznie śledź mój blog.

Marcin Badtke

Przyjaźnie o SQL, bazach danych i ludziach

Może Ci się spodobać...

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *