Код_средства(FK)
|
Инвентарный
номер
|
Дата
испытания
|
Дата
следующего испытания
|
Все таблицы связаны между собой по смыслу и
особенностям работы базы. Для обеспечения целостности данных при создании связи
между таблицами следует
обеспечивать целостность данных. Каждая таблица
содержит ключевое поле, которое помечается в каждой таблице. Ключевые поля
обозначены в таблицах вместе с ключом (PK- primary key, FK -foreign key)
«Таблица наименования защитных средств» - эта
таблица содержит сведения о наименовании защитных средств
«Таблица наименования объектов» - в этой таблице
отображены названия объектов, где находятся защитные средства
«Таблица даты и инвентарных номеров» - содержит
данные о датах и инвентарных номерах защитных средств
Связи между таблицами наглядно отображены.
2.3 Создание БД в СУБД MySQL
Создадим базу данных c именем uset> Greate
database USET;
Выберем ее командой> Use USET;
Таблицы создаются командой Greate table.При
создании нужно указать не только имя таблицы, но и ее полное определение,
состоящее из определений отдельных полей.
Создадим таблицу Date:TABLE Date(Код_средства
SMALLINT NOT NULL, Инв_номер SMALLINT NOT NULL, Дата_испытания DATE,
Дата_следующего_испытания DATE, PRIMARY KEY());
Введем данные в талицу:INTO Date
VALUES(1,1001,'2012-05-18','2012-11-18'); INSERT INTO Date
VALUES(2,1002,'2012-02-02','2012-07-02'); INSERT INTO Date
VALUES(3,1003,'2012-01-03','2012-03-03'); INSERT INTO Date
VALUES(4,1004,'2012-01-01','2012-12-01'); INSERT INTO Date VALUES(5,1005,'2012-03-01','2014-03-01');
INSERT INTO Date VALUES(6,1024,'2012-02-14','2012-07-14'); INSERT INTO Date
VALUES(7,1245,'2012-04-01','2012-10-01'); INSERT INTO Date
VALUES(8,7841,'2012-01-17','2012-06-13'); INSERT INTO Date
VALUES(9,1547,'2012-04-09','2013-04-16'); INSERT INTO Date
VALUES(10,2157,'2012-04-02','2014-04-16');
INSERT INTO Date VALUES(11,7541,'2012-03-01','2012-09-02'); INSERT INTO Date
VALUES(12,7451,'2012-04-05','2012-10-06'); INSERT INTO Date
VALUES(13,1578,'2012-04-01','2012-10-01'); INSERT INTO Date
VALUES(14,3254,'2012-05-02','2013-05-15'); INSERT INTO Date
VALUES(15,8123,'2012-04-16','2014-04-16'); INSERT INTO Date
VALUES(16,8914,'2012-02-15','2012-08-15'); INSERT INTO Date
VALUES(17,9123,'2011-11-16','2012-04-17'); INSERT INTO Date VALUES(18,2678,'2011-11-15','2012-04-15');
INSERT INTO Date VALUES(19,9451,'2011-10-11','2012-10-14'); INSERT INTO Date
VALUES(20,6812,'2011-07-02','2013-07-03'); INSERT INTO Date
VALUES(21,9523,'2011-10-25','2012-04-16');
INSERT INTO Date VALUES(22,9532,'2011-12-06','2012-04-06'); INSERT INTO Date
VALUES(23,6819,'2012-04-03','2012-10-03'); INSERT INTO Date
VALUES(24,3698,'2011-05- 25','2012-05-24'); INSERT INTO Date VALUES(25,3684,'2010-09-29','2012-09-25');
Создадим таблицу Obj:TABLE Obj(Код_объекта
SMALLINT NOT NULL AUTO_INCREMENT, Имя_объекта VARCHAR(30), PRIMARY KEY());
Введем данные в таблицу:INTO Obj
VALUES(1,'Распределительное_устройство_1'); INSERT INTO Obj VALUES(2,'Распределительное_устройство_2');
INSERT INTO Obj VALUES(3,'Распределительное_устройство_3'); INSERT INTO Obj
VALUES(4,'Трансформаторная_подстанция_3'); INSERT INTO Obj
VALUES(5,'Электротехническая_лаборатория');
Создадим таблицу Zach:TABLE Zach(Код_средства
SMALLINT NOT NULL AUTO_INCREMENT, Наименование VARCHAR(30), Код_объекта
SMALLINT NOT NULL, PRIMARY KEY());
Введем данные в таблицу:INTO Zach
VALUES(1,'Диэлектрические_перчатки',1); INSERT INTO Zach
VALUES(2,'Диэлектрические_боты',1); INSERT INTO Zach VALUES(3,'Указатель_высокого_няпряжения',1);
INSERT INTO Zach VALUES(4,'Оперативная_штанга',1); INSERT INTO Zach
VALUES(5,'Переносное_заземление',1); INSERT INTO Zach
VALUES(6,'Диэлектрические_перчатки',2); INSERT INTO Zach
VALUES(7,'Диэлектрические_боты',2); INSERT INTO Zach
VALUES(8,'Указатель_высокого_няпряжения',2); INSERT INTO Zach
VALUES(9,'Оперативная_штанга',2); INSERT INTO Zach
VALUES(10,'Переносное_заземление',2); INSERT INTO Zach
VALUES(11,'Диэлектрические_перчатки',3); INSERT INTO Zach VALUES(12,'Диэлектрические_боты',3);
INSERT INTO Zach VALUES(13,'Указатель_высокого_няпряжения',3); INSERT INTO Zach
VALUES(14,'Оперативная_штанга',3); INSERT INTO Zach
VALUES(15,'Переносное_заземление',3); INSERT INTO Zach
VALUES(16,'Диэлектрические_перчатки',4); INSERT INTO Zach
VALUES(17,'Диэлектрические_боты',4); INSERT INTO Zach
VALUES(18,'Указатель_высокого_няпряжения',4); INSERT INTO Zach
VALUES(19,'Оперативная_штанга',4); INSERT INTO Zach
VALUES(20,'Переносное_заземление',4); INSERT INTO Zach VALUES(21,'Диэлектрические_перчатки',5);
INSERT INTO Zach VALUES(22,'Диэлектрические_боты',5); INSERT INTO Zach
VALUES(23,'Указатель_высокого_няпряжения',5); INSERT INTO Zach
VALUES(24,'Оперативная_штанга',5); INSERT INTO Zach
VALUES(25,'Переносное_заземление',5);
3. Создание интерфейса базы данных
.1 Управление базой данных
Управление базой данных будет осуществляться
через веб-форму, написанную на языке программирования PHP, в оформлении так же
будет использоваться html- верстка для приветливого интерфейса. На главной
форме размещено меню, где можно выбрать операции управления базой данных, а
именно «Поиск по объектам», «Поиск по дате»,«Редактирование», Отчеты и «Панель
запросов» где можно оперировать Sql-запросами рис1.
Рис. 1 - Главная страница веб-формы управления
базой данных
3.2 Поиск по объектам
В «Поиске по объектам» можно выбрать
наименование объекта электроснабжения и получить данные о защитных средствах
(инвентарные номера, даты испытаний и даты следующих испытаний), в данном случае
был выбран объект «Электротехническая лаборатория «DEBA» и получены данные о
защитных средствах находящиеся на объекте рис 2
Рис. 2 - Поиск по объектам
3.3 Поиск по дате
По распоряжению руководителя предприятия осмотры
объектов проводятся каждый месяц, поэтому мастеру необходимо ежемесячно вести
контроль над датами следующих испытаний.
Мастер смены вводит даты и получает информацию,
на каком объекте в текущем месяце необходимо осуществить новые испытания
защитных средств во избежание просрочек.
Для примера возьмем месяц май и введем интервал
2012-05-01 и 2012-05-30 и нажмем «Найти» (рис 3)
По полученным данным видно, что на объектах
Электротехническая лаборатория защитное средство «Оперативная штанга подлежит
немедленному изъятию на испытания, мастером ОДС дается распоряжение
оперативному персоналу срочно выехать на объект для изъятия защитных средств.
Рис. 3 - Выполнение поиска по «Датам следующих
испытаний» по всем объектам
3.4 Редактирование данных
После изъятия защитного средства с объекта, она
передается в «Метрологическую лабораторию» для испытаний, где после прохождения
испытания на нее устанавливается бирка с датой следующего испытания и выдается
протокол испытания.
Протокол испытания остается у Мастера ОДС
который редактирует в БД «Учет защитных средств» дату испытания и дату
следующих испытаний.
Рис. 4 - Редактирование данных о защитных
средств после испытаний
3.5 Создание отчетов
При ведении журнала Учета защитных средств
необходимо все действия, осуществляемые с базой данных Учета защитных средств
заверять своей подписью, поэтому была предусмотрена возможность создания
ежемесячных отчетов в форме документа Excel. На форме можно выбрать тип отчета
по одному или по всем объектам после нажатия кнопки «вывести» появится окошко с
предложением открыть или сохранить файл Отчет.xls.(рис 5). Возьмем в качестве
примера вывод отчета по всем объектам электроснабжения (рис.6).
Рис. 5 - Вывод отчета
Рис. 6 - Вид отчета по всем объектам
4. Оценка проекта
Для выявления недостатков разработанного
программного обеспечения, проведения сравнений с существующими программными
продуктами проводится анализ качества. В данном разделе описывается методика
тестирования программной системы, приводятся результаты тестовых испытаний.
Выносятся предложения по улучшению качества программы.
Данная стадия реализуется с помощью методов
индивидуальных для каждого проекта, т.е. в зависимости от функциональных
возможностей, содержащихся данных и интерфейса. Методы тестирования проекта
создавались разработчиком, т.к. разработчик - человек больше кого бы то ни
было, понимающий структуру проекта, его назначение и возможности.
4.1 Тестирование функциональных
возможностей
Тестирование функциональных возможностей
производилось во всех формах. Применялся эмпирический метод тестирования, т.е.
исследование работоспособности проводилось многократным перебором действий. Было
проверено соответствие назначения кнопок также проверена работоспособность
запросов. В результате тестирования ошибок не выявлено.
4.2 Тестирование пользовательского
интерфейса
Данный этап тестирования предназначен для
обнаружения ошибок в оформлении и увеличения эргономичности проекта.
Тестирование пользовательского интерфейса
производилось в нескольких направлениях: стилистическом и эргономическом.
Стилистическое направление тестирования подразумевает контроль за общим стилем
оформления проекта, т.е. за цветовой композицией проекта, упорядоченностью
элементов пользовательского интерфейса и др.
Эргономическое направление отвечает за удобство
работы пользователя, т.е. за соответствие элементов нормам четкости, размера,
смысловой нагрузки и др.
Тестирование проводилось сразу в обоих
направлениях, для достижения максимально эффективного результата, т.к. элемент
соответствующий стилистическим требованиям может не соответствовать требованиям
эргономики. Стилистическое тестирование проводилось с участием коллег по
работе. Так как данные люди обладают минимальными навыками работы с
компьютером. В результате совместного тестирования были выявлены и устранены
следующие ошибки: несоответствие общему стилю оформления ряда элементов
пользовательского интерфейса (изменены размеры, оформление, положение и цвет
элементов), низкий уровень эргономики форм проекта (изменены шрифты и их
размеры, для элементов интерфейса). Тестирование проводилось в визуальной
форме, т.е. путем осмотра каждого элемента формы.
4.3 Тестирование на стадии
реализации
В ходе тестирования программного продукта было
выявлено, что все кнопки работают верно.
4.4 Оценка проекта с точки зрения
заказчика
информатизация проект программа
интерфейс
Так как проект не создавался по реальному
заказу, то пришлось обращаться к коллегам по работе, назначение проекта
соответствует целям, поставленным на начальной стадии разработки и описанным во
введении к пояснительной записке. В проекте выполнены все минимальные
возможности для работы, поэтому ещё остаются ресурсы для его доработки и
добавления новых функций.
4.5 Оценка проекта с точки зрения
разработчика
С точки зрения разработчика проект находится на
ранней стадии развития. Ещё остается обширное поле возможностей для доработки
проекта таких, как улучшение функциональности скрипта, проверка входных данных
усовершенствование интерфейса программы, доработки по составу данных,
добавление механизмов авторизации и аутентификации сотрудника,, расширение
параметров поиска и добавление подробных подсказок для пользователей.
4.6 Назначение программы
Главное назначение программы заключается в
обеспечении Мастера смены удобным средством для хранения, просмотра и
манипулирования информацией о защитных средствах на обслуживаемых объектах
4.7 Требования
Этот пункт посвящается необходимому и
достаточному набору программно-аппаратных средств, без которых приложение
работать не сможет. Обязательно приводится минимальный и рекомендуемый набор.
Для работы программы необходим сервер с WAMP
(Windows+Apache+MySQL+PHP) рассчитанный на несколько рабочих машин(персональных
компьютеров) и браузер
Было проведено тестирование функциональных
возможностей и пользовательского интерфейса проекта.
Произведена оценка проекта с точки зрения
заказчика и разработчика. Определены цели для дальнейшего усовершенствования
проекта.
Приведены требования программных средств.
Проект готов к внедрению в пользовательскую
среду.
Заключение
В курсовой работе была посвящена автоматизации
учета защитных средств. Эта программа производит обработку информации о
наименовании, даты испытаний и местонахождения защитных средств.
Была спроектирована простая в эксплуатации и
обслуживании база данных которая выполняла все требования заказчика.
Разработанный проект позволит освободить
сотрудников Участка электроснабжения от рутинной работы за счет ее
автоматизации, обеспечить пользователей достоверной информацией, заменить
бумажные носители данных на электронные, увеличить эффективность работы
сотрудников и предприятия в целом.
При создании проекта была использована среда
разработки баз данных MySQL на основе реляционных технологий. Применение
методов нормализации позволило устранить дублирование хранимой информации для
дальнейшего проектирования базы данных. При проектировании структуры БД были
рассмотрены все достоинства и недостатки применения нормализации. База данных
была приведена к третьей нормальной форме, которая позволила устранить
избыточность данных.
При создании проекта использованы методы доступа
к базе данных с помощью запросов, что позволяет осуществлять работу сразу в
нескольких направлениях.
Для дальнейшего развития проекта предполагается
добавление некоторых новых возможностей, пересмотр старых вариантов реализации
проекта, изменение некоторых алгоритмов.
Список использованной литературы:
1. Томас,
Бегг, Каролин. Базы данных: проектирование, реализация и сопровождение. Теория
и практика, 2-е изд. - М.: Издательский дом ”Вильямс”, 2011.
. Михайлов
В.В., Савинков В.М. Проектирование баз данных информационных систем. - М.:
Финансы и статистика, 2012. - 351 с.
. Глушаков
С.В., Ломотько Д.В. Базы данных: Учебный курс. - М.: АСТ, 2011.- 504 с.
. Фишер
Дж. Автоматизированное проектирование баз данных. - М.: Мир, 2014. - 294 с.
. Цикритизис
Д., Доховский Ф. Модели данных. - М.: Финансы и статистика, 2014. - 344 с.
6. <http://citforum.ru/cfin/prcorpsys/infsistpr_03.shtml#21>
- Проектирование и разработка корпоративных информационных систем. Центр
Информационных Технологий;
. <http://msdn2.microsoft.com/ru-ru/library/ms345584.aspx>
- Масштабируемые общие базы данных;
. <http://books.kulichki.com/index.php?book=access>;
. Полежаев
С.В., Антонов Д.В. Базы данных. Учебный курс. - Харьков: фолио; Ростов н/Д:
Феникс; Киев: Абрис, 2010;
. Карпова
Т.С. Базы данных. Модели, разработка, реализация - СПб: Питер, 2012;
. Корнеев
В.В. и др. Базы данных.