Курсовая работа (т): Автоматизации работы автобусного парка

Рисунок 3.4

Программные классы_Plist

FIO_driver: String_cond: String

№marsh: Byte: Byte

№Plist: Byte(№marsh, data, №Plist, FIO_driver, FIO_cond)

Journal_Ychet

data: Byte_t №1: Byte_t №2: Byte

№marsh: Byte: Byte

Beginwork_day (data, colvo_t №1, №marsh)_day (data, colvo_t №1, colvo_t №2, sum, №marsh)

Journal_ZP

pribul: Byte: Byte: Byte_account: Byte_driv: Byte_disp: Byte_cond: Byte_ZP (pribul, sumZP)_ZP (zp, zp_account, zp_driv, zp_disp, zp_cond)

Journal_transport register

data: Byte

№marsh: Byte: Byte

timeB: Byte

Begin_marsh (data, №marsh, timeA)_marsh (data, №marsh, timeB)

Journal_sh

№marsh: Byte_sh: Byte: Byte

FIO: String

Shtraff (sum_sh, data, FIO, №marsh)

Journal_Tax

pribul: Byte: Byte: Byte_Tax (pribul, sumTax)_ZP (sumTax, data)

Journal_break

№marsh: Byte: Byte(data, №marsh)_Elect

data: Byte_el: Byte_oplata (data, sum_el)

System

FIO_driver: String_cond: String

№marsh: Byte: Byte

№Plist: Byte_t №1: Byte_t №2: Byte: Byte: Byte: Byte: Byte_account: Byte_driv: Byte_disp: Byte_cond: Byte: Byte: Byte: Byte_sh: Byte: String: Byte: Byte_el: Byte_now: Byte

№marsh_old: Byte

№marsh_new: Byte_pay: Byte_prible: Byte(№marsh, data, №Plist, FIO_driver, FIO_cond), Beginwork_day (data, colvo_t №1, №marsh), Endwork_day (data, colvo_t №1, colvo_t №2, sum, №marsh),_ZP (pribul, sumZP), Pay_ZP (zp, zp_account, zp_driv, zp_disp, zp_cond),_marsh (data, №marsh, timeA), End_marsh (data, №marsh, timeB), Shtraff (sum_sh, data, FIO, №marsh), Podschet_Tax (pribul, sumTax), Pay_ZP (sumTax, data), Polomka (data, №marsh), El_oplata (data, sum_el), Otsyts_tr (FIO_driver, FIO_cond, data, time_now, №marsh), Zamena (№marsh_old, №marsh_new), Pay_break (sum_pay, data), Salary (all_prible, data)

4. Модель данных

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

База данных - это единое, большое хранилище данных, которое однократно определяется, а затем используется одновременно многими пользователями из разных подразделений.

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

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

представление данных и связей между ними, необходимых для всех основных областей применения данного приложения и любых существующих групп его пользователей;

создание модели данных, способной поддерживать выполнение любых требуемых транзакций обработки данных;

разработка предварительного варианта проекта, структура которого позволяет удовлетворить все основные требования, предъявляемые к производительности системы.

При создании базы данных проходят 3 этапа её разработки:

концептуальное моделирование;

логическое моделирование;

физическое моделирование.

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

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

Основными компонентами концептуальной модели являются:

Данные, циркулирующие в данной предметной области;

Описание классов, объектов предметной области и связей между ними;

Описание информационных потребностей пользователей.

Среди методов концептуального моделирования наибольшей популярностью пользуется ER-моделирование. ER-модель представляет собой графическое описание предметной области в терминах «объект-свойство-связь».

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

На рисунке 4.1 представлена диаграмма ER-типа, соответствующая рассмотренной диаграмме ER-экземпляров.

Рисунок 4.1 - Диаграмма ER-типа

Пример концептуальной модели данных предметной области представлен на рисунке 4.2

Рисунок 4.2 - Концептуальная модель предметной области

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

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

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

При даталогическом моделировании необходимо спроектировать структуру таблиц с учетом требований к реляционным моделям в среде СУБД Access.

Обычно исходная реляционная модель формируется из ER-модели путем преобразования классов объектов и процессов в самостоятельные отношения - таблицы.

В результате моделирования может быть получена реляционная модель следующего вида:

КАДРЫ (Табельный номер, Фамилия, Имя, Отчество, Дата Рождения, Образовании)

Должность (Код Должности, Название, Оклад, По Штату)

Зарплата (ТабНомер, Фамилия, Имя, Отчество, Оклад, ДоплСложн, ДоплУдален, НадбКласс, Премия, НазваниеДолжн, Зарплата)

ДоплатаСложность (КодСложн, Название, Надбавка)

ДоплУдаленность (КодВредности, Название, Надбавка)

Архив Удаленных (ТабНомер, Фамилия, Имя, Отчество, Дата Найма)

НадбавкаКласс (КодКласс, Класс, Надбавка)

Претенденты (КодПретед, ФИО, Образование, ДатаРождения, Адрес, На должность)

На следующем этапе реализуется физическая модель в СУБД Access. Создаются таблицы классов объектов с соответствующими типами данных и свойствами полей.

Рисунок 4.3 - Структура таблиц с типами данных

С помощью инструментальных средств в окнах Схема данных и Изменение связей устанавливаются связи между полями.

Рисунок 4.4 - Схема данных

Рисунок 4.5 - Установка связи «один-ко-многим»

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

Рисунок 4.6 - Размер текстового поля «Название»

После создания всех полей и определения их свойств в таблицу можно вводить информацию. Для этого необходимо войти в режим таблицы. Новая таблица Access состоит из одной пустой записи. Чтобы её заполнить, необходимо ввести несколько строк с данными.

После ввода данных пустая запись смещается в конец таблицы.

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

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

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

С помощью клавиш Tab и Enter можно перемещаться по полям слева направо, а посредством клавиш Shift+Tab - в обратном направлении.

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

После активизации любого поля записи в строке состояния появляется комментарий, который введен пользователем в поле Описание при составлении таблицы.

Также загрузка данных на этапе проектирования может производиться с помощью форм.

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

Рисунок 4.7 - Маска ввода для поля Дата Рождения

. Модель реализации

Реализация программного обеспечения - это процесс перевода системной спецификации в работоспособную систему. Итогом реализации приложения является работоспособная информационная система.

Алгоритмы реализации модулей задачи и их реализация (запросы, таблицы, формы, отчеты, макросы, стандартные программы).

Реализация запросов средствами Access 2007:

Запрос, по удержаниям заработной платы (пример выполнения представлен на рисунке 5.1) - определяет именно тех сотрудников, у кого производится удержание заработной платы (Вид>Режим SQL):

Рисунок 5.1 - Пример выполнения запроса по удержаниям заработной платы

Сотрудники.[Табельный №], Сотрудники.ФИО, Сотрудники.Должность, Сотрудники.Подразделение, [Учёт удержаний из зарплаты].[Вид удержания], [Учёт удержаний из зарплаты].[Сумма удержания (в %)][Учёт удержаний из зарплаты] INNER JOIN ((Сотрудники INNER JOIN [Табель учёта рабочего времени] ON Сотрудники.[Табельный №] = [Табель учёта рабочего времени].[Табельный № сотрудника]) INNER JOIN [Расчётно-платёжная ведомость] ON [Табель учёта рабочего времени].[№ табеля] = [Расчётно-платёжная ведомость].[№ табеля]) ON [Учёт удержаний из зарплаты].[Код удержания] = [Расчётно-платёжная ведомость].[Удержание зарплаты]((([Учёт удержаний из зарплаты].[Сумма удержания (в %)])>0))BY [Учёт удержаний из зарплаты].[Сумма удержания (в %)];

Запрос, по стажу работы сотрудников (пример выполнения представлен на рисунке 5.2) - определяет именно тех сотрудников (и их стаж), которые удовлетворяют введённому пользователем значению в диалоговом окне (Вид>Режим SQL):Сотрудники.[Табельный №], Сотрудники.[ФИО], Сотрудники.[Год рождения], Сотрудники.[Количество детей], Сотрудники.[Должность], Сотрудники.[Подразделение], Сотрудники.[Образование], Сотрудники.[Стаж работы]Сотрудники(((Сотрудники.[Стаж работы])=[Введите интересующий вас возраст]))BY Сотрудники.[ФИО];

Рисунок 5.2 - Пример выполнения запроса по стажу работы сотрудников

Запрос для расчётно-платёжной ведомости (пример выполнения представлен на рис. 5.3). Данный запрос выводит полностью всех сотрудников (по запрашиваемому времени с помощью диалогового окна) с указанием всех рабочих часов, тарифных ставок, отпусков, премий, удержаний - и в итоге подсчитывает каждому зарплату - (Вид>Режим SQL). Так же с помощью данного запроса формируются отчёты по зарплате:

Рисунок 5.3 - Пример выполнения запроса для расчётно-платёжной ведомости

Сотрудники.[Табельный №], Сотрудники.ФИО, Сотрудники.Должность, Сотрудники.Подразделение, [Тарифная сетка].[Тарифная ставка (руб)], [Табель учёта рабочего времени].[Дневные часы (часов)], [Табель учёта рабочего времени].[Ночные часы (часов)], [Табель учёта рабочего времени].[Праздничные часы (часов)], [Табель учёта рабочего времени].[Часов по болезни (часов)], [Табель учёта рабочего времени].[Часов по отгулам (часов)], Награждения.[Сумма в %], [Учёт удержаний из зарплаты].[Сумма удержания (в %)], [Расчётно-платёжная ведомость].[Дата начисления], ((((([Табель учёта рабочего времени]![Дневные часы (часов)]*[Тарифная сетка]![Тарифная ставка (руб)])+(([Табель учёта рабочего времени]![Ночные часы (часов)]/10)*[Тарифная сетка]![Тарифная ставка (руб)])+([Табель учёта рабочего времени]![Праздничные часы (часов)]*2*[Тарифная сетка]![Тарифная ставка (руб)])-((([Табель учёта рабочего времени]![Часов по болезни (часов)]*70)/100)*[Тарифная сетка]![Тарифная ставка (руб)]))*[Награждения]![Сумма в %])/100)*[Учёт удержаний из зарплаты]![Сумма удержания (в %)])/100 AS Зарплата[Учёт удержаний из зарплаты] INNER JOIN ([Тарифная сетка] INNER JOIN ((Сотрудники INNER JOIN [Табель учёта рабочего времени] ON Сотрудники.[Табельный №] = [Табель учёта рабочего времени].[Табельный № сотрудника]) INNER JOIN (Награждения INNER JOIN [Расчётно-платёжная ведомость] ON Награждения.[Код премии] = [Расчётно-платёжная ведомость].[Премия сотруднику]) ON [Табель учёта рабочего времени].[№ табеля] = [Расчётно-платёжная ведомость].[№ табеля]) ON [Тарифная сетка].[Номер разряда] = [Расчётно-платёжная ведомость].[Номер разряда]) ON [Учёт удержаний из зарплаты].[Код удержания] = [Расчётно-платёжная ведомость].[Удержание зарплаты](((((((([Табель учёта рабочего времени]![Дневные часы (часов)]*[Тарифная сетка]![Тарифная ставка (руб)])+(([Табель учёта рабочего времени]![Ночные часы (часов)]/10)*[Тарифная сетка]![Тарифная ставка (руб)])+([Табель учёта рабочего времени]![Праздничные часы (часов)]*2*[Тарифная сетка]![Тарифная ставка (руб)])-((([Табель учёта рабочего времени]![Часов по болезни (часов)]*70)/100)*[Тарифная сетка]![Тарифная ставка (руб)]))*[Награждения]![Сумма в %])/100)*[Учёт удержаний из зарплаты]![Сумма удержания (в %)])/100)>0))BY Сотрудники.ФИО;

Далее переходим в главное меню и выбираем пункт «Отчёты» и переходим в соответствующее меню. Нам на выбор предоставляется два отчёта по зарплате (они идентичны, но отличаются группировкой). При выборе пункта «….. с группировкой по сотрудникам» на экран выводятся диалоговые окна с предложением ввести интересующую на дату.

Далее мы сможем вывести отчёт «…… с группировкой по подразделениям»- ход выполнения тот же самый. Таким образом, работа с приложением завершена - из него можно выйти, выбрав в главном меню пункт «Выйти из приложения». Ниже на рисунке 5.4 приведена схема навигации диалога пользователя.

Рисунок 5.4 - Пример схемы навигации диалога пользователя

Заключение

В результате выполнения данного курсового проекта было разработано приложение для автоматизации работы автобусного парка. Данное приложение позволяет значительно упростить работу сотрудников ТК «АБУС-транс» (главным образом бухгалтера) и сэкономить время клиентов данной организации.

Список использованной литературы

1.      Автоматизация управления предприятием / В.В. Баронов, Г.Н. Калянов, Ю.Н. Попов и др. - М.: Инфра-М, 2010.

.        Автоматизированные информационные технологии в экономике / под ред. Г.А. Титоренко - М.: ЮНИТИ, 2011. - 400с.

.        Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. - М.: Финансы и статистика, 2010. - 351с.

.        Гребенюк Е.И., Гребенюк Н.А. Технические средства информатизации. - М.: Издательский центр «Академия», 2014. - 345с.

.        Ильина О.П. Информационные технологии бухгалтерского учета. - СПб.: Питер, 2011. - 688с.

.        Информационные технологии управления: Учебное пособие для ВУЗов под ред. Г.А. Титоренко - М.: ЮНИТИ-ДАНА, 2014. - 439с.

.        Кириллов В.В. Основы проектирования реляционных баз данных. Учебное пособие. - СПб.: ИТМО, 2014. - 90с.

.        Петров В. Н., Избачков Ю.С. Информационные системы 2-е издание.- СПб.: Издательский дом «Питер», 2005.- 656 с.

.        Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем: Учебник; Под. ред. Ю.Ф.Тельнова.- М.: Финансы и статистика, 2012.

.        Устинова Г.М. Информационные системы менеджмента/ Учебное пособие. - СПб: Изд-во «ДиаСофт ЮП», 2010. - 368 с.

.        Уткин В. Б., Балдин К. В. Информационные системы в экономике - М.: Финансы и статистика , 2014. - 335с.

.        Шафрин Ю. Информационные технологии - М.: Издательство: «Бином. Лаборатория знаний», 2012. - 336с.

Приложение

Приложение 1

Спецификация требований к программному обеспечению

Назначение

Эта спецификация требований описывает функциональные и нефункциональные требования для разрабатываемой АИС «Расчёт зарплаты» для ТК «АБУС-транс» г. Пермь. Система предназначена для расчёта заработной платы по временной системе оплаты труда и вывода отчёта в виде расчётного листка. Цель