Реляционно-сетевая модель данных

Реляционная модель потеряла свою исключительность


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


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


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


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


«Красота» и строгость реляционной модели, реализуемой на SQL, на протяжении 3-х десятков лет восхищали программистов. «Старые» модели: сетевая или иерархическая были почти забыты. Да программных продуктов таких почти не осталось, за исключением, пожалуй, «почти бессмертной» IDMS [1].


В последнее десятилетие идет активная работа по созданию альтернативных систем управления БД (СУБД), которые так просто и называются – NoSQL. Под это понятие сейчас подпадают очень разные системы, которые сильно отличаются между собой. Интересно, что «старые» сетевая и иерархическая модели в понятие NoSQL не входят! Хорошие обзоры в этой области можно найти в [2,3,4].


В категорию NoSQL включают «графовые» БД [5], которые абстрактно близки к канонической сетевой модели CODASYL [6]. Как и следует из самого названия, такие системы представляют собой два неорганизованных множества – узлы (вершины) и ребра (дуги). Главное преимущество сетевых БД – навигация «определяется» не в момент обработки запроса, как в РБД, а в момент добавления новых данных (для графов — вершин и ребер), полностью справедливо и для графовых систем. Но графовая БД не структурирована до начала ее наполнения, в отличие от БД по CODASYL.


Другие самые популярные классы NoSQL БД – «ключ-значение» (пример — Redis [7]) и «хранилище документов» (пример — MongoDB [8]). Так как детальный обзор подобных систем не есть цель настоящей статьи, важно отметить только следующее.


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


В итого на сегодня ситуация примерно следующая: 75% БД – реляционные, NoSQL в чистом виде используются в узко специализированных системах, а комбинации различных моделей БД применяют в высоконагруженных глобальных сетевых проектах: Google, Facebook, Instagram, WhatsApp и подобных.


Реляционные базы данных без SQL


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


Помимо порой чрезмерной «жесткости» реляционной модели, крупный ее практический (не теоретический) недостаток – сложность манипулирования данными. Первый вариант – использование конвейера операций над множествами – объединения, пересечения, фильтрации и т.п. на практике вообще почти не используется, так как связан с затратами колоссальных ресурсов и оправдан только при «пакетной» обработке множеств однотипных запросов. Второй вариант – интерпретатор языка SQL требует высокого профессионализма, хорошего знания теории множеств, теории баз данных, и немалого практического опыта.


Объектно-ориентированное программирование (ООП) в языках стало стандартом, но SQL – процедурный язык и очень плохо «дружит» с ООП. Вследствие этого популярность приобрело решение задачи стыковки программного кода приложений с запросами на SQL на основе библиотеки классов под названием ORM (Object-Relational Mapping — объектно-реляционное отображение (преобразование) [9]).


Использование классов ORM позволяет программисту обходится без SQL при использовании РБД. ORM автоматически генерирует запросы на SQL к РБД для создания таблиц и манипулирования данными. Большинство ORM имеют интерфейсы с различными популярными СУБД – SQLite, MySQL, PostgreSQL и другими, что дает выбор без модификации программного кода.


Реализаций ORM имеется масса, даже по несколько для каждого языка программирования. Все они похожи, поэтому для определённости в дальнейшем под ORM будем понимать соответствующую библиотеку (пакет) models класса Model фреймворка Django [10] на языке Python [11].


ORM очень «удобно» и программисты не особо задумываются, что, используя этот API, они получают не только преимущества реляционной модели, но все ее недостатки. Например, в самом коде нельзя переопределять модели таблиц – добавить или удалить столбец, добавить новую таблицу и т.п. Чтобы сделать миграцию БД, надо сначала переписать код, потом «подняться этажом выше», и после этого перезапустить программу. В итоге невозможно создать приложение, который предусматривает даже простейшие изменения схемы данных в процессе работы программы без изменения самой программы.


Поиск данных в ORM реализуется применением цепочек методов, например, “objects.all()”, “objects.get(…)”, “objects.filter(…)” в Django. Просто, красиво и удобно, но к какой алгоритмической сложности исполнения SQL-запросов, сгенерированных ORM, это приведет, не видно «невооруженным» взглядом.


Когда SQL-запрос пишет человек, предполагается, что он думает и понимает затраты вычислительных ресурсов. ORM вуалирует эту задачу.


Гипертаблица как база данных нового поколения


Нами разработана новая концепция, методы и практические способы объединить реляционную и сетевую модели БД с преимуществами идеи ORM – отказ от использования специальных языков запросов, что позволило создать новую модель и технологию баз данных.


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

  1. «реляционные» атрибуты (домены данных), значениями которых, как в РБД, являются поля строк с самоопределенными данными по соответствующим столбцам таблиц
  2. «сетевые» атрибуты (домены ссылок). Будем называть их АТС – атрибут типа «ссылка»

Значениями полей АТС в строках таблицы являются явные ссылки на любые строки в любых таблицах, входящих в гипертаблицу.

Понятие гипертаблицы, введённое нами, никак не связано с проектом [13], который был свернут в 2016 году.


Имеется действующий прототип — комплекс инструментальных средств на языке Python – система управления гипертаблицами HTMS (Hyper Table Management System), в которую входят следующие уровни (сверху вниз):

  • редактор (клиент) гипертаблиц HTed – технологический вспомогательный сервис, реализованный как веб-сайт на фреймворке Django, который может подключаться к любому серверу с гипертаблицей независимо от приложений (до некоторой степени функционально близок к утилите PgAdmin для PostgeSQL);
  • библиотека утилит и классов логического уровня – API для создания БД и манипулирования данными на прикладном уровне программирования (замена ORM);
  • библиотека утилит и классов физического уровня работы с БД, на которой основаны утилиты и классы логического уровня (как API может использоваться опытными системными программистами);
  • класс Cage, который предназначен для создания на стороне клиента (приложения) «виртуального» слоя кэшированного удаленного доступа к файлам БД;
  • файл-сервер CageServer – программное обеспечение, работающее в мультипрограммном и многопоточном режиме, реализующее функции для многопользовательского удаленного доступа к файлам на сервере по протоколу TCP.

Принципиально возможно вместо Cage использовать обычную локальную файловую подсистему ОС для управления файлами, а также использовать API Cage и ПО CageServer как независимый от HTMS инструмент для реализации удаленного распределенного файлового доступа в любых системах.


В дальнейших статьях планируется подробнее познакомить читателей с системой HTMS.


Литература
1. IDMS — en.wikipedia.org/wiki/IDMS
2. The Types of Modern Databases / John Hammink — Database Zone, Mar. 09, 2018 — dzone.com/articles/the-types-of-modern-databases
3. Неструктурированные базы данных (NoSQL) / Андрей Волков – Oracle Patches, Nov. 14, 2018 — oracle-patches.com/db/nosql/3739
4. Реляционные базы данных обречены? (пер. с англ.) / Tony Bain — habr.com/ru/post/103021/
5. Графовые базы данных / Aida — Oracle Patches, Oct.29, 18 — oracle-patches.com/db/3680-графовые-базы-данных
6. CODASYL — en.wikipedia.org/wiki/CODASYL
7. Redis — redis.io
8. MongoDB — www.mongodb.com
9. Odysseus/DFS: Integration of DBMS and Distributed File System for Transaction Processing of Big Data / Jun-Sung Kim and other — College of Information Science and Technology, Drexel University, Philadelphia, USA, 2014
10. Object-relational mapping — en.wikipedia.org/wiki/Object-relational_mapping
11. Django Software Foundation — www.djangoproject.com
12. Python Software Foundation — www.python.org
13. Hypertable — www.hypertable.com
Поделиться публикацией

Комментарии 13

    +3

    Привет, роботам. На OrientDB не смотрели?

      +1

      В начале 80-х я познакомился с семантической моделью данных Abrial (Abrial, J.R.: Data semantics. In: Klimbie, K. (ed.) Data Management Systems. North-Holland, Amsterdam (1974)). Она меня покорила. Я даже написал СУБД "Бинар" в далеких 1980-1982 г.г. и несколько статей. К сожалению они были в закрытом сборнике. Так что можно посмотреть не только на OrientDB, но и на Абриалевскую модель представления данныых.

        0
        Есть ли статья Abrial, J.R в электронном виде?
          0

          К сожаления, я пока найти не смог. Я меня был оригинал, но куда-то запропостился. Есть еще изданный перевод в Советской союзе книги: А. Цикритзис, Ф. Лоховски. Модели данных. Москва, "Финансы и статистика", 1985 год. Хороших обзор различных моделей данных.
          Лично я написал по этому поводу несколько статей. Более того даже написал СУБД "Бинар", правдв на ЕС ЭВМ и ПЛ/1. Давно это было. При создании стенда имитационного моделирования в рамках программы АнтиСОИ мы тоже ориентировались на Абриаля, его модель. В 1987 году вышла моя книжка В.Орлов "Основы построения систем автоматизации проектирования", шестая глава в которой была написана по материалам Абриаля и называлась"Модель представления и манипулирования в САПР". Книга была издана в Министерстве Обороны СССР.
          Если найдете раньше, — сообщите.

        0
        А чем не устраивает SPARQL?
          +1
          Отвергая реляционную модель вы предлагаете низкоуровневую концепцию уровня начальной школы. То есть вместо близкого по уровню абстракции к реляционной модели описания вашего подхода вы пишете про какой-то класс, какие-то библиотеки, какой-то файл-сервер и т.д.

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

          Ну и аргументы против реляционной модели — неопытные разработчики могут накосячить. А в вашей вселенной с яблоками они накосячить не могут?
            –1
            Проблема в том, что ниспровергатели реляционной модели знают её довольно поверхностно и критикуют часто «таблицы» (которых в реляционной модели нет) и язык SQL (который стройную картину отношений разрушает) т.е. мешают те вещи, которые имеют к реляционной модели косвенное отношение.
              +1
              Я не отвергаю реляционную модель, читайте внимательно, любитель фруктов. Я считаю ее теоретической основой математически строгого моделирования структур данных.
              Мои разработки — это fork от реляционной модели.
              Кстати, на днях на Хабре появился отличный обзор в данной области — https://habr.com/ru/post/462493/
              0

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

                0
                Объектно-ориентированное программирование (ООП) в языках стало стандартом, но SQL – процедурный язык и очень плохо «дружит» с ООП.

                отлично дружит с ООП.
                В категорию NoSQL включают «графовые» БД [5]
                а они тоже внезапно реляционные только, если обычные эквивалентны грубо говоря статической типизации, то эти — динамической. И кстати даже у меня есть примерная идея как представить любой граф любой формы в обычном SQL.
                  0
                  Реляционная модель — универсальна, в нее можно уложить структуру и работать с ней на SQL. Но из универсальности вытекают и практические недостатки.
                  0

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


                  И кстати даже у меня есть примерная идея как представить любой граф любой формы в обычном SQL.

                  Это реально трэш.

                    0
                    абсолютно согласен

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

                  Самое читаемое