Бредятина,

Если у объекта нет ни одной характеристики (т.е. он не включен ни в один классификтор), то это не объект, а явно выделенная позиция в системе идентификации объектов для регистрации будущего объекта.
Система регистрация объектов создает не объекты, а идентификаторы.
Объект - совокупность классификационных признаков в каждый момент времени. Идентификатор объекту нафиг не нужен, он нужен системе идентификации для отслеживания жизненного цикла объекта.
Связи = отношение объектов. Связь типа {(ИД1,ИД2,,,),(ИД11, ИД22,,,)} фигня малопригодная для описания сути отношений. Связь должна быть типизирована, объекты должны получать роли, роли должны быть типизированы.
Это минимум, что бы можно было что то осмысленное построить с помощью этих понятий.

_модБредятинаЯ просто давно убедился, что логическую и концептуальную модель следует банально соединить
В догонку простой пример:
в концептуальной модели есть одна сущность Счет-фактура
в логической модели несколько таблиц (файлов, сегментов, типов записей - зависит от СУБД)
Если модели объединить, то СУБД должна автоматически обеспечивать хранение одной сущности Счет-фактура. Ни одна из СУБД (любого типа) этого не умеет.
А зачем СУБД Счет-фактура? На тех же типах образующих с/ф можно построить другие понятия. СУБД до этого не должно быть дела.

_мод,

если "единая" сущность сложная, то зачем ее хранить монолитно? лучьше хранить модель сущности в схеме контекста концептов
другое дело что СУБД не могут работать на этом уровне и приходиться генерировать скл

Бредятина
:) Вы о какой модели данных рассказали? В которой Вы ввели концепции (напомню, что в РМД, по сути одна ключевая концепция - отношение, а в ОМД две - объекты и связи):
1) "объект";
2) объект Вы понимаете таким образом, что есть еще "класс";
3) "классификатор";
4) "жизненный цикл объекта";
5) "отношение объектов";
6) "типы отношений объектов";
7) "роль";
8) "тип роли".

:( Не знаю.
Рассуждении таковы.
Есть "субъект" с кое-какими начальными навыками "идентификации".
Идентификация ограничено возможностями органов идентификации(допустим глаз там, ухо, нос,...), которые могут идентифицировать "объект" в определенном диапазоне с определенной разрещающей способностью. Если эти диапозоны градуировать и именовать, то получим первичные домены "свойств" доступных идентификации.
Метод идентификации - нечеткое сравнение с элементами домена свойств.
На горизонте появляется претендент на "объект".
Органы идентификации усиленно изучают объект, после установления списка свойств менеджер кучи идентифицированных объектов сравнивет список свойств со списками свойств уже идентифицированных объектов и если находит, то посылает этого претендентат нафиг, иначе он этому списку свойств присваивает уникальный идентификатор и появляется новоиспеченный идентифицированный объект.
Менеджер классификации субъекта начинает сравнивать имена списка свойств объекта с списком свойств "типов". ("Тип" - куча объектов со одинаковыми именами свойств. Если значение одного свойства для всех объектов в типе одинаковы, то тип вырождается, это свойство у типа исчезает, вместо этого появляется (если таковойеще нет) ветка в "классификаторе" графе с именем этого свойства и тип привязывается к этой ветке. Если мир уже изучен, то типов больше нет, еть только классификатор и привязанные к ней идентификаторы объектов. Но,так не бывает. :(). Как только какое-то подмножество свойств объекта совпадает со списком свойств типа, то сразу к этому типу добавляется данный объект. Если какие то свойства объекта остались нетипизированными, то быстренько так создается новый тип и объект суется и в этот тип. По мере изучения мира типов становятся все меньше и меньше, а классификатор разрастается. Щоб с этой фигней бороться классификатор называют множественным классификатором, каждый из которых может начинаться либо с имени доменов свойств, либо именем элемента домена свойств и мучаются кто как может.
Это по части идентификации и классификации.
Когда дваили несколько объектов начинают с какого то бодуна друг с другом отношаться у этих свинюшек появляются новые свойства присущие только всем вместе!!!! Эту фигню надо как то идентифицировать, но менеджер не может идентифицировать кучу объектов, потому ему приходится всю эту кучу считать как одного объекта и классифиировать. При этом ему все ж приходится этот новый объект "связать" с объектами из кучи, попутно запомнив с какого бодуна они связались и кто тут кого доминировал , а кто и был пассивным пидерром. Так как таких бодунов бывают часто , то приходится все эти бодуны как то идентифицировать. Таким образом появлется отношене объектов, идетифуатор отношения, связь и тип связи объекта с отношением, роли объектов внутри отношения.
Но, все это мертвячина. В эти долбаные отношения объекты и входят и оттуда выходят и это все время мучает менеджера процессов и регистрации изменений состояния объектов во времени, ведь они в этих процессов могут изменнить значения свойств своих, да и совсем потерять некоторые или все свойства или приобрести новые. За всеми блин приходится присматривать.
Вот такая модель данных.