CC BY
83
Казакова. Е.А., Шибанов С.В. , Хмелевской Б.Г.
ПРОБЛЕМА ВЫБОРА МОДЕЛИ ДАННЫХ ДЛЯ ХРАНЕНИЯ СЛОЖНЫХ СТРУКТУР ДАННЫХ И КЛАССОВ
В программных приложениях данные представляются в виде объектов, коллекций объектов и всевозможных связей между ними, а также в виде структур данных - массивов, списков, стеков, очередей, деревьев, графов. Поэтому разработчику необходимы инструменты для хранения и обработки объектов, коллекций объектов, связей между ними и структур данных в долговременной памяти. Приступая к проектированию приложения, разработчики должны выбрать модель данных и соответствующую методологию моделирования данных.
Современным приложениям, в том числе, информационным системам приходится манипулировать огромными массивами данных, которые невозможно хранить только в оперативной памяти. Необходимо сохранять данные между сеансами работы программы или для передачи данных для обработки другим приложениям. При этом данные должны легко, быстро и в удобном для использования виде извлекаться из хранилища, обрабатываться и помещаться обратно. Поэтому перед разработчиком программного обеспечения (ПО) встает проблема методов и средств хранения данных в долговременной памяти.
Внутри программных приложений данные представляются в виде различных объектов, коллекций объектов и всевозможных связей между ними, а также в виде структур данных - массивов, списков, стеков, очередей, деревьев, графов. Поэтому разработчику ПО необходимы инструменты для хранения и обработки объектов, коллекций объектов, связей между ними и структур данных в долговременной памяти.
Для решения этой задачи существует несколько подходов:
использование плоских файлов и ПО для управления ими;
использование специализированных хранилищ, таких как Storage от Microsoft;
использование систем управления базами данных (СУБД).
Первый подход требует разработки ПО для управления плоскими файлами и данными. Второй подход также требует создания промежуточного ПО между приложением и хранилищем. Оба подхода обладают слабой интероперабильностью к другим способам и средствам хранения данных. СУБД лишены этих недостатков, так как предоставляют готовые и универсальные интерфейсы для обработки данных.
На сегодняшний момент существует несколько типов СУБД, поддерживающие соответствующую модель данных: иерархические, сетевые, реляционные, объектно-ориентированные. Каждый из типов СУБД обладает
своими достоинствами и недостатками. Иерархические и сетевые СУБД предназначены для обработки иерархий и сетей соответственно, но для работы с неиерархическими или несетевыми данными требуют разработки специализированных жестко определенных запросов. Иерархические и сетевые СУБД морально устарели, да и найти их реализацию под IBM PC совместимые компьютеры с операционными системами Windows от компании Microsoft проблематично, а именно на этой программно-технической платформе приходится работать многим разработчиками ПО. Объектно-ориентированные СУБД хорошо работают с объектами и коллекциями объектов, но не имеют универсальных и стандартизованных интерфейсов обработки данных. Реляционные СУБД (РСУБД) обладают неоспоримыми преимуществами по сравнению с другими: основаны на формальной математической модели, являются своего рода стандартом хранения данных, занимают львиную долю рынка СУБД. В то же время РСУБД, как и другие СУБД, непосредственно не поддерживает хранение и обработку сложных структур данных, таких как списки, массивы, деревья, графы, стеки и очереди.
Приступая к проектированию приложения, разработчики должны выбрать модель данных и соответствующую методологию моделирования данных. По большей части, выбор производится между традиционным способом моделирования с помощью реляционных таблиц и современным подходом - моделированию в форме объектов. Многие разработчики утверждают, что объектное моделирование более эффективно для сложных информационных структур, с которыми сегодня приходится иметь дело.
Реляционная модель наиболее формализована из всех представленных моделей. И на данный момент реляционные СУБД (РСУБД) занимают львиную долю рынка СУБД. РСУБД являются своего рода стандартом хранения данных. Одной из проблем разработки информационных систем на основе реляционных баз данных является то, что логически связанный проект распадается на две различные части, реализуемые с помощью различных средств: проектирование и разработка схемы базы данных и проектирование и разработка
программного кода. Реляционная модель непосредственно не поддерживает хранение сложных структур данных, таких как массивы, списки, стеки, очереди, бинарные и сильно ветвящиеся деревья, графы. Тем самым реляционные отношения уже не удовлетворяют современным требованиям к абстракции представления данных.
Современные приложения создаются обычно с использованием объектной технологии, которая допускает более быстрый и более интуитивный способ описания и использования информации. Ускоряется разработка и увеличивается надежность. К сожалению, объекты не совместимы с реляционными базами данных естественным образом. Преимущества объектной технологии теряются, когда конечные объекты в базе данных должны быть помещены в двумерную реляционную модель.
Технология объектной СУБД (ОСУБД) предполагает существенное интегрирование языковой среды, которая одновременно позволяет конструировать объектную базу данных, но и программный код.
Основные трудности объектно-ориентированного моделирования данных проистекают из того, что такого развитого математического аппарата, на который могла бы опираться общая объектно-ориентированная модель данных, не существует. С другой стороны, общая объектно-ориентированная модель данных в классическом смысле и не может быть определена по причине непригодности классического понятия модели данных к парадигме объектной ориентированности. Современная ситуация с ООБД напоминает ситуацию с реляционными системами середины 1970-х годов. При наличии большого количества экспериментальных проектов (и даже коммерческих систем) отсутствует общепринятая объектно-ориентированная модель данных, и не потому, что нет ни одной разработанной полной модели, а по причине отсутствия общего согласия о принятии какой-либо модели. На самом деле, имеются и более конкретные проблемы, связанные с разработкой декларативных языков запросов, выполнением и оптимизацией запросов, формулированием и поддержанием ограничений целостности, синхронизацией доступа и управлением транзакциями и т.д.
Кроме ООБД, можно рассматривать и вариант отображения схем баз данных в на схему языка программирования. Объектно-реляционное отображение (ORM - object relational mapper) - это библиотека языка программирования, выполняющая отображение объектов реляционной модели (отношения, строки и атрибуты) на объекты языка программирования (классы, экземпляры, методы, атрибуты). Отображение это обычно двунаправлено: манипуляции с атрибутами объекта приводят к чтению информации из (и записи в) соответствующие таблицы базы данных. Могут также поддерживаться искусственные атрибуты (транслирующие значения в колонках таблицы во что-то более содержательное для прикладной задачи). При использовании ORM- библиотек, программист манипулирует привычными элементами языка программирования - классами, объектами (экземплярами классов), атрибутами и методами и может получить автоматически сгенерированные SQL-запросов. Но реализации ORM бывают сильно негибки. Они могут требовать своей собственной схемы БД, и могут не быть применены к базам данных, созданным другими средствам.
В то время как реляционные СУБД используются преимущественно в экономике и бизнесе, ОСУБД зачастую внедряются в менее масштабные, но более наукоемкие области. Преимущества ОСУБД проявляются там, где требуются сложные структуры данных и интенсивные вычисления. В объектной технологии все сложности структур данных скрываются внутри объектов, а доступ к информации осуществляется через простой унифицированный интерфейс. Реляционная технология также предлагает простой унифицированный интерфейс, однако формат хранения данных упрощен настолько, насколько это возможно, поэтому все проблемы, связанные с обработкой сложной информации, ложатся на плечи пользователей и программистов.
Требования, предъявляемы к модели данных, могут существенно отличаться. Пользователям- предметникам нужны модели данных самого высокого уровня, описывающие доступную для использования информацию. Разработчикам баз данных и прикладных программ нужны модели, точно определяющие структуру данных. Администраторы баз данных работают с моделями, содержащими спецификацию физической структуры данных, что бы решать задачи повышения производительности и оптимизации функционирования системы.
При построение логической модели данных можно выделить два подхода: предметно-ориентированный и
универсальный. Таким образом, можно говорить о двух видах логических моделей данных: предметно-
ориентированной и универсальной модели данных.
В предметно-ориентированной модели метаданные играют служебную роль и не являются частью логической модели, в то время как в универсальной модели метаданные - существенная и неотъемлемая часть логической модели. При внесении изменений в логическую модель универсальный подход имеет неоспоримое преимущество, но при этом можно потерять привычную естественность запросов к базе данных, которую имеет предметно-ориентированная модель. Но для универсальной модели полнотекстовый поиск программируется и выполняется быстрее.
Две модели хранения данных в равной степени применимы и к реляционным, и к объектным базам данных. Выбор между предметно-ориентированной и универсальной моделями данных является весьма сложной и нетривиальной задачей, которая зависит от множества факторов простота составления и зачастую может быть окончательно решена только экспериментальным путем.
Обеспечение эксплуатационных характеристик базы данных - по-прежнему непростая задача, несмотря на повышение удельной мощности компьютеров и снижение удельной стоимости памяти. При определении временных характеристик работы с базой данных и сохранение этих характеристик в процессе эксплуатации базы данных относится к трудным проектным задачам. Поэтому необходимо разработчикам предоставить выбор или синхронизацию или дублирование между обеими моделями. Один и тот же запрос можно адресовать как одной схеме хранения данных, так и другой, что даст возможность практического тестирования производительности и выбора наилучшей модели для конкретной базы данных.
Представляется актуальной разработка система автоматизации процесса отображения структур данных и классов приложений, которая предоставляла возможность выбора вида логической модели данных (предметно-ориентированную, универсальную или смешанную). Результатами могут быть как реляционная модель данных, так и объектно-ориентированная модель данных или описание данных для ОЫМ-библиотек. Это позволит выполнить предварительный анализ полученных вариантов моделей данных для моделируемой предметной области по заданным характеристикам (например, объем базы данных, скорость выполнения запросов к базе данных, возможность реорганизации и т.д.).
