Мимо пробегал...
[ ( column [ ,...n ] ) ] состоящий из набора колонок
REFERENCES ref_table [ ( ref_column [ ,...n ] ) ] связанный с набором колонок в другой таблице
Слишком быстро - вот и мимо:) Автору нужен ключ на набор ТАБЛИЦ.
Кстати, решалось бы, если можно было реализовывать ссылки на View.
В Оракл 9 - 10 это можно объявлять, но лишь DISABLE NOVALIDATE :(.

Не скажите. Сплошь и рядом такая задача возникает не по ошибке. Начиная с аналитики в бухучете.

ChA ModelRНачиная с аналитики в бухучете.И что с ней не так ?Вот топик по теме структур бухучета. Там много примеров приводили, начиная с OEBS.
Дело в том, что бухучет сам по себе прекрасный пример информационной модели. Коротко - каждый счет логически есть сущность со специфической аналитикой, Аналитикой счета может быть сегодня все, что и не предполагалось вчера:). Т.е.применение максималистского подхода означает рефакторинг таблиц при изменении плана счетов. Практически никто так не делает.

ChA ModelRАналитикой счета может быть сегодня все, что и не предполагалось вчера Некоторое представление о бухучете(БУ) имею, как, думаю, и половина здесь бывающих. В принципе, Вы подтверждаете предположение выше, о недостатке понимания/знания предметной области.Определенно, Вы же не утверждаете, что сегодня мы можем знать все про завтра? В любом случае система не должна исходить из того, что завтра ничего не измениться. ChA
ModelRприменение максималистского подхода означает рефакторинг таблиц при изменении плана счетов. Практически никто так не делает.Со второй частью готов согласиться, с первой - нет. Если бы в процессе проектирования БД для БУ стоял специалист, хорошо понимающий предметную область, то ссылки на "разнородные" сущности всплыли бы на этапе обследования, именно в связи с аналитикой. В таком случае нашелся бы способ ее решить, например, введением общего "предка", с последующим "расщеплением" на subtypes. Утрированно говоря, если объектом ссылки может быть любой объект, значит должна существовать сущность "Любой объект" :) Которая является эээ... предком для всех остальных сущностей. Более того, есть системы, реализованные именно таким образом, в которых нет проблем с разнородными ссылками. Возможно, у них есть свои недостатки, но нарушение ссылочной целостности точно не относится к их числу.Со сторны удаления - да, единый каталог OID предотвращает безобразия. При изменени/добавлении система контроля целостности будет допускать много мусора. Точное же отражение в ссылочной целостности ограничений предметной области ведет к комбинатрному взрыву числа сущностей типа каталогов подмножеств OID. Так что практически это реализуется на уровне приложения динамически.
Вот тут разбирался с КЛАДР. Три естественных ограничения, кстати реальные данные их немножко:) нарушают:
-Актуальные объекты могут быть частью только актуальных.
-Район обязан входить в субъект федерации.
-Переименованный объект обязан иметь парный актуальный того же уровня.
Если их реализовывать как ссылочную целостность, то шесть сущностей немедленно.

ChA ModelRВы же не утверждаете, что сегодня мы можем знать все про завтра? В любом случае система не должна исходить из того, что завтра ничего не измениться.Ну почему же. В принципе, множество предметных областей настолько формализовано, что добавить практически уже нечего. Неплохое пособие, но сам автор их назвал 'Kick-Start' Data Models, т.е. добавить есть много чего. ChA ModelRЕсли их реализовывать как ссылочную целостность, то шесть сущностей немедленно.И ? Есть популярные СУБД, для которых это становится непреодолимым препятствием ? Э.., так это ж только начало и только для одной таблицы.
С "не отрываться от практики" согласен.