3.1.1 Концептуальная модель предметной области
Основными конструктивными элементами концептуальной модели являются сущности, их атрибуты (свойства) и связи между сущностями. Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущности и связи между ними концептуальной модели представляются в виде реляционной таблицы (отношения). Отношение, соответствующее сущности, содержит атрибуты (столбцы), являющиеся атрибутами сущности и описывающие сущность (объект). Атрибут или некоторое множество атрибутов, которые однозначно определяют объект называются первичным ключом.
Удобно представлять отношение как таблицу, где каждая строка есть кортеж, и каждый столбец соответствует одному компоненту. Столбцы при этом называются атрибутами и им присваивают имена. Список имён атрибутов называется схемой отношения. Совокупность схем отношений, используемых для представления информации, называются схемой базы данных, а текущие значения соответствующих отношений – базой данных.
При разработке концептуальной модели, прежде всего, следует определить сущности. С этой целью нужно сделать следующее:
необходимо понять, какая информация должна храниться и обрабатываться и можно ли это определить как сущность;
присвоить этой сущности имя;
выявить атрибуты сущности и присвоить им имя;
определить уникальный идентификатор сущности.
Выявив сущности, необходимо определить, какие связи имеются между ними, т.к. именно эти связи и определяют в конечном итоге интегрированную базу данных.
При определении связей (естественно, рассматриваем только те связи, которые имеют отношение к решаемым задачам) необходимо учитывать следующее:
то, как экземпляр одной сущности связан с экземпляром другой сущности;
то, как должны быть установлены связи, чтобы была возможность ответа на все запросы пользователей (исходя из их информационных потребностей).
Далее необходимо присвоить связям имена и определить тип связей.
На втором этапе построенные локальные модели объединяются в обобщенную концептуальную модель, после чего необходимо привести модель к требуемому уровню нормальной формы.
На основании результатов анализа предметной области выделены ее сущности (таблица 3.1), а также атрибуты этих сущностей (таблица 3.2):
Таблица 3.1 – Перечень сущностей предметной области
|
Идентификаторсущности |
Назначение |
|
Client |
Заказчик |
|
Order |
Заказ |
|
OrderItem |
Позиция заказа (конкретный заказанный товар) |
|
Invoice |
Счет на оплату заказа |
|
Basket |
Корзина покупок |
|
ParcelIn |
Входящая посылка, поступившая из магазина |
|
ParcelOut |
Исходящая посылка, доставляющая клиентам выкупленные для них товары |
|
ParcelOutItems |
Элемент содержимого исходящей посылки (каждая отдельно взятая покупка) |
Таблица 3.2 – Атрибуты сущностей предметной области
|
Сущность |
Атрибут |
Назначение |
|
1 |
2 |
3 |
|
Client |
client_id |
Идентификатор заказчика (Перв. ключ) |
|
fullname |
Полное имя заказчика | |
|
|
Адрес электронной почты | |
|
address |
Почтовый адрес | |
|
city |
Город | |
|
state |
Область, край, республика | |
|
postcode |
Почтовый индекс | |
|
country |
Страна | |
|
phonenumber |
Телефонный номер | |
|
password |
Пароль | |
|
Order |
order_id |
Идентификатор заказа (Перв. ключ) |
|
ordernum |
Внутренний номер заказа | |
|
client_id |
Идентификатор заказчика (Внеш. ключ) | |
|
date |
Дата размещения заказа | |
|
invoice_id |
Идентификатор счета (Внеш. ключ) | |
|
status |
Статус заказа | |
|
notes |
Заметки | |
|
OrderItem |
orderitem_id |
Идентификатор товара (Перв. ключ) |
|
order_id |
Идентификатор заказа (Внеш. ключ) | |
|
orderitemstatus |
Статус товара | |
|
basket_id |
Идентификатор корзины (Внеш. ключ) | |
|
room |
Литер помещения склада | |
|
rack |
Номер стеллажа | |
|
shelf |
Номер полки | |
|
place |
Номер места на полке | |
|
title |
Наименование товара | |
|
url |
URLстраницы с описанием товара | |
|
code |
Артикул товара | |
|
color |
Цвет товара | |
|
size |
Размер товара | |
|
price |
Цена товара | |
|
amount |
Заказанное количество экземпляров | |
|
photo |
Фотография товара | |
|
parcelout_id |
Идентификатор исходящей посылки (Внеш. ключ) |
Продолжение таблицы 3.2
|
Invoice |
invoice_id |
Идентификатор счета (Перв. ключ) |
|
invoicenum |
Внутренний номер счета | |
|
invoicedate |
Дата выставления счета | |
|
duedate |
Дата окончания действия счета | |
|
datepaid |
Дата фактической оплаты | |
|
subtotal |
Сумма счета | |
|
credit |
Сумма, погашенная за счет средств с виртуального лицевого счета заказчика | |
|
invoicestatus |
Статус счета | |
|
paymentmethod |
Использованный способ оплаты | |
|
invoicenotes |
Заметки | |
|
Basket |
basket_id |
Идентификатор корзины (Перв. ключ) |
|
baskettitle |
Наименование | |
|
datecreated |
Дата создания | |
|
datepassedtoshopping |
Дата передачи на выкуп товаров | |
|
datecompleted |
Дата завершения выкупа товаров | |
|
basketstatus |
Статус корзины | |
|
basketnotes |
Заметки | |
|
ParcelIn |
parcelin_id |
Идентификатор входящей посылки (Перв. ключ) |
|
date_arrival |
Дата поступления | |
|
sender |
Информация об отправителе | |
|
senderpostcarrier |
Почтовый оператор | |
|
sendertracking |
Трек-номер посылки | |
|
basket_id |
Идентификатор корзины, в рамках выкупа которой поступила посылка (Внеш. ключ) | |
|
parcelinnotes |
Заметки | |
|
ParcelOut |
parcelout_id |
Идентификатор отправленной посылки (Перв. ключ) |
|
parceloutaddress |
Адрес назначения посылки | |
|
dateshipping |
Дата отправки | |
|
postcarrier |
Почтовый оператор | |
|
tracking |
Трек-номер посылки | |
|
length |
Длина | |
|
width |
Ширина | |
|
height |
Высота | |
|
weight |
Вес | |
|
parceloutnotes |
Заметки |
ER-диаграмма системы на уровне концептуальной модели представлена на рисунке 3.1.
Рисунок 3.1 ER-диаграмма системы на уровне концептуальной модели
БД как модель предметной области отражает ее реальное состояние в любой фиксированный момент времени в виде текущей конфигурации хранимых данных. При этом любое хранимое в БД значение любого семантически значимого атрибута в любой момент времени должно быть истинным значением характеристики соответствующего объекта предметной области. Кроме того, состояние БД в любой момент времени должно иметь осмысленную интерпретацию в терминах предметной области. Это называется требованием поддержания целостности состояния БД.
В рассматриваемой структуре БД каждая сущность идентифицируется уникальным ключом, разработана система внешних ключей. База данных не содержит несогласованных значений внешних ключей, то есть при работе с записями обеспечивается возможность каскадного обновления связанных полей и каскадного удаления связанных записей. Целостность, определяемая пользователем, поддерживается обеспечением выбора значений внешних ключей из списков без разрешения варианта ввода недопустимого значения.
Нормализация предусматривает определение требуемых атрибутов с последующим созданием из них нормализованных таблиц, основанных на функциональных зависимостях между этими атрибутами. Отношение, в котором на пересечении каждой строки и каждого столбца содержится атомарное (или единственное) значение, находится в 1-й нормальной форме. При этом необходимо, чтобы отношение имело первичный ключ.
Вторая нормальная форма применяется к отношениям с составными ключами, т.е. к таким отношениям, первичный ключ которых состоит из двух или более атрибутов. Отношение с первичным ключом на основе единственного атрибута всегда находится во 2-й нормальной форме. Отношение, которое находится в 1-й нормальной форме и каждый атрибут которого, не входящий в состав первичного ключа, зависит только от полного значения ключа и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа, имеет вторую нормальную форму (каждый неключевой атрибут функционально полно зависит от ключа).
Отношение находится в 3-й нормальной форме, если оно представлено во 2-й нормальной форме и не имеет не входящих в первичный ключ атрибутов, которые находились бы в транзитивной функциональной зависимости от этого первичного ключа.
Разработанная модель находится в 3-й нормальной форме, так как:
– атрибуты сущностей являются атомарными;
– каждый неключевой атрибут функционально полно зависит от первичного ключа;
– в модели отсутствуют транзитивные зависимости неключевых атрибутов от ключа.