![]() |
Модераторы: LSD |
![]() ![]() ![]() |
|
crimaniak |
|
||||||||||
Unregistered |
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 в одном файле. |
||||||||||
|
|||||||||||
Евгений Григорьев |
|
|||
Unregistered |
to: crimaniak
ОК! Как практик ( в наше время в нашей стране занятия чистой теорией дают чисто теоретичиеский ![]() Во-первых, хочу придраться к фразе "МОДЕЛЬ ПЛЫВЕТ". МОДЕЛЬ НЕ МОЖЕТ ПЛЫТЬ! То что может плавать называется "схема данных, описывающая моделируемую предметную область реализованная в рамках модели данных". Например: в рел. БД есть несколько таблиц описывающих склад. Описание этих таблиц и есть схема данных. Можно менять таблицы, можно добавлять новые, можете устанавливать новые связи - другими словами можно менять схему данных, но реляционная модель от этого не меняется и, всен эти изменения происходят в рамках реляционной модели. Точно так же и про объектную схему данных описывающих некий бизнес. Во-вторых. Реализация имеет такое же отнощение к модели как костер к формуле описываюшей окисление углерода. Вы же не будете утверждать, что дрова горят плохо горят из-за того, что формула горения неверна? Точно также не стоит утверждать, что в том, что для изменения таблицы надо останавливать сервер, виновата реляционная модель данных. ИМХО это абсурд. Вот фразу "рел. модель невыразительная" - это я еще понимаю... когда речь идет о попытках применить рел. модель для выражения некой предметной области ![]() Наконец. Я не хочу полемизировать. Это про вес... и про цену ![]() Но все это с теоретической точки зрения ![]() ![]() |
|||
|
||||
crimaniak |
|
||||||||
Unregistered |
Да, я имел в виду схему данных.
Нет, именно стоит. Потому что так дела и обстоят. Находясь в рамках данной аналогии, при реляционной модели я вынужден разбираться с формулой горения и рихтовать ее вручную, считая валентности, если мне для костра принесли другие дрова. При объектной - не должен. Там формула инкапсулирована и я ее не вижу. И знать про нее ничего не хочу!
Да я уже два длинных опуса написал на эту тему! Я уж не знаю, как еще объяснить, что унификация всех сущностей как объектов ведет к громадному упрощению объектной модели. Как ни крути, а объекты - это не более чем точки в многомерном гиперкубе их параметров, причем у этого пространства имеет место преобразование, когда бывшая ось становится точкой. И в реляционной модели мы эмулируем эту ситуацию при помощи отдельно взятых сечений, а в объектной непосредственно задаем. У нас есть три таблицы - поставщики, клиенты и товары. Мы взяли и сделали формочку на сайте для отзывов обо всем этом. Таблица для отзывов. Как будем связывать? А никак! Занимаемся эмуляцией. Вот поле типа - к чему относится отзыв, вот ID объекта в его таблице. Программа лезет в поле типа, а потом - банальный switch(). Есть такая проблема в OODB? Нет! Благодаря чему? Именно этому, "все есть объект". Вот захочу и выберу все объекты в базе, у которых вес - 20 кг, и которые синего цвета. Независимо от того, в какой ветке они лежат - столы это, клиенты с Марса или свадебные торты. Вот еще штука: когда я начал работать с OODB админом, выяснилось, что он легко дает всякого рода статистику, при помощи одной и той же страницы. Например, вогнал я туда рестораны Москвы - и могу сразу выбрать рестораны у данного метро или с данной кухней, или данной ценовой категории. Или посмотреть статистику значений любого свойства в базе (там легко ошибки вылавливать). В общем, бесполезно описывать, надо поработать... А вот Вы почему упорно отрицаете подход, когда вес - тоже объект, несмотря на приведенные примеры его эффективности? По-моему, это гораздо более загадочное обстоятельство.
В реляционной модели надо создавать таблицу. В объектной - не надо. |
||||||||
|
|||||||||
Евгений Григорьев |
|
||||
Unregistered |
ОК!
С первым проехали ![]() Второе (кстати на основе первого). То, что инкапсулировано в объектах - это описание схемы данных в рамках модели. Меняя схему данных в реляционной модели вы (всего лишь!) меняете схему данных, но не саму модель. В теории рел БД есть такие вещи как домен, отношение и операции над отношениями - и это все(!), чем оперирует реляционная модель. В книге "Теория реляционных БД" написанной на более чем 400-х станицах нет ни слова о такой штуке как "сервер", и о такой операции как "остановка сервера". Да, реляционную модель называют невыразительной, но это только потому, что ИМХО от нее требуют большего, чем то, на что она реально рассчитана. Да. говорят про "потерю семантики", но ИМХО не модель тому причиной, а глобальное непонимание того, что семантика - это в принципе такие же данные (во-всяком случае она кодируется значеними...словами ![]() Как бы это объяснить на пальцах? Вот есть память (компьютерное ОЗУ) про которую можно сказать, что она линейная. Единственная ее задача - хранить данные и с этой задачей она справлется достаточно хорошо. Она действительно хранит данные, и код, оперирующий над этими данными . Заметьте, никто не требует, что бы эта линейная память была выразительной и служила для описания моделируемой предметной области. Это ОЗУ можно назвать системой. Информация в этой системе храниться в ....ну назовем это ячейками памяти. Раньше (давным-давно, во времена ассемблеров ![]() ИМХО беда в том, что Вы (и не только Вы ![]() Если во все вышесказанное въехать, то дальнейшии споры насчет невыразительности объектной модели станут просто ненужными. Мы же не требуем выразительности от ассемблера, но он прекрасно подходит для манипуляций с ОЗУ. Точно так же реляционная модель невыразительна когда речь идет о описании предметной области, но она шикарно(математически строго) описывает систему хранения. Вы поймите, все ваши сетования относятся к РЕАЛИЗАЦИИ, а я говорю про модель. Я утверждаю и буду утверждать "рел. модель форевэ" ![]()
Потому, что модель должна адекватно описывать сущности предметной области. Пример на пальцах. Есть два яблока с одинаковым весом. Пусть вес в граммах. Вдумайтесь в фразу. Описываем. Пусть (как вы хотите) все объекты - два объекта и два атрибута - тоже объекта. Всего получили четыре объекта - два яблока и два веса. Вдумайтесь в то,что мы получили. Было три(!) сущности - два яблока и ОДИНАКОВЫЙ(один и тот же!) вес, а получили четыре объекта. А почему? Да потому что мы описали вес как объект, что подразумевает существование уникального объектного идентификатора OID (это основа объектной концепции!). Знаете принцип Оккама - "не умножай сущности сверх надобности"? Так вот - здесь мы его нарушили. И для того, что бы модель точно соответсвовала предметной области, с весом не надо ассоциировать никаких OID. А раз нет OID, то это уже не объект. Единственное, что нужно для описания и сравнеия ВЕСА - этоя его ЯВНО ЗАДАННОЕ значение, каким бы сложным оно не было (200,"граммы"). А это уже гораздо ближе к реляционной модели (прямо таки ее основа). Кстати, исходя из моих построений "поставщики, клиенты и товары" так же бы ли бы объектами. Но вот такие вещи как вес, цена, адрес - это НЕ ОБЪЕКТЫ. Разницу я объяснил.
Загадочная для меня фраза. Так Вы про модель или про схему? В любом случае в объектная концепция изначально подразумевает, что любая сущность описывается в виде объекта. Именно с этим я и спорю. |
||||
|
|||||
Vit |
|
|||
![]() Vitaly Nevzorov ![]() ![]() ![]() ![]() Профиль Группа: Экс. модератор Сообщений: 10964 Регистрация: 25.3.2002 Где: Chicago Репутация: 14 Всего: 207 |
Тут Евгений Григорьев задал мне вопрос на личную почту: "Можно ли публиковать ссылки на эту обсуждаемую тему?".
Ответ: Можно и даже нужно! Можете давать ссылки на любые темы, на сам форум и его разделы, причём чем больше Вы их дадите, тем больше мы Вам будем благодарны. Вы также можете копировать с форума любую информацию и публиковать ее где угодно с условием что будет дана ссылка на форум. От таких действий форум только выиграет и мы будем надеятся что это приведёт новых посетителей. -------------------- With the best wishes, Vit I have done so much with so little for so long that I am now qualified to do anything with nothing Самый большой Delphi FAQ на русском языке здесь: www.drkb.ru |
|||
|
||||
crimaniak |
|
||||||
Unregistered |
r vs o опускаю, раз у нас реляционная модель - это одно, а базы на ее основе - это, оказывается, совсем другое. Сравнение с ассемблером правильное. Так же, как вредно программировать на ассемблере, так же и пользуясь реляционной парадигмой. Отмечу только распространенную ошибку: свойства, приписываемые ассемблеру, в большей мере относятся к программированию в кодах (хотя кто сейчас помнит ДВК-1, Б3-34 и прочее в этом роде?). В ассемблере у нас уже есть символические имена, структуры и прочие вещи, позволяющие нам абстрагироваться от линейной модели памяти.
Уровень непонимания высок, но я попробую еще раз. В оодв у нас было три объекта - и осталось три объекта! (а всего лишь - надо было внимательно прочитать описание реализации). Именно так. И два линка между ними. Обладающие свойством. Атомарным, кстати. Вот так, в верхней строчке:
Схема наверняка разъехалась, но я ничего не могу с этим сделать. Намек веб-мастеру: "Код" предполагает моноширинный шрифт. И сколько бы у нас объектов и каких бы классов ни было бы, нам нужен только один объект "Вес", чего совершенно нельзя сказать о реляционной реализации. Там нам придется делать поле "вес" у яблок, у груш, у столов, у тортов и у клиентов с марса, поскольку у них разные аттрибуты и нам приходится пихать их в разные таблицы. Да еще получать проблемы с единицами измерения (в самом простом случае).
"... о вкусе ананасов..." (с) Жванецкий. ![]() Just try it! |
||||||
|
|||||||
Евгений Григорьев |
|
|||
Новичок Профиль Группа: Участник Сообщений: 9 Регистрация: 23.7.2002 Репутация: нет Всего: нет |
to: crimaniak
OK! Ну то, что реляционная модель и современные реляционные СУБД (точнее SQL-СУБД) имеют значительные (принципиальные!) несоответсвия - так это слава богу не моя мысль. Вот ссылка на сайт DataBase Debunking, где одним из авторов является Крис Дейт, очень известный спец. и по реляционной модели и по БД вообще. Там очень много интересных материалов по данной теме. Схему я посмотрел в правильном фонте. И возникли у меня вопросы. Из схемы неясно, а что же является переменной для значений 210 или 260. Поясню. Есть такие фундаментальные понятия. Значение - это информация, а переменная - это ...ммм... место где эта информация находиться. В объектной концепции вполне четко звучит, что любая переменная - это объект. Вот у вас ЗНАЧЕНИЯ 260 и 210 они где? Переменные, содержащие их - это что? это объекты? Тогда у вас 5(!) объектов. Но если не объекты, а характеристики связи, т.е. ОТНОШЕНИЯ (англ: relation) между объектами, то я хочу сказать вам следующее 1) Вы высказываете идеи, которые более 20 лет назад высказывались Румбаухом и ныне активно развиваются Дейтом (на том же сайте очень много инф. про это), и которые совсем НЕ противоречат реляционной модели. Его цитату по этому поводу я привожу в самом начале моей второй статьи. Вот она: "в реляционной модели не существует ничто, что может ограничить скалярные значения, существующие в доменах, … простыми формами. … эти скалярные значения могут быть настолько сложными насколько мы пожелаем". В данном случае мы говорим об отношении на доменах "яблоки","значения","вес" и об отношении на доменах "вес","значение","единицы измерения". ИМХО Вы черезчур усложняете схему. Вот ситуация: один вес измеряется в граммах а другой - скажем в унциях ![]() 2) Возможно Вам это покажеться странным, но то, что вы говорите,является ЧАСТНЫМ случаем моих постоений. Понимаете, они позволяют реализовать любую схему, в том числе и вашу. Еще раз говорю - мои построения теоретические, хотя и приводят к достаточно простой и однозначной практической реализации. Я тоже могу создать классы "явлоки","вес", "единицы измерения" и строить отношения между ними (которые кстати у меня хотя и направлены, но.... одновременно и ненаправлены, и поэтому по ссылкам я могу гулять туда и обратно ![]() Наконец - так вы с чем спорите? - со моими построениями или с реляционной моделью? Если с реляционной моделью, то о ее выразительности и гибкости я уже устал писать. Если с моими построениями, то я просто не буду вам пересказывать мои статьи - ну просмотрите вы их наконец. У меня все атрибуты каждого качества "вес", "адрес" да и любого другого качества, сколь угодоно сложного, ХРАНЯТЬСЯ в одной таблице для всех(любых) объектов (по таблице на качество: мы описывам качество - система создает таблицу). Мы можем обратимся к системе с запросом, "дай мне все объекты с весом "500, унции" и она( в результате очень простого запроса к этой ОДНОЙ таблице) вернет все указатели (OID) любых объектов с таким весом, будь то "яблоки, груши, столы, торты или клиенты с марса". Я очень люблю ананасы ;) |
|||
|
||||
crimaniak |
|
||||||
Unregistered |
Не знаю ничего про Криса Дейта (мне Ваших писем хватает пока), но назвать мою базу реляционной - это круто. Судя по всему, употребляемая Вами терминология сильно отличается от общеупотребительной. (Собственно, исходя из написанного в последнем письме, получается, что любая база - реляционная). Теперь о примерах. 210 и 260 - направленные связи между объектами. Или между тем, что я тут называю объектами. Как хотите.
Про Румбауха.
Правильно не можете, потому что сделали ошибку. Даже как-то неудобно об этом писать, в школе вроде все это проходят. Но вес в граммах и вес в унциях - это два разных свойства. На что явно указывает возникшее перед вами затруднение. В своем же варианте модели Вы, ничтоже сумняшеся, пихаете их в одну таблицу, и Ваша модель никак не помогает понять сделанную ошибку. Что есть плохо. Я такой вариант уже реализовал в сайте одного из клиентов. Там тоже свойства были сложносочиненными. После чего я пошел дальше и логически завершил этот подход, сделав значения свойств атомарными. Что избавило меня от некоторых принципиальных проблем. Таким образом, мой подход не сложнее, как показывают Ваши предположения, а проще, как показывает моя практика. Как выглядит данный пример в моей модели? Ну, начнем с того, что пример неудачный, так как в данном случае я бы приводил вес к общим единицам измерения. Но если у нас есть действительно сложносочиненное "свойство", то модель заставляет нас описывать его правильно, а именно - вот так:
Стрелочки со значениями, как и раньше - это направленные связи, а расположение Веса с плюсом под яблоком с минусом эмулирует показ оного соотношения, если его записать в 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 |
||||||
|
|||||||
Евгений Григорьев |
|
|||
Новичок Профиль Группа: Участник Сообщений: 9 Регистрация: 23.7.2002 Репутация: нет Всего: нет |
To crimaniak
ОК Возникает ощущение, что вы видите в моих ответах только то, что вам нужно. Или, по крайней мере, не читаете их внимательно (к тому же в прошлой схеме стрелочка шла от яблока через 210 к весу, а в последней - от веса через 210 к значению, что есть немножко совсем по разному. Вы бы определились однозначно, как Ваша схема выглядит). Вы так и не сказали, что является переменной для значения "210". Вы обзываете это "направленной связью между объектами"? Связь - это не переменная. И кроме того, я первый раз слышу, что числовое значение - это связь. Извините,"даже как-то неудобно об этом писать", но связь возникает между чем-то и чем-то, а целочисленное значение связью быть не может - или это вам в школе не объяснили? Далее - я никогда не говорил, что ваша БД - реляционная... (или Вы опять скажете, что "просто полемизируете"?). Я сказал совсем другое (если Вы меня именно так поняли, то тогда мне вообще неясно, о чем спор. Я использую общепринятые термины, но, к сожалению, не уверен в том, что они Вам ясны). Я сказал, что то ваше смутное определение связи очень хорошо описывается в терминах отношений. Давайте на примере веса... в моем необъектном понимании. Я уже писал, но придется растолковать. Только читайте до конца и внимательно. Есть домен "значения". Есть домен "единицы измерения". На этих двух доменах установлено отношение называемое "вес". Значения кортежей этого отношения могут выглядеть следующим образом ("100", "граммы"), ("200", "граммы"), (200, "унции"). Заметьте, я говорю не о свойствах "вес в унциях" или "вес в граммах", а просто о свойстве "вес". Сравним два последних значения (200, "граммы") и (200,"унции"). Естественно они разные, потому как у них разные значения атрибутов, определённый на домене "единицы измерения".... я надеюсь понятие домен Вам знакомо). Когда мы говорим про "вес в граммах", или "вес в унциях", мы товорим о подмножествах отношения "вес", определенных исходя из значений второго атрибута "единицы измерения" (естественно, эти подмножества не пересекаются....). Где ошибка? Теперь рассмотрим качество вес, как атрибут объекта "яблоко". Схема выглядит так: Оя{...,(200, "граммы"),...} Здесь я показываю, что объект "яблоко" определяется многими качествами, в том числе и сложным качеством "вес". ). Тем самым определяется существование нового отношения и его кортежа (Оя, 200, "граммы") и практически в таком виде мы и храним из в реляционной БД. К чему я это? Да к тому же. Еще раз повторяю что мои построения позволяют реализовать любую схему, в том числе и Вашу. В Вашем случае домены "единицы измерения" и "значения" будут реализован как классы, а для хранения значений "граммы","унции" или 210, 260 будут создаваться специальные объекты. Соответсвенно кортеж отношения "вес" будет выглядеть как (о(200), о("граммы")). Вы хотите, что бы это значение - значение веса - так же хранилось как объект? Пожалуйста! В результате получим такую схему: ов(о(200), о("граммы"))...здесь овз начит объект вес. И этот объект будет атрибутом яблока: Оя{...,ов(о(200), о("граммы")),...}. В целом нехило. Особенно если учеть, что все, что нам нужно - это два ЯВНО ЗАДАННЫХ значения (200, граммы). Помните принцип Оккама? Почему я назвал ваше определение связи смутным? Внимание, цитата!...из Вашего раннего
Определите пожалуста, что Вы подразумеваете под этим "чем-то". Объекты? Взгляните на последнюю схему. Вес в данном случае - это отношения к "значению" с значением 210, или же это отношение к "единицам измерения" с значением "граммы"? Но если это и то и другое, то он уже пятиричен?... или он все лишь четверичен, но таки имеет неатомарное значение (210, "граммы")? Сам вес - это объект? Значит есть связь между объектом "яблоко" и объектом "вес" (они же связаны, в конце концов)....но эта связь не есть свойство, ведь у нее отсутсвует собственной значение... Или же вес - это не объект? Но тогда(третий раз спрашиваю) что это? А как же быть с таким качеством как "адрес"? там много полей и все они характеризуют отношение чегото к чему то. Это же придется создавать кучу объектов - "дома", "строения", "улицы", "переулки", "города","поселки", "деревни" и т.п. Попробуйте изобразить схему для свойсва "адрес" оставаясь в рамках "третичности". Очень интересно, что получиться. На всякий случай привожу приблизительную схему для качества "адрес", исходя их моих построений: АДРЕС(страна, тип области, название области, тип нас.пункта, название нас.пункта,тип улицы, название улицы, номер дома, номер квартиры.), где "тип области" ограничено перечислением "АО, область, республика..." и тд, тип города - перечислением "город, деревня" и тд, а тип улицы - перечислением "проспект, проезд, улица..." и тд. Наконец. Вы бы все же определии глобальную идею Вашей активности. Идею своих выступлений я определил давно - объектное представление данных не противоречит их реляционному хранению и противопоставление объектных и реляционных систем лишено всякого смысла (как я ранее писал, это подобно сравнению оператвной памяти и объектной программы). Вы то что хотите сказать? |
|||
|
||||
Vyacheslav |
|
|||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Экс. модератор Сообщений: 2124 Регистрация: 25.3.2002 Где: Москва Репутация: нет Всего: 59 |
Меня впечатлила эта дискуссия. Было очень интересно и я склонен согласиться с Вашими доводоми. А поэтому может имеет смысл совместными усилиями реализовать теорию в практику? Даже в качестве прототипа может получится довольно любопытный проект. -------------------- С уважением, Вячеслав Ермолаев |
|||
|
||||
crimaniak |
|
||||
Unregistered |
Это "противоречие" у Вас от непонимания простейших вещей. Например, таких, что схема данных должна отражать предметную область. Я привел пример и нарисовал для него схему данных. Вы изменили этот пример и я привел для этого случая другую схему данных.
Увы, если прочтение моих предыдущих писем ничего не дало, тут я бессилен. Тем более что я никогда значение не называл связью. Кажется, Вы заквотили соответствующий фрагмент в последнем письме, не прочитав его. Потому что там явно написано иное. Разжую, кстати, ответы на вопросы (вот не думал, что это кому-то придется явно объяснять). "Чего-то" к "чему-то" там - да, как раз объекты. И связь является переменной для значения. А соотношение веса к яблоку - действительно, отличается от обычных свойств, и у него нет значения, значащим является его наличие. Потому что это соотношение типа "part of.." Оно очень важно, так что я сделал поддержку его в базе. "Человек может оперировать только с тем, что может выстроить в иерархию". Вернемся к весу и прожуем его еще раз. Объект есть набор его свойств. А набор свойств есть объект. Можно заявить, что "не каждая рыба - селедка", но фишка в том, что это делать незачем. Это усложняет и лишает гибкости. Итак, во втором примере вес - не атомарен. Значит, это уже объект со всеми своими аттрибутами. У него есть два свойства - значение и единица измерения. Вес-набор свойств является частью яблока как набора свойств. Что я отразил на схеме. Каждое значение атомарно, каждое свойство троично. Объект так сложен, сколько свойств для него напихаешь. Все. Буду закругляться, потому что реплики типа {Попробуйте изобразить схему для свойства "адрес" оставаясь в рамках "третичности".} показывают не то чтобы непонимание, а абсолютное непонимание. Ведь даже на скриншотах, которые я постил, есть пример с конкретно адресом. И из примеров в целом можно нарисовать схему данных, которую я использовал для адреса в той базе. |
||||
|
|||||
crimaniak |
|
|||
Unregistered |
отдельная заметка "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 форматом. Базу легко импортировать-экспортировать частями-"ветками". Успехов, короче. ![]() |
|||
|
||||
Евгений Григорьев |
|
||||||
Новичок Профиль Группа: Участник Сообщений: 9 Регистрация: 23.7.2002 Репутация: нет Всего: нет |
то Crimaniak
ОК! Согласен, надо сворачиваться. Но хотелось бы напоследок сказать пару слов 1) [QУОТЕ]схема данных должна отражать предметную область. Я привел пример и нарисовал для него схему данных. Вы изменили этот пример и я привел для этого случая другую схему данных[/QУОТЕ] Я бы сказал "пришлось менять схему, что бы впихнуть ее в парадигму". У меня схема данных НЕ меняется. Что есть гибче? 2) [QУОТЕ]Тем более что я никогда значение не называл связью[/QУОТЕ] ...из раннего... [QУОТЕ]210 и 260 - направленные связи между объектами. Или между тем, что я тут называю объектами[/QУОТЕ] ...и вдогонку...
...а в следующем посте...
Слов нет... 3)...о том, что Вы называете объектами [QУОТЕ]Итак, во втором примере вес - не атомарен. Значит, это уже объект со всеми своими аттрибутами[/QУОТЕ] Еще раз повторю, что НЕАТОМАРНОСТЬ и НАЛИЧИЕ АТРИБУТОВ не являтся признаком объекта. Отношения в реляционной модели тоже имеют атрибуты. 4) Кстати, об атомарных типах. Фактически это типы, определенные в системе хранения данных. Так вот, исходя из моих построений, где система хранения описывается реляционной моделью, любое отношение, каким бы сложным оно не было, является по отношению к объектам атомарным типом (я называю в своей статье это базовым типом). То есть само по себе оно конечно сложное, но ПО ОТНОШЕНИЮ К ОБЪЕКТАМ оно есть базовый(атомарный) тип. Следовательно, в объектной системе может быть произвольное число базовых типов, описывающих ЯВНО ЗАДАВАЕМЫЕ значения. Но поскольку мы таки рабораем с железом, то эти ЯВНО ЗАДАВАЕМЫЕ сложные значения должны быть в конце-концов выражены в терминах аппартной системы хранения. В результате получается такая штука - класс есть атомарный тип для создания отношения (помните цитату из Дейта?), а отношение есть атомарный тип для создания класса. Началом цепочки являются ПРИМИТИВНЫЕ типы, поддерживаемые аппаратной системой хранения и фактически описывающие примитивные объекты этой системы хранения (те самые ячейки памяти). А вот дальше эта цепочка может быть расручена до бесконечности, поскольку любой созданный объект хранит данные и так же может входить в кортеж отношения. Вы же ставите знак равенства между "базовыми"(логическое понятие) и "примитивными"(аппартно-поддерживаемыми) типами. Я хотел бы обратить внимание на Вашу фразу из раннего
(Кстати CHAR(12) уже есть сложный тип) И у меня таблиц столько же сколько типов свойств я использую, но я не ограничиваюсь примитивными, аппартно-поддерживаемыми типами. - соответсвенно таблиц свойств у меня может быть сколь угодно много. Значения свойств могут быть сколь угодно сложными, что позволяет отказаться от ненужных связей с ненужными объектами 5) ...то есть добавляя информацию о адресе вам приходиться делать столько операций вставки в таблицу свойств, сколько в адресе полей, причем еще необходимо контролировать, что бы эти верно записи были связаны с объектами-названиями (дом, улица т т.д.)? Вы называете это эффективностью? (исходя из моих построений адрес будет добавляться одной операцией вставки в соответсвующую таблицу свойств). |
||||||
|
|||||||
Евгений Григорьев |
|
||||||||||||||
Новичок Профиль Группа: Участник Сообщений: 9 Регистрация: 23.7.2002 Репутация: нет Всего: нет |
Какая то беда с тегами приключилась. Предыдущее надо бы удалить
то Crimaniak ОК! Согласен, надо сворачиваться. Но хотелось бы напоследок сказать пару слов 1)
Я бы сказал "пришлось менять схему данных, что бы впихнуть ее в парадигму". У меня схема данных НЕ МЕНЯЕТСЯ. Вопрос - что есть гибче? 2)
...из раннего...
...и тогда уж вдогонку...
...а в следующем посте...
...странно это все. 3)...о том, что Вы называете объектами
Еще раз повторю, что НЕАТОМАРНОСТЬ и НАЛИЧИЕ АТРИБУТОВ не являтся признаком объекта. Отношения в реляционной модели тоже имеют атрибуты. 4) Кстати, об атомарных типах. Фактически это типы, определенные в системе хранения данных. Так вот, исходя из моих построений, где система хранения описывается реляционной моделью, любое отношение, каким бы сложным оно не было, является по отношению к объектам атомарным типом (я называю в своей статье это базовым типом). То есть само по себе оно конечно сложное, но ПО ОТНОШЕНИЮ К ОБЪЕКТАМ оно есть базовый(атомарный) тип. Следовательно, в объектной системе может быть произвольное число базовых типов, описывающих ЯВНО ЗАДАВАЕМЫЕ значения. Но поскольку мы таки рабораем с железом, то эти ЯВНО ЗАДАВАЕМЫЕ сложные значения должны быть в конце-концов выражены в терминах аппартной системы хранения. В результате получается такая штука - класс есть атомарный тип для создания отношения (помните цитату из Дейта?), а отношение есть атомарный тип для создания класса. Началом цепочки являются ПРИМИТИВНЫЕ типы, поддерживаемые аппаратной системой хранения и фактически описывающие примитивные объекты этой системы хранения (те самые ячейки памяти). А вот дальше эта цепочка может быть расручена до бесконечности, поскольку любой созданный объект хранит данные и так же может входить в кортеж отношения. Вы же ставите знак равенства между "базовыми"(логическое понятие) и "примитивными"(аппартно-поддерживаемыми) типами. Я хотел бы обратить внимание на Вашу фразу из раннего
(Кстати CHAR(12) уже есть сложный тип) И у меня таблиц столько же сколько типов свойств я использую, но я не ограничиваюсь примитивными, аппартно-поддерживаемыми типами. - соответсвенно таблиц свойств у меня может быть сколь угодно много. Значения свойств могут быть сколь угодно сложными, что позволяет отказаться от ненужных связей с ненужными объектами 5) ...то есть добавляя информацию о адресе вам приходиться делать столько операций вставки в таблицу свойств, сколько в адресе полей, причем еще необходимо контролировать, что бы эти верно записи были связаны с объектами-названиями (дом, улица т т.д.)? Вы называете это эффективностью? (исходя из моих построений адрес будет добавляться одной операцией вставки в соответсвующую таблицу свойств). Взаимно желаю удачи ![]() |
||||||||||||||
|
|||||||||||||||
Vyacheslav |
|
|||
Эксперт ![]() ![]() ![]() ![]() Профиль Группа: Экс. модератор Сообщений: 2124 Регистрация: 25.3.2002 Где: Москва Репутация: нет Всего: 59 |
To crimaniak
Я извиняюсь, что влезаю в вашу дискуссию. Сразу скажу что не обладаю такими знаниями в области объектных баз данных. Но просто хочу отметить одно противоречие
С этим трудно не согласиться. Но ранее Вы утверждали, что "Вес -это объект".Но это не отражает предметную область. В Вашем примере есть объект - "Яблоко", но в реалиях не может существовать отдельно объекта "Вес". Рассуждая таким образом, надо идти дальше - должен быть объект "Значение" и объект "Единица измерения". Если взять ООП(это мне ближе) , то в нем различают прежде всего классы и экземпляры классов и совсем необязательно чтобы по каждому классу предполагалось создание объекта. Если я попытаюсь реализовать вышу схему в ООП, то я буду вынужден сделать примерно следущее 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), который реализует данный механизм на автомате. При этом, как показывает практика, не нарушается принцип нормализации данных и добавление новых классов происходит безболезненно -------------------- С уважением, Вячеслав Ермолаев |
|||
|
||||
![]() ![]() ![]() |
Правила форума "Общие вопросы по базам данных" | |
|
Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:
Данный форум не предназначен для:
Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение.
Полезные советы: Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa. |
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | СУБД, общие вопросы | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |