Проектирование Баз Данных - Сибилев, 2007

141

6.4 Общий обзор методологии

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

6.4.1 Фаза концептуального моделирования

Этап 1. Создание локальных концептуальных моделей данных пользователей.

На начальном этапе проект информационной системы организации разбивается на относительно небольшие подпроекты. Для этого определяются типы конечных пользователей (КП) системы и изучаются их преставления о предметной области проекта. Локальные представления кладутся в основу соответ-

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

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

Ниже перечислены виды работ, которые выполняются на этом этапе.

1.1.Определение типов сущностей.

1.2.Определение типов связей.

1.3.Определение атрибутов и связывание их с типами сущностей и связей.

1.4.Определение доменов атрибутов.

1.5.Определение атрибутов, являющихся потенциальными ключами и выделение первичных ключей.

1.6.Специализация или генерализация типов сущностей (необязательно).

1.7.Создание диаграммы «сущность-связь».

1.8.Обсуждение локальной модели с заинтересованными конечными пользователями.

142

6.4.2 Фаза логического моделирования

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

Этап 2. Построение и проверка локальных логических моделей данных пользователей.

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

Затем корректность локальной логической модели проверяется с помощью правил нормализации. Это делается для того, чтобы убедиться в структурной согласованности, логической целостности и минимальной избыточности модели. Далее проверяется возможность выполнения транзакций пользователя в созданной схеме локальной РБД. Все эти проверки необходимы для того, чтобы получить уверенность в корректности модели данных.

Перечислим виды работ этапа.

2.1.Очистка локальной концептуальной модели от нежелательных элементов.

2.2.Определение набора отношений на основе очищенной концептуальной модели.

2.3.Проверка соответствия логической модели требованиям нормализации.

2.4.Проверка исполнимости транзакций пользователя.

2.5.Создание диаграмм модели.

2.6.Определение требований поддержки целостности данных.

2.7.Обсуждение локальной логической модели с заинтересованными конечными пользователями.

143

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

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

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

3.1.Слияние локальных логических моделей в единую глобальную модель данных.

3.2.Проверка глобальной логической модели.

3.3.Проверка возможностей расширения модели в будущем.

3.4.Создание окончательного варианта диаграмм модели.

3.5.Обсуждение глобальной логической модели с пользователями.

6.4.3 Фаза физического проектирования

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

Этап 4. Перенос глобальной логической модели данных в среду целевой СУБД.

4.1.Проектирование основных таблиц в среде целевой СУБД.

4.2.Реализация бизнес-правил в среде целевой СУБД.

Этап 5. Проектирование физического представления базы данных.

5.1.Анализ транзакций.

5.2.Выбор файловой структуры.

5.3.Определение вторичных индексов.

5.4.Анализ необходимости введения контролируемой избыточности данных.

144

5.5. Определение требований к дисковой памяти. Этап 6. Разработка механизмов защиты.

6.1.Проектирование пользовательских представлений.

6.2.Определение прав доступа.

Этап 7. Организация мониторинга и настройка функционирования системы.

Контрольные вопросы

1.Опишите понятие методологии проектирования.

2.Перечислите, и кратко опишите фазы проектирования базы данных.

3.Перечислите факторы успешного завершения проекта базы данных.

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

5.Перечислите виды работ, выполняемых на фазе логического моделирования.

6.Перечислите виды работ, выполняемых на фазе физического проектирования.

145

7 МЕТОДОЛОГИЯ КОНЦЕПТУАЛЬНОГО МОДЕЛИРОВАНИЯ

7.1 Создание локальной концептуальной модели

Локальная концептуальная модель описывает представление одного типа конечного пользователя3. Это представление включает в себя данные, необходимые пользователю для принятия решений или выполнения некоторого задания. Обычно оно отражает некоторую функциональную область в поле деятельности предприятия: производство, маркетинг, сбыт, управление кадрами, складской учёт и т.п. Задача проектировщика на этом этапе — изучить и адекватно описать требования пользователя к данным.

Начинать изучение информационных потребностей пользователя следует с выделения функциональных областей и отдельных функций. Затем, получив общее представление о функциях, следует опросить пользователей с целью уточнения некоторых деталей и проверки адекватности ваших представлений представлениям пользователей. Далее нужно изучить деловые процедуры, существующие отчёты, формы документов, провести наблюдения за работой пользователей и т.п. Цель всех этих мероприятий — понять, что делает будущий пользователь, чем он ограничен в своих действиях, какие данные и как он использует для выполнения своих функций.

Изучая локальное представление, аналитик накапливает описания

−процессов и сценариев деятельности,

−функций пользователя,

−входных документов и сообщений,

−выходных документов и сообщений,

−делового регламента,

−транзакций пользователя.

Эти описания (спецификации на проект) могут включать текстовые фрагменты, рисунки, диаграммы, формы и примеры

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

146

документов и отчётов. Спецификации содержат исходные данные для концептуального моделирования. В реальном проекте процессы накопления и анализа информации о локальном представлении идут параллельно.

Создание локальной концептуальной модели сводится к описанию (специфицированию):

–типов сущностей;

–типов связей;

–атрибутов (сущностей и связей);

–доменов атрибутов;

–потенциальных ключей;

–первичных ключей.

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

Рассмотрим основные детали процесса моделирования.

Этап 1.1. Определение типов сущностей

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

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

Шаг 1. Составить список имён существительных. Сущности в естественном языке обозначаются именами

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

–преподаватель,

–учебная дисциплина,

–аудитория,

–лекция,

–лабораторная работа,

147

–семинар,

–занятие,

–кафедра,

–фамилия,

–должность,

–номер группы,

–численность.

Эта работа должна быть проделана очень тщательно. В ходе моделирования аналитику очень часто приходится обращаться к списку имён.

Шаг 2. Выяснить смысл, вкладываемый пользователем в каждое имя.

Смысл следует зафиксировать в рабочем словаре данных. Например, так, как в таблице 7.1.

Таблица 7.1 — Фрагмент рабочего словаря

В ходе работы над моделью в словаре происходят изменения: появляются новые записи, уточняются описания смысла имён, добавляются различные примечания и т.п. Однако ни в коем случае записи словаря не следует удалять. Часто то, что аналитик счёл несущественным на каком-то уровне понимания предметной области, оказывается важным в дальнейшем.

Шаг 3. Выбрать из списка представляющие интерес для пользователя объекты и концепции.

Например, с точки зрения работника бюро расписаний в нашем списке таковыми могут быть:

148

ПРЕПОДАВАТЕЛЬ — специалист, проводящий учебные занятия (объект);

АУДИТОРИЯ — помещение, предназначенное для проведения учебных занятий (объект);

УЧЕБНАЯ ДИСЦИПЛИНА — раздел научно-технических знаний, изучаемый студентами (концепция);

ЗАНЯТИЕ — запланированная встреча преподавателя и группы студентов с целью изучения учебной дисциплины (концепция).

Шаг 4. Среди оставшихся элементов списка попытаться выделить группы имён, которые могут быть характеристиками или свойствами каких-либо объектов или концепций.

Так, в приведённом выше списке это

Шаг 5. Среди оставшихся элементов списка попытаться выделить группы имён, имеющих сходный смысл.

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

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

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

Шаг 6. Основываясь на результатах шагов 3 — 5, составить список «кандидатов» в сущности.

В нашем примере в этот список войдут имена ПРЕПОДАВА-

ТЕЛЬ, АУДИТОРИЯ, УЧЕБНАЯ ДИСЦИПЛИНА, ЗАНЯТИЕ, вхо-

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

149

ГРУППА — сформированное приказом ректора множество студентов одного года обучения, получающих одну специальность.

ВИД ЗАНЯТИЯ — способ изучения учебной дисциплины. Шаг 7. Выделить в списке «кандидатов» сущности модели. Задача этого шага — отделить сущности от атрибутов и связей. Часто объект можно вполне обоснованно отнести к лю-

бой из этих категорий.

Примеры.

Объект АУДИТОРИЯ следует трактовать как сущность, если пользователю для исполнения какой-то функции нужно знать не только номер аудитории (идентификатор), но и вместимость, тип (лекционная, компьютерный класс, лаборатория микроэлектроники…), принадлежность и т.п. Этот же объект следует рассматривать как атрибут какой-то сущности, скажем, сущности ЗАНЯТИЕ, если пользователю достаточно различать аудитории только по идентификаторам.

Объект ЗАНЯТИЕ можно трактовать как сущность, атрибу-

тами которой являются Преподаватель, Группа, Учебная дисциплина, Аудитория. Этот же объект можно трактовать как связь (ассоциацию) четырёх сущностей.

Анализ требований пользователя — субъективный процесс. Различные аналитики могут создавать различные интерпретации одних и тех же фактов. Эти интерпретации могут быть менее или более удачными (естественными, ясными, точными). Выбор варианта интерпретации существенно зависит от двух факторов: здравого смысла аналитика (хорошо усвоенного жизненного опыта) и накопленного опыта аналитической работы. Основными ориентирами в процессе анализа являются цель модели точка зрения пользователя. Аналитик должен смотреть на предметную область его глазами и уметь описать увиденное средствами базовой модели данных. Как правило, выделить полный набор сущностей с первой попытки не удаётся.

Шаг 8. Документировать типы сущностей.

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

150

обозначать один экземпляр сущности и в равной степени относиться к любому экземпляру. Оно должно быть понятно пользователю. Нарушение этих требований искажает смысл и затрудняет понимание модели.

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

Этап 1.2. Определение типов связей

Тип связи — это отношение одного или более типов сущностей, представляющее интерес с точки зрения пользователя. Техника выделения типов связей подобна изложенной выше технике выделения типов сущностей. И проблемы возникают в ходе анализа подобные. Однако теперь у аналитика есть фундамент — список сущностей.

Шаг 1. Из текста спецификаций на проект, выписать простые предложения, содержащие имена сущностей.

Наиболее часто встречаются предложения, содержащие имена двух сущностей. Каждое такое предложение описывает бинарную связь. Однако нужно быть осторожным, и тщательно проверять наличие в ПО связей высших степеней. Например, обнаружив предложения:

«ГРУППА изучает УЧЕБНую ДИСЦИПЛИНу» и

«ПРЕПОДАВАТЕЛЬ преподаёт УЧЕБНую ДИСЦИПЛИНу»,

можно упустить из виду тернарную связь

«ГРУППА изучает УЧЕБНую ДИСЦИПЛИНу под руково-

дством ПРЕПОДАВАТЕЛя».

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

Шаг 2. Проверить, все ли связи, упомянутые в спецификациях и следующие из них, включены в список.

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