Software & Systems

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

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

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

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

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

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

В качестве механизма взаимодействия приложения с БД наиболее часто используется система объектно-реляционного преобразования, или ORM-система (Object relation mapping). ORM-системы призваны решить проблему хранения объектов в РБД путем создания промежуточного слоя, выполняющего это преобразование автоматически.

В настоящее время разработано множество подобных систем для различных объектных языков программирования, таких как Hibernate, iBatis для Java; NHibernate, Vanatec open access (VOA), eXpress persistent objects (XPO), DataObjects.NET, .NET entity objects (NEO), написанные для C#; Prado, Doctrine для PHP и т.д. Все они имеют различную эффективность работы и способы представления данных в БД. С точки зрения программиста, ORM-система является системой с длительным хранением персистентных объектов.

Использование ORM-системы уменьшает многократно повторяющийся код манипулирования данными в программе. В архитектуре приложения можно четко разделить слой хранения данных, поддерживаемый СУБД, и слой прикладных объектов («бизнес-объектов»).

Преимущества ORM-системы особенно очевидны при разработке систем, осуществляющих транзакционную обработку данных (OLTP), сложные расчеты, диспетчеризацию, оповещение о событиях и т.д.

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

С целью уменьшения затрат на получение данных из БД и загрузку доменных объектов в приложение можно использовать механизм кэширования. Причем данные могут кэшироваться в оперативной памяти, файле или даже в БД. Физически кэш может располагаться на стороне сервера или на стороне клиента. Кэширование позволяет получить быстрый доступ к данным, которые часто используются в приложении, например, к агрегированным данным. Приведем пример интерфейса кэша на языке PHP.

interface ICacheStorage { 

  const DEFAULT_CACHE_GROUP = 'default';

  public function validate($key, $group =

self::DEFAULT_CACHE_GROUP);

  public function putValue($value, $key,

$group = self::DEFAULT_CACHE_GROUP,

$expired_time = null);

  public function getValue($key, $group =

self::DEFAULT_CACHE_GROUP);

  public function flushValue($key, $group =

self::DEFAULT_CACHE_GROUP);

  public function flushGroup($group =

self::DEFAULT_CACHE_GROUP);

  public function flushAll();

}

Интерфейс ICacheStorage предоставляет следующие методы:

­                                 putValue() сохраняет значение в кэше;

­                                 getValue() возвращает значение по ключу и по имени группы;

­                                 validate() проверяет актуальность информации в кэше (например, по времени);

­                                 flushValue(), flushGroup и flushAll() очищают кэш с данными по ключу, по названию группы или весь кэш полностью.

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

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

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

Для апробации предложенного механизма кэширования интерфейс ICacheStorage был реализован в классе FileCacheStorage при разработке web-сервиса Livents.ru – онлайнового календаря событий, тематику которых посетители определяют самостоятельно. Пользователь может выбирать интересные для себя события, участвовать в них или создавать свои, о которых через Livents узнают другие). Класс FileCacheStorage осуществляет кэширование в текстовом файле результатов запросов к БД, отдельных фрагментов и содержимого всей web-страницы. Использование кэширования позволило сократить время загрузки страниц в среднем с 2 до 0,5 с.