прохожий 317Вы немного преувеличиваете, ModelR, про "утрату декларативного задания" (особенно про значение утраты) и про "объявлю пару атрибутов".
Во-первых, не пару, а тройку: Человек,Дата занятия,Пара.Да, опечатка конечно. прохожий 317
Во-вторых, нужно объявить еще одну тройку уникальной: Группа,Дата занятия,Пара.
В-третьих, это так же делается и в случае использования ссылок в ОМДТак в Вашей версии ОМД сущности могут иметь характеристики-ссылки? Тогда о чем мы так долго спорили... прохожий 317, а из этого почти автоматически следует, как Вы правильно подметили, что можно поправить (в случае использования явных связей вместо ссылок).Или не могут? прохожий 317

В-четвертых. Повторю, что определенные накладные расходы есть. Но я к ним (к написанию триггеров, например) отношусь совершенно спокойно. И вот почему (даже если говорить только об ОДНОМ дне):
1) Человек не может проводить за день больше определенного количества Пар;
2) Группа не может заниматься за день больше (своего) определенного количества Пар;
3) не могут соседствовать аудитории (для соседних пар), расстояние между которыми Человек не сможет преодолеть за время перерыва между парами;
4) аналогично п.3 для Группы;
5) и т.д.
И многие из этих условий нельзя будет выполнить, просто объявив "уникальность". Придется (на сегодняшний день) писать код. И нет никаких гарантий, что в этот же код не следует интегрировать и те ограничения, которые Вы сделали "декларативными". Вот это существенный момент. Согласен, что даже сильно накрученная декларативная целостность покрывает лишь малую часть бизнес-правил. Но возможность декларировать наиболее фундаментальные правила сильно упрощает прикладную часть, а также снижает риски при модификациях и переделках. Поэтому для меня это более высокий приоритет. прохожий 317
И еще раз о ссылках и связях. Это, с концептуальной точки зрения, одно и то же (то есть они нужны для одного и того же). Записав идентификатор экземпляра idB объекта B в значение некоторой характеристики hA экземпляра idA объекта A, мы установили связь между экземплярами idA и idB В данном случае я называю характеристику hA ссылкой, проекцию А [IDA ,hA] - связью (бинарной). В данном случае связь встроена в В. Можно ее вынести в отдельную таблицу путем очевидной декомпозиции. Поэтому никак не пойму, что значит "использование явных связей вместо ссылок" . Может это как раз упомянутая декомпозиция?

mir[quot прохожий 317]Это понимание воплотилось в документах комитета ANSI/SPARC еще задолго до господства реляционных систем , а прошедшие десятки лет его только подтвердили. Кстати, упоминаемая архитектура ANSI/SPARC насколько мне известно, никогда не существовала в виде официального стандарта, хотя по тексту очень многих книг можно понять обратное. Это был всего лишь промежуточный отчет об исследовательской работе, выполненный по заказу ANSI/SPARC, кажется даже студентами. Хорошая идея не нуждается в регалиях :).

Сорри, следует читать:

В данном случае я называю характеристику hA ссылкой, проекцию А [IDA ,hA] - связью (бинарной). В данном случае связь встроена в А .

прохожий 317Если уж быть точным, ModelR, то "уникальность" не проходит вообще в "нашем примере", так как Занятия в неутвержденном Расписании могут содержать неизвестные значения (или не иметь связей). Но это мелочи.Да, и более того, в этом случае в "чистой" РМД, без NULL, занятия с известными и неизвестными данными - это будут вообще разные отношения. Либо опять таки декомпозиция - выделение связей. прохожий 317
Мы не спорили, а разбирались, мне кажется. В "моей версии" ссылок не должно быть. Это принципиально. Вопрос был не о ссылках вообще - пнятно, что в Ваших связях участвуют ссылки на объекты, а не их копии, я надеюсь:). Вопрос был о допустимости ссылок в сущностях (объектах по Вашему) типа Занятие. Я видел ответ НЕТ и много раз, но затем следовали пассажи типа
авторсимметричная (двусторонняя) семантика поддерживается в ОМД для ссылок ("неявных связей") "так же" как и для явных связей. из которых следует ДА.