Ошибки, допущенные при проектировании базы данных, могут существенно снизить эффективность её использования. Информационное моделирование позволяет снизить риск совершения критических ошибок.
При создании информационной модели также целесообразно использование специализированного инструментария (AllFusion ERwin Data Modeler или аналогичного) и определённой методологии (нотации). Наиболее распространены нотации методологий IDEF1X (IDEF1 Extended, Integration DEFinition for Information Modeling) и IE (Information Engineering). IDEF1X и IE относятся к типу методологий «сущность-связь» (Entity-Relationship, ER). Их назначение – определить, какая информация требуется для реализации функций, выявленных при функциональном моделировании. Они используют различные нотации для представления проектируемых информационных структур. Рекомендуется использование нотации IE в виду её визуально более строгого вида. Различия между собственно методологиями для дипломного проекта в большинстве случаев несущественны.
Информационное моделирование системы выполняется на основе совокупности моделей, принадлежащих нескольким уровням проектирования. На первом уровне создаётся логическая модель данных, при этом выявляются информационные объекты системы, зависимости между ними, задаются свойства объектов. На втором уровне строится универсальная физическая модель данных. В ней определяется состав и структура таблиц базы данных, основные характеристики полей таблиц. Модели этих двух уровней не зависят от выбранной СУБД. На третьем уровне определяется физическая модель данных, специфичная для выбранной СУБД. При этом могут быть заданы расширенные характеристики таблиц и их полей, описаны дополнительные объекты базы данных.
Основными конструктивными элементами логической модели являются сущности, их атрибуты и связи между ними.
Рекомендуется создание начального набора сущностей по принципу «один факт сохраняется в одном месте». Для этого следует выделить основные информационные объекты и разместить их свойства как атрибуты по разным сущностям. Уже на этом уровне для каждого атрибута могут быть заданы тип и размер, а также дополнительные характеристики, устанавливающие значения, допустимые для атрибута, а также значение по умолчанию. Каждая сущность должна обдать первичным ключом, состоящим из одного или нескольких атрибутов. Кроме того, возможно создание альтернативных ключей, способных заменить первичный ключ, и ключей, с помощью которых можно изменять порядок отображения кортежей.
Количество сущностей в модели зависит от сложности объекта автоматизации и типа проектируемой системы. Для системы, в которой ключевым компонентом является база данных, сущностей должно быть не меньшее десяти.
Следует выполнить проверку полученного начального проекта базы данных методом нормальных форм (с использованием нормальной формы Бойса- Кодда – НФБК) и внести соответствующие исправления. При необходимости можно осознанно нарушить правила нормализации, приведя конкретные соображения относительно увеличения эффективности работы с базой данных.
ER-диаграмма логической модели должна быть размещена в тексте записки.
Описание сущностей и их атрибутов целесообразно привести в табличном виде. Количество таблиц с описанием атрибутов будет соответствовать количеству сущностей.
При переходе к физической модели сущности заменяются реляционными таблицами, атрибуты – полями.
Универсальную физическую модель можно описать совокупностью таблиц. После имени таблицы или поля в скобках указывается наименование соответствующей сущности или атрибута логической модели.
В автоматизированных системах, которые разрабатываются в рамках дипломных проектов, как правило, используется только одна СУБД. Поэтому уровень универсальной физической модели в явном виде можно не выделять. В этом случае приводимые на этом уровне сведения должны быть отнесены к первому и/или третьему уровню.
Для выбранной СУБД выполняется проектирование реализации базы данных.
. При использовании специализированной среды моделирования база данных в формате целевой СУБД будет сгенерирована автоматически.
На этом уровне целесообразно выполнить описание индексов таблиц. При небольшом количестве индексов можно привести эти сведения в текстовом виде.
Помимо физических таблиц, ряд СУБД допускает использование представлений – виртуальных таблиц, представляющих данные отдельных полей и записей одной или нескольких физических таблиц. Если представление использует фильтрацию данных, выборку из нескольких таблиц и другие возможности, необходимо привести текст SQL-запроса, с помощью которого оно создаётся. Для простейшего представления достаточно указать список полей «базовой» физической таблицы.
При использовании в базе данных триггеров и хранимых процедур следует привести их тексты.
Конкретный состав описываемых типов объектов зависит от возможностей СУБД и от использования объектов этого типа при разработке информационного обеспечения.