krvsaЧто-то вот эдакое...

----------
Cache for Windows (x86-32) 2007.1.3 (Build 607) Wed Oct 17 2007 02:12:09 EDT
Cache не поддерживает связи между объектами в принципе, а не только М:М (которых, впрочем, в действительности не существует). Можно принять и прозвучавшую причину: "чтобы был SQL".
В Cache объект (ради организации сявзи) рассматривается как свойство другого объекта, что не совсем то же самое, что ограничения целостности FK/PK в "реляционных системах", но почти то же самое):
В приведенном примере, в случае действительной поддержки связей, было бы не семь фрагментов описания метаданных, а пять, и, конечно, не было бы конструкций Index ... On ...:

Object {Man,Человек}
Object {Ent,Предприятие}
Object {Wor,Работник}
Relationship {Man,Wor,[номер связи],[тип связи],Является,Это}
Relationship {Ent,Wor,[номер связи],[тип связи],Состоит из,Работает на}

Здесь [номер связи] - так как может быть несколько связей между двумя объектами, и указывается семантика связи в обоих направлениях. В результате "приложение" уже можно использовать в рамках объектного навигатора, так как определены и имена объектов и имена связей, а не только, как и в "реляционных" СУБД, идентификаторы объектов (Man,Ent,Wor) и связей (в конструкции As ... в примере Cache), которые почему то часто называют именами.

Разумеется пользователь в своих схемах (которых для данного примера может быть довольно много, а ему разработчик в Cache навяжет одну):) должен иметь возможность изменять имена объектов, характеристик (часто говорят "свойств") объектов и связей между объектами.

kolesovНу, в общем согласен - действуем по старому принципу: Если есть нечто, что мы хотим назвать "класс, реализующий отношение многие-ко-многим", вначале пытаемся для этого класса найти реальную предметную сущность, на которую можно повесить связь, а дальше действуем как обычно (1 вариант).

За редким исключением, так и выходит (пассажир-билет-автобус, человек-должность-работа, товар-строка-документ и т.д.).

В редком исключении остается двунаправленный список - но пока на ум не приходят примеры для него, да и на практике вроде бы если по факту у нас получается такой список, то лучше поискать, что мы упустили в начальных посылках ;)
Уточню:)
1. Объект и Связь между объектами - это не одно и то же, и они не должны представляться в МД одинаково. Связь, в частности, отличается от объекта тем, что у нее нет и не может быть никаких характеристик (кроме характеристик метаданных: типа, семантики, ограничений). И это отличие, конечно же, не зависит от типа связи. Характеристик нет ни у связи 1:1, ни у связи 1:M, ни у связи М:М (если такие связи существуют).
2. Связи не являются характеристиками объектов. Никакие. Ни 1:1, ни 1:M, ни М:М.
3. Связи должны представляться одинаково, независимо от их типа.
4. Связи должны представляться симметрично для однородной двунаправленной навигации.
5. При объявлении на уровне метаданных (то есть на уровне концептуальной схемы, которая в случае ОМД выполняет и роль логической) связи между объектами A и B, на уровне данных каждый экземпляр объекта A связывается с экземплярами объекта B, а каждый экземпляр объекта B - с экземплярами объекта A (количество связанных экземпляров зависит от типа связи). Связываются, естественно, идентификаторы экземпляров. То есть "двунаправленные списки", о которых Вы говорите, существуют всегда, независимо от типа связи.
6. В универсальном объектном навигаторе пользователь сам может строить любые схемы, основанные на концептуальной модели. Например, пользователь может разместить запись накладной (операцию отгрузки) "выше", а накладную "ниже", тогда как "разработчик" обычно делает наоборот): И примеров такого рода (причем вполне объяснимых и обоснованных) на практике я видел очень много.

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