Колоната (или колоните) на първичен ключ трябва да НЕ е NULL. Записът не може да бъде идентифициран еднозначно чрез NULL. Така че ID колоните в референтния край на външния ключ трябва да бъдат дефинирани като NOT NULL.
Въпреки това е легитимно дизайнерско решение връзката с външен ключ да бъде незадължителна и начинът да се представи това е като направите референтния край на ключа незадължителен, т.е. позволявайки NULL.
От гледна точка на моделиране на данни това, което описахте, е (изключителна) дъга:"таблица ... с два или повече външни ключа, където един и само един от тях може да бъде ненулев." При логическото моделиране дъгите са напълно приемливи, но има силно мнение в полза на прилагането им като отделни таблици. Във вашия сценарий това би било обща Sale таблица плюс две таблици от подтип, VehicleSale и PieceSale .
Предимствата на прилагането на отделна таблица са:
- по-лесно налагане на ограниченията на външния ключ;
- по-лесно добавяне на допълнителни колони, свързани с (да речем) продажбите на превозни средства, които не се отнасят за продажбите на парче;
- по-лесно разширяване на модела с допълнителни подтипове;
- по-ясен модел на данни, който може да опрости разработването на приложения.
Предимствата обаче не са еднопосочни. Въпреки че е доста лесно да се гарантира, че Sale важи или за VehicleSale или PieceSale но не и двете, налагайки правило, което Sale трябва да имате запис на дете всъщност става доста неудобно.
И така, преобладаващият съвет е, че изключителната дъга е погрешна и като цяло е добър съвет. Но не е толкова ясно, колкото някои го правят.
