Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Учебное пособие 3000136.doc
Скачиваний:
29
Добавлен:
30.04.2022
Размер:
513.54 Кб
Скачать

1.6. Объектно-реляционная модель данных

Промежуточной моделью данных между реляционными и объектно-ориентированными моделями данных является объектно-реляционная модель данных (ОРБД).

Различают две разновидности ОРБД – гибридные и расширенные.

В гибридных ОРБД интерфейс пользователя и алгоритм приложения выполнены с применением объектно-ориентированного подхода, а БД является реляционной. Примерами могут служить СУБД Paradox и InterBase, используемые для создания и использования базы данных в приложениях, разработанных в среде Delphi. В каком-то смысле гибридной можно считать СУБД Access, которая используется для создания базы данных и приложения и использует встроенный язык программирования Visual Basic for Application (VBA).

В расширенных (постреляционных) ОРБД предполагается объектно-ориентированное построение собственно базы данных путем использования известных и введения новых типов данных, связанных между собой. Эта связь реализуется через методы, описываемые с помощью триггеров и хранимых процедур. В расширенной объектно-реляционной модели допускается неатомарность данных, записываемых в поле. В полях может располагаться другая таблица или массив данных. К подобным СУБД относятся Informix Universal Server, Oracle 8, UniSQL. Данные СУБД используют язык запросов SQL3.

Постреляционными называют БД, в которых частично проведена денормализация данных и частично допускается неатомарность записей.

В настоящий период широкое распространение получила гибридная разновидность ОРБД.

К достоинствам ОРБД следует отнести следующие;

- повторное использование компонентов, имеющих заданный набор свойств и методов;

- частичное или полное отсутствие нормализации таблиц;

- возможность повтора данных в поле.

К недостаткам ОРБД можно отнести следующее:

- усложнение структуры базы данных;

- сложность построения абстрактных типов данных и методов, связывающих типы в иерархию.

2. Технология проектирования ообд с применением языка uml

2.1. Общая методология проектирования баз данных

Процесс проектирования БД представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели.

Проектирование базы данных можно разделить на четыре этапа [1]:

- системный анализ предметной области и формирование требований;

- концептуальное (инфологическое) проектирование;

- логическое (даталогическое) проектирование;

- физическое проектирование.

На этапе анализа и формирования требований определяют общие и специфические требования к базе данных. Требования уточняются в ходе опроса персонала различных уровней управления.

В рамках системного анализа предметной области необходимо провести подробное словесное описание предметной области и реальных связей, которые существуют между описываемыми объектами.

В общем случае существуют два подхода к выбору состава и структуры предметной области.

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

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

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

На этапе формирования требований определяются требования к БД. Они состоят из общих требований и специфических требований, связанных с особенностями решаемых задач.

Общие требования к базе данных могут быть следующими [1]:

- простота обновления данных; под обновлением понимают добавление и удаление записей и изменение полей;

- высокое быстродействие (малое время отклика на запрос);

- независимость данных;

- совместное использование данных многими пользователями;

- безопасность данных – защита данных от преднамеренного или случайного нарушения секретности, искажения или разрушения;

- стандартизация построения и эксплуатации БД;

- адекватность отображения данных соответствующей предметной области;

- дружелюбный интерфейс пользователя.

Специфические требования уточняются в ходе опроса персонала различных уровней управления.

Системный анализ и формирование требований должны заканчиваться техническим заданием на проектирование базы данных и приложения для работы с ней.

Техническое задание может содержать:

- подробное описание объектов предметной области, информацию о которых требуется хранить в БД;

- формулировка конкретных задач, которые будут решаться с использованием данной БД, с кратким описанием алгоритмов их решения;

- описание выходных документов, которые должны генерироваться в системе,

- описание входных документов, которые служат основанием для заполнения данными БД.

Все общие и специфические требования документируются в форме, доступной конечному пользователю и проектировщикам БД.

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

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

Логическое (даталогическое) проектирование – это преобразование высокоуровневого представления данных в структуру базы данных используемой СУБД. Таким образом, на первой стадии данного этапа осуществляется разработка схемы БД с учетом особенностей выбранной СУБД. Например, схема реляционной базы данных есть совокупность схем отношений, которые адекватно моделируют объекты предметной области, их основные свойства и связи между объектами.

Логическое проектирование заключается:

- в определении числа и структуры таблиц, описываемых средствами выбранной СУБД;

- в описании запросов к базе данных;

- в описании выходных документов;

- в разработке алгоритмов обработки информации;

- в проектировании форм для ввода и редактирования данных в таблицах базы данных.

Часто этапы инфологическое проектирование, выбор СУБД и логическое проектирование объединяют и называют логическим проектированием.

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

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