Концептуальное проектирование
Концептуальное проектирование является первым шагом в построении базы данных. В этом процессе обязательно должны принимать участие маркетологи как главные пользователи, для которых информация из базы данных является основным предметом анализа и основой для планирования.
На этапе концептуального проектирования создается неформальная модель, описывающая взаимоотношения между объектами предметной области. Для построения концептуальной модели в настоящее время широко применяется подход ER-модели, предложенной Ченом в 1976 г. Модель ER (Entity-Relationship – Сущность-Связь) основана на описании предметной области с помощью графических диаграмм, включающих небольшое число разнородных компонентов. ER-модель дает наглядное представление концептуальных схем баз данных.Основными понятиями ER-модели являются сущность, атрибут и связь.
Для сущности КНИГА атрибут ISBN-код книги является идентификатором отдельной книги (экземпляра сущности). Атрибуты Раздел литературы, Название, Авторы, Цена описывают свойства сущности.
Связи представляют отношения между сущностями. На рис. 7.13 приведен пример диаграммы связи сущностей ПОКУПАТЕЛЬ и КНИГА.
Рис. 7.13. Связи между сущностями
Базовыми типами связей сущностей являются: «один-к-одному», «один-ко-многим», «многие-ко-многим». При этом вместо стрелок на диаграмме можно указывать тип связи.
Связь «один-к-одному» (1:1) определяет такой тип связи между сущностями А и В, когда каждому экземпляру сущности А соответствует один и только один экземпляр сущности В и наоборот. Например, если покупатель в магазине оплачивает товары только с помощью одной кредитной карты, то связь между сущностями ПОКУПАТЕЛЬ и КРЕДИТНАЯ КАРТА является связью 1:1 (рис. 7.14).
 | Примечание |
| Сущность – это некоторая абстракция реального объекта, процесса или явления, информацию о котором необходимо хранить в системе. В нашей системе сущностями являются покупатели, заказы, книги. Атрибут сущности – это некоторая характеристика сущности, которая описывает одно из ее свойств. Атрибут имеет имя и принимает значение из некоторого множества значений. Например, у сущности КНИГА могут быть атрибуты: ISBN-код книги, Раздел литературы, Название, Авторы, Цена. Множество значений, разрешенных для данного атрибута, называется его доменом. Домен может насчитывать лишь несколько элементов или очень большое число элементов. Например, для сущности КНИГА домен атрибута Раздел литературы насчитывает около двадцати элементов, домен атрибута Название имеет очень большое число текстов возможных наименований, состоящих из не более чем 50-ти символов и т. д. Домен также указывает на тип возможных данных (число, текст, дата и др.) Для идентификации отдельных экземпляров сущностей должны существовать атрибуты или совокупность атрибутов, которые позволили бы отличать один экземпляр сущности от всех остальных. Такие атрибуты называются идентификаторами. |
Рис. 7.14 Связь «один-к-одному»
Связи «один-к-одному» на практике встречаются редко. В нашем примере целесообразно включить код карты как атрибут сущности ПОКУПАТЕЛЬ и рассматривать одну эту сущность.
Связь «один-ко-многим» (1: М) определяет такой тип связи между сущностями А и В, когда одному экземпляру сущности А может соответствовать ноль, один или несколько экземпляров сущности В, однако каждому экземпляру сущности В соответствует только один экземпляр сущности А.
Пример связи «один-ко-многим» – связь между сущностями ПОКУПАТЕЛЬ и ЗАКАЗ. ПОКУПАТЕЛЬ может размещать несколько заказов, но каждый заказ обязательно имеет ПОКУПАТЕЛЯ и только одного (рис. 7.15).
Рис. 7.15. Связь «один-ко-многим»
Связи «один-ко-многим» наиболее широко распространены.
Связи «многие-ко-многим» также широко распространены. К такому типу относится связь между сущностями ЗАКАЗ и КНИГА. В одном заказе может фигурировать несколько различных книг, в то же время каждая книга может встречаться во многих заказах (рис. 7.16).
Рис. 7.16. Связи «многие-ко-многим»
Проведем теперь проектирование базы данных путем совмещения представлений отдельных групп пользователей.
Для сотрудников отдела заказов есть две сущности: ЗАКАЗ и КНИГА. Как мы отметили, связь ЗАКАЗ – КНИГА является связью «многие-ко-многим». При анализе связи «многие-ко-многим» часто возникает необходимость ввода новых сущностей. В нашем примере непонятно, где хранить такую характеристику как Количество заказанных экземпляров. Это количество определяется книгой, которых может быть в заказе несколько, и не может быть атрибутом сущности ЗАКАЗ. В то же время количество заказанного товара не может быть и атрибутом сущности КНИГА, так как определяется заказом. Выходом из положения является ввод сущности КОРЗИНА ЗАКАЗА, которая связывает заказ с заказанными книгами.
Сущность ЗАКАЗ имеет атрибуты: Код заказа, Дата заказа, Покупатель, Телефон, Адрес электронной почты, Адрес доставки. Код заказа является идентифицирующим отдельный экземпляр сущности (то есть конкретный заказ) атрибутом.
Сущность КНИГА имеет атрибуты: ISBN-код книги, Название, Авторы, Издательство, Год издания, Цена. ISBN-код является международным стандартным номером книг, который присваивается каждой книге. Таким образом, он является естественным идентифицирующим атрибутом.
Сущность КОРЗИНА ЗАКАЗА имеет атрибуты: Код заказа, ISBN-код книги, Количество экземпляров в заказе. Определяющим экземпляр сущности признаком является совокупность полей Код заказа и ISBN-код книги.
Связь «многие-ко-многим» между сущностями ЗАКАЗ и КНИГА реализуется в такой схеме через сущность КОРЗИНА ЗАКАЗА (рис. 7.17). На рисунке помимо названий сущностей указаны ключевые атрибуты.
Рис. 7.17. Пользовательское представление сотрудников отдела заказов
С точки зрения сотрудников маркетинговой службы важным является анализ потребительского спроса, определение потребностей и предпочтений покупателей. Поэтому в представлении маркетолога ПОКУПАТЕЛЬ рассматривается как отдельная сущность, ее следует выделить из сущности ЗАКАЗ, оставив в заказе некоторый идентифицирующий покупателя атрибут, например, код покупателя. Атрибутами сущности ПОКУПАТЕЛЬ являются Код покупателя, Организация, Фамилия, Имя, Отчество, Телефон, Адрес электронной почты, Почтовый адрес. Атрибут Организация определяет, осуществляет ли заказ организация или частное лицо. Это атрибут-признак. Сущность ПОКУПАТЕЛЬ позволяет исследовать сегмент потребителей, выявлять постоянных клиентов и рационально организовать обратную связь с потребителем. Связь между сущностями ПОКУПАТЕЛЬ и ЗАКАЗ представлена на рис. 7.18.
Для выявления спроса на отдельную продукцию и группы продукции, а также для предоставления покупателям возможности поиска книги по разделу, важно ввести в описание сущности КНИГА атрибут Раздел литературы. В этом случае можно реализовать такие запросы, как получение информации об объемах и поступлениях от продаж книг различных разделов.
Сотрудники отдела доставки оперируют только с сущностью ЗАКАЗ. Для них важно обеспечить своевременное выполнение заказа и управление работой курьеров. Поэтому сущность ЗАКАЗ дополняется такими атрибутами как Дата доставки, Дата исполнения, Тип доставки, Цена доставки, Курьер. Курьеру бывают нужны дополнительные сведения: ближайшие станции метро, № маршрутов городского транспорта, как пройти/проехать, желательные часы доставки и т. п. Поэтому целесообразно включить также атрибут Примечание, в котором могут содержаться такие сведения.
Руководитель отдела доставки хотел бы иметь более полные личные данные по курьерам. Его представление состоит из двух сущностей: ЗАКАЗ и КУРЬЕР. Сущность ЗАКАЗ имеет атрибуты: Код заказа, Дата доставки, Дата исполнения, Тип доставки, Код курьера. Сущность КУРЬЕР определяется атрибутами Код курьера, Фамилия, Имя, Отчество, Дата рождения, Дата приема на работу, Рабочая смена. Сущности КУРЬЕР и ЗАКАЗ связаны соотношением один-ко-многим (рис. 7.20).
Рис. 7.18 Пользовательское представление сотрудников отдела маркетинга
Рис. 7.19 Пользовательское представление сотрудников отдела доставки
С точки зрения сотрудника бухгалтерии важным является, как именно будет произведена оплата: наличными курьеру, кредитной картой, через определенную платежную систему Интернет. Поэтому сущность ЗАКАЗ дополняется атрибутом Форма оплаты.
Полная концептуальная модель базы данных представляется теперь в виде пяти сущностей, связанных между собой связями «один-ко-многим» (рис. 7.20).
 |
| Рис. 7.20 Полная концептуальная модель базы данных Интернет-магазина |
Помимо схемы взаимосвязей сущностей в концептуальной модели описываются также атрибуты сущностей и их домены, то есть формируется так называемый Словарь атрибутов. Словарь атрибутов для нашего примера представлен в табл. 7.1. Идентифицирующие атрибуты выделены жирным шрифтом.
| Таблица 7.1 Словарь атрибутов концептуальной модели базы данных Интернет-магазина | |
| Атрибут | Домен |
| ПОКУПАТЕЛЬ | |
| Код покупателя | Целое число, уникальный номер |
| Организация | Да/Нет |
| Фамилия | Текст, не более 30 символов, содержащий фамилии |
| Имя | Текст, не более 20 символов, содержащий имена |
| Отчество | Текст, не более 20 символов, содержащий отчества |
| Телефон | Текст, не более 15 символов, содержащий 10-ти значный номер |
| Адрес электронной почты | Текст, не более 30 символов, содержащий символ @ |
| Почтовый адрес | Текст, не более 255 символов |
| ЗАКАЗ | |
| Код заказа | Целое число, уникальный номер |
| Код покупателя | Целое число |
| Форма оплаты | Одно из: наличными курьеру; кредитной картой; платежную систему CyberPlat ; платежную систему WebMoney; платежную систему КредитПилот. Список может расширяться |
| Дата заказа | Дата |
| Дата доставки | Дата |
| Дата исполнения | Дата |
| Тип доставки | Одно из: курьером по Москве; курьером по Московской области; курьером по Санкт-Петербургу; почтой наложенным платежом; почтой по предоплате. Список может расширяться |
| Цена доставки | Вещественное число, денежный формат, определяется видом доставки |
| Код курьера | Целое число |
| Адрес доставки | Текст, не более 255 символов |
| Примечание | Текст, не более 255 символов |
| КОРЗИНА ЗАКАЗА | |
| Код заказа | Целое число |
| ISBN-код книги | Текст, не более 25 символов |
| Количество экземпляров в заказе | Целое число, не более 1000 |
| КНИГА | |
| ISBN-код книги | Текст, не более 25 символов |
| Раздел литературы | Текст, не более 50 символов |
| Название | Текст, не более 255 символов |
| Авторы | Текст, не более 255 символов |
| Издательство | Текст, не более 50 символов |
| Год издания | Целое число от 2000 до 2100 |
| Цена | Вещественное число, денежный формат |
| КУРЬЕР | |
| Код курьера | Целое число |
| Фамилия | Текст, не более 30 символов |
| Имя | Текст, не более 20 символов |
| Отчество | Текст, не более 20 символов |
| Дата рождения | Дата |
| Дата приема на работу | Дата |
| Рабочая смена | Одно из: первая, вторая, обе |
Логическое проектирование
Если на этапе концептуального проектирования объектом исследования является предметная область, то на этапе логического проектирования в качестве объекта исследования выступают уже сами данные, их структура и правила построения.
Все возможные структуры данных подразделяются на несколько классов структур, представляющих собой структурные модели данных. Часто, говоря о логическом проектировании, эти модели называют просто моделями данных.
Классической и наиболее широко используемой в настоящее время моделью данных являются реляционная модель данных. Исторически ей предшествовали иерархическая и сетевая модели. Ряд СУБД иерархического и сетевого типов применяется до сих пор, так как многие корпорации имеют огромные базы данных, реализованные в этих системах.