Содержание к диссертации
Введение
1. Анализ проблем проектирования и моделирования систем, имеющих в своем составе сервер БД 9
1.1 Преимущества и особенности объектной разработки информационных систем 9
1.2 Возможности и ограничения реляционных структур баз данных по поддержке методологии разработки 16
1.2.1. Равноправие атрибутов отношений 18
1.2.2. Ограниченный набор базовых типов 19
1.2.3. Фиксированность методов хранения и доступа 19
1.2.4. Отсутствие списочных структур 20
1.2.5. Отсутствие иерархической подчиненности типов данных 21
1.3 Объектно-ориентированные базы данных и их использование.. 23
1.4. Объектно-реляционные СУБД 27
1.5. Задачи интеграции объектной разработки с реляционным сервером 31
1.6. Выводы по главе 40
2. Реляционная и объектная модели. постановка задачи отображения 43
2.1. Модели в задачах проектирования и реализации БД 43
2.1.1. Концептуальная модель (прикладного домена) 45
2.1.2. Логическая модель (данных) 46
2.1.3. Физическая модель (хранения) 47
2.1.4. Использование объектной модели на концептуальном и
логическом уровнях 47
2.2. Основные характеристики объектных моделей 50
2.2.1. Стандарты и профили хранения объектов 57
2.3. Формализация задачи отображения моделей данных 58
2.4. Выводы по главе 62
3. Исследование методов отображения объектной модели в реляционную 63
3.1. Идентификация объекта в РБД 66
3.2. Отображение объектов изолированного класса 72
3.3. Отображение в таблицы ассоциаций 75
3.3.1. Отображение в реляционную модель ассоциации "один к одному" 76
3.3.2. Отображение в реляционную модель ассоциации "один ко многим" 81
3.3.3. Отображение в реляционную модель ассоциации "один ко многим" с квалификатором 97
3.3.4. Отображение в реляционную модель ассоциации "многие ко многим" 99
3.3.5.. Отражение в таблицы тернарной ассоциации 109
3.4. Отражение решетки наследования классов в реляционную модель 111
3.4.1. Вариант 1. Все классы хранятся в одной таблице 114
3.4.2. Вариант 2. Каждый конкретный (не абстрактный) класс хранится в одной таблице 116
3.4.3. Вариант 3. Отдельная таблица для каждого класса 118
3.4.4. Сравнительный анализ вариантов отражения отношения наследования 122
3.4.5. Множественное наследование 125
3.4.6. Нестандартные типы атрибутов 127
3.4.7. Агрегация 128
3.5. Интегрированная методика структурного моделирования 129
3.6. Выводы по главе 131
4. Исследование вопросов построения объектно-реляционного сервера 133
4.1. Концептуальная модель сервера объектного представления 133
4.1.1. Сущности 134
4.1.2. Поля сущностей 137
4.2. Исследование функциональных аспектов 141
4.3. Разработка архитектуры сервера объектного построения 150
4.3.1. Механизм хранения объектов 150
4.3.2. Динамические аспекты 155
4.4. Выводы по главе 159
5. Вопросы реализации специального рограммного обеспечения 160
5.1. Подсистемы и шаблоны проектирования для сервера объектного представления 160
5.2. Интерфейс для отражения объектной модели 164
5.3. Выводы по главе 173
Заключение 174
Литература 176
- Преимущества и особенности объектной разработки информационных систем
- Модели в задачах проектирования и реализации БД
- Отображение объектов изолированного класса
- Исследование функциональных аспектов
Введение к работе
Обращаясь к истории развития и совершенствования информационных систем, выполняющих поддержание целостности и актуализацию данных с помощью СУБД, можно выделить три основных этапа [31]. Причем если переход от первого этапа развития СУБД ко второму связан с изменением только модели хранения данных (от иерархической и сетевой моделей к реляционной), то эволюция СУБД от второго к третьему этапу определяется сменой целой парадигмы программирования - от структурной к объектно-ориентированной.
СУБД третьего поколения - это сложные многофункциональные программные системы, работающие в открытой распределенной среде. Поэтому, для них характерно использование идей [40]: активного сервера БД; многопотоковой архитектуры; фрагментации и параллельной обработки запросов; управления распределенными базами данных; технологии тиражирования данных; объектно-ориентированного подхода.
При этом, в базе данных, помимо собственно данных и непосредственных связей между ними, должны храниться знания о данных, а она сама должна адекватно отражать процессы, происходящие в реальном мире. Соответственно, необходимо иметь средства хранения и управления такой информацией.
Для реализации указанных требований и наиболее полного использования преимуществ объектной парадигмы программирования, которая стала стандартом создания информационных систем, стали разрабатываться объектно-ориентированные БД (ООБД). Можно выделить три характерные черты современного состояния дел по их созданию [54]: отсутствие общепринятой модели данных. В то время как классическая статья Кодда предоставила отчетливую спецификацию систем реляционных баз данных (модель данных и язык запросов), для ООСУБД подобная спецификация отсутствует. Предлагаются различные варианты, но отсутствует единое мнение о том, что из себя представляет объектно-ориентированная база данных; активная экспериментаторская деятельность. Ведутся многочисленные экспериментальные разработки. Ситуация похожа на ситуацию с системами реляционных баз данных в середине семидесятых. Однако, в случае реляционных систем, существовала общепринятая основополагающая модель. Специалисты занимались, главным образом, разработкой технологии реализации. Сегодня же одновременно и решается проблема спецификации системы и создается технология для поддержки ее реализации.
Сказанное приводит к тому, что не существует мощных, имеющих устойчивое положение ООБД.
При этом необходимо не забывать, что огромные инвестиции уже вложены в реляционные СУБД такие как INFORMIX или ORACLE.
Из сказанного следует, что одной из насущных задач является разработка архитектур, методик проектирования и реализации ОО систем обработки информации, опирающихся на классические реляционные СУБД. Ключевыми проблемами в реализации данного подхода являются:
Анализ возможных методов отражения объектных структур в реляционные. Выбор оптимального метода (методов) отражения.
Разработка методов и алгоритмов принятия решений и обработки информации при реляционном представлении объектных схем.
З. Исследование вопросов создания специального математического и программного обеспечения систем, обеспечивающих их реализацию, в том числе архитектурного построения и функциональной организации.
Цель работы. Работа посвящена исследованию вопросов интеграции объектно-ориентированной парадигмы создания информационных систем и реляционных серверов баз данных на основе отражения абстрактных типов данных в реляционную модель. Цель достигается через создание методик проектирования информационных систем, создаваемых с использованием объектно-ориентированного подхода к их разработке и реализации, и имеющих в своем составе реляционный или объектно-реляционный сервер базы данных.
В соответствии с поставленной целью в работе:
Проанализированы особенности принятия решений и обработки информации при создании информационных систем, опирающихся на сервер базы данных. Произведен анализ всех трех существующих в настоящее время типов серверов: реляционного, объектного и объектно - реляционного (глава 1).
Рассмотрены возможности формализации реляционной и объектной моделей данных и постановки задачи взаимного отражения одной модели в другую (глава 2).
Исследованы методы отражения объектных структур в реляционные. Предложены количественные и качественные критерии сравнения методов и отбора оптимальных. На основании результатов исследований отобраны оптимальные методы отражения объектной модели в реляционную. Последние объединены в методику принятия решений и обработки информации при отображении абстрактных типов данных в реляционные схемы (глава 3).
Сделаны предложения по построению и функциональным особенностям специального программного обеспечения для поддержки полученных методов и алгоритмов принятия решений и обработки информации. Обоснованы его архитектура и функциональная организация. Данное программное обеспечение названо в работе объектно-реляционным сервером (глава 4).
Проведены экспериментальные проверки на тестовых задачах адекватности и состоятельности методов и алгоритмов отражения (глава 5).
Использованные методы исследования включают:
Аналитические методы: теорию множеств и математическую логику, теорию конечных автоматов, графов, сетей и языков программирования.
Аналитико-экспериментальные методы - вычислительный эксперимент в виде имитационного моделирования на ЭВМ объектов исследования, предпосылок и процедур разрабатываемых методик, их сравнения с альтернативными, известными из литературы.
Соискателем получены следующие результаты, имеющие научную новизну:
Предложены оптимальные методы отражения объектной модели в реляционную.
Построена методика реляционного моделирования объектной модели данными методами.
Сформулирована интегрированная методика проектирования объектных информационных систем, использующих реляционные или объектно-реляционные сервера баз данных.
Предложена архитектура и функциональная организация систем реализации.
На защиту выносятся:
Результаты исследований возможных методов отражения объектной модели в реляционную.
Методика реляционного моделирования объектной модели предложенными оптимальными методами отражения объектной модели в реляционную.
Архитектура и функциональная организация сервера объектно — реляционного сервера
4. Объектная модель сервера объектного представления. Практическая ценность работы состоит в том, что полученные результаты позволяют снизить сроки разработки информационных систем, повысить их качество, эффективность и надежность, обеспечить семантическую, сущностную и ссылочную целостность хранения абстрактных типов данных, использовать активный реляционный сервер РСУБД для контроля состояния типов данных, определенных разработчиком, отслеживания всех изменений в них и адекватной реакции эти изменения.
В заключении хочу поблагодарить моих научных руководителей -профессора Григорьева В. А. и профессора Виноградова Г.П. за доброжелательное отношение к работе и оказанную мне в ней помощь.
Преимущества и особенности объектной разработки информационных систем
Сложность создания программно обеспечения определяется, в целом, тремя основными причинами [18,2-6]: 1) сложностью прикладного домена; 2) трудностями, возникающими в процессе управления процессом разработки; 3) высокими требованиями к гибкости программного обеспечения. Соответственно, приступая к созданию информационной системы (ИС) необходимо, прежде всего, выбрать отвечающую предъявляемым требованиям и сложности задачи парадигму программирования, т.е. систему взглядов, с учетом которой решаются задачи программирования, а также ту или иную методологию проектирования программного средства. Анализ известных парадигм: от хаотической, через функциональную, структурную, модульную до объектной; показал, что основной стимул всех изменений парадигмы, через которые прошла технология программирования, являлась декомпозиция, которая, в свою очередь, основана на использовании абстракции [1,55]. Все изменения шли в сторону построения абстрактного типа данных. Абстрактный тип данных - тип данных, определяемый программистом, с теми же возможностями работы с ним, что и у встроенных типов данных. Чтобы создать абстрактный тип данных, необходимо иметь возможности для [87]: 1) расширения определений типов; 2) определения операций, которые будут использоваться для манипулирования экземплярами данного типа; 3) защиты данных, ассоциированных с данным типом так, чтобы они были доступны только для соответствующих этому типу процедур; 4) создания множества экземпляров данного типа. Модули структурно-модульной парадигмы - отвечают только требованиям 2 и 3. Предоставляя достаточно эффективный способ сокрытия информации, они не дают возможности конкретизации (instantiation) абстрактных типов, которая необходима при создании различных их экземпляров. Это, а также отсутствие возможности наследования, не позволяет рассматривать их как действительно абстрактный тип данных. Только объектно-ориентированный подход позволил в достаточной мере решить данные проблемы. Выбирая ту или иную парадигму программирования необходимо учитывать системы процедур, правил и инструментальных средств, используемых для проектирования и разработки программной системы. Для достижения эффективности нужно объединить приемы выбранной парадигмы программирования с методологией проектирования системы. Различные методологии проектирования системы могут объединяться с разными парадигмами программирования, порождая тем самым, самые разнообразные технологии создания программных средств [17]. На сегодняшний день в инженерии программного обеспечения существуют два основных подхода к разработке программных систем, различие между которыми обусловлено критериями декомпозиции [22]. Первый подход называют функционально - модульным или структурным и в его основу положен принцип алгоритмической декомпозиции, которая выделяет функциональные элементы системы, и устанавливает строгую древовидную иерархию выделенных элементов. Методы структурного проектирования работают на уровне проектирования архитектуры системы и реализуются через парадигмы структурного или, в лучшем случае, модульного программирования, со всеми вытекающими из этого достоинствами и недостатками. Преимущество функциональной декомпозиции (т.е. декомпозиции по решаемым функциям) в ясности и универсальности. Недостатки непредсказуемость и изменчивость, т.к. функции не являются наиболее стабильной частью системы, а наоборот, такой наиболее стабильной частью являются структуры данных. Наиболее опасными последствиями применения структурного подхода являются [27]: 1) фокусирование внимания на внешнем интерфейсе. Однако в больших системах интерфейс имеет тенденцию быть наиболее изменчивым. Поэтому, при разработке системы важно отделить, насколько возможно, интерфейс от других частей системы. Подход же "сверху-вниз" кладет этот поверхностный аспект системы в основу ее структуры; 2) преждевременное фиксирование временных взаимосвязей (порядок, в котором действия должны быть выполнены). Разработка "сверху-вниз" предполагает, что каждая система может быть подходящим образом описана на абстрактном уровне своей единственной основной функцией. Описание системы единственной функцией как правило возможно, но, тем не менее, довольно искусственно. В действительности, реальные системы не имеют верха; 3) исключается из рассмотрения эволюционная природа процесса создания программных систем. Метод проектирования предусматривает строго последовательный порядок действий (т.н. "модель водопада"), характеризуется лавинообразным нарастанием сложности и, следовательно, непригоден для разработки больших программных систем: ошибки, заложенные на ранних этапах, сильно сказываются на времени и конечной цене разработки, так что изменение требований к системе может привести к ее полному перепроектированию; 4) низкая возможность повторного использования программного кода. Структурное проектирование "сверху-вниз" порождает код, который (практически) невозможно использовать повторно, т.к. элементы при проектировании создаются для решения конкретных подпроблем и не обеспечивают достаточной степени общности. Второй, объектно - ориентированный подход использует объектную декомпозицию - взаимодействующие друг с другом объекты обеспечивают общее поведение системы.
Модели в задачах проектирования и реализации БД
В математике модели хорошо изучены на уровне строгости и тщательности, недостижимом в других областях знаний, а в качестве описательного средства они универсальны. Они всегда "незримо присутствуют" во всяком процессе проектирования ИС. Однако явным образом при разработках БД они не используются. Дело в том, что математическая модель - абстрактное понятие, лишенное семантической окраски, пронизывающей прикладную область. Ей неизвестен прикладной смысл объектов из S, R и F, и это затрудняет работу конкретного разработчика с ней. Кроме того, модели, в том виде, в каком они существуют в математике, "не понимает" ни одна компьютерная программа. Поэтому при реализации БД применяются другие модели, не сводящиеся к математическим.
С точки зрения реляционных БД тройка S,R,F напоминает, триаду Базовые таблицы, Декларативные ограничения целостности, Процедуры БД . Однако реально в проектировании БД между математической моделью с одной стороны, и схемой базы данных с другой стороны присутствует несколько моделей разных уровней абстракции, связанных между собою. Существуют три уровня моделей, заполняющих "промежуток": уровень концептуальной модели прикладной области, уровень логической модели БД и уровень физической модели БД. Это те виды абстракций, которые в той или иной степени, явно или неявно, но обязательно присутствуют в разработке конкретной БД. В концептуальном моделировании проектируется схема понятий прикладной области в их взаимосвязи. Это наиболее общий вид модели, с которым имеет дело разработчик - в том смысле, что модели этого вида являются "понятийными", т.е. моделями понятий предметной области и практически не привязаны к компьютерным реалиям (абстрагированы от них). Концептуальные модели (в литературе встречается еще название "семантические модели") еще не являются БД-моделями.
Исходными базовыми понятиями являются объекты и связи между объектами. Связи могут быть двух видов: обобщение и агрегация. Обобщение связывает одни объекты с другими, по смыслу более общими. Агрегация связывает разнородные объекты по признаку компонентного вхождения в другие объекты. Независимо, оба вида связей образуют каждый свою иерархию среди объектов модели.
Кроме этих базовых имеются и другие понятия концептуальной модели: атрибут; отношение; связь; экземпляр. Перечисленные понятия относительны. Одно и то же явление может быть и объектом, и отношением, и атрибутом, и экземпляром, и связью, и все определяется точкой зрения на явление. Зависимость интерпретации от точки зрения на явление (а точнее -возможность выбора точек зрения с разной интерпретацией) - мощное свойство, придающее концептуальной модели большую гибкость и приспособляемость в описании проектируемой ИС.
Существуют самые разные модели концептуального проектирования, например, концептуальная модель "объект-роль" (ER-модель), введенная Ченом, графовые модели, семантические сети и др. [12,13,90]. Современной моделью концептуального проектирования является объектная модель, обладающая наибольшей выразительностью из перечисленных моделей концептуального моделирования. В отличие от концептуального, логическое моделирование (называемое часто логическим проектированием) несет в себе меньшую семантическую нагрузку, и часто понимается уже как "логическое моделирование базы данных" (а не прикладной области). В таком понимании цель логического моделирования состоит в том, чтобы описать базу данных безотносительно к конкретной СУБД и архитектуре БД [88]. Наиболее популярными видами моделей БД логического уровня являются реляционная модель, описанная Коддом [7,8], и снова объектная модель, обладающая высокой насыщенностью семантических конструкций, но вместе с тем и сложностью. В реляционном подходе логическое проектирование сводится к тому, чтобы правильно сформировать объекты, их атрибуты и взаимосвязи с учетом методологических требований ликвидации избыточности, нормализации, целостности, а также, с учетом требований прикладной постановки (что может противоречить друг другу). Модели реляционного подхода не поддерживают сколь-нибудь развитую семантику межобъектных отношений. Поэтому на данном этапе происходит искажение модели прикладного домена, и появляется несоответствие между моделью данных и моделью предметной области (т.н. импеданс рассогласования). В объектном подходе на данной стадии используется объектная модель прикладного домена, которая только дополняется объектными структурами, необходимыми для эффективной реализации. Поэтому на данном этапе не происходит искажения концептуальной модели, а лишь ее расширение. Здесь приходится оговориться, что не существует общепринятой, абстрактной и формально определенной "объектной модели данных" и применительно к "объектной "модели" правильнее говорить об "удобным ярлыке для целой совокупности некоторых взаимосвязанных идей". Физическая модель данных соответствует описанию данных в БД конкретной СУБД, то есть схеме данных. Она непосредственно учитывает такие аспекты, как архитектуру, безопасность, эффективность доступа и другие. Физическая модель учитывает возможности, ограничения и особенности конкретной используемой СУБД. Она состоит из реального программного кода для реализации концептуальной схемы. Преобразование логической схемы во внутреннюю является продукт-зависимым делом. В настоящее время стандартной для приложений с использованием СУБД является предложенная ANCI/SPARC комитетом по БД трехуровневая архитектура «внешняя схема» - «концептуальная схема» - «внутренняя схема» Каждая внешняя, схема - проект базы данных с точки зрения отдельного приложения, из общего множества приложений работающих с ней. Концептуальная схема - проект базы данных с точки зрения с точки зрения всей интегрированной системы, работающей с БД. Концептуальная схема интегрирует данные всех связанных приложений и не связана со специфическими особенностями используемой базы данных. Объектное моделирование применимо для проектирования как внешних, так и концептуальной схемы. При этом для каждой внешней схемы строится своя объектная модель, которая отражается в нее. Отдельная объектная модель строится для концептуальной схемы.
Отображение объектов изолированного класса
В этом случае (вся объектная схема отражается в один кортеж одной таблицы) приходится, естественно, задавать максимальное число объектов, которые могут участвовать в ассоциации на стороне "многие" (п). Делая этот выбор, мы налагаем ограничение на модель прикладного домена с целью увеличения скорости выполнения запросов. Таким образом, общее количество атрибутов реляционной модели составит 1. Высокая скорость работы с БД т.к. нет необходимости поиска по нескольким таблицам. Однако это справедливо только в случае выбора всех объектов, участвующих в ассоциации на стороне "многие" т.е. при запросе, выбирающем атрибуты всех соответствующих столбцов, хранящихся в строке таблицы. При г п такой запрос приведет к выборке п-г пустых полей. 2. Таблица удовлетворяем НФБК. Первичным ключом таблицы является суррогатный ключ clB_OID, все остальные атрибуты не транзитивно зависят от него (для обязательной ассоциации). Недостатки: 1. Ограниченность объектной модели. Жестко установленное максимальное число объектов, участвующих в ассоциации на стороне "многие" ограничивает исходную объектную модель, накладывая на нее дополнительное условие (г п). Для определения реального г количества объектов класса на стороне "многие", участвующих в ассоциации необходимо или вводить дополнительное поле, в котором будет храниться это число, или определять его по количеству пустых и/или заполненных полей в записи. Кроме того, имеем ухудшение гибкости процесса проектирования. На ранних стадиях проектирования трудно сразу правильно определить множественность или представление ассоциации. Поэтому, при дальнейшем проектировании, возможно, придется изменить реализацию для случаев 1-1 и 1-п и обязательно придется перепроектировать, если множественность сменится на п-п. 2. Нарушение принципа расширяемости реляционной модели. Ограничение на максимальное число объектов, участвующих на стороне "многие" ассоциации. Если при работе с БД окажется необходимым хранить более, чем п объектов (г п), то для добавления (г-п) экземпляров потребуется полная перестройка БД, что противоречит принципу расширяемости реляционной модели. 3. Избыточность реляционной модели. Для хранения п экземпляров класса стороны " многие ", в таблице необходимо иметь (n k) столбцов. В случае, если г п, к» (п-г) столбцов остаются незаполненными, что ведет к потере памяти. Оценивая избыточность реляционной модели отношением количества незаполненных полей к общему количеству полей таблицы, получаем: и, согласно определению, р 0, к 0, п 0, то Y/O, Yi" 0 и, следовательно, Y] убывает выпукло вниз. Все вышесказанное отражено на графике. Были взяты следующие значения переменных:n=20, р=5, к=4. 5. Проблемы доступа к объекту, участвующему в ассоциации на стороне "многие". Допустим необходимо совершить операцию (добавления, удаления, обновления, чтения) объекта стороны "многие", для заданного объекта стороны "один". Чтобы найти этот объект в отношении необходимо определить в каких именно столбцах таблицы он находится. Т.е. при выполнении запроса потребуется каждый раз определять имена столбцов, что является нетривиальной задачей, ведет к усложнению прикладных программ (или хранимых процедур) и замедляет работу с БД. При работе с данной структурой можно предложить, для увеличения скорости выполнения запроса на вставку объекта в БД, ввести дополнительное поле, содержащее г (реальное число объектов, стороны "многие" ассоциации хранящихся в БД), что позволяет ускорить определение необходимых полей для данной операции. Однако это не решает проблемы в случае других операций с БД (удаления, обновления, чтения). 6. Проблемы индексации объектов, участвующих в ассоциации на стороне "многие". Данные проблемы аналогичны проблеме доступа к объекту на стороне "многие", рассмотренному в предыдущем пункте. 7. Структура объектной модели из реляционной не видна. Объектная модель содержит два класса, т.е. две независимые сущности прикладного домена, описываемого моделью. Реляционная модель содержит одну, т.е. одну сущность в терминах R-моделирования. Таким образом, два этих описания одного и того же домена совершенно различны. Ассоциации связывают объекты с независимой семантикой. Поэтому представляется нелогичным объединять знание об объекте со знаниями о других объектах. Такое решение противоречит также принципу инкапсуляции объектного моделирования. Таким образом, данное решение значительно ухудшает качество проекта. 8. Нарушение ЗНФ. Действительно, в качестве первичного ключа данного отношения можно взять "с1В ОГО", от которого (в случае обязательной ассоциации) полно функционально зависят все остальные атрибуты, (и, соответственно, при таком выборе оно находится во 2NF). Однако, существует транзитивная функциональная clBOID— clA_OIDk—»atrAik. Таким образом, отношение не находится в 3NF и тем более в нормальной форме Бойса-Кодда (BCNF).
Исследование функциональных аспектов
Сервер объектного представления должен получать запросы раньше, чем они попадают на обработку в ядро СУБД. Это необходимо для перетрансляции SQL запроса из объектной формы. Объектная форма запросов должна быть максимально приближена к естественной форме запросов SQL, то есть очень желательно, чтобы изменения в SQL были минимальны, настолько, насколько это возможно. Алгоритм работы сервера объектного представления: получить запрос; проверить относится запрос к классу (классам) или отношениям; если запрос направлен к классу (классам), то выполнить перетрансляцию; направить запрос к СУБД; получить результаты; если необходимо, то выполнить дополнительную обработку результатов запроса; вернуть результаты запроса пользователю. Проверка запроса сводится к получению списка таблиц, участвующих в запросе. Для каждой таблицы делается попытка найти её имя в отношении CLASSES. Если хотя бы одна таблица представляет собой класс, то запрос направляется на стадию перетрансляции. В противном случае, он перенаправляется к СУБД в первозданном виде. Запросы на создание класса Запрос на создание класса следует отличать от запроса на создание обычной таблицы, с этой целью в операторе CREATE TABLE вводится дополнительно четыре опциональных параметра. Опция AS CLASS определяет, что table name , специфицирует имя класса. Опция ABSTRACT определяет класс, как абстрактный. Опция INHERITED FROM определяет, что данный класс является подклассом class name . Опция METHOD определяет, что хранимая процедура с именем table name method name является методом method name данного класса. Оператор "" обозначает строковую операцию конкатенации. При создании подкласса, не являющегося абстрактным, необходимо получить имена и типы полей суперкласса, а также его индексы, триггеры, методы и ограничения. Это требуется для создания одной или более таблиц (экземпляров класса) ассоциированных с данным классом. Таблицы, ассоциированные с классом, должны иметь весь набор полей, полей, индексов, триггеров, методов и ограничений, определённых у всех суперклассов в совокупности. Рассмотрим простейшую схему наследования. Пусть создаётся класс С, который является подклассом класса В, который, в свою очередь, является подклассом класса А (А- В- С- ). Пусть класс А имеет атрибуты fja и f2a, индекс iia и методы /И/Л, т2а и т3а. Класс В имеет поля flb, /2ь и /Зь, и метод т1Ь. Класс С имеет поле/}с, индекс //с, методы т1с и т2с, а также ограничения cojc и со2с- Тогда таблица-экземпляр, созданная на основе описания класса С будет иметь: ПОЛЯ: /іач/2аі/іЬ /2Ьі/зЬі/іс индексы: і я/, іс/; методы: т1ю т2а, т3а, тш т]с, т2с; ограничения: cojc, со2с. Запросы на изменение класса. Менять структуру классов - скверная практика. Но в момент разработки возникают ситуации, когда данная операция необходима. Именно поэтому должна быть реализована возможность изменения структуры классов. Аналогично тому, как мы можем менять структуру таблиц с помощью оператора ALTER TABLE, точно также можно воспользоваться этим оператором для изменения структуры класса. ALTER TABLE table name [AS CLASS [ABSTRACT][INHERITED FROM class name ]] (ADDDROP) : [METHOD method name ( list of parameters ) [, METHOD -Onethod name ( list of parameters ) ] ] Опция AS CLASS позволяет превратить таблицу с именем table name в одноимённый класс. Опция ABSTRACT определяет, что класс является абстрактным, если ранее класс существовал, но как реальный, то применение к нему данной опции приведёт к уничтожению связанных с ним одной или более таблиц. Опция INHERITED FROM class name делает возможным наследование подкласса от класса с именем class name . Это приводит к тому, что подкласс будет расширен полями, индексами, ограничениями, триггерами и методами суперклассов. В случае пересечения имён, например, если исходный класс и суперкласс имеют поля с одинаковым именем, операция должна быть отменена с выдачей соответствующего диагностического сообщения. Традиционно изменение таблиц возможно только за счёт добавления или удаления полей и ограничений (CONSTRAINT). Но, работая с классами, можно аналогичным образом добавлять или удалять методы. Если класс, в котором производятся изменения, имеет подклассы, то все изменения в базовом классе должны быть спроецированы на его подклассы. Так, например, удаление поля в суперклассе должно повлечь удаление соответствующих полей в каждом его подклассе. Аналогичные требования можно выдвинуть и относительно индексов, ограничений, триггеров и методов. Запросы на удаление класса. Запрос на удаление класса синтаксически полностью аналогичен запросу на удаление таблицы. DROP TABLE class name ; Здесь class name является именем удаляемого класса. При удалении класса следует предусмотреть проверку ссылочной целостности. Если класс имеет бинарные связи с другими классами или таблицами, то его удаление невозможно. В такой ситуации операция отменяется, а пользовательское приложение должно быть оповещено о возникшей проблеме. Удаление суперкласса автоматически приводит к удалению всех его подклассов. Запросы на изменение данных.
