Интеграция объектных систем обработки информации и реляционных серверов

• Автор: Полтавцева, Наталья Анатольевна
• Шифр специальности: 05.13.01
• Научная степень: Кандидатская
• Год защиты: 2003
• Место защиты: Тверь
• Количество страниц: 183 с. : ил.

ОГЛАВЛЕНИЕ
ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ

1. АНАЛИЗ ПРОБЛЕМ ПРОЕКТИРОВАНИЯ И МОДЕЛИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ,

ИМЕЮЩИХ В СВОЕМ СОСТАВЕ СЕРВЕР БД ю

1.1 Преимущества и особенности объектной разработки

информационных систем

1.2 Возможности и ограничения реляционных сгруктур баз

данных по поддержке методологии разработки.

1.2.1. Равноправие атрибутов отношений.

1.2.2. Ограниченный набор базовых типов

1.2.3. Фиксированность методов хранения и доступа
1.2.4. Отсутствие списочных структур.
1.2.5. Отсутствие иерархической подчиненности типов данных
1.3 Объектноориентированные базы данных и их использование
1.4. Объектнореляционные СУБД
1.5. Задачи интеграции объектной разработки с реляционным
сервером.
1.6. Выводы по главе
2. РЕЛЯЦИОННАЯ И ОБЪЕКТНАЯ МОДЕЛИ. ПОСТАНОВКА
ЗАДАЧ И ОТОБРАЖЕНИЯ.
2.1. Модели в задачах проектирования и реализации БД
2.1.1. Концепту ал ьная модель прикладного домена.
2.1.2. Логическая модель данных
2.1.3. Физическая модель хранения.
2.1.4. Использование объектной модели на концептуальном и
логическом уровнях
2.2. Основные характеристики объектных моделей
2.2.1. Стандарты и профили хранения объектов
2.3. Формализация задачи отображения моделей данных
2.4. Выводы по главе
3. ИССЛЕДОВАНИЕ МЕТОДОВ ОТОБРАЖЕНИЯ ОБЪЕКТНОЙ
МОДЕЛИ В РЕЛЯЦИОННУЮ
3.1. Идентификация объекта в РБД
3.2. Отображение объектов изолированного класса
3.3. Отображение в таблицы ассоциаций.
3.3.1. Отображение в реляционную модель ассоциации один к
одному
3.3.2. Оюбражение в реляционную модель ассоциации один ко
многим
3.3.3. Отображение в реляционную модель ассоциации один ко
многим с квалификатором
3.3.4. Отображение в реляционную модель ассоциации многие ко
многим.
3.3.5 Отражение в таблицы тернарной ассоциации
3.4. Отражение решетки наследования классов в реляционную
модель.
3.4.1. Вариант 1. Все классы хранятся в одной таблице
3.4.2. Вариант 2. Каждый конкретный не абстрактный класс
хранится в одной таблице
3.4.3. Вариант 3. Отдельная таблица для каждого класса.
3.4.4. Сравнительный анализ вариантов отражения отношения
наследования.
3.4.5. Множественное наследование
3.4.6. Нестандартные типы атрибутов
3.4.7. Агрегация.
3.5. Интегрированная методика структурного
моделирования
3.6. Выводы по главе.
4. ИССЛЕДОВАНИЕ ВОПРОСОВ ПОСТРОЕНИЯ ОБЪЕКТНО
РЕЛЯЦИОННОГО СЕРВЕРА.
4.1. Концептуальная модель сервера объектного представления
4.1.1. Сущности
4.1.2. Поля сущностей
4.2. Исследование функциональных аспектов
4.3. Разработка архитектуры сервера объектного построения
4.3.1. Механизм хранения объектов
4.3.2. Динамические аспекты
4.4. Выводы по главе.
5. ВОПРОСЫ РЕАЛИЗАЦИИ СПЕЦИАЛЬНОГО
ПРОГ РАММНОГО ОБЕСПЕЧЕНИЯ
5.1. Подсистемы и шаблоны проектирования для сервера
объектного представления.
5.2. Интерфейс для отражения объектной модели
5.3. Выводы по главе.
ЗАКЛЮЧЕНИЕ
ЛИТЕРАТУРА


Установление сложных многоуровневых отношений между информационными объектами. Вложение" объектов друг в друга, выделение общих свойств объектов на верхних уровнях и учет индивидуальных качеств и свойств объектов на нижних уровнях иерархии. Объектная ориентация обеспечивает эффективность применения итерационного подхода к разработке приложений (rapid applications development - RAD) в процессе совместной разработки приложений (joint applications development - JAD). Постоянно собирая информацию от конечных пользователей, разработчики создают приложения в динамике их развития, а объектно-ориентированная технология гарантирует, что кодирование не ляжет тяжким бременем на процесс разработки. Объектно-ориентированная методология представляет собой не революционный подход, а эволюционный, перенявший все лучшее из существующих методологий. Нахождение классов, которые могут быть повторно использованы, напоминает подход "сверху-вниз" ( в данном случае сверху вниз в смысле иерархии классов). Подход "снизу-вверх" пытается найти общность в описании классов, выделяя общие черты в новые абстрактные суперклассы. Далее, если выясняется, что поведение конкретного класса может быть разделено на несколько компонент с независимыми обслуживающими программами (утилитами), то целесообразно создать новые классы, отвечающие за эти функции. Как часть архитекту рных решений производится кластеризация классов в категории и организация их в модули и подсистемы. Наряду с общеизвестными достоинствами объектно-ориентированная методология имеет и недостатки [9,,,,,,,], связанные с ее практическим применением для построения сложных программных систем. Такие языки программирования, как SmallTalk и CLOS, сохраняют чистоту объектно-ориентированной идеи, но обеспечивается это, к сожалению, за счет снижения эффективности работы программ, так как это интерпретируемые языки. Среди компилируемых объектно-ориентированных языков наблюдается противоположная ситуация -стремление к эффективности влечет за собой зацикливание на деталях реализации и введение в семантику языка неоправданных ухищрений. Внедрение любой новой технологии требует вложения капиталов в инструменты для разработки программного обеспечения (ПО). Для некоторых проектов начальные затраты, связанные с внедрением объектного подхода, могут оказаться более высокими, чем при использовании традиционного подхода. Недостаток, связанный с использованием библиотек классов -возможное давние ее идеологии на архитектуру разрабатываемых приложений. На основании приведенных положений автор считает, что крупные информационные системы необходимо создавать, используя объектно-ориентированную методологию проектирования и реализации информационных систем. Важным вкладом технологии баз данных стало широко признанное открытие, констатирующее, что данные имеют самостоятельную ценность и что они должны управляться независимо от какого-либо отдельного приложения []. До этого приложения обладали собственными файлами данных, которые часто дублировали данные из других файлов. Для создания же совместно используемых баз данных стали необходимыми анализ и проектирование, которые бы балансировали требования множества приложений. В настоящее время система управления базами данных (СУБД) является весьма сложной системой, объединяющей богатое множество технологий. СУБД имеют дело в значительной степени с проблемами про изводится ъност и. Высокая производительность должна быть достижима даже в тех случаях, когда объем данных оказывается значительно большим, чем вмещается в физическую память, и даже когда данные распределены среди множества машин. Корректность достигается за счет более жестких ограничений целостности (например, целостности по ссылкам) и сериализации транзакций. Возможности поддержки достш-аются благодаря разделению логических и физических структур данных, а также с помощью большой коллекции инструментальных средств, призванных облегчить осуществление таких функций, как проектирование базы данных и обеспечение необходимого уровня производительности системы.