Объекты + отношения. Это не просто. Это очень просто.

добавлено: 19 апр 13
понравилось:0
просмотров: 2459
комментов: 8

теги:

Автор: U-gene

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

Говоря про то, что тема запутана, я подразумеваю клубок ненужной логики, накрученной даже не на заблуждения, а на привычные, часто неосознаваемые шаблоны, что, в свою очередь порождает, новые шаблоны. Вот примеры типичных шаблонов: термин "целевая машина" ассоциируется с "фон-неймановской архитектурой", "иерархические структуры" с "навигацией по ссылкам", "реляционная модель данных" с "плоскими таблицами". Новым шаблоном является, например, "object-relational impedance mismatch" (IM). Удобная, кстати, штука, что бы оправдывать неудачные попытки соединения объектов и отношений: "Это трудно, потому что IM". С другой стороны, если вспомнить, что IM определяется как набор трудностей при соединении объектов и отношений, то поневоле приходят на ум непонятные Лемовские сепульки. В общем, все эти трудности носят чисто психологический характер. Их не надо преодолевать, про них можно забыть.

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

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

Обращаю внимание, что
1)показан прототип, предназначенный для демонстрации принципа объектно-реляционной интеграции, поэтому в нем
-реализована лишь часть функционала СУБД (отсутствуют, например, обычные таблицы, нет XML, хотя он местами очень просится, и тд.)
-используется весьма условный язык
2)практическим результатом является не новая СУБД, а способ развития существующих РСУБД. (короче, никаких революций или NoSQLя).
3) Это не ORM и не application server. Это СУБД.

Отвечу на любые ваши вопросы.

Хотелось бы услышать мнения по следующим вопросам.
1) После OРСУБД никаких серьезных попыток в этом направлении сделано не было. Тема совсем заглохла. Почему? Не нужно или не смогли?
2) Какими могут быть инструменты для разработчика и для пользователя такой СУБД?

А вообще, приветствуются любые конструктивные мысли.



Есть бумажные материалы:
Немного концепции
Описание системы (урезанный вариант видео)
Математика


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

Комментарии


  • 03 мая 2013, 15:01 defragmentator

    Ничего нового на первый взгляд. Классы успешно используются в ОРМ.

  • Классы успешно используются много где. :)

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

    Надо обратить внимание не только на то, ЧТО сделано (очень знакомые ОО выражения), а и на то КАК и ГДЕ они реализованы.

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

    - ГДЕ. В РСУБД. Я _не_ предлагаю новый язык, систему, программирования, ORM-систему или аппликэйшн сервер. Особо отмечу, что и внутри RxO-системы отдельно взятые "объекты" тоже нигде не прячутся (а то у людей порой возникает впечатление, что я организовал прямо внутри СУБД мэппинг между какими-то "внутренними" объектами и таблицами.) Предлагается ОО система управления реляционными базами данных. Речь идет о (еще раз) нескольких новых командах, которые расширяют SQL до полноценного ОО языка. В результате получается инструмент, который позволяет моделировать предметную и в ОО и в реляционных терминах прямо в СУБД (и развивать эту модель по мере надобности – см. пред.пункт) .

    Возможно, Вы знаете, о ОРСУБД. Это КМК самое близкое, с чем можно сравнивать.

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

  • 06 мая 2013, 10:05 defragmentator

    Я работал с DevExpress (XAF). Но там классы соответствуют реальным объектам (таблицам или view). Естественно, при добавлении нового класса (таблицы в БД) приходится перекомпилировать программу. С таким, чтобы добавлять классы динамически, честно говоря, никогда не сталкивался, ни в одном языке программирования.

  • Так как автор статьи любит эпиграфы предложу еще один: "Тяжелый случай некомпетентности" "Сон разума порождает чудовищ"

    Итак, что имелось в виду:

    1. Имеется хорошо изученная ОБЩАЯ теория реляционных отношений между любыми... объектами. Имя ей - реляционная алгебра. Конечно никому не интересно ее учить, а уж тем более применять на практике.

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

    3. ООП также является одной из попыток применения РЕЛЯЦИОННОЙ алгебры отношений между множествами сущностей. Опять же, в силу различных объективных причин, в "современных" ЯП (C#, Java) практическая реализация ООП далека как от реляционной алгебры, так и от классического объектного взаимодействия.

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

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

  • Это еще один шаблон. Сформировался, похоже, под влиянием Дейта, но как то очень своеобразно.

    1) "Теорией" может называться только то, что может быть формализовано. Есть формальное определение понятия "отношение" (в терминах теории множеств), есть такое же формальное определение ограничений целостности, есть формальное описание операций над отношениями. Возьмите книгу Мейера "Теория реляционных баз данных" (http://www.twirpx.com/file/100951/), там в первых главах всё это дано. Никаких "отношений между объектами там и рядом не валялось"- только буковки и значочки. Все остальные красивые слова, и даже мысли ( в том числе об общей "общая теория реляционных отношениях между объектами") – это применения и интерпретации этого формализма. Кто как может, то так и применяет. Например, у Дейта накручено то, что многие (в том числе он сам) называют "развитием РМ". Но попробуйте доказать, что РМ (формализм, о котором я пищу) не может развиться в другую сторону.

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

    3) "… ООП также является одной из попыток применения РЕЛЯЦИОННОЙ алгебры …"ю :) Забавная фраза. Пруфлинк дайте хотя бы, где такое написано, я много странного видел, но такого припомнить не могу.

    4) " В итоге,…"… Исходя их сказанного, не ясно, откуда Вы этот итог вообще взяли?

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

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

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

  • посмотрел презентацию. Вместо этого я бы посоветовал больше отдавать предпочтение принципу K.I.S.S. Но в любом случае- успехов!

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

    А с точки зрения пользователя, это даже и не новый инструмент. Речь идет об развитии обычных РСУБД, об обычном SQL, куда добавлено несколько команд, которые делают эту СУБД заодно и полноценной ОО системой. Это даже не KISS, а эволюция в направлении MISS (от слова make).

    За добрые пожелания - спасибо.



Необходимо войти на сайт, чтобы оставлять комментарии