Tworząc schematy baz danych, możemy korzystać z narzucanych przez model relacyjny ograniczeń, aby system baz danych "pilnował nas" podczas pracy z przechowywanymi w bazie danymi.
Ograniczenia modelu relacyjnego możemy podzielić na trzy grupy:
- ograniczenia oparte na modelu danych, wynikające wprost z założeń modelu relacyjnego,
- ograniczenia oparte na schemacie (ograniczenia bezpośrednie), wynikające z zaprojektowanego schematu danych,
- ograniczenia oparte na aplikacjach (ograniczenia semantyczne / reguły biznesowe), wynikające z założeń, na podstawie których projektuje się schemat bazy danych; ograniczenia te nie mogą być zaprogramowane w bazie danych (lub jest to bardzo trudne do zaimplementowania), przez co są wyrażane w projektowanej aplikacji bazodanowej.
Ograniczenia oparte na modelu danych
Ograniczenia oparte na modelu danych wynikają z tego, jakich narzędzi dostarcza nam relacyjny model danych (lub inny model, którego używamy w danym systemie baz danych). Charakterystyczne dla relacyjnych baz danych jest np. ograniczenie mówiące o tym, że w relacji nie może być dwóch takich samych krotek lub to, że nie dopuszcza się atrybutów wielowartościowych.
Ograniczenia oparte na schemacie
Wśród ograniczeń opartych na schemacie wyróżniamy ograniczenia dziedziny, kluczy, wartości pustych, więzy integralności encji oraz odwołań.
Ograniczenia dziedziny
Każdy atrybut encji musi mieć wartość atomową należącą do określonej dziedziny tego atrybutu. Dla przykładu, projektując schemat relacji PRACOWNIK opisującej pracownika firmy, jednym z atrybutów może być imię i nazwisko takiego pracownika. Imię i nazwisko nie jest atrybutem, którego wartości będą atomowe, ponieważ składa się z imienia oraz nazwiska. Należy zatem utworzyć atrybuty imię oraz nazwisko. Ich dziedzinami będzie napis - typ danych pozwalających wprowadzić dane tekstowe (implementując schemat relacji np. w MySQLu, zapewne właściwą dziedziną takiego atrybutu będzie VARCHAR lub TEXT).
Ograniczenia kluczy, rodzaje kluczy
Wiemy, że relacja jest zbiorem krotek, oraz że w danej relacji nie może być dwóch takich samych krotek. Wynika z tego, że nie może być w niej dwóch krotek zawierających takich samych wartości atrybutów w takiej samej kolejności.
Nadkluczem (lub superkluczem, ang. superkey) nazywamy zbiór zawierający wszystkie atrybuty danej relacji.
Wprowadzenie nadklucza wprowadza nam ograniczenie unikatowości.
Ograniczenie unikatowości
W relacji nie mogą istnieć dwie takie same krotki.
Ograniczenie unikatowości dotyczy klucza i nadklucza.
Aspekt praktyczny. Niestety, systemy baz danych na ogół nie są w stanie sprawdzać naruszeń nadklucza - czyli nie sprawdzają, czy nie dodajemy do tabeli wiersza, który już został dodany. Operacja ta jest zbyt kosztowna obliczeniowo (wszak należało by sprawdzać nowo dodawany wiersz ze wszystkimi już dodanymi wierszami), dlatego korzystamy z innych rodzajów kluczy.
Klucz (ang. key)
Podzbiór atrybutów relacji (niezawierający wszystkich jej atrybutów).
Wprowadzenie pojęcia klucza wprowadza nam dodatkowe ograniczenie minimalności.
Ograniczenie minimalności
Klucz jest minimalnym nadkluczem, czyli takim, że nie można już z niego usunąć żadnego atrybutu, zachowując ograniczenie unikatowości.
Ograniczenie minimalności jest wymagane dla klucza, ale opcjonalne dla nadklucza.
Jeśli klucz zawiera tylko jeden atrybut, nazywamy go kluczem prostym. Jeśli zawiera ich więcej - nazywamy go kluczem złożonym.
Co do zasady, relacja może zawierać więcej niż jeden klucz. Wówczas każdy z nich nazywamy kluczem kandydującym (ang. candidate key). Spośród nich zwykle wybiera się jeden do pełnienia roli klucza głównego.
Klucz główny (ang. primary key)
Klucz zawierający wartości służące do jednoznacznego identyfikowania krotki w relacji. Nie może przyjmować wartości pustej.
Klucz główny musi spełniać dodatkowo warunek braku wartości pustej. Klucz główny nie może przyjąć wartości NULL. Jest to wymagane, aby nie doszło do sytuacji, w której kilka krotek ma klucz główny o wartości NULL.
Przykład: PESEL jako klucz główny
Rozważmy przykład relacji PRACOWNIK(Imię, Nazwisko, PESEL, Adres). Wiemy, że w Polsce każdy obywatel ma nadany numer PESEL służący do identyfikacji w kontaktach z administracją państwową (np. w urzędzie gminy, gdy składamy do organu - wójta gminy (burmistrza, prezydenta miasta) - wniosek o wydanie dowodu osobistego. Numer ten jest zatem kluczem kandydującym, ponieważ wiemy, że każdy ma swój indywidualny, niepowtarzalny numer.
Numer PESEL nie jest jednak dobrym kandydatem do bycia kluczem głównym. Zdarzały się w Polsce sytuacje zduplikowania numeru PESEL, jak również istnieją procedury, w wyniku których numer PESEL ulega zmianie (np. zmiana aktu urodzenia w wyniku adopcji dziecka lub w wyniku korekty płci).
Wobec tego najczęstszym wyborem klucza głównego jest utworzenie sztucznego klucza głównego z automatycznie nadawaną wartością kolejną. Trzeba pamiętać, że klucz główny ma służyć do jednoznacznego identyfikowania krotki. Choć cecha ta może pochodzić z opisu świata rzeczywistego w mini-świecie, możemy też ją nadać samodzielnie - wszak jest to element wewnętrzny tworzonego schematu bazy danych.
Dla dodatkowego przykładu, w Systemie Informacji Oświatowej każda szkoła, wprowadzając dane ucznia, musi podać jego imię, nazwisko i numer PESEL (dla uproszczenia) jako dane identyfikujące. Wydawać by się mogło zatem, że klucz (imię, nazwisko, PESEL) jest kluczem głównym. Ze względów praktycznych jednak stosowanie złożonych kluczy głównych jest trudne (np. w tworzonej aplikacji), jak również nie każdy uczeń ma numer PESEL - dlatego system ten nadaje wprowadzonym uczniom identyfikator pełniący rolę klucza głównego. Jest to identyfikator wyłącznie wewnętrzny, służący do tworzenia powiązań (związków) z innymi relacjami (tabelami).
Aspekt praktyczny. Najczęściej wybieramy klucz główny tak, aby zawierał jeden atrybut (np. identyfikator). Pozostałe klucze kandydujące są kluczami unikatowymi.
Klucz unikatowy (ang. unique key)
Klucz, którego wartości nie powtarzają się w relacji.
Z kluczy unikatowych korzystamy, aby zapobiec sytuacji powtórzenia się wartości jakiegoś atrybutu. Na przykład w tabeli z użytkownikami jakiegoś serwisu możemy przyjąć założenie, że każdy taki użytkownik ma niepowtarzający się, unikatowy adres e-mail. Wówczas atrybut email może być ustawiony jako klucz unikatowy. W odróżnieniu od klucza głównego, klucz unikatowy może mieć wartość NULL (chyba że tego jawnie zabronimy).
Istnieje także klucz obcy, który omówiono nieco dalej.
Ograniczenie wartości pustych
Jak wskazano wcześniej, klucz główny według swojej definicji nie może mieć wartości NULL. Takiego ograniczenia z definicji nie ma w innych kluczach. Możemy jednak nałożyć na wybrany klucz ograniczenie wartości pustych. Wówczas nie będzie możliwe wprowadzenie wartości pustej wybranego atrybutu. W języku SQL odpowiada za to klauzula NOT NULL.
Więzy integralności encji
Więzy integralności encji określają, że żadna z wartości wchodzących w skład klucza głównego encji nie może przyjąć wartości NULL. Innymi słowy, wszystkie atrybuty należące do klucza głównego muszą mieć jakąś niepustą wartość.
Więzy integralności odwołań, klucz obcy
Więzy integralności odwołań definiujemy między relacjami. Oznaczają one, że wartości przyjmowane przez atrybut (lub atrybuty) relacji odwołującej pochodzą z wartości jakiegoś atrybutu (najczęściej klucza głównego) relacji wskazywanej. Na przykład w relacji PRACOWNIK(Imię, Nazwisko, Numer_Działu) atrybut Numer_Działu może wskazywać na atrybut Nr z relacji DZIAŁ(Nr, Nazwa).
Taki atrybut (lub zestaw atrybutów) danej relacji, który odnosi się do wartości atrybutu (atrybutów) innej relacji, nazywamy kluczem obcym.
Klucz obcy (ang. foreign key)
Atrybut odnoszący się do wartości innego atrybutu.
Powyższe oznacza, że klucz główny musi spełniać dwa wymagania:
- oba atrybuty w więzie integralności odwołań muszą mieć taką samą dziedzinę,
- wartości klucza obcego odnoszą się do klucza głównego innej relacji lub wartość ta jest pusta.
Ważne jest, że wartości klucza obcego muszą wskazywać istniejące wartości klucza głównego. Odnosząc się do przykładu na początku tej sekcji, nie można pracownikowi wpisać numeru działu, którego nie ma wcześniej w relacji DZIAŁ.
Klucz obcy może odnosić się do tej samej relacji. Rozważmy przykład relacji PRACOWNIK(Imię, Nazwisko, PESEL, PESELKIEROWNIKA). Jeśli założymy, że PESEL jest kluczem głównym, to PESELKIEROWNIKA może być kluczem obcym odnoszącym się do atrybutu PESEL tej samej relacji. Wówczas jako wartość pola PESELKIEROWNIKA można wpisać:
- PESEL innego pracownika, aby wskazać, że jest on przełożonym danego pracownika,
- wartość
NULL, aby wskazać, że dany pracownik nie ma przełożonego (np. jest właścicielem firmy).
Z kluczy obcych korzystamy praktycznie w każdym schemacie baz danych. Możliwość ta pozwala nam uniknąć wielokrotnego zapisywania tych samych danych - zamiast wpisywać informacje o dziale, w którym pracuje dany pracownik, przy każdym takim pracowniku, wpisujemy jedynie numer działu, a wszystkie informacje o tym dziale zapisujemy w odrębnej relacji. Pozwala to uniknąć nadmiarowości w bazach danych i utrzymać bazę w wymaganej postaci normalnej.
Ograniczenia biznesowe
Reguły biznesowe to wymagania, które danemu systemowi stawiają osoby zamawiające dany system bazodanowy. Zwykle są one trudne do jednoznacznego wyrażenia oraz implementacji w bazie danych. Przykłady:
- pracownik nie może mieć pensji wyższej niż jego przełożony, chyba że w ciągu ostatniego roku otrzymał premie o średniej wartości mniejszej niż lub równej średniej premii osób z działu, w którym wówczas pracował,
- pracownik nie może być kierownikiem więcej niż 2 działów, chyba że prezes firmy wyraźnie na to pozwolił.
W takich sytuacjach sprawdzanie warunków biznesowych pozostaje zadaniem programistów aplikacji korzystającej z projektowanej bazy danych. Jeśli jednak warunki były by dość proste, można je wprowadzić do schematu bazy danych korzystając z asercji.
Źródła:
- Elvasri, R., & Navathe, S. B. (2019). Wprowadzenie do systemów baz danych (T. Walczak, Tłum.). 7.
- Opracowanie własne.