Классика баз данных - статьи

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


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

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

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

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

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



Содержание раздела