Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych

Pojęcie integralności referencyjnej bywa mylone z innymi rodzajami ograniczeń w bazie danych, dlatego łatwo tu o skrót myślowy. W relacyjnych bazach danych mamy kilka różnych typów integralności: integralność encji, integralność dziedzinową oraz właśnie integralność referencyjną. Każda z nich dotyczy trochę innego aspektu poprawności danych i warto je sobie w głowie rozdzielić, bo w praktyce projektowej to mocno pomaga. Stwierdzenie, że wartość atrybutu należy do jego dziedziny, opisuje integralność dziedzinową. Oznacza to, że np. kolumna typu DATE faktycznie przechowuje poprawne daty, kolumna z ograniczeniem CHECK mieści tylko dopuszczalne wartości, a kolumna typu INT nie zawiera losowego tekstu. To jest ważne, ale nie ma nic wspólnego z powiązaniem między dwiema tabelami. Tutaj mówimy o poprawności pojedynczej kolumny, a nie relacji klucz główny–klucz obcy. Z kolei odporność bazy na błędy sprzętu czy oprogramowania to już zupełnie inny obszar – to domena niezawodności systemu, mechanizmów transakcyjności, backupów, logów transakcyjnych, klastrów HA, replikacji itd. To są dobre praktyki administracyjne i architektoniczne, ale nie opisują integralności referencyjnej. Można mieć świetnie zabezpieczony serwer, a jednocześnie kompletnie rozwaloną spójność logiczną danych, jeśli nie ma poprawnie zdefiniowanych kluczy obcych. Wymóg, że każda encja ma unikalny klucz podstawowy, dotyczy integralności encji. Chodzi o to, żeby każdy rekord w tabeli dało się jednoznacznie zidentyfikować i żeby klucz główny nie był NULL. To jest fundament, ale nadal mówimy tylko o pojedynczej tabeli. Integralność referencyjna wchodzi dopiero wtedy, gdy jedna tabela „wskazuje” na drugą przez klucz obcy. Typowy błąd myślowy polega na wrzuceniu do jednego worka wszystkich zasad typu PRIMARY KEY, FOREIGN KEY, CHECK, UNIQUE i nazywaniu tego ogólnie integralnością. W rzeczywistości integralność referencyjna jest ściśle związana z relacjami między tabelami: pilnuje, żeby żaden klucz obcy nie wskazywał na nieistniejący rekord. Jeśli chcemy projektować bazy sensownie, trzeba świadomie odróżniać te pojęcia i korzystać z odpowiednich ograniczeń dokładnie tam, gdzie są potrzebne.