Концептуальное проектирование

Концептуальное проектирование – первый шаг в построении БД. В этом процессе обязательно должны принимать участие маркетологи как главные пользователи, для которых информация из БД является основным предметом анализа и основой для планирования. На этапе концептуального проектирования создается неформальная модель, описывающая взаимоотношения объектов предметной области. Для построения концептуальной модели в настоящее время широко применяется подход ER-модели, предложенной Ченом в 1976 г. Модель ER (Entity-Relationship – сущность–связь), основанная на описании предметной области с помощью графических диаграмм, включающих небольшое число разнородных компонентов, дает наглядное представление о концептуальных схемах баз данных. Основные понятия ER-модели – сущность, атрибут и связь.

Для сущности КНИГА атрибут ISBN-код книги является идентификатором отдельной книги (экземпляра сущности). Атрибуты Раздел литературы, Название, Авторы, Цена описывают свойства сущности.

Связи представляют отношения между сущностями. На рис. 25 приведен пример диаграммы связи сущностей ПОКУПАТЕЛЬ и КНИГА.

Рис. 25. Диаграмма связи между сущностями

Базовыми типами связей сущностей являются: «один-к-одному», «один-ко-многим», «многие-ко-многим». При этом вместо стрелок на диаграмме можно указывать тип связи. Связь «один-к-одному» (1:1) определяет такой тип связи между сущностями А и В, когда каждому экземпляру сущности А соответствует один и только один экземпляр сущности В, и наоборот. Например, если покупатель в магазине оплачивает товары только с помощью одной кредитной карты, то связь между сущностями ПОКУПАТЕЛЬ и КРЕДИТНАЯ КАРТА является связью 1:1 (рис. 26).

Рис. 26. Связь «один-к-одному»

Связи «один-к-одному» на практике встречаются редко. В нашем примере целесообразно включить код карты как атрибут сущности ПОКУПАТЕЛЬ и рассматривать одну эту сущность.

Связь «один-ко-многим» (1: М) определяет такой тип связи между сущностями А и В, когда одному экземпляру сущности А может соответствовать ноль, один или несколько экземпляров сущности В, однако каждому экземпляру сущности В соответствует только один экземпляр сущности А. Пример связи «один-ко-многим» – связь между сущностями ПОКУПАТЕЛЬ и ЗАКАЗ. ПОКУПАТЕЛЬ может размещать несколько заказов, но каждый заказ обязательно имеет ПОКУПАТЕЛЯ, и только одного (рис. 27).

Рис. 27. Связь «один-ко-многим»

Связи «один-ко-многим» наиболее широко распространены.

Связи «многие-ко-многим» также широко распространены. К такому типу относится связь между сущностями ЗАКАЗ и КНИГА. В одном заказе может фигурировать несколько различных книг, в то же время каждая книга может встречаться во многих заказах (рис. 28).

Рис. 28. Пример связи «многие-ко-многим»

Проведем теперь проектирование БД путем совмещения представлений отдельных групп пользователей.

Для сотрудников отдела заказов есть две сущности: ЗАКАЗ и КНИГА. Как мы отметили, связь ЗАКАЗ – КНИГА является связью «многие-ко-мно-гим». При анализе связи «многие-ко-многим» часто возникает необходимость ввода новых сущностей. В нашем примере непонятно, где хранить такую характеристику, как Количество заказанных экземпляров. Это количество определяется книгой, их может быть в заказе несколько, и не может быть атрибутом сущности ЗАКАЗ. В то же время количество заказанного товара не может быть и атрибутом сущности КНИГА, так как определяется заказом. Выходом из положения будет ввод сущности КОРЗИНА ЗАКАЗА, которая связывает заказ с заказанными книгами.

Сущность ЗАКАЗ имеет атрибуты: Код заказа, Дата заказа, Покупатель, Телефон, Адрес электронной почты, Адрес доставки. Код заказа является идентифицирующим отдельный экземпляр сущности (конкретный заказ) атрибутом.

Сущность КНИГА имеет атрибуты: ISBN-код книги, Название, Авторы, Издательство, Год издания, Цена. ISBN-код считается международным стандартным номером книг, который присваивается каждой книге. Таким образом, он является естественным идентифицирующим атрибутом.

Сущность КОРЗИНА ЗАКАЗА имеет атрибуты: Код заказа, ISBN-код книги, Количество экземпляров в заказе. Однозначно определяющим экземпляр сущности признаком становится совокупность полей Код заказа и ISBN-код книги.

Связь «многие-ко-многим» между сущностями ЗАКАЗ и КНИГА реализуется в такой схеме через сущность КОРЗИНА ЗАКАЗА (рис. 29). На рисунке помимо названий сущностей указаны ключевые атрибуты.

Рис. 29. Пользовательское представление сотрудников отдела заказов

С точки зрения сотрудников маркетинговой службы важным является анализ потребительского спроса, определение потребностей и предпочтений покупателей. Поэтому в представлении маркетолога ПОКУПАТЕЛЬ рассма-тривается как отдельная сущность, ее следует выделить из сущности ЗАКАЗ, оставив в заказе некоторый идентифицирующий покупателя атрибут, например, код покупателя. Атрибутами сущности ПОКУПАТЕЛЬ выступает Код покупателя, Организация, Фамилия, Имя, Отчество, Телефон, Адрес электронной почты, Почтовый адрес. Атрибут Организация определяет, осуществляет заказ организация или частное лицо. Это атрибут-признак. Сущность ПОКУПАТЕЛЬ позволяет исследовать сегмент потребителей, выявлять постоянных клиентов и рационально организовать обратную связь с потребителем. Связь между сущностями ПОКУПАТЕЛЬ и ЗАКАЗ представлена на рис. 30.

Рис. 30. Пользовательское представление сотрудников отдела маркетинга

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

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

Руководитель отдела доставки хотел бы иметь более полные личные данные по курьерам. Его представление состоит из двух сущностей: ЗАКАЗ и КУРЬЕР. Сущность ЗАКАЗ имеет атрибуты: Код заказа, Дата доставки, Дата исполнения, Тип доставки, Код курьера. Сущность КУРЬЕР определяется атрибутами Код курьера, Фамилия, Имя, Отчество, Дата рождения, Дата приема на работу, Рабочая смена. Сущности КУРЬЕР и ЗАКАЗ связаны соотношением «один-ко-многим» (рис. 31).

Рис. 31. Пользовательское представление сотрудников отдела доставки

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

Полная концептуальная модель базы данных представляется теперь в виде пяти сущностей, связанных между собой связями «один-ко-многим»
(рис. 32).

Рис. 32. Полная концептуальная модель базы данных интернет-магазина

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

О к о н ч а н и е т а б л. 1