ЧАЛЗначит я правильно понял Вашу, serg99, постановку задачи. А Вы не правильно поняли. Есть ДВА объекта в точном соответствии с "корректной постановкой задачи": Книга и Автор. Есть ОДНА связь М:М:

Книга <- Написана/Участвовал в написании -> Автор

с характеристиками связи "Сумма" и "Доля".
И "Сумма" обновляется триггером при обновлении характеристики "Прибыль" объекта Книга или характеристики связи "Доля" (видимо "Сумму" лучше сделать вычисляемой характеристикой).
И "Доля" обновляется и контролируется (сумма долей=1) триггером при обновлении характеристики "Доля".
Все таки Вы меня не так поняли. Я хочу сохранить в БД информацию об одном экземпляре книги (с конкрентным названием) и о трех экземплярах авторов (с конкретрными фамилиями), которые эту книгу написали. Ни про какую Сумму и необходимость ее обновления механизмами СУБД я не писал, соответственно и упомянутый Вами Триггер к делу не относится.

Если по вашему "есть одна связь М:М", то как это соотносится с Вашим утверждением буквально в следующем абзаце, что ""n-арные" связи не существуют"? Связь М:М - это разве не частный случай n-арной связи?

Ну пусть будет одна связь между Книгой и тремя авторами. Тогда значит у этой связи ТРИ характеристики - Доля1, Доля2 и Доля3. Как система понимает какая характеристика к какому автору относится?

ЧАЛОбратите внимание на свою серьезную ошибку: "констрейна" (хотя ничто не мешает описывать констрейны любой сложности на уровне ОСУБД) НЕ ДОСТАТОЧНО для обновления "Доли".
У Вас логическая неувязка. Констрейн не является условием обновления Доли, - он является условием НЕ обновления Доли. То есть для обновления значения характеристики Доля1 необходима соответсвующая команда от приложения И отсутствие заданного на уровне СУБД констрейна не позволяющего эту команду выполнить (в общем случае констрейн может быть задан на уровне прав доступа пользователя, на уровне флагов Read Only, и на уровне механизмов обеспечения логической целостности данных (например с помощью триггеров)).


ЧАЛP.S. "n-арные" связи не существуют (следует понимать семантическую разницу между связью и составным объектом; см. мой вариант формализации РМД), и, что очень важно, "небинарные связи", рассматриваемые в "книжных" примерах, НЕ МОГУТ быть представлены в виде "набора бинарных".
Хотелось бы опуститься с небес на землю. Я не обсуждаю основной вопрос философии и варианты формализации РМД, я спрашиваю Вас о том как в ВАШЕЙ ОБД будут представлены 4 конкрентных экземпляра объектов (Книга и три Автора) и связи между ними. Готов даже к тому, что у Вас связь будет представлена составным объектом. Просто хочется конкретных подробностей. Это три связи на каждого автора? Одна связь на всех? Связь реализуется составным объектом? Все четыре экземпляра хранятся как составной объект?

ЧАЛserg99, Вы совсем запутались. Поверьте мне. n в "n-арные связи" у моих оппонентов - это количество объектов (сущностей, классов - эти понятия часто используются в слаборазвитых моделях данных), "вовлеченных в связь", а не количество экземпляров одного объекта, связанных с конкретным экземпляром другого объекта.
Я Вас спрашиваю не о том что думают Ваши оппоненты, а том что думаете Вы сами.

ЧАЛНо возникшая у Вас путаница очень неплохо демонстрирует, лишний раз, что никаких "небинарных связей" нет.
У меня нет никакой путаницы, потому что пока я просто задаю Вам вопросы. Если "никаких "небинарных связей" нет", то что означает упомянутый Вами термин "связь М:М". Разновидность бинарной связи?

ЧАЛУ ОДНОЙ связи есть (раз Вам нужна только "Доля") ОДНА характеристика связи - "Доля". И никаких "логических неувязок" у меня нет, тем более, если "констрейн может быть задан... (например с помощью триггеров)."
Я знаю что в существующих распространенных СУБД такой констрейн может быть задан. Я спрашивал может ли быть задан констрейн в ВАШЕЙ СУБД. Вы не ответили. На всякий случай спрошу - ОДНА характеристика ОДНОЙ связи имеет ОДНО значение?

ЧАЛЕще раз обращаю Ваше внимание, что с помощью только указанного ограничения Вы не сможете обновлять значение характеристики "Доля" (ни в какой модели данных).
Я так же обращаю повторно Ваше внимание на логические проблемы в Ваших рассуждениях - С ПОМОЩЬЮ ограничения нельзя обновить ни одно значение ни одной характеристики, так как с помощью ограничения можно только ПОМЕШАТЬ обновлению значения характеристики.


ЧАЛЯ подробно описал схему ОБД для Вашего примера. Какие три связи на каждого автора ? Связь реализуется связью, а не составным объектом. Какие четыре экземпляра ?
Получается и "критика" зря старался...
В общем то это понятно, что связь реализуется связью, объект реализуется объектом, а база данных реализуется базой данных :-). Но мне хотелось бы вернуться к примеру.

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

Характеристикой чего является характеристика

Название Книги= "Приключения Васи Пупкина"?

Характеристикой чего являются характеристики

Фамилия="Иванов"
Фамилия="Петров"
Фамилия="Сидоров"?

Характеристика Доля насколько я Вас понял является характеристикой связи.

Но у меня есть три значения этой характеристики.

Характеристикой чего являются характеристики

Доля=20%
Доля=30%
Доля=50%?

Если не можете или не хотите отвечать по существу, то лучше не отвечайте. При получении ответа типа "Разве Вам еще не понятно" и "я же уже все подробно объснил" я не буду Вас больше утомлять своими вопросами.