Вечер добрый. Представим, что у нас есть модель данных и в ней есть сущность "Клиент", "Клиент" может быть или "Физ. лицом" или "Юр. лицом", но ни как ни тем и не тем одновременно, и ничем иным. Соответственно, и в самой БД есть три таблицы - "Клиент", "Юр. лицо", "Физ. лицо", последние две зависимы от первой и как внешний ключ содержат ссылку на "клиент_ид". Согласно описанию нашей ПрО, юр. и физ. лицо не могут одновременно содержать ссылку на одного клиента. Можно ли как-то это контролировать не прибегая к помощи триггеров?

я бы завел в таблице клиентов еще ENUM "тип клиента".
тогда сам запрос будет контроллировать "только один тип". для физлиц и юрлиц в отдельных таблицах разный набор полей или один и тот же?
если разный — то тем более, надо хранить флаг в таблице клиентов, чтоб запрос был на WHERE clients.type = 'PE' вместо 

что ужасно.
а если набор полей одинаков — то зачем добавлять дополнительные таблицы?

Набор полей разный. И да, мысль сделать в клиенте указание его подтипа была. Но на лекциях по проектированию БД нам давали, что если в КМД имеем сущность с подсущностями, то уже при создании информ. отношений. все подсущности выносятся в отдельные таблицы и имеют ссылку на главную. 

Ссылка на таблицу атрибутов конкретного подтипа сущности уже есть энумерация атрибута "подтип".

Это DDL для оракла, уверен для маси можно что-то вроде замутить.

Добавлено через 10 минут и 58 секунд

Так то оно так, но неоднозначность может возникнуть.
Нужно ли в действительности городить вышеприведенный огород с констрейнтами, я еще посомневаюсь(хотя сам горожу весьма регулярно). А вот за типизацию клиентов на уровне мастер таблицы я, лично, двумя руками за.

Я сторонник обратного подхода - объявления каждого типа (ЮрЛицо, ФизЛицо) самостоятельной сущностью, и формирование объединяющей надсущности Клиент. Да, при этом в каждую связную таблицу вместо одного поля падает два - но как много геморроев уходит!

Тоже, конечно вариант 

Но, случается, сферический в вакууме контрагент может иметь еще какие-либо атрибуты, не зависящие от его типа... да еще и в отношении один ко многим. Например контактные лица, телефоны, адреса доставки. Придется либо дублировать структуру этих атрибутов, либо закладываться на дуализм. С плоским справочником таки куда удобнее.

К слову, у меня еще есть, скажем, справочник товаров. Он типизируется сейчас восемью значениями, пять из восьми типов имеют различные расширенные атрибуты, если идти по твоему пути... в строках накладных восемь ссылок надо держать и следить чтобы лишь одна not null была?

Эммм... не понял... Да, в описании сущности каждого контрагента, никуда не деться, поля атрибутов дублированы. Но таблица такого атрибута - едина. И что, что на часть из них ссылается одна таблица, а на остальные - другая?


Почему восемь? два поля - тип товара и его идентификатор в конкретной таблице товаров этого типа, причём оба not null. А уже из конкретной таблицы куда ссылки поведут - это пусть соотв. вьюшки разбираются.

Получается, мы отказываемся от механизма внешнего ключа для контроля целостности. 

Zloxa, почему? мы просто допускаем существование "подвисших" записей на стороне "много"...

Потому что мы не можем прокинуть fk по константе. Увы. 
Или мася умеет?


Это ведь и есть следствие отказа )))
Зачем, ради чего, мы жертвуем согласованностью данных?
Если с адресами контрагента как бы и фиг с ним, но вот с "подвисшими" строками накладной - уже как-то неуютно.

не-а...