to: Евгений Григорьев

Цитата

Она тоже требует тщательного прочтения. Но это Вам не грозит.

 Не надо заводить старого флеймера. Гвоздями к стенке прибью.
 Но лучше по существу вопроса.

Цитата

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

Отвечаю. Реляционная база в данном проекте на хрен никому не нужна. Почему она у меня есть? По одной простой причине: мне недосуг заниматься собственной основой. Поэтому я взял готовую, в виде давно написанного и вылизанного по быстродействию и надежности MySQL и написал то, чего не хватало. Что же касается настоящих коммерческих ОО баз, там у них внутри реляционной моделью с ее SQL даже не пахнет, а SQL интерфейс эмулируется для возможности быстрого переноса проектов. Получается куда быстрее.

Цитата

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

Статью я не пересказывал, а с ней полемизировал. Теперь объясняю. Тут читать очень внимательно. Потому что прошлый раз объяснение понято не было. Сущность "Вес" обладает атрибутами. В данном случае - это единица измерения. Точно так же, как стол обладает весом, вес обладает единицами измерения. Причем точно так же, как столовладелец обладает столом. Поэтому мы не можем делить вес и его стол на две принципиально разные группы. Начинающие программисты баз данных часто не понимают этого. И поэтому ситуация, когда какой-то объект, использовавшийся ранее в только качестве свойства, начинает иметь свои значащие аттрибуты, ставят их в тупик. Типичый пример: цена товара. Сделал такой программист базу, у товара есть цена, все работает. А потом потребовалось посмотреть статистику за три месяца, для которой накопительного счетчика не было. Ну, к примеру, коэффициент использования полок на складе, выраженный в рублях на погонный метр. И наступает большой Ёк. Почему? Потому что цена товара поменялась. А в базе цена - полем. И сидит программист и репу чешет, что делать. А делов-то всего - признать, что цена - это объект, сделать для цен таблицу и дать туда поля - значение, валюта, дата от и дата до. И мы можем наткнуться на эту ситуацию _в любом месте_. Именно поэтому вес у меня - объект. Сразу. И именно в этом одна из причин создания такой базы. Я написал и вот уже два года поддерживаю не самый мелкий в мире электронный магазин. Заказы тут идут мелкие, но часто, т.е. много часов может наблюдаться ситуация, когда в обработке  одновременно находится с десяток заказов. А при уплытии объектной модели (а она плывет непрерывно - это бизнес) надо менять поля. А изменение таблицы - это остановка сервера, потому что никто не может шариться по таблице из миллиона записей, которая прямо сейчас колбасится по alter table. А остановка сервера - это убытки. И причина - в негибкой реляционной парадигме. А в объектной модели мы не меняем никаких таблиц. Никогда. Даже если пользуемся ими в качестве хранилища.

Цитата

Несколько практических вопросов о  системе, созданной Вами. Заметьте, что я спрашиваю именно про систему хранения... про серверную компоненту (что бы было понятнее).

Независима ли она от использующей ее программы?
 Да. Даже в другом каталоге лежит.
Существет ли язык, описывающий ее и служащий для ее управления?
 OQL, примеры которого я приводил в прошлом письме. Похож на SQL - я сделал поблажку своей инерции мышления.

Храняться ли в ней метаданные (я имею в виду хотя бы описание структуры хранимых сложных объектов)?
 Сколько угодно. Стандарта типа DTD я не разрабатывал, но фактически пришел к тому, что кое-что храню. На основе этого делаются редакторы, к примеру.
$form=$shop->$part->createEditForm($object);
$form->printForm();
Вот так я показываю пользователю форму для редактирования любого объекта из базы. Оно берет описание из базы и по нему фигачит нужные поля.

Можно ли получить и изменить метаданные?
       write-only и read-only не предусмотрено.

Контролирует ли система то, что вносимые данные соответсвуют этим метаданным?
 Акститесь, как же на сайте магазина без этого? Впрочем, можно контролировать, можно не контролировать.

Контролирует ли система то, что при изменении метаданных существующие данные не будут противоречить внесенным изменениям?
 Не-а. Потребуется - напишу.

Реализует ли система хранения метаданных наследование и полиморфизм?
 Да, это используется во встроенном админе базы.

Реализует ли система хранения метаданных хранение методов? Возможно ли выполнение эти методов (на стороне сервере, конечно)?
 В процессе.

Если на эти вопросы Вы ответите утвердительно, то совершенно очевидно, что Ваша работа заслуживает самого пристального внимания.
 Сразу видно теоретика. Практик спросил бы: документация есть? Я ответил бы: НЕТ.

Цитата

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

Это от отсутствия практики, судя по всему. И не надо переносить на других свои мотивы. Уже то, что я вместо монстроузного бэк-оффиса из сотни страниц могу  использовать уже написанный OODB Admin, похожий на Проводник Windows как заспиртованный брат-близнец, и дописать пару специализированных страниц для менее продвинутых админов, типа начальства и девочек, что письма обрабатывают, уже оправдывает написание OODB. И миллион других аспектов, о которых теоретики просто понятия не имеют. Например, надо мне сейчас несколько индексов в таблицы добавить. (Кто хочет писать про плохое проектирование - лезть выше и читать три раза про изменение объектной модели). Мне придется сделать это завтра днем, в минимум заказов. А перед этим я сидел и разбирался с протоколом медленных запросов. И потратил я на это уже несколько часов. При чем тут OODB? Там такого случиться не могло. В принципе. Второй аспект из миллиона. Далее продолжать не буду - каждый вспомнит сам исходя из своего опыта.

WTB, программный монстр занимает 61K кода. Без ooforms - 49K. Сама основа, которую уже можно использовать (без OQL) - 20K в одном файле.

to: crimaniak
ОК!

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

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

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

Наконец. Я не хочу полемизировать.  Это про вес... и про цену (Я, опять же повторюсь. что как практику мне такие заморочки очень хорошо знакомы).... НО!.. Но почему вы упрямо хотите назвать вес объектом? Только потому, что он обладает атрибутами?  Но ведь отношения рел. модели тоже обладают атрибутами, то есть сложность и наличие атрибуты не могут являться критерием для того, что бы обозвать сущность объектом. Да - вес (цена) это сущность, это сущность со многиим атрибутами. Тем не менее для ее идентификации и сравнения необходимо и достаточно только ее ЯВНО ЗАДАННОЕ значения, каким бы сложным оно не было и какое бы число атрибутов (например "значение, валюта, дата от и дата до") - оно не включало. Именно поэтому я утверджаю, что это - НЕ ОБЪЕКТ и для описания цены или веса идельной является именно реляционная модель. Кстати, Вы пишите, что по-вашему для цен надо создавать отдельную таблицу, так ведь исходя из моих теоретических построения именно так и получится.

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

Цитата

Во-первых,  хочу придраться к фразе "МОДЕЛЬ ПЛЫВЕТ". МОДЕЛЬ НЕ МОЖЕТ ПЛЫТЬ! То что может плавать называется "схема данных, описывающая моделируемую предметную область реализованная в рамках модели данных".

 Да, я имел в виду схему данных.

Цитата

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

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

Цитата

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

Да я уже два длинных опуса написал на эту тему! Я уж не знаю, как еще объяснить, что унификация всех сущностей как объектов ведет к громадному упрощению объектной модели. Как ни крути, а объекты - это не более чем точки в многомерном гиперкубе их параметров, причем у этого пространства имеет место преобразование, когда бывшая ось становится точкой. И в реляционной модели мы эмулируем эту ситуацию при помощи отдельно взятых сечений, а в объектной непосредственно задаем. У нас есть три таблицы - поставщики, клиенты и товары. Мы взяли и сделали формочку на сайте для отзывов обо всем этом. Таблица для отзывов. Как будем связывать? А никак! Занимаемся эмуляцией. Вот поле типа - к чему относится отзыв, вот ID объекта в его таблице. Программа лезет в поле типа, а потом - банальный switch(). Есть такая проблема в OODB? Нет! Благодаря чему? Именно этому, "все есть объект". Вот захочу и выберу все объекты в базе, у которых вес - 20 кг, и которые синего цвета. Независимо от того, в какой ветке они лежат - столы это, клиенты с Марса или свадебные торты. Вот еще штука: когда я начал работать с OODB админом, выяснилось, что он легко дает всякого рода статистику, при помощи одной и той же страницы. Например, вогнал я туда рестораны Москвы - и могу сразу выбрать рестораны у данного метро или с данной кухней, или данной ценовой категории. Или посмотреть статистику значений любого свойства в базе (там легко ошибки вылавливать). В общем, бесполезно описывать, надо поработать...

А вот Вы почему упорно отрицаете подход, когда вес - тоже объект, несмотря на приведенные примеры его эффективности? По-моему, это гораздо более загадочное обстоятельство.

Цитата

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

В реляционной модели надо создавать таблицу. В объектной - не надо.

ОК!

С первым проехали

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

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

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

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

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

Цитата

А вот Вы почему упорно отрицаете подход, когда вес - тоже объект, несмотря на приведенные примеры его эффективности?

Потому, что модель должна адекватно описывать сущности предметной области. Пример на пальцах. Есть два яблока с одинаковым весом. Пусть вес в граммах. Вдумайтесь в фразу. Описываем. Пусть (как вы хотите) все объекты - два объекта и два атрибута - тоже объекта. Всего получили четыре объекта - два яблока и два веса. Вдумайтесь в то,что мы получили. Было три(!) сущности - два яблока и ОДИНАКОВЫЙ(один и тот же!) вес, а получили четыре объекта. А почему? Да потому что мы описали вес как объект, что подразумевает существование уникального объектного идентификатора OID (это основа объектной концепции!). Знаете принцип Оккама - "не умножай сущности сверх надобности"? Так вот - здесь мы его нарушили. И для того, что бы модель точно соответсвовала предметной области, с весом не надо ассоциировать никаких OID. А раз нет OID, то это уже не объект. Единственное, что нужно для описания и сравнеия ВЕСА - этоя его ЯВНО ЗАДАННОЕ значение, каким бы сложным оно не было (200,"граммы"). А это уже гораздо ближе к реляционной модели (прямо таки ее основа).

Кстати, исходя из моих построений "поставщики, клиенты и товары" так же бы ли бы объектами. Но вот такие вещи как вес, цена, адрес  - это НЕ ОБЪЕКТЫ. Разницу я объяснил.

Цитата

Я уж не знаю, как еще объяснить, что унификация всех сущностей как объектов ведет к громадному упрощению объектной модели.

Загадочная для меня фраза. Так Вы про модель или про схему? В любом случае в объектная концепция изначально подразумевает, что любая сущность описывается в виде объекта. Именно с этим я и спорю.

Тут Евгений Григорьев задал мне вопрос на личную почту: "Можно ли публиковать ссылки на эту обсуждаемую тему?".

Ответ: Можно и даже нужно! Можете давать ссылки на любые темы, на сам форум и его разделы, причём чем больше Вы их дадите, тем больше мы Вам будем благодарны. Вы также можете копировать с форума любую информацию и публиковать ее где угодно с условием что будет дана ссылка на форум. От таких действий форум только выиграет и мы будем надеятся что это приведёт новых посетителей.

r vs o опускаю, раз у нас реляционная модель - это одно, а базы на ее основе - это, оказывается, совсем другое. Сравнение с ассемблером правильное. Так же, как вредно программировать на ассемблере, так же и пользуясь реляционной парадигмой. Отмечу только распространенную ошибку: свойства, приписываемые ассемблеру, в большей мере относятся к программированию в кодах (хотя кто сейчас помнит ДВК-1, Б3-34 и прочее в этом роде?). В ассемблере у нас уже есть символические имена, структуры и прочие вещи, позволяющие нам абстрагироваться от линейной модели памяти.

Цитата

Потому, что модель должна адекватно описывать сущности предметной области. Пример на пальцах. Есть два яблока с одинаковым весом. Пусть вес в граммах. Вдумайтесь в фразу. Описываем. Пусть (как вы хотите) все объекты - два объекта и два атрибута - тоже объекта. Всего получили четыре объекта - два яблока и два веса. Вдумайтесь в то,что мы получили. Было три(!) сущности - два яблока и ОДИНАКОВЫЙ(один и тот же!) вес, а получили четыре объекта. А почему? Да потому что мы описали вес как объект, что подразумевает существование уникального объектного идентификатора OID (это основа объектной концепции!). Знаете принцип Оккама - "не умножай сущности сверх надобности"? Так вот - здесь мы его нарушили.

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

Код

[Яблоко1] ----<210>---->  [Вес] <-----<260>------ [Яблоко2]                            |                         <грамм>                            |                            v                   [Единица измерения]

Схема наверняка разъехалась, но я ничего не могу с этим сделать.
Намек веб-мастеру: "Код" предполагает моноширинный шрифт.

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

Цитата

Загадочная для меня фраза. Так Вы про модель или про схему? В любом случае в объектная концепция изначально подразумевает, что любая сущность описывается в виде объекта. Именно с этим я и спорю.

 "... о вкусе ананасов..." (с) Жванецкий.
Just try it!

to: crimaniak
OK!

Ну то, что реляционная модель и современные реляционные СУБД (точнее SQL-СУБД) имеют значительные (принципиальные!) несоответсвия - так это слава богу не моя мысль. Вот ссылка на сайт DataBase Debunking, где одним из авторов является Крис Дейт, очень известный спец.  и по реляционной модели и по БД вообще. Там очень много интересных материалов по данной теме.

Схему я посмотрел в правильном фонте. И возникли у меня вопросы.  Из схемы неясно, а что же является переменной для значений 210 или 260. Поясню. Есть такие фундаментальные понятия. Значение - это информация, а переменная - это ...ммм... место где эта информация находиться. В объектной концепции вполне четко звучит, что любая переменная - это объект. Вот у вас ЗНАЧЕНИЯ 260 и 210 они где? Переменные, содержащие их - это что? это объекты? Тогда у вас 5(!) объектов. Но если не объекты, а характеристики связи, т.е. ОТНОШЕНИЯ (англ: relation) между объектами,  то я хочу сказать вам следующее

1) Вы высказываете идеи, которые более 20 лет назад высказывались Румбаухом и ныне активно развиваются Дейтом (на том же сайте очень много инф. про это), и которые совсем НЕ противоречат реляционной модели. Его цитату по этому поводу я привожу в самом начале моей второй статьи. Вот она: "в реляционной модели не существует ничто, что может ограничить скалярные значения, существующие в доменах, … простыми формами. … эти скалярные значения могут быть настолько сложными насколько мы пожелаем". В данном случае мы говорим об отношении на доменах  "яблоки","значения","вес" и об отношении на доменах "вес","значение","единицы измерения". ИМХО Вы черезчур усложняете схему. Вот ситуация: один вес измеряется в граммах а другой - скажем в унциях . У меня это будет выглядеть так: яблоко1(200,"граммы"), яблоко2(500,"унции"). Но схема то не поменялась. А у Вас? Я что-то не могу понять, как она будет выглядеть (похоже должен появиться второй объект "вес", связанный через "унции" с "единицами измерения").

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

Наконец - так вы с чем спорите? - со моими построениями или с реляционной моделью? Если с реляционной моделью, то о ее выразительности и гибкости  я уже устал писать. Если с моими построениями, то я просто не буду вам пересказывать мои статьи - ну просмотрите вы их наконец. У меня все атрибуты каждого качества "вес", "адрес" да и любого другого качества, сколь угодоно сложного, ХРАНЯТЬСЯ в одной таблице для всех(любых) объектов (по таблице на качество: мы описывам качество - система создает таблицу). Мы можем обратимся к системе  с запросом, "дай мне все объекты с весом "500, унции" и она( в результате очень простого запроса к этой ОДНОЙ таблице) вернет все указатели (OID) любых объектов с таким весом, будь то "яблоки, груши, столы, торты или клиенты с марса".

Я очень люблю ананасы ;)

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

Цитата

ИМХО Вы черезчур усложняете схему. Вот ситуация: один вес измеряется в граммах а другой - скажем в унциях . У меня это будет выглядеть так: яблоко1(200,"граммы"), яблоко2(500,"унции"). Но схема то не поменялась. А у Вас? Я что-то не могу понять, как она будет выглядеть (похоже должен появиться второй объект "вес", связанный через "унции" с "единицами измерения").

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

Код

-Яблоко  +Вес ---<210>-->[Значение]    | <грамм>    |    v  [Единица измерения]

Стрелочки со значениями, как и раньше - это направленные связи, а расположение Веса с плюсом под яблоком с минусом эмулирует показ оного соотношения, если его записать в XML, а именно: Этот Вес - подобъект этого Яблока. (Помните, я писал, что объекты, помимо прочего, можно выстроить в дерево?)

BTW, по ссылкам у меня тоже можно "гулять" в обе стороны.

Цитата

Наконец - так вы с чем спорите? - со моими построениями или с реляционной моделью?

На всякий случай повторюсь еще раз: Вес есть объект

Настрелял скринов для облегчения понимания.

Вот типичный объект из базы: http://www.crimaniak.com/oodb/demo/object.gif
Слева подобъекты, справа свойства. И того и другого может не быть.

Вот оодв админ предлагает мне вводить свойства, исходя из принципа наследования: http://www.crimaniak.com/oodb/demo/propselect.gif

Вот что делаем, если свойство обладает вариантами: http://www.crimaniak.com/oodb/demo/propvar.gif

Это сразу позволяет нам иметь такие вещи, как: http://www.crimaniak.com/oodb/demo/ref1.gif
То же самое относится к любому подобному свойству: http://www.crimaniak.com/oodb/demo/ref2.gif

Во всех других раскладах мы, конечно, тоже можем получить это же, но тут это не возможность - тут это фундаментальное свойство.

Так же легко проводить анализ на правильность. Пожалуй, с этим свойством нам делать больше нечего:
http://www.crimaniak.com/oodb/demo/good_data.gif

А тут после скрипта, который все это выколупывал из экселя, явно требуется доработка напильником: http://www.crimaniak.com/oodb/demo/bad_data.gif

To crimaniak
ОК

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

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

Давайте на примере веса... в моем необъектном понимании. Я уже писал, но придется растолковать. Только читайте до конца и внимательно. Есть домен "значения". Есть домен "единицы измерения". На этих двух доменах установлено отношение называемое "вес". Значения кортежей этого отношения могут выглядеть следующим образом ("100", "граммы"), ("200", "граммы"), (200, "унции"). Заметьте, я говорю не о свойствах "вес в унциях" или "вес в граммах", а просто о свойстве "вес". Сравним два последних значения (200, "граммы") и (200,"унции"). Естественно они разные, потому как у них разные значения  атрибутов, определённый на домене "единицы измерения".... я надеюсь понятие домен Вам знакомо). Когда мы говорим про "вес в граммах", или "вес в унциях", мы товорим о подмножествах отношения "вес", определенных исходя из значений второго атрибута "единицы измерения" (естественно, эти подмножества не пересекаются....). Где ошибка?

Теперь рассмотрим качество вес, как атрибут объекта "яблоко". Схема выглядит так: Оя{...,(200, "граммы"),...} Здесь я показываю, что объект "яблоко" определяется многими качествами, в том числе и сложным качеством "вес". ). Тем самым определяется существование нового отношения  и его кортежа (Оя, 200, "граммы") и практически в таком виде мы и храним из в реляционной БД.

К чему я это? Да к тому же. Еще раз повторяю что мои построения позволяют реализовать любую схему, в том числе и Вашу. В Вашем случае домены "единицы измерения" и "значения" будут реализован как классы, а для хранения значений "граммы","унции" или 210, 260 будут создаваться специальные объекты. Соответсвенно кортеж отношения "вес" будет выглядеть как (о(200), о("граммы")). Вы хотите, что бы это значение - значение веса - так же хранилось как объект? Пожалуйста! В результате получим такую схему: ов(о(200), о("граммы"))...здесь  овз начит объект вес. И этот объект будет атрибутом яблока: Оя{...,ов(о(200), о("граммы")),...}. В целом нехило. Особенно если учеть, что все, что нам нужно - это два ЯВНО ЗАДАННЫХ значения (200, граммы). Помните принцип Оккама?

Почему я назвал ваше определение связи смутным? Внимание, цитата!...из Вашего раннего

Цитата

1. Всё есть недифференцированные объекты. 2. Свойство - троично. Оно есть отношение чего-то к чему-то и имеет какое-то значение.

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

А как же быть с таким качеством как "адрес"? там много полей и все они характеризуют отношение чегото к чему то. Это же придется создавать кучу объектов - "дома", "строения", "улицы", "переулки", "города","поселки", "деревни" и т.п. Попробуйте изобразить схему для свойсва "адрес" оставаясь  в рамках "третичности". Очень интересно, что получиться. На всякий случай привожу приблизительную схему для качества "адрес", исходя их моих построений: АДРЕС(страна, тип области, название области, тип нас.пункта, название нас.пункта,тип улицы, название улицы, номер дома, номер квартиры.), где "тип области"  ограничено перечислением "АО, область, республика..." и тд, тип города - перечислением "город, деревня" и тд, а тип улицы - перечислением "проспект, проезд, улица..." и тд.

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

Цитата

К сожалению - это только теория. Даже протипа нет, а могла бы классная штука получиться.

Меня впечатлила эта дискуссия. Было очень интересно и я склонен согласиться с Вашими доводоми. А поэтому может имеет смысл  совместными усилиями реализовать теорию в практику? Даже в качестве прототипа может получится довольно любопытный проект.

Цитата

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

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

Цитата

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

Увы, если прочтение моих предыдущих писем ничего не дало, тут я бессилен. Тем более что я никогда значение не называл связью. Кажется, Вы заквотили соответствующий фрагмент в последнем письме, не прочитав его. Потому что там явно написано иное. Разжую, кстати, ответы на вопросы (вот не думал, что это кому-то придется явно объяснять). "Чего-то" к "чему-то"  там - да, как раз объекты. И связь является переменной для значения. А соотношение веса к яблоку - действительно, отличается от обычных свойств, и у него нет значения, значащим является его наличие. Потому что это соотношение типа "part of.." Оно очень важно, так что я сделал поддержку его в базе. "Человек может оперировать только с тем, что может выстроить в иерархию". Вернемся к весу и прожуем его еще раз. Объект есть набор его свойств. А набор свойств есть объект. Можно заявить, что "не каждая рыба - селедка", но фишка в том, что это делать незачем. Это усложняет и лишает гибкости. Итак, во втором примере вес - не атомарен. Значит, это уже объект со всеми своими аттрибутами. У него есть два свойства - значение  и единица измерения. Вес-набор свойств является частью яблока как набора свойств. Что я отразил на схеме. Каждое значение атомарно, каждое свойство троично. Объект так сложен, сколько свойств для него напихаешь. Все.

Буду закругляться, потому что реплики типа {Попробуйте изобразить схему для свойства "адрес" оставаясь  в рамках "третичности".} показывают не то чтобы непонимание, а абсолютное непонимание. Ведь даже на скриншотах, которые я постил, есть пример с конкретно адресом. И из примеров в целом можно нарисовать схему данных, которую я использовал для адреса в той базе.

отдельная заметка "To: All"

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

Теперь расскажу про подводный камень, на который можно наткнуться далее.
Итак, все работает. Возникло искушение еще более упростить схему и оставить одну таблицу. Таблицу свойств. Ведь если мы все свойства объекта записываем связями, то что остается в самой таблице объектов? Ни-че-го! Только уникальный ID. А зачем нам куча записей с уникальными ID? Достаточно будет счетчика, который будет инкрементироваться при создании нового объекта, дабы не шариться по базе с MAX(ObjectID)+1 в поисках следующего номера. И наступает полная ляпота. Например, такая вот:

s t value
- - ----------
1 1 Название
2 1 Вес
3 1 Яблоко1
3 2 210
4 1 Яблоко2
4 2 260

Или такая вот:

s t value
- - -------------------
1 1 Название
2 1 Вес
3 1 Часть от
4 1 Значение
4 3 2
5 1 Единица измерения
5 3 2
6 1 Яблоко1
6 4 210
6 5 грамм
7 1 Яблоко2
7 4 10
7 5 унций

Но - увы и ах! Так мы сделать не можем. Точнее, можем, но получим одну интересную проблему из области ИИ (в том плане, что там подобные грабли двно известны) - у нас нет точки отсчета. То, что у нас получилось, называется "сетевая модель данных". Как верно заметил кто-то из авторитетных, "сетевая модель - хороший способ потерять Ваши данные". В данном случае любой пользователь может создать абсолютную копию имеющегося графа, и у нас не будет никаких критериев, чтобы отличить одно от другого. Или немного отличающуюся копию... Таким образом, нам надо забить где-то на графе гвоздь, который там покажет, что вот оно - начало. В живых нейронных сетях таким гвоздем являются ощущения "хорошо - плохо организму". Мы можем запомнить ID Названия и дальше плясать от него, к примеру. Но это плохо. Я опущу долгие разборки насчет путей решения этой проблемы, но кратко вывод получается следующий: легче оставить таблицу объектов и добавить туда ParentID, превратив модель в иерархическую. Это добавляет нам быстродействия и избавляет от головной боли по поводу целостности данных, репликации и прочих аспектов. И, что для современной базы немаловажно, дает однозначное соответствие с XML форматом. Базу легко импортировать-экспортировать частями-"ветками".

Успехов, короче.

то Crimaniak
ОК!
Согласен, надо сворачиваться. Но хотелось бы напоследок сказать пару слов

1)
[QУОТЕ]схема данных должна отражать предметную область. Я привел пример и нарисовал для него схему данных. Вы изменили этот пример и я привел для этого случая другую схему данных[/QУОТЕ]

Я бы сказал "пришлось менять схему, что бы впихнуть ее в парадигму". У меня схема данных НЕ меняется. Что есть гибче?

2)
[QУОТЕ]Тем более что я никогда значение не называл связью[/QУОТЕ]

...из раннего...

[QУОТЕ]210 и 260 - направленные связи между объектами. Или между тем, что я тут называю объектами[/QУОТЕ]

...и вдогонку...

Цитата

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

...а в следующем посте...

Цитата

Статью я не пересказывал, а с ней полемизировал.

Слов нет...

3)...о том, что Вы называете объектами
[QУОТЕ]Итак, во втором примере вес - не атомарен. Значит, это уже объект со всеми своими аттрибутами[/QУОТЕ]

Еще раз повторю, что НЕАТОМАРНОСТЬ и НАЛИЧИЕ АТРИБУТОВ не являтся признаком объекта. Отношения в реляционной модели тоже имеют атрибуты.

4) Кстати, об атомарных типах. Фактически это типы, определенные в системе хранения данных. Так вот, исходя из моих построений, где система хранения описывается реляционной моделью, любое отношение, каким бы сложным оно не было, является  по отношению к объектам атомарным типом (я называю в своей статье это базовым типом). То есть само по себе оно конечно сложное, но ПО ОТНОШЕНИЮ К ОБЪЕКТАМ оно есть базовый(атомарный) тип. Следовательно, в объектной системе может быть произвольное число базовых типов, описывающих ЯВНО ЗАДАВАЕМЫЕ значения. Но поскольку мы таки рабораем с железом, то эти ЯВНО ЗАДАВАЕМЫЕ сложные значения должны быть в конце-концов выражены в терминах аппартной системы хранения.

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

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

Цитата

Ну, на самом деле немного сложнее. Например, таблиц свойств столько, сколько типов свойств ты используешь, для эффективного индексирования. Использовал ты CHAR(12) - у тебя появилась таблица l_CHAR_12_, где все такие свойства и лежат.

(Кстати CHAR(12) уже есть сложный тип)

И у меня таблиц столько же сколько типов свойств я использую, но я не ограничиваюсь примитивными, аппартно-поддерживаемыми типами. - соответсвенно таблиц свойств у меня может быть сколь угодно много.  Значения свойств могут быть сколь угодно сложными, что позволяет отказаться от ненужных связей с ненужными объектами

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

Какая то беда с тегами приключилась. Предыдущее надо бы удалить

то Crimaniak
ОК!
Согласен, надо сворачиваться. Но хотелось бы напоследок сказать пару слов

1)

Цитата

схема данных должна отражать предметную область. Я привел пример и нарисовал для него схему данных. Вы изменили этот пример и я привел для этого случая другую схему данных

Я бы сказал "пришлось менять схему данных, что бы впихнуть ее в парадигму". У меня схема данных НЕ МЕНЯЕТСЯ. Вопрос - что есть гибче?

2)

Цитата

Тем более что я никогда значение не называл связью

...из раннего...

Цитата

... .210 и 260 - направленные связи между объектами. Или между тем, что я тут называю объектами.

...и тогда уж вдогонку...

Цитата

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

...а в следующем посте...

Цитата

Статью я не пересказывал, а с ней полемизировал.

...странно это все.

3)...о том, что Вы называете объектами

Цитата

Итак, во втором примере вес - не атомарен. Значит, это уже объект со всеми своими аттрибутами

Еще раз повторю, что НЕАТОМАРНОСТЬ и НАЛИЧИЕ АТРИБУТОВ не являтся признаком объекта. Отношения в реляционной модели тоже имеют атрибуты.

4) Кстати, об атомарных типах. Фактически это типы, определенные в системе хранения данных. Так вот, исходя из моих построений, где система хранения описывается реляционной моделью, любое отношение, каким бы сложным оно не было, является  по отношению к объектам атомарным типом (я называю в своей статье это базовым типом). То есть само по себе оно конечно сложное, но ПО ОТНОШЕНИЮ К ОБЪЕКТАМ оно есть базовый(атомарный) тип. Следовательно, в объектной системе может быть произвольное число базовых типов, описывающих ЯВНО ЗАДАВАЕМЫЕ значения. Но поскольку мы таки рабораем с железом, то эти ЯВНО ЗАДАВАЕМЫЕ сложные значения должны быть в конце-концов выражены в терминах аппартной системы хранения.

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

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

Цитата

Ну, на самом деле немного сложнее. Например, таблиц свойств столько, сколько типов свойств ты используешь, для эффективного индексирования. Использовал ты CHAR(12) - у тебя появилась таблица l_CHAR_12_, где все такие свойства и лежат.

(Кстати CHAR(12) уже есть сложный тип)

И у меня таблиц столько же сколько типов свойств я использую, но я не ограничиваюсь примитивными, аппартно-поддерживаемыми типами. - соответсвенно таблиц свойств у меня может быть сколь угодно много.  Значения свойств могут быть сколь угодно сложными, что позволяет отказаться от ненужных связей с ненужными объектами

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

Взаимно желаю удачи

To crimaniak
Я извиняюсь, что влезаю в вашу дискуссию. Сразу скажу что не обладаю такими знаниями в области объектных баз данных. Но просто хочу отметить одно противоречие

Цитата(crimaniak @ 30.7.2002, 20:29)

Например, таких, что схема данных должна отражать предметную область.

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

class Единица
{
 AnsiString Value;
};

class Значение
{
 double Value;
};

class Вес
{
 Единица*   ed; //указатель на объект единица
 Значение*  val; //указатель на объект значение
};
class Яблоко
{
 Вес* value; //указатель на объект
};

То есть все сводиться к агрегатированию классов. При этом непонятно с весом. В реалиях вес у яблока  один, но он может измеряться разных единицах
Я бы поступил по другому.
class Вес
{
private:
double Value; // значение в базовых  единицах
public:
double GetValue(); //значение в тех единицах , которые мы хотим получить
AnsiString  Ed;      // единица ихмерения          
};
Здесь Вес - некое понятие, выделенное в класс, которое ведет себя в соответствии с определенными правилами, т.е если я в Ed - задаю единицу, я получаю соответствующее значение веса. Теперь внимание:
class Яблоко: public Веc
{
Цвет соlor;
Сорт sort;
....
};
Ну добавим еще для примера
class Стол: public Вес
{
Форма form;
}
Вместо агрегатирование используется наследование.
Я использую класс Вес не для создания объктов, а для наследования от него. т.е я выделил понятие Вес в класс и в то же время сделал так что чистых объектов "Вес" не существует.В С++ имеются способы наложить такое ограничение. Теперь как это я бы наложил на реляционную БД

Таблица Вес
ID                                                      
Value
ClassID                                  

Taблица Яблоко                      
ID  
Цвет
Сорт                          
ВесID

Tаблица Стол
ID
Формв
ВесID

Здесь не хватает только таблицы классов
Classes
ID
ClassName
ClassTable

Ну а далее все просто. Для каждого класса создается вьюер. Если предполагается работа с определенным классом, то открывается вьюер, где имееются все столбцы данного класса. GetValue() для веса может быть реализована хранимой процедурой. Если предполагается работа с заранее неизвестным классом(например при реализации принципа глобального каталога), окрывается базовая таблица, определяется к какому классу принадлежит данный объект  и соответственно обращение пойдет к таблице соответствующего класса(реализация полиморфизма - базовый класс преобразуем в производный) .  Совсем нетрудно написать компонент(я работаю с С++Builder), который  реализует данный механизм на автомате.
При этом, как показывает практика, не нарушается принцип нормализации данных и добавление новых классов происходит безболезненно