Я здесь давеча обещал статью, в которой даю формальное обоснование сабжа. Обещанное можно посмотреть здесь . Быстрой реакции не жду, но что-нить умное :) услышать хотелось бы.

Наверное это надо было в "проектировании... " обсуждать.

В ссылке оказалось два лищних слэша в конце. Откуда они взялись, ума не приложу. Номальная ссылка здесь .

Ну что же сделать - лень так лень. Мне тоже иногда лень писать бывает (особенно когда написанное "читать лень").

Что бы понять о чем речь можно прочитать начало, вместе с оглавлением, и заключение. Может понятней станет.

2 all

Людям сломавшимся на введении отвечать не буду :)

2 Gt_

Ну коль ты дошел до "Из теории реляционных БД известно,..." то ты уже вышел из введения и я тебе попытаюсь ответить.

0) употребляя термин ОЗУ я оговариваюсь, что это не более чем метафора, которую я считаю удачной. А насчет фл э ша - интерсный вопрос. ИМХО развитие инф. систем - крайне эволюционный процесс и неясно, что было бы сейчас с СУБД, если скажем в 60-х резко развилась какая-нибудь магнито-ферритовая память, которая, подобно. фл э ш, позволяет хранить данные постоянно.

1) Для доступа к данным реляционные системы используют непроцедурный высокоуровневой язык, реализующий ненавигационный доступ к данным.

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

2) Используемые в настоящее время СУБД представляют собой результат развития средств управления внешними запоминающими устройствами

Я даю ссылку на очень хорошую (хотя и достаточно старую) книгу "Дж.Мартин. Организация баз данных в вычислительных системах. Изд. 2-е 1980 Мир (Москва)". Там этот процесс (системы управления ВЗУ - файловые системы как средство позволяющее реализовать независимоть данных от физических устросйв - БД как совместно используемая совокупность файлов - СУБД как средство позволяющее реализовать принцип логической независимости данных) достаточно подробно рассматривается. Так что NO CO MM ENTS - это, в основном, к "Дж. Мартин"у. Я просто все это в одной фразе уместил.

3) Существуют ОС, позволяющие при выключении компьютера сохранить на диске полный образ ОЗУ

Разве не существует? У меня на ноутбуке такая стоит...

4) Из теории реляционных БД известно, что для того, что бы сохранить данные в реляционной БД, эти данные должны быть представлены в нормализованном виде

....Даже ссылки есть :)

5) Существующая реляционная модель данных не нуждается в каких-либо изменениях или дополнения.

И это правильно!....

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

И вообще - чем вопросы в воздух задавать, лучше прочитали бы, что-ли. А то, отвечая на эти вопросы, я в конце концов перескажу все по второму разу. :) На самом деле идея очень простая. Ну очень простая. И то, что предложеный подход будет работать - в этом я абсолютно уверен.

2 Gt_

Это называется - спор ради спора.Это очень просто - выхватываешь фразу из текста и начинаешь по ней кататься. Я выглядишь таким таким умным и крутым программером что просто круче вареных яиц. Флаг тебе в руки и перо в зад.

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

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

беру XML/iso диска С и сваливаю в CLOB, кто мне запретит ? ГЫ!!!
Никто не запретит. А еще ты можешь это "XML/iso диска С" на бумажке записать и этой бумажку потом использовать (только возьми бумажку помягче:), потому что этой твоей записью пользоваться мягко говоря трудно (что например ты будешь делать, если в начало байт потребуеться добавить?).

Действительно, зачем нормализовать? И хто ето выдумал - "избыточность данных", "функциональные и многозначные зависимости", "нормальные формы" и т.п. Наверное дураки каки-нить? надо взять CLOB ("о, я какие слова знаю!") и запихнуть все туда....

И, что самое интересное - ведь запихивают.....

2 Gt_
Я так понял, что аргументы по делу иссякли. А то, что в любом споре самое главное - это вовремя перейти на личности, так это Жванецкий уже давно озвучил.
А коли ты ты так за детей (может ты себя имел в виду?) волнуешся, взял бы орфографический словарь для начала.

2 Cat2

Фразу "Из теории рел БД известно..." переделал.... Спасибо :). Уболтали :).

Далее

писал:
Однако возможен и другой случай, когда значение атрибута объекта вычисляется исходя из значений других атрибутов данного объекта. Будем называть такие атрибуты вычисляемыми.

В нормализованой базе невозможен.

Здесь я не понял... Почему невозможно?

Одной из наиболее актуальных проблем, существующих в области хранения данных, является проблема объединения свойств, присущих объектно-ориентированным программам и реляционным системам хранения данных, в рамках единой универсальной системы обработки и хранения информации. Обращает на себя степень единодушия в отношении желаемых возможностей такой системы [1,2,3].

Не знаю, не знаю. На мой взгляд, средства доступа клиентов к база данных уже давно объектно- ориентированы, а нужно ли это для самих данных?

Может я не в курсе, но все OO-средства доступа к БД, что я видел до сих пор (допускаю, что я мало видел), былы именно средствами доступа к БД и не более. То есть речь идет об объектах БД или об объектах доступа (всякие там Connection'ы, Recordset'ы). А клиетское приложение рабает с этими объектами. А для чего оно работает? Что бы сохратить данные объектов, моделирующих предметную область в таблицах БД, или достать эти данные оттуда. То есть в клентском приложении есть объекты, моделирующие объекты предметную область, и есть объекты, представляющие БД. И вот что получается (предположим, что объект был создан ранее).



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

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

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



Причем все данные (в том числе и описание формы), могут храниться на сервере, у клиентов же есть только маленькая такая програмуля (типа браузер, значица:) которая эту форму загружает.

В общем это все ИМХО и фантазии , касающиеся визуализации данных и клиентской части.

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

Наиболее распространенная операция - получение пересечений свойств классов. То бишь - множественное наследование

Не знаю, насколько это распростанено, но у меня мн. наследование вполне возможно. Только я в этой статье про это не уточнил :) Можно использовать в качестве предка одно именованное подмножество атрибутов, а можно - несколько. Самое главное - с реализацией потом определиться.

Пример в статье о наследовании класса "Отгрузка товаров" классом "Продажа товара" неудачен.

Может быть... Но здесь важен не столько пример, сколько... мммм.... сама демонстация понятия "переопределяемый атрибут", и последующии действия с ним. Точнее факт того, что последующих действий может и не быть, посколку эти действия МОГУТ БЫТЬ УЖЕ ОПИСАНЫ - поскольку они описываются для спецификации этого атрибута.

Огромное спасибо свсем заинтересовавшимся. Посколька опыта написания совсем нет, то рассмартиваю все замечания и, вношу необходимые изменения. Все, принявщие участие, будут упомянуты в части "Благдорности" :)

2 Репликант

1) Для доступа к данным реляционные системы используют непроцедурный высокоуровневой язык, реализующий ненавигационный доступ к данным.

SQL - да, непроцедурный. А что там с оракловским PL/SQL? Вроде говорят он как бы процедурный (Дед Маздай: врут что ли паразиты!?)

Я говорю не про управления данными в среде СУБД , а про доступ ....ммммм..... снаружи. Написав процедурку на PL/SQL или на Т-SQL мы должны использовать команду CREATE PROCEDURE в которой наша процедура рассматривается практически как строковый аргумент. Вот это и есть непроцедурный доступ. Обращаясь с СУБД, дабы эта процедура была выполнена, мы будем использовать команду EXEC - и это тоже непроцедурный доступ.

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

Мда. Что мы имеем сейчас в SQL. Мы имеем несто типа "CREATE TABLE...", "CREATE VIEW...", "CREATE PROCEDURE..." (еще мне нравиться "CREATE FUNCTION"? которое есть в MS SQL) - и это все мы имеем по отдельности. ИМХО все это можно заменить на нечто типа


Команды высокого уровня остаются, но описание данных в них нескоько иное.

Я пытаюсь показать, что вся это хренотень будет работоать и в ОО- и в реляционном- жанрах. Аналогия: раньше в языках програмирования мы описывали структуры и функции (по отдельности), а потом стали работать с объектами.

Что мы получаем в конце концов? С одной стороны - гибкость и расширяемось объектных систем, с другой стороны - мы остаемся в рамках реляционной модели данных.
1. Можно ли обойтись без ЭТОГО?
Конечно можно :) До сих пор обходились. С другой стороны есть "Манифест СУБД третьего поколения", в котором приведен ряд требований к этим самым СУБД3пок. ИМХО, то что я пытаюсь описать, очень хорошо на основные из этих требований ложиться. Опять же, можно писать на ассемблере (очень эффективно), но почемуто все пользуют всякие С++, Java и BASIC. Видимо потому, что это позволяет увеличить размер контролируемой сложности.

2. Чего мне ЭТО будет стоить?
Дык, я уже написал. :) - мне уже ничего не стоит.

3. Что можно с ЭТОГО поиметь?
Минимум ничего. Ну не убьют же меня за это, в самом деле? :)

Я не знаю, как это будет реализовано. ИМХО как угодно. Мне это видится в виде сервера, представляющего собой среду существования объектов и управляемого непроцедурными выражениями. Как этот сервер будет реализован - тоже как угодно. Например, можно взять существующие SQL-сервера и иcпользовать их в качестве основы. Можно написать с нуля. Можно попросить производителей железа , что бы они спаяли :) "реляционное ОЗУ" и строить систему на нем.

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

Далее о терминах. "терминальный механизм" я вроде бы определяю - "механизм хранения с неизвестным устройством, который определен только через способ обращения к нему и действия, которые он производит по отношению к другим частям системы" (эту фразу я практически без изменений взял изочень умной монографии, найденной в сети, но, блин, сослаться не смог, потому что монография исчезла и "Cannot find server"...). Можно сказать, что терминальный механизм, это механизм, который обеспечивает поддержку переменных базовых типов (INT,FLOAT и т.п.).

Слово "киберентическая" значит "управляемая". Система может определенным изменяться в ответ на определнные внешние воздействия (команды). Мож это и вправду не надо?

Насчет данные "должны быть нормализованы" давно уболтали :). Как вам фраза "для обеспечения эффективного хранения данных (что подразумевает их целостность и непротиворечивость) , эти данные должны быть нормализованы "?

5. Между исходным множеством объектов и результирующим множеством отношений
существует отношение "многие ко многим": каждое отношение может состоять из кортежей,
описывающих
Тут не используется один и тот же термин для обозначения разных понятий? Если "отношение"
у вас означает аналог сущности/таблицы, то используйте термин "связь" (relationship, association)
А фиг ё знает... Если у меня мат. статья, то надо писать "отношение". Если статья по БД - то "связь". Но раз в начале предложения говорится о двух множествах, то ИМХО "отношение" тоже уместно.

Насчет терминологии - это правда трындец :) Но я могу оправдаться! Ортогональности объектных и реляционных типов в том числе подразумевает, что множество атрибутов класса и множество атрибутов отношения - это два разных множеста - и мы должны их как то отличать, в том числе и в тексте. Поэтому я всегда стараюсь уточнить - o a или r a - а порой перехожу на терминологию таблиц и столбцов, применительно ес-но к реляционным делам.

Кстати 2 Cat2 ! Может быть именно со этим связано Ваша реплика
Однако возможен и другой случай, когда значение атрибута объекта вычисляется
исходя из значений других атрибутов данного объекта. Будем называть такие атрибуты вычисляемыми.
В нормализованой базе невозможен . Я имел в виду атрибуты объекта. У меня вычисляемые атрибуты объектов по смыслу близки к видам SQL-систем.



во втором классе, схема табличного значения, возвращаемого SELECT, должна совпадать со схемой, заданной в определии TABLETYPE.

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

Создана форма (зарплатная ведомость) основанная на этом запросе. Предположим, что у нас появился новый тип работников, для которых мы расчитываем зарплату как-то по другому. Что нам надо было делать в традиционных системах? Нам надо было делать или пределывать UNION и добавлять в него записи из вновь созданного вида, когторый возвращает данные именно для этого типа служащих. Что нам надо делать здесь? Надо переопределить класс, после чего данные для вновь созданных объектов этого класса автоматично появется в расчетной ведомости. Именно для этого и нужны переопределяемые атрибуты. Аналогия: в дообъектных языках для обработки близких структур приходилось писать и переписывать IFы и CASEы (если флаг=1 то функция1 иначе если флаг = 2 то функция2); в объектных же мы просто переопределяем метод класса.

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

Насчет Word в ZIP'e.... Дело в том, что статья выложена на ряд источников именно в HTML-формате. И, поскольку приходиться вностить исправления, то желательно использовать более-менее один источник в одном формате. Вот.

Ух. Писал пять часов. Плохой из меня поветсвователь, в связи с чем Ваши замечания очень кстати.

По поводу производительности...

Для начала приведу цитату из того же "Манифеста СУБД третьего поколения" - "Показатели производительности не имеют почти ничего общего с моделями данных и не должны в них проявляться". Для себя я это понимаю как "можно извращаться как угодно, только модель не трогай..."

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

Что я видел в обсуждении на форуме MS SQL (если не ошибаюсь это статья Тенцера)? Создана таблица для целых, таблица для строк, таблица для чисел с плавающей точкой и т.п., и объектные атрибуты базовых типов храняться в соответсвйющих таблицах. То есть, если есть в объекте десять атрибутов типа INT- тупо получишь десять записей таблицы, предназначенной для хранения INT. Например, если шапка отгрузки содержит пять атрибутов - получим пять записей, если каждый отгруженный артикул описывается тремя атрибутами - получим еще три записи на каждый артикул (кстати! я не понял,как при этом подходе реализуются повторяющиеся группы). Естественно, что в этом случае об эффективной работе с БД говорить не приходится.

ИМХО предложение Тенцера можно прочитать так: "Объектная системы строяться на основании терминального механизма, поддерживающего ограниченное число примитивных типов (int, char, float) и, следовательно БД должна хранить значения этих примитивных типов." Тем самым он кастрирует реляционный механизм, лежащий в основе БД, по самые уши. У меня совершенно другой подход- в качестве терминального механизма я использую реляционную систему хранения всю, целиком. Базовым типом у меня является отношение (а у отношения в свою очередь есть домены, которые и есть эти примитивные типы).

2 чингиз

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

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

Опять же аналогия: Обращения к атрибуту объекта в традиционных объектных языках приводит к генерации ассемблерного кода, использующего адрес некого объекта как базу и некое смещение, однозначно соответсвеющее требуемому атрибуту указанного объекта. Фактически, описание структуры объекта, будучи преобразованным к терминам линейного ОЗУ (терминальной системы) - представляет собой набор смещений, который может быть применен к любой базе, т.е. к адресу любого объекта. Я же пытаюсь использовать в качестве терминальной систему, реализующую реляционую модель, являющуюся ИМХО единственно существующей моделью данных (во всяком случае математически обоснованной).

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

А давайте поставим вопрос так - по-вашему, этот термин просто ни к чему, или он все же вредит восприятию написанного?

Здравствуйте-здравствуйте ! :)

Прошу прощения за то, что оставил без ответа несколько последних сообщений. В связи с рождением дочки голова был сильно занята вещами, достаточно далекими от БД и СУБД и тп. Ну разве инода заглядывал... мимо пробегал, значица. :)

Потенциальному читателю хочу сказать, что статья доступна на сервере CITFORUM по адресу http://www.citforum.ru/database/articles/ooo_rel_data/ . Кстати, ссылка имеется и на этом сервере - в разделе статьи от 26.06.03

c127 по этому же адресу может скачать файл в Вордовском формате. К сожалению PDF сделать не смог (4-й акробат рухает вместе с системой а 5-го у меня нет). Если у кого есть возможность конвертнуть (только 5-м!!! 4-й рухнет:) )- если не трудно, сделайте милость, а результат вышлите мне.

По поводу благодарностей :) Я упомянул участников активного :) обсуждения на SQL.ru, но было бы неплохо, что бы Чингиз, репликант и Саt2 дешифровались и прислали мне свои мирские имена, если посчитаете нужным, конечно.

>поздравляю
Спасибо

>у меня первый ребенок тоже дочка.
У меня их две (довелось услышать "бракодел".... естественно от бездетного человека )

>все что не помогает - мешает.
Беда видимо в том, что я попытался запихнуть в одну кучу саму идею (типа "концепцию" значица), подводимый под нее формализм и вдобавок приправил это вариантами использования, причем эти варианты можно назвать деталями....достаточно существенными(такие как проектирование данных) и не очень. И даже не объяснил, что же это такое "объектно-ориентированная система управления реляционными базами данных". У меня возникает мысль написать что-то в виде "вопрос - ответ(на пару абзацев)" - типа ФАКа, начав с "что таке ООСУРБД?" и "а причем здесь реляционные БД?". Достаточно много такого рода вопросов я уже получил,в том числе и здесь. И возникающие вопросы мне очень интересны.

>если у Вас есть еще интерес к обсуждению - я могу почитать дальше.

Конечно интересует!!! Еще как. Поскольку я заморачиваюсь темой практически в одиночку, то отсутсвие обратной связи жутко угнетает. Два года назад я опубликовал статью "модель объект-качество" и уже думал, что про нее забыли.... и вдруг начал встечать какие то ссылки, в конфах вспоминают, а кто-то даже сказал, что это статья "формирует требования к универасльной модели данных" .... но два года - это очень много.

-)). тоже был занят.
А кому сейчас легко? :)

>Ваше мыло скрыто.
Это вряд ли ( (C) тов.Сухов) :) Адрес есть во всех статьях прямо под названием. Никак не могу понять почему , но как только в очередной публикуешь свой адрес в каком-нить открытом источнике, так количество спама увеличивается.

Гы, ОО-модель говорите? а что это такое? Поди туда- не знаю куда, найдит то - не знаю что...

Я уже писал тут, пробегая мимо, но не довел свою мысль до конца. Цитирую (сам себя :)

>>>Мысль первая! вспомним определение модели данных: "1)множество типов, 2)множество операций над экземплярами типов, 3)множество ограничений, применимых к экземплярам типов".

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

Итак, как мы видим, все три важнейшии ОО-концепции имеют прямое отношение к РЕАЛИЗАЦИИ.

Так вот - фишка заключается в том, что говоря (в определении модели данных) про множествах типов, опреций и ограничений, мы фактически говорим о множестве классов, для которых совершенно четко определна их СПЕЦИФИКАЦИЯ - и ни слова о их РЕАЛИЗАЦИИ. <<< Конец цитаты. <

Другими словами МОДЕЛЬ ДАННЫХ - это некая цель, а ОО - это способ достижения этой цели. Если модель данных соверщенно четко описывает некий набор ТИПОВ и определяет СПЕЦИФИКАЦИЮ этих типов , то ОО-парадигма утверждает, что имея некий исходный набор "примитивных" типов для которых определный исходный набор "примитивных" операторов, мы можем РЕАЛИЗОВАТЬ (описать) ЛЮБЫЕ типы. Именно поэтому я и говорю, что математическая модель ОО - это химера.

Говоря образно, мы можем нарисовать чертеж детали (модель), но сделать деталь мы можем абсолютно разными способами, но если мы создали деталь, то пофигу, работали ли мы напильником (писали на ассемблере, значица:) или использовали роботизированную линию (испльзовали что-нить типа C++).

Пример (я продолжаю цитирование)
>>>Предположим, что используя ОО язык програмирования я создал класс "Абстрактная таблица" для которой определи набор методов, реализующих реляционные операторы, и два класса-наследника "Хранимая таблица" и "Вид" (у них могут быть конструкторы, принимающие в качестве параметров выраженияч типа "CREATE TABLE" и "CREATE VIEW"). Ну, я надеюсь вы понимаете, что у нас в конце концов должно получиться . И, наконец, мой вопрос - это объектная система или реляционная? Правильный ответ такой - для создания системы, реализующе реляционную модель использовалось средство, реализующее ОО парадигму. <<< Конец цитаты. <

Используя это же средство мы можем написать систему моделирующую географические объекты, производственные процессы или реализующую виртальную Java-машину. В каждом случае у нас разная моделируемая предметная область - т.е. разная спецификация. Реляционеая моель полностью описывает СПЕЦИФИКАЦИЮ математическим языком, виртуальная Java-машину моделирует железо, а чем описываются производственные процесы?

Далее...
>>> ИМХО здесь надо отличать СИСТЕМУ от ИНСТРУМЕНТА, служащего для создания этой системы.

Термин ОО в применении к СИСТЕМЕ действительно значит, что она состоит из объектов - а больше ничего и не нужно. Части системы - т.е. объекты - взаимодействуют на основании некой СПЕЦИФИКАЦИИ. Выполнена спецификация - есть рабочая система.

Термин ОО в применении к ИНСТРУМЕНТУ создания системы означает некую методологию позволяющую описывать эти объекты на основанни существующих типов и операций. Другими словами речь идет о способах РЕАЛИЗАЦИИ заданной СПЕЦИФИКАЦИИ и именно на этом этапе возникают все эти вещи - инкап.,насл. и полиморф. То есть эти понятия нужны на этапе создания - когда же система функционирует то уже по барабану, является данный объект объектом наследуемого класса или же его класс написан с нуля. <<< Конец цитаты. <

...только я погорячился, обозвав СИСТЕМУ(результат) объектно-ориентированной. СИСТЕМА на самом деле просто ОБЪЕКТНАЯ, а вот ИНСТРУМЕНТ может быть ОБЪЕКТНО_ОРИЕНТИРОВАННЫМ. А может и не быть - в конце концов любую ОО-программу можно изобразить на ассемблере, но каких трудов это будет стоить? С другой стороны, используя ОО-инструмент легко можно написать какую-нить ерунду. Например, создавая прогамму можно ВСЕ впихнуть в один класс с кучей PRIVATE-арибутов примитивных типов, кучей таких же PRIVATE-методов и единственным PUBLIC-методом "run". Соответсвенно этот класс реализует функциональный подход к созданию программы ... но разве такая система объектная? (конечно она объектная, только в этом случае любую выполняемую программу можно рассматривать как объект, но разве мы этого хотели?)

В общем я повторяю - ИМХО "строгая модель ОО" есть химера, этакий филосовсий камень, о которм все мечтают, но который, увы.....

Далее... про глубинный смысл и язык.

И не слово о маппинге! Кстати, а что это такое? Не, я читал что-то, но объясните мне это на словах, как Вы это понимаете.....

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



Здесь я хотел бы обратить внимание на то факт, что атрибут t локально в классе представляет собой...мммм...... табличку - с ней мы може работать в области видимости класса, например выбирая из нее записи - SELECT ... FROM t (это может быть оформлено в виде хранимых процедур этого класса) . В случае, если атрибут является публичным, мы можем работать с ним, как с атрибутом объекта определенного некой ссылкой obj и написать SELECT ... FROM obj.t (Это может быть в другой хранимой процедуре, где такая ссылка определена).

Важнейшая же фишка заключается в том, что, поскольку каждому объекту соответсвует некий уникальный OID , то АБСОЛЮТНО законным является также выражения SELECT ... FROM base_c.t! То есть становиться возможным групповой доступ ко множеству объектов, причем в это множество входит и объекты производного класса, в которых указанный атрибут переопределяется (это может быть и в хранимой процедуре и ...мммм.....как команда доступа к данным извне). И все это выражение является абсолютно реляционным. Развивая мысль мы можем дать абсолютно реляционное определние объекта "объект - это декартово произведение своих атрибутов", что позволяет смело написать SELECT ... FROM base_c - то есть организовывать групповой доступ к объектам класса. И поскольку класс inh_c наследует класса base_c (в.тч. и его спецификацию...т.е. набор сигнатур атрибутов) то этот SELECT относится и к объектам класса inh_c, тем самым являясь командой доступа к данным НАСЛЕДУЕМОГО ПОЛИМОРФНОГО класса не выходя за пределы реляционной модели данных. То есть классы как типы данных имы описываем ....мммм.....императивно :) но работать с ними можем и декларативно :)) ну или что-то типа того.

Возвращаясь к предыдущему посту можно сказать так. Создавая объектную систему на базе аппратного компьютера мы ВЫНУЖДЕНЫ представлять наши объекты как набор переменных простых типов. Создавая объектную систему на базе реляционной БД мы должны представить ее как совокупность переменных типа "отношение", поскольку это единтсвенный тип, реализуемый реляционными системами. Можем ли мы это сделать? А нормализация то на что нам дана? именно для этого. В результате нормализации мы и получаем требуемую струкутру атрибутов объекта.

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

Вот такой вот "глубинный смысл"....