Касаемо "маппинга объектов в ОЗУ"...
мод...Но (повторяю) РМД обратно в классы не отображается... И снова - идея ясна (даже без повторений), но доказательсв нет...А что - ОЗУ обратно в классы прямо так с налета отображается, да? А что Вы вообще имеете в виду, когда говорите слово "отображается".

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

Опять двадцать пять :)

Давайте повторим по другому

мод U-gene Это я к тому, что может быть ООП вообще ни в чем не виновато? То, в чем вВы его обвиняете - это всего лишь проблемы обмена данными? Тоесть если данными не обмениваться, то все глядишь и получится. :)

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

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

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

модА ОЗУ обратно в классы не отображается, т.е. произвольные операции над ОЗУ испортят объекты И что дальше? Я уже третий раз спрашиваю, что значит слово "отображаются" в Вашей интерпретации. И в второй раз говорю, что речь об отображении не идет.

Вот скажите, когда мы пишем CREATE TABLE (абстрагируемся пока от некоторых нереляцилонных фичей SQL) мы подразумеваем существование отношений, правда? Как только мы начали это подразумевать, мы можем применять к этим отношениямреляционные операции, и ничто никуда не отображается не нужно. И точно так же НРМ показывает, что написав выражение CREATE CLASS ( ненормализованное значение,ссылки, методы, наследование полиморфизм и инкапсуляция и тд и тп и др. ОО дела ....), можно и нужно подразумевать существования множества отношений. к которым применимы групповые операции. Ни о каких "отображениях" речи не идет. Они есть.

мод.е. манипулировать можно только методами классов, т.е про ОЗУ и РБД можно забыть как будто их не существует вовсе..... и слава богу ,однако это не значит, что данные при этом не могут не могут быть представлены как множество отношений. Более того НРМ показывает, что вызов метода также может стать групповым, в том смысле что вызов метода у группы объектов не потребует циклов по этим объектам даже в реализации.

модЭто и значит что ООП делает невозможным и не нужным применение других моделей Хорошо, давайте тогда заключим пари. Я не берусь утверждать, что это нужно(это интимное дело каждого), однако я могу попытаться доказать,что это возможно и даже полезно. Ставки 1:3 в Вашу пользу конечно :). Пусть будет в том же коньяке...или в чем нибудь еще - на Ваш выбор... :) В качестве арбитра может выступить великий ALL.

Согласны?

фразу "Ни о каких "отображениях" речи не идет. Они есть. " сдедует читать как "Ни о каких "отображениях" речи не идет. Они (отношения) уже есть. "

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

модНу тогда ткните плиз в то место НРМ где используется именно РМД

Дык боюсь пальцев не хватит.

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

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

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

Что такое - "объединени классов?".

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

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

В первом приближении методы нужны для того, что менять состояние объектов (одного или множества, что в общем то суть одно и то же). А рел алгебра нужно, что бы манипулировать с данными об объектах. И всё это в одном пространстве имен.

Нуи к какому - это значение, содержащее некие данные об объектах этих классов.

мод U-gene вызов метода также может стать групповым

Вообще-то в ООП метод применяется только к одному объекту (который self).
Иначе это уже не совсем ООП (или вернее совсем не ООП).

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

Ни к какому - это значение, содержащее некие данные об объектах этих классов.

Уточняю. Результат вычисления отношения в любой рел БД чем является? Я могу просто написать Х UNION Y и получить значение из базы. Или я могу написать CREATE VIEW Z AS X UNION Y, тем самым создав переменную Z , значение которой представляет искомый UNION.

То же самое у меня. Я могу просто получить значение об объектах, либо создать перменную (и соответсвующий тип - не обязательно класс) содержащий это значение. Напимер я могу создать глобальную переменную типа-отношения ListOfAllEvents AS SET OF EventRecord и реализовать ее ALTER ListOfAllEvents REALIZE AS X UNION Y (здесь ListOfAllEvents есть тот же самый вид). Или я могу описать класс "Журнал событий" и создать соответсвующий объект, у которых значения компонентов вычисляется как UNION.

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