Эволюция систем, насыщенных данными

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

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

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

Функциональная эволюция систем

Функциональные требования системы данных выражаются технологическинезависимым образом посредством концептуальной схемы базы данных, содержащей типы сущностей, атрибуты и типы связей. Эта схема транслируется в физическую, которая отвечает некоторым нефункциональным требованиям, таким как целевая технология баз данных. Наконец, эта схема кодируется с использованием языка определения данных (data definition language, DDL) соответствующей СУБД.

Как показано на рисунке, любое изменение функциональных бизнес-требований приводит к необходимости синхронной модификации четырех компонентов: схемы базы данных; ее содержимого; программ, взаимодействующих с этой базой данных; проектных моделей. Например, если требуется разделить ранее слитные бизнес-объекты «счет» (invoice) и «поставка» (shipment), то соответствующую таблицу данных INVOICE будет необходимо расщепить на две новые — INVOICE и SHIPMENT, ее содержимое перераспределить по новым таблицам, поменяв операторы доступа к данным в программах, чтобы они были согласованы с новой схемой базы данных.

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

Нефункциональная эволюция систем

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

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

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

Более сложный метод семантической миграции приводит к целевым схемам, полностью соответствующим современным стандартам качества и производительности. Он состоит в трансляции концептуальной схемы исходной базы данных в целевую физическую модель. В этом случае отображение «источник-цель» может быть более сложным: один тип записи может быть распределен по нескольким таблицам или записи нескольких типов могут быть слиты в одну таблицу. Более сложен и процесс преобразования данных, но если мы можем положиться на точность описания отображения схем, то параметры для процессов извлечения-преобразования-загрузки (Extract-Transform-Load, ETL) могут генерироваться автоматически.

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

Потребность в обратной инженерии баз данных

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

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

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

Понимание программ для понимания баз данных

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

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

Текущие проблемы

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

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

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

Рост использования динамического SQL. В стандартных подходах к обратной инженерии баз данных интенсивно используются методы статического анализа программ, которые равным образом применимы к жестко заданному статическому SQL, однако многие современные системы разрабатываются с использованием динамического SQL. В этом случае операторы SQL образуются во время выполнения программы и посылаются серверу баз данных на основе специальных API, таких как Open Database Connectivity (ODBC) или Java Database Connectivity (JDBC). В таких программах статический анализ часто оказывается мало полезным, что вынуждает разработчиков применять методы динамического анализа программ для перехвата точного вида операторов SQL и лучшего понимания логики программы.

Разработка программ на основе ORM. В системах, насыщенных данными, прикладные программы взаимодействуют с базами данных через внешнее представление данных. Все более популярное связующее программное обеспечение объектно-реляционного отображения (Object-Relational Mapping, ORM) позволяет программистам использовать внешнюю объектно-ориентированную схему базы данных, что снижает уровень воздействия проблемы «потери соответствия» (impedance mismatch) между моделями программирования и базы данных. Однако в действительности эта технология только ухудшает ситуацию, поскольку теперь физическая и внешняя схемы могут эволюционировать асинхронно, с разной скоростью, а отвечают за это независимые группы. В результате наличия недисциплинированных процессов эволюции между компонентами системы могут постепенно образоваться серьезные несоответствия.

***

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

Энтони Клив (anthony.cleve@inria.fr)  — аспирант докторантуры INRIA (Франция); Том Менс (tom.mens@umons.ac.be)  — профессор Университета Монс-Эно (Бельгия); Жан-Люк Эно (jlh@info.fundp.ac.be)  — профессор Университета Намюр (Бельгия)