![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Эволюция схемы
Проектирование представляет собой пошаговый процесс, который развивается со временем. Для поддержки этого процесса приложениям требуются достаточно гибкие средства динамического определения и изменения схемы базы данных. Например, система должна допускать изменение определений классов, структуры наследования и спецификации атрибутов и методов без необходимости ее остановки и перезагрузки. Концепция модификации схемы тесно связана с рассмотренной выше концепцией управления версиями. Вопросы, возникающие в процессе эволюции схемы, весьма сложны, и не все они достаточно хорошо исследованы. Ниже перечислены типичные изменения, которые может потребоваться внести в схему базы данных. 1. Изменение определения класса (изменение атрибутов, изменение методов); 2. Изменение иерархии наследования: определение класса как суперкласса, удаление класса из списка суперклассов, изменение порядка суперклассов класса; 3. Изменения набора классов, например создание и удаление классов, изменение имен классов. Вносимые в схему изменения не должны переводить ее в несогласованное состояние. В ООСУБД обычно определены правила согласованности схемы, называемые инвариантами схемы, которые должны соблюдаться при любой модификации схемы. 4. Разрешение конфликтов, вызванных множественным наследованием и переопределением атрибутов и методов в подклассе. 5. Распространение изменений на подклассы. Изменения атрибутов/методов в классе всегда наследуются его подклассами, за исключением тех подклассов, в которых этот атрибут/метод был переопределен. 6. Правило распространения изменений в случае возникновения конфликтов. Введение нового атрибута/метода или изменение имени атрибута/метода распространяется только на те подклассы, для которых не возникает конфликтов имен. 7. Правило изменения доменов. Домен атрибута может быть изменен только с помощью обобщения. Домен унаследованного атрибута не может быть более общим, чем домен исходного атрибута в суперклассе. 8. Агрегирование и удаление наследственных связей между классами в процессе создания или удаления классов. 2.5. Документ «Манифест разработчиков объектно-ориентированных систем баз данных» В документе «Манифест разработчиков объектно-ориентированных систем баз данных» предлагается тринадцать обязательных характеристик, которым должна отвечать любая ООСУБД. Их выбор основан на двух критериях: система должна быть объектно-ориентированной и представлять собой СУБД. Первые восемь правил относятся к критерию объектной ориентированности.
|