SQL zachází s NULL speciálně podle své verze 3VL (logika se třemi hodnotami). Normalizace a další teorie vztahů ne. Můžeme však převést návrhy SQL do relačních návrhů a zpět. (Předpokládejte, že zde nejsou žádné duplicitní řádky.)
Normalizace se týká vztahů a je definován z hlediska operátorů, které nezacházejí s NULL speciálně. Termín „normalizace“ má dva nejběžnější odlišné významy:vložení tabulky do „1NF“ a do „vyšších NF (normální formy)“. NULL neovlivňuje "normalizaci na 1NF". "Normalizace na vyšší NF" nahrazuje tabulku menšími tabulkami, které se k ní přirozeně připojují. Pro účely normalizace můžete zacházet s NULL jako s hodnotou, která je povolena v doméně sloupce s možnou hodnotou null kromě hodnot jeho typu SQL. Pokud naše tabulky SQL nemají žádné hodnoty NULL, můžeme je interpretovat jako vztahy a spojení SQL atd. jako spojení atd. Ale pokud rozložíte sloupec s možnou hodnotou NULL, kde byl mezi komponentami sdílen, uvědomte si, že k rekonstrukci originálu v SQL musíte SQL připojit stejnojmenné sloupce mají stejnou hodnotu nebo obě hodnoty NULL . A takové CK (klíče kandidáta) v SQL databázi chtít nebudete. Např. to nemůžete deklarovat jako SQL PK (primární klíč), protože to znamená UNIQUE NOT NULL. Např. omezení UNIQUE zahrnující sloupec s možnou hodnotou Null umožňuje více řádků, které mají v tomto sloupci hodnotu NULL, i když mají řádky v každém sloupci stejné hodnoty. Např. hodnoty NULL v SQL FK způsobí, že budou splněny (různými způsoby podle režimu MATCH), ne selžou, protože se neobjeví v odkazované tabulce. (Ale DBMS se od standardního SQL idiosynkraticky liší.)
Bohužel rozklad může vést k tabulce se všemi CK obsahující NULL, takže nemáme co deklarovat jako SQL PK nebo UNIQUE NOT NULL. Jediným jistým řešením je převod na design bez NULL. Po následné normalizaci bychom mohli chtít znovu zavést do komponent možnost nulování.
V praxi se nám daří navrhovat tabulky tak, aby vždy existovala sada sloupců bez NULL, které můžeme deklarovat jako CK, přes SQL PK nebo UNIQUE NOT NULL. Pak se můžeme zbavit sloupce s možnou hodnotou NULL tím, že jej z tabulky vypustíme a přidáme tabulku s tímto sloupcem a sloupce nějaké CK bez NULL:Pokud sloupec nemá hodnotu NULL pro řádek ve starém designu, pak řádek s jeho hodnota podřádku a sloupce CK jde do přidané tabulky; jinak je ve starém návrhu NULL a v přidané tabulce není žádný odpovídající řádek. (Původní tabulka je přirozeným levým spojením nových.) Samozřejmě také musíme upravit dotazy ze starého designu na nový.
Vždy se můžeme vyhnout NULL pomocí návrhu, který přidá booleovský sloupec pro každý starý sloupec s možnou hodnotou NULL a starý sloupec NOT NULL. Nový sloupec říká pro řádek, zda byl starý sloupec ve starém návrhu NULL, a když je pravda, má starý sloupec být nějakou hodnotou, kterou pro tento účel vybereme pro tento typ v celé databázi. Samozřejmě musíme také upravit dotazy ze starého designu na nový.
Zda se chcete vyhnout NULL, je samostatná otázka. Vaše databáze může být nějakým způsobem "lepší" nebo "horší" pro vaši aplikaci s jakýmkoli designem. Myšlenka vyhýbání se NULL spočívá v tom, že to komplikuje význam dotazů, a tudíž komplikuje dotazování zvráceným způsobem ve srovnání s komplikací více spojení z více tabulek bez NULL. (Tato zvrácenost je obvykle řízena odstraněním NULL ve výrazech dotazu co nejblíže místu, kde se objevují.)
PS Mnoho pojmů SQL včetně PK a FK se liší od relačních pojmů. SQL PK znamená něco jako superklíč; SQL FK znamená něco jako cizí superklíč; ale ani nemá smysl mluvit o "superklíči" v SQL:
Kvůli podobnosti tabulek SQL s relacemi jsou termíny, které zahrnují vztahy, na tabulky aplikovány nedbale. Ale i když si můžete vypůjčit termíny a dát jim SQL významy – hodnota, tabulka, FD (funkční závislost), superklíč, CK (kandidátský klíč), PK (primární klíč), FK (cizí klíč), spojení a predikát, NF (normální forma), normalizovat, 1NF atd. – nemůžete jen nahradit tyto významy SQL za tato slova v definicích, větách nebo algoritmech RM a získat něco rozumného nebo pravdivého. Navíc SQL prezentace pojmů RM téměř nikdy vlastně vám řeknou, jak správně aplikovat pojmy RM na databázi SQL . Prostě papouškují prezentace RM a nevšímají si toho, zda jejich použití významů SQL pro termíny dělá věci nesmyslnými nebo neplatnými.