Размещено на http://www.allbest.ru/

Курсовая работа по дисциплине: «Разработка программных приложений»

На тему: «Разработка приложения для учета компьютерной техники и программного обеспечения в организации»

Оглавление

Введение

1. Теоретическая часть

2. Практическая часть

Заключение

Список литературы

Приложение

Введение

Автоматизированный учет компьютерной техники на предприятии, особенно на крупном - очень важная и полезная вещь. Если с учетом десятка компьютеров и пары принтеров и сканеров можно справиться с помощью листка бумаги, карандаша и собственной памяти, то держать в голове сведения о местонахождении и перемещениях компьютерного оборудования свыше 40-50 единиц - довольно проблематично. Наличие удобного специализированного программного обеспечения для учета компьютерной техники сильно облегчает задачу учета специалисту профильного отдела. Информация, хранимая с помощью специализированного программного обеспечения в базе данных (БД) имеет целый ряд преимуществ перед аналогичной информацией, хранимой в голове человека («забыл», заболел, уволился) или в бумажном виде - очевидна. Информация в БД легко позволяет отслеживать динамику состояния техники (поступила на склад - введена в эксплуатацию - передана Иванову - передана Петрову - сдана в ремонт - отремонтирована - выдана Сидорову - актирована - списана - утилизирована и т.д.). Также подобная информация удобна для формирования отчетов по технике в различных разрезах (сколько в организации устаревших компьютеров, требующих замены, каковы ежемесячные расходы на расходные материалы, кто больше всех расходует картриджи и пр.). Анализ подобных отчетов позволяет руководству ИТ-направления оптимизировать затраты на приобретение, ремонт и обслуживание техники, рационально распределять нагрузку на принтеры и МФУ. На рынке программного обеспечения довольно богатый выбор как платных, так и бесплатных программ для учета компьютерной техники с разными функциональными возможностями, различной широтой охвата предметной области (только учет компьютеров и принтеров, учет расходных материалов, учет заявок на ремонт и обслуживание техники и т.д.)

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

Итак - задача: написать специализированную программу и заложить в неё следующий функционал:

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

2. Учет перемещения техники (склад<->пользователь, пользователь<->пользователь, пользователь<->подрядчик).

3. Учет расхода расходных материалов для обслуживания техники.

4. Актирование и списание неисправной техники.

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

Разрабатываемый программный комплекс будет состоять из непосредственно приложения, в котором будут реализованы основные алгоритмы работы программы и базы данных, в которой будут храниться данные, подлежащие обработке. От продуманности принципиальных концепций и тщательной проработки деталей зависит удобство пользования программой, её надёжность, масштабируемость и переносимость.

Разработка программного обеспечения будет мной вестись с применением интегрированной среды разработки (IDE) Borland C++ Builder.

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

В качестве базы данных выбираю SQL Server Express 2005. Borland C++ Builder позволяет выбрать любую из большого списка поддерживаемого набора баз данных, но я остановлюсь именно на SQL, поскольку это позволит закрепить недавно изученный материал. SQL Server Express имеет удобный инструмент для проектирования структуры будущей базы данных, под названием MS SQL Server Management Studio.

Далее, в теоретической части курсовой работы будут подробно рассмотрены детали проекта.

1. Теоретическая часть

Стремительное развитие товарных и финансовых рынков в России явилось мощным толчком к интенсивному нарастанию процессов информатизации во всех сферах жизни общества. Изменились подходы к оценке роли информации и информационному обслуживанию производственно-хозяйственной, управленческой деятельности и различных категорий пользователей. Современное общество живет в период, характеризующийся небывалым увеличением информационных потоков. Наибольший рост объема информации наблюдается в промышленности, торговле, финансово-банковской сфере. Рыночные отношения предъявляют повышенные требования к своевременности, достоверности, полноте информации, без которой немыслима эффективная маркетинговая, финансово-кредитная, торговая деятельность. Роль информации в общественной жизни существенно меняется. Информация приобретает преобразующий, определяющий характер. Качественно новое обслуживание информационных процессов человеческой деятельности связано с использованием современной персональной электронно-вычислительной технике, систем телекоммуникаций, созданием сетей ЭВМ. Актуальность вопросов информатизации всех сфер общественно-экономической жизни вполне очевидна. Потребность в разработке и применении эффективных и адекватных реальной действительности компьютерных программ и технологий сегодня возрастает. Автоматизация в общем виде представляет собой комплекс действий и мероприятий технического, организационного и экономического характера, который позволяет снизить степень участия или полностью исключить непосредственное участие человека в осуществлении той или иной функции производственного процесса, процесса управления. Таким образом, автоматизированные системы обработки информации можно рассматривать как человеко-машинную систему с автоматизированной технологией получения результатной информации, необходимой для информационного обслуживания специалистов и оптимизации процесса управления в различных сферах человеческой деятельности, в том числе и на промышленных предприятиях. Важнейшим элементом систем автоматизированной обработки информации являются базы данных (БД). Можно смело утверждать, что появление баз данных стало одним из важнейших достижений в области программного обеспечения. Базы данных лежат в основе автоматизированных информационных систем (АИС). Использование вычислительной техники (ВТ) обычно связывают с двумя направлениями: первое - для выполнения трудоемких численных расчетов, которые почти невозможно выполнить вручную, второе - для обработки больших объемов информации. Первое направление в начале развития ВТ было, по существу, единственным. Характерной особенностью этого направления является наличие сложных алгоритмов обработки, которые применяются к простым по структуре данным, объем которых сравнительно невелик. Второе направление по времени появилось позже, что объясняется техническими трудностями и несовершенством носителей данных: медлительностью одних и малой емкостью других. Эти ограничения не являлись слишком существенными для чисто численных расчетов, но препятствовали реализации задач обработки и хранения больших объемов данных. Возросшие возможности компьютеров по хранению информации в конце шестидесятых годов двадцатого века привели к развитию технологий информационных систем, где требуется быстрый доступ к большому объему информации. Автоматизированные информационные системы (АИС) - программно-аппаратные комплексы, обеспечивающие надежное хранение информации в памяти ЭВМ, выполнение специфических для решаемой задачи преобразований информации и вычислений и удобный для пользователя интерфейс. Активное создание и внедрение АИС началось в то время, когда человечество подошло к ситуации, в которой потоки информации возросли настолько, что все населяющие Землю люди, уже не могли справиться с ее обработкой. Второй причиной появления автоматизированных систем явилось противоречие между своевременностью и достоверностью информации. Чтобы выработать управляющее воздействие на объект, надо собрать о нем информацию. Первые автоматизированные системы разрабатывались на основе позадачного метода. Выбирались очевидные, легко формализуемые задачи, автоматизация которых давала эффект немедленно (кадры, расчет заработной платы, снабжение). Для каждой задачи создавался свой блок данных и своя прикладная программа, решающая эту задачу с максимальной эффективностью. Прикладные программы содержали как описания данных, так и алгоритмы манипулирования ими: поиска, добавления, удаления и тому подобное. При этом, с одной стороны, изменение в организации данных приводило к необходимости изменения программ, в которых они описывались, а с другой - все прикладные программы содержали практически идентичные алгоритмы манипулирования данными. Кроме того, разные задачи, например задача расчета заработной платы и задача управления кадрами, могли содержать одинаковые данные о сотрудниках, что приводило к необходимости контролировать соответствие данных в обеих задачах и при изменении данных в одной задаче, требовалась соответствующая их корректировка в другой. Положение изменилось, когда были сформулированы требования к организации хранения и обработки данных в автоматизированных системах.

Суть этих требований сводилась к двум положениям:

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

2. Данные должны быть максимально независимы от программ их обработки.

Выполнение этих требований привело к созданию для всех решаемых в рамках АИС задач единой базы данных (БД) и к разработке управляющей программы, предназначенной для управления этими данными -- системы управления базой данных (СУБД).

Примеры разработанных и используемых АИС:

1. В супермаркете, когда кассир считывает с покупок штрих-код для поиска цены данного предмета в базе данных всех товаров.

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

3. В библиотеке обращение к базе данных, содержащей сведения о книгах, позволяет найти книгу (книги), составить заявку на бронирование и т.д.

4. В страховых компаниях (информация о застрахованных , данные полисов и пр.)

5. В вузе - база данных с информацией о студентах, результатах сдачи различных экзаменов.

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

К.Дж. Дейт (C.J. Date) -- один из наиболее уважаемых во всем мире экспертов и мыслителей в области технологии баз данных, независимый публицист, лектор, ученый и консультант, специализирующийся на технологии реляционных баз данных, 80-е гг. XX столетия: «База данных состоит из совокупности устойчивых (персистентных) данных, которые используются прикладными системами некоторого определенного предприятия. В сущности база данных есть не что иное, как автоматизированная система учета и обработки записей».

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

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

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

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

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

Упрощенное и несколько устаревшее название СУБД - метод доступа (МД):

СУБД = БД + МД

Наиболее полный вариант СУБД включает следующие компоненты:

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

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

- компилятор для создания независимого пакета программ в виде набора exe-файлов;

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

СУБД классифицируются по различным основаниям:

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

- технология (файл-серверные, клиент-серверные, распределенные);

- местоположение отдельных частей (локальные и сетевые).

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

Файловые системы давно устарели, но есть несколько причин, по которым с ними следует познакомиться. В частности, для понимания логической структуры БД и механизма взаимодействия системы управления (СУ) и БД.

Файловые системы были первой попыткой компьютеризировать известные всем ручные картотеки.

БД представлена в виде набора файлов, например (семейства dBASE):

файлы таблиц,

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

файлы запросов,

файлы отчетов,

файлы программ (приложений, созданных как средствами самой СУБД, так и внешними по отношению к ней), др.

Технология файл-сервер предполагает копирование (перекачку) данных с сервера на ПК. Таким образом, в любой момент времени могут существовать несколько различных копий БД. Задача сервера - синхронизация БД.

Недостатки:

Низкая надежность (нарушение целостности, достоверности).

Снижение производительности по мере роста количества файлов.

Технология клиент-сервер относится к группе технологий распределенной обработки данных.

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

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

Достоинства:

меньший объем передаваемых данных,

централизованное хранение, обслуживание коллективного доступа к общей корпоративной информации

индивидуальная работа пользователей.

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

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

Пример мощного промышленного сервера, используемого для создания запросов и управления данными: SQL-base.

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

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

Те программы которые раньше назывались локальными (независимо от способа связи с СУБД) , чаще всего сейчас входят в число одноуровневых приложений, так как обработка данных в них ведется в единственном месте. Клиент/серверные приложения стали делиться на двухуровневые (классический клиент/сервер) и трехуровневые (клиент/сервер с ПО промежуточного слоя - сервером приложений) (см. рис. 2).

Клиентское звено при такой архитектуре СУБД в основном занято отображением данных в удобном для пользователя виде.

Выполняя свое назначение СУБД - предоставление пользователям БД средств доступа к данным - СУБД обладает приведенными ниже возможностями.

1 Позволяет определять базу данных, что обычно осуществляется с помощью языка определения данных (DDL - Data Definition Language). Язык DDL предоставляет пользователям средства указания типа данных и их структуры, а также средства задания ограничений для информации, хранимой в базе данных.

2 Позволяет вставлять, обновлять, удалять и извлекать информацию из базы данных, что обычно осуществляется с помощью языка управления данными (DML - Data Manipulation Language). Язык DML является общим инструментом управления данными и организации запросов (иногда его называют языком запросов - query language).

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

Существует две разновидности языков DML - процедурные (procedural) и непроцедурные (non-procedural) языки, - которые отличаются между собой способом извлечения данных.

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

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

Наиболее распространенным типом непроцедурного языка является язык структурированных запросов (Structured Query Language - SQL), который в настоящее время определяется специальным стандартом и фактически является обязательным языком для любых реляционных СУБД. (SQL произносится либо по буквам "S-Q-L", либо как мнемоническое имя "See-Quel".)

Для информационных систем с клиент-серверной архитектурой характерна максимальная разгрузка клиента от вычислительной работы, которая переносится на сервер, и существенное улучшение защищенности данных от несанкционированного доступа или ошибочных изменении. Для реализации клиент-серверной архитектуры применяются так называемые промышленные SQL-серверы, например, InterBase, Oracle, SQL Server, Informix, Sybase Adaptive Server, DB2.

Типичная СУБД, в том числе и реляционная СУБД, реализует ряд важных функций, рассматриваемых далее.

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

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

Пример. Ключевой особенностью архитектуры ANSI-SPARC [10] является наличие интегрированного системного каталога с данными о схемах, пользователях, приложениях и т.д. Предполагается, что каталог доступен как пользователям, так и функциям СУБД. Системный каталог (или словарь данных) является хранилищем информации, описывающей данные в базе данных (по сути, это «данные о данных, или метаданные). Обычно в системном каталоге хранятся следующие сведения:

имена, типы и размеры элементов данных;

имена связей;

накладываемые на данные ограничения поддержки целостности;

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

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

статистические данные, например частота транзакций и счетчики обращений к объектам базы данных.

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

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

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

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

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

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

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

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

Реляционные СУБД, когда-либо представленные на рынке, отличались различными характеристиками и возможностями. Важнейшей характеристикой любой СУБД является используемый в ней тип транслятора (интерпретатор или компилятор). Программы, написанные для системы-интерпретатора, не работают без наличия самой этой системы, однако в такой среде удобно разрабатывать и отлаживать программы, а также осваивать соответствующий язык программирования. Интерпретаторами являются устаревшие на сегодняшний день СУБД dBASE, FoxPro, также и СУБД Access.

Наличие компилятора позволяет сформировать ЕХЕ-файлы готовых программ, работающих автономно от СУБД. Недостатком систем-компиляторов являются большие суммарные затраты времени на многократную компиляцию и сборку (линковку) исходных модулей программы при ее отладке. Наиболее популярной из используемых ранних СУБД реляционного типа стоит упомянуть Clipper. Однако в некоторых СУБД могут присутствовать как компиляторы, так и интерпретаторы, например, в dBASE и FoxPro, и всех современных СУБД реляционного типа.

Информационные системы с клиент-серверной архитектурой характеризуются наличием сервера - программным комплексом, устанавливаемым в компьютерной сети на специально выделенном компьютере--сервере, к которому имеют одновременный доступ компьютеры пользователей. При этом достигается максимальная разгрузка клиента от вычислительной работы, которая переносится на сервер. Если языком взаимодействия с СУБД является язык SQL, то речь идет о SQL-сервере, например, промышленные SQL-серверы: InterBase, Oracle, SQL Server, Informix, Sybase Adaptive Server, DB2. Использование SQL-сервера обеспечивает эффективное коллективное использование общей БД, также установленной на компьютере-сервере.



Рис. 1.1. архитектура СУБД по технологии

2. Практическая часть

Разрабатываемое приложение не имеет какой-либо специализированной направленности, типа, только для строительных организаций или только для бюджетных организаций. Программа подходит для работы в любой среде, где количество компьютеров и оргтехники перевалило за тот предел, когда можно сведения обо всей технике держать в голове. Коснусь сути поставленной задачи. Необходимо на некоем предприятии организовать автоматизированную систему учета поступления, перемещения и списания вычислительной и оргтехники. Данные в базе данных должны быть организованы таким образом, чтобы удобно было их обрабатывать, в том числе, например формировать отчеты в разных разрезах, добавлять процедуры массового прихода техники, массового списания отслужившей свой век техники и т.д.Конечно, разрабатываемая задача (программа и база данных) будет несколько упрощенной по сравнению с коммерческими платными программами, например ИТИЛ (на базе платформы 1С 8) или IT-Invent. На рынке великое множество программ подобной направленности, написанные как профессиональными софтверными фирмами так и простыми программистами-одиночками, имеющими различный уровень профессионализма как в написании программ, так и проектировании баз данных. Эти программы могут иметь достаточно приличную стоимость, быть условно-бесплатными или совершенно бесплатными. Разница и уровень охвата автоматизируемых процессов - от простого учета приема/передачи компьютеров до сложных комплексов, позволяющих кроме компьютеров учитывать также и программное обеспечение, учет расходных материалов, учет заявок в Снрвис-Деск в больших компаниях, расчет трудозатрат и экономических показателей деятельности ИТ-отдела. Я, в силу отсутствия достаточного времени (да и опыта) для проектирования сложной системы, ограничусь простейшим функционалом - учет поступления новой техники, учет перемещений техники со склада ИТ сотруднику, от сотрудника к сотруднику и от сотрудника на склад ИТ. Также будет предусмотрено формирование некоторого числа отчетов по разным критериям.

Для написания программы я выбрал имеющуюся у меня в наличии интегрированную среду разработки (IDE - Integrated Development Environment) Borland C++ Builder 6.0. данную задачу позволит разработать, в принципе, любая современная (и не очень) система разработки приложений (Pascal, VisualBasic, MS Access, VisualFoxPro, C# и пр.), но выбрал я то, что у меня уже есть, с чем я достаточно знаком и в чем удобно работать. В качестве базы данных мной выбран MS SQL Server (версия SQL Server Express 2005). Для разработки таблиц применена среда SQL Server Management Studio Express 2005. Это достаточно удобный инструмент, который позволяет разработчику выполнять все манипуляции с таблицами, данными, хранимыми процедурами и т.д. Для доступа к БД из приложения применены компоненты из набора ADO (входят в стандартную поставку Borland C++ Builder 6.0 Enterprise). Это компоненты ADOConnection для установления связи с внешней базой данных SQL, ADOTable для доступа к отдельным таблицам БД (я их применял для простейших таблиц, типа справочник типов техники и справочник отделов), ADOQuery - для доступа к связанным таблицам (с применением SQL-команд) и для формирования отчетов (там тоже сложные обращения к нескольким таблицам). С компонентами ADOStoredProc связываться не стал из-за их чрезмерной "капризности" и массы ограничений при работе. Хранимые процедуры я вызывал с помощью ADOQuery, задавая в качестве команд SQL вызов нужных мне (заранее сформированных) хранимых процедур.

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

1. Таблица "Пользователи" (users) - Здесь хранятся данные о работниках предприятия - ФИО, отдел, в котором работает сотрудник, и дата его приема на работу.

2. Таблица "Отделы" (dapartments) - маленькая табличка, в которой перечислены отделы, имеющиеся на предприятии.

3. Таблица "Типы" (types) - здесь перечислены типы техники (принтеры, мониторы, сканеры и т.д.). Это нужно для правильного формирования отчетов.

4. Таблица "Устройства" (devices) - здесь хранятся сведения о каждом отдельном устройстве, подлежащем учету: наименование устройства, его тип, инвентарный номер устройства, на ком оно числится, когда поступило на учет.

5. Таблица "История" (history) - сюда записываются сведения при добавлении нового устройства, перемещении или списании. По этой таблице легко отследить судьбу любого устройства (когда получено, кому и когда передавалось, когда списано).

Более детально рассмотрим структуру БД в разрезе таблиц.



Рисунок 2.1

Таблица "Пользователи" (users), рисунок 2.1, состоит из четырех полей:

id (тип integer) - автоинкрементирющееся поле, первичный ключ.

По этому полю таблица "Пользователи" связана с таблицей "Устройства" (devices).

fio (тип varchar(50) - фамилия, имя и отчество пользователя. Разбивать ФИО на отдельные поля, я посчитал, не имеет смысла в данной задаче. По этому полю данные отсортированы в таблице "Пользователи".

date (тип datetime) - дата приема пользователя на работу. Поле заполняется в процессе ввода нового пользователя и запрещено к изменению в дальнейшем.

department (тип integer) - целочисленное поле, в котором хранится код подразделения. По этому полю таблица "Пользователи" связана с таблицей "Отделы".

Рисунок 2.2

Таблица "Отделы" (departments), рисунок 2.2, состоит всего из двух полей:

id (тип integer) - автоинкрементирющееся поле, первичный ключ. По этому полю таблица "Отделы" связана с таблицей "Пользователи".

name (тип varchar(50)) - название подразделения, отдела, службы.

Рисунок 2.3

Таблицы "Типы", рисунок 2.3 - тоже маленькая и состоит из двух полей:

id (тип integer) - автоинкрементирющееся поле, первичный ключ. По этому полю таблица "Типы" связана с таблицей "Устройства".

name (тип varchar(50)) - названия типов устройств (принтеры, сканеры, мониторы и т.д.).

Рисунок 2.4

Таблица "Устройства" (devices), рисунок 2.4, состоит из шести полей:

id (тип integer) - автоинкрементирющееся поле, первичный ключ.

model (тип varchar(50)) - название устройства (например, Epson FX-1000).

invn (тип varchar(50)) - инвентарный номер устройства.

type (тип integer) - код типа устройства. По этому полю таблица "Устройства" связана с таблицей "Типы".

owner (тип integer) - код владельца. По этому полю таблица "Устройства" связана с таблицей "Полъзователи".

date (тип datetime) - время постановки устройства на учет.

Рисунок 2.5

Таблица "История" (history), рисунок 2.5 - состоит из восьми полей:

id (тип integer) - автоинкрементирющееся поле, первичный ключ.

operation (тип varchar(50)) - название операции (поступление, перемещение, списание).

device (тип varchar(50)) - название устройства в текстовом виде.

type (тип varchar(50)) - тип устройства в текстовом виде.

invn (тип varchar(50)) - инвентарный номер устройства.

user1 (тип varchar(50)) - от кого выполнено поступление, перемещение.

user2 (тип varchar(50)) - на кого выполнено перемещение, списание.

date (тип datetime) - дата осуществления операции.

Логическая схема связей таблиц в базе данных (рис. 2.6)



Рисунок 2.6

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

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

Сведения о пользователях хранятся в отдельной таблице. Сведения об отделе, в котором работает пользователь, хранятся в виде идентификатора. В отдельной таблице "Отделы" под этими идентификаторами хранятся текстовые названия отделов. Пользователей в таблице "Пользователи" можно добавлять, редактировать. Если за пользователем не закреплено оборудование - сведения о нем можно удалять. Если за пользователем числится оборудование, то тут ситуация двоякая: первый вариант - сообщить оператору о наличии у удаляемого пользователя числящегося за ним оборудования и ничего далее не делать. Второй вариант - автоматически переместить все оборудование, числящееся за пользователем на склад ИТ. В приложении мной введена специальная переменная usr_mode, определяющая поведение системы в случае попытки удаления пользователя с числящимся за ним оборудованием. Ее значение задается в самом начале программы. Если usr_mode равна "1", то система просто выдает предупреждение о наличии у удаляемого пользователя оборудования и удаление не выполняется. Если переменная в "0", то производится автоматическое перемещение всей техники с пользователя на склад ИТ (в моей программе не реализовано, но, на самом деле, ничего сложного - делается цикл до RecordCount и в поле owner таблицы devices проставляется код нового владельца - это "склад ИТ"). Для выполнения операций с таблицей "Пользователи" под визуальным отображением (гридом - TDBGrid) таблицы "Пользователи" имеются соответствующие кнопки "Добавить", "Изменить", "Удалить".

Аналогично - таблица "Устройства" (devices) - можно заводить новое оборудование (но только на склад ИТ !), редактировать разрешенные к редактированию сведения об оборудовании и удалять (списывать) оборудование. Поле "type" таблицы "Устройства" хранит идентификатор типа устройства, названия типов хранятся в отдельной таблице "Типы". Также под гридом есть соответствующие кнопки "Добавить", "Изменить", "Удалить". Присутствует также кнопка "Переместить", при нажатии на которую оператору дается возможность выбрать нового пользователя. Перемещению подлежит то устройство, на котором находится курсор. На закладке "Настройки" доступны к редактированию таблицы "Отделы" и "Типы", а также расположен грид таблицы "История". Таблица "История" не предполагает каких-либо действий с ней. Далее идет закладка "Отчеты". Ее предназначение - формирование отчетов по разным критериям.

Теперь расскажу о процессе проектирования и возникших трудностях. Первоначально планировалось использовать две таблицы "Пользователи" (users) и "Устройства" (devices) как элементы ADOTable, связанные друг с другом по методу "master-detail" ("Пользователи" в роли главной таблицы, "Устройства" - в роли подчиненной). Но при таком раскладе становится проблематичной операция по переподчинению записи в detail-таблице, например, при передаче принтера от Иванова к Петрову, или со склада ИТ кому-либо из пользователей. Дело в том, что таблицы связаны по ключевым полям и как раз изменение ключевого поля в таком режиме запрещены. Цивильного решения этой проблемы мне нигде найти не удалось. Поэтому я решил пойти по другому пути. Я обратился к таблицам "Пользователи" и "Устройства" с помощью компонент ADOQuery. С точки зрения интерфейса для программиста - никакой разницы: эта компонента "выглядит" точно также как ADOTable. Для изменения подчиненности устройства я написал, проверил и сохранил в базе данных хранимую процедуру (Stored Procedure) с именем ch_owner, в качестве входного параметра передаю процедуре id нового владельца и процедура на стороне SQLсервера производит переподчинение записи. Мне лишь остается после вызова поцедуры принудительно обновить таблицы (иначе произведенные изменения сразу не отображаются). Второй причиной выбора в пользу ADOQuery было то, что, например, в таблице "Пользователи" содержалось не название отдела, в котором работал сотрудник, а его код, а текстовое название хранилось в другой таблице - "Отделы" под соответствующим кодом. В моем случае строка SQL-запроса в компоненте ADOQuery выглядела следующим образом

select users.id, users.fio, users.date, users.department, departments.name from users join departments on ( users.department = departments.id ) ORDER BY users.fio ASC

Здесь я объединяю таблицы users и departments с помощью конструкции join.

Аналогично, в таблице "Устройства" хранится не текстовое название типа устройства, а его код. Само название хранится в отдельной таблице "Типы" под соответствующим уникальным идентификатором (id). Соответственно, запрос выглядит следующим образом:

select devices.id, devices.model, devices.type, types.name, devices.invn, devices.owner, devices.date from devices join types on ( devices.type = types.id ) where devices.owner =:id

Остальные моменты программирования не вызвали каких-либо серьезных затруднений, достойных быть особо описанными здесь. Формирование отчетов также мной было выполнено с применением компонентов ADOQuery. Запросные SQL-команды сначала опробовались мной в среде SQL Server Management Studio Express, а затем помещались в ADOQuery.

Думаю, стоит рассказать еще об одном моменте, с которым я столкнулся уже при написании отчетов. Если, например, формируется отчет о наличии техники у какого-то пользователя и в заголовке отчета хотелось бы видеть что-то наподобие "Отчет по технике у пользователя Иванов Иван Иванович", то имя пользователя в отчет QuickReport (именно этот генератор отчетов входит в комплект поставки Borland C++ Builder 6.0) передать непросто. Для этого необходимо использовать метод BeforePrint:

void __fastcall TfrReport3::QuickRep1BeforePrint(TCustomQuickRep *Sender,

bool &PrintReport)

{

QRLabel8->Caption = frMain->lcbRepUserSelect->Text;

}

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

Итак - главное рабочее окно программы - закладка "Учет техники" (рис. 2.7)



Рисунок 2.7

Далее, окно "Настройки" (рис. 2.8)

Рисунок 2.8

Здесь расположена кнопка "Инициализация БД" - она нужна, в основном, в процессе разработки. По нажатию этой кнопки происходит полное стирание всех записей во всех таблицах базы данных и заполнение всех таблиц некоторвм набором заранее подготовленных данных. Листинг SQL-команды, которая выполнена в виде хранимой процедуры, приведен в приложении.

Последняя закладка - "Отчеты" (рис. 2.9)

Рисунок 2.9

Теперь можно переходить к описанию каждой оперрации. Начну с добавления нового пользователя (рис. 2.10). При нажатии на кнопку "Добавить" под гридом "Пользователи" появляется окно ввода нового пользователя (кстати, при нажатии на кнопку "Изменить" появляется это же самое окно, только с другим заголовком). ФИО вводится руками, отдел выбирается из списка отделов (помогает элемент TDBLookupComboBox, "заглядывающий" в таблицу "Отделы"). Дата вводится руками. При нажатиина кнопку "Ввод" в таблице "Пользователи" (users) создается новая пустая запись и заполняется данными из вышеописанной формы. При нажатии на кнопку "Отмена" - ничего не происходит: введенные в форму данные пропадают, таблица остается неизменной. В новой записи поле id я не ирогаю, оно генерится системой самостоятельно, путем добавления единицы к id предыдущей записи.



Рисунок 2.10

На рисунке 2.11 показана операция "Изменить" пользователя, на котором стоит курсор.

Рисунок 2.11

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

Аналогичные процессы происходят и при работе с таблицей "Устройства" (рис. 2.12, 2.13)

Рисунок 2.12

Рисунок 2.13

Опишу работу кнопки "Переместить" (рис. 2.14).



Рисунок 2.14

При нажатии на кнопку "Переместить" появляется форма, содержащая элемент выбора из списка "Пользователи" (уже знакомый нам TDBLookupComboBox). Прямая замена значения поля "owner" т екущей записи на код нового владельца здесь невозможна - процессор баз данных BDE не дает заменить значение поля, по которому связаны две таблицы "Пользователи" и "Устройства". Поэтому пришлось доверить это дело специально подготовленной хранимой процедуре ch_owner, котоой в качестве параметра передается id нового владельца. В тест программы пришлось добавить специальные команды по принудительному обновлению таблиц "Пользователи" и "Устройства", т.к. действия, произведенные хранимой процедурой не обносляют данные в отображаемых в программе таблицах. Если коды старого владельца и новового совпадают, то программа выдает предупреждение "Перемещение не произведено" и ничего не происходит, чтобы не загружать сервер баз данных ничтожными операциями. программа файловый компьютеризация

На закдадке "Настройки" - тоже все стандартно - кнопки для добавления, редактирования и удаления отделов и типов устройств (см. рисунки)



Рисунок 2.15

Рисунок 2.16

Рисунок 2.17



Рисунок 2.18

Перехожу к описанию последней закладки - "Отчеты". Здесь подготовлены пять различных отчктов по технике. Выбор нужного отчета происходит при переулючении селектра (панель GroupBox с пятью элементами RadioButton). Выбираем нужный отчет (при этом некоторые отчеты требуют указания дополнительных параметров, напимер, выбора из списка пользователя, по которму надо стелать отчет, или тип техники). Листинги отчетов приедены в Приложении.

Заключение

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

Список литературы

1. Е. Ермолаев, Т. Сорока: C++ Builder: Книга рецептов. Изд-во Кудиц-Образ, г. Москва, 2006 г. - 196 стр.

2. Фуфаев, Э.В. Базы данных Учеб. пособие для студ. сред. проф. образования / Э.В. Фуфаев, Д.Э. Фуфаев. - 3-е изд., стер. - М.: Академия, 2007. - 320 с.

3. Культин Н.: C++ Builder в задачах и примерах. Издательство БХВ-Петербург, г. Санкт-Петербург, 2005 г. - 336 стр.

4. Послед Б.С.: Borland C++ Builder 6. Разработка приложений баз данных. Издательство «ДиасофтЮП», г. Санкт-Петербург, 2003 г. - 320 стр.

5. Шустова Л.И. Тараканов О.В.: Базы данных. Учебник. Издательство Инфра-М, 2016 г. - 304 стр.

6. В. В. Дунаев: Базы данных. Язык SQL для студента. Издательство БХВ-Петербург, 2008 г. - 288 стр.

7. Крис Фиайли: SQL. Издательство ДМК Пресс, Москва, 2013 г. - 456 стр.

8. Дмитрий Осипов: Базы данных и Delphi. Теория и практика. Издательство БХВ-Петербург, 2011 г. - 752 стр.

Приложение

Отчеты.

SQL-запросы.

Хранимая процедура (StoredProc) CH_OWNER

ALTER PROCEDURE [dbo].[ch_owner] @newid INT, @devid INT AS UPDATE devices SET owner = @newid WHERE id = @devid

Хранимая процедура (StoredProc) ADDDEVICE

ALTER PROCEDURE [dbo].[adddevice] @model1 VARCHAR(50), @invn1 VARCHAR(50), @type1 INT, @owner1 INT, @date1 DATETIME

AS INSERT INTO devices ( model, invn, type, owner, date )

VALUES ( @model1, @invn1, @type1, @owner1, @date1 )

Хранимая процедура (StroredProc) INIT_DB

ALTER PROCEDURE [dbo].[Init_db] AS

BEGIN

SET NOCOUNT ON

DROP TABLE users

DROP TABLE departments

DROP TABLE devices

DROP TABLE types

DROP TABLE history

CREATE TABLE [dbo].[users]

(

[id] [int] IDENTITY(1,1) NOT NULL,

[fio] [varchar](50) NULL,

[date] [datetime] NULL,

[department] [int] NULL,

CONSTRAINT [PK_users] PRIMARY KEY CLUSTERED ( [id] ASC )

) ON [PRIMARY]

CREATE TABLE [dbo].[departments]

(

[id] [int] IDENTITY(1,1) NOT NULL,

[name] [varchar](50) NULL,

CONSTRAINT [PK_departments] PRIMARY KEY CLUSTERED ( [id] ASC )

) ON [PRIMARY]

CREATE TABLE [dbo].[devices]

(

[id] [int] IDENTITY(1,1) NOT NULL,

[model] [varchar](50) NULL,

[invn] [varchar](50) NULL,

[type] [int] NULL,

[owner] [int] NULL,

[date] [datetime] NULL,

CONSTRAINT [PK_devices] PRIMARY KEY CLUSTERED ( [id] ASC )

) ON [PRIMARY]

CREATE TABLE [dbo].[types]

(

[id] [int] IDENTITY(1,1) NOT NULL,

[name] [varchar](50) NULL,

CONSTRAINT [PK_types] PRIMARY KEY CLUSTERED ( [id] ASC )

) ON [PRIMARY]

CREATE TABLE [dbo].[history]

(

[id] [int] IDENTITY(1,1) NOT NULL,

[operation] [varchar](50) NULL,

[device] [varchar](50) NULL,

[type] [varchar] (50) NULL,

[invn] [varchar](50) NULL,

[user1] [varchar](50) NULL,

[user2] [varchar](50) NULL,

[date] [datetime] NULL,

CONSTRAINT [PK_history] PRIMARY KEY CLUSTERED ( [id] ASC )

) ON [PRIMARY]

INSERT INTO users ( fio, date, department ) VALUES ( '_Склад ИТ', '01.01.2000', 1)

INSERT INTO users ( fio, date, department ) VALUES ( 'Степанов Петр Степанович', '12.01.2005', 2)

INSERT INTO users ( fio, date, department ) VALUES ( 'Клюшкин Николай Евгеньевич', '13.02.2006', 3)

INSERT INTO users ( fio, date, department ) VALUES ( 'Сысоев Дмитрий Васильевич', '14.03.2007', 4)

INSERT INTO users ( fio, date, department ) VALUES ( 'Аверин Андрей Антонович', '15.04.2008', 5)

INSERT INTO users ( fio, date, department ) VALUES ( 'Нефёдов Ярослав Геннадиевич', '16.05.2009', 2)

INSERT INTO users ( fio, date, department ) VALUES ( 'Шириков Виктор Иванович', '17.06.2010', 1)

INSERT INTO users ( fio, date, department ) VALUES ( 'Борисов Борис Семенович', '18.07.2011', 2)

INSERT INTO departments ( name ) VALUES ( 'Отдел ИТ' )

INSERT INTO departments ( name ) VALUES ( 'Бухгалтерия' )

INSERT INTO departments ( name ) VALUES ( 'Отдел снабжения' )

INSERT INTO departments ( name ) VALUES ( 'Транспортный отдел' )

INSERT INTO departments ( name ) VALUES ( 'Администрация' )

INSERT INTO types ( name ) VALUES ( 'Принтер' )

INSERT INTO types ( name ) VALUES ( 'Сканер' )

INSERT INTO types ( name ) VALUES ( 'Монитор' )

INSERT INTO types ( name ) VALUES ( 'Системный блок' )

INSERT INTO types ( name ) VALUES ( 'ИБП' )

INSERT INTO types ( name ) VALUES ( 'Мышь' )