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

Я намекаю уже в который раз. Если Вам хочется "продолжать", откройте свой топик и продолжайте там. Дайте ссылки на первоисточники, найдите наконец то Ваши формулы, и в путь!!!..... Но здесь "продолжать" не надо - тем более, что я уже признал свое полное моральное поражение. Не надо здесь флудить - неужели Вы этого до сих пор не поняли? Ай-яй-яй, как это печально....

2 ModelR Не нашел Ваших координат (есть личный вопрос). Вы можете со мной связаться (_grg@comail.ru_)?

2 Dimonische

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

Пример

Каждый объект типа ot содержит комонент с атрибутами i и s.Соответсвенно, мы можем говорить о R-переменной компонента "ot.c" с атрибутами "i" и "s", ои о R-переменной типа "ot" с атрибутами "с.i" и "с.s". Я специально имена переменных и их атрибутов обозначил кавычками. Сами атрибуты скалярные(никаких вложенных коллекций!), но имена у них сложные. В НМР повторяется несколько раз, что РМД не накладывает никаких требований на имена переменных отношений и их атрибутов, за исключением требования уникальности. Соотвественно я могу написать имя атрибута как "с.s" или как "c . ref . comp_of_ref . scalarattr_of_comp_of_ref" - в любом случае за этим сложным именем атрибута, несущего в себе семантику ссылки, стоит некое скалярное значение.

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

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

2. Структура объектов может быть наследована и изменена.Да.

3. Запросы полиморфны, если не указано обратноеЯ бы сказал так - "В запросах используются данные из R-переменных полиморфных классов". Откуда беруться и как получаются эти данные, определяется системой на основании реализации этих классов.

4. Пункт 3 распостраняется и на вложенные объекты.С точки зрения пользователя, который не задумывается о R-переменных (у него в голове есть структура сосссылками) - Да.

5. Запросы могут обращаться к вложенным объектам через точку типа customer.address[0].city. JOIN используется для связи к другими объектамиДа. Опять - же с точки зрения этого пользователя. Формально, в терминах R-переменных работа со сслылочными структурами есть те же JOIN-ы, но пользоваетель не должен об этом не думать.

ИМХО НРМ предлагает подход, позволяющий освободить пользователя от лишнего явного использования JOIN-ов. Например, вместо того, что бы каждый раз получая данные о продажах, делать " таблица_заголовков JOIN таблица_строк ON ..."? можно использовать просто "продажи". А если нужны данные только, например, по строкам, можно использовать те же "продажи.строки". А если учесть возможность переопределять компопненты, то я даже не берусь навскидку написать то, что в традиционном SQL будет соотвествовать простому обращению к полиморфным "продажам."

Тьфу - не классов, а О-типов. Ну не класс это, не класс.... :)

Тьфу - не классов, а О-типов. Ну не класс это, не класс.... :)Это не Вам - это я сам себе сказал.... :) Тоже привык. Опять же, с точки зрения пользователя оно так и есть - он этой разницей заморачиваться не должен.

2 Dimonische
А я еще и добавлю!...

Про классиков есть разные версии Я тут в сети кое-что нашел

из сети...Про это еще Эйнштейн сказал, что ученый, который не может объяснить теорию относительности 5-класснику, не ученый, а шарлатан...

...А. Эйнштейн говорил, что ученый, который не может объяснить пятилетнему ребенку теорию относительности - шарлатан…

...Альберт Эйнштейн: "Если вы не можете что-то объяснить шестилетнему ребенку, значит вы сами этого не понимаете"...

...Эйнштейн сказал: если вы не можете объяснить, что вы делаете, то
не стоит этого делать...

...Эйнштейн сказал в свое время : "Если ученый не может 10 летнему ребенку объяснить суть своей работы - это не ученый, а шарлатан!" (или рядом с этим ...не дословно)..

...Как говорил Эйнштейн, ученый, который не может уборщице объяснить, чем он занимается, зря получает зарплату...Так что же все таки сказал Эйнштейн? Когда я зашел на сайт www.aphorism.ru я нашел там целую кучу афоризмов,приписывваемых А.Э. Но! среди них не было ничего про объяснение сложных вещей людям без соответсвующего образования.

Вот если бы кто-то смог обяснить 6-ти летнему ребенку, что есть те же ООП, РМД и все, что с этим связано.... А то ведь и взрослые дяди всё норовят "простейшии термины" пользовать, считая, что при этом они ничего не теряют(что же, пользователь - он и есть пользователь). И на здоровье, и это все понятно.... Я помниться, давным-давно с С на С++ переходил, так все думал - и зачем это все? Можно пользоваться простым С и ничего не теряешь... И ведь действительно, пользуя С++ в сравнении с С я практически ничего не потерял. Зато сколько приобрел!...но это я потом понял....

В общем, как говорил все тот же Эйнштейн "Никакую проблему нельзя решить на том же уровне, на котором она возникла." Постейшие термины принадлежат уровню, где проблема возникла. Можно пользоваться ими и дальше - при этом ничего не будет потеряно. И точно остануться проблемы.

Раз уж речь зашла о таблицах.... Вопрос к знатокам SQL. Я понимаю, что есть теория, а есть суровая практика. Я понимаю, что SQL очень развился, и порой возникает ощущение, что там можно сделать уже все. Правда, ИМХО там это все не совсем очевидно..... Но даже не в очевидности дело...

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

Вот выдержки из примера НРМ (незначимые куски я заменил на )

Итак, мы имеем о-тип GoodsMotion, описывающий отгрузки со склада. Соответственно, мы имеем R-переменную компонента типа "GoodsMotion.MovedItems" и можем с ней как то работать. Например мы можем найти артикулы, которые отгружались в количестве 100 штук, оформив результат в виде глобальной переменной значимого типа

Теперь у нас есть глобальная перменная 100PiecesArticleList , которую мы можем использовать в запросах. Это вычисляемая перменная - фактически аналог типа.

До сей поры ничего нового. Данные об отгрузках типа храняться и на их базе сделан вид. В SQL такое как два пальца....

Теперь я наследую и переопределяю о-тип GoodsMotion

Отмечу, что я переопределил компонент MovedItems. Теперь R-переменная компонента типа "GoodsMotion.MovedItems" содержит не только хранимые но и вычисляемые данные. При этом нам не пришлось делать каких либо UNION-ов или других операций, сливающих хранимые и вычисляемые данные вместе. Нам вообще не потребовалось менять существующий вид "100PiecesArticleList". Мы просто унаследовали и переопределили тип. Это можно сделать в SQL?

Я это все к тому, что "простейшии термины" "таблица" и "вид" таки не могут заменить R-переменные. Термины "таблица" или "вид" УЖЕ определz.n реализацию - подразумевается, что они сами по себе УЖЕ определяют, храняться эти данные или как-то вычисляются. R-переменная (подобно таблицам и видамв первом приближении) представляет данные в виде отношения, однако (в отличии от них) откуда эти данные беруться, храняться они или вычисляются - все это определяется реализацией класса. Эта реализация может быть 20 раз переопределна, и, соответсвеннол, R-переменная будет содержать данные полученные 20-ю разными способами. Но никаких изменений существующих запросов - просто переопределние типа.

Павел Воронцов Реализацию Вашего примера на SQL на вскидку действительно придумать сложно, но, поднатужившись, вероятно можно. ИМХО это будет как переписывание программы С++ в использую plain C.

Павел Воронцов А вот на Tutorial D такое должно делаться довольно легко... Наверно... Но думать лень. Ой как Вас ленивых много развелось ...:)... ИМХО конечно можно, но так же как см. выше про SQL...

Как медитации?

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

авторКроме этого придется еще и думать (ой, звыняюсь, не всем, конечно, многим это больно), когда использовать отношения, а когда вложенные массивы, классы и т.д., как и где задавать ограничения непротиворечивости данных и т.п.Дык!..думать то не надо:)...Думаем исключительно в терминах сложных структур. Однако можем ипользовать операции РМД, обращаясь к данным про которые мы думаем как о сложных структурах. При этом мы продолжаем думать о данных как о сложнных структурах, что достигается благодоря тому, что в этих оперциях используются сложные имена переменных отношений и сложные же имена их атрибутов (то есть они сложные с нашей точки зрения, а с точки зрения РМД - это просто имена ). Однако эти переменные - являются б/п переменными отношений, определённых на множестве скалярных доменов.

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

Где-то видел я высказывание Дейта, в духе, что можно, например, объект "крыло самолета" представить, хранить и обрабатывать в РБД как значение абстрактного типа данных (домена), но можно и описать множеством значений relvars, но это разные уровни абстракции, и смешивать их нельзя. Ну может Дейт так и думает :). У меня по поводу НРМ есть аналогия. Если вглянуть на бочку сверху - она круг. Если сбоку - она прямоугольник. Однако это одна и та же бочка. НРМ рассматривает данные как эту бочку. Они могут быть представлены как множество объектов и, одновременно, как множество отношений.
НРМ(стр13)Другими словами, данные, представленные в виде значений компонентов объектов, и данные, представленные в виде значений R-переменных - это одни и те же данные (в дальнейшем мы будем говорить о двояком представлении данных).
Но это одни и те же данные, и это один и тот же уровень абстракции.

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

В первом приближении в таких системах вместо того, что бы проектировать объекты приложения, и, затем, под них проектировать БД, мы должны проектировать объекты предметной области и, уже затем, делать какой то интерфейс Получается типичная КС система (только используется уже не сервер данных а ...ммм... наверное можно сказать, что сервер моделей ПО), где С является соверщенно отдельной и независимой от К системой. Мы можем развивать модель ПО не трогая К, или мы можем делать любые К.

Насколько это сложнее?

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

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

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

Другое дело, что говоря о реализации системы я предполагаю, что она может быть создана на базе существующих РСУБД (уровень хранения). На этом уровне тоже есть отношения (используя "простые термины" это таблицы и виды). Естественно, предполагается, что система "не допускает напрямую" запросы к этому уровню. Т.е команды, манипулирующие с даннымы, которые представлены для пользователя как сложные так или иначе транслируются в команды выполняемые используемойц РСУБД.

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

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

Кстати! Вчера целый вечер потратил, но с Tutorial D у меня аналог моего примера пакамист не вырисовывается.