Разработка базы данных для автоматизированной информационной системы «Учет оказания услуг в химчистке»

Введение

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

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

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

Чтобы разработать полноценную информационную систему следует создать соответствующую базу данных [1]. Структура базы данных напрямую будет зависеть от задач, которые должна будет выполнять информационная система, и от среды разработки этой системы. Вероятно, было бы предпочтительней разработать базу данных, не зависящую от конкретной СУБД, но все-таки среда разработки накладывает свой отпечаток, заставляя разрабатывать наиболее оптимальную и удобную с точки зрения реализации модель базы данных. В дальнейшем будут указаны конкретные примеры такой зависимости.

1. Описание бизнес-процесса и задачи

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

Пусть требуется разработать информационную систему для автоматизации работы химчистки в части учета заказов. Средством разработки информационной системы выбрана среда программирования MS Vsual FoxPro 9.0 Согласно краткому описанию бизнес-процесса химчистки будущая информационная система должна обладать следующими функциями:

-          регистрация клиентов химчистки;

-          ведение каталога услуг по чистке изделий;

-          оформление заказов на чистку изделий;

-          расчет стоимости чистки изделий;

-          формирование квитанций к заказам;

-          начисление скидки;

-          формирование отчетов по выручке;

-          определение готовых и неготовых заказов;

-          определение выданных заказов;

-          определение заказов на доставку.

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

Одним из отправных пунктов в разработке базы данных для будущей информационной системы может стать проектирование главного документа системы [2]. Очевидно, что таковым станет диалоговое окно (форма), при помощи которого и будет выполняться оформление заказа на чистку изделий. Составляющие этого окна определяются в соответствии с предполагаемыми функциями будущей разработки. На рис. 1 приведен пример такого окна.

Рис. 1. Примерный вид диалоговой формы оформления заказов

2. Определение сущностей и взаимосвязей между ними

Анализ бизнес–процесса позволяет подойти к построению информационной модели химчистки. Перечень информации, которая будет храниться в базе данных, понятен из главной формы системы (рис. 1). На первом этапе уже возможно определить некоторое начальное количество сущностей, которые будут содержать эту информацию в качестве своих атрибутов. Сущности и связи между ними изображается в виде диаграммы, которая представлена на рис. 2.

Рис. 2. Диаграмма «сущность — связь»

В данной диаграмме используются следующие связи:

-          между сущностями «Изделие» и «Заказ» установлена связь «многие-ко-многим», поскольку один вид изделия может быть указан в нескольких заказах, а в одном заказе может быть указано несколько видов изделий;

-          между сущностями «Клиент» и «Заказ» установлена связь «один-ко-многим», поскольку один клиент может быть указан в нескольких заказах, но в одном заказе может быть указан только один клиент;

-          между сущностями «Вид_обработки» и «Заказ» установлена связь «многие-ко-многим», поскольку один вид обработки может быть указан в нескольких заказах для нескольких изделий, а в одном заказе для одного изделия может быть указано несколько видов обработки.

При определении типов связей между сущностями следует обратить внимание на сущность «Вид_обработки». Конечно, по смыслу хочется установить связь этой сущности и сущности «Изделие», но, во-первых, разные изделия могут подвергаться одинаковым видам обработки, и тогда возникает необходимость несколько раз вносить в базу данных один и тот же вид, а это влечет избыточность данных и увеличение используемой памяти; во-вторых, установление связи между сущностями «Вид_обработки» и «Заказ» позволит облегчить реализацию в системе MS Visual FoxPro 9.0.

Итак, на основе диаграммы взаимосвязей между сущностями (рис. 2) будет разработана модель базы данных, доведенная до третьей нормальной формы. Понятие нормализации применимо только к реляционным базам данных, поэтому следует преобразовать исходную модель, так как в реляционной базе данных не должны присутствовать связи «многие-ко-многим». Для этого следует добавить еще одну сущность, получив эквивалентный вариант диаграммы, представленный на рис. 3. Стоит обратить внимание, что в диаграмме присутствовало две связи «многие-ко-многим», но сущность будет добавлена только одна, т. к. обе связи используют одну сущность «Заказ» (это один из плюсов использования связи Заказ-Вид_обработки вместо Изделие-Вид_обработки).

Рис. 3. Эквивалентный вариант диаграммы «сущность-связь»

3. Задание первичных ключей, определение атрибутов сущностей

Для каждой сущности определяются атрибуты, которые будут храниться в базе данных. Результат представлен в таблице 1.

Таблица 1

Атрибуты и первичные ключи сущностей информационной модели

Следует обратить внимание на то, что в сущности «Вид_обработки» присутствует атрибут «коэффициент_обр». Какого его назначение? Дело в том, что цена обработки одного и того же изделия может быть разной в зависимости от того, какой вид чистки к нему применяется (деликатная стирка, выведение пятен, обычная стирка и т. д.). Естественно, нецелесообразно хранить в базе данных полный перечень цен на каждый вид обработки каждого изделия, поэтому можно по каждому изделию хранить некоторую базовую цену, которая будет меняться в зависимости от вида обработки путем ее умножения на коэффициент обработки. Вообще говоря, такой прием помножающих коэффициентов эффективен во многих подобных случаях.

4. Приведение модели базы данных к первой нормальной форме

Отношение находится в первой нормальной форме, если для каждой сущности выполняются условия:

-     должны отсутствовать повторяющиеся записи;

-     должны отсутствовать повторяющиеся атрибуты;

-     каждый атрибут должен быть неделим [3].

Согласно требованиям первой нормальной формы необходимо преобразовать атрибуты «ФИО_клиента» и «адрес_клиента» в сущности «Клиент» так, чтобы получить неделимые атрибуты. Результат преобразования представлен в таблице 2.

Таблица 2

Атрибуты и первичные ключи сущностей в первой нормальной форме

Диаграмма взаимосвязей между атрибутами сущностей в первой нормальной форме представлена на рис. 4.

Рис. 4. Диаграмма взаимосвязей между атрибутами сущностей в первой нормальной форме

5. Приведение модели базы данных ко второй нормальной форме

Отношение находится во второй нормальной форме, если оно удовлетворяет следующим требованиям:

-                   выполняются условия первой нормальной формы;

-                   первичный ключ однозначно определяет запись;

-                   все поля записи функционально полно зависят от первичного ключа [3].

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

Таблица 3

Атрибуты и первичные ключи сущностей во второй нормальной форме

Диаграмма взаимосвязей между атрибутами сущностей во второй нормальной форме представлена на рис. 5.

Рис. 5. Диаграмма взаимосвязей между атрибутами сущностей во второй нормальной форме

6. Приведение модели базы данных к третьей нормальной форме

Условия третьей нормальной формы:

-     должны выполняться условия второй нормальной формы;

-     внутри каждой сущности должны отсутствовать транзитивные зависимости [3].

В сущности «Состав_заказа» атрибут «сумма_за_позицию» зависит от атрибута «кол-во» этой же сущности. Поэтому данный атрибут следует удалить из сущности, создав на соответствующей форме поле, вычисляемое по формуле:

Сумма_за_позицию =цена*коэффициент_обр*кол-во,                                          (1)

где «коэффициент_обр» — поле из сущности «Вид обработки»,

«цена» — поле из сущности «Изделие».

В сущности «Заказ» атрибут «дата_исполнения» зависит от атрибута «дата_составления» этой же сущности. Поэтому данный атрибут следует удалить из сущности, создав на соответствующей форме поле, вычисляемое по формуле:

Дата_исполнения =дата_составления+общ_длительность,                                    (2)

где «общ_длительность» — поле из сущности «Заказ».

В сущности «Заказ» атрибут «сумма_со_скидкой» зависит от атрибута «сумма_заказа» этой же сущности. Поэтому данный атрибут следует удалить из сущности, создав на соответствующей форме поле, вычисляемое по формуле:

скидка = F(сумма_заказа),                                                                                          (3)

где F — правило расчета скидки, оно не описывается в явном виде, поскольку может быть любым и не является принципиально важным в контексте данной статьи.

В сущности «Заказ» атрибут «скидка» зависит от атрибута «сумма_заказа» этой же сущности. Поэтому удалим данный атрибут следует удалить из сущности, создав на соответствующей форме поле, вычисляемое по формуле:

Сумма_со_скидкой =сумма_заказа — скидка,                                                         (4)

где «скидка» — поле из сущности «Заказ».

Результат преобразований приведен в таблице 4.

Таблица 4

Атрибуты и первичные ключи сущностей в третьей нормальной форме

Диаграмма взаимосвязей между атрибутами сущностей в третьей нормальной форме представлена на рис. 5.

Рис. 5. взаимосвязей между атрибутами сущностей в третьей нормальной форме

7. Физическое описание модели базы данных

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

Таблица 5

Таблица «Изделие» (izdelie.dbf)

Имя поля	Тип поля	Размер поля	Содержание
kod_izd	Integer(AutoInc)	4	код_изделия
kod_kat	Integer	4	код_категории
cena	Numeric	10.2	цена_за_обработку
dlit	Numeric	4.1	длительность_обработки
naim	Character	30	наименование

Таблица 6

Таблица «Вид обработки» (vid_obrabot.dbf)

Имя поля	Тип поля	Размер поля	Содержание
kod_vid	Integer(AutoInc)	4	код_вида
vid	Character	30	вид_обработки
koeffic	Numeric	4.2	коэффициент_обработки

Таблица 7

Таблица «Cостав_заказа» (sostav.dbf)

Имя поля	Тип поля	Размер поля	Содержание
kod_zakaz	Integer	4	код_заказа
kod_izd	Integer	4	код_изделия
kod_vid	Integer	4	код_вида_обработки
kol	Integer	4	количество_изделий

Таблица 8

Таблица «Заказ» (zakaz.dbf)

Имя поля	Тип поля	Размер поля	Содержание
кod_zakaz	Integer(AutoInc)	4	код_заказа
kod_kl	Integer	4	код_клиента
data_sost	Date	8	дата_составления
o_dlit	Integer	4	общая_длительность
summa	Numeric	10.2	сумма_заказа
gotov	Logical	1	готовность
vadacha	Logical	1	выдача

Таблица 9

Таблица «Клиент» (klient.dbf)

Имя поля	Тип поля	Размер поля	Содержание
kod_kl	Integer(AutoInc)	4	код_клиента
fam_kl	Character	25	фам_клиента
im_kl	Character	25	имя_клиента
ot_kl	Character	25	отч_клиента
tel_kl	Character	13	тел_клиента
ul_kl	Character	25	улица_клиента
d_kl	Character	3	дом_клиента
k_kl	Character	3	корпус_клиента
kv_kl	Character	3	кварт_клиента

Таблица 10

Таблица «Категория» (kategor.dbf)

Имя поля	Тип поля	Размер поля	Содержание
kod_kat	Integer(AutoInc)	4	код_категории
kategor	Character	50	категория
kol_iz	Integer	4	кол-во_в_категории

Литература:

1.     Хомоненко А., Цыганков В., Мальцев М. Базы данных: Учебник для высших учебных заведений. — М.: КОРОНА-принт, 2011.

2.     Гурвиц Г. А. Разработка реального приложения с использованием Microsoft Visual FoxPro 9: учеб. пособие. — Хабаровск: Изд-во ДВГУПС, 2007.

3.     Клепинин В. Б., Агафонова Т. П. Visual FoxPro 9.0 в подлиннике. — С-Пб.: БХВ-Петербург, 2008.