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

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

Как можно быть уверенным в перпендикулярности OO и реляционной модели, если нет определения OO? Это как обсуждать перпендикулярность отрезков при наличии только одного отрезка.

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

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

>А для нее имеет значение атомарность значений.

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

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

>Для алгебры имеет значение композиция операций и их свойства. Например, ассоциативность.

Ассоциативность не является необходимым условием, есть неассоциативные алгебры. Например кольцо гиперкомплексных чисел - октав - неассоциативно, но не выходит за пределы алгебры. Хороший пример с циклами в графах. Но ведь и в деревьях, заданных в таблице в виде (id, parent_id) могут быть петли, если их специально не исключить каким нибудь check(id<>parent_id), и это никому не мешает.

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

Если у вас есть ссылки на альтернативные модели баз данных, хоть какие-нибудь формальные, не обязательно общепринятые, то не могли бы Вы их выложить, по-видимому это будет многим тут интересно. Я, например, кроме реляционной, не видел таких моделей вообще, а интересно посмотреть. Разговор бы сразу стал предметным.
15 июн 04, 04:00    [741397]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

Как можно быть уверенным в перпендикулярности OO и реляционной модели, если нет определения OO? Это как обсуждать перпендикулярность отрезков при наличии только одного отрезка.

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

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

Ну поэтому и используется термин "пользовательский тип", а не класс. Но в том то и дело, что мы создаем этот тип, не для того, чтобы абстрагироваться от его природы. У него есть своя структура и методы (не реляционные). Свои отношения между экземплярами. А рел алгебра определена на множестве отношений. И могут быть опасения, что в БД есть не единый способ для получения результатов, а несколько. (перпиндикулярных меджду собой)
c127

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

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

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

Ассоциативность не является необходимым условием, есть неассоциативные алгебры. Например кольцо гиперкомплексных чисел - октав - неассоциативно, но не выходит за пределы алгебры. Хороший пример с циклами в графах. Но ведь и в деревьях, заданных в таблице в виде (id, parent_id) могут быть петли, если их специально не исключить каким нибудь check(id<>parent_id), и это никому не мешает.

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

c127

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


Ссылки надо искать. Но что Вы имеете в виду под термином формальные? Например, иногда файловый БД, которые были до иерархических, называют плоской моделью. Это делается ради замкнутости понятия модели данных для БД. Есть способ структурирования данных, есть способ ограничений целостности и есть способ манипулирования данными - можно говорить о модели. Разумеется присутствует и механизм интерпритации данных. Точнее о типе модели. Это уже формально. Когда применят для БД будет не формальная модель данных этой БД (там будет уже содержание).
Но есть факт, что ООСУБД уже присутствуют на рынке с 1995 и составляли тогда 3% от всех СУБД. Ну и ORACLE называет себя ОРСУБД. Т.е. СУБД с таким моделями уже есть. Они альтернативны. Кто-то считает, что они праздно еще себя являют, кто-то нет. Но мы с Вами уже соглачились, что есть сложные типы приложений, для которых РСУБД не адекватна. Значит там будут применять, скорее всего, использоваться ООСУБД или ОРСУБД.
15 июн 04, 11:48    [741916]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 vadiminfo

>Граф, который содержит циклы не является деревом, но это не важно.

Да, разумеется, это я брякнул и не прочтал. Но мысль понятна: если введено простое ограничение, то можно ввести аналогичное более сложное.

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

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

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

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

>Ссылки надо искать. Но что Вы имеете в виду под термином формальные?

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

>Но есть факт, что ООСУБД уже присутствуют на рынке с 1995 и составляли тогда 3% от всех СУБД.

Это не ООСУБД, это нечто похожее на то, как мы себе представляем ООСУБД. Бейсик тоже присутствовал некоторое время и чем это закончилось? Еще раз повторяю, хотелось бы конечно пообсуждать новые СУБД, но обсуждать пока нечего, мы просто не поймем друг друга из-за различного понимания терминов.

>Но мы с Вами уже соглачились, что есть сложные типы приложений, для которых РСУБД не адекватна.

Вроде не соглашался. Я признал, что существуют задачи, для которых есть более удобные методы решения, чем РСУБД. Так с этим никто и не спорил.

>Значит там будут применять, скорее всего, использоваться ООСУБД или ОРСУБД.

Не значит. Для решения диффуров психически здоровые люди ООСУБД применять не будут. Разве что хранить результаты, что сейчас с успехом делается в РСУБД.
16 июн 04, 02:35    [743953]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vdimas
Member

Откуда: Севастополь
Сообщений: 1147
елки, 100 лет здесь не был, а тут такие споры :)
хочу вставить свои 5 копеек.

насчет формализации, считается, что нет единого определения ООП-подходу/языку/методологии. И не надо.

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

Итак, св-ва ООП как такового (как это принято считать сейчас), и как это соотнести с СУБД:

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

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

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

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

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

Т.е. ничто не мешает представить некую высокоуровневую абстракцию для РАЗРАБОТЧИКА под названием "инкапсуляция", а на "низком" уровне можно использовать практически любую современную СУБД (даже не ОО-), введя некие правила однозначного отображения имен методов и имен типов, к которым они принадлежат. (Я имею ввиду, что конечный SQL/DLL пусть рассматривается как некий "ассемблер", а разработка ведется на языке-надстройке над ним)

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

- наследование
Что происходит при наследовании? Некий ТИП наследует от базового:
  • внутреннюю структуру,
  • методы, оперирующие над наследованной структурой.

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

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

    - полиморфизм
    Полиморфизм позволяет нам абстрагировать МЕТОДЫ типов от конкретных ТИПОВ, обощая АЛГОРИТМЫ, успешно дополняя тем самым понятие "повторное использование кода". Итак, полиморфизм дополнительно экономит труд РАЗРАБОТЧИКА.

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

    ------------------------
    Итак, будем считать ОО-подход некоей методологией разработки ПО (способом, подходом), которая дает следующие бенефиты:
    1. помогает в процессе моделирования/абстрагирования
    2. предоставляет средства для декомпозиции (исходный код приобретает больше шансов стать упорядоченным и управляемым)
    3. помогает обощать/отделять алгоритмы от конкретных оперируемых типов.

    Если принять DDL/SQL за "низкий уровень", т.е. за результат работы некоего компилятора с некоего ОО ЯП для БД, то ОО-подход вполне достижим и сейчас на современных вовсе не ОО-СУБД.

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

    В принципе, для решения описанных проблем необходимо создать СУБД, которая могла бы оперировать не только над конкретной таблицей, а именно над некоей СТРУКТУРОЙ таблицы, и индеферентно относилась бы к конкретному экземпляру таблицы (главное, чтобы записи подаваемой таблицы удовлетворяли ожидаемой структуре). Согласитесь, что подобное введение никак не конфликтует с реляционной теорией :). (Ведь, это просто синтаксис SQL завязан на конкретные таблицы, что мешает дополнить этот синтаксис?)

    А так же неплохо было бы ввести понятие "индексированного" хранилища, где на уровне СУБД можно было бы хранить в некоей таблице лишь ссылки на экземпляры некоего семейства ТИПОВ. Все эти вещи ввести нетрудно, IMHO.

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

    ------------------
    сорри за длинный пост, по этой теме можно было и еще длинее :)
  • 16 июн 04, 13:48    [745144]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    Andrei N.Sobchuck
    Guest
    vdimas

    - наследование
    Что происходит при наследовании? Некий ТИП наследует от базового:
  • внутреннюю структуру,

  • Или не наследует. Что и происходит в ОО языках основанных не на классах, а на прототипировании.
    vdimas

    Итак, будем считать ОО-подход некоей методологией разработки ПО (способом, подходом), которая дает следующие бенефиты:
    1. помогает в процессе моделирования/абстрагирования
    2. предоставляет средства для декомпозиции (исходный код приобретает больше шансов стать упорядоченным и управляемым)
    3. помогает обощать/отделять алгоритмы от конкретных оперируемых типов.

    Вообще-то, все методологии и языки служат этим целям :)

    А инкапсуляция, наследование, полиморфизм не отправные точки в любых рассуждениях, а, просто напросто, "вторичные половые признаки" присущие майнстримовым языкам.
    vdimas

    Если принять DDL/SQL за "низкий уровень", т.е. за результат работы некоего компилятора с некоего ОО ЯП для БД, то ОО-подход вполне достижим и сейчас на современных вовсе не ОО-СУБД.

    Это у тебя получается банальный O/R mapping.
    vdimas

    сорри за длинный пост, по этой теме можно было и еще длинее :)

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

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

    если введено простое ограничение, то можно ввести аналогичное более сложное.

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

    c127

    Во первых не получения результатов, а только хранения и манипулированя данными.

    Манипулирование данными и предназачено для получения результатов - требуемой информации из определенным образом структурированных данных. Ведь это главная цель создания БД.
    c127

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

    >Ссылки надо искать. Но что Вы имеете в виду под термином формальные?

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

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

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


    c127


    Это не ООСУБД, это нечто похожее на то, как мы себе представляем ООСУБД. Бейсик тоже присутствовал некоторое время и чем это закончилось? Еще раз повторяю, хотелось бы конечно пообсуждать новые СУБД, но обсуждать пока нечего, мы просто не поймем друг друга из-за различного понимания терминов.


    Это вопрос терминов. И Бейсик не перестал бы быть бейском, если бы исчез. Хотя он есть, но с приставкой «Вижуал». Их называют ООРБ. Просто одни более ориентированные, чем другие. Ну можно их назвать похожими на ООРБ. Они есть и претендуют на захват части рынка. Значит, достойны обсуждения.

    c127

    Вроде не соглашался. Я признал, что существуют задачи, для которых есть более удобные методы решения, чем РСУБД. Так с этим никто и не спорил.


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

    Значит там будут применять, скорее всего, использоваться ООСУБД или ОРСУБД.

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

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

    vdimas

    ООП концентрирует свое внимание на ТИПАХ и ЭКЗЕМПЛЯРАХ типов, реляционная теория оперирует доменами и множествами. Учитывая, что любой конечный ТИП имеет некую конечную внутреннюю структуру (набор полей), к множеству экземпляров такого типа (и даже к множеству произвольных наследников такого типа, сохраняющих, как минимум, структуру базового типа) вполне применимо все из реляционной теории, нету никаких конфликтов :)))


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


    Р.S. Когда писал это, наши проигрывали - поэтому возможны неточности.
    16 июн 04, 23:54    [746719]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    c127
    Guest
    >Я не совсем понял Вашу позицию. Вы считаете, что после включения в РСУБД пользовательских типов она так и осталась реляционной?

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

    >Я бы тоже хотел, чтобы рел. модель была везде адекватной – мне так легче.

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

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

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

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

    >Отсюда видно, что с точки зрения структурирования данных уже просматриваются два способа структурирования: упорядоченное - кортежи и неупорядоченное члены. По сути две разные категории лежат в основе модели – Дуализм.

    Нет дуализма, упорядоченные множества это все те же множества. Кортеж очевидно легко записывется средствами теории множеств.

    >Это вопрос терминов. И Бейсик не перестал бы быть бейском, если бы исчез. Хотя он есть, но с приставкой «Вижуал».

    Нет уже бейсика. Приказал долго жить, сыграл в ящик в общем безвременно ушел от нас. Есть нечто под названием VB.NET, не совместимое с VB, который официально не поддерживается. Это другой язык и только отсутсвие формальных спецификаций позволяет называть его тем же словом. Попробовали то же самое сделать с дельфи-паскалем. С бейсиком по-моему удачный пример. За время его жизни в виде VB по крайней мере один раз его крепко поменяли - между версией 3 и версией 5, совместимость пропала. Была бы БНФ и прочие формальные вещи и в подобных мутациях не было бы необходимости, основные проблемы бы отсеялись на этапе проектирования. Это бы сильно сохранило время тех несчастных которые мигрировли приложения с одной версии на другую, но кто о них думает.

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

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

    >c127> Это не ООСУБД, это нечто похожее на то, как мы себе представляем ООСУБД.

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

    Так что если Вы хотите что-то пообсуждать, то я все-таки предлагаю начать со ссылок на более-менее серьезные источники, где хотя бы даны основные определения. У меня таких ссылок нет.
    17 июн 04, 02:10    [746775]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    c127
    Guest
    Фразу: "Попробовали то же самое сделать с дельфи-паскалем."
    следует читать как "Попробовали бы то же самое сделать с дельфи-паскалем."
    17 июн 04, 02:12    [746777]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    vdimas
    Member

    Откуда: Севастополь
    Сообщений: 1147
    Andrei N.Sobchuck
    Или не наследует. Что и происходит в ОО языках основанных не на классах, а на прототипировании.

    Подробней можно? (речь об интерфейсах?)

    Andrei N.Sobchuck
    Вообще-то, все методологии и языки служат этим целям :)

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

    ВСЕ методологии и языки??? ню-ню...
    из тех, которыми я владею - менее половины

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

    Я помню, что Алан Кей, изобредший термин ООП понимал его несколько иначе (объекты с внутренними состояниями, обмен сообщениями и пр. ерунда так и не ставшая востребованной В ЧИСТОМ ВИДЕ)... да и флаг ему в руки, и всем другим поборникам "чистоты теорий"... Теории ООП как таковой нет, ибо ООП - это как раз неплохой набор ПРАКТИК, наработанных еще в до-ООП времена. (Смотрим исходники тех же дров под Linux на "плоском" С и видим как инкапсуляцию, так и полиморфизм :), далее, в сообщениях WinAPI просматривается неявное наследование, например для структуры, подаваемой как аргумент сообщения WM_NOTIFY, просто из-за отсутсвия ср-в поддержки в не-ОО ЯП, такие вещи приходится эмулировать).

    Andrei N.Sobchuck
    Это у тебя получается банальный O/R mapping.

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

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

    Мне вообще трудно обсуждать эту тему, ибо термин O/R mapping изначально неккоректен, IMHO. (нельзя взаимно произвольно в произвольные моменты времени отображать объекты в памяти программы и в хранящей их СУБД)
    Для 99.99% подобных систем подошел бы скорее термин типа Object Storage. Более того, факт хранения неких данных во внешнем хранилище (обычно это только часть полей объектов, т.к. обычно хранят, повторю, только "устойчивые" состояния объектов), так вот, сам этот факт подтверждает, что система используется именно ради обработки/хранения этих самых "полезных" данных. А то, что разработчик прячет потом эти данные в приватных полях своих объектов - это только лишь выбранный им способ промежуточного (на уровне исходных кодов) представления информации, помогающий ему "думать". (назовем прикладные объекты в данном случае лишь "оберткой" над полезными данными, вот почему в привязке к СУБД я все время твержу о структуре объектов и их полях)
    17 июн 04, 07:02    [746822]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    vdimas
    Member

    Откуда: Севастополь
    Сообщений: 1147
    vadiminfo
    Я не совсем понял Вашу позицию. Вы считаете, что после включения в РСУБД пользовательских типов она так и осталась реляционной?
    Я то считаю, Вы фактически уже обсуждаете ОР модель, обсуждая пользовательские типы.
    Я тут выше первым моим постом на этой странице пытался показать, что можно использовать ОО-подход как раз для проектирования типов. Что есть тип в ООП в общем виде? Это некая запись c внутренними полями и определенными на этой записи операциями. Где тут противоречие с реляционной теорией? Просто можно использовать ОО-подход для получения описания конечного типа (скажем, через цепочку наследований). В том же С++ (весьма объектно-ориентированном языке) в run-time не делается никаких предположений о типах, процессор оперирует адресами и смещениями, так как он это делал бы с бинарником программы, скомпиленной, скажем не ОО-ориентированным простым С.

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

    Не обращайте внимания на новомодные словеса. Внутри у этих систем все по-старому, просто добавился еще один уровень/шаг м/у описательной частью типов и конкретными таблицами. Я бы давно перешел на какие-нить подобные системы (опробовал уже парочку довольно сильных систем из этой области), если бы был так же ууверен в их надежности и масштабируемости, как в MS SQL или ORACLE.
    17 июн 04, 12:58    [747724]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    Andrei N.Sobchuck
    Guest
    vdimas
    Andrei N.Sobchuck
    Или не наследует. Что и происходит в ОО языках основанных не на классах, а на прототипировании.

    Подробней можно? (речь об интерфейсах?)


    Нет. У объекта есть один или более "родителей", которым и делегируется реагирование на сообщения о которых не знает объект. Смена "родителей" возможна "на лету". Понятно, что наследование структуры "родителей" в такой схеме не возможно.

    vdimas

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

    Я повторюсь, что все языки и методологии создаются, чтобы "борьбы со сложностью (с целью уменьшения издержек производства ПО)" (всякие brainfuck-и отбрасываем, как приколы :). Или ты знаешь другие причины?
    vdimas

    Те языки, которые наиболее УДАЧНО помогают достичь этой цели и СТАЛИ мэйнстримовыми.

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

    Я помню, что Алан Кей, изобредший термин ООП понимал его несколько иначе (объекты с внутренними состояниями, обмен сообщениями и пр. ерунда так и не ставшая востребованной В ЧИСТОМ ВИДЕ)... да и флаг ему в руки, и всем другим
    поборникам "чистоты теорий"...

    "изобредший" - опечатка "по Фрейду" :)
    А если серьёзно, то у идеи "лишь объектов и сообщений" есть определённые обоснования. Смещение к "3-м китам" уменьшает эффект подхода.

    vdimas

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

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

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

    >Я не совсем понял Вашу позицию. Вы считаете, что после включения в РСУБД пользовательских типов она так и осталась реляционной?

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

    Повторюсь, что самое первое принято называть базовой (1970). Ее неадекватность даже для бизнес приложений была слишком очевидна. И в 1979 сам Кодд предложил расширенную модель (не смотря на то, что что-то вписывалось в реляционную алгебру очень красиво). Потом стали появляться другие расширения. Появился термин расширенная реляционная модель данных, под которым скрывались все расширения. При добавление в эти расширения пользовательского типа появился термин РО. Это термин используется в разных источниках. Использование этих терминов помогает лучше понимать друг друга при обсуждении моделей. Ведь мы должны их как-то отличать. А если все называть одним словом, то что получится?

    c127

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

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

    c127

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


    Это значит, скорее всего, что используется и вычисления и обработка информации в одной системе. Ну это отражено даже в названии факультетов.
    Есть информационные системы, а есть вычислительная математика. Там разные методы, теории. Да и выч. технику для ИС желателно иметь другую. Но пока это в основном техника ориентированная на вычисления.

    c127

    Нет дуализма, упорядоченные множества это все те же множества. Кортеж очевидно легко записывется средствами теории множеств.

    Кортеж можно представить в виде конструкции неупорядоченных множеств типа <а,b> := {a,{a,b}}, но это не дает никакой пользы для моделирования и ничего не меняет. Можно отрабазить тип записи Сетевой модели в отношениях (множествах) реляционной. Мы же не говорим что Сетевая и Реляционная модель - одно и то же.

    c127

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

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


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

    vdimas

    Я тут выше первым моим постом на этой странице пытался показать, что можно использовать ОО-подход как раз для проектирования типов. Что есть тип в ООП в общем виде? Это некая запись c внутренними полями и определенными на этой записи операциями. Где тут противоречие с реляционной теорией? Просто можно использовать ОО-подход для получения описания конечного типа (скажем, через цепочку наследований). В том же С++ (весьма объектно-ориентированном языке) в run-time не делается никаких предположений о типах, процессор оперирует адресами и смещениями, так как он это делал бы с бинарником программы, скомпиленной, скажем не ОО-ориентированным простым С.


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


    vdimas


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


    Я думал, что эже давно не новомодные словеса, а принятые для отличия от других моделей.
    17 июн 04, 16:56    [748754]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    vadiminfo
    Member

    Откуда: Обнинск
    Сообщений: 4802
    Извиняюсь за ошибки. Спешил - нужно было комп выключать.
    17 июн 04, 18:33    [749147]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    c127
    Guest
    2 vdimas

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

    Золотые слова. Только во что это вылилось в результате.

    2 vadiminfo

    >Повторюсь, что самое первое принято называть базовой (1970). ... Ведь мы должны их как-то отличать. А если все называть одним словом, то что получится?

    Ok, согласен, давайте уточним. Что мы называем ОРСУБД? Как мы называем ту модель, которая включает типы?

    >Ну это решение пректировщика. Пусть у него будет выбор. Но если Вы понимаете под РСУБД, то что принимваю за ОРСУБД, то она может оказаться и адекватной.

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

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

    >Есть информационные системы, а есть вычислительная математика. Там разные методы, теории. Да и выч. технику для ИС желателно иметь другую.

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

    >Кортеж можно представить в виде конструкции неупорядоченных множеств типа <а,b> := {a,{a,b}}, но это не дает никакой пользы для моделирования и ничего не меняет.

    Кортеж И ЕСТЬ упорядоченное множетво, а не меняет это ничего только потому, что те понятия, к которым сводится кортеж на момент его появления уже были формализованы. Можно было и обойтись без дополнительного определения, но это выбор автора. Та же история с доменом. Но без формализма РСУБД никто бы ИМХО не принял, как сейчас не принимают ООСУБД. В те годы и в голову никому не могло прийти поступать иначе, это сейчас нас мелкософт и Ко разбаловали.

    >Концепция и формализация не совсем одно и то же. И концепция (ии)
    есть. Их обсуждаю в этой же теме.


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

    Интересно было бы ознакомиться с концепцией ИИ.

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

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

    Следующий момент: необходимо гарантировать надежность системы. А о какой надежности можно говорить, если сами разработчики ООСУБД по-моему не очень понимают, что там у них в системе происходит, и что главное, что там должно происходить. Тоже без формализма не обойтись, только тут еще и теоремы нужно доказывать.
    18 июн 04, 00:34    [749521]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    vadiminfo
    Member

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

    >Повторюсь, что самое первое принято называть базовой (1970). ... Ведь мы должны их как-то отличать. А если все называть одним словом, то что получится?

    Ok, согласен, давайте уточним. Что мы называем ОРСУБД? Как мы называем ту модель, которая включает типы?

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

    с127

    >Кортеж можно представить в виде конструкции неупорядоченных множеств типа <а,b> := {a,{a,b}}, но это не дает никакой пользы для моделирования и ничего не меняет.

    Кортеж И ЕСТЬ упорядоченное множетво, а не меняет это ничего только потому, что те понятия, к которым сводится кортеж на момент его появления уже были формализованы. Можно было и обойтись без дополнительного определения, но это выбор автора. Та же история с доменом. Но без формализма РСУБД никто бы ИМХО не принял, как сейчас не принимают ООСУБД. В те годы и в голову никому не могло прийти поступать иначе, это сейчас нас мелкософт и Ко разбаловали

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

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

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

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

    Следующий момент: необходимо гарантировать надежность системы. А о какой надежности можно говорить, если сами разработчики ООСУБД по-моему не очень понимают, что там у них в системе происходит, и что главное, что там должно происходить. Тоже без формализма не обойтись, только тут еще и теоремы нужно доказывать.

    Вот, насчет, нет успеха как раз и интересно. Про ООСУБД я знаю, что объем продаж составлял 150 млн. дол в 1995 и прирост ожидался 50%, но это было менее 3% от всех СУБД. Есть ли у Вас, что про рыночные более свежие показатели? По ОРСУБД тоже ожидается, но тут как раз проблема в том, что они скрываются продуктах, которые имели успех как РСУБД. И могут и дальше использоваться как РСУБД, но декларируются как ОРСУБД.
    В проекте участвуют не только программисты, но и проектировщики, которые объяснят программистам. Без формального описания языка не возможно, а без формального описания типа модели возможно. А я уверен, что существует много проектировщиков, которые не знают формального описания реляционной модели, и тем ни менее проектируют успешные системы. Они знают, что есть таблицы (а слово отношение может сбить их с толку), у таблиц есть поля. А чего нельзя им СУБД не позволит. Т.е. они не в курсах, что где-то написано, что это реляционные таблицы, а чем они отличаются от других. Но в СУБД есть формальное описание и средств моделирования. И проектировщики знают конкретное СУБД, будь оно известно хоть по каким названием типа модели данных. Сам термин модель данных им не нужен. Есть формальное описание и в SQL3, но он тоже ближе к описанию языка. Это не то формальное описание модели, что есть у базовой реляционной модели. Это формальное описание средств моделирования данной СУБД. Но у разных СУБД, могут быть общие черты - использование объектов. Поэтому модель относится к классу - например, ООМД.
    Я, разумеется, согласен, что наличие формального описания общепринятой модели играет огромную роль для успеха. Но ради осторожности в оценках нельзя, наверное, сбрасывать со счетов и другие варианты. Кроме того, это описание может появиться на каком-то более позднем этапе. Можно сказать, что у ООМД нет и теоретического обоснования, что тоже недостаток. Но объявлять недостатки критическими тоже, по-моему, преждевременно.
    Вряд ли они не разобрались. Надежность все-таки не вопрос модели данных, а вопрос реализации системы, средств обеспечивающих надежность. Но формализмы, свои собственные у них есть. Более того, не только надежность, но и модели транзакций, например, не определяются моделью данных.
    На, самом деле, у нас подходы к оценкам отличаются только степенью осторожности. Но, мне кажется, что в плане перспектив положения дел по соотношению этих трех типов СУБД много неясного. Ближайшие 10 лет СУБД, использующие реляционные структуры и средства манипулирования данными не сойдут со сцены. В этом я относительно уверен. Хотя сам термин из названия СУБД может и устранится. Появится Универсальный Сервер – УСУБД. Или еще что, но там реляционная модель будет присутствовать.
    20 июн 04, 02:44    [752750]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    c127
    Guest
    vadiminfo

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

    А это и не обязательно, тут самое главное что есть четкое понимание, что такое кортеж. Это же касается других понятий и концепций РСУБД. Для ООСУБД, насколько мне известно, вообще никакого понимания нет.

    >И ставил только вопрос - насколько хорошо они согласуются.

    Они согласуются абсолютно, поскольку есть одно и то же. То что используются два термина есть вопрос удобства разговора, не больше.

    >Индоевропейские языки многозначны.

    По-моему все естетвенные языки многозначны, но я не эксперт. Просто не могу представить другого.

    >Формализация предполагает средства по устранению этого.

    Из наличия формального описания языка не следует отсутсвие многозначности в интерпретации. Избавление от многозначности интерпретаций ИМХО не есть цель формализации. Более того, формальная система может иметь различные интерпретации (они называются реализации). Пример - геометрия на плоскости и конечные геометрии есть реализации одной аксиоматической системы задаваемой аксиомами геометрии.

    Хотя может мы говорим о разных вещах, определение многозначности тут не встречалась.

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

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

    >Есть ли у Вас, что про рыночные более свежие показатели?

    Нет, я специально не интересовался этим вопросом. Пока просто смотрю вокруг и вижу, что никто не использует.

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

    Правильно, в том и смысл, что даже если разработчики и архитекторы не знают деталей, а их полностью никто не знает, то сервер будет работать надежно несмотря ни на что. По крайней мере гарантируется, что если вдруг с данными стало происходить что-то непонятное, то это проблема разработчика (может разработчика сервера), а не реляционной модели. Надежность обеспечивается тем, что 1) модель очень простая; 2) строится непосредственно на теории множеств, с которой народ возится не одну сотню лет и которая зарекомендовала себя как удобная система. Это же гарантирует, что всякая задача, имеющая решение, при необходимости, может и не идеально, но будет решена при разумных затратах труда. С точностью до здравого смысла. В ОО модели данных таких гарантий нет просто потому, что нет модели. Даже если построить, то получится несравнимо сложнее. А реализация естественно будет еще сложнее, т.е. менее надежная.
    23 июн 04, 07:11    [758972]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    Old Nick
    Member

    Откуда: Санкт-Петербург
    Сообщений: 3185
    Мне понравилось то что тут написал vdimas

    Я именно по такой методологии разработал ОО надстройку над реляционной СУБД и все получилось замечательно и инкапсуляция и наследование и полиморфизм.

    Но вот он тут пишет, что нужно абстрагироваться от конкретных таблиц. Мне не понятно зачем. Если у нас есть 2 класса - абстрактный объект и клиент. Клиент наследуется от абстракного объекта. Допустим, что у абстрактного объекта есть атрибут название, а у клиента добавляется атрибут адрес (оба строковые). Как в таком случае vdimas спроектирует таблицы? Если я правильно понял то так:

    Objects
    (
    OID int not null identity(1,1),
    Name varchar(100),
    primary key clustered (OID)
    )

    Clients
    (
    OID int not null identity(1,1),
    Name varchar(100),
    Address varchar(200),
    primary key clustered (OID)

    )

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

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

    А это и не обязательно, тут самое главное что есть четкое понимание, что такое кортеж. Это же касается других понятий и концепций РСУБД. Для ООСУБД, насколько мне известно, вообще никакого понимания нет.

    Как же нет? Объект может включать и кортежи. Да и другие структуры или ссылки на них. В том числе и объекты. В этом то как раз их сила. Нет общепринятой модели, ну хорошо, скажем универсальной. Это другое дело. А так разных пониманий про ОО БД. Много есть. Существует манифест ООСУБД (1989). В литературе упоминается стандарт ООМД группы ODMG.
    c127

    Они согласуются абсолютно, поскольку есть одно и то же. То что используются два термина есть вопрос удобства разговора, не больше.

    Это слишком сильные утверждения. Что не одно и то же - это точно. Например, потому, что есть области, где РСУБД неадекватно, а ОРСУБД адекватно. И уж тем более, в РСУБД только кортежи, а ОРСУБД и объекты, имеющие менее однородную структуру. На счет их абсолютного согласования тоже слишком смело. Например, объекты придется заталкивать в атрибуты отношений. При этом сильная однородность отношений может привести к каким-то ограничениям. Мне, кажется, что ничего абсолютно согласованного не бывает.
    c127

    По-моему все естетвенные языки многозначны, но я не эксперт. Просто не могу представить другого.

    Например, формальные языки описания данных или манипулирования данными избавлены по возможности от неоднозначности.
    c127

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

    Если группа лиц о чем-то и не может договориться, это еще ничего не значит.
    Реляционной модели никакие недоговоренности не помешали в свое время. Полиморфизм - свойство иметь много форм. Думаю, что если производитель включит полиморфизм в свой продукт, поддерживающий ОО, то не ошибется. Даже если с кем-то и не договорится.
    c127

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

    Здесь, наверное, мы опять используем термины по разному. Термин надежность. Вы говорите, скорее, о рисках проекта. Я под надежностью понимал вопросы, связанные с отказоустойчивостью. Т.е. то, что описано в теории надежности. Если говорить про риски, то простота способа структурирования данных не всегда залог успеха. Мы же помним про области где, например, РСУБД неадекватна. Именно решение там будет непомерно сложным, и модель окажется, скорее всего, чрезвычайно сложной. Хотя способ структурирования простой. Но и однородный, а там это может не подойти. Т.е. и риски не снижаются простотой способа структурирования в общем случае. Ну а теория множеств дает возможность большего теоретического обоснования. Что, конечно, снижает риски для тех задач, для которых РСУБД в принципе подходит. Но ООСУБД уже имеет репутацию как средство именно для сложных предметных областей. И теперь пытается избавиться от этого, чтобы применяться и для более простых, где господствует РСУБД. И в этом у нее одна из трудностей.
    Но мы с Вами пошли по кругу. Видимо, упустили какие-то важные детали.
    25 июн 04, 00:58    [764491]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    c127
    Guest
    >Но мы с Вами пошли по кругу. Видимо, упустили какие-то важные детали.

    Да. Для того, чтоб разорвать круг еще раз предлагаю выдать мне ссылки на источники по ООСУБД, ОО и пр., те, которые Вы считаете наиболее удачными. Я почитаю, может после этого будет легче общаться. Только желательно в интернете или в крайнем случае на англоязычные источники.

    >Как же нет? Объект может включать и кортежи.

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

    >Это слишком сильные утверждения. Что не одно и то же - это точно. Например, потому, что есть области, где РСУБД неадекватно, а ОРСУБД адекватно.

    Речь шла только о том, что кортеж и множество это одно и то же. Хотя в реализации в SQL серверах, согласен, это разные вещи.

    c127>По-моему все естетвенные языки многозначны, ...

    vadiminfo>Например, формальные языки описания данных или манипулирования данными избавлены по возможности от неоднозначности.


    Речь шла о естественных языках.

    >Если группа лиц о чем-то и не может договориться, это еще ничего не значит.
    Реляционной модели никакие недоговоренности не помешали в свое время. Полиморфизм - свойство иметь много форм. Думаю, что если производитель включит полиморфизм в свой продукт, поддерживающий ОО, то не ошибется. Даже если с кем-то и не договорится.


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

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

    Т.е. РСУБД обладает свойствами "существования" (или "непротиворечивости") и "полноты". Это уникальный случай, других таких моделей вроде бы не предвидется.

    >Здесь, наверное, мы опять используем термины по разному. Термин надежность. Вы говорите, скорее, о рисках проекта. Я под надежностью понимал вопросы, связанные с отказоустойчивостью.

    Нет, я под надежностью тоже понимаю надежность сервера. Сложнее схема - сложнее сервер а значит (теоретически) ниже его надежность. Значит больше усилий нужно затрачивать чтоб доказать, что с бесценными данными ничего плохого никогда не случится. Поэтому закономерно, что к ООСУБД относятся с такой настороженностью.
    26 июн 04, 01:42    [767287]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    vadiminfo
    Member

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

    Да. Для того, чтоб разорвать круг еще раз предлагаю выдать мне ссылки на источники по ООСУБД, ОО и пр., те, которые Вы считаете наиболее удачными. Я почитаю, может после этого будет легче общаться. Только желательно в интернете или в крайнем случае на англоязычные источники.

    Ну, я в основном пользовался книгами. В инете с помощью поисковиков можно найти разные мысли по поводу ОО МД или ОО БД. Они просто могут быть в других терминах, чем те что я использовал.
    c127

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

    Что такое объект известно в той же степени, в какой известно, что такое сущность.
    Тут не совсем понял. И в реляционной модели тоже разным проектировщикам, если не начхать друг на друга, то видеть модель по разному можно. Я уже говорил, что критериев оптимальной схемы не найдено. Т.е. проектировщик в РСУБД в общем случае стоит перед выбором – в чем-то выигрывает, в чем-то проигрывает.
    Насчет того, что никто не использует, Вы сами сказали, что у Вас сведений нет.
    c127

    Речь шла только о том, что кортеж и множество это одно и то же. Хотя в реализации в SQL серверах, согласен, это разные вещи.


    Кортеж упорядоченное множество. Т.е. <a,b> не равно <b,a>, тогда как множества {a,b} и {b,a} равны. Но в объектно-ориентированном подходе члены можно рассматривать как кортежи, но это другая модель. Кроме реляционной модели Кодда, существуют и другие реляционные модели. Я об этом писал. Т.е. не все что содержит отношения есть реляционная модель Кодда. Отношение одна из наиболее общих конструкций теории множества, которая нашла применение во многих разделах математики, не имеющих ничего общего с реляционной моделью.

    c127

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

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

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

    Т.е. РСУБД обладает свойствами "существования" (или "непротиворечивости") и "полноты". Это уникальный случай, других таких моделей вроде бы не предвидется.

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

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

    Боюсь, что теоретического здесь слишком мало для теории надежности. Кроме того, тогда получается, что примитивные СУБД надежней. ОРАКЛ достаточно сложная система, но в плане надежности может поспорить с более простыми.
    Есть разные модели надежности систем, позволяющие сложным системам обладать высокой надежностью. Резервирование и все такое. У нас полетел физически сервак, но юзера почти не заметили - перешли на резервный сервер. Фактор модели, даже если его и привистовать искусственно в расчеты надежности, наверное, слишком мал и потеряется в других показателях.
    26 июн 04, 23:33    [767605]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    c127
    Guest
    2 vadiminfo

    >Насчет того, что никто не использует, Вы сами сказали, что у Вас сведений нет.

    Не говорил. На вопрос есть ли у меня более свежие данные о статистике использования ООСУБД я ответил вот так:"c127>Нет, я специально не интересовался этим вопросом. Пока просто смотрю вокруг и вижу, что никто не использует."

    >Ну, я в основном пользовался книгами. В инете с помощью поисковиков можно найти разные мысли по поводу ОО МД или ОО БД. Они просто могут быть в других терминах, чем те что я использовал.

    Вот и сообщите мне эти ссылки, на книги в том числе, если не жалко. Самому искать лень, там много мусора и хороших источников мало.

    >Это что-то уже из разделов математической логики. Дедуктивных теорий.

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

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

    Да есть там все. От теории множеств до реляционной модели данных один маленький шаг. Кодд это заметил - честь ему и хвала. Вы знаете за что Эйнштейн получил нобелевскую премию? h*w=A+m*v^2/2 - формула фотоэффекта. Этого оказалось достаточно, а у Кодда, по объему, даже больше получается. Потому РСУБД и завоевали рынок, что в принципе ничего не было выдумано, все основы уже были подготовлены и, что важно, это все замечательно и надежно работало в других областях.

    В любом случае есть факт, что реальных конкурентов у РСУБД в данный момент нет. По-моему это закономерный результат, по-Вашему - нет, но результат есть.

    А вообще не надоело ходить по кругу? По-моему пора заканчивать. Дайте ссылки на основы ООБД, КОТОРЫЕ (ссылки) ВЫ СЧИТАЕТЕ НАИЛУЧШИМИ, я постараюсь прочитать, потом продолжим на более предметной основе, если будет желание.
    29 июн 04, 03:48    [770066]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    U-gene
    Member

    Откуда: Москва. Россия
    Сообщений: 1576
    vadiminfo
    Кортеж упорядоченное множество. Т.е. <a,b> не равно <b,a>, тогда как множества {a,b} и {b,a} равны.


    Эта... как это? Вот эту мыслю - про то, что кортеж, это упорядоченное множество - поподробней можно? Как то это не согласуется со, скажем, те ми же Дейтовскими "Основами баз данных" где то ли в третьей, то ли в четвертой главе он пишет что одним из признаков отношение есть неупорядоченность атрибутов. В более сУрьезной книжке Мейера, отношение рассматривается через отображение из множества имен атрибутов в множество доменов... то есть, опять же не о каком упорядочивании речи не идет.....В общем хочется услышать что-нить поподробнее об упорядочивании, иначе, начиная с этого места, к топикам уважаемого vadiminfo я начну относится несерьезно:)

    vadiminfo

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


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

    Не надо в сотый раз говорить, что рел модель данных полна семантики - ее так вообще нет. Если начну соединять отношения
    А(a,b,c#)  
    В(#c,d,e) 
    то, несмотря на определнность результата, это будет казаться бессмысленным до тех пор пока я не скажу, что скажем А - это заголовки отгрузок, а В - это строки отгрузок. Тут уж проявиться некая cемантика. А еще лучше если я эти отношения так и обзову
    SaleHeaders(Date, Warehouse, No#)
    SaleItems(No#, Article, Pieces)
    и тогда семантики будет выше крыши.... но результат определяемой в рел. модели данных операции соединения от этой семантики НИКАК ЗАВИСЕТЬ НЕ БУДЕТ, потому что семантика исключительно в именах, а единственное требование, которое рел. модель предьявляет к именам - уникальность.
    29 июн 04, 12:06    [770826]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    vadiminfo
    Member

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

    Да есть там все. От теории множеств до реляционной модели данных один маленький шаг. Кодд это заметил - честь ему и хвала. Вы знаете за что Эйнштейн получил нобелевскую премию? h*w=A+m*v^2/2 - формула фотоэффекта. Этого оказалось достаточно, а у Кодда, по объему, даже больше получается. Потому РСУБД и завоевали рынок, что в принципе ничего не было выдумано, все основы уже были подготовлены и, что важно, это все замечательно и надежно работало в других областях.

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

    В любом случае есть факт, что реальных конкурентов у РСУБД в данный момент нет. По-моему это закономерный результат, по-Вашему - нет, но результат есть.

    Вот это факт и нуждался в проверке. Но мы не смогли здесь ничего сказать.
    c127

    А вообще не надоело ходить по кругу? По-моему пора заканчивать. Дайте ссылки на основы ООБД, КОТОРЫЕ (ссылки) ВЫ СЧИТАЕТЕ НАИЛУЧШИМИ, я постараюсь прочитать, потом продолжим на более предметной основе, если будет желание.

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


    U-gene

    Эта... как это? Вот эту мыслю - про то, что кортеж, это упорядоченное множество - поподробней можно? Как то это не согласуется со, скажем, те ми же Дейтовскими "Основами баз данных" где то ли в третьей, то ли в четвертой главе он пишет что одним из признаков отношение есть неупорядоченность атрибутов. В более сУрьезной книжке Мейера, отношение рассматривается через отображение из множества имен атрибутов в множество доменов... то есть, опять же не о каком упорядочивании речи не идет.....В общем хочется услышать что-нить поподробнее об упорядочивании, иначе, начиная с этого места, к топикам уважаемого vadiminfo я начну относится несерьезно:)

    То что кортеж упорядоченное множество, то это просто из теории множеств.
    Отношение в теории множества есть подмножество декартова произведения.
    Так, любое комплексное число бинарный кортеж. Уберите упорядоченность и что получите? 2+3i = 3+2i? Какая от этого польза?
    Иногда используют прямое произведение и вместо кортежей функции из множества индексов в семейство множеств индексированных этим множеством индексов. Почти подошли к аксиоме выбора.
    Особенно такой подход используется для бесконечных множеств индексов, для конечных декартово произведение. Впрочем в разделах алгебры эти термины иногда перегружаются. Книжка Мейера, насколько я понимаю, "Теория реляционных баз данных". Там, насколько я помню, оговаривается, что для теоретических аспектов, рассматриваемых в этой книге, порядок атрибутов ничего не дает, и после этого вводят те отображения, о которых Вы говорили. Т.е. они абстрагируются от конкретного порядка конкретного отношения. И изучают, например, функциональные зависимости между атрибутами, порядок не накладывает на свойства этих зависимостей никакого отпечатка. Т.е. не отрицают, а всего лишь абстрагируются для своих целей.
    U-gene

    Не надо в сотый раз говорить, что рел модель данных полна семантики - ее так вообще нет. Если начну соединять отношения
    А(a,b,c#)
    В(#c,d,e)
    то, несмотря на определнность результата, это будет казаться бессмысленным до тех пор пока я не скажу, что скажем А - это заголовки отгрузок, а В - это строки отгрузок. Тут уж проявиться некая cемантика. А еще лучше если я эти отношения так и обзову SaleHeaders(Date, Warehouse, No#)
    SaleItems(No#, Article, Pieces)
    и тогда семантики будет выше крыши.... но результат определяемой в рел. модели данных операции соединения от этой семантики НИКАК ЗАВИСЕТЬ НЕ БУДЕТ, потому что семантика исключительно в именах, а единственное требование, которое рел. модель предьявляет к именам - уникальность.

    Бухгалтер тоже складывает числа, результат, которых определен. Что теперь в бухгалтерских моделях нет никакой семантики?
    Модель данных должна обеспечить интерпретацию данных. Отсюда и роль семантики. В теоретических аспектах семантика может и не играть значения, хотя могу напомнить слова из Мейера, о том что функциональные зависимости, которые не могут быть выведены из других имеют семантическую природу. Бытует такое мнение, что некоторые авторы не придают должного значения семантике. Но иногда говорят, что Кодд придумывал свою модель ради повышения независимости данных от прикладных программ, работающих с этими данными (даже не идеи алгебры и теории множеств были первотолчком). А для того, чтобы данные были независимы, и даже могли, например, продолжать жизнь после завершения жизненного цикла информационной системы, информационная модель и в первую очередь механизм их интерпретации должны храниться вместе с данными. Вы все-таки сконцентрировались на теоретических аспектах. Они важны, хотя многие проектируют и не зная теории толком. Но вот без семантики проектировать нельзя однозначно. Если бы реляционная модель была бы как угодно теор. обоснована, но имела сложную интерпретацию, то не известно где бы она была. Так есть утверждения о том, что логики исчисления предикатов второго порядка хватило бы, чтобы описать и получать результаты для достаточно сложных ПО, но трудность ее восприятия не позволяет рассчитывать на успех от ее применения для моделирования данных.
    29 июн 04, 16:48    [772214]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    SergSuper
    Member

    Откуда: SPb
    Сообщений: 5488
    vadiminfo
    Бухгалтер тоже складывает числа, результат, которых определен. Что теперь в бухгалтерских моделях нет никакой семантики?

    А Вы что, по бухгалтерскому балансу сможете отличить ликёроводочный завод от завода резинотехнических изделий?
    29 июн 04, 19:49    [772818]     Ответить | Цитировать Сообщить модератору
     Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
    vadiminfo
    Member

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

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

    Это означает еще большую роль семантики. Я про это и пытаюсь сказать. Мы моделируем в том числе и для того, чтобы отличать. Теория множеств различет множества с точностью до изоморфизма. А модель должна отличить алкогольные предриятия от каучуковых в том числе. И чем выразительнее она будет это позволять делать, тем лучше. Для математического обоснования модели теория множеств, конечно, имеет важное значение. Но это разные аспекты модели данных. Главная цель как можно лучше организовать данные, чтобы как можно легче было извлекать необходимую информацию. Для этого важны, в частности, и семантичиская выразительность, и система запросов модели.
    29 июн 04, 22:46    [772975]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 .. 12 13 14 15 16 [17] 18 19 20 21 .. 83   вперед  Ctrl
    Все форумы / Сравнение СУБД Ответить