Электронная коммерция

ЛЕКЦИЯ №7

Тема Электронная коммерция

Проектирование баз данных для коммерческих приложений

Учебные вопросы:
Microsoft SQL Server
Заключительная часть

Вводная часть:

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

В основе проектирования решений в области электронной коммерции лежит использование системы управления базами данных Microsoft SQL Server. Это не говорит о безусловной монополии данного продукта. Вместо нее также можно использовать Oracle и другие базы данных с поддержкой интерфейсов ODBC и OLE DB. При изложении материала данной лекции пример применения программного кода SQL был по возможности избавлен от привязки к конкретному серверу для того, чтобы его можно было использовать на разных платформах баз данных.

Первый учебный вопрос: - Microsoft SQL Server

SQL Server предлагается фирмой Microsoft как решение промышленного уровня в области баз данных, Microsoft Access является предложением начального уровня, предназначенным для разработки простых приложений. Осенью 1998 года появилась версия SQL Server 7, заметно усовершенствованная по сравнению с версией 6.

SQL Server - мощная платформа для построения реляционных баз данных, используемых при построении коммерческих Web-сайтов с большим объемом проводимых операций. Эта серверная технология заложена в основу таких коммерческих сайтов, как Martha Stewart (www. ), Electronics Boutique (www. ) и 1-800 Flowers ().

Примечание

Хотя базы данных, в основном, создаются на Microsoft SQL Server, они также могут использоваться в Oracle или даже Microsoft Access. Однако на этих платформах приходится вносить исправления в некоторые запросы SQL, хранимые процедуры и т. д.

Программирование SQL

Взаимодействие с SQL Server осуществляется в основном через Visual Studio, а точнее - через средства работы с базами данных, входящие в Visual InterDev и Visual Basic 6.0. В обоих продуктах предусмотрены возможности построения запросов, управления таблицами и т. д.

Для непосредственной работы с SQL Server можно воспользоваться программой SQL Enterprise Manager. Ее мощные административные средства позволяют управлять сразу несколькими серверами. При помощи SQL Enterprise Manager можно настраивать, запускать, приостанавливать и завершать экземпляры SQL Server, отслеживать текущие операции и просматривать журнал ошибок SQL Server. Вы можете создавать устройства, базы данных и т. д., управлять параметрами системы безопасности, в том числе регистрационными данными пользователей и правами доступа к базам данных. SQL Enterprise Manager и служба SQL Executive позволяют включать режим оповещения о различных серверных событиях, а также планировать выполнение сервером определенных задач. В SQL Enterprise Manager существуют графические средства для настройки и управления процессом репликации, предусмотрены возможности выполнения и анализа запросов, архивации и восстановления баз данных, автоматической генерации сценариев SQL и т. д.

Однако тонкости настройки SQL выходят за рамки данной лекции.

Язык Transact-SQL

Microsoft SQL Server поддерживает язык Transact-SQL, который является надмножеством SQL (Structured Query Language) - стандартного языка для построения запросов к реляционным базам данных. Язык T-SQL имеет сертификат соответствия стандарту ANSI SQL-92, однако при адаптации фрагментов, использующих нестандартные расширения, конечно, возникнут проблемы.

Проектирование базы данных

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

Разделы

На верхнем уровне абстракции товары классифицируются по разделам (departments). Например, ракетки и мячи относятся к разделу "Теннис", а щиты, обручи и сетки - к разделу "Баскетбол". В нашем примере компакт-диски распределяются по разделам в соответствии с музыкальным жанром (например, "Джаз" или "Кантри").

Теоретически можно использовать многоуровневую иерархию разделов, изображенную на рисунке 1. В этом случае создается раздел верхнего уровня (например, "Спортивные товары"), состоящий из нескольких подразделов (таких как "Теннис" и "Баскетбол").

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

Таблица 1- Поля таблицы Department

Поле	Описание
idDepartment	Автоматически увеличиваемый счетчик, содержащий уникальный идентификатор записи в таблице разделов
chrDeptName	Название раздела, отображаемое в приложении
txtDeptDesc	Описание раздела, предназначенное для служебных целей или для внешнего вывода
chrDeptlmage	Ссылка на графическое изображение, представляющее данный раздел

Перейдем к определению товаров.

Товары

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

Структура таблиц базы данных

В нашем примере с Web-сайтом товары (футболки) обладают всего двумя атрибутами - размером и цветом. Впрочем, реляционная структура таблицы позволяет использовать большее количество типов атрибутов. На рисунке 2 изображена структура записи товара в базе данных.

При определении товара используются четыре таблицы: Products - основная информация о товаре.

Attribute - все значения атрибутов (например, красный, зеленый, X, XL). ProductAttribute - связь между товаром и его атрибутами,

AttributeCategory - категория, к которой относится конкретный атрибут (например, размер, цвет или вес).

Следует выделить еще два важных отношения: классификация товаров по разделам и необходимость отражения связей между товарами. Например, красная юбка может быть связана с красной блузкой, которая к ней хорошо подходит. Связи такого типа называются горизонтальными. Возможны и другие, вертикальные связи. Они используются в ситуациях, когда вместо дешевого товара покупателю предлагается другой, более дорогой аналог. На рисунке 3 показаны логические связи основной таблицы товаров Products с таблицами разделов и других товаров. Любой товар может принадлежать нескольким разделам и быть связанным с несколькими товарами.

Таблица Products

Каждый товар принадлежит по крайней мере к одному разделу. В нашем примере допускается, чтобы товар принадлежал к нескольким разделам. Следовательно, понадобится отдельная таблица DepartmentProducts, содержащая информацию о принадлежности товаров к разделам. В другой таблице, RelatedProducts, хранится информация о связях между товарами. Ниже будут приведены команды SQL, которые создают эти таблицы и образуют связи между ними. Поля таблицы Products описаны в таблице 2.

Таблица 2 - Поля таблицы Products

Поле	Описание
ipProduct	Автоматически увеличиваемый счетчик, содержащий уникальный идентификатор записи в таблице товаров
ChrProductName	Название товара, отображаемое в приложении
txtDescription	Описание товара. Информация хранится в текстовом формате, но текст может содержать теги HTML, определяющие его внешний вид
ChrProductlmage	Графическое изображение. Обычно в этом поле содержится имя файла на Web-сервере, в котором находится изображение. Также поле может содержать гиперссылку на файл
intPrice	Цена товара. Чтобы не возникало проблем с округлением, цена хранится в виде целого числа с двумя разрядами в дробной части
dtSaleStart	Начальная дата распродажи товара
dtSaleEnd	Конечная дата распродажи товара
intSalePrice	Цена товара при распродаже
intActive	Признак активности товара

Таблица Attribute

От полей таблицы товаров можно перейти к описанию полей таблицы атрибутов, перечисленных в таблице3.

Таблица 3 - Поля таблицы Attribute

Поле	Описание
idAttribute	Автоматически увеличиваемый счетчик, содержащий уникальный идентификатор записи в таблице атрибутов
cnrAttributeName	Название атрибута, выводимое для покупателя
idAttributeCategory	Ссылка на категорию, к которой относится данный атрибут

Таблица ProductAttribute

Конкретный продукт связывается со списком атрибутов при помощи таблицы ProductAttribute. Поля этой таблицы описаны в таблице 4.

Таблица 4 - Поля таблицы ProductAttribute

Поле	Описание
idProductAttribute	Автоматически увеличиваемый счетчик, содержащий уникальный идентификатор для каждой комбинации
idAttribute	Идентификатор атрибута
idProduct	Идентификатор товара, с которым связан данный атрибут

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

Таблица AttributeCategory

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

Таблица 3.5. Поля таблицы AttributeCategory

Поле	Описание
idAttributeCategory	Автоматически увеличиваемый счетчик, содержащий уникальный идентификатор для каждой категории
chrCategoryName	Название категории

В таблице просто перечисляются категории атрибутов.

ПРИМЕЧАНИЕ:

Чтобы узнать, какими категориями атрибутов обладает тот или иной товар, достаточно построить запрос, который возвращает список категорий на основании набора атрибутов, присвоенных объекту. Из результатов запроса следует исключить возможные повторения.

Классификация товаров по разделам

Как уже говорилось выше, каждый товар должен быть отнесен по крайней мере к одному разделу. Впрочем, структура базы данных должна быть достаточно гибкой, чтобы товары могли принадлежать сразу нескольким разделам. Например, хотя блузка и относится к категории "Блузки", она также может быть частью раздела "Весенняя коллекция". Компакт-диск может одновременно относиться к категориям "Джаз" и "Блюз". Поля таблицы DepartmentProducts описаны в таблице 6.

Таблица 6 - Поля таблицы DepartmentProducts

Поле	Описание
IdDepartmentProduct	Автоматически увеличиваемый счетчик, содержащий уникальный идентификатор для каждой комбинации
IdDepartment	Идентификатор раздела
idProduct	Идентификатор товара, относящегося к данному разделу

Эта таблица, как и AttributeCategory, содержит простой список комбинаций "товар/раздел".

Связывание товаров

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

Таблица 7 - Поля таблицы RelatedProducts

Поле	Описание
IdRelatedProduct	Автоматически увеличиваемый счетчик, содержащий уникальный идентификатор для каждой комбинации
IdProductA	Идентификатор товара
IdProductB	Идентификатор товара, связанного с предыдущим товаром
IdRelationType	Тип связи (горизонтальная или вертикальная)

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

ПРИМЕЧАНИЕ:

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

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

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

Покупатели

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

ПРИМЕЧАНИЕ
Помните: электронные магазины бывают такими же разнообразными и сложными, как и люди. У всех людей есть общие элементы (голова, сердце, тело), но по характеру и природе мы сильно отличаемся друг от друга. Вы должны хорошо понимать, какие требования предъявляются к вашему магазину и как лучше применить шаблон, описанный в книге.

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

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

Таблица с данными покупателя имеет простую структуру. Ее записи в основном состоят из реквизитов, используемых при доставке или выписке счета. Поскольку в каждом заказе присутствует идентификатор покупателя, вы можете установить соответствие между теми товарами, которые он заказывал ранее, и содержимым сайта (персональная настройка). Поля таблицы Shopper перечислены в таблице 8.

ПРИМЕЧАНИЕ:

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

Таблица 8 - Поля таблицы Shopper

Поле	Описание
idShopper	Автоматически увеличиваемый счетчик, содержащий уникальный идентификатор покупателя
chrFirstName	Имя покупателя
chrLastName	Фамилия покупателя
chrAddress	Адрес
chrCity	Город
chrState	Штат
chrProvince	Область
chrCountry	Страна
chrZipCode	Почтовый индекс
chrPhone	Телефон
chrFax	Факс
chrEmail	Адрес электронной почты
dtEntered	Дата ввода информации о покупателе
chrUserName	Имя пользователя. Вводится покупателем при обращениях к профилю, получении информации о состоянии заказов и т. д
chrPassword	Пароль. Вводится покупателем при обращениях к профилю и получении информации о состоянии заказов
intCookie	Флаг проверки имени пользователя и пароля при обращении к профилю. Отказ от проверки позволяет немедленно идентифицировать пользователя, когда он в очередной раз посетит сайт со своего компьютера

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

ПРИМЕЧАНИЕ

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

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

ПРИМЕЧАНИЕ:

В данном примере не учтена возможность международных заказов, поэтому в записи отсутствуют соответствующие адресные поля.

Корзина

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

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

На рис. 3.4 изображена связь таблиц, образующих корзину, с таблицей покупателей Shopper.

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

Таблица 3.9. Поля таблицы Basket

Поле	Описание
idBasket	Автоматически увеличиваемый счетчик, содержащий уникальный идентификатор корзины
intQuantity	Общее количество позиций в корзине
dtCreated	Дата создания корзины
idShopper	Идентификатор покупателя, создавшего корзину
intOrderPlaced	Признак оформления заказа на корзину
intSubTotal	Промежуточный итог без учета налогов, стоимости доставки, обработки заказа и т. д.
intTotal	Общая стоимость заказа с учетом всех дополнительных сборов
intShipping	Стоимость доставки заказа. Вычисляется по действующим нормам
intTax	Налог на заказ. Вычисляется по действующим нормам

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

В каждой корзине присутствует список входящих в нее товаров. Информация из этого списка используется при оформлении заказа. Поля таблицы Basket-Items описаны в табл. 3.10.

Таблица 3.10. Поля таблицы BasketItems

Поле	Описание
idBasketltem	Автоматически увеличиваемый счетчик, содержащий уникальный идентификатор каждой позиции в корзине
idProduct	Идентификатор товара, включенного в корзину
intPrice	Цена товара на момент включения в корзину. В случае распродажи может отличаться от основной цены
chrName	Название товара
intQuantity	Количество заказанных единиц товара
idBasket	Идентификатор корзины, к которой относится данная позиция
chrSize	Значение атрибута "размер"
chrColor	Значение атрибута "цвет"

СОВЕТ
Операции с таблицами, содержащими данные корзин и их отдельных позиций, являются одним из основных аспектов управления базами данных. На Web-сайтах с большим объемом сделок количество корзин может существенно превышать количество размещенных заказов. Необходимо предусмотреть возможность автоматической очистки корзин, существующих дольше заданного периода времени (например, 24 или 48 часов).

Операции с таблицами корзины осуществляются по мере просмотра Web-сайта покупателем. Ниже будут рассмотрены функциональные средства для добавления, обновления и удаления отдельных позиций корзины. А пока мы переходим к рассмотрению заказов, размещаемых на нашем сайте.

Заказы

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

Информация заказа тесно связана с содержимым корзины, а точнее - с товарами, находящимися в этой корзине. На рис. 3.5 показаны связи между таблицей заказа, таблицами корзины и данными покупателя.

В нашем примере заказ связывается с корзиной и покупателем. Каждой корзине и каждому заказу обязательно должен соответствовать некоторый покупатель.

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

Таблица 3.11. Поля таблицы OrderData

Поле	Описание
idOrder	Автоматически увеличиваемый счетчик, содержащий уникальный идентификатор заказа
idShopper	Идентификатор покупателя, разместившего заказ
chrShipFirstName	Имя лица, которому доставляется заказ
chrShipLastName	Фамилия лица, которому доставляется заказ
chrShipAddress	Адрес для доставки заказа
chrShipCity	Город, в который доставляется заказ
chrShipState	Штат, в который доставляется заказ. Может повлиять на величину налога и стоимости доставки
chrShipProvince	Область (для международных заказов)
chrShipCountry	Страна, в которую доставляется заказ
chrShipZipCode	Почтовый индекс для доставки заказа. В некоторых сложных ситуациях может использоваться при вычислении налога
chrShipPhone	Телефон для доставки заказа
chrShipFax	Факс для доставки заказа
chrShipEmail	Адрес электронной почты лица, которому доставляется заказ
chrBillFirstName	Имя лица, на которое выписывается счет
chrBillLastName	Фамилия лица, на которое выписывается счет
chrBillAddress	Адрес для выписки счета
chrBillCity	Город для выписки счета
chrBillState	Штат для выписки счета
chrBillProvince	Область для выписки счета
chrBillCountry	Страна для выписки счета
chrBillZipCode	Почтовый индекс для выписки счета
chrBillPhone	Телефон для выписки счета
chrBillFax	Факс для выписки счета
chrBillEmail	Адрес электронной почты лица, на которое выписывается счет
dtOrdered	Дата размещения заказа

ПРИМЕЧАНИЕ
Как правило, для выписки счета и доставки используется один и тот же адрес. Однако мы сохраняем эти данные дважды на случай их изменения. В интерфейсе приложения следует предусмотреть возможность однократного ввода информации в случае, если выписка счета и доставка осуществляются по одному адресу.

Затем мы должны определить таблицу для хранения платежных реквизитов покупателя. Чтобы упростить процедуру проверки, в таблице сохраняются три основных атрибута кредитной карты: тип карты, ее номер и срок действия. Поля таблицы PaymentData описаны в табл. 3.12.

Таблица 3.12. Поля таблицы PaymentData

Поле	Описание
idPayment	Автоматически увеличиваемый счетчик, содержащий уникальный идентификатор платежа
idOrder	Идентификатор заказа, к которому относится платеж
chrCardType	Тип кредитной карты (Visa, American Express и т. д.)
chrCardNumber	Номер кредитной карты
chrExpDate	Срок действия кредитной карты
chrCardName	Имя владельца кредитной карты

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

Состояние заказа

В данном примере заказ может находиться на одной из трех стадий:

Заказ получен, но еще не исполнен. Заказ находится в процессе исполнения. Заказ находится на последней стадии - в процессе доставки. В информацию состояния включается номер транспортной накладной.

С каждым заказом связывается запись в таблице OrderStatus (см. рис. 3.6). Поля этой таблицы описаны в табл. 3.13.

Таблица 3.13. Поля таблицы OrderStatus

Поле	Описание
idOrderStatus	Автоматически увеличиваемый счетчик, содержащий уникальный идентификатор записи, описывающей состояние заказа
idOrder	Идентификатор заказа
idStage	Стадия обработки заказа
dtShipped	Дата отправки (стадия 3)
dtFulfilled	Дата исполнения заказа со склада (стадия 2)
dtProcessed	Дата начала обработки заказа, полученного из Web (стадия 1)
txtNotes	Произвольные заметки, относящиеся к состоянию заказа. Например, при возникновении каких-либо проблем информация о них заносится в это поле
chrShippingNum	Номер транспортной накладной
intProcessed	Признак обработки заказа для последующего исполнения

Таблица состояния заказа может иметь значительно более сложную структуру. В идеальном варианте информация о состоянии заказа принимается непосредственно от системы обработки заказов.

Стоимость доставки

Существует несколько вариантов вычисления стоимости доставки. Факторы, используемые в расчетах, перечислены в табл. 3.14.

Таблица 3.14. Факторы, используемые при вычислении стоимости доставки

Фактор	Описание
Количество единиц товара	Стоимость доставки вычисляется на основании количества единиц товара, включенных в заказ. Возможные варианты - фиксированная стоимость доставки для одной единицы товара или для интервала. Например, стоимость доставки от 1 до 5 единиц составляет $3, от 6 до 10 единиц - $6 и т. д.
Общая стоимость заказа	Вместо количества единиц товара стоимость доставки вычисляется на основании общей стоимости доставки. Например, при заказе на сумму от $0 до $5 стоимость доставки составляет $1, на сумму от $6 до $10 - $3 и т. д.
Вес	Вес оказывается решающим фактором в ситуациях, когда товары отличаются необычно большим или непостоянным размером. Обычно в вычислениях используется специальная таблица, содержащая информацию о весе единицы товара
Расстояние доставки	Вероятно, сложнее всего стоимость доставки вычисляется на основании расстояния. Вычисление расстояний на основании почтовых индексов - довольно сложная задача. В упрощенной модели задается фиксированная стоимость доставки внутри регионов и стоимость доставки между регионами. Этот способ нередко объединяется с вычислением на основе веса

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

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

Таблица 3.15. Поля таблицы Shipping

Поле	Описание
idQuantityRange	Автоматически увеличиваемый счетчик, содержащий уникальный идентификатор для каждого интервала
idLowQuantity	Нижняя граница количества единиц товара в интервале
idHighQuantity	Верхняя граница количества единиц товара в интервале
intFee	Стоимость доставки в заданном интервале

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

Таблица 3.16. Стоимость доставки

Нижняя граница	Верхняя граница	Стоимость
0	5	$5.00
6	10	$7.50
11	20	$10.00
21	99999	$15.00

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

ПРИМЕЧАНИЕ
Часто существуют специальные условия оплаты для доставки в течение одного или двух дней. Например, если покупатель хочет, чтобы товар был доставлен в течение двух дней, стоимость доставки увеличивается на $5. Чтобы товар был доставлен на следующий день, к стоимости прибавляется $10.

Налог

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

Исходя из этих требований, в таблице Tax (см. табл. 3.17) просто устанавливается прямая связь между штатом и налоговой ставкой.

Таблица 3.17. Поля таблицы Tax

Поле	Описание
idState	Автоматически увеличиваемый счетчик, содержащий уникальный идентификатор для каждого штата
chrState	Сокращенное название штата
intTaxRate	Налоговая ставка для указанного штата

Данные, используемые в наших примерах, приведены в табл. 3.18.

Таблица 3.18. Примеры налоговых ставок

Штат	Налоговая ставка
TX	5% (0.05)
VA	10% (0.10)
DC	25%(0.25)

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

Окончательная структура базы данных

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

В результате объединения всех элементов возникает полная картина данных, необходимых для работы нашего электронного магазина. На следующем этапе мы рассмотрим сценарии SQL, в которых создаются описанные таблицы.