Конспект по курсу. Объектно ориентированный анализ и проектирование (1133667), страница 16

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 16)

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

Для множественных полюсов указываются типы: множество {set}, упорядоченное множество {ordered}, мультимножество {bag}, упорядоченное мультимножество {sequence}. На диаграммы могут быть явно указаны классы-контейнеры (список, хэш-таблица и проч.). Классам с необязательными связями добавляются операции проверки, существования соединения между их экземплярами.

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

В модели добавляются ограничения. Для их записи используется язык OCL, рассмотренный в лекции 4.

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

Литература к лекции 8

1. Кулямин В. В. Технологии программирования. Компонентный подход. – М.: Бином. Лаборатория знаний. 2007. Лекция 4.

2. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.: Пер. с англ. – СПб.: Питер, 2007. – Главы 14, 15.

3. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения.: Пер. с англ. – СПб.: Питер, 2002. – Глава 9.

4. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 4.

5. Коналлен Дж. Разработка Web-приложений с использованием UML.: Пер. с англ. – М.: Вильямс, 2001. – Глава 10.

Лекция 9. Проектирование баз данных

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

Основные понятия реляционной модели:

База данных – долговременное самодокументированное хранилище данных. Самодокументация = схема данных, хранящаяся в БД.

Система управления базами данных (СУБД) – ПО доступа к данным. Обеспечивает:

• защиту данных;

• эффективность;

• многопользовательский режим;

• разделение данных между несколькими приложениями;

• распределенность данных;

• безопасность.

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

Оператор SQL – предложение SQL для манипуляции данными (выборка, изменение, добавление, удаление).

Ограничения – условия, являющиеся частью схемы БД. Если какая-либо добавляемая запись нарушает какое-то ограничение, то она не будет добавлена.

Виды ограничений:

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

Основной (первичный) ключ – возможный ключ, который предпочтительнее использовать для работы с таблицей. Есть у каждой таблицы.

Внешний ключ – ссылка из другой таблицы на возможный ключ.

Пример:

П
ервичные ключи: persID в 1-ой таблице, compID – во 2-ой. Внешний ключ – столбец employer 1-ой таблицы.

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

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

Триггеры являются частным случаем хранимых процедур. Хранимая процедура – это процедура, работающая с таблицами, которая скомпилирована и хранится в виде кода в БД и может быть вызвана из клиентской программы. Хранимые процедуры выгоднее SQL-запросов, но они доступны всем приложениям, работающим с БД, что иногда нежелательно.

Реляционная схема данных и объектная модель оперируют разными понятиями, из‑за чего необходима специальная работа по объектно-реляционному отображению. Отображение возможно в обе стороны: в прямую (от классов к таблицам) и в обратную (от таблиц к классам). В лекции мы будем говорить о прямом отображении, но обратное отображение подразумевается.

Еще одно предваряющее замечание. Получаемая при отображении схема БД зависит не только от совокупности устойчивых классов и связей между ними, но и от практических соображений. Например, может оказаться, что решение хранить все устойчивые объекты в одной «толстой» ненормализованной таблице, вполне себя оправдывает тем, что делает приемлемой скорость большинства запросов к БД. Описывая объектно-реляционное отображение, мы будем рассматривать решения, тяготеющие к получению нормализованной БД.

Переводить модель классов в схему БД предлагается в 3 этапа: отобразить классы в таблицы, отобразить ассоциации и отобразить связи обобщения.

Отображение классов

1. Каждый класс переводится в отдельную таблицу, атрибуты становятся столбцами таблицы. Операции на структуру таблицы не влияют. Они могут переводиться в хранимые процедуры, если мы ходим переложить часть работы по манипулированию данными на СУБД.

2. Уникальный идентификатор устойчивого класса превращается в первичный ключ таблицы. Если имеется несколько альтернативных уникальных идентификаторов, выбирается наиболее используемый. Если в модели для устойчивого класса явно не указан идентификатор, то в таблицу добавляется столбец ID – первичный ключ.

П
ример:

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

О
тображение бинарных ассоциаций:

• «1 к 1му» – возможны различные решения, лучше создать общую таблицу для 2х классов. Столбцы – совокупность атрибутов. Первичный ключ – любой ID (первого или второго класса). Достигается максимально возможная экономия: одна таблица представляет оба класса и ассоциацию между ними.

• «
  1 к 0..1» – внешний ключ добавляется к таблице необязательного класса.

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

• «
  0..1 к 0..1» – рекомендуется отдельная таблица для связи. Ее столбцы – внешние ключи для таблиц классов, связанных ассоциацией. Основной ключ – комбинация этих столбцов.

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

• «* к *» – для ассоциации заводится отдельная таблица. Ее столбцы – внешние ключи для таблиц классов, связанных ассоциацией. Основной ключ – комбинация этих столбцов.

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

• «1 к 1..*» – к таблице класса у полюса «1..*» добавляется столбец – внешний ключ для таблицы класса у полюса «один».

• «1 к 0..*» – как «1 к 1..*».

П
ример:

• «0..1 к *» – применяются те же решения, что и в «0..1 к 0..1».

Всякий раз, когда при реализации ассоциаций возникают связанные таблицы, возникают и ограничения целостности (в разных случаях разные), т. е. фактически добавляется не только внешний ключ и/или таблица, но и триггеры или хранимые процедуры.

Отображение классов связанных N-арной ассоциацией:

Т
ребуется таблица для хранения связи. Например, в случае тернарной (N=3) связи формируются четыре таблицы, по одной для каждого класса и одна для связи. Таблица связи будет иметь среди своих атрибутов ключи каждой из 3х других таблиц.

Пример:

Отображение классов-ассоциаций:

Атрибуты класса-ассоциации добавляются либо в создаваемую для связи таблицу, либо (если дополнительная таблица не требуется) в ту таблицу, куда добавляется внешний ключ.

П
ример:

Отображение квалифицированных ассоциаций

Решение:

• Определить, какие мощности были бы у полюсов ассоциации без квалификатора.

• Применить решение для ассоциаций с полученными мощностями.

• Добавить квалификатор как столбец (или столбцы) в ту же таблицу, куда добавляются внешние ключи.

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

Пример:

О
тображение обобщения (наследования):

Стратегии:

• для каждого класса своя таблица;

• для всей иерархии наследования одна таблица;

• таблицы только для конкретных (не абстрактных) классов;

• таблицы только для различных конкретных классов.

К
акой именно способ выбрать диктуют соображения эффективности (скорость в обмен на объем памяти). Рассмотрим на примере. Пусть класс Person – абстрактный.

При использовании 1-го подхода будут созданы 4 таблицы. У таблиц Person, Student, Employee будет дополнительный столбец – тип, в котором будет храниться реальный тип объекта. Для каждого экземпляра класса Student будут две записи, одна в таблице студентов, вторая – в таблице персон. Для экземпляра StudentEmployee – четыре записи, по одной в каждой таблице. При чем у всех их будет одинаковое значение первичного ключа. Дублирование записей позволит быстро находить всех персон, всех студентов и т. п.

При втором подходе используется общая разреженная таблица. В ней также для каждой записи хранится ее тип. Неудобство состоит в том, что для любой записи о персоне есть риск «залезть» в поля, принадлежащие подклассу.

Третий подход позволяет сэкономить одну таблицу – Person – для поиска всех персон в БД будет создан View, объединяющий записи 3-х созданных таблиц.

Характеристики

Список файлов лекций