Роман Дынник Вы отвечайте по существу вопроса, а не разводите флейм. Вы помогли автору, ответили на его вопрос? Вместо ответа на вопрос в рамках конкретной задачи Вы пытетесь развести базар. И так во всех топиках форма.
Неправда. Я, конечно, помог. А вот Вы встряли, как всегда, невпопад. А когда поняли, что нечего сказать по существу ни одного обсуждаемого вопроса, скатились на личности. Это нормально, я привык уже:)
Роман ДынникДискутировать мне с Вами не интересно, для дискуссии нужен общий язык, фундамент. У Вас он ограничивается моделированием данных. Для меня этого не достаточно.
И для меня. Возьмите любой свой проект. Вот хотя бы расчет ЗП для 50-ти предприятий. У Вас там по архитектуре данных был вопрос. Но все остальное Вы же делали, как предписано "институтами и группами", правильно? Вот и поясните как Вы:
1) проектировали БП;
2) проектировали БД (другой человек);
3) маппировали БП на БД.
Роман Дынник На мой взгляд, пусть даже он будет по-вашему субъективный, в своих сообщениях Вы не "четко показываете на ошибки и противоречия", а создаете их, устраиваете "фетиш" из моделирования данных, хранилища, тем самым создавая хрупкую архитектуру.

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

А мне не нужно об этом думать - я об этом никогда не забываю. Вы еще про рисование аналогичный афоризм приведите:)
Роман Дынникp.s.
А банить мне Вас не за что пока, Вы же матом не ругаетесь, к экстремизму не призываете.
Так что не обольщайтесь :)
Вот и чудненько:) Значит на этом форуме разрешается обсуждать вопросы по существу.

guest_20040621> оптимальную по заданному критерию

Вот я и спрашиваю: если у вас параметрическая оптимизация, зачем вам дополнительные абстракции? В чем фишка?
Я много раз спрашивал ViPRos про многочисленные, избыточные на мой взгляд, концепции в его модели в отдельной специальной теме. Можно ее вспомнить. Может быть ViPRos даст ссылку.

ViPRosБредятинапропущено...

Я много раз спрашивал ViPRos про многочисленные, избыточные на мой взгляд, концепции в его модели в отдельной специальной теме. Можно ее вспомнить. Может быть ViPRos даст ссылку.
так называемая "избыточность" следствие того, что ВИПРОС работает ТОЛЬКО с метаданными
т.е. - нету в прикладной проге программного класса "Оборудование" и унаследованного от него класса "Оборудование в эксплуатации", потому, что бы применить операторы is, as, ... вся ООП описано структурно, через типы связей отношения, роли типов в отношении, классификаторы отношений, контексты интерпретации

Вот отношение РаботаетВ((Работает)Сотрудник, (В)Цех)
если читать по русски, то все понятно, что {Сотрудник} Работает<> В {Цех}
т.е. - глагол в предложении Работает - имя отношения, Кто{Сотрудник} работает и Где{Цех} работает в именах атрибутов отношения
теперь берет китаец и переименовывет всю эту фигню
и вся наша так называемая семантика летит в тартарары, интерпретатору пипец наступает
но если типизируем роль типа (атрибута) и ссылку на этот тип, то всегда можем интерпретировать это отношение (при том, что роли, контексты и т.д. нередактируемы китайцами :))

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

Сотрудник <--Работает в/В котором работает-- Цех

Здесь не показаны технические (неизменяемые) метаданные - надеюсь уже понятно что такое содержательные и технические метаданные.
Так вот, у Вас не симметрично выглядит - где связь со стороны Цеха? У Вас это выглядит, как в РМД:) Любая связь бинарная (здесь не одна тема была, в которых я объяснял заблуждение Дейта относительно n-арных связей) и имеет семантику в обоих направлениях. Какая еще навигационная ссылка??? Вы имеет ввиду ДРУГУЮ связь между типами сущностей, наверное. Например,

Сотрудник <--Хотел бы работать/В котором хотел бы работать-- Цех

Мне кажется, Вам как-то конкретнее нужно показать преимущество множества концепций (как правильно заметил vadiminfo - серьезно усложняющих реализацию манипулирования).
Мы сейчас вернемся к теме, наверное - каким-то "циклическим связям":)

Спутал темы - здесь у нас "Инструмент для моделирования логики процесса...":)
А вышли опять на связи.

ViPRos Бредятина,
приведи пример содержательных метаданных
Мы же уже приводили пример:
Сотрудник (содержательные метаданные - могут изменяться и китайцами и русскими);
Т1 (технические метаданные - не изменяются).
ViPRos у меня там две связи
Сотрудник_Работает{Сторудник} и
Цех_Работает{Цех}
Это содержательные связи
Предлагаю для простоты рассмотреть одну связь. Это, как я понимаю
Сотрудник_Работает{Сотрудник}
Не понимаю что с чем здесь связано? В традиционной терминологии - это связь между какими типами сущностей?
Сдается мне, что это вовсе не связь.
Особенно, когда выяснилось, что "связей" даже не две (вместо одной), а целых четыре:)

В РМД есть один основной элемент структуры - отношение. В КОМД два - объект и связь между объектами. В Вашей модели, вероятно, в отличие от РМД, отношения имеют строгие типы. Например, отношение типа связи?

ViPRos содержательные связи должны быть типизированы {Наследование, Агрегация, ...}
обратные связи всегда {Навигационные}
Странная терминология: содержательные и обратные? Что обратные - бессодержательные?:) Для чего нужна эта асимметрия?
ViPRos В Работает оба типа имеют Роли - Кто и Где
ВИПРОС работае с этими ролями, а все эти Сотрудники и Цеха - внешний антураж
Итак, Сотрудник и Цех - это ТИПЫ.
Работает - это ОТНОШЕНИЕ.
Вы уверены, что Сотрудник и Цех - это не ОТНОШЕНИЯ, а Работает - это не ТИП?

ViPRos В ВИПРОС типы, в РМД отношения
Итак, ТИПЫ - это то же самое, что и отношения в РМД.
ViPRos в ВИПРОС много разных связей, в РМД никаких
Много разных СВЯЗЕЙ между ТИПАМИ? Я все время вынужден что-то уточнять:)
Переспрашивать...
ViPRos запись X_Y{Z}
означает X определен в Y как Z - это связь с каким то типом{Наследование, Переопределение, Агрегация,...}
Y_X{Z} тож связь с типом {Навигация}
вот так вот устроено все
Для нашего простого примера:

Сотрудник определен в Работает как Сотрудник

Это как я понимаю ПРЯМАЯ связь. Уточните чего с чем. Похоже ТИПА сотрудник с ТИПОМ (который Вы называете ОТНОШЕНИЕМ) Работает. То есть, если проводить аналогию с РМД, то это, как раз, обратная связь (если бы она поддерживалась в РМД) отношения Сотрудник (точнее Emp, так как содержательные метаданные не поддерживаются) с отношением Работает (точнее EmpDep), созданным для связывания по общим полям отношений Сотрудник и Цех.

Далее у Вас ошибка, похоже (Y_X{Z} ???). Правильно Y{Z}_X, что вероятно читается как-то так:

Работает содержит Сотрудник из Сотрудник.

Это соответствовало бы описанию внешнего ключа, если проводить аналогию с РМД.

Другими словами, Вы сделали две вещи, которые поначалу хотел бы сделать и Кодд:
1) для всех "связей" создаете отдельное отношение (как рекомендует Дейт - независимо от мощности связи);
2) в этом отношении у Вас всегда два "атрибута" (или какой термин используется в Вашей модели?), соответствующие двум внешним ключам в РМД.

Пожалуйста, поясните более детально, не отклоняясь от примера.
Тем более, что если "вот так вот устроено все (!)", то ничего, кроме ТИПОВ и ОТНОШЕНИЙ (особые ТИПЫ для организации связей) в общем-то и нет?:)