SQL третира NULL специално за своята версия на 3VL (логика с 3 стойности). Нормализирането и другите релационни теории не го правят. Въпреки това можем да преведем SQL дизайни в релационни дизайни и обратно. (Да приемем, че тук няма дублиращи се редове.)
Нормализиране се случва с отношенията и се дефинира по отношение на оператори, които не третират NULL специално. Терминът "нормализация" има две най-често срещани различни значения:поставяне на таблица в "1NF" и в "по-високи NF (нормални форми)". NULL не засяга "нормализирането към 1NF". "Нормализация към по-високи NF" заменя таблица с по-малки таблици, които естествено се присъединяват към нея. За целите на нормализирането можете да третирате NULL като стойност, която е разрешена в домейна на колона с нулева стойност в допълнение към стойностите на нейния SQL тип. Ако нашите SQL таблици нямат NULL, тогава можем да ги интерпретираме като релации и SQL присъединяване и т.н. като присъединяване и т.н. Но ако разложите къде е била споделена колона с нула между компонентите, тогава осъзнайте, че за да реконструирате оригинала в SQL, трябва да се присъедините към SQL колони със същото име са равни или и двете са NULL . И няма да искате такива CK (кандидат ключове) в SQL база данни. Например не можете да го декларирате като SQL PK (първичен ключ), защото това означава УНИКАЛНО, НЕ НУЛЕВО. Например ограничение UNIQUE, включващо колона с нула, позволява множество редове, които имат NULL в тази колона, дори ако редовете имат еднакви стойности във всяка колона. Например NULL в SQL FK карат те да бъдат удовлетворени (по различни начини за режим MATCH), да не се провалят, тъй като не се появяват в посочената таблица. (Но СУБД идиосинкратично се различават от стандартния SQL.)
За съжаление разлагането може да доведе до таблица с всички CKs, съдържащи NULL, така че няма какво да декларираме като SQL PK или UNIQUE NOT NULL. Единственото сигурно решение е да конвертирате в дизайн без NULL. След това нормализиране може да искаме да въведем отново известна нула в компонентите.
На практика успяваме да проектираме таблици така, че винаги да има набор от колони без NULL, които можем да декларираме като CK, чрез SQL PK или UNIQUE NOT NULL. След това можем да се отървем от колона с нула, като я изхвърлим от таблицата и добавим таблица с тази колона и колоните на някакъв CK без NULL:Ако колоната не е NULL за ред в стария дизайн, тогава ред с неговата стойност на подреда и колона CK влизат в добавената таблица; в противен случай е NULL в стария дизайн и няма съответен ред в добавената таблица. (Оригиналната таблица е естествено ляво присъединяване на новите.) Разбира се, ние също трябва да модифицираме заявките от стария дизайн към новия.
Винаги можем да избегнем NULL чрез дизайн, който добавя булева колона за всяка стара колона с нула и има старата колона NOT NULL. Новата колона казва за ред дали старата колона е била NULL в стария дизайн и когато е истина, старата колона е някаква стойност, която избираме за тази цел за този тип в цялата база данни. Разбира се, ние също трябва да модифицираме заявки от стария дизайн към новия.
Дали искате да избегнете NULL е отделен въпрос. Вашата база данни може по някакъв начин да бъде "по-добра" или "по-лоша" за вашето приложение с всеки дизайн. Идеята зад избягването на NULL е, че то усложнява значенията на заявките, следователно усложнява заявките по извратен начин, в сравнение с усложняването на повече присъединявания от повече таблици без NULL. (Тази извращение обикновено се управлява чрез премахване на NULL в изразите на заявката възможно най-близо до мястото, където се появяват.)
PS Много SQL термини, включително PK и FK, се различават от релационните термини. SQL PK означава нещо повече като суперключ; SQL FK означава нещо повече като чужд суперключ; но дори няма смисъл да говорим за "суперключ" в SQL:
Поради приликата на SQL таблиците с релациите, термините, които включват релации, се прилагат небрежно към таблиците. Но въпреки че можете да заемате термини и да им давате SQL значения - стойност, таблица, FD (функционална зависимост), суперключ, CK (кандидат ключ), PK (първичен ключ), FK (външен ключ), присъединяване и предикат, NF (нормална форма), нормализиране, 1NF и т.н. - не можете просто да замените тези SQL значения с тези думи в RM дефиниции, теореми или алгоритми и да получите нещо разумно или вярно. Освен това SQL презентации на RM понятия почти никога всъщност ви казва как правилно да прилагате RM понятията към SQL база данни . Те просто като папагал RM презентации, без да обръщат внимание на това дали използването им на SQL значения за термини прави нещата безсмислени или невалидни.
