Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 11 12 13 14 15 [16] 17 18 19 20 .. 83   вперед  Ctrl
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 vadiminfo

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

автор

Это не исключает естественных требований к ее адекватности (выразительности).


Можно подробнее про то как такой параметр как выразительность связан с адекватностью ? ИМХО, но выразительность весьма и весьма субъективный параметр.

автор

Можно вообще вспомнить, что существуют попытки создать базы знаний, которые потребуют не только своих моделий, но вычислительных систем. Так, если не обращать внимания на нейронные сети, о все компы - алгоритмические. А понадобятся системы искусственного интеллекта.


Согласен с утверждением полностью - попытки содать базы знаний пока всё ещё попытки , но вот только нейронные сети - это ведь тоже алгоритмическая система и чётко формализованная при этом.

автор

Это семантичность модели. Она тоже имеет большое значение. Так одним из недостатков реляционной является семантическая перегруженность (я писал выше).


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

автор

Про изображения. Хранить то можно, но как одно значение - неделимое. Но в модели еще есть операции и ограничения целостности.


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

автор

Например, нужно получать информацию о возможных маршрутах на основе анализа местности. Но у реляционной модели для этого ничего нет.


А вот тут вы путайте АЛГОРИТМ (набор операций над данными) и сами данные, почему реляционная модель должна уметь решать задачу о возможных маршрутах ? Какие ещё топологические задачи она должна уметь решать ? Почему ? ИМХО, но это рел. модель и придумана она для хранения и извлечения данных, а в каких алгоритмах вы будете использовать эти данные и с какой целью, вряд ли рел. модель (да и любая другая) сможет предугадать.

автор

Но ведь это все избитые истины. Они не оспариваются сторонниками реляционной модели. Потому и появилость понятие объектно-реляционной модели.


Какие именно ? Семантическая избыточность ? Безусловно есть и не оспаривается, но это не недостаток, а скорее достоинство, позволяющее использовать рел. модель для различного круга задач.
7 июн 04, 15:40    [726433]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
автор

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

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

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

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

Можно подробнее про то как такой параметр как выразительность связан с адекватностью ?

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

автор

только нейронные сети - это ведь тоже алгоритмическая система и чётко формализованная при этом

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

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

Ну, если не понятно, что за данные в БД (семантичность), то адекватно в ней отражается ПО? Мне кажется, не совсем адекватно. Все-таки интерпретация данных имеет значение.
автор

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

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

Какие именно ? Семантическая избыточность ? Безусловно есть и не оспаривается, но это не недостаток, а скорее достоинство, позволяющее использовать рел. модель для различного круга задач.

Избыточность сама по себе без относительно других вопросов не является достоинством. Иначе, зачем такой неблагозвучный термин? Например, нормализация реляционной БД направлена именно на устранение избытка и это считается оптимизацией схемы БД. К сожалению, при проектировании ИС в целом или даже БД избыток может оказаться меньшим злом, чем плата за него.
Не только семантическая перегруженность. Есть и другие: слабое представление сущностей реального мира – из-за нормализации может происходить фрагментация сущности реального мира. Однородная структура и т.д. Если, хотите могу перечислить типы приложений для которых реляционная модель считается неадекватной. Я пишу это не потому что на 100 процентов уверен, но пока думаю, что это обосновано.
7 июн 04, 20:42    [727417]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 vadiminfo

>Например, нужно получать информацию о возможных маршрутах на основе анализа местности. Но у реляционной модели для этого ничего нет.

У реляционной модели для этого есть все, это у SQL-ля ничего для этого нет, но SQL != реляционная модель и даже далеко не единственный язык запросов. Предлагаю не смешивать эти понятия во избежание недоразумений.

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

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

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

Возможно и даст, если кто-нибудь когда-нибудь сможет объяснить, что это такое - ООМ.

Кстати пример с нейронными сетями вписывается в ту же схему: попытки использовать нечто без обоснования, на одном голом энтузиазме. Что-то реальных успехов пока не видно, хоть попытки начались лет двадцать назад.

Сравните с HMM (Hidden Markov Models), которые похожи по структуре на нейронные сети, но в отличие от них хорошо математически обоснованы. На сегодняшний день HMM - самая лучшая база для распознавания речи.

>Тут неадекватность реляционной модель для таких систем считается более или менее установленным фактом.

Нельзя ли объяснить поподробней, что понимается под понятием "адекватность", оно тут интенсивно используется.

Если адекватность есть соответствие решаемой задаче, то идеально адекватная система будет решать только одну эту задачу. Шаг вправо-влево от нее (от задачи) приведет к таким проблемам, что проще окажется все строить с нуля на асемблере. Шутка. Универсальная система всегда "неадекватна" (если я правильно понимаю термин), это плата за универсальность.

>Если, хотите могу перечислить типы приложений для которых реляционная модель считается неадекватной.

Да, конечно. А еще, если можно, поделитесь ссылками.
8 июн 04, 11:28    [728166]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Шо в лоб, шо по лбу....


автор
...есть же в этом отношении что-то искуственное. Без него разве чего-то не хватало...


Рел.модель - модель данных!!! Есть некие данные (в данном случае о связи) - рел.модель предлагает универсальный способ их описания, представления, существовния. Данные же такие есть? тогда при чем здесь "хватало - не хватало" или "не было в реальном мире"?

автор
Например, нужно получать информацию о возможных маршрутах на основе анализа местности. Но у реляционной модели для этого ничего нет.


ИМХО это бред. Есть операции над отношениями, есть операции над доменами. Так вот - в реляционной модели определяются операции над отношениями, в том числе и такие, что используют операции над доменами (например операция эквисоединения использует определяемую для доменов операцию равенства). В принципе домены могут быть любыми и операции для них могут быть определны любые - например домен "люди" и операция равенства ...ммммм......по цвету волос :) . Но реляционная модель от этого не измениться - если есть несколько отношений с атрибутами, определёнными на домене "люди", то мы запросто выполним эквисоединение, причем это эквисоединение как-то соединит кортежи по цвету волос. Но, блин, смысл этой операции никак не связан с реляционной моделью!!! точно так же калькулятор сложит 2+2 , а что это значит понятно только человеку.

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

Все слова об адекватности или ....кхе-кхе.....семантичности :) моделей, это ИМХО от непонимания, что котлеты отдельно, и мухи отдельно.....
8 июн 04, 12:09    [728350]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
автор

У реляционной модели для этого есть все, это у SQL-ля ничего для этого нет, но SQL != реляционная модель и даже далеко не единственный язык запросов. Предлагаю не смешивать эти понятия во избежание недоразумений.

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

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

Но вообще-то есть явная идея о том, что каждому отношению должна соответствовать какая-то сущность реального мира. Это выглядит как наиболее естественное описание реальности. Ассоциативные таблицы - это сематическая перегруженность. Вобще это подламывание реального мира под компьютерные структуры. Безусловно, от этого подламывания нельзя совсем избавиться, раз компьютеры используются, но к этому есть всегда стремление. Ведь нас интересует только информация, а компьютер только инструмент.
автор

Нельзя ли объяснить поподробней, что понимается под понятием "адекватность",

Тут уже приводилось определение для моделирования вообще. Но для моделирования данных в узком смысле - это соответствие ПО (предметной области) модели данных.
1. сущности, информация о которых нас(заказчика)интересует прописывается ясным образом в структуре данных и достаточно легко интерперетируется. Субьективность понятий "легко" и "ясным образом" не должна вводить в заблуждение. Таблицы, например, хороши тем, что они оправдали себя за долго до появления реляционной модели в определенных областях деятельности.
2. Система запросов достаточна для получения ответов на интересующие вопросы. Причем желательно достаточно простым способом.
3. Логические правила должны прописаны и тоже достаточно просто.
Эти все 3 пункта взаимосвязаны. Например, можно подавить избыточность ценой того, ограничения целостности нельзя будет прописать декларативно (проблемы НФБК). Та модель, которая хуже это обеспечивает эти требования менее адекватна. Появление службных таблиц снижение адекватности.
Если эти пункты нельзя полностью обеспечить или усилия на их обеспечение превосходят разумные, то модель неадекватна ПО. В широком смысле неадекватность типа модели - это признание того, что ее использование либо не даст желаемого результата вообще, либо приведет к значительным трудностям в том или ином этапе жизненного цикла ИС.
автор

Да, конечно. А еще, если можно, поделитесь ссылками.

Ссылки - это книга. Она дома. Вечером напишу.

автор

Рел.модель - модель данных!!! Есть некие данные (в данном случае о связи) - рел.модель предлагает универсальный способ их описания, представления, существовния. Данные же такие есть? тогда при чем здесь "хватало - не хватало" или "не было в реальном мире"?

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

автор

ИМХО это бред. Есть операции над отношениями, есть операции над доменами. Так вот - в реляционной модели определяются операции над отношениями, в том числе и такие, что используют операции над доменами (например операция эквисоединения использует определяемую для доменов операцию равенства). В принципе домены могут быть любыми и операции для них могут быть определны любые - например домен "люди" и операция равенства ...ммммм......по цвету волос :) . Но реляционная модель от этого не измениться - если есть несколько отношений с атрибутами, определёнными на домене "люди", то мы запросто выполним эквисоединение, причем это эквисоединение как-то соединит кортежи по цвету волос. Но, блин, смысл этой операции никак не связан с реляционной моделью!!! точно так же калькулятор сложит 2+2 , а что это значит понятно только человеку.

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

Я может неудачно выразился. Имеется ввиду что поиск маршрутов, их расстояний и других свойств должен быть получен достаточно просто админом БД с помощью системы запросов. Или он мог по фотографии определить местность в которой эта фотография была сделана. Алгоритмы были и до появления реляционной модели. Но выяснилось, что применение БД с этой моделью повысило эффективность приложений. Все-таки главная цель ИС - это получение неюбходимой инфрмации максимально легким способом. Если нет моделей влияющих положительно на решение этой задачи - это одно. А если есть, то это другое.
8 июн 04, 13:45    [728812]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
автор
Но вообще-то есть явная идея о том, что каждому отношению должна соответствовать какая-то сущность реального мира


....и где такая явная идея, кроме как в Вашей головы, есть? если не трудно, хоть одну ссылку на любой более-менее приличный источник....

автор
SQL - реализованный язык реляционных БД


....Не стоит прям так с плеча. Например Дейт является яростным противником SQL-я, обоснованной утверждая, что он явным образом нарушает реляцинноую модель. Что касается

автор
там много расширений и последние, по-моему, включают и обектно-реляционные расширения


дык это всё еще дальше от реляционной модели.

автор
Можно не путать эти понятия, но какая в этом сегодня польза?


Ну, например, не было бы этого топика :)
8 июн 04, 14:48    [729063]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
имхо
Guest
vadiminfo
Но вообще-то есть явная идея о том, что каждому отношению должна соответствовать какая-то сущность реального мира. Это выглядит как наиболее естественное описание реальности. Ассоциативные таблицы - это сематическая перегруженность.


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


Как видим - никакой избыточности. Просто внимательное рассмотрение "реального мира". И сущность "связь" (взаимоотношение) ничем не хуже сущностей "человек" или "собака".

Если бы взаимоотношений не было (в "реальном мире"), то и не надо было бы их моделировать. А то, что они способны вырождаться в однозначные - лишь удобство, позволяющее свести сложное (множественность взаимоотношений) к простому (единственность скалярного признака).
8 июн 04, 15:44    [729254]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 vadiminfo

автор


автор

SQL - реализованный язык реляционных БД.


Вне сомнения, язык запросов к реляционным БД, плохо то, что широко рспостранён только он, вот и пытаются его улучшить - чаше почему-то неудачно.

автор

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


Не можно, а НУЖНО, ИМХО. Нужно пытаться разработать язык, который на основе реляционных данных решал бы топологические задачи, например. Скорее всего такой язык будет разработан (если уже не разработан), но применение найдёт не настолько широкое как универсальный SQL.

автор

Но вообще-то есть явная идея о том, что каждому отношению должна соответствовать какая-то сущность реального мира. Это выглядит как наиболее естественное описание реальности.


Почему каждому отношению должна соответствовать реальная сущность ?
Отношение - это подмножество декартова .... (не буду повторяться), вы как и МНОГОУВАЖАЕМЫЙ Чернышев А.Л. пытаетеась математическому определению поставить в соот. объект, тогда как при моделировании (объекта, процесса или данных) нас в первую очередь интересует результат, во вторую стоимость его получения (по большому счёту, скорость с которой он получен).

ПРИМЕР : Когда инженер прочнист расчитывает прочность конструкции его не интересуют промежуточные значения напряжений и моментов, он не особенно задумывается над физ. смыслом значений частных производных и тензоров, но применив удачно разработаную модель - получает результат : необходимый запас прочности.

автор

Ассоциативные таблицы - это сематическая перегруженность. Вобще это подламывание реального мира под компьютерные структуры. Безусловно, от этого подламывания нельзя совсем избавиться, раз компьютеры используются, но к этому есть всегда стремление.


А любое моделирование - это подламывание под структуры, математические как правило. Иначе никак, а стремление есть только одно получить результат с наименьшими затратами.

автор

Ведь нас интересует только информация, а компьютер только инструмент.


Так почему же вы выделяете в отдельные сущности комнаты и приборы (по-моему ваш же пример) но отказывае в праве называться сущностью расположению прибора в комнате ? Мне показалось вы весьма грамотный человек (в отличии от УВАЖАЕМОГО Ч.А.Л.) и цитировать Эшби и Шеннона мне не придётся, просто хочу напомнить вам - расположение, это тоже информация.

автор

Субьективность понятий "легко" и "ясным образом" не должна вводить в заблуждение. Таблицы, например, хороши тем, что они оправдали себя за долго до появления реляционной модели в определенных областях деятельности.


А ведь вводят заразы Меня, например, вводят. Вот УВАЖАЕМЫЙ КОЛЛЕГА Ч.А.Л. легко вывел ("уже предполагается") несостоятельность рел. модели, для него "совершенно ясным" представляются строки кода похожие больше на какой-то ключ для криптоалгоритма, он это рассказывает людям которые программируют по 10-20 лет несмотря на всеобщее хихиканье.

То что ясно и легко для одного недостижимо для другого, хотите могу привести ещё примеров.

автор

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


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

автор

Или он мог по фотографии определить местность в которой эта фотография была сделана.


А не высоковато ли мы замахнулись (пока) : язык запросов к данным, который решит все проблемы быстро и легко, возможно ли такое ?

автор

Алгоритмы были и до появления реляционной модели. Но выяснилось, что применение БД с этой моделью повысило эффективность приложений.


С какой именно моделью ?

автор

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


Именно ! Именно так "получение неюбходимой инфрмации максимально легким способом", а её анализ и (возможно) синтез задача совсем не БД.
8 июн 04, 16:19    [729389]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
автор

>Если, хотите могу перечислить типы приложений для которых реляционная модель считается неадекватной.

Да, конечно. А еще, если можно, поделитесь ссылками.

"Базы данных" Томас Конноли, Каролин Бегг, Анна Страчан 2000.
Перчень типов приложений, в которых по мнению авторов РСУБД продемонстрировали свою неадекватность.
1. Автоматизированное проектирование.
2. Автоматизированное производство.
3. Автоматизированная разработка программного обеспечения.
4. Офисные информационные системы и мультимедиа системы.
5. Цифровое издательское дело.
6. Геоинформационные системы.
Конечно, это не окончательный список. Так я читал жалобы спецалистов занимающихся обработкой научных и инженерных данных, что рел. модель не содержит того, что им бы подошло.
Наиболее успешно рел. модель применяется в традиционных бизнес-приложениях.

автор

....и где такая явная идея, кроме как в Вашей головы, есть? если не трудно, хоть одну ссылку на любой более-менее приличный источник....

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

SQL - реализованный язык реляционных БД

....Не стоит прям так с плеча. Например Дейт является яростным противником SQL-я, обоснованной утверждая, что он явным образом нарушает реляцинноую модель. Что касается

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

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


Как видим - никакой избыточности. Просто внимательное рассмотрение "реального мира". И сущность "связь" (взаимоотношение) ничем не хуже сущностей "человек" или "собака".

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

По этому вопросу, я говорил про перегруженность, а не избыточность. Т.е. отношение не соответствующее никакой сущности, а не избыточное хранение информации. На самом деле я для краткости примера хотел упростить. Но Вы углубили вопрос. Хорошо. Тогда скажем так: нужно дополнительное отношение, реализующее связь. Но при этом нет механизма отличить связь от сущности. И, кроме того, связи как Вы правильно заметили, могут иметь разную семантическую окраску, а средств для выражения этого нет. Фактически, Вы перешли на терминологию модели Сущность-Связь Чена. Но в ней то, как раз есть средства для отличия типов связей от типов сущностей.

автор

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

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

автор

Отношение - это подмножество декартова .... (не буду повторяться), вы как и МНОГОУВАЖАЕМЫЙ Чернышев А.Л. пытаетеась математическому определению поставить в соот. объект, тогда как при моделировании (объекта, процесса или данных) нас в первую очередь интересует результат, во вторую стоимость его получения (по большому счёту, скорость с которой он получен).

Подмножество декартова произведения. Нужно отметить, что отношение в Рел. модели хоть и похоже на теоретико множественную конструкцию - отношение в теории множеств, но не совпадает полностью. В частности, математика стремится абстрагироваться от природы объектов, а в реляционной модели семантика имеет большое значение. Берется рациональное зерно, чтобы построить реляционную алгебру и соотв. по выразительной силе исчисления кортежей или доменов. Нас интересует информация, а без интерпретации ее нет. Что такое 157 рост человека или еще что? Результат в ИС это информация. Вы можете взять БД в виде таблиц без всех остальных частей этого приложения и, зная интерпретацию с помощью запросов и специальных прог получить результат. Но что еще важнее - это обеспечение независимости данных от множества клиентских приложений в разработке системы. А моделирование обеспечивает, в том числе и средства интерпретации данных.
автор


Так почему же вы выделяете в отдельные сущности комнаты и приборы (по-моему ваш же пример) но отказывае в праве называться сущностью расположению прибора в комнате ? Мне показалось вы весьма грамотный человек (в отличии от УВАЖАЕМОГО Ч.А.Л.) и цитировать Эшби и Шеннона мне не придётся, просто хочу напомнить вам - расположение, это тоже информация.

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

А ведь вводят заразы Меня, например, вводят. Вот УВАЖАЕМЫЙ КОЛЛЕГА Ч.А.Л. легко вывел ("уже предполагается") несостоятельность рел. модели, для него "совершенно ясным" представляются строки кода похожие больше на какой-то ключ для криптоалгоритма, он это рассказывает людям которые программируют по 10-20 лет несмотря на всеобщее хихиканье.

В настоящее время есть как сторонники, так и противники реляционной модели данных. Никто не ожидал такого успеха этой модели, в том числе и IBM, которая фактически дала этой модели зеленый свет. Практика показывает, что на успех влияют не только технические факторы, но и многие другие. Особенно коммерческие. Причем, вовлечено много участников и большие средства. Я думаю, что на сегодня развитие моделей стоит перед делемой: объектно-реляционные или объекнтно ориентированные. Или они как-то поделят рынок. Но как я писал, там, где реляционные модели успешны, а это бизнес приложения (т.е. там где сосредоточен капитал) там они имеют слишком явные преимущества – не видно кто их оттуда вытеснит. Если только не произойдет какой-то революции в технологиях. Кроме того, из всех БД 99% реляционные, а это слишком много для замены. 20 лет назад 99% было не много, а теперь многовато. Пока у ООБМ нет таких заметных преимуществ, чтобы привлечь всех переходить на эту модель. Более того, им еще предстоит догонять в вопросах реализации СУБД. А недостатки тоже есть. Что будет завтра сказать трудно. Тенденций тоже пока ясных не видено. Объектно-реляционные включают реляционную как подмножество. Фактически, объектное и там носит пока больше декларативный характер. Можно отметить, что изначально предполагалось сосуществование многих моделей данных. Но реальность оказалась иной.

автор

Именно ! Именно так "получение неюбходимой инфрмации максимально легким способом", а её анализ и (возможно) синтез задача совсем не БД.

Но основывается на БД. Если БД плохо спроектирована или модель не адекватна, то скорее всего никакие программные ухищрения не помогут. По этому в определенном смысле данные выходят на первый план в технологиях БД в отличии от традиционного программирования.
8 июн 04, 22:19    [730177]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 vadiminfo

>"Базы данных" Томас Конноли, Каролин Бегг, Анна Страчан 2000.

Спасибо за ссылку. Не могли бы Вы привести название книги и имена авторов на английском, там наверняка есть на титульном листе? Я постараюсь найти и прочитать.

>Перчень типов приложений, в которых по мнению авторов РСУБД продемонстрировали свою неадекватность.
1. Автоматизированное проектирование.
2. Автоматизированное производство.
3. Автоматизированная разработка программного обеспечения.
4. Офисные информационные системы и мультимедиа системы.
5. Цифровое издательское дело.
6. Геоинформационные системы.


Тут бесспорно только одно, что все эти системы полностью средствами РСУБД реализовать неудобно и работать будет плохо. РСУБД очень успешно могут быть чстью этих систем. Но по-моему это нормальный подход, когда задача решается совместным использованием нескольких средств. Я даже теоретически не представляю себе средства, которое бы позволило полностью решить, включая пользовательский интерфейс, задачи 1-6. ООДБ картины не изменят, GUI они тоже отображать не умеют.

>А разве это не язык реляционных БД или он не был реализован во многих СУБД? Или эти БД не являются реляционными? Тогда какие являются реляционными?

Говорить что SQL == RDBMS примерно то же самое, что говорить что C есть процедурное программирование и критиковать процедурное программирование из-за того, что C имеет проблемы.

Есть довольно стандартный язык QBE, оракл-дизайнер его даже когда-то поддерживал по-моему, может и сейчас поддерживает. QBE тоже язык для РСУБД, на SQL совсем не похож. Можно посмотреть у Дейта.

>Тут уже приводилось определение для моделирования вообще. Но для моделирования данных в узком смысле - это соответствие ПО (предметной области) модели данных.
1. сущности, информация о которых нас(заказчика)интересует прописывается ясным образом в структуре данных и достаточно легко интерперетируется. ...
2. Система запросов достаточна для получения ответов на интересующие вопросы. Причем желательно достаточно простым способом.
3. Логические правила должны прописаны и тоже достаточно просто.


По этому определению РСУБД очень даже адекватны, по крайней мере в тех примерах, которые тут приводили. Например, как уже говорили, появление таблицы-связи много ко многим очень логично и вписывается в концепцию. А вот если такую связь реализовать внутренними средствами, без явного прописывания в БД, то непонятно что делать в тех случаях, когда условия задачи вдруг слегка изменятся и эта связь станет сущностью. Такое часто бывает. Или что делать с тренарными, n-арными отношениями? Каждый раз сводить к бинарным мало не покажется ни вам ни потом серверу. ИМХО проблем будет больше чем в РСУБД.

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

Именно так оно и есть: связь и есть сущность. Если понятия связь-сущность разделять, то возникнут проблемы, поскольку в математике функция есть отношение частного вида и вообще все есть отношение (множество) и это очень удобно. А ничего лучше математики человечество пока не придумало.
9 июн 04, 02:11    [730307]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Zaxx
Guest
c127
Есть довольно стандартный язык QBE, оракл-дизайнер его даже когда-то поддерживал по-моему, может и сейчас поддерживает.


Ключевое слово "ПО МОЕМУ"... А оракл-дизайнер это CASE-средство. Даже если вы его перепутали с Oracle Developer, то QBE в нём, это не язык, а возможность нажать в форме F7, ввести в нужное поле значение или маску, и по нажатию F8 в запрос, который отображает данные в датаблоке, добавится условие в выражение where.

QBE как язык запросов я видел только у Borland в Paradox и Database Desktop. Так-что есть сомнения в его стандартности.
9 июн 04, 08:34    [730485]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Почитал упомянутую статью А.Л.Чернышева в части критики реляционной модели. Учитывая, что реляционная модель имеет довольно четкое формальное определение, автор для ее критики попытался выйти на «сверхформальный» уровень, определив кучу «понятий», «гипотез» и т.д. Увы, формализация понятий («объект», «предмет», «пространство и время» и пр.) далась ему чрезвычайно слабо. Тут суть в непонимании автором того, что многие термины аксиоматичны и любая попытка их «наукообразной» формализации ничего кроме улыбки или недоумения не вызовет. Ну, возьмем определение:
автор
Объект — все, что противостоит субъекту в его предметно-практической и познавательной деятельности.

Во-первых, определение предельно несамодостаточно, оно замкнуто на определение «субъекта», которого автор не дает. Во-вторых, «Объект — это всё» уже само по себе забавное начало определения. Далее, что такое «предметно-практическая» деятельность, «познавательная» деятельность? Зыбкие, нечеткие понятия, куда более вторичные по отношению к фундаментальному «объект». И, наконец, перечисление вот «таких» видов деятельности субъекта вызывает вопрос, а есть ли другие виды? Если нет, зачем их перечислять (сказать, мол, «в его деятельности» и все)? Если есть, то почему в них объект «не противостоит» субъекту?
Очень слабо. И это только самое начало статьи.
Возьмем его описание гипотез, на основе которых чуть позже автор смелой рукой вскрывает «фундаментальное противоречие» модели Кодда:
автор
«Такая модель данных (реляционная), основанная, конечно же, на гипотезе 1, позволяет использовать операции реляционной алгебры для манипулирования данными, то есть позволяет параллельно использовать реляционную модель, основанную на гипотезе 2!
Это фундаментальное противоречие, которое нельзя назвать ни недостатком, ни преимуществом модели Кодда.»

Итак, гипотезы:
автор
Гипотеза 1 (материалистическая). Мир состоит из объектов и связей между ними.
Гипотеза 2 (идеалистическая). Мир состоит только из объектов, которые мы "связываем" в своем сознании, образуя новые объекты.

В гипотезе 1, на которой основана математика (и реляционная теория), фигурируют (1) объекты и (2) связи. Оба понятия аксиоматичны, но интуитивно понятны. Что нам предлагает автор в составе 2 гипотезы? (1) объекты, (2) наше сознание, (4) связывание, (5) образование новых объектов. Очевидно, что «связывание» неявно дает нам те же «связи», что и в 1 гипотезе. То есть гипотеза 2 фактически включает гипотезу 1, плюс понятие (2) «наше сознание», минус ненужное «образование новых объектов». Вывод: гипотеза 2 есть гипотеза 1, снабженная примечанием о том, что объекты и связи интерпретируются человеческим сознанием. Но это именно примечание, поскольку факт интерпретации не отрицается гипотезой 1. Таким образом, никакой самостоятельной гипотезы 2 не существует. «Фундаментальное противоречие» модели Кодда — это такое же противоречие как «Чапай, ты за большевиков али за коммунистов?»

Пару слов еще об одном пассаже:

автор
Гипотеза 3 (биологическая). Мир состоит из объектов, обладающих поведением и обменивающихся сообщениями.

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

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

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

Если бы автор хоть раз в жизни оторвался от письменного стола и побывал в цехе или на складе, он бы с удивлением заметил, что перемещение материала из цеха на склад не происходит само по себе. Для этого выписываются заявки, приходят/приезжают люди, грузят и перевозят материалы и т.п. Никаких «классов», «методов», «сообщений» здесь нет. Почему? А не надо путать реальный мир и информационную систему. Когда мы говорим про ООП, мы говорим в конечном итоге про компьютерные программы. А они имеют дело не с реальным миром, а с его информационной моделью. А в таковой информационные объекты «кладовщик», «накладная», «кирпичи» и т.д. вполне реальны и могут вызывать доступные им методы (или, если угодно, обмениваться сообщениями).

Многозначительный вывод автора, что «все модели данных являются объектно-ориентированными в смысле гипотезы 1» довольно странно выглядит, ибо существующие представления об ООП сформулированы вполне четко (читайте Буча, например). И именно существующие определения всеми понимаются. При чем здесь ваше, дорогой автор, собственное представление об ООП «в смысле гипотезы 1»? Вы себе представляете ООП как-то по своему? Тогда не называйте его ООП. Не надо этой терминологической путаницы.

Дальше даже читать не стал.
9 июн 04, 11:59    [731137]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
с127
Guest
2 Zaxx
>Ключевое слово "ПО МОЕМУ"... А оракл-дизайнер это CASE-средство. Даже если вы его перепутали с Oracle Developer, то QBE в нём, это не язык, а возможность нажать в форме F7, ввести в нужное поле значение или маску, и по нажатию F8 в запрос, который отображает данные в датаблоке, добавится условие в выражение where.

QBE как язык запросов я видел только у Borland в Paradox и Database Desktop. Так-что есть сомнения в его стандартности.


Нет, ключевое слово тут "Можно посмотреть у Дейта". QBE как раз и есть возможность вводить запрос прямо в форму в интуитивно понятном виде (отсюда название Query By Example), точно так же как это делалось в парадоксе. У Дейта эти формы нарисованы в явном виде. Куда QBE транслируется - в SQL или в машинные коды - не важно, язык от этого не меняется и остается языком запросов. QBE вкладывается в SQL или даже еквивалентен ему, сейчас не помню, и именно поэтому может быть перетранслирован в SQL, что по-видимому и делается в дизайнере. Было бы странно, если бы оракловцы написали отдельный оптимизатор для QBE.

А вот к вопросу о стандартности и распространенности.
Building SQL queries with QBE Vision Query Builder's easy-to-use multi-database graphical query tools:
http://www.sysdeco.no/products.asp?file=description_query.xml

QBE DB2 Software:
http://www.cutedownloads.com/two/QBE-DB2.htm

IBM DB2 Everyplace Query by Example (Pocket PC) 7.2.1:
http://download.com.com/3000-2156-8752809.html

Вообще похоже IBM любит QBE больше.
9 июн 04, 13:05    [731471]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Zaxx
Guest
с127
QBE как раз и есть возможность вводить запрос прямо в форму в интуитивно понятном виде (отсюда название Query By Example)

В предыдущем сообщении вы ясно сказали:
автор
Есть довольно стандартный язык QBE


Именно ЯЗЫК, а не НЕ ВОЗМОЖНОСТЬ вводить запрос. И в Paradox это был именно язык, со своим синтаксисом.

с127
QBE вкладывается в SQL или даже еквивалентен ему, сейчас не помню, и именно поэтому может быть перетранслирован в SQL

Не всякий QBE может быть перетранслирован в SQL.

с127
что по-видимому и делается в дизайнере
.
Повторюсь: Oracle Designer - это CASE-средство. Где вы там запросы нашли?

автор
Было бы странно, если бы оракловцы написали отдельный оптимизатор для QBE.

Действительно странно, зачем писать оптимизатор для языка который Oracle не поддерживает.
9 июн 04, 14:50    [731995]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
2 c127

В дизайнере задаются спецификации по структурам данных и приложениям, после чего он генерирует соответствующие формы, SQL и т.д. К QBE он не имеет никакого отношения. А QBE есть в девелопере (oracle forms) как возможность задавать критерии отбора записей. Появилось это все до парадокса и прочих настольных штучек.

2 all

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

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

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

Короче, без четкого определния границ применимости того или иного метода построения информационных систем, будут продолжаться войны типа RDBMS и реляционная модель - фигня, а мы можем все.
9 июн 04, 15:02    [732057]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Zaxx
Guest
2 c127

Про QBE (про язык, а не "возможность вводить запрос прямо в форму ") : QBE is both a query language and the name of a DB system including it. The system is no longer in use, but the language is part of IBM's Query Management Facility (QMF).

http://www.cs.sfu.ca/CC/354/zaiane/material/notes/Chapter5/node1.html
9 июн 04, 19:31    [733194]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
автор

Говорить что SQL == RDBMS примерно то же самое, что говорить что C есть процедурное программирование и критиковать процедурное программирование из-за того, что C имеет проблемы.

Есть довольно стандартный язык QBE, оракл-дизайнер его даже когда-то поддерживал по-моему, может и сейчас поддерживает. QBE тоже язык для РСУБД, на SQL совсем не похож. Можно посмотреть у Дейта

Вообще-то я пытался сказать, что SQL (а точнее его диалекты) - является реализованным языком баз данных, т.е. имеет практическое значение. И по, крайней мере, до появления стандарта SQL99 он являлся языком реляционных БД. Следовательно, имеет значение для реляционных СУБД. Плох он или хорош, позволяет полностью реализовать эту модель или ее расширения или привносит что-то дополнительное, но так получилось, что реальные результаты успеха рел. БД в проектах связаны с СУБД, использующими этот язык. Поэтому при сравнении СУБД его, скорее всего, игнорировать нельзя. Ведь в теме звучит именно сравнение различных типов СУБД, а не моделей самих по себе в отрыве от реального вклада в приложения баз данных. Тем более нельзя с этим не считаться при оценке перспектив.
Если говорить о С, то критика на его основе отдельных аспектов процедурного программирования не совсем лишена смысла - этот язык несомненно входит в ведущие языки, и выражает определенные достижения и, по-видимому, все-таки реализует многие принципы этого программирования достаточно полно. В тех случаях, когда это не так, можно будет критиковать и без ссылок на С. Но ведь то, что не реализовано может так и остаться никогда не реализованным, хотя и быть очень рациональным. Возможно, существуют лучшие модели, чем реляционная, но которые не были реализованы в силу разных причин. А если бы реляционная не была реализована, мало бы кто ее критиковал вообще (а большинство из нас не подозревало бы о ее существовании). Критика - это уже успех. Напомню, что для IBM реляционная СУБД была второстепенным исследовательский проектом (SYSTEM/R). Не проведи IBM его, и не опубликуй результаты, и не будь еще массы факторов, то неизвестно какя была бы судьба у этой модели.
Кроме QBE, есть и другие языки. Например, на заре реляционных БД СУБД Ingres использовала язык QUEL, а Oracle - SQL. Была острая конкуренция. Может QUEL в чем-то лучше соответствовал реляционной модели. Но в 1986 году Ingres перешла на SQL. Имеет значение признание на рынке. QBE есть в ACCESS наряду с SQL (точнее диалектом). Но для написания запроса, содержащего коррелированный подчиненный подзапрос, приходится писать на SQL (хотя, возможно, и в бланке QBE). Кроме того, UNION можно написать там, по-моему, только на SQL. Т.е. там QBE имеет менее выразительную силу, чем SQL.
Я не говорю, что все надо мешать в одну кучу и модель, и конкретный язык БД, но раз речь идет о типе СУБД (например, реляционном), то язык БД игнорировать не стоит.
автор

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

Утверждение "связь и есть сущность" не может быть выведена из пользы в математике теоретико-множественной конструкции - "отношение". Функциональные зависимости описываются с помощью выделения ключей, хотя в теории они и определяются формально как отношения частного вида. Да и про функцию не всегда удобно помнить, что она может быть представлена как это отношение частного вида И не все математике есть отношение: сами отношения - это конструкция из множеств, наряду с другими конструкциями. Математика абстрагируется от природы объектов, а модель данных описывает именно явления природы, реальные объекты, хотя она и нуждается в манипулировании данными и, следовательно, чем глубже опирается на математику, тем лучше (отсюда и отношения). Кроме того, существуют модели данных, не использующие отношения для структурирования данных. И не только инфологические, но и датологические. Например, сетевые структурируют данные с помощью типов записей, хотя тоже описывают сущности и связи. Поэтому из полезности отношения выводить тождество между сущностью и связью вряд ли стоит. Тем более с точки зрения логики это разные понятия. (Да и вообще, какой смысл в двух отдельных словах, когда одно есть другое). Другое дело, что описать с помощью отношения связь можно. А в реляционной модели связь многие ко многим и придется так описать. Но было бы не так плохо, чтобы все-таки можно было отличать сущности от связей и разные типы связей друг от друга. Кроме того, в случае один ко многим нет необходимости в третьем отношении, но и здесь связи могут иметь разную семантическую окраску (владеет, управляет и т.д.). Есть мнение, что если бы модель имела механизмы для придания связям семантической окраски, то это бы придало большую сематичность операциям. Я не говорю, что это единственный и главный недостаток, или что у реляционной модели нет вообще семантических возможностей. Я просто привел один из известных недостатков, как пример того, что они есть. Недостатки есть и у объектно-ориентированной модели данных. Наверное, я неудачно выразился и прозвучало как что-то типа - этот недостаток убийственен для реляционной модели и, наоборот, докажите что его нет - и у реляционной модели нет проблем вообще никаких.
9 июн 04, 22:48    [733375]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Zaxx
>QBE как раз и есть возможность вводить запрос прямо в форму в интуитивно понятном виде (отсюда название Query By Example)

В предыдущем сообщении вы ясно сказали:
автор
Есть довольно стандартный язык QBE


Именно ЯЗЫК, а не НЕ ВОЗМОЖНОСТЬ вводить запрос. И в Paradox это был именно язык, со своим синтаксисом.


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

>Не всякий QBE может быть перетранслирован в SQL.

Читаем Дейта (An Introduction to Database Systems, Addison-Wesley, 1995, pp.210-211):

The relational language Query-By-Example (QBE) incorporates elements of both the tuple and domain the domain calculus. .... Unfortunately QBE is not relationaly complete. To be specific, it does not (properly) support the neglected existential qualifier (NOT EXISTS). As a result certain queries (e.g. ...) cannot be expressed in QBE.

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

>Действительно странно, зачем писать оптимизатор для языка который Oracle не поддерживает.

Если бы написали оптимизатор, то QBE поддерживался в ядре, а так он поддерживается в оракл формс или где там еще. Никакой разницы с точки зрения обсуждаемого вопроса нет. Язык есть и худо-бедно поддерживается системой. Что и требовалось доказать.

Еще тот же Дейт там же на стр.186 пишет:"Of these languages, QBE is probably the best known, and several commertial QBE implementations exist".

Так что я вполне законно заявил, что "Есть довольно стандартный язык QBE". Никакого другого смысла, кроме того, что язык существует, в этой фразе искать не нужно.
10 июн 04, 01:46    [733469]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 vadiminfo

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

Давайте подведем промежуточный итог. Если я ошибся поправьте. Итак мы пришли к следующим выводам:

0) язык SQL очень тесно связан с реляционной моделью данных, отражает основные проблемы модели, но ставить знак равенства между реляционной моделью и языком SQL все-таки нельзя; (этот пункт можно проигнорировать)
1) реляционная модель является хорошо обоснованной и успешной на данный момент;
2) реляционная модель обладает недостатками и существуют задачи, в которых она не является оптимальным выбором; (если бы не было бы недостатков то она была бы оптимальна всегда для абсолютно всех задач. Как фокспро.)
3) альтернативные модели данных (постреляционные, OO) на сегодняшний день обоснованы хуже реляционной; (я бы сказал вообще никак не обоснованы, но это ИМХО)
4) альтернативные модели обладают недостатками по сравнению с реляционной моделью; (я этих недостатков не знаю, поскольку до построения обоснования модели говорить о ее недостатках нет смысла);
5) альтернативные модели обладают достоинствами по сравнению с реляционной; (опять же проблема с обоснованием как в п.4)
6) альтернативные модели не обладают по сравнению с реляционной столь явными достоинствами (или мы их не знаем), которые превесили бы инерцию мышления, вложенные средства и пр. и заставили разработчиков массово перейти с реляционной модели на какую-либо из альтернативных (под разработчками понимаются и те, кто разрабатывает сервера).

Вроде ничего не забыл.
10 июн 04, 02:25    [733484]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
По пункту 0, не очень понятно получилось. Я хотел сказать, что нельзя ставить равенство между моделью данных, в данном случае реляционной, и языком манипулирования данными в этой модели. Любым языком, а не только SQL. Это включает и "абстрактные" языки как реляционная алгебра и реляционное исчисление.

Например реляционная модель данных может содержать "транзитивно замкнутые" данные, а запросов для работы с такими данными может и не быть (vadiminfo>Известно, что существуют недостатки реляционной модели, которые признаются и ее сторонниками: ...., существование запросов, не выразимых в реляционной алгебре (транзитивное замыкание)). Но это не недостаток модели.
10 июн 04, 02:43    [733489]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
автор

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

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

0) язык SQL очень тесно связан с реляционной моделью данных, отражает основные проблемы модели, но ставить знак равенства между реляционной моделью и языком SQL все-таки нельзя; (этот пункт можно проигнорировать)

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

1) реляционная модель является хорошо обоснованной и успешной на данный момент;

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

2) реляционная модель обладает недостатками и существуют задачи, в которых она не является оптимальным выбором; (если бы не было бы недостатков то она была бы оптимальна всегда для абсолютно всех задач. Как фокспро.)

Реляционная модель обладает недостатками, и существуют типы приложений для которых она неадекватна.
автор

3) альтернативные модели данных (постреляционные, OO) на сегодняшний день обоснованы хуже реляционной; (я бы сказал вообще никак не обоснованы, но это ИМХО)

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

4) альтернативные модели обладают недостатками по сравнению с реляционной моделью; (я этих недостатков не знаю, поскольку до построения обоснования модели говорить о ее недостатках нет смысла);

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

5) альтернативные модели обладают достоинствами по сравнению с реляционной; (опять же проблема с обоснованием как в п.4)

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

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

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

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

Реляционная модель может по структуре удобно описать потомков и их предков, но реляционная алгебра не имеет операций, чтобы, например, найти всех потомков данного предка. Это тоже известный недостаток реляционной модели. Но разные производители СУБД могут включать в свою систему средства для ответа на такие вопросы. У Orale есть такая конструкция. Но конечно, она тоже имеет ограничения. Это все-таки недостаток - недостаточная выразительная сила реляционной алгебры. Структуры позволяют хранить такую удобно такую информацию, а средства манипулирования данными не позволяют ее извлечь. Тогда приходится как-то искусственно менять структуру, чтобы все-таки извлекать такую информацию, т.е. усложнять структуру, ради вычислений, ухудшать семантичность модели и т.д. Т.е. с точки зрения стиля - ставить заплатки.
10 июн 04, 12:34    [734413]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
:)

Мысли по поводу....

....Нет у алгебры выразительной силы и быть не должно!...

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

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

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

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

... обзовите одну таблицу "связь" а другую "сущность" и отличайте себе их сколько влезет ...

и тд и тп
10 июн 04, 19:25    [736100]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
автор

Мысли по поводу....
....Нет у алгебры выразительной силы и быть не должно!...

Не совсем понял. Я не говорил, что ее нет, тем более у алгебры вообще (в теории групп, линейной алгебре, просто алгебре, модулях и кольцах и т.д.).
Речь шла о том, что ее в реляционной алгебре недостаточно. Т.е. существуют невыразимые в реляционной алгебре запросы.



автор


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


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

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

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

автор

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

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

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


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

автор

... обзовите одну таблицу "связь" а другую "сущность" и отличайте себе их сколько влезет ...

Обозвать то можно, но и то и другое так останутся таблицами. И мне, а главное пользователям придется еще раздумывать и что-то держать в голове, вместо того чтобы, взглянув на схему сразу понять, где сущность, а где связь. Ведь не любому пользователю надо знать все про данные. Я, например, вынужден переключаться между проектами, и хочу тратить как можно меньше времени на чтение схем и разгадывания замыслов авторов. Мне для задач было бы проще сразу видеть, где сущности, где связи и, например, писать запросы.
11 июн 04, 01:15    [736434]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 vadiminfo

>Более того, SQL99 содержит и не характерные для реляционной модели структуры - массивы, пользовательские типы. (Oracle их тоже содержит).

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

Введение ораклом embedded tables, например, это по-моему просто расширение модели Кодда в рамках реляционной алгебры. Но в данном случае попытка неуспешна по-моему, вместо embedded tables проще пользоваться отношением один-ко-многим.

>Альтернативные модели - не только постреляционные, но и дореляционные.

Я дореляционные намеренно исключил, врядли с той стороны будут какие-то неожиданности. Например иерархические БД в некоторых случаях очень хороши, но таких случаев в чистом виде очень мало.

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


Последнее предложение снимает все вопросы.

С рекурсией в SQL действительно проблема, точнее полное ее, рекурсии, отсутсвие. Но с появлением в оракле, дб2, сайбейзе рекурсивных запросов жить стало легче.

Кстати интересно, как рекурсивные запросы вписываются в концепцию классического SQL-я или реляционной модели данных? Я по этому поводу ничего ну встречал, но по-моему очевидных противоречий нет.

2 U-gene

>....ну что за бред о ОО и ОР моделях и о сравнении их с рел. моделью? где они???

За исключением бреда со всем полностью согласен: основная проблема в том, что сравнивать на сегодня нечего.

И ничего не получится с ООДБ и пр., пока не будут построены модели. Строить сервера данных без формализации модели данных есть ламерский подход. Много раз пытались кавалерийскими наскоками решать проблемы и вроде ни разу ничего путного не вышло. С искуственным интеллектом та же проблема, с многозначными логиками вообще конфуз вышел. Сколько же раз нужно наступать на грабли, чтоб понять, что сначала нужно подумать, а только потом писать код.
11 июн 04, 03:16    [736454]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
c127

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

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

Я дореляционные намеренно исключил, вряд ли с той стороны будут какие-то неожиданности. Например иерархические БД в некоторых случаях очень хороши, но таких случаев в чистом виде очень мало.

Чтобы оценки претендовали на осторожность, дореляционные, а также другие, не рассматриваемые сегодня на предмет реализации, все таки не следует не упоминать. Возможно, при изменении ситуации в компьютерных технологиях, появлении новых каких-то принципов построения информационных систем, а тем более БД, эти модели могут еще проявить себя. Ведь вычислительные машины были предложены в 18хх, но не было возможности продемонстрировать всю их силу в то время. Но, наверное, сегодня эти модели можно временно не рассматривать в данном топике.
c127

Кстати интересно, как рекурсивные запросы вписываются в концепцию классического SQL-я или реляционной модели данных? Я по этому поводу ничего ну встречал, но по-моему очевидных противоречий нет.

Но есть кое-что не очевидное. Действительно, производители включают из в свои диалекты SQL. А вот что сделает организации по стандартизации SQL, действительно, интересно. Что касается реляционной модели, точнее реляционной алгебры, то тут сразу видны сложности. Тут неясности и с определением такой операции на отношении. Что она должна возвращать в случае если граф содержит петли? И на каких отношениях она вообще определена? Для алгебры имеет значение композиция операций и их свойства. Например, ассоциативность. А что в этом отношении можно сказать про транзитивное замыкание? И, наконец, вопрос - а решит ли она все, что связано с запросами о такого рода связях между атрибутами? Наверное, там еще какие трудности найдут или нашли исследователи.
Производители СУБД в погоне за клиентом пойдут на включение в свои языки много, что будут очень желать потребители. И во главу угла поставят, наверное, простоту. Так в стандарте SQL1 не было внешнего соединения, а потребность в нем была. Oracle включил "+", а SQL Server "*", причем ставить в запросах их надо в противоположных местах для каждой СУБД. Кроме того, стали возникать ситуации, когда не совсем ясно, что вернут сложные запросы с использование таких операторов. В стандарт SQL2 был включен LEFT JOIN, RIGHT JOIN и FULL JOIN. А что они сделают с транзитивным замыканием или какими-то операциями такого плана, но более выразительными? Тоже нигде пока не встречал. Но возможно, что и ничего не сделают.
c127

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

Наверное, пока еще не построены общепринятые модели. Но это можно отнести к недостаткам. А мы же согласились, что недостатки имеют и модели, которые являются успешным. Даже если кавалерийским наскоками не удалось решить что-то сразу, но создать предпосылки, наверное, удавалось. Что касается искусственного интеллекта, то его исследования, как и многозначных логик нельзя назвать бесполезными. Возможно, время еще не пришло для значительного прорыва в искусственном интеллекте. А многозначные логики применяются - в Оракле присутствует трехзначная логика, а Кодд вроде высказывался в пользу четырехзначной логики. Про написание кода согласен, но здесь скорее речь идет о проектировании СУБД.
13 июн 04, 23:24    [740314]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 11 12 13 14 15 [16] 17 18 19 20 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить