Проектирование приложений пользователя в среде СУБД 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:М, т.е. у одного сотрудника много табелей.

    И понятно,  что у табеля сотрудника может быть несколько признаков: отпуск, больничный, прогул и т.д. это значит что табл. «Признак» связана с табл. «Табель» связью 1:М. 
 

3.2.1. Разработка технологии  ввода и накопления  входной информации 

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

    3.2. Разработка алгоритмов  и технологии решения  задачи

 

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

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

     Для расчета больничного нужно знать общий стаж сотрудника, т.к.

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

    Таким образом, должно быть предусмотрено:

    - Введение признака каждого сотрудника по дням.

    - Хранение журнала, в котором  находится личная информация  о сотрудниках.

    - Оклад сотрудников

    - Табельные номера, дабы облегчить  поиск информации о сотрудниках.

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

    3.2.1. Разработка технологии  ввода и накопления  входной информации

 

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

Данные о сотрудниках  храняться в табл. «Сотрудники»,  далее по мере решения задачи текущая  информация заносится в табл. «Табель», в которой можно отследить информацию по дням.  Далее   полученная информация заноситься в форму «Больничный лист», если признак какого-то сотрудника  требует нас это сделать, и рассчитывается уже сама сумма больничного.

     Если  признаки сотрудников позволяют  нам не заполнять форму «Больничный лист», то мы переходим к заполнению формы «Расчетные ведомости», где подводит итоги суммы за месяц.

    3.2.2. Разработка форм  ввода

 

Главная форма, готовая к испльзованю:  

 
 

     Форма «Больничный лист» 

     

 
 
 

    Форма «Расчетные ведомости» 

      

    3.2.3. Разработка запросов  и отчётов для  обработки и отображения  информации

 
  1. Запрос  «Для_больн_по _признаку» включает данные из таблиц:
 

    - Табель (Табельный номер, Дата, Признак)

    - Сотрудники (ФИО) 

    - Месяц: Format([Дата];"mm") (группировка)

    -Год: Format([Дата];"yyyy") (группировка) 

  1. Запрос  «Работающ_на_дату»
 

    -Сотрудники (ФИО, Табельный номер)

    - Табель (Признак, Дата) 

  1. Запрос  «Стаж_работы»
 

    -Сотрудники (ФИО, Табельный номер)

    - Выражение1: (Date()-Сотрудники!Стаж_общий)/365 

  1. Запрос  «Табель»
 

    - Табель (Код табеля, Табельный номер, Дата, Кол-во часов, Признак)

    - НомерМесяца: Format([Дата];"mm") 

  1. Запрос  «Табель месяца»
 

    - Запрос  «Табель» (Табельный номер, Дата по месяцам: Format$([Табель Запрос].Дата;'mmmm\ yyyy'), Признак, Номер месяца, Кол-во часов(sum)) (группировка).

    - Норма  (Норма (группировка))

    -Year([Табель Запрос].Дата)*12+DatePart('m';[Табель Запрос].Дата)-1 (группировка) 

  1. Запрос  «ТабельМесЗапрос»
 

    -Запрос  «Табель месяца» (Табельный номер,  Дата по месяцам, Признак, НомерМесяца,  Часы: Sum-Количество_часов, Норма) 

  1. Запрос  «Больничный по стажу»

     

    - Запрос  «Стаж работы» (Табельный номер,  ФИО, Выражение1,)

    - Запрос  «Больничный» (Часы: Sum-Количество_часов, "Больничный_от_стажа": IIf(Стаж_работы!Выражение1>=8;Больничный!Сумма_больничного*1;IIf(Стаж_работы!Выражение1<8 And Стаж_работы!Выражение1>5;Больничный!Сумма_больничного*0,8;IIf(Стаж_работы!Выражение1<5;Больничный!Сумма_больничного*0,6;Больничный!Сумма_больничного*0)))) 

  1. Запрос  «Больничный»
 

    - Запрос  «Для_больн_по _признаку» (Табельный  номер, ФИО, Count-Дата, Месяц, Год,

    -Сумма_больничного:Для_больн_по_признаку![Count-Дата]*Сотрудники!Мин_сред_зараб_в_день) 

  1. Запрос  «Зарплата»
 

    - Запрос  «ТабельМесЗапрос» (Табельный номер,  Часы, Норма,)

    - Сотрудники (ФИО)

    - Начислено: Сотрудники!Оклад/[Норма]*[Часы]

    - НДФЛ: (Сотрудники!Оклад/[Норма]*[Часы])*0,13

    - Итого_начислено 

  1. Запрос  «Зарплата для больничного»
 

    - Запрос  «Табель месяца» (Табельный_номер, sum-Количество_часов, НомерМесяца)

    -Табл. «Сотрудники» (ФИО, Оклад) 

    - Начислено: Сотрудники!Оклад/ТабельМес!Норма*ТабельМес![Sum-Количество_часов]

    - НДФЛ: (Сотрудники!Оклад/ТабельМес!Норма*ТабельМес![Sum-Количество_часов])*0,13

    -Итого_начислено: Сотрудники!Оклад/ТабельМес!Норма*ТабельМес![Sum-Количество_часов]-(Сотрудники!Оклад/ТабельМес!Норма*ТабельМес![Sum-Количество_часов]*0,13) 
     

Проектирование приложений пользователя в среде СУБД ACCESS