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

Здесь описаны концепции и процедуры моделирования данных, принятые в подходе ER (Entity Relational - отношения между сущностями), на основе рассмотрения следующих вопросов:

• Роль моделирования данных
• Формирование модели данных
• Принятие корпоративного представления
• Основы методологии моделирования

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

Роль моделирования данных

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

Проект разработки ПО: общее представление

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

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

1. Определение проблемы
2. Анализ требований
3. Концептуальное проектирование
4. Детальное проектирование
5. Реализация
6. Тестирование

Этот подход к разработке известен как метод водопада. Как видно из рисунка 1.1, каждая фаза завершается перед переходом к следующей, создавая эффект "водопада".

Рис. 1.1. Метод водопада для проекта разработки ПО.

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

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

Когда именно следует заняться моделированием данных

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

Формирование модели данных

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

В большинстве случаев для построения модели данных вам потребуется выполнить следующие операции:

1. Определение проблемы и функциональных границ
2. Сбор требований
3. Анализ
4. Формирование логической модели
5. Формирование физической модели
6. Генерация базы данных

Рисунок 1.2 показывает, как каждый из шагов обеспечивает исходные данные для следующего шага.

Рис. 1.2. Формирование логической модели может предшествовать выбору платформы СУБД
(Oracle, DB2, Sybase и т.п.).

Определение проблемы и функциональных границ

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

Сбор требований к информации

Многие из профессионалов согласны, что наиболее важной задачей проекта разработки ПО является точное и полное определение требований. В самом деле, неполное или неточное понимание требований может привести к выходу за рамки отведенного бюджета и существенному срыву срока завершения проекта.

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

Подготовка к рабочей сессии

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

Рекомендации по подбору участников сессии

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

Хороший председатель - еще один критически важный фактор. Председатель гарантирует, что все участники имеют возможность поделиться знаниями, опытом и высказать свое мнение. Сессия, на которой выступили лишь несколько человек, вероятнее всего, приведет к неадекватному набору требований к информации.

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

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

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

Помещение и оборудование

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

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

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

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

Распространение материалов перед заседанием

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

ПРИМЕЧАНИЕ
Скелетная модель предоставляет стартовую позицию для процесса моделирования. Она содержит ограниченный набор сущностей и атрибутов, и создается на основе описания проблемы и какой-либо предыдущей работы, относящейся к данной предметной области.

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

Убеждайте участников готовиться к заседаниям! Запланируйте перерывы, по меньшей мере, раз в два часа.

С чего начать

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

Правила проведения сессии призваны сохранить ее продуктивность. Ниже приведен список наиболее общих правил:

• Начало - в назначенное время
• Говорит один человек, а не все сразу
• Выступающий должен иметь возможность выразить свои соображения до конца, не перебивайте его
• Равноправие всех участников
• Если спорный вопрос не может быть решен в разумное время, зафиксируйте проблему или отложенный вопрос
• После перерыва вовремя приступайте к работе
• Заканчивать заседание нужно в назначенное время

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

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

Анализ

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

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

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

Отображение и трансформация данных

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

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

Таблица 1.1. Правила отображения для исходного кода.

Исходный код	Значение атрибута 1	Значение атрибута 2	Значение атрибута 3
1234567890	123	456	7890
0987654321	098	765	4321
12345	123	450	0000

Бизнес-правила, показанные в таблице 1.1, включают руководство для отображения значений исходного кода в его компоненты. Значения исходного кода содержат атрибут 1, атрибут 2 и атрибут 3. Новые значения исходного кода используются, начиная с 1-го января 1998, и состоят из 10 цифр, в то время как старые значения состояли из 5 цифр. Первые три цифры значения исходного кода содержат атрибут 1. Следующие три цифры составляют атрибут 2. Последние четыре цифры содержат значение атрибута 3. Для значений из пяти цифр в исходном коде вы используете ноль (0) в качестве третей цифры атрибута 2 и заполняете нулями значение атрибута 3.

Область определения данных

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

Значения по умолчанию

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

ПРИМЕЧАНИЕ
Аналитик должен с самого начала уделять внимание неинициализированным значениям и значениям по умолчанию. Тщательно обсудите возможное отсутствие значения и значения по умолчанию с экспертами предметной области. Не забывайте с осторожностью относиться к генерации отчетов по полям, если эти поля могут заполняться значениями по умолчанию, так как это может привести к неожиданным результатам.

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

Логическая модель данных

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

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

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

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

Компоненты логической модели данных

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

Сущности

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

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

Рис. 1.3. Пример использования ERwin для отображения сущностей в простейшей форме.

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

Атрибуты

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

Рисунок 1.4 иллюстрирует несколько примеров атрибутов.

Рис. 1.4. В качестве атрибутов могут выступать дата рождения клиента,
модель автомобиля или код ISBN книги.

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

Отношения

Отношения представляют взаимосвязи между объектами, о которых корпорация заинтересована хранить данные. Отношения выражаются глаголами или глагольными фразами, которые описывают взаимосвязь. На рис. 1.5 приведено несколько примеров отношений, представленных в нотации IE (Information Engineering - информационная инженерия) системы ERwin.

Рис. 1.5. Примеры отношений используют нотацию IE системы ERwin, в которой "коровьи копыта" или "трезубцы" отображают многие стороны отношений.

Понятие нормализации

Нормализация является операцией перемещения атрибутов в подходящие сущности в соответствие с требованиями нормальных форм. Нормализацию обычно представляют как набор сложных правил, из-за чего эта концепция кажется трудной для понимания. В действительности, нормализация достаточно очевидна: "Один факт в одном месте", как пишет К.Д. Дейт в своей книге ("Введение в системы баз данных, 6-е издание") изд. Вильямс: 1999, 848 с.).

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

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

В конце этой статьи приведено формальное определение Дейта для первых пяти нормальных форм, включая нормальную форму Бойса/Кодда (BCNF - Boyce/Codd normal form), которая представляет собой более строго ограниченную третью нормальную форму.

Термин "бизнес-нормальная форма", введенный Клайвом Финклештейном (Finklestein C. An Introduction to Information Engineering: From Strategic Planning to Information Systems. Reading, Massachusetts: Addison-Wesley, 1989), дает менее формальное определение нормальных форм и рекомендаций по приведению моделей к каждой форме. Хотя существуют незначительные различия в способах определения нормальных форм, приводимых разными экспертами, конечный результат будет один - модель, где каждый атрибут "зависит от ключа, полного ключа, и только ключа, да поможет мне Кодд".

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

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

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

Часть 2