Co zrobić z wartościami null podczas modelowania i normalizacji?

SQL traktuje NULL specjalnie dla swojej wersji 3VL (logika trójwartościowa). Normalizacja i inna teoria relacji nie. Możemy jednak przełożyć projekty SQL na projekty relacyjne iz powrotem. (Załóżmy, że nie ma zduplikowanych wierszy.)

Normalizacja dzieje się z relacjami i jest zdefiniowany w kategoriach operatorów, które nie traktują specjalnie wartości NULL. Termin „normalizacja” ma dwa najczęstsze odrębne znaczenia:umieszczenie tabeli w „1NF” i „wyższe NF (formy normalne)”. NULL nie wpływa na "normalizację do 1NF". „Normalizacja do wyższych NF” zastępuje tabelę mniejszymi tabelami, które w naturalny sposób łączą się z nim. Dla celów normalizacji można traktować NULL jako wartość dozwoloną w domenie kolumny dopuszczającej wartość null oprócz wartości jej typu SQL. Jeśli nasze tabele SQL nie mają wartości NULL, możemy je zinterpretować jako relacje, łączenie SQL itp. jako łączenie itp. Ale jeśli zdekomponujesz kolumnę dopuszczającą wartość null między komponentami, zdaj sobie sprawę, że aby zrekonstruować oryginał w SQL, musisz połączyć SQL na kolumny o tej samej nazwie są równe lub obie NULL . I nie będziesz chciał takich CK (kluczy kandydata) w bazie danych SQL. Np. nie możesz zadeklarować go jako SQL PK (klucz podstawowy), ponieważ oznacza to UNIQUE NOT NULL. Np. ograniczenie UNIQUE obejmujące kolumnę dopuszczającą wartość null pozwala na wiele wierszy, które mają wartość NULL w tej kolumnie, nawet jeśli wiersze mają te same wartości w każdej kolumnie. Np. wartości NULL w FK SQL powodują, że są one spełnione (na różne sposoby w trybie MATCH), a nie występują w tabeli, do której się odwołują. (Ale DBMS idiosynkratycznie różnią się od standardowego SQL).

Niestety rozkład może prowadzić do tabeli ze wszystkimi CK zawierające NULL, dzięki czemu nie mamy nic do zadeklarowania jako SQL PK lub UNIQUE NOT NULL. Jedynym pewnym rozwiązaniem jest konwersja do projektu bez wartości NULL. Po normalizacji możemy chcieć ponownie wprowadzić pewne wartości null w komponentach.

W praktyce udaje nam się zaprojektować tabele tak, aby zawsze był zestaw kolumn wolnych od wartości NULL, które możemy zadeklarować jako CK, poprzez SQL PK lub UNIQUE NOT NULL. Następnie możemy pozbyć się kolumny dopuszczającej wartość NULL, usuwając ją z tabeli i dodając tabelę z tą kolumną i kolumnami jakiegoś CK wolnego od wartości NULL:Jeśli kolumna nie ma wartości NULL dla wiersza w starym projekcie, to wiersz z jego wartość podrzędna i kolumny CK trafia do dodanej tabeli; w przeciwnym razie w starym projekcie ma wartość NULL i w dodanej tabeli nie ma odpowiedniego wiersza. (Oryginalna tabela jest naturalnym sprzężeniem lewym do nowych). Oczywiście musimy również zmodyfikować zapytania ze starego projektu do nowego projektu.

Zawsze możemy uniknąć wartości NULL poprzez projekt, który dodaje kolumnę logiczną dla każdej starej kolumny dopuszczającej wartość null i ma starą kolumnę NOT NULL. Nowa kolumna mówi dla wiersza, czy stara kolumna miała wartość NULL w starym projekcie, a kiedy prawda oznacza, że ​​stara kolumna ma jedną wartość, którą wybraliśmy w tym celu dla tego typu w całej bazie danych. Oczywiście musimy również zmodyfikować zapytania ze starego projektu do nowego projektu.

To, czy chcesz uniknąć NULL, to osobne pytanie. Twoja baza danych może być w jakiś sposób „lepsza” lub „gorsza” dla twojej aplikacji w obu wersjach. Ideą stojącą za unikaniem NULL jest to, że komplikuje to znaczenie zapytań, a zatem komplikuje zapytania w przewrotny sposób, w porównaniu z komplikacją większej liczby złączeń z większej liczby tabel wolnych od wartości NULL. (Tą przewrotnością zwykle zarządza się usuwając wartości NULL z wyrażeń zapytania możliwie najbliżej miejsca, w którym się pojawiają).

PS Wiele terminów SQL, w tym PK i FK, różni się od terminów relacyjnych. SQL PK oznacza coś w rodzaju superklucza; SQL FK oznacza coś w rodzaju obcego superklucza; ale nie ma nawet sensu mówić o "superkluczu" w SQL: