В предыдущей статье я рассказала о том, как следует собирать требования к базе данных и моделировать процессы ведения бизнеса компании. Настоящая статья посвящена следующей, третьей фазе моделирования данных - составлению модели сущностей. Здесь будут рассмотрены два типа диаграмм Сущность-связь (Entity Relationship Diagram, ERD) и показано, как каждый из них связан с диаграммой потоков данных (Data Flow Diagram, DFD), используемой для моделирования процессов бизнеса. При помощи этих диаграмм можно получить более полное представление о тех реальных требованиях к данным, которые предъявляются в компании.

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

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

Создание ERD

Диаграмма ERD строится из графических элементов, в основном из прямоугольников, (представляющих сущности и их свойства) и линий (представляющих отношения и связи сущностей друг с другом). В соответствии с некоторыми подходами, например, с методикой Чена, для отношений между сущностями применяются комбинации линий с маленькими ромбиками, а для представления атрибутов используются маленькие кружочки. Подробнее о том, как идентифицировать сущности, написано в статье <Моделирование данных>, опубликованной в предыдущем номере (№2) журнала. Для построения диаграммы ERD предприятия будет использована модель DFD, сконструированная в статье "Моделирование процессов", также помещенной во втором номере нашего журнала. Модель ERD предприятия является результатом моделирования сущностей. Затем полученная модель предприятия будет расширена и преобразована в детальную модель ERD, которая представляет ту же самую информацию, но на более глубоком и сложном уровне.

Модель ERD предприятия

Как показано на схеме 1, модель ERD уровня предприятия содержит только названия сущностей и отношения между ними, причем взаимосвязи типа многие-ко-многим, (М:N), не обязательно должны быть раскрыты. В приведенной диаграмме это касается отношений между Служащим (Employee) и Умением (Skill), а также отношений Издателя (Publisher) и Автора (Author). В диаграмме намеренно опущены свойства сущностей, подобно тому, как это делается на этапе эскизного проектирования, ведь ERD создается для получения общего плана того, как будет выглядеть база данных. Такую диаграмму свободно можно демонстрировать на совещании, где присутствуют люди, не посвященные в тонкости проектирования баз данных.

В диаграмме ERD я позволила себе некоторую вольность - снабдила каждое отношение номером соответствующего процесса из диаграммы DFD. Сущности в этой диаграмме ERD соответствуют внешним сущностям или накопителям данных из диаграммы DFD.К примеру, найдите на диаграмме ERD сущности Служащий (Employee) и Умение (Skill). Заметьте, что между ними имеется нераскрытое отношение М:N, а на диаграмме DFD им соответствует процесс 3.1, Оценка умений (Skills Evaluation). На DFD этот процесс начинается, когда служащий сдает квалификационный экзамен, по результатам которого формируется перечень его умений (Employee Skills Listing). Отношение ERD между Служащим и Умением читается следующим образом: <Служащий может обладать как несколькими умениями, так и ни одним; а умение может быть присуще как нескольким служащим, так и ни одному>. На диаграмме DFD как Служащий, так и Умение являются накопителями данных, один - внешним, другой - внутренним. На диаграмме ERD им обоим соответствуют сущности. Надо всегда помнить об этой тесной зависимости между моделью процессов DFD и диаграммой сущностей ERD.

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

Детальная модель ERD

Детальная модель ERD является развитием модели ERD предприятия. Основываясь на собранных ранее требованиях, вы добавляете свойства (называемые также атрибутами) каждой сущности. Для разрешения отношения многие-ко-многим (М:N) следует создать ассоциативную сущность, которая будет соединена отношениями один-ко-многим (1:N), к обеим сущностям, образовывавшим отношение многие-ко-многим. Ассоциативная сущность будет содержать записи, определяющие, какие экземпляры одной сущности связаны с какими экземплярами второй сущности, и наоборот. В детальной ERD также вводятся справочные сущности, которые будут содержать перечень значений, ограничивающих домен свойств сущности. На более поздних стадиях разработки модели данных справочные сущности превратятся в справочные таблицы (кодификаторы). На схеме 2 сущность Pub_Category содержит список категорий публикаций (к примеру, книга, печатный журнал, сетевой журнал в Internet, сетевой бюллетень новостей и т.п.). Каждый экземпляр сущности Публикация (Publication) должен соответствовать одной из этих категорий.

Наконец, можно ввести обобщающие и специализирующие сущности - сверхтипы и подтипы. Для обобщения необходимо проанализировать содержание каждой сущности, выделяя сходные моменты, которые требуют создания сущности сверхтипа. Для специализации определите, можно ли ввести категории, позволяющие разбить сущность на подтипы. На схеме 2 новая сущность Личность (Person) является сверхтипом, описывающим подтипы Служащий и Автор. Все совпадающие атрибуты как авторов, так и служащих, будут храниться в виде атрибутов сущности Личность. Характеристики, присущие только служащим, будут храниться в виде атрибутов сущности Служащий, а характерные только для авторов свойства станут атрибутами сущности Автор. Таким образом, появится возможность отнести каждого отдельного индивидуума либо к категории Личность, либо к категории Автор или к категории Служащий, а, возможно, одновременно к категориям Автор и Служащий.

Определение сущностей, отношений, свойств

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

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

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

В процессе создания детальной ERD целесообразно протестировать каждую группу атрибутов сущности с точки зрения нормализации. Убедитесь в том, что для каждой группы атрибутов существует один атрибут, который сможет выступить в роли уникального идентификатора каждого экземпляра сущности. Этот атрибут будет первичным идентифицирующим атрибутом (на более поздних стадиях моделирования данных - первичным ключом). К примеру, PersonID будет первичным идентифицирующим атрибутом сущности Личность (Person). Проверьте, зависят ли от него значения всех остальных атрибутов. Избегайте транзитивных зависимостей, при которых один неключевой атрибут определяет значение другого неключевого атрибута. Следующее мнемоническое правило поможет запомнить все стадии нормализации:

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

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

Мишель Пуле (mapoolet@sqlmag.com)обладает сертификатами MCIS и MCP. Она входит в число основателей консалтинговой компании Mount Vernon Data Systems, находящейся в штате Колорадо, США. Преподает программирование и проектирование баз данных в университете Дэнвера.