Домой

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




Скачать 240.17 Kb.
НазваниеЛекция №7 Тема Электронная коммерция
Дата14.04.2013
Размер240.17 Kb.
ТипЛекция
Содержание
Первый учебный вопрос: - Microsoft SQL Server
SQL Server - мощная платформа для построения реляционных баз данных, используемых при построении коммерческих Web-сайтов с больш
Программирование SQL
Язык Transact-SQL
Проектирование базы данных
Разделы На верхнем уровне абстракции товары классифицируются по разделам (departments).
Таблица 1- Поля таблицы Department
Структура таблиц базы данных
Таблица Products
Таблица 2 - Поля таблицы Products
Таблица Attribute
Таблица ProductAttribute
Таблица AttributeCategory
Таблица 3.5. Поля таблицы AttributeCategory
Таблица 6 - Поля таблицы DepartmentProducts
Таблица 7 - Поля таблицы RelatedProducts
Таблица 8 - Поля таблицы Shopper
Таблица 3.9. Поля таблицы Basket
Таблица 3.10. Поля таблицы BasketItems
Таблица 3.11. Поля таблицы OrderData
...
Полное содержание
Подобные работы:

ЛЕКЦИЯ №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.marthastewart.com), Electronics Boutique (www.ebworld.com) и 1-800 Flowers (www.1800flowers.com).


Примечание

Хотя базы данных, в основном, создаются на 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

Тип связи (горизонтальная или вертикальная)

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

ПРИМЕЧАНИЕ:

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

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

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

Покупатели

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

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


Если информация о покупателе накапливается на постоянной основе, у вас появляется много возможностей для персональной настройки 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 до 99 999 единиц. В другой разновидности этого способа используется формула, в которой учитывается количество заказанных единиц свыше 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, в которых создаются описанные таблицы.

Скачать 240.17 Kb.
Поиск по сайту:



База данных защищена авторским правом ©dogend.ru 2014
При копировании материала укажите ссылку
обратиться к администрации
Уроки, справочники, рефераты