Проектирование приложений пользователя в среде СУБД ACCESS
CАНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ
ПОЛИТЕХНИЧЕСКИЙ
УНИВЕРСИТЕТ
Кафедра
«Стратегический менеджмент»
Курсовой
проект
Дисциплина:
Информационные технологии
управления
Тема:
«Проектирование приложений
пользователя в среде
СУБД ACCESS»
Выполнила: студентка гр. З 4075/26
Добрина Р.А.
Мерзлякова Е.В.
Проверил
преподаватель: Пашкина Н.Л.
Санкт-Петербург
2011г.
Оглавление
Концептуальное проектирование
1.1. Цель проекта.
Целью создания автоматизированной системы управления некоторым процессом является:
в первую очередь, возможность использования CУБД работниками компании для осуществления более быстрой работы, точность выданных данных была достоверной и возможность выбора, при составлении СУБД, какие именно задачи необходимо выполнять данной программе для удобства работников.
Структурирование информации в «отделе труда и зарплаты» для универсального использования её в различных задачах;
- осуществление быстрого поиска оперативной информации;
- получение
данных за любой заданный
- получение документов в соответствии с установленным стандартом;
- быстрое обслуживание клиентов;
- предоставление исчерпывающей отчётной документации;
- вычисление
промежуточных и итоговых
- защита информации от случайных лиц;
- контроль достоверности данных;
- надёжное хранение данных;
и
т.д.
1.2.Описание предметной области. Постановка задачи. Функции решаемой задачи. Используемые в задаче документы.
Предметной областью является «отдел по расчету труда и зарплаты».
Для того чтобы можно было вести полный учет о сотрудниках необходимо:
- Знать общий стаж сотрудника
- В какой день, какой сотрудник работал или отсутствовал (по какой причине он не пришел на работу)
- Оклады сотрудников
- Личные данные сотрудников и т.д.
-
Расчет зарплаты и больничного
В данном проекте рассматривается задача «Расчет зарплаты и больничного».
Предпологается, что бухгалтер начисляет зарпату и больничные сотрудникам оталкиваясь от данных самих сотрудников: сколько человек проработа в данном месяце, сколько проболел, сколько дней прогулял, сколько часов переработал и т.д.
Функции проектируемой задачи:
- расчет денежных выплат;
- ввод данных их редоктирование;
-
введение количества
-
поиск отработанных дней по
месяцу или по фамилии, также
зависимость от стажа
-
вывод сумма выплаты за месяц
сотруднику.
2 Логическое проектирование
2.1. Разработка информационного обеспечения задачи
Результатом логического проектирования информационного обеспечения задачи должна быть ИЛМ БД .
2.1.1. Анализ документов
Рассмотрим информацию, содержащуюся в документах, относящихся к данной задаче. Её можно разделить на две группы: условно-постоянную (о кол-ве сотрудников, о положенных днях работы за месяц, формула по которой, расчитывается месячная выплата) и оперативно-учётную (сколько на самом деле сотрудник отработал, сколько дней проболел и т.д.)
Для описания сотрудников (личные карточки) используются атрибуты, соответствующие его свойствам :
-Табельный номер
(первичный ключ), который является
уникальным для каждого
- ФИО
- Дата_рождения
- Дата_приема
- Стаж_общий
- Оклад
- Мин_сред_зараб_в_день
Норма часов по месяцам:
| Норма | |
| Месяц | Норма |
| Янаврь | 128 |
| Февраль | 128 |
| Март | 136 |
| Апрель | 160 |
| Май | 168 |
| Июнь | 176 |
| Июль | 168 |
| Август | 184 |
| Сентябрь | 176 |
| Октябрь | 168 |
| Ноябрь | 176 |
| Декабрь | 176 |
Признаки:
| Признак | |
| Код_признака | Признак |
| 1 | Прогул |
| 2 | Больничный |
| 3 | Отпуск |
| 4 | Командировка |
| 5 | Работал |
| 6 | Уволен |
Оклад сотрудников.
- Табельный номер
- ФИО
-
Оклад
Оперативно-учётная информация находится в табеле:
-код сотрудника (табель)
- текущая дата
- количество часов отработанных в этот день
- признак(работал
сотрудник, болел, в отпуске,
в командировке и т.д.)
Расчетные ведомасти:
- Табельный номер;
- ФИО;
- Отработанные часы;
- Норма часов;
- Оклад;
- Начислено;
- НДФЛ;
- Итого начислено
Больничные листы:
- Табельный номер;
- ФИО;
- Посчитанное выражение;
-Сумма больничного;
- Сумма больничного
от стажа сотрудника;
Анализ реквизитного состава документов позволяет произвести формализацию данных, которая имеет целью их однозначное определение для хранения, поиска и обработки на компьютере.
Для
реализации проекта будет использоваться
реляционная СУБД, поэтому должна
быть разработана логическая структура
реляционной БД , на основе которой
будут выполняться функции
Используем процессный подход к разработке БД, определяя состав только тех данных, которые необходимы для получения выходных документов (расчетная ведомасть и больничный лист).
Рассмотрим информацию, которая содержится в расчетной ведомасти: Т
табельный номер, ФИО, Отработанные часы, Норма часов, Оклад, Начислено, Начислено, НДФЛ, Итого начислено.
Каждая расчетная ведомасть относится к одному сотруднику.т.к у каждого сотрудника может быть разное количество отработанных часов, так же у всех работников разный оклад. Ключом в расчетной ведомасти выбран табеьный номер в данном случае это самый логичный выбор, что позволяет нам быстро искать информацию о работнике.
Рассмотрим информацию, которая содержится больничном листе: Табельный номер, ФИО, Посчитанное выражение, Сумма больничного, Сумма больничного от стажа сотрудника.
Информация, которая содержится в больничном листе так же уникаьна т.к. начисление суммы больничного зависит от стажа сотрудника, а куждого работника он уникаьный, поэтому расчет введеться по каждому отдельно.
Ключом также выбран табельный номер, что позволяет нам с легкостю найти информацию о любом сотруднике.
На основе проведённого анализа установим функциональные зависимости реквизитов документа «расчетная ведомасть» («больничный лист») и документа отобразим их в нижерасположенных таблицах 1, 2.
В этих таблицах слева перечислены наименования реквизитов документа, а справа графически показаны функциональные зависимости не ключевых реквизитов (на них указывают стрелки) от ключевого реквизита (на него указывает линия без стрелки).
Требование
нормализации таблиц для реляционных
моделей проще удовлетворить, если построить
функциональные зависимости реквизитов
и таким образом избавиться от повторяющейся
группы (товары и их количественные показатели),
относящейся к одному документу. Повторяющаяся
группа зависит от номера документа, и
будет описываться отдельным объектом
(содержание документа), связанным с объектом
документ.
| Таблица 1.
Функциональные зависимости реквизитов документа больничный лист. | |
| Наименование реквизита | Функциональные зависимости |
| Табельный номер | |
| Дата_по_мес | |
| Признак | |
| Номер_мес | |
| Табельный номер | |
| ФИО | |
| Дата_рождения | |
| Дата_приема | |
| Стаж_общий | |
| Оклад | |
| Мин_ср_вып_в_мес | |
| Код_признака | |
| Признак | |
| Таблица 2.
Функциональные зависимости реквизитов документа «Расчетная ведомость» | |
| Наименование реквизита | Функциональные зависимости |
| Табельный номер | |
| Дата_по_мес | |
| Признак | |
| Номер_мес | |
| Часы | |
| Норма | |
| Табельный номер | |
| ФИО | |
| Дата_рождения | |
| Дата_приема | |
| Стаж_общий | |
| Оклад | |
| Мин_ср_вып_в_мес | |
| Код_признака | |
| признак | |
| Код_табеля | |
| Табельный номер | |
| Дата | |
| К-во_часов | |
| Признак | |
| Код месяца | |
| Месяц | |
| Норма | |
В теории моделирования
2.1.2. Выделение информационных объектов
Функциональные
зависимости, выявленные при анализе
документов, позволяют выделить объекты
рассматриваемой предметной области
и описать их реквизиты (имя, тип, признак
ключа). Для признака ключа используются
следующие сокращения: П – простой; У –
уникальный (первичный); С – составной
(состоит из двух или нескольких реквизитов),
В – вторичный (используется для связи
с главной таблицей). Для описания объекта
будем использовать названия реквизитов
документа, добавляя, при необходимости,
имя объекта. Не будем употреблять пробел
между словами в имени реквизита. Описание
объектов приведено в таблице 3.
| Имя реквизита | Признак ключа | Тип данных | Название объекта |
| Код_месяца | П,У | Счетчик | Норма |
| Месяц | Текстовый | ||
| Норма | Текстовый | ||
| Код_признака | П,У | Счетчик | Признак |
| Признак | Текстовый | ||
| Табельный_номер | П,У | Счетчик | Сотрудники |
| ФИО | Текстовый | ||
| Дата_рождения | Дата/время | ||
| Дата_приема | Дата/время | ||
| Стаж_общий | Дата/время | ||
| Оклад | Денежный | ||
| Мин_сред_зараб_в_день | Денежный | ||
| Код_табеля | П,У | Счетчик | Табель |
| Табельный_номер | Числовой | ||
| Дата | Дата/время | ||
| Количество_часов | Числовой | ||
| Признак | Числовой |
2.1.3. Определение связей и построение ИЛМ
Связи между выявленными
информационными объектами определяются
реальными отношениями между
парами объектов, показанными в таблице
3. При их определении учитывались
сведения из описания предметной области.
| Ключ связи | Главный объект | Подчинённый объект | Тип отношения |
| 1 | 2 | 3 | 4 |
| Табельный номер | Сотрудники | Табель | 1:М |
| Признак | Табель | Признак | 1:М |
| ------ | Норма | ------ | ------ |
Таблица «Норма» используется в запросах для справочной информации.
Графическое
изображение ИЛМ в канонической
форме наглядно показывает уровни подчинённости
объектов друг другу на рисунке 2.
Соуаровыармвыомпавпявапвар
Рис 2. Каноническая форма ИЛМ.
3.1.4. Определение логической структуры реляционной базы данных
Логическая структура реляционной базы данных определяется совокупностью логически взаимосвязанных нормализованных таблиц. Каждая реляционная таблица имеет структуру, определённую реквизитным составом информационного объекта, который входит в состав ИЛМ. Логические связи таблиц соответствуют связям между объектами. Логическая структура БД, строится на основе ИЛМ. Визуально логическая структура должна совпадать со схемой данных, построенной при реализации проекта, на основе разработанной ИЛМ. Логическая структура БД должна показывать структуру каждого объекта предметной области и связи, построенные с помощью ключевых атрибутов объектов.
В
рассматриваемом примере
И
понятно, что у табеля сотрудника
может быть несколько признаков: отпуск,
больничный, прогул и т.д. это значит что
табл. «Признак» связана с табл. «Табель»
связью 1:М.
3.2.1.
Разработка технологии
ввода и накопления
входной информации
Требования к данным контрольного примера – их представительность, учитывающая особенности информации, указанные в описании предметной области. Такие данные должны обеспечить отладку алгоритма на компьютере и подтвердить работоспособность реализации алгоритма. В данных контрольного примера для рассматриваемой задачи должно быть предусмотрено, что в разные месяца разная норма рабочих часов. Это напрямую зависит на расчет зарплатной ведомости, сумма может колебаться.
3.2. Разработка алгоритмов и технологии решения задачи
Для расчета зарплатной ведомости необходимо знать сколько часов отработал данный сотрудник, полученная цифра сопоставляется с нормой часов за месяц, далее выполнятся сам расчет.
Также для выхода на итоговую сумму за месяц, необходимо учесть больничные, отпуска и т.д. в зависимости от признака, который мог бы быть у сотрудника за месяц работы.
Для расчета больничного нужно знать общий стаж сотрудника, т.к.
У каждого сотрудника больничный может рассчитываться по разному, это на прямую зависит от количества отработанных лет.
Таким образом, должно быть предусмотрено:
-
Введение признака каждого
- Хранение журнала, в котором находится личная информация о сотрудниках.
- Оклад сотрудников
-
Табельные номера, дабы облегчить
поиск информации о
Поиск информации должен осуществляться по значению реквизита, которое должно вводиться в окно, предоставляемое для этой цели. Для каждого вида поиска разрабатывается соответствующий запрос. Для вывода документов должны быть разработаны соответствующие отчёты.
3.2.1. Разработка технологии ввода и накопления входной информации
В поставленной задаче должны вводиться и накапливаться данные о сотрудниках стаж, оклад, признаки по дням, табельные номера и т.д.
Данные о сотрудниках храняться в табл. «Сотрудники», далее по мере решения задачи текущая информация заносится в табл. «Табель», в которой можно отследить информацию по дням. Далее полученная информация заноситься в форму «Больничный лист», если признак какого-то сотрудника требует нас это сделать, и рассчитывается уже сама сумма больничного.
Если признаки сотрудников позволяют нам не заполнять форму «Больничный лист», то мы переходим к заполнению формы «Расчетные ведомости», где подводит итоги суммы за месяц.
3.2.2. Разработка форм ввода
Главная форма,
готовая к испльзованю:
Форма
«Больничный лист»
Форма
«Расчетные ведомости»
3.2.3. Разработка запросов и отчётов для обработки и отображения информации
- Запрос «Для_больн_по _признаку» включает данные из таблиц:
- Табель (Табельный номер, Дата, Признак)
- Сотрудники (ФИО)
- Месяц: Format([Дата];"mm") (группировка)
-Год:
Format([Дата];"yyyy") (группировка)
- Запрос «Работающ_на_дату»
-Сотрудники (ФИО, Табельный номер)
-
Табель (Признак, Дата)
- Запрос «Стаж_работы»
-Сотрудники (ФИО, Табельный номер)
-
Выражение1: (Date()-Сотрудники!Стаж_общий)
- Запрос «Табель»
- Табель (Код табеля, Табельный номер, Дата, Кол-во часов, Признак)
- НомерМесяца:
Format([Дата];"mm")
- Запрос «Табель месяца»
- Запрос «Табель» (Табельный номер, Дата по месяцам: Format$([Табель Запрос].Дата;'mmmm\ yyyy'), Признак, Номер месяца, Кол-во часов(sum)) (группировка).
- Норма (Норма (группировка))
-Year([Табель
Запрос].Дата)*12+DatePart('m';
- Запрос «ТабельМесЗапрос»
-Запрос
«Табель месяца» (Табельный
- Запрос «Больничный по стажу»
- Запрос
«Стаж работы» (Табельный
- Запрос
«Больничный» (Часы: Sum-Количество_часов,
"Больничный_от_стажа": IIf(Стаж_работы!Выражение1>=8;
- Запрос «Больничный»
- Запрос «Для_больн_по _признаку» (Табельный номер, ФИО, Count-Дата, Месяц, Год,
-Сумма_больничного:Для_больн_
- Запрос «Зарплата»
- Запрос
«ТабельМесЗапрос» (Табельный
- Сотрудники (ФИО)
- Начислено:
Сотрудники!Оклад/[Норма]*[
- НДФЛ:
(Сотрудники!Оклад/[Норма]*[
- Итого_начислено
- Запрос «Зарплата для больничного»
- Запрос
«Табель месяца» (Табельный_
-Табл. «Сотрудники» (ФИО, Оклад)
- Начислено:
Сотрудники!Оклад/ТабельМес!
- НДФЛ:
(Сотрудники!Оклад/ТабельМес!
-Итого_начислено:
Сотрудники!Оклад/ТабельМес!