Atrybut kolumny NOT NULL jest wymagany w przypadku
A. definicji wszystkich pól tabeli.
B. definicji wszystkich pól typu numerycznego.
C. klucza podstawowego.
D. użycia atrybutu DEFAULT.
Pytanie z egzaminu CKE, czerwiec 2020 (arkusz EE.09-SG-20.06).
W modelu relacyjnym atrybut NOT NULL jest wymagany dla kolumny będącej kluczem podstawowym, ponieważ klucz podstawowy ma jednoznacznie identyfikować każdy rekord w tabeli. W praktyce oznacza to dwie rzeczy: wartość musi być unikalna i nie może być pusta. Gdyby w kluczu podstawowym można było zapisać NULL, baza nie miałaby pewności, czy taki rekord da się poprawnie wskazać, połączyć relacją z inną tabelą albo zaktualizować bez ryzyka pomyłki. Standard SQL traktuje PRIMARY KEY jako ograniczenie obejmujące właśnie unikalność oraz zakaz wartości NULL. W wielu systemach, np. MySQL, PostgreSQL czy SQL Server, zapis id INT PRIMARY KEY automatycznie powoduje, że kolumna id jest NOT NULL, nawet jeśli nie dopiszemy tego ręcznie. Z mojego doświadczenia i tak warto rozumieć, co się dzieje pod spodem, bo przy projektowaniu tabel łatwo wtedy uniknąć dziwnych błędów z relacjami. Przykład praktyczny: tabela uczniowie może mieć kolumnę id_ucznia jako PRIMARY KEY, a tabela oceny przechowuje id_ucznia jako klucz obcy. Jeśli id_ucznia byłoby puste, powiązanie oceny z konkretnym uczniem nie miałoby sensu. Dlatego w dobrze zaprojektowanej bazie danych klucz podstawowy zawsze musi mieć konkretną, niepustą wartość.
Atrybut NOT NULL nie jest wymagany po prostu dlatego, że kolumna ma wartość DEFAULT. To są dwa różne mechanizmy w SQL i dość często się je myli. DEFAULT określa wartość domyślną, która zostanie użyta wtedy, gdy przy wstawianiu rekordu pominiemy daną kolumnę. Nie oznacza to jednak automatycznie zakazu wpisania NULL. W wielu bazach można mieć kolumnę status VARCHAR(20) DEFAULT 'nowy', a mimo tego ręcznie wstawić do niej NULL, jeśli nie ma ograniczenia NOT NULL. Dopiero połączenie DEFAULT i NOT NULL daje efekt typu: jeżeli użytkownik nic nie poda, wstaw wartość domyślną, ale nie pozwól na pustą wartość.
Nie jest też prawdą, że NOT NULL musi występować przy wszystkich polach tabeli. W realnych projektach wiele danych jest opcjonalnych: drugi numer telefonu, uwagi do zamówienia, data zakończenia reklamacji albo zdjęcie profilowe użytkownika. Wymuszanie NOT NULL na wszystkim może prowadzić do sztucznych wartości typu pusty tekst, zero albo 1900-01-01, co moim zdaniem jest gorsze niż poprawnie użyty NULL, bo zaciemnia znaczenie danych.
Typ numeryczny również nie narzuca obowiązku NOT NULL. Kolumna cena, rabat czy liczba_punktow może być numeryczna, ale nadal może być nieznana albo jeszcze nieuzupełniona. Typ danych mówi, jaki rodzaj wartości można przechowywać, natomiast NOT NULL mówi, czy wartość musi istnieć. To osobne cechy kolumny. Obowiązek braku NULL wynika przede wszystkim z roli kolumny w modelu danych, a klasyczny przypadek to właśnie klucz podstawowy, który musi identyfikować rekord jednoznacznie i stabilnie.
Nie jest też prawdą, że NOT NULL musi występować przy wszystkich polach tabeli. W realnych projektach wiele danych jest opcjonalnych: drugi numer telefonu, uwagi do zamówienia, data zakończenia reklamacji albo zdjęcie profilowe użytkownika. Wymuszanie NOT NULL na wszystkim może prowadzić do sztucznych wartości typu pusty tekst, zero albo 1900-01-01, co moim zdaniem jest gorsze niż poprawnie użyty NULL, bo zaciemnia znaczenie danych.
Typ numeryczny również nie narzuca obowiązku NOT NULL. Kolumna cena, rabat czy liczba_punktow może być numeryczna, ale nadal może być nieznana albo jeszcze nieuzupełniona. Typ danych mówi, jaki rodzaj wartości można przechowywać, natomiast NOT NULL mówi, czy wartość musi istnieć. To osobne cechy kolumny. Obowiązek braku NULL wynika przede wszystkim z roli kolumny w modelu danych, a klasyczny przypadek to właśnie klucz podstawowy, który musi identyfikować rekord jednoznacznie i stabilnie.