Магазин шоколадных изделий

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

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

 

 

Каталог изделий и список клиентов

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

■ Таблица Products, в которой перечислены соблазнительные шоколадные деликатесы, предлагаемые для продажи. В таблице записаны: название, описание и цена каждого предлагаемого изделия. Имеет смысл включить в нее несколько необязательных подробностей — например, почему бы не учесть текущий запас с помощью двух числовых полей (UnitsInStock (количество единиц на складе) и UnitsOnOrder (количество заказанных единиц)), а также логическое поле (названное Discontinued (больше не продающиеся)) для обозначения изделий, которые больше не поступают в продажу.

 

 

Примечание

Во многих БД нельзя удалять старые данные. Компания вроде Boutique Fudge не может просто исключить старые изделия из своих каталогов, поскольку они могут быть связаны со старыми заказами. Кроме того, есть смысл хранить исторические сведения для возможного анализа данных. (Boutique Fudge могла бы применить запрос для поиска самых хорошо продаваемых товаров в 1999 г. и выяснить, есть ли связь между снижением содержания какао и сокращени­ем продаж.) Именно поэтому вам нужно поле Discontinued. Когда перечисляются изделия для продажи, все больше не поступающие в продажу изделия можно исключить с помощью средств фильтрации, с которыми вы познакомились в разд. "Фильтрация" главы 3.

 

■ Таблица ProductCategories делит изделия на несколько описательных групп. Это позволит клиентам просматривать изделия только в той категории, которая им нужна (будь то напитки (Beverages), конфеты (Candies), шоколад (Chocolate) или сделанная на заказ одежда с надписями, подчеркивающими пристрастие хозяина к шоколаду (Personalized Choco-wear).

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

 

 

Примечание

Многие компании разрешают своим клиентам предоставлять несколько адресов доставки и кредитных карт. Если вы согласитесь на такое разнообразие, вам понадобится (не удивляйтесь)

больше таблиц. Можно создать таблицу CustomerCreditCards. Затем каждую запись из таблицы Customers можно связать с одной или несколькими записями в таблице CustomerCreditCards. BoutiqueFudge выбрала легкий путь и хранит номер кредитной карты клиента и его адрес непосредственно в таблице Customers.

Пока существует одна действующая связь — связь типа "один-ко-многим" между табли­цами ProductCategories и Products. Этот проект показан на рис. 5.21.

 

Рис. 5.21. Товар (например, Chocolate Jasmine Tea (шоколадный жасминовый чай)) можно поместить в одну категорию (скажем, напитки), но в отдельную категорию входит много товаров

Заказ товаров

Как бы искусно не была спроектирована ваша БД о продажах, если клиенты не смогут зака­зывать интересующие их товары, компания Boutique Fudge быстро разорится.

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

■ В таблицу Orders записывается каждый заказ, сделанный клиентом. Она связана с клиентом, сделавшим заказ, и включает информацию, такую как дата размещения заказа.

■ В таблице OrderDetails перечислены отдельные элементы заказа. Каждая запись в таблице OrderDetails включает код (ID) заказанного товара, количество единиц товара в заказе и цену, по которой они заказаны.

Поскольку в среднем заказ содержит несколько видов изделий, отдельная запись в таб­лице Orders обычно связана с несколькими записями таблицы OrderDetails (как показано на рис. 5.22). Это утверждение может показаться нелепым (т. к. оно означает, что вам требу­ется создать группу новых записей для всего лишь одного заказа), но процесс не потребует от вас больших усилий. У программы Access есть два средства, которые выручат: подтаблицы (рис. 5.23) и формы (см. главу 12).

Обратите внимание на то, что запись OrderDetails хранит цену каждого заказанного ви­да товара. Может показаться, что такая система порождает избыточность данных по отношению

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

 

Рис. 5.22. У каждого заказа может быть неограниченное количество заказанных видов товаров. Такая возможность неизменно радует компанию Boutique Fudge

 

Рис. 5.23. Благодаря наличию подтаблицы можно добавлять в одном месте запись о заказе и связанные с ним виды товаров

 

 

Примечание

Профессиональные разработчики БД называют информацию такого сорта сиюминутными или текущими данными (point-in-time data), поскольку они меняются со временем.

Следует отметить, что запись таблицы Order не хранит общую стоимость заказа, т. к. общая стоимость — это просто сумма стоимостей всех заказанных товаров. Если хранить общую стоимость, то возникает возможность появления противоречивых данных — иными словами, у вас появится проблема, если сохраняемая общая стоимость не совпадет со стои­мостью всех товаров, включенных в заказ.

Вам придется еще как следует поработать, прежде чем Boutique Fudge превратится в компанию, которая управляется БД. Например, возможно, придется создать таблицу Ship­ments (доставки), в которой учтены заказы, отправленные по почте, и таблицу Payments (платежи), чтобы быть уверенными в том, что клиенты расплатились полностью. Концепту­ально в этом нет ничего нового, но чем больше таблиц добавляется, тем сложнее становятся БД. Теперь, зная основы отношений и правила создания таблиц хорошей структуры, вы су­меете сохранять хладнокровие в стрессовой ситуации.

Часть II