База данных для автоматизации процесса заказа газовых баллонов (курсовая: программа (база данных Access) и пояснительная записка)


СОДЕРЖАНИЕ

ВВЕДЕНИЕ    3

1. ОБЩАЯ ХАРАКТЕРИСТИКА ЯРАНСКОГО ФИЛИАЛА «КИРОВОБЛГАЗ»    4

1.1. Организационно-правовая форма предприятия    4
1.2. Перечень видов деятельности Филиала    7
1.3. Организационная структура управления    10

2. ПРОЕКТНАЯ ЧАСТЬ    13

2.1. Постановка задачи    13
2.2. Инфологическая модель системы    15
2.3. Даталогическая модель системы    20
2.4. Структура БД системы    22
2.5. Формы    27
2.6. SQL запросы    31
2.7. Отчеты    34

ЗАКЛЮЧЕНИЕ    37

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ    38

 

ВВЕДЕНИЕ

 

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

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

Целью данной работы является разработка информационной системы с использованием СУБД для автоматизации процесса заказа газовых баллонов. Для достижения поставленной цели в работе используется СУБД Microsoft Access 2003. Выбор СУБД обусловлен тем, что программный комплекс Access входит  в пакет Microsoft Office и, таким образом, доступен всем пользователям, у кого установлен этот пакет.

В рамках данной работы были поставлены следующие задачи:

-  рассмотреть бизнес-процесс заказа газовых баллонов населением;

- спроектировать информационную систему для автоматизации процесса заказа газовых баллонов населением;

- реализовать информационную систему в СУБД Microsoft Access.

 

2.2. Инфологическая модель системы

 

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

Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д.

Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: Красный, Синий, Банановый, Белая ночь и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута.

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

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

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

Схема документооборота бизнес-процесса представлена на рис. 2 Бизнес-процесс начинается с заявки от клиента на предоставление ему газа начальнику ГУ(1). Начальник предоставляет ему форму для заполнения(2) и  заключается договор поставки, который подписывает директор(3) и передает обратно начальнику(4). Начальник ГУ подает общий список заказов(5), договора(6) совместно со счетом на предоплату бухгалтерии, который формируется из следующих пунктов: стоимость груза, количество, транспортные услуги, погрузочно-разгрузочные работы(7). Клиенты производят оплату в бухгалтерию(8), на основании чего получает квитанцию об оплате(9). Бухгалтерия оформляет доверенность покупателю на получение газа, на которой ставит подпись и печать директор(10), затем заверяет подписью главный бухгалтер(11) и документ остается у клиента(12).

 

Рис. 2. Схема документооборота бизнес-процесса

 

Общий список заказов направляется диспетчеру по реализации газа(13). Диспетчер формирует накладную на отпуск газа М15 в двух экземплярах, одну из которых направляет клиенту(14), другую на склад(15), совместно с общим списком заказов(16). Кладовщик составляет  ведомость учета производственных запасов и товаров, а также НДС, уплаченного по ценностям(17) и журнал учета движения товаров на складе(18) и посылает заявку на наполнение баллонов наполнителю баллонов(19), который, в свою очередь, выполнив заказ, передает наполненные баллоны на склад(20). Далее кладовщик передает накладную на отпуск материалов на сторону(21) и общий список заказов гаражу(22). Водитель-экспедитор и таксовщик поставляют заказ клиентам. Клиент предоставляет свой экземпляр М15  водителю-экспедитору(23), доставившему заказ, на основании чего устанавливается баллон и забирается пустой. Пустые баллоны доставляют на склад(24) совместно с товарно-транспортной накладной(25). Завскладом предоставляет диспетчеру по реализации газа материальный отчет о реализации сжиженного газа(26). Наполнитель баллонов направляет диспетчеру материальный отчет о движении сжиженного газа(27). Диспетчер направляет в бухгалтерию авансовые отчеты об израсходовании денежных средств на хоз. цели и командировочные расходы совместно с имеющимися отчетами(28,29).

При построении инфологических моделей можно использовать язык ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь). Для построения ER-диаграмм используют различные программные продукты. Мы использовали для построения ER-диаграммы программу Microsoft Visio 10, которая, на наш взгляд, является одной из наиболее простых в использовании. Инфологическая модель БД системы представлена на рис. 3.

На рисунке прямоугольные области означают сущности. В СУБД Microsoft Access этим сущностям будут соответствовать таблицы. PK (primary key) – первичный ключ, FK1, FK2, … , FKN – (foreign key) – внешние ключи. Внешний ключ обеспечивает связь родительской и дочерней таблиц.

Между двумя сущностям, например, А и В возможны четыре вида связей. Первый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

Студент может не "заработать" стипендию, получить обычную или одну из повышенных стипендий.

Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Квартира может пустовать, в ней может жить один или несколько жильцов.

 

Рис. 3. Инфологическая модель

 

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).

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

 

2.3. Даталогическая модель системы

 

Под даталогической понимается модель, отражающая логические взаимосвязи между элементами данных безотносительно их содержания и физической организации. При этом даталогическая модель разрабатывается с учетом конкретной реализации СУБД, также с учетом специфики конкретной предметной области на основе ее инфологической модели. Для конкретной реализации даталогической модели проектируется физическая, oтображающая первую на конкретные программные и аппаратные средства (ОС, внешняя память, работа с данными на физическом уровне и т.д.). Наполненная конкретной информацией физическая модель и составляет собственно БД. Система, обеспечивающая cоответствующее совместное функционирование указанных компонентов и составляет суть конкретной СУБД. Даталогическая модель БД системы представлена на рис. 4.

 

Рис. 4. Даталогическая модель

 

Здесь:

С – счетчик

Ч – число

Т – текст

Д – дата

Ден. – денежный тип

Л – логический тип

 

Входные и результатные данные системы представлены на рис. 5.

 

Рис. 5. Входные и результатные данные системы

 

В системе необходимо создать 4 математические модели:

1) Математическая модель №1 по расчету стоимости конкретного заказа, учитывая дополнительные услуги (рассчитывается по номеру заказа):

М.М.1 = Цена товара (за единицу) * Количество (единиц) + Доставка + Установка + Замена

2) Математическая модель №2 по расчету стоимости всех заказов для одного клиента, учитывая дополнительные услуги (рассчитывается по номеру клиента):

М.М.2 =   (Цена товара (за единицу) * Количество (единиц) + Доставка + Установка + Замена)

Где i –номер заказа, N – число заказов

 

3) Математическая модель №3 по расчету стоимости всех заказов для всех клиентов, учитывая дополнительные услуги:

М.М.3 =   (Цена товара (за единицу) * Количество (единиц) + Доставка + Установка + Замена)

Где i – номер заказа, N – число заказов,

j – номер клиента, M – число клиентов.

4) Математическая модель №4 по расчету всех оплаченных заказов всеми клиентами:

М.М.4. = (Цена товара (за единицу) * Количество (единиц) + Доставка + Установка + Замена)

 

2.4. Структура БД системы

 

Таблицы – это основные объекты любой базы данных. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят и структуру базы (поля, их типы и свойства). В данной БД мы используем 9 таблиц (рис. 6).  Эти таблицы связаны между собой средствами поддержания целостности, заданными на физическом уровне, то есть на уровне структуры БД.

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

 

База данных для автоматизации процесса заказа газовых баллонов

Рис. 6. Структура БД системы

 

Рассмотрим основные таблицы. На рис. 7 изображена  структура таблицы Клиенты.

1) Поле Код_клиента – это поле первичного ключа таблицы автоинкрементального типа (то есть счетчик).

2) Поле ФИО_Название – текстовое поле с ФИО или Названием организации клиента.

3) Поле Телефон – телефон клиента.

4) Поле Адрес – адрес клиента.

5) Поле Орг_Чл – организация или частное лицо.

 

Рис. 6. Структура таблицы Клиенты

 

На рис. 7 изображена структура таблицы НаселенныеПункты.

1) Поле Код_пункта – поле первичного ключа данной таблицы автоинкрементального типа.

2) Поле Название – Название пункта.

3) Поле Доставки – стоимость доставки. Если клиент осуществляет доставку сам, нужно указывать код пункта - 11.

 

Рис. 7. НаселенныеПункты

 

На рис. 8 изображена структура таблицы Товары.

1) Поле Код_товара – поле первичного ключа типа счетчик.

2) Поле Наименование – название товара.

3) Поле единица – единица измерения

4) Поле Цена – цена 1 единицы товара. Тип поля – денежный.

 

Рис. 8. Структура таблицы Товары

 

На рис. 9 изображена структура таблицы УстановкаЗамена.

1) Поле Код_установки_замены – поле первичного ключа типа счетчик.

2) Поле Установить – установить баллон (да/нет).

3) Поле Заменить – заменить старый баллон (да/нет).

4) Поле Стоимость – стоимость услуг. Тип поля – денежный.

 

Рис. 9. Структура таблицы УстановкаЗамена.

 

На рис. 10 изображена структура таблицы Заказы.

1) Поле Номер_заказа – поле первичного ключа числового типа.

2) Поле Дата – дата заказа.

3) Поле Код_клиента – внешний ключ к таблице Клиенты.

4) Поле Код_товара - внешний ключ к таблице Товары

5) Поле Количество – количество товара (в единицах).

6) Поле Код_пункта – внешний ключ к таблице НаселенныеПункты.

7) Поле Код_установки_замены – внешний ключ к таблице УстановкаЗамена.

8)  Поле Задержка – задержка (измеряется в днях).

 

Рис. 10. Структура таблицы Заказы

 

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

1) Поле Счет_фактура – поле первичного ключа числового типа.

2) Поле Номер_заказа – внешний ключ к таблице Заказы.

3) Поле Итого – итого к оплате (товар + доп. услуги).

4) Поле Оплачен – оплачен заказ (да/нет)

5) Поле Дата – дата оплаты

 

Рис. 11. Структура таблицы Оплата

2.5. Формы

 

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

Рассмотрим основные формы системы. На рис. 12 представлена форма для расчета итоговой суммы к оплате по заказам.

 

Рис. 12. Форма для расчета итоговой суммы к оплате по заказам

 

В поле Номер заказа нужно ввести номер заказа, в поле Счет фактура – задать номер счета фактуры, а также отметить переключатель Оплачен, если счет уже оплачен. Далее следует нажать кнопку Провести (выставить) счет к оплате. Обработчик нажатия кнопки написан на языке  Visual basic, который встроен в СУДБ Access и предназначен для программирования интерфейса. Рассмотрим листинг процедуры обработки нажатия кнопки:

Private Sub Кнопка0_Click()

Dim SQL As String

Dim Zakaz As String

Dim SchetFaktura As String

Dim Data As String

Dim Flag As String

Поле1.SetFocus

Zakaz = Поле1.Text

Поле2.SetFocus

SchetFaktura = Поле2.Text

Data = Str(Date)

If (Переключатель.Value = True) Then Flag = Str(True) Else Flag = Str(False)

SQL = "INSERT INTO Оплата (Счет_фактура, Номер_заказа, Итого, Оплачен, Дата) SELECT " + SchetFaktura + "," + Zakaz + ", (Заказы.Количество * Товары.Цена + НаселенныеПункты.Доставка + УстановкаЗамена.Стоимость) AS Итого," + Flag + "," + "'" + Data + "'" + " FROM ((Заказы INNER JOIN Товары ON Заказы.Код_товара=Товары.Код_товара) INNER JOIN НаселенныеПункты ON Заказы.Код_пункта=НаселенныеПункты.Код_пункта) INNER JOIN УстановкаЗамена ON Заказы.Код_установки_замены=УстановкаЗамена.Код_установки_замены WHERE (((Заказы.Номер_заказа)=" + Zakaz + ") And ((Заказы.Код_товара)=Товары.Код_товара) And ((Заказы.Код_пункта)=НаселенныеПункты.Код_пункта) And ((Заказы.Код_установки_замены)=УстановкаЗамена.Код_установки_замены))"

DoCmd.RunSQL SQL

End Sub

 

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

После нажатия кнопки, если поля заполнены корректно, СУБД выдает сообщение (рис. 13).

 

Рис. 13. Сообщение СУБД о добавлении записи

 

Таким образом, в таблицу Оплата была добавлена новая запись (рис. 14)

 

Рис. 14. Добавление записи в таблицу Оплата

 

В поле дата проставляется текущая дата формирования (оплаты) счета.

 

Для добавления клиентов используется форма Добавить клиента (рис. 15). В этой форме также имеется кнопка и процедура обработки нажатия на нее:

Private Sub Кнопка10_Click()

Dim SQL As String

Dim S1 As String

Dim S2 As String

Dim S3 As String

Dim S4 As String

Поле1.SetFocus

S1 = Поле1.Text

Поле2.SetFocus

S2 = Поле2.Text

Поле3.SetFocus

S3 = Поле3.Text

Поле4.SetFocus

S4 = Поле4.Text

SQL = "INSERT INTO Клиенты (ФИО_Название, Телефон, Адрес, Орг_Чл) VALUES ('" + S1 + "','" + S2 + "','" + S3 + "','" + S4 + "')"

DoCmd.RunSQL SQL

End Sub

 

Рис. 15. Добавление записи в таблицу Клиенты

 

Здесь также использует оператор INSERT для добавления новой записи в таблицу программным способом.

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

Для навигации используются встроенные средства Microsoft Access 2003 – кнопки в низу формы. Также с помощью этой формы можно добавить новую запись в  таблицу  - кнопка со звездочкой предназначена для открытия нового бланка для заполнения. Подобные формы предусмотрены для всех таблиц БД.

 

Рис. 16. Форма для  просмотра и редактирования записей таблицы Товары

2.6. SQL запросы

 

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

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

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

Математическая модель №2 по расчету стоимости всех заказов для одного клиента реализуется с помощью запроса Все заказы клиента:

SELECT SUM(Заказы.Количество*Товары.Цена+НаселенныеПункты.Доставка+УстановкаЗамена.Стоимость) AS Стоимость_всех_заказов

FROM (((Заказы INNER JOIN Товары ON Заказы.Код_товара=Товары.Код_товара) INNER JOIN НаселенныеПункты ON Заказы.Код_пункта=НаселенныеПункты.Код_пункта) INNER JOIN УстановкаЗамена ON Заказы.Код_установки_замены=УстановкаЗамена.Код_установки_замены) INNER JOIN Клиенты ON Заказы.Код_клиента=Клиенты.Код_Клиента

WHERE (((Заказы.Код_клиента)=2) And ((Заказы.Код_товара)=Товары.Код_товара) And ((Заказы.Код_пункта)=НаселенныеПункты.Код_пункта) And ((Заказы.Код_установки_замены)=УстановкаЗамена.Код_установки_замены));

 

В запросе указывается код клиента, для которого рассчитывается стоимость всех его заказов (в данном запросе – код клиента 2). Результат выполнения запроса  представлен на рис. 17.

 

Рис. 17. Результат выполнения запроса Все заказы клиента

 

Математическая модель №3 по расчету стоимости всех заказов для всех клиентов  реализуется с помощью запроса Все заказы всех клиентов:

SELECT SUM(Заказы.Количество*Товары.Цена+НаселенныеПункты.Доставка+УстановкаЗамена.Стоимость) AS Стоимость_всех_заказов_всех_клиентов

FROM (((Заказы INNER JOIN Товары ON Заказы.Код_товара=Товары.Код_товара) INNER JOIN НаселенныеПункты ON Заказы.Код_пункта=НаселенныеПункты.Код_пункта) INNER JOIN УстановкаЗамена ON Заказы.Код_установки_замены=УстановкаЗамена.Код_установки_замены) INNER JOIN Клиенты ON Заказы.Код_клиента=Клиенты.Код_Клиента

WHERE (((Заказы.Код_товара)=Товары.Код_товара) And ((Заказы.Код_пункта)=НаселенныеПункты.Код_пункта) And ((Заказы.Код_установки_замены)=УстановкаЗамена.Код_установки_замены));

Результат выполнения запроса представлен на рис. 18.

 

Рис. 18. Результат выполнения запроса Все заказы всех клиентов

 

Математическая модель №4 по расчету всех оплаченных заказов всеми клиентами реализуется с помощью запроса Всего оплачено:

SELECT SUM(Оплата.Итого) AS Всего_оплачено

FROM Оплата

WHERE Оплата.Оплачен=True;

Результат выполнения запроса Всего оплачено представлен на рис. 19.

 

Рис. 19. Результат выполнения запроса Всего оплачено

 

Также в системе имеются другие запросы:

  1. Заказы клиентов по городам
  2. Стоимость доставки по населенным пунктам
  3. Конечная дата оплаты

 

Заказать курсовую

 

Добавить комментарий


Защитный код
Обновить