Разработка плана базы данных

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

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

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

  • сбор сведений;

  • выделение объектов;

  • моделирование объектов;

  • определение типов данных для каждого объекта;

  • определение связей между объектами.

Сбор сведений

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

Выделение объектов

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

Основным объектом в образце базы данных База данных AdventureWorks2008R2, поставляемом вместе с SQL Server, является велосипед. Объектами, связанными с велосипедом внутри компании, являются ее сотрудники, производящие велосипеды, поставщики деталей, необходимых для производства, клиенты, покупающие велосипеды, а также осуществляемые сделки купли-продажи. Каждому из указанных объектов соответствует таблица базы данных.

Моделирование объектов

После определения объектов системы необходимо записать их в таком порядке, чтобы можно было представить систему визуально. Модель базы данных может быть использована в качестве ссылки при внедрении базы данных.

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

Определение типов данных для каждого объекта

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

  • Столбцы необработанных данных

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

  • Категориальные столбцы

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

  • Столбцы идентификаторов

    Эти столбцы предоставляют механизм идентификации каждого элемента, хранящегося в таблице. В названиях подобных столбцов часто присутствуют строки «ID» и «number», например employee_id, invoice_number и publisher_id. Столбец идентификатора является основным компонентом, используемым для получения доступа к строкам данных таблицы, как пользователями, так и внутренними функциями базы данных. В некоторых случаях идентификатор объекта может обладать реальным смыслом, например являться номером социального страхования. Однако в большинстве случаев при определении таблицы для хранения строк данных создается надежный, искусственный идентификатор.

  • Реляционные или ссылочные столбцы

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

Определение связи между объектами

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

Допустим, что конструктор базы данных База данных AdventureWorks2008R2 создал в ней таблицы для продуктов и их моделей. Таблица Production.Product содержит сведения о каждом товаре, содержащем столбец идентификаторов с именем ProductID, столбцы данных о названии товаров, цены на товары, цвета товаров, а также их размер и вес. Таблица содержит группировочные столбцы, такие как Class или Style, что позволяет группировать товары по соответствующим критериям. Для каждого товара также существует модель, сведения о которой содержатся в другой таблице. Поэтому таблица Production.Product содержит столбец ProductModelID, в котором хранятся идентификаторы моделей товаров. Для добавления строк данных для товара необходимо наличие значения параметра ProductModelID в таблице Production.ProductModel.

См. также

Другие ресурсы