Моделирование информационного обеспечения

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

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

Разработка БД выполняется на основе моделирования данных. Цель моделирования данных состоит в обеспечении разработчика ИС концептуальной схемой БД в форме одной или нескольких (локальных) моделей, которые относительно легко могут быть отображены в любую систему БД. Наиболее распространенным средством моделирования данных являются диаграммы «сущность — связь» (ERD, entity-relationship diagram). С помощью ERD осуществляется детализированное представление накопителей данных из DFD-диаграмм, а также документируются информационные аспекты бизнес-модели, включая идентификацию бизнес-объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их связей с другими объектами (отношений).

Базовые понятия, использующиеся при создании моделей на основе диаграмм ERD, представлены ниже.

Сущность (entity) — множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и др.), обладающих общими характеристиками-атрибутами. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО).

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

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

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

Связь (relationship) — поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Связь — это ассоциация между сущностями, при которой каждый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, и наоборот.

Атрибут (attribute) — любая характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут отражает тип характеристик или свойств, ассоциированных со множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, предметов и т. д.). Экземпляр атрибута — это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее значением, называемым значением атрибута. На диаграмме «сущность — связь» атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным набором значений ассоциированных атрибутов.

Наиболее распространенными методами построения ERD-диаграмм являются метод Баркера и метод IDEFI. Метод Баркера основан на нотации, предложенной автором, и используется в CASE-средстве Oracle Designer. Метод IDEFI базируется на подходе Чена и позволяет построить модель данных, эквивалентную реляционной модели БД в третьей нормальной форме. На основе совершенствования метода IDEFI создана его новая версия — метод IDEFIX, разработанный с учетом таких требований, как простота для изучения и возможность автоматизации. IDEFIXдиаграммы используются в ряде распространенных CASE-средств (в частности, ERwin, Design/IDEF).

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

Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может порождать каждый экземпляр сущности-родителя). Могут быть использованы следующие мощности связей:

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

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

Связь изображается линией, проводимой между сущностыо-родителем и сущностью-потомком, с точкой на конце линии у сущности-потомка. Мощность связей может принимать следующие значения: N — ноль, один или более; Z — ноль или один; Р — один или более. По умолчанию мощность связей принимается равной N.

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

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

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

Сущности могут иметь также внешние ключи (Foreign Key), которые используются в качестве части или целого первичного ключа или неключевого атрибута. Для обозначения внешнего ключа внутрь блока сущности помещают имена атрибутов, после которых следуют буквы FK в скобках (рис. 5.6).

Рис. 5.6. Пример обозначения связи между объектами.

Описание данных предполагает два уровня представления модели — логический и физический.

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

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

Построение логической модели данных предполагает идентификацию сущностей и атрибутов, т. е. на этом этапе необходимо определить, какая информация будет храниться в конкретной сущности или атрибуте. Сущность можно определить как объект, событие или концепцию, информация о которых должна сохраняться. Сущности должны иметь наименование с четким смысловым значением, именоваться существительным в единственном числе, не носить «технических» наименований и быть достаточно важными для того, чтобы их следовало включить в модель. Именование сущности в единственном числе облегчает в дальнейшем чтение модели. Фактически имя сущности дается по имени ее экземпляра. Примером может быть сущность «Заказчик» (но не «Заказчики»!) с атрибутами «Номер заказчика», «Фамилия заказчика» и «Адрес заказчика». На уровне физической модели ей может соответствовать таблица «Customer» с колонками «Customer_number», «Customer_name» и «Customer_address». Каждая сущность должна быть полностью определена с помощью текстового описания.

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

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

Каждый атрибут должен быть определен, при этом следует избегать циклических определений, например, когда термин 1 определяется через термин 2, термин 2 — через термин 3, а термин 3 в свою очередь — через термин 1. Часто приходится создавать производные атрибуты, т. е. атрибуты, значение которых можно вычислить из других атрибутов. Примером производного атрибута может служить «Возраст сотрудника», который может быть вычислен из атрибута «Дата рождения сотрудника». Такой атрибут может привести к конфликтам: если вовремя не обновить значение атрибута «Возраст сотрудника», то он может противоречить значению атрибута «Дата рождения сотрудника». Производные атрибуты — ошибка нормализации, однако их вводят для повышения производительности системы, чтобы не проводить вычисления, которые на практике могут быть сложными.

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

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

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

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

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

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

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

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

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

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

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

Домен можно определить как совокупность значений, из которых берутся значения атрибутов. Каждый атрибут может быть определен только на одном домене, но на каждом домене может быть определено множество атрибутов. В понятие домена входит не только тип данных, но и область значений данных. Например, можно определить домен «Возраст» как положительное целое число и определить атрибут «Возраст сотрудника» как принадлежащий этому домен}'.

Домены позволяют облегчить работу с данными как разработчикам на этапе проектирования, так и администраторам БД на этапе эксплуатации системы. На логическом уровне домены можно описать без конкретных физических свойств. На физическом уровне они автоматически получают специфические свойства. Так, домен «Возраст» может иметь на логическом уровне тип Number, на физическом уровне колонкам домена будет присвоен тип INTEGER.

Физическая модель содержит всю информацию, необходимую для реализации конкретной БД. Различают два уровня физической модели:

• 1) трансформационную модель;
• 2) модель СУБД.

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

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

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

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

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

Триггером называется процедура, которая выполняется автоматически как реакция на событие. Таким событием могут быть вставка, изменение или удаление строки в существующей таблице. Триггер сообщает СУБД, какие действия нужно выполнить при выполнении команд SQL INSERT, UPDATE или DELETE для обеспечения дополнительной функциональности, выполняемой на сервере.

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

• [1] Кагаловский М. Р. Энциклопедия технологий баз данных. М.: Финансы и статистика, 2002.