Помогите разобраться в интересном вопросе, связанным с проектированием БД.

Есть отношение (реляционная табличка) R:
Номер_типа_платежа, Счет_получателя, Номер_платежа, Cумма, Номер_доп_реквизита, Имя_доп_реквизита, Значение_доп_реквизита.

Вижу следующие зависимости:

Номер_типа_платежа --> Счет_получателя;
Номер_платежа --> Сумма;
Номер_платежа --> Номер_типа_платежа;
Номер_платежа, Номер_доп_реквизита --> Значение_доп_реквизита.
Номер_доп_реквизита --> Номер_типа_платежа, Имя_доп_реквизита.

Возможно, что какие-то зависимости между атрибутами отношения R мною упущены.

В голову приходит декомпозиция R на четыре таблички:

Тип платежа (Номер_типа_платежа,Счет_получателя);
Доп_реквизиты(Номер_доп_реквизита,Номер_типа_платежа, Имя_доп_реквизита);
Платежи(Номер_платежа, Cумма, Номер_типа_платежа);
Значения реквизитов (Номер_платежа, Номер_доп_реквизита,Значение_доп_реквизита);

Но в при такой декомпозиции есть возможность добавить в таблицу "Значения реквизитов" запись, у которой "номер_доп_реквизита" не входит в набор, определяемый атрибутом "Номер_типа_платежа" в таблице "Доп_реквизиты".

Пример. Есть два типа платежа: SIMPLE с номером 1 и COMPLEX с номером 2.
В таблице "Тип платежа" имеем две записи: (1,0000000) и (2,9999999).

Для типа SIMLPE, необходимо наличие дополнительного реквизита SA с номером 11. Для типа COMPLEX необходимы реквизиты CA с номером 21 и CB с номером 22. Т.е. в таблице "Доп_реквизиты" имеются записи: (11,1,SA); (21,2,CA); (22,2,CB).

Если принят платеж COMPLEX с номером 0, на сумму 10.00 у.е. со значением реквизита CA равным "Значение CA" и значением CB равным "Значение CB", то в таблице "Платежи" появится запись (0, 10.00, 1). Помимо этого в таблице "Значения реквизитов" появиться записи (0,21, "Значение CA") и (0,22, "Значение CB"). Однако, теоретически, при приведенной выше декомпозиции,
ничто не мешает вставить в таблицу "Значения реквизитов" запись (0,11, "Значение SA").

Хочется, чтобы такая возможность была исключена на уровне ссылочной целостности. Но для этого, видимо, необходима иная декомпозиция исходного отношения. Каким образом это можно сделать? Возможно кто-то укажет ссылки на ресурсы, в которых можно найти ответ на этот вопрос.

Видимо, шибко тяжелая вещь эта декомпозиция? Либо вопрос глупый? Не пойму.

ChAМного букв, посему, IMHO, никто не хочет задумываться :)

А задумываться хотя бы изредко стоит.

ChAА если серьезно, то для поиска зависимостей необходимо знать их наличие на предметном уровне, на уровне перечисления полей одной таблицы они совсем не очевидны.

Предметную область знать может и надо, но в данном случае, как мне кажется, это не обязательно.

Примером я хотел донести следующую мыслю (видимо не очень получилось): есть Предмет(Платежи), есть значения некоторых свойств предмета (Значения реквизитов), и есть две таблички, одна из которых задает типы предметов (Типы платежей), а другая сопоставляет этим типам множество допустимых свойств (Доп_реквизиты). Спрашивается как, используя ссылочные ограничения, не допустить наличия в у предмета, имеющего некоторый тип, таких свойств, которые ему не сопоставлены таблицей "Доп_реквизиты"?

ModelRА почему именно ссылочной ?
Почему не декларативной в принципе, и где граница допустимого. Например, в ОРАКЛ можно сконструировать материализованное представление с ограничениями - это допустимо?

Честно говоря с таким типом целостности не знаком. Не свойственна ли она лишь Oracle?

В теории реляционных БД ничего об этом не встречал, хотя усилинно и не рыскал. Буду благодарен, если укажите какие-либо полезные ссылочки для ознакомления.

Может после и отвечу на вопросы
ModelR
Почему не декларативной в принципе, и где граница допустимого.

ModelRНапомню,
декларативное ограничение целостности (в отличие от процедурного) - родовой термин. Теоретически это любой предикат, истинность которого СУБД должна поддерживать. Практически DDL СУБД включают уникальность, ссылочные ограничения, ограничения внутри строки таблицы.
Так вопрос теоретический или практический?

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

В противном случае, можно было бы, всегда проектировать БД в виде одной таблички, наложив массу декларативных ограничений, например внутри строки таблицы.

По видимому, мой первоначальный вопрос можно рассматривать таким образом: можно ли те ограничения, что приведены в примере с платежами, реализовать как ограничения ссылочной целостности? Вопрос скорее теоретический, ведь можно не париться и реализовать все в триггерах, но это не интересно. То ли я чего-то упустил, какую-то сущность или зависимость. Сомнение вызывает и то, что в примере декомпозиции с платежами есть несколько различных путей от одной таблице к другой по зависимстям типа M:1. С одной стороны, это говорит о том, что какая-то из них лишняя, с другой стороны, я не могу выбрасить ни одной.

Вот такие пироги.