Функциональная эволюция систем
Если иметь в виду системы данных, то функциональные требования выражаются технологически-независимым образом посредством концептуальной схемы базы данных, содержащей типы сущностей, атрибуты и типы связей. Эта схема затем транслируется в физическую схему, которая отвечает некоторым нефункциональным требованиям, таким как целевая технология баз данных. Наконец, эта схема кодируется с использованием языка определения данных (data definition language, DDL) соответствующей СУБД.
Рис. 1. Эволяция системы, насыщенной данными. Этот процесс включает взаимосвязанное преобразование схемы, данных, программ и проектных моделей.
Как показывает рис. 1, любое изменение функциональных бизнес-требований приводит к необходимости синхронной модификации четырех компонентов: схемы базы данных, содержимого базы данных, программ, взаимодействующих с этой базой данных и проектных моделей, которым должны соответствовать модели. Например, если нам потребуется разделить ранее слитые бизнес-объекты "счет" ("invoice") и "поставка" ("shipment"), то соответствующую таблицу данных INVOICE будет необходимо расщепить на две новых таблицы INVOICE и SHIPMENT, ее содержимое придется перераспределить по новым таблицам, и нужно будет поменять операторы доступа к данным в программах, чтобы они были согласованы с новой схемой базы данных.
В идеальном мире функциональные изменения транслируются в изменения спецификаций – в частности, проектных моделей и концептуальной схемы базы данных. Мы удаляем объекты схемы, добавляем новые объекты и модифицируем некоторые существующие объекты. Эти операции распространяются на физическую схему, в которой соответствующим образом удаляются, создаются и модифицируются таблицы, столбцы и ключи. Поскольку это изменяет семантику данных, последующие операции преобразования данных и изменения программ нельзя полностью автоматизировать, это возможно разве что при весьма незначительных модификациях.
