Эволюция схемы

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

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

1. Изменение определения класса (изменение атрибутов, изменение методов);

2. Изменение иерархии наследования: определение класса как суперкласса, удаление класса из списка суперклассов, изменение порядка суперклассов класса;

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

4. Разрешение конфликтов, вызванных множественным наследованием и переопределением атрибутов и методов в подклассе.

5. Распространение изменений на подклассы. Изменения атрибутов/методов в классе всегда наследуются его подклассами, за исключением тех подклассов, в которых этот атрибут/метод был переопределен.

6. Правило распространения изменений в случае возникновения конфликтов. Введение нового атрибута/метода или изменение имени атрибута/метода распространяется только на те подклассы, для которых не возникает конфликтов имен.

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

8. Агрегирование и удаление наследственных связей между классами в процессе создания или удаления классов.

2.5. Документ «Манифест разработчиков объектно-ориентированных систем баз данных»

В документе «Манифест разработчиков объектно-ориентированных систем баз данных» предлагается тринадцать обязательных характеристик, которым должна отвечать любая ООСУБД. Их выбор основан на двух критериях: система должна быть объектно-ориентированной и представлять собой СУБД. Первые восемь правил относятся к критерию объектной ориентированности.