6. Проектирование баз данных с использованием uml Обзор возможностей современных субд

См. umlpracticum4.pdf

Всякая формальная система формальна постольку, поскольку для нее существует модель. Например, база данных - это модель, и значит, проектирование базы данных есть построение модели.

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

В качестве недостатков реляционных СУБД отмечаются следующие:

• негибкость структуры для развивающихся БД,

• затруднения в построении концептуальной модели для объектов с многочисленными связями многие - ко - многим,

• неестественность табличного представления для разреженных массивов данных.

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

Что касается объектно-ориентированных СУБД, то можно сказать, что теоретическая модель для них на сегодняшний день не разработана, а прикладные коммерческие продукты, провозглашенные как объектно-ориентированные, либо таковыми не являются, либо незрелы. Заявления об их будущей конкурентоспособности носят явно предположительный характер. Крупнейшие разработчики СУБД стали встраивать в свои продукты поддержку объектной ориентации, по соображениям совместимости предполагая смешанный подход – объектно-реляционный.

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

Между тем кризис в сфере практического применения реляционных СУБД постепенно нарастает. По имеющимся в литературе сведениям до 80% созданных корпоративных хранилищ данных не решают полностью поставленных перед ними задач, а 40% являются проваленными проектами. Около 50% запросов пользователей являются не предусмотренными в ходе их проектирования. По-видимому, можно считать, что использование реляционных СУБД неэффективно при количестве заложенных в них отношений (таблиц, информационных объектов) свыше 100-300.

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

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

Несмотря на все вышесказанные недостатки реляционной модели данных, всё же она является наиболее современной на сегодняшний день. По этому нет смысла использовать ранние модели ввиду их неконкурентноспособности по сравнению с реляционными и нет смысла использовать системы провозгласившие себя ОО, ввиду того, что под ними нет теоретической основы. Но и строить БД на основе чисто реляционной структуры было бы то же неуместно, ввиду её нереальности отображения семантики мира. Поэтому необходимо найти систему, которая основывалась на реляционном подходе и имела определённые разработки в объектно-ориентированных направлениях. При этом реляционный подход к организации БД должен быть наиболее популярным. И такой подход уже давно развит. Он основан на использование техники B-деревьев. С точки зрения внешнего логического представления B-дерево - это сбалансированное сильно ветвистое дерево во внешней памяти. Сбалансированность означает, что длина пути от корня дерева к любому его листу одна и та же. Ветвистость дерева - это свойство каждого узла дерева ссылаться на большое число узлов-потомков. Поиск в B-дереве - это прохождение от корня к листу в соответствии с заданным значением ключа. Заметим, что поскольку деревья сильно ветвистые и сбалансированные, то для выполнения поиска по любому значению ключа потребуется одно и то же (и обычно небольшое) число обменов с внешней памятью. Более точно, в сбалансированном дереве, где длины всех путей от корня к листу одни и те же, если во внутренней странице помещается n ключей, то при хранении m записей требуется дерево глубиной log_n(m), где log_n вычисляет логарифм по основанию n. Если n достаточно велико (обычный случай), то глубина дерева невелика, и производится быстрый поиск. Основной "изюминкой" B-деревьев является автоматическое поддержание свойства сбалансированности.

Одной из систем удовлетворяющих выше поставленным условиям является СУБД Cache.

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

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

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

Слайд 1.

Определения.

1. Свойство инкапсуляции означает, что объекты наделяются некоторой структурой и обладают определенным набором операций. То есть поведением. Операции, принадлежащие данному объекту, образуют его методы. Внутренняя структура объекта скрыта от пользователя; манипуляция объектом, изменение его состояния возможны лишь посредство его методов. Для того, чтобы объект произвел некоторое действие, ему необходимо извне послать сообщение, которое инициирует выполнение.

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

3. Свойство полиморфизма означает, что различные объекты могут получать одинаковые сообщения. Но –разносу, в соответствии с тем, как реализованы у них методы, реагирующие на сообщения.

Слайд 2.

Объектно-ориентированная технология призвана устранить ограничения, присущие реляционной технологии проектирования БД, предоставляя новые методы проектирования:

• Классификация. Объекты, обладающие одинаковыми свойствами и поведением, могут рассматриваться как члены одного класса.

• Подклассы и суперклассы. Экземпляры одного класса могут образовывать подмножество другого класса. Подклассы наследуют атрибуты и поведение своих суперклассов.

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

• Агрегирование. Позволяет создать сложные объекты из объектов – компонентов, определять отношения типа «часть-целое».

Слайд 3.

Пример наследования: идентификационные документы.

(файл Идент_докум(л11))

Каждый человек может иметь множество идентификационных документов различных видов. ОО-схема должна представлять эти данные с иерархией наследования.

Абстрактный класс Идентифитификационный документ представляет собой документ и имеет атрибут Идентификатордокумента и отношение к классу Человек. Абстрактный класс – это класс, у которого нет объектов, потому что он представляет собой обобщение (генерализацию) реальных классов объектов.

Диаграммы вариантов использования

Определение акторов

Определение транзакций, инициируемых акторами

Связь акторов с транзакциями - ассоциация

Диаграмма вариантов использования каталога

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

Атомарные транзакции имеют связующие связи с акторами, а податомарные – расширяют другие варианты использования или используются ими.

Некоторые ООDBMS поддерживают модель вложенных транзакций.

Диаграммы деятельности

(пример)

Модель сущность – связь

Сущность – это объект данных.

Отношения

Множественность отношения «играет роль».

Множественное наследование

Разработка схемы объектно-ориентированной базы данных

Модель данных UML преобразуется в такую схему легко, хотя существуют проблемы, связанные с отсутствием стандартов OODBMS.

Поведение объектов

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

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

Отношение – это конечное подмножество декартова произведения множества доменов, каждый из которых является набором значений. Сущность – таблица, атрибут отношения – столбец таблицы. Каждый столбец можно ограничить многими способами, включая требование содержать только уникальные значения в каждой строке отношения (ограничение уникального первичного ключа доступа или потенциального ключа поиска); превращение его в подмножество всего домена (ограничение домена) или ограничение домена как множества значений в строках в другом отношении (ограничение внешнего ключа), ограничение нескольких атрибутов совместно (первичный ключ. Состоящий из нескольких атрибутов). Ограничения выражают бизнес-правила.

Модель объектно-реляционных данных является гибридом, который берет за основу реляционную модель данных и расширяет ее с помощью некоторых объектно-ориентированных концепций. На рис.1 показана комбинация ОО и реляционной структуры. Класс Адрес конструируется из значений, на которые в реляционном отношении приходилось бы несколько колонок., и свертывает их в объект, который занимает всего одну. Основная цель – достижение концептуальной ясности и упрощение проекта. В примере не используется наследование, но проект компактнее, и возможно повторное использование кода.

Преимущества: можно использовать объектно-ориентированные средства (наследование, методы, объектные ссылки)для создания схемы. Которая хорошо вписывается в объектно-ориентированный концептуальный проект. Взаимодействие с реляционными средствами модели данных обеспечивает мост к реляционным операциям (например. использовать SQL).