Концептуальное проектирование. 
Экономическая информатика

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

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

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

Связи представляют отношения между сущностями. На рис. 3.34 приведен пример диаграммы связи сущностей Покупатель и Книга.

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

Базовыми типами связей сущностей являются «один-кодному», «один-ко-многим», «многие-ко-многим». При этом вместо стрелок на диаграмме можно указывать тип связи.

Связь «один-к-одному» (1: 1) определяет такой тип связи между сущностями А и В, когда каждому экземпляру сущности А соответствует один и только один экземпляр сущности В, и наоборот. Например, если покупатель в магазине оплачивает товары только с помощью одной кредитной карты, то связь между сущностями Покупатель и Кредитная карта является связью 1: 1 (рис. 3.35).

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

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

Связь «один-ко-многим» (1: М) определяет такой тип связи между сущностями, А и В, когда одному экземпляру сущности, А может соответствовать ноль, один или несколько экземпляров сущности В, однако каждому экземпляру сущности В соответствует только один экземпляр сущности А.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 3.5. Словарь атрибутов концептуальной модели базы данных интернет-магазина.

Продолжение табл. 3.5