Как известно, у каждого человека в голове есть свои тараканы. Вот, например, вчера я ехал в автобусе с мужиком, который неожиданно наехал на ни в чем не повинную девушку с фразой "фигли ты лыбишся, у меня трое ртов, довели страну". Какая тут связь - никто не понял, но он буквально бился в истерике. Мужику лет 40 на вид средний класс, инженер, аккуратная светлая одежда, часы, портфель.... Ни в жисть не подумаешь, что такое может быть.

Да что там вчера!... Пройтись здесь по соседним топикам, так там эти тараканы тоже усов понавысовывали. У кого незаметных, у кого то аж за версту видно и уже не справиться с ними.

Воооооот..... К чему я это всё..... Есть и у меня пара таких тараканов в голове. Я, кстати, про них давеча упоминал, обещался как вырастут - на публику вывести. Вывожу. Тут они родные, смотрите. Только чур сразу не пинать - критики, уличенные в неознакомлении, будут жестонко игнорироваться.

Я не говорю про связи между самими объектами. Я говорю про связь(соотвествие, соотношение) между моделируемыми объектами(с одной стороны) и переменными отношений хранящими данные про эти объекты(с другой стороны). И наасчет нормализации это верно в любом случае. Даже когда схема РБД будет совсен ненормализована то и в этом каждому объекту будет соответсвовоать множество значений отношений. Здесь просто надо понимать, что одно знанчние - это тоже множество, и что это значение может быть подмножеством другого значнеия, описываещего предметную область в целом. Но то же самое верно и при любой степени нормализации.

Я не собираюсь впадать в дискусии по поводу объектов, сущностей, связей и т.п субъективных вещей. Как показывает опыт, в спорах по этому поводу мало смысла. По большому счету, все что я делаю в НРМ, так это...
1)...предлагаю достаточно простую систему типов.(С одной стороны, она ИМХО достаточно выразительная и сравнима в этом с традиционными ОО-языками. С другой стороны она сохраняет черты систем базирующихся на РМД.)
2) ...предлагаю способ ее реализации

Причем (специально для вас ув.АЛ!) говоря про РМД, я говорю про рел модель данных , а не предметной области!. Другими словами я воспринимаю РМД как модель некого ассоциативного устройства хранения данных, как модель памяти, если угодно. Ни о какой предметной области на данном этапе речи ни идет. Но тот факт, что мы помещаем данные в эту память, означает, что мы должны так или иначе принять законы, по которым эта память работает. А тот факт, что мы манипулируем этими данными, означает что мы должны принять операции РМД. Вопрос в том, как все это принимать.

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

Сейчас с РСУБД дела обстоят похожим образом. Есть система хранения данных, где они организованы в виде, задаваемом РМД, и эта система используем напрямую. Однако (и я это показываю) на ее основе можно построить систему с еще более высоким "уровнем абстракции", при этом сохранив возможности базовой системы хранения. Насколько этот уровень абстракции высок? Позволит ли он адекватно отобразить все ваши "объекты", "сущности", "связи" и т.п? Я не знаю - это Вам решать. Поэтому я прошу - воспринимайте это как описание системы (этакий теоретический user manual) и решайте, насколько она соответсвует Вашим конкретным задачам. При этом я прошу учесть, что речь идет о соотвествии в таких труднообъяснимых вещах как выразительность,
адекватность и т.п. Ни о каких библиотеках, "настройках, типа ejb, hibernate, jdo итп", быстродействиях, протоколах и платформах речи пока не идет.

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

В НРМ есть две части - в первой я предлагаю некий подход к описанию данных (как это выглядит, когда мы это будем использовать), во второй я предлагаю способ реализации этого подхода.
В первой части вообще нет таблиц и пользователю не нужно даже этим словом заморачиваться.
Таблицы РСУБД появляются во второй части, но они являются частью реализации. Пользователь R*O-системы не думает о них (точно также как программист С++ не думает об детальной организации данных в ОЗУ).Если Вы про эти таблицы, то в них один и тож же OID может присутсвовать во многих кортежах многих разных таблиц, причем это натуральные таблицы со многими аргументами. Подразумевается, что R*O-система собирает эти кортежи и представляет их для пользователя в виде сложного объекта. Например, объект отгрузка будет собираться из кортежа одной таблицы, содержащего заголовок, и многих кортежей другой таблицы, содержащих данные об отгружаемом товаре... конечно если компоненты этого объектного типа реализованы как хранимые, а они могут быть реализован и по другому, и в этом случае всё будет еще интересней (один кортеж может хранится а другой вычисляться или как то еще).

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

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

...Кстати, классов в НРМ тоже нет (это даже явно указывается) Есть типы (объектные и значимые), а объектным типам соответсвует набор глобальных переменных. Здесь можно провести аналогию с моделью ODMG, где тоже нет классов, а есть есть типы (объектные и литеральные) и у объектных типов могут быть экстенты (множество ссылок на объекты данного класса). Однако глобальные переменные НРМ являются реляционными (R-переменные - т.е. переменные отношений) и, в отличии от экстентов, содержат не только OID(т.е. ссылки) но и значения компонентов объектов. Кроме того, для каждого без исключения объектного типа может существовать много разных R-переменных (хотя бы одна). Наконец экстенты - это некое необязательное програмное образование, а R-переменные они ...ммм...достаточно обоснованны.

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

На самом деле там все это написано. Если что то не понятно, попытайтесь смотреть примеры и спрашивайте.

2 vadiminfo

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

2 ModelR

Вы напрасно пытаетесь сравнить R-переменные с таблицыми SQL3. Если уж вам так приспичило сравнивать , то это не таблица а, скорее, вид причем то, как этот вид вычисляется, определяется реализацией компонентов о-типа. Например, если в процессе наследования о-типа реализация компонента была изменена, то значение R-переменной будет вычислятся по новому. Однако весь ранее определнный функционал, который так или иначе манипулировал с этой R-переменной, изменений не потребует(что подразумевает позднее связывание). ИМХО это средствами SQL3 никак не сделать. Посмотрите еще раз пример в первой части от начала до конца. Там есть все - от описания типов, до наследования с переопрелделением компонентов. Побробуйте сделайте то же на SQL3 - это было бы очень интересно, но мне кажется у Вас это не получится (это будет как преобразование С++ программы на язык С).

Насчет CREATE CLASS? Есть какая то устоявшаяся терминология, а поскольку пользователь, объявив и описав объектный тип, сразу же может манипулирвать его R-переменными, то для него это выглядит в точности как класс. Поэтому я оставил CREATE CLASS.

авторДалее, "запихнуть в одну таблицу" - нет, ORACLE nested table физически размещается в отдельной таблице Физически то да, но нафига это логически впихивать в одну таблицу? Нафига это таблица вообще нужна? Можно без нее - ИМХО даже нужно.

авторПоскольку DML описан очень скупо, то реально сравнить тяжело. Я абсолютно согласен. DML в НРМ гораздо менне сложен ,чем DML в SQL3. Однако я готов спорить, что в выразительных способностях НРМ мощнее SQL3.

Насколько я понял, DDL вам более-менее понятен. А DML ИМХО действительно прост:
*Cоздать/изменить/уничтожить класс,
*Cоздать объект, уничтожить объект/множество объектов
*Изменить объект/множество объектов, что подрузамевает
--вызов методов(в том числе для множества объектов)
--прямое использование INSERT|UDEATE|DELETE(использую термины SQL) применительно к компонентам-атрибутам объектов
*Групповой доступ - фактически тот же SELECT по к R-переменным + операции выборки объектов и раскрытия ссылок.

Наверное все. Опять же - в примерах практически все это есть.

авторРечь шла о том, что соответствие объекта кортежу может быть оправдана тоже.

Я не вижу проблемы. Может здесь просто термнологическая путаница? ИМХО кортеж так или иначе подразумевает значение отношение, частью которого он является. Мне же, как я сказал, попытки привязать данные к таблицам кажутся определнно избыточными. ЧТо яздесь подразумеваю под избыточностью. Напрмер, как это сделано в ORACLE. Там определяешь тип, а потом для типа создаешь таблицу, строки котрой являются экземплярами этого типа. Я уж не говорю про то, что подход "строка = объект" является ущербным, но, позвольте, а что, описав тип, мы разве уже не подразумеваем, что в системе будет сущекствовать множество экземпляров этого типа? Нафига нам это множество еще раз явно оформлять?

И, конечно же, структура объектов может быть достаточно проста, что бы в точности соответсвовать структуре кортежей. Кстати, в этом случае, классу будет соответсвовать всего одна R-переменная (в НРМ, в примере это класс Article). То есть этот простой частный случай является фактически полноой калькой кортежей, которые соответсвуют объектам, и таблицам, служащим для их хранения. Просто мы явно таблицу не определяем, пользуемся R-переменной данного объекного типа, и, что немаловажно, ИМХО называем вещи своими именами (объект-объектом). Но это только частный, самый простой случай.

2 funikovyuri

авторТ.е. какие черты РМД вы считаете полезными и в НРМ?

Если рассматривать РМД как модель данных (а не предметной области) то наверное все. Теперь бы определимтся что такое черты РМД:) В любом случае, ничего такого в РМД, что было бы вредным, я не нахожу.


автортак как по-сути такой транслятор можно сделать и вокруг другой модели данных
Транслятор можно сделать вообще вокруг всего, что имеет язык управление. РМД - она формальная и работает с множествами. Соответсвенно, к некоторым аспектам этой самой трансляции можно подойти также формально, и показать, что операцию(или последовательность операций) определённую для одного объекта, можно преобразовать в операцию (последовательность операций) выполняемую сразу для множества объектов, чему собственно первая половина второй части и посвящена.

И потом. Какая-такая другая модель? Я,конечно ,имею в виде формальную модель?

авторУ Оракло первый - строковый объект, второй - объекты столбцов.

Не понял. Объекты столбцов подразумевают, что для их хранения используется своя таблица, соотвествующая типу этих объектов? то есть реально там ссылка?

авторИногда, под моделью данных понимают именно модель предметной области.

И что? Что эта фраза значит в контексте данного обсуждения?

vadiminfo

U-geneНапрмер, как это сделано в ORACLE. Там определяешь тип, а потом для типа создаешь таблицу, строки котрой являются экземплярами этого типа. Я уж не говорю про то, что подход "строка = объект" является ущербным, но, позвольте, а что, описав тип, мы разве уже не подразумеваем, что в системе будет сущекствовать множество экземпляров этого типа? Нафига нам это множество еще раз явно оформлять?


Не оформлять, а организовать (реализовать) в структуре БД.

А что эта фраза занчит? Хорошо, я буду использовать другое слово: Нафига нам это множество еще раз явно организовать?

Уважаемый vadiminfo . Я намекаю, что мыслью по древу можно растекаться очень далеко и многословно. Однако мне не хотелось бы делать это здесь - в данном топике. Все же было бы очень неплохо если бы Вы таки прочитали и попытались бы понять то, что я предлагаю. Потому как Ваши топики кажутся мне несколько рефлексивными и не совсем относящимися к предложенной теме.

Я еще раз гворю - забудьте про эти явно определяемые таблицы. Попытайтесь понять, что для РМД в общем то пофигу, как определены переменные отношений - явно или неявно.

funikovyuri
Если рассматривать РМД как модель данных (а не предметной области) то наверное все.

Т.е. не как основу для проектирования?
Я не знаю, что Вы здесь имеете в виде под словом "проектирование". В этом топике в пятом посте я объясняю, что я имею в виде говоря о модели данных (а не предметной области).

Уважаемый vadiminfo
Я больше Вам отвечать не буду. Вы кажетесь мне большим мастером раздувать флейм, не потрудившись даже ознакомится с предложенной работой. Если Вы не пытаетесь понять как это работает, нафига Вы это обсуждаете?

Я уверен в том что НРМ является достаточно читабельным и понятным документом(конечно, если поднапрячься). Я делал его около двух лет и это уже третья крупная редакция(не говоря о постоянных мелких правках). Все это рецензировалось известным спецом в области БД (ИМХО ведущим в России) и, судя по его отзыву, он считает это полезным подходом и не может припомнить аналоги. Я и сам абсолютно уверен в простоте(по сравнению с тем же SQL3) и работоспособности предлагаемого подхода и, поэтому, меня просто убивают фразы типа... vadiminfo...хорошее дело, как манипулировать не зная имя таблы?....Ведь у Вас ее по любому нет?
Думаю, Вы слишком расточительны Это все описано - R-переменными и их именование являются буквально основными вопросами НРМ.

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

2 vadiminfo автор...я само это и не обсуждаю, а тока некоторые тезисы, упомянутые в топике, представляющие для меня интерес...

Эти некоторые тезисы(правильные они или неправильные и идиотские) имеют смысл только в контексте предложенной статьи. Обсуждение их без ее прочтения ни имеет никакого смысла. Что я до Вас попытался в очередной раз донести.

2 Андрей Леонидович

Андрей ЛеонидовичТо, что связи на объектном уровне представляются с помощью ключей (как в РМД) - это настораживает

В НРМ ключи декларируются как ограничение целостности (этим, кстати, НРМ отличается от модели ODMG, где ключи декларируются исключительно как срество ассоциативного доступа). И конечно же там есть внешние ключи, и их можно импользовать для обозначения связей. Однако НРМ не в коем случае не связывает внешние ключи и связи напрямую. То есть внешний ключ - это просто внешний ключ. Как вы будете использовать этот механизм, какой смысл Вы в него вложите - я не знаю.

Однако заметьте, что НРМ позволяет определять и использовать самые натуральные ссылки . Ссылки - это тоже механизм. Но ИМХО они гораздо ближе вашим любимым:) "связям". К тому же они позволяют организовывать групповой доступ к данным как по ссылке, так и навстречу ей.

2 vadiminfo
Тьфу на Вас :). Когда же Вы перестанете мусорить здесь прописными истинами? Я же Вас об этом просил четыре раза! Это же такое занудство..

2 vadiminfo
Посколку статью Вы не читали, я даже не буду спрашивать, как хорошо Вас понимаете то, что говорите.

2 ModelR
Ну раз приспичило, значит интересно :)
Я буду цитировать исходный текст - ИМХО там все ответы есть.

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

Таким образом, спецификация объектного типа представляет собой набор спецификаций значимых компонентов. Совокупность значений компонентов объекта определяет состояние объекта. Любой компонент может быть реализован либо как хранящий значение, либо как вычисляющий его, однако важно понимать, что в спецификации компонента не определяется, является ли это значение хранимым или вычисляемым.
Замечание. Конечно, спецификация в определённом смысле определяет реализацию. Например, наличие параметров у метода позволяет предположить, что значение, возвращаемое методом, должно быть вычисляемым. Однако эта зависимость все же не очевидна. Вполне возможна такая реализация, что значение, возвращаемое методом, не требует вычислений (например, при наследовании одна из реализаций метода использует параметры, а другая может их не использовать). Более того, это значение может быть реализовано вообще как хранимое. С другой стороны, реализации атрибутов, не имеющих параметров, может содержать вычисляющие выражения.
....
Все компоненты допускают операцию чтения. Компоненты, не имеющие параметров (т.е. атрибуты), допускают также операцию присваивания. Естественно, что значение, присваиваемое атрибуту, должно иметь тип этого компонента. Для атрибутов типов отношений возможны обычные для РСУБД операции над значениями отношений, том числе операции, изменяющие число кортежей (INSERT, DELETE) и состояние существующих кортежей (UPDATE).
Замечание. Мы осознаем трудности, которые могут возникнуть при реализации операций, явно изменяющих значение атрибута, в случае, когда эти атрибуты реализованы как вычисляемые. Однако мы предполагаем, что в реальных системах такие трудности можно преодолеть (например, с помощью триггеров).


Еще вопрос. 2 ModelR U-geneНапример, если в процессе наследования о-типа реализация компонента была изменена, то значение R-переменной будет вычислятся по новому. Однако весь ранее определнный функционал, который так или иначе манипулировал с этой R-переменной, изменений не потребует(что подразумевает позднее связывание). Правила наследования очень важны. Например, базовый тип определяет компоненту как хранимую, а порожденный - как вычисляемую, что тогда? А если обратно?

Ответ. НРМ(стр14-15)....Как указывалось ранее, в спецификации объектного типа не определяется, являются ли значения его компонентов хранимыми или вычисляемыми. Компонент, реализованный в родительском типе как хранимый, может быть переопределен в классе-наследнике как вычисляемый (и наоборот). Соответственно, когда речь идет о полиморфном наследуемом объектном типе, любая из R-переменных его компонентов может содержать одновременно как хранимые, так и вычисляемые разными способами значения.

Говоря строго, значение R-переменной компонента, конечно же, вычисляется и представляет собой объединение UNION нескольких значений, одни из которых могут быть реализованы как хранимые, а другие являются вычисляемыми (прим для modelR - это и есть тот самый вид, о котором я говорю). Для R-переменных типов картина еще более сложна. Поскольку значение R-переменной типа определяется как декартово произведения значений компонентов, возможен случай, когда в некоторых кортежах только несколько атрибутов являются хранимыми. А из-за того, что в процессе наследования типа реализация компонентов, содержащих эти атрибуты, может измениться, в других кортежах указанные атрибуты могут вычисляться (т.е. R-переменная типа, говоря образно, хранится мозаично ). Но в любом случае вычисления значений любых R-переменных должны выполняется системой неявно для пользователя (на основании информации о наследовании типов и реализации компонентов этих типов). Для использования R-переменных необходима только спецификация типа.

Можно провести следующую аналогию. Полиморфные OO-языки программирования делают ненужными использование громоздких и чувствительных к изменениям программы селекторных конструкций, необходимых для выполнения близких по смыслу действий для структур, хранящих близкие по смыслу данные, например
if s.f=1 then function1(s)
elseif s.f =2 then function2(s), заменяя их вызовом полиморфного метода s.function()..

Точно так же полиморфные компоненты делают ненужным явное использование оператора UNION для получения значения отношения, объединяющего близкие по смыслу данные в том случае, когда эти данные хранятся и/или вычисляются разными способами. При этом подразумевается, что объектный тип является наследуемым и что полиморфный компонент может менять свою реализацию. Таким образом, если имеется объектный тип t, в котором определён компонент a, и соответствующие этому типу R-переменные используются в запросах и методах, то создание типа t*, наследующего тип t и переопределяющего реализацию компонента a, не ведет к необходимости менять эти запросы и методы. .... ....Далее идет часть общего примера, демонстрирующего эту мысль

2 ModelR
ModelRЗамечу только, что разделение определения типа и декларации переменных просто позволяет один тип использовать многократно.
А зачем это нужно? Для чего это требуется? Может быть эти потребности можно удовлетворить механизмами, предлагаемыми НМР?

авторВы очень облегчили бы понимание вашего труда если бы провели предлагаемое сравнение, а также может сравнение с какой-то ОБД.

С ОСУБД сравнивать не хочу. Все, что я видел - это не столько СУБД, сколько системы, позволяющие хранить объекты программы постоянно - то есть это даже и не СУБД. Настоящих ОСУБД я как то даже и не припомню. То, что предлагает НРМ ближе скорей SQL3.... НРМ (стр34)Предлагаемый НРМ подход может служить основой для создания системы, которая позволяет создать адекватную, активную и долговременно существующую модель предметной области, управляемую пользователем и предоставляющую пользователю данные о своем состоянии.

2 ModelR
Давайте разбираться.

ModelRНапример, в вашем примере остатки товара на складе определены как вычисляемые, теперь я присваиваю им некоторое значение, например пустое.
Что это значит? Отныне они перестают вычисляться?

Нет, вычисляться они не перестанут. Такое присваивание не изменит реализации и, соответственно, при следующем чтении мы опять получим вычисленное значение. НРМ говорит, что... НРМ(стр9)...Компоненты, не имеющие параметров (т.е. атрибуты), допускают также операцию присваивания.Должна ли эта операция обязательно изменять значение этих компонентов НРМ не оговаривает.

ИМХО ваш же пример демонстрирует возможную обоснованность такого подхода. Раз остатки на складе не хранятся, а определяются многими поставками и отгрузками, то система попросту не должна обращать внимание на попытки прямого изменения значения соответсвующего компонента. Если конечно иное не оговорено в реализации этого компонета специально (например, тем же триггером).

Замечу, НРМ оговаривается, что... НРМ(стр8)Мы не рассматриваем иные характерные для языков программирования возможности спецификации объектных типов (например, модификаторы видимости private и public, модификаторы обновляемости readonly, и т.д.), однако допускаем, что такие возможности могут существовать и быть полезными.
Другими словами, если нужно явно запретить такое присваивание, то может быть стоит специфицировать такой компонент как readonly?

2 ModelR

ModelRЕсли мне нужно две переменные идентичного типа, удобнее написать
больше ничего.

Тогда я не понял.
W1 - это отдельно взятая переменная? то есть это объект? Так у меня можно создать сколько угодно объектов одного класса. Или я где то вопрос не догоняю?

ModelR Из приведенной цитаты про наследование (мозаичное представление одного атрибута), а также из рассуждений о единстве спецификации объектного типа и объявления переменной соответствующего типа возникает подозрение, что наследование включает в себя и копирование значения родительской переменной в наследующую переменную. Так ли это?
Давайте таки отделять мух от котлет. Есть объекты (то, что создается командой new имя_о_типа ) и есть R-переменные. Я пока не понял, о каких перменных речь.

Однако на всякий случай скажу, что если речь идет о R-переменных, то ни о каком копировании речи нет. Аналог R-переменных- это не таблицы, а виды. Они вычисляется. Их значения не могут куда либо копироваться, потому что эти перменные определяются(неявно!) один раз - когда определяется их класс.

Попробуйте читать внимательней. Мозаичное представление - это про R-переменную класса, а не компонента.

И я хочу донести, что все эти рассуждения про R-переменные есть не более чем обоснование . Пользователь может этого не знать, точно так же как пользователь SQL систем может не знать РМД. Смотрите пример. Он представляет собой достаточно полную модель оговоренной предметной области, которой можно пользоваться - создавать объекты, делать запросы и т.д. Рассматривая пример попробуйте абстрагироваться от обоснования : тогда Вы увидите, что это достаточно просто использовать - описали классы, задали их реализацию и после этого сразу же можно создавать объекты и делать запросы.

2 ModelR

Про наследование и R-переменные по другому. Объекты класса наследника, естественно, принадлежат и базовому классу. Спецификация класса наследника включает спецификацию базового класса. Поэтому класс наследнимк наследуют R-переменные базового класса. Никакие значение никуда не копируются(точнее нет даже обснований для того, что бы подозревать это).

ModelR Именно - в смысле сколько угодно. Ну так сколько угодно и создавайте.

ModelR Предлагаю не вводить в модель данных такое понятие как триггер Хорошо. Вместо фразы U-geneЕсли конечно иное не оговорено в реализации этого компонета специально (например, тем же триггером). Следует читать: "Если конечно иное не оговорено в реализации этого компонета специально.".

2 Андрей Леонидович

Какой такой навигатор? Язык и только язык. И никаких рисованных схем. То есть я не против такого рода интерфейса в реальных системах, но в манифесте языка вполне достаточно.

Андрей Леонидович1) Эта концептуальная схема в ОСУБД представляется на ЛОГИЧЕСКОМ уровне точно в таком же виде, и, следовательно, точно в таком же виде поддерживается объектным навигатором (который должен быть в любой ОБЪЕКТНОЙ системе).

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

Понимете, когда я говорю, что было отгружено 20 штук артикула "а" и было отгружено 20 штук артикула "а" (это сознательное повторение), как Вы определите - это я два раза про один и тот же факт я сказал или про разные? Никак! Сами по себе эти значения (факты) абсолютно одинаковы! Отличить их можно только в контексте объектов, которые этими фактами описываются. Уникальность этих значений(фактов) определяется не в них самим, но только в содеражащих их объектах. Поэтому не надо изо всего делать объекты. Есть просто значения(факты), которые объектами не являются и НМР отражает это.

И какой-такой навигатор?

Андрей Леонидович2) а с другой стороны, Вы допускаете (непонятно зачем) денормализацию (встраивание объектов), противоречащую "реляционному духу" (но, впрочем, не Манифесту Дейта), и осложняющую (мягко говоря) прямой доступ к встроенным объектам (в данном случае - к операциям).

Что значит - непонятно зачем? Вы же сами забодали тут всех ребят :)утверждением, что ключи - это дескать плохо, и я подумал - раз Андрею Леонидовичу это не нравится, надо изобазить что-то подобное ссылкам в ОО-языках (может так понравиться?). :)

А насчет ненормализованности это самый интересный вопрос. Да, объекты ненормализованы. Однако... НРМ(стр13)Предполагается, что данные, хранящиеся в R-переменных, всегда актуальны – любое изменение состояний объектов приводит к изменению значений соответствующих R-переменных. Другими словами, данные, представленные в виде значений компонентов объектов, и данные, представленные в виде значений R-переменных - это одни и те же данные (в дальнейшем мы будем говорить о двояком представлении данных). Любому объектному типу с ненормализованнйо структурой соответсвует несколько R-переменных, структура которых однозначно нормализована. При этом система организована таким образом, что пользователю не приходится даже задумываться, с каким именно представлением он работает. Прочитайте еще раз внимательн раздел "R-переменные" - там все это описано

Я еще раз говорю - В НРМ нормализованные переменные отношений явно не описыаются. Однако это не значит, что их нет вообще. Их существование, их имена, имена их атрибутов - все это задается описанием значимых и объектных типов (структура последних ненормализована).

Например для о-типа "документ" будет существовать аж три R-переменные
1)R-переменная собственного компонента (что это такое - см. НМР) содержашая данные из заголовка документа
2)R-переменная компопнента описывающего отгрузки поэлементно
3)общая R-переменная типа
Все эти пременные являются нормализованными переменными отношений: первые две навскидку в >=3НФ, третья в 1НФ.
(Замечу, что фактически тоже самое получилось бы и в традиционных SQL системах две таблицы для хранения заголовков и строк, + постоянное использования JOINа, связывающего их вместе(R-перменаая типа и есть этот JOIN). По сути в НРМ то же самое, просто описано и представлено абсолютно по-другому)

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

Абсолютно никакой проблемы - делаете(я использую термины SQL) SELECT...WHERE.... . И что это за слои? Все, с чем работает пользователь, существует....мммм....в одном и том же месте. Никаких слоев. И потом...:)... Какой-такой навигатор?

Еще раз указыаю на ошибочность фразы Андрей ЛеонидовичВы допускаете (непонятно зачем) денормализацию (встраивание объектов)

Я не допускаю встаиания объектов. Где Вы это нашли?На всякий случай связка цитат. НРМ стр3,10
1)скалярные – включая базовые (числовые, символьные, булевские и т.п. типы) и ссылочные типы (о них - далее).
2)конструируемые кортежные типы. Кортежем называется множество пар "имя атрибута, значение атрибута скалярного типа". Соответственно, кортежный тип определяется как множество пар "имя атрибута, скалярный тип атрибута".
3)конструируемые типы отношений, определяемые как типы множеств значений заданного кортежного типа.
(прим - До сих пор, как видите, все что есть это ссылочный тип. Что же это такое?)
...
Операция сравнения объектов (один и тот же объект – разные объекты) основывается на непосредственном сравнении их объектных идентификаторов. Именно поэтому объектные идентификаторы (сами по себе) рассматриваются как генерируемые системой значения ссылочного скалярного типа (домена) DOID. Входящие в компоненты объектов поля ссылочного типа позволяют описывать связи, существующие между объектами моделируемой предметной области. Для переменных ссылочного типа определены операции присваивания, сравнивания и неявного разыменования. Последнее подразумевает, что любая операция, отличная от операций присваивания и сравнивания, выполняется не над ссылкой, а над объектом, на который эта ссылка указывает
(Вот видите как я для Вас старался :) - даже написал, что ссылки позволяют описывать связи (наверное это надо убрать))

Далее вопрос
Андрей ЛеонидовичВидимо с многие-ко-многим проблема не преодолима ?

Как не преодолима? Например. Определяем кортежный значимый тип, содержащий ссылку на объектный тип А. Создаем объектный тип В, содержащй компнент ref_comp, представляющий множество кортежей указанного значимого типа. При этом в ключ этого компонента ссылочное поле не входит.

Создаем объектный тип B, содержащй компнент ref_c, представляющий множество кортежей указанного значимого типа. Теперь каждый объект класса В может ссылаться на многие объекты класса А, и на каждый объект класса А могут ссылаться многие объекты класса В. Это разве не связь многие ко многим. При этом учтите - ссылки в НРМ допускают доступ к данным в обе стороны.

А если учесть, что
НРМ(стр10)В системе могут существовать переменные, представляющие собой группу ссылок на объекты заданного типа (групповые ссылки). Значение, хранящееся в такой переменной можно рассматривать как значение отношения с одним единственным атрибутом OID, определенным на одном из ссылочных типов. Отметим, что такая переменная не требует явного определения ключа – подразумевается, что ключом однозначно является единственный атрибут. Одиночную ссылку (т.е. ссылку на один-единственный объект) можно рассматривать как частный случай групповой ссылки.

То такая связь может быть задане еще более просто.
в данном случае компонент ref_comp прямо определяется как групповая ссылка.

Андрей ЛеонидовичПока у меня складывается впечатление, что НРМ остается "реляционным" даже в объектном "слое".

Какие-такие слои? :)
Да он остается реляционным - я этого и добивался Однако описание данных - объектное, и я этого тоже добивался.

2 ModelR
ModelR Вообще по-моему трактовка множеств объектов (коллекций) - одно из принципиальных отличий РМД и ООБД. Что по этому поводу говорит НРМ?

Определив о-тип мы (благодаря его R-переменным) сразу же можем работать с множеством, содержащим все существующие в системе объекты этого типа.

Например

CREATE CLASS A{};

SELECT ... FROM A ...;

Опять же
НРМ(стр10)В системе могут существовать переменные, представляющие собой группу ссылок на объекты заданного типа (групповые ссылки).

Таким образом мы можем явно задать некое подмножество существующих в системе объектов. Далее, в разделе "R-переменные и ссылки." показано, что... НРМ(стр19)...Таким образом, имя ссылки, подобно имени объектного типа, является многозначным именем, которое должно интерпретироваться в зависимости от операции, в которой это имя используется (конечно, в групповых операциях оно интерпретируется как имя R-переменной). По большому счету единственное отличие между R-переменной t и R-переменной reft заключается в том, что первая определена глобально, а вторая – только там, где определена соответствующая ссылочная переменная (т.е. в типе или в методе типа).
То есть мы может работать с подмножеством, определяемым групповой ссылкой, точно так же, как и с множеством, определяемым о-типом

Единственный вопрос может быть в том, что такого рода подмножества не определены глобально, что не позволяет обращаться к ним используя непроцедурные команды управления системой. Да, наверное это было бы полезно. Спасибо, буду думать.

Сбили меня тут своим классами :)

В НРМ есть, конечно же, объектные типы, и они допускают множественное наследовангие. Вс екомпоененты этих типов можно переопрелелять при наследовании. То есть и компоненты и, следовательно, сами эти типы являются полиморфными.