ЧАЛНадеюсь, serg99, Вы не потребуете от меня проектов баз данных по тем или иным предметным областям ?
Упаси Бог. Я просто пытаюсь прояснить достаточно общий вопрос.

ЧАЛУверяю Вас, что я хорошо знаком и с этой предметной областью, о которой Вы говорите.
Я рад за Вас.

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


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

Меня интересовало не некое хранилище, которое "в принципе можно представить" и где что то обновляется из "какой то OLTP системы", а как бы в рамках ВАШЕЙ корректно спроектированной базы хранились бы данные про одну книгу и трех авторов.

Насколько я понял из Вашего текста у Вас был бы один объект "Книга" и три объекта "Автор", каждый из которых был бы связан бинарной "связью" с этой книгой. При этом каждая связь имела бы характеристику "Доля".

Однако при этом, как уже упоминалось, должно выполняться равенство Доля1+Доля2+Доля3=100%. То есть мы имеем 3 штуки "чего то", чьи характеристики взаимосвязаны (взаимозависимы, взаимообусловлены, взаимо...). Если характеристики нескольких "чего то" взаимозависимы, то эти "чего то" связаны. То есть в данном случае интересует
1) Как в Вашей системе реализуется "связь" между "связями"?
2) Если она никак не реализуется, то как можно в Вашей системе задать констрейн, так, что бы никакое приложение не смогло бы изменить какую ни будь из трех характеристик "Доля", если в результате нарушится искомая функциональная зависимость Доля1+Доля2+Доля3=100%?

Да забыл. Под системой в вопросах 1 и 2 подразумевается СУБД. Если ответы на оба вопроса отрицательные, то получается, что описанный констрейн предметной области должен отслеживаться на уровне приложений.

Я не хочу дискутировать хорошо это или плохо, мне просто хочется некоторой ясности.

P.S. За то, что n-арная связь может быть представлена в виде набора бинарных, меня агитировать не надо. Это и так понятно. Это правда не значит что n-арные связи в природе не существуют :-).