_модViPRosесли читать по русски, то все понятно, что {Сотрудник} Работает<> В {Цех}
Неудачный пример. Это просто свойство объекта Сотрудник, такое же как его таб. номер. И никаких отношений
Не понятый до конца, а не неудачный.

ViPRosнисходящие сявзи несут разную семантику
восходящие одну - навигационную
Еще раз прошу пояснения - ради чего сделана такая асимметрия? Почему эти половинки бинарной связи должны чем-то отличаться? На нашем простом примере связи Сотрудника с Цехом. Ощущение такое, что вынужденное использование РМД привело Вас к очевидному решению маппинга между "связями" на концептуальном уровне и отношениями РМД. Но и в этом случае непонятно что такое связь на концептуальном уровне.

vadiminfoViPRos ....в РМД никаких...

Возможно, для верности, нуно заявить, что в РМД и сущностей нет, чтобы позиция была более последовательна.
А ViPRos и написал ОТНОШЕНИЯ, а вовсе не СУЩНОСТИ:)
vadiminfo Раз для сущностей моно, то почему для связей низя?
Это же очевидно. Только эти отношения неразличимы. Вы что сказать-то хотели?:)
vadiminfo А Вам с ЧАЛом то этого не надо, судя по всему: потому, скорее всего, надо обих убирать.
А в РМД нужно убрать только одно - ОТНОШЕНИЕ. Что, конечно, в два раза проще)))

vadiminfoБредятинаЭто же очевидно
Тада связи есть в РМД: связей не было ба, если представить их с помощью структур и ОЦ МД не было бы никакой возможности. Отсутсвие семантической окраски для связей и самих связей не одно и то же. Это же очевидно.
Как обычно, взяли из абзаца только то, что удобно:) А где же:
"Только эти отношения неразличимы."
Нет именно связей, а вовсе не только "семантической окраски". Есть только отношения. Связи - в другой модели. Модели ViPRos, например. И маппинг. Какой смысл много лет этого как бы не понимать???

ViPRos у меня именно X_Y{Z} и Y_X{Z} потому и второй тип связи навигацинный, т.е. через эту связь можно получить тип без надобности влезать в детали
В 12812389 написано
Сотрудник_Работает{Сотрудник}
и обратная
Работает{Сотрудник}_Сотрудник
Значит там была ошибка. Правильно:
Работает_Сотрудник{Сотрудник}

Но сути это не меняет. Совершенно не понимаю почему Вы игнорируете мои объяснения про соотношение понятий с РМД. Что значит навигационный? И в "первом" направлении связь навигационная.

ViPRos а первая - кроме получения типа надо анализировать семантику - тип ссылки, роль типа, контекст и т.д.
Итак, под связью Вы понимаете не связь МЕЖДУ ТИПАМИ Сотрудник и Цех. А связь между ТИПОМ Сотрудник и ОТНОШЕНИЕМ Работает. Так???

ViPRos один тип может сослаться на множество типов
Вы, вероятно, хотели сказать, что между двумя типами может быть множество связей (то, что один тип может быть связан со многими это же очевидно)? Но почему-то применили новое понятие "сослаться"???

ViPRos тип лукапится ролями типов
объекты - ролями типов и лукапами объектов во всю глубину
И снова Вы ввели новое понятие - ОБЪЕКТ. Что это такое? Как соотносится с ТИПОМ и ОТНОШЕНИЕМ (особым типом)?

vadiminfoБредятинаА где же:
"Только эти отношения неразличимы."

В "семантической окраски".

БредятинаНет именно связей,

Если их нет, то как мог возникнуть вопрос о различимости? Различать то нечего, раз нет.
Ну подурачьтесь, если хочется))) Неразличимы ОТНОШЕНИЯ. На уровне МД и СУБД. Разумеется связей, как и сущностей, нет. Кодд вводил понятия в ранних отчетах "отношение типа сущности" и "отношение типа связи", но они остались только в мыслях, из-за того, что с алгеброй не срослось:)

vadiminfoБредятинаНеразличимы ОТНОШЕНИЯ.
Нельзя отличить одно ОТНОШЕНИЕ от другого что ли? С каких это пор? Там все таки было о неразличимости отношения в плане он тип СУЩНОСТИ или тип СВЯЗИ (с. окраска), но тем самым допускалось, что оно может быть как тем как так и другим.
Именно так. И это все (в том числе и автор РМД) изначально понимали, как серьезную проблему. Бороться с которой можно только на уровне приложений. Или с использованием другой модели и маппинга, как делает ViPRos. Это, наряду с бесполезностью алгебры для подавляющего большинства систем (я приводил количественные характеристики бесполезности, с одной стороны, и пример, когда алгебра была бы полезна - с другой), и сделало РМД основой для коммерческого, но не технического успеха.
vadiminfoБредятинаКодд вводил понятия в ранних отчетах "отношение типа сущности" и "отношение типа связи", но они остались только в мыслях, из-за того, что с алгеброй не срослось:)
Это семантическая окраска. Осталось ниболее оптимальное.
Нет, не нужно делать таких вольных интерпретаций. Остались просто отношения, потому что с алгеброй (она сначала появилась, а не РМД, как думает _мод) не срослось.
vadiminfoНикакая выразительность модели не может компенсировать недостатки манипулирования:
Это философское высказывание абсолютно симметрично высказыванию: никакая вычислительная мощность не может компенсировать отсутствие смысла:)
vadiminfo скорее всего, БД придумывают не для того, чтобы просто занять персонал их набором.
Однозначно! И SQL ничего не принес нового и полезного для БД в этом плане.

ViPRosну мы же это обсуждали, что все связи навигационные, но некоторые имеют допольнительную нагрузку
ОБЪЕКТ - внутренности типа, который ни на что не ссылается(независим) или есть тип где роль этого типа - Объект для заданной пути в графа классов
Я, когда чего-то не понимаю, считаю, что дело во мне, а не в объекте или субъекте объяснения:) Так что буду дальше спрашивать. Давайте на нашем простом примере.
1) Фамилия в ТИПЕ Сотрудник - это что? Какой термин используете - только точно:) Свойство, атрибут, характеристика, как-то еще?
2) Приведите пример ОБЪЕКТА внутри ТИПА Сотрудник.
3) Почему дополнительная нагрузка нужна только в одном направлении?
4) И, все-таки, поясните конкретно, что такое СВЯЗЬ:

Вариант 1. Она между ТИПАМИ Сотрудник и Цех, и ее компонентой является ОТНОШЕНИЕ Работает? То есть, всего в нашем примере ОДНА связь.
Вариант 2. Она между ТИПОМ Сотрудник и ОТНОШЕНИЕМ Работает (а другая связь между ТИПОМ Цех и ОТНОШЕНИЕМ Работает? То есть, всего в нашем примере ДВЕ связи.
Вариант 3. Она по варианту 2, но только в одном направлении. То есть, всего в нашем примере ЧЕТЫРЕ связи.

_модViPRosну не устраивает хотя бы тем, что Сотрудник может работать во многих местах
Обычное дело: свойство м.б. списком. В чем проблема ?
Другой объект - это не свойство объекта. Это Вам так хотелось бы, возможно, в Вашем перспективном ЯП, который приведет к отказу от БД:) И так есть в бесперспективной РМД в виде FK/PK.

ViPRos_мод,
свойство списком не может быть, может быть список свойств :)
Такой тип, как набор строк (есть же тип строка), вполне может быть полезен в частных случаях. Это стандартный тип для БД (_мод, вероятно, думает, что только для ЯП:)). Только чего в Вашем случае - свойства, атрибута чего-то еще - какой термин Вы используете?

ViPRos_мод,
ну значит разное понимание "свойства" у нас :)
Обратите внимание с чего началась эта ветвь. Набор строк - это один частный случай типа.
А началось с набора "ссылок" (внешних ключей, другими словами), то есть, при обсуждении концепции СВЯЗИ. Можете посмотреть как это делается "институтами и группами". Ну, например, друпал посмотрите:) То есть, как это маппируется на РМД (точнее, на EAV).