Разработка приложения для учета рабочего времени сотрудников предприятия (стр. 2 из 3)

2.3 Информационная модель

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

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

Рисунок 5 Контекстная диаграмма информационной модели

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

Рисунок 6 Диаграмма декомпозиции информационной модели

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

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

В моей информационной модели осуществляются следующие деления подразделений: 1. «реализация» делится на «формирование счета» и «подписание договора купли - продажи».

2. «изготовление» делится на «формирование списка изготовленной продукции», «формирование цены на выполненную работу» и «поступление заявки».

3. «монтаж» делится на «подписание объема выполненных работ» и «подписание акта о сдаче объекта».

2.4 Структура данных

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

Собрав все необходимые данные по проблемной области, я разбил ее по группам (рис. 7).

Рисунок 7 Сгруппированная проблемная область.

Сгруппированные данные, я объединил в пять таблиц, и присвоил каждой таблице уникальное имя, я назвал их «предприятие», «монтаж», «клиенты», «материалы» и «бригадиры» (рис. 7), все это делается в конструкторе для создания таблиц. Там же определяется тип для каждого поля, уточняется должны ли повторяться данные в этом поле. Необходимо было, чтобы в каждой из таблиц было поле, которое являлось бы общим для двух таблиц, иначе я не смог бы связать все таблицы в одну. После этого я выбрал главные, определяющие поля в каждой таблице, которые сделал ключевыми. Например, в таблице «бригадиры» ключевым полем у меня было «ответственный», поскольку это поле является главным, оно есть в таблице «предприятие» и данные в этом поле не совпадают, что тоже является не мало важным моментом.

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

После установления связей я определил тип связи, это нужно для того, чтобы знать последовательность заполнения таблиц. В моем случае все связи определялись типом «один ко многим» (рис 8).

Рисунок 8 Схема данных ООО «СЭТ»

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

2.5 Обработка данных

Обработка данных в Access осуществляется посредством запросов, которые создаются либо в конструкторе, либо с помощью структурированных запросов SQL. В своей базе данных я использовал SQL.

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

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

SELECT №накладной, объемзаказа, видработ, стоимостьзаказа

После этого я определил, в каких таблицах хранятся эти данные, и записал их во второй строке после «from»:В моем случае это таблицы «предприятие» и «монтаж»:

FROM Предприятие, монтаж

Для создания данного запроса требуется описать связь двух таблиц, поскольку стоимость заказа хранится в таблице «предприятие», а все остальные данные в таблице «монтаж». Эту связь мы описываем с помощью зарезервированного слова «where»:

WHERE Предприятие.№заказа=монтаж.№заказа

После этого я закрыл запрос и назвал его «накладная».

Второй запрос, который я хочу описать, связан с начислением премиальных. Чтобы стимулировать рабочих на повышение квалификации, предприятие пошло на увеличение заработной платы, путем начисления премиальных тем, у кого разряд выше второго. Я это делал следующим образом. Нам нужны данные – «ответственный» и «заработная плата» из таблицы «бригадиры». Причем заработная плата должна увеличиваться. Допустим премия равна 1000 у.е., поэтому тело запроса будет выглядеть так:

SELECT Ответственный, Заработнаяплата+1000 AS Премия

FROM Бригадиры

«…AS Премия» означает, что заработная плата после суммирования с премиальными, будет записываться в новый столбец, который будет называться «Премия». Далее я вводил строку с условием отбора, в которой оговаривал какой разряд должен иметь бригадир, чтобы ему начислили премию:

WHERE Разряд>2;

После этого я закрыл запрос и назвал его «Премия».

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

2.6 Разработка пользовательского интерфейса

Рассмотрим разработку интерфейса компонента приложения ООО «СЭТ», обеспечивающего технологию работы с взаимосвязанными документами приложения при подготовке и вводе в базу данных.

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

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

В процессе функционирования предприятия, часто приходится сталкиваться с такой важной документацией, как накладная, список заказов с объемом необходимых к выполнения заказов, просмотр работников, их квалификация, начисление премиальных, поэтому наиболее часто используемую информацию я обозначил через запросы представленные в форме отчетов. Для их разработки я использовал мастер построения отчетов. В нём необходимо было выбрать запрос, тип построения отчета, а также стиль в котором отчет должен быть представлен. Отчет делается на каждый представленный мною запрос. Также нужно отметить, что менять, заносить новые, или удалять данные из таблиц в отчете мы не можем, что обеспечивает сохранность данных.