Може да искате да помислите за модел на данни тип/подтип. Това много прилича на клас/подкласове в обектно-ориентираното програмиране, но е много по-неудобно за изпълнение и нито една RDBMS (за която знам) не ги поддържа естествено. Общата идея е:
- Дефинирате тип (сграда), създавате таблица за него, давате му първичен ключ
- Дефинирате два или повече подтипа (тук Болница, Клиника, Училище, Университет), създавате таблици за всеки от тях, създавате първични ключове... но първичните ключове са също външни ключове, които препращат към таблицата за изграждане.
- Вашата таблица с една колона „ObjectType“ вече може да бъде изградена с външен ключ върху таблицата Building. Трябва да се присъедините към няколко таблици, за да определите какъв вид сграда е, но все пак ще трябва да направите това. Това или съхранявайте излишни данни.
Забелязали сте проблема с този модел, нали? Какво трябва да попречи на сградата да има записи в две или повече от таблиците с подтипове? Радвам се, че попитахте:
- Добавете колона, може би „BuildingType“, към сградата, кажете char(1) с разрешени стойности на {H, C, S, U}, показващи (duh) тип сграда.
- Създайте уникално ограничение за BuildingID + BuildingType
- Имайте колоната BulidingType в подтаблиците. Поставете контролно ограничение върху него, така че да може да бъде настроено само на стойност (H за таблицата с болници и т.н.) На теория това може да бъде изчислена колона; на практика това няма да работи поради следната стъпка:
- Създайте външния ключ, за да свържете таблиците с помощта на двете колони
Voila:Като се има предвид набор от редове BUILDING с тип H, запис в таблицата SCHOOL (с тип S) не може да бъде настроен да препраща към тази сграда
Ще си спомните, че казах, че е трудно за изпълнение.
Всъщност големият въпрос е:струва ли си това да се прави? Ако има смисъл да се прилагат четирите (или повече, с течение на времето) типа сгради като тип/подтип (допълнителни предимства за нормализиране:едно място за адрес и други атрибути, общи за всяка сграда, със специфични за сградата атрибути, съхранявани в подтаблиците), може да си струва допълнителните усилия за изграждане и поддръжка. Ако не, значи се връщате към изходната позиция:логически модел, който е труден за прилагане в средната съвременна RDBMS.
