U-geneА что за вопросы по существу? Можно их прямо так "по существу" и озвучить? На всякий случай - возможно, на некоторые из них я здесь уже ответил.
Все озвучено, в том числе и "здесь". Ни на один мой вопрос Вы не ответили:)

U-geneБредятина - меня постоянно зарубает на мыли, что Вы - ЧАЛ :) Даже не знаю, радоваться этому, или печалится. Только честно.
"Только честно" - это оригинально:)
Здесь все прекрасно знают кто я. Только ЧАЛов здесь немало, все-таки, было. И даже буквально вот это сообщение неизвестно кто написал. А как только я официально зарегистрировался, меня тут же заблокировали, и именно потому, что друзья модераторов не могут ответить ни на один вопрос. А считаются профессионалами:)

ViPRosЧто ты прицепился что нет связей?

Потому что это намного важнее, чем Вы можете себе представить.
Вот сказали бы Вы, что связей принципиально нет. Вообще. Есть только объекты. Поэтому, мол, и у меня в модели связей нет.
И закончили бы на этом этот "спор":)
ViPRosЕсли у объекта есть характеристики(свойства), которые являются идентификаторами других объектов - разве не связь это?

Нет, не связь. Это характеристики объекта. Причем совершенно недопустимого типа. Я Вам сто раз уже объяснял, что ни свой собственный иденитификатор, ни, тем более, идентификаторы экземпляров других объектов, не являются значениями характеристик экземпляра объекта. И на уровне метаданных - идентификаторы не являются характеристиками объектов. То что Вы делаете - это повтор вынужденной меры Кодда, необходимой для реализации алгебры.
ViPRosтут есть одна фигня
есть какие то сильные и слабые связи
есть какой то разрыв тут
вот связь Работник-Цех звучит сильно :)
а, Товар - Единица измерения ну слабовато как то:( маловато будет для связи
связь с примитивными типами как то надо отделить
Здесь Вы говорите, примерно, следующее: "связь" значения характеристики объекта с идентификатором экземпляра объекта (например, значения Фамилии "Петров" с идентификатором Человека 100134) - это "слабая связь", и мы не выделяем Фамилию в ОТДЕЛЬНЫЙ ОБЪЕКТ.
Ну, я не знаю, есть ли смысл, теоретический, в такой интерпретации. Думаю только познавательный:)

guest_20040621Точняк. Спасибо за подсказку. В архивах ковыряться лень, а стиль очень уж знаком. Разница в том, что теперь он заходит с другой стороны: за пару лет, видимо, Дейта таки прочел и несет ахинею со ссылкой на вольную интерпретацию Дейта, к Дейту, впрочем, никакого отношения не имеющую.

Нет, совсем не так у Дейта про связи написано, зачем же обманывать? Я Дейта читаю всегда, и понимаю лучше всех:) В любой момент времени:)
guest_20040621Как тогда было загадкой, что он здесь делает, так и сейчас. Может, конечно, ему платят за этот бред (в чем я сомневаюсь), но скорее всего, просто работы нет и заняться нечем.
Ну, наконец-то, признался, что работы нет. Но это же не повод, чтобы писать сообщения по теме, о которой нет ни малейшего понимания:)

ViPRosот меня просто так не уйдешь

А от меня - тем более:)
ViPRosвся навигация у меня построена имеено на этих связях, а ты говоришь что их нет

Пока, действительно, нет. Но вот-вот появятся:)
Дейт приводит цитату из руководства по ER-моделированию:

"Обычно на первом этапе в процессе разработки концептуальной схемы принято представлять некоторые связи в виде атрибутов [то есть, практически, в виде внешних ключей]. Затем эти атрибуты преобразуются в связи по мере дальнейшей разработки проекта и углубления понимания его особенностей."

Далее Дейт комментирует:

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

И далее идет ссылка на уже упоминавшееся объектно-ролевое моделирование...
ViPRosу меня "внутри" есть четкое понятие Relation, которое по этим связывающим идентификаторам строит динамические выборки

Ни о чем не говорит. В Cache тоже есть такое "четкое понятие":) Это вовсе не означает, что связи между объектами поддерживаются.
ViPRosи воще у меня Свойства отделены от Ссылочных свойств

Уже теплее:) Только, учитывая, что никаких свойств просто не может быть в базах данных (свойства, как мы помним, не могут быть измерены, и не имеют никаких значений), и восстанавливая некую логику "движения от объектов", можно сказать:
"и воще у меня связи объекта с другими объектами отделены от характеристик объекта".
Очень хорошо:)
ViPRosкак раз Ссылочные свойства и есть навигационные связи
Прилагательное "навигационные" совершенно не уместно. Так что это предложение должно звучать так:
"как раз связи и есть связи":)

БредятинаНи о чем не говорит. В Cache тоже есть такое "четкое понятие":) Это вовсе не означает, что связи между объектами поддерживаются.

Посмотрите как ужасно выглядит описание "связи" (пример из одной из тем в разделе Cache):

/// Контракт
Class tmp.Contract Extends %Persistent
{

/// Номер договора
Property dgNum As %String;

/// Начало договора
Property dgBeg As %Date;

/// Окончание договора
Property dgEnd As %Date;

Relationship ClientToContract As tmp.ClientToContract [ Cardinality = many, Inverse = Contract ];

}

/// Клиент
Class tmp.Client Extends %Persistent
{

/// Имя клиента
Property Name As %String;

Relationship ClientToContract As tmp.ClientToContract [ Cardinality = many, Inverse = Client ];

}

/// Связь клиентов с контрактами
Class tmp.ClientToContract Extends %Persistent
{

Relationship Client As tmp.Client [ Cardinality = one, Inverse = ClientToContract ];

Index ClientIndex On Client;

Relationship Contract As tmp.Contract [ Cardinality = one, Inverse = ClientToContract ];

Index ContractIndex On Contract;

}


Здесь мы видим два фундаментальных недостатка Cache (как и любой другой СУБД, кроме тех, в которых реализована классическая объектная модель данных):
1) метаданные приходится хранить в приложении; это прошлый век, мягко говоря:)
2) отсутствие нормальной поддержки связей; это тоже прошлый век:)

Если бы связи поддерживались, то этот пример выглядел бы, примерно, так (первый недостаток сохраняется):

Class tmp.Contract Extends %Persistent
{
Property dgNum As %String;
Property dgBeg As %Date;
Property dgEnd As %Date;
}

Class tmp.Client Extends %Persistent
{
Property Name As %String;
}
Relationship Client -> Contract

ViPRosПолная задница это, а не описание связи.
Я метаданные в приложении не храню, для этого есть репозитарий метаданных.

По отношению к РСУБД, которую Вы неизбежно используете - это приложение:) В котором Вы надстраиваете над реляционной еще одну модель. И делаете мэппинг. Это даже не прошлый век, а позапрошлый:)
ViPRosВот как раз так у меня и делается, только без главного твоего недостатка.

Это что еще за "главный мой недостаток"? Слишком большие знания в области баз данных?:)
ViPRosТем более, что у тебя Характер связи не описан, В Кашэ хоть и многословно, но точно описан.

Ради бога, не смешите меня:) Я же написал ПРИБЛИЗИТЕЛЬНО, просто чтобы показать, что связь не нужно описывать в трех местах, так как из этого описания со всей очевидностью следует, что это вовсе не связь, а творческие поиски инженеров IS:)
В классической объектной модели данных есть ясное определение связи, в соответсвие с которым связь полностью описывается. Вы просто опять про это забыли. А я вот никогда не забываю о том, что Вы пишите:)
ViPRosИнтересно что делает Каше если связь не Persistent, наверное то же самое что и я (АДО.НЕТ)

Серьезное непонимание концепции связи, а так же того, что является результатом запроса к базе данных. "Связь не Persistent" - это принципиально не связь.
ViPRosДелается у меня так.
Считывается метаданные Макротипа, создаются образующие типы и связи между типами.
Связь - описательня конструкция, используются так -
Объект[] связанныеОбъекты = Объект.ПолучитьПоСвязи(Связи)
ДляКаждого(var объект Из Объект)
{
ДелайЧтоНибудь(объект);
}
Интерес представляют в Вашей неизвестной модели только связи между Макротипами. Так как связь это такая же структурная концепция, как и Макротип (если, конечно, связи у Вас поддерживаются, так как опять пошел откат к плохо формализованным многочисленным концепциям, которые только отвлекают от сути - Вам нужно почитать про "информационный принцип Кодда", только не ради сути этого принципа, так как она глубоко ошибочна, а ради самой идеи), а вовсе не описательная конструкция.

ViPRosЯ просто немного доработал Адо.Нет под себя и все.
И подвигло к этому Именно разделение понятий Связь и Ограничение внешнего ключа. То, чего не хватает в МССКЛ.

Это хорошо, но вынужденная мера. От безысходности:)
ViPRos но потом МС пошла за всеми гибернейтами и т.д. и забила на удачное начало.
И с их подачи наши прогеры тоже забили на все это и генерят и правят всякие муделив коде по кругу.
Конечно. Для этого и придуманы РСУБД, чтобы генерить и править по кругу:)

ViPRosнабрал "информационный принцип Кодда" и попал на статью какогото Кузнецова.
Непонятно кого он там критикует, Дейта или Кодда и по какому праву

Не какого-то, а самого Сергей Кузнецова, я полагаю:)
ViPRosно
вес словесный понос "объект тип отношение свойство характеристика связь ассосиация ключ внешний ключ классификация типов (ядерные,...), каталоги типов... " что мы тут мусолим, там присутствует
Значит вышеуказанные товарищи тоже плавают

Плавают, конечно. Но идея-то понятна. Еще раз прочитайте.
ViPRosРМД удачная модель для смешивания всего и вся

Крайне не удачная. Одна из самых неудачных.
[quot ViPRos]
Над ней надо ввести свои Правила смещивания (для определенной предметной области)
от того что А отношение, Б отношение и АБ отношение не холодно и не жарко
а вот построенная на них семантическая сеть (с указанием способа манипуляции - :):) )
уже что то, за это можно и бабки получить
[quot ViPRos]
А вот над классической объектной моделью не нужно ничего надстраивать и мэппировать для получения того же самого результата:)
ViPRosвощем я тебя понял - для тебя связь есть такое же отношение как и сами связанные объекты

Нет, не понял. Это для Дейта, а не для меня. Между объектом и связью нет ничего общего.
ViPRosпросто твои объекты могут имет вертикальный набор значений свойств(характеристик)

Не мои. И "горизонтальный". И могут и не иметь (в отличие от РМД, в которой отношение не может не иметь атрибутов, точнее может, но в таком отношении будет ровно один кортеж).
ViPRosи объекты твои - ядерные сущности кодда - "сущность которая существует"

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

ViPRosСчас они пишут проект Осло с языком М.
Может это что то дасть.

Ничего не даст. Прежде чем писать нужно подумать хоть немного:)

мастер Йодапара комплиментарная диалог этот ведет
"принцип Кодда информационныЙ" (в единственном числе) набирает один по совету другого
...
и оба возмущены
Нет. Это принципиально не точная цитата из известной статьи Кодда. Будьте внимательнее, пожалуйста:)
Хотя Ваша мысль о связях мне понравилась.

ViPRosа кто этот Кузнецов?
http://sp.cmc.msu.ru/staff/ksd.html

Штудировать, конечно, не обязательно. Просто быть в курсе:)