Информационная система "Учёт комплектующих и ремонта оборудования"

число

дата выполнения

дата выполнения обслуживания оборудования

t_vipolnenie_date

дата

тип обслуживания

код типа обслуживания

t_tip_obsl_id

число

Справочник типов обслуживания

тип обслуживания

код типа обслуживания

t_tip_obsl_id

число

наименование

наименование типа обслуживания

t_tip_obsl_name

строка

Справочник работ

вид работ

код вид работ

t_vid_work_id

число

наименование

наименование вида работ

t_vid_work_ name

строка

Работы _Комплектующие

инвентарный номер

инвентарный номер оборудования

t_obor_invent_id

число

тип обслуживания

код типа обслуживания

t_tip_obsl_id

число

дата выполнения

дата выполнения обслуживания оборудования

t_vipolnenie_ date

дата

деталь/узел

код детали/узла

t_detal_id

число

кол-во

кол-во деталей/узлов

t_kolichestvo

число

Справочник деталей/узлов

деталь/узел

код детали/узла

t_detal_id

число

единица измерения

код единицы измерения

t_ediniza_izm_id

число

наименование

наименование детали/узла

t_detal_name

строка

изготовитель

код изготовителя

t_izgotovitel_id

число

Оборудование _детали/узлы

оборудование

код оборудования

t_obor_id

число

деталь/узел

код детали/узла

t_detal_id

число

кол-во

кол-во деталей/узлов

t_kolichestvo

число

характер обслуживания

характер обслуживания оборудования

t_haracter_ obslygivaniya

строка

Справочник единиц измерения

единица измерения

код единицы измерения

t_ediniza_izm_id

число

наименование

наименование единицы измерения

t_ediniza_izm_ name

строка

аббревиатура

аббревиатура единицы измерения

t_abbr_ed_izm_ name

строка

Вспомогательные материалы

материал

код материала

t_material_id

число

наименование

наименование материала

t_material_name

строка

единица измерения

код единицы измерения

t_ediniza_izm_id

число

изготовитель

код изготовителя

t_izgotovitel_id

число

План использования деталей

оборудование

код оборудования

t_obor_id

число

деталь/узел

код детали/узла

t_detal_id

число

тип обслуживания

код типа обслуживания

t_tip_obsl_id

число

кол-во

кол-во деталей/узлов

t_kolichestvo

число

План использования материалов

оборудование

код оборудования

obor_id

число

материал

код материала

t_material_id

число

тип обслуживания

код типа обслуживания

t_tip_obsl_id

число

кол-во

кол-во материала

t_kolichestvo

число

Обслуживание_ используемые_у злы/детали

инвентарный номер

инвентарный номер оборудования

t_obor_invent_id

число

деталь/узел

код детали/узла

t_detal_id

число

дата выполнения

дата выполнения обслуживания оборудования

t_vipolnenie_ date

дата

тип обслуживания

код типа обслуживания

t_tip_obsl_id

число

кол-во

кол-во деталей/узлов

t_kolichestvo

число

Обслуживание_ используемые_ материалы

инвентарный номер

инвентарный номер оборудования

t_obor_invent_id

число

материал

код материала

t_material_id

число

дата выполнения

дата выполнения обслуживания оборудования

t_vipolnenie_ date

строка

тип обслуживания

код типа обслуживания

t_tip_obsl_id

число

кол-во

кол-во материала

t_kolichestvo

число

Справочник периодичностей обслуживания

периодичность

код периодичности обслуживания

t_period_obsl_id

число

наименование

наименование периодичности обслуживания

t_period_obsl_ name

строка

Периодичность обслуживания

оборудование

код оборудования

t_obor_id

число

тип обслуживания

код типа обслуживания

t_tip_obsl_id

число

периодичность

код периодичности обслуживания

t_period_obsl_id

число

Каждый из атрибутов при преобразовании логической ER-диаграммы в схему базы данных становится колонкой таблицы, с которой связан определённый тип данных. ERWin позволяет указать этот тип данных на диаграмме, однако удобнее определять тип данных атрибута не через простой тип данных, а через его подмножество - домен. Домены для атрибутов создаются в Редакторе словаря доменов(Edit| Domain Dictionary…). Здесь же определяется тип домена(String, Number, Date time, blob) , логические и физические имена. Физические имена в данном проекте содержат префикс «t_», что означает, что это имя типа данных (домена).

Далее в Редакторе атрибутов(Edit|Attribute…) сущностям задаются атрибуты. Здесь же указываются первичные ключи и можно посмотреть внешние ключи.

Затем между сущностями определяются связи. В данном проекте были определены связи следующих степеней: ноль, один или более; один или более; ноль или один. В зависимости от того, являются сущности зависимыми или нет, указывался тип связи: идентифицирующая или не идентифицирующая. Для не идентифицирующей связи была указана обязательность (Nulls). Назначить связи глагольную фразу(Verb Phrase) можно в Редакторе связей (Relationship Editor…).

Так как сущностей и атрибутов достаточно много и модель становится труднообозримой (особенно на уровне атрибутов), то следует разбить её на подмножества - объектные области(Model => Subjects Areas…=> New…). Каждая область будет содержать часть сущностей модели. В каждом из объектов области определены ключи и индексы для обеспечения однозначного определения записей таблиц

Были выделены следующие предметные области (рисунки предметных областей показаны на уровне атрибутов и с установкой ссылочной целостности):

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

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

Справочник оборудования(Sp_Oborydovaniya)-оборудование, имеющееся на предприятии (оно может быть ещё не введено в эксплуатацию). Справочник оборудования связан со Справочником типов оборудования.

Справочник типов оборудования(Sp_Tip_Oborydovaniya). В справочник входят все имеющиеся на предприятии типы, в которые входят единицы оборудования.



Рисунок 5 - Диаграмма предметной области «Учёт оборудования»

Справочник подразделений(Sp_Podrazdeleniy). Справочник состоит из списка ответственных подразделений с указанием их телефона и адреса.

Оборудование _Подразделения(Oborydovaniye_Podrazdeleniya). В данной сущности содержится информация об установленном в конкретном подразделении оборудовании.

Изготовитель(Izgotovitel). Справочник изготовителей оборудования.

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

Сущности:

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

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

Справочник единиц измерения(Sp_Ed_Izmereniya). Справочник единиц измерения категории ремонтной сложности.

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

Рисунок 6 - Диаграмма предметной области «Учёт комплектующих»

План использования деталей/узлов(Plan_isp_detali). Сущность для формирования планов использования деталей/узлов при ремонтообслуживании

План использования вспомогательных материалов (Plan_isp_material). Сущность для формирования планов использования вспомогательных материалов при ремонтообслуживании.

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

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

Диаграмму данной области со всеми сущностями и связями между ними можно посмотреть на рисунке 7. Сущности:

Справочник типов обслуживания(Sp_Tip_Obslygivaniya). В справочник входят типы технического обслуживания и проф. ремонтов.

Оборудование _Обслуживание(Oborydovaniye_Obslygivaniye). Сущность содержит информацию о проведении технического обслуживания и проф. ремонтов с указанием даты обслуживания и его типа.

Справочник периодичностей обслуживания(Sp_Periodichnostey_ Obslygivaniya). Справочник включает в себя все виды периодичностей обслуживания.

Рисунок 7 - Диаграмма предметной области «Ремонтообслуживание»

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

Обслуживание _Используемые детали, узлы(Obslygivanie_Isp_detali_yzli). Здесь указывается информация об использованных при обслуживании запасных частей, а точнее деталей и узлов.

Обслуживание_ Используемые вспомогательные материалы (Obslygivanie_Isp_maerial). Здесь указывается информация об использованных при обслуживании вспомогательных материалах.

Главное подмножество (<Main Subject Area>) ER- диаграммы на уровне «Сущностей» со всеми сущностями модели и связями между ними можно посмотреть в Приложении А, рисунок А1.

Таким образом, полученная на предыдущем этапе модель преобразована в схему БД. Составлены сущности, указаны названия и типы данных атрибутов всех сущностей, а также определены базовые ограничения целостности некоторых атрибутов. Установлены связи между сущностями. Для каждой сущности определен первичный ключ (primary key)[3].

3.2.2 Нормализация БД

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

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

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

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

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

Рисунок 8 - Пример несоответствия 1NF

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

Вторая нормальная форма(2NF). Для соответствия второй нормальной форме отношение, которое находится в первой нормальной форме, в котором каждый атрибут, не входящий в состав первичного ключа, должно являться полностью функционально независимым от любого потенциального ключа. Нормализация отношений 1НФ с приведением к форме 2НФ предусматривает устранение частичных зависимостей, то есть каждый неключивой атрибут должен зависеть только от всего составного ключа, а не от его частей.

Например, в приведённом ниже отношении (рисунок 9) наименование оборудования зависит только от инвентарного номера, но не от местоположения и подразделения.

Подразделение	Местоположение	Инвентарный номер	Наименование оборудования	Изготовитель	Дата установки
СКП	Корпус 5, цех 31	124688	Токарно-винторезный станок	Чувашия, ООО ТЦМ и НТ	12.05.2005

Рисунок 9 - Отношение «Единица оборудования»

Третья нормальная форма(3NF). Отношение, которое находится в первой и во второй нормальных формах и не имеет атрибутов, не входящих в первичный ключ атрибутов, которые находились бы в транзитивной функциональной зависимости ни от одного потенциального ключа. Нормализация отношений 2НФ с образованием отношений 3НФ предусматривает исключение транзитивных зависимостей. На практике это означает, что не должно быть зависимостей между неключивыми атрибутами одного отношения.

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

Четвёртая нормальная форма(4NF). Отношение в нормальной форме Бойса - Кодда, которое не содержит нетривиальных многозначных зависимостей между атрибутами. Нормализация отношения НФБК с получением отношений 4НФ заключается в устранении многозначных зависимостей из отношения НФБК путём выделения в новое отношение одного или нескольких участвующих в многозначной зависимости атрибутов вместе с копией одного или нескольких детерминантов.

Пятая нормальная форма на практике не используется.

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

При разработке ER-диаграммы не требуется декомпозиция универсального отношения и приведения его ко второй и третей нормальной форме. Определение сущностей - это, по сути, приведение универсального отношения к 3NF. Поэтому, можно сказать, что в данной дипломной работе отношения приведены к третей нормальной форме[1,3].

3.3 Физическое проектирование. Выбор сервера

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

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

Выбор именно СУБД InterBase обусловлен следующими фактами:

· Поддерживает архитектуру клиент-сервер.

· Поддерживает процедурное расширение языка SQL.

· Не сложен в установке и настройке.

· Компактен.

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

Что отличает InterBase? Прежде всего, это кросс-платформенность, то есть, переносимость с одной операционной системы на другую. InterBase поддерживает Linux, Windows и значительное количество Unix-платформ. И делает это легко и удобно. Фактически, приложение, которое использует InterBase, не увидит разницы, на какой платформе в данный момент находится сервер. А если захочется поменять платформу, то это не потребует переделки базы данных - достаточно лишь проделать операцию резервного копирования на одной платформе и восстановления копии на другой.

InterBase всегда был инновационным продуктом. Многие технологии, которые сейчас считаются само собой разумеющимися в мире баз данных, впервые появились именно в InterBase. Прежде всего, речь идет о BLOB-полях. Именно в InterBase они впервые появились. Во-вторых, это UDF, то есть, функции, определяемые пользователем. Замечательная возможность расширить набор встроенных функций при помощи любого средства разработки! Сама идеология InterBase - система множественного поколения записей, которая позволяет гарантировать отсутствие блокировок по чтению и быстрое восстановление базы данных при сбоях - это совершенно инновационная технология, которая являлась уникальной с самого начала, да и сейчас, пожалуй, не имеет реальных аналогов. И, наконец - каскадные триггеры. Именно этот механизм, позволяющий создавать очереди автоматически запускающихся триггеров на все виды операций с данными, дает возможность гибко реализовывать практически сколь угодно сложную бизнес-логику.[1]

Многие функции существующих СУБД были впервые реализованы в InterBase.

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

InterBase отличается значительной устойчивостью, поскольку специально был спроектирован для применения в Internet-приложениях, приложениях для мобильных устройств и встроенных приложениях БД[5,7].

3.3.1 Создание базы данных «Учёт комплектующих и ремонта оборудования» на сервере InterBase

Локальный сервер Interbase представляет собой версию Borland Interbase 6.5 Server Edition для одного пользователя, работающую под управлением Windows.

Сервер может использоваться в среде разработчика Delphi для решения ряда задач создания приложений и наборов данных:

1.Под управлением локального сервера Interbase могут создаваться полноценные БД.

2.Проводится тестирование приложений клиент/сервер, причем Interbase используется в качестве модели реального сервера.

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

Рисунок 10 - Графическая утилита IBConsole

Для того чтобы создать базу данных, необходимо сначала подключится к Interbase серверу. Для этого запускается утилита InterBase IBConsole (рисунок 10).

Чтобы программа IBConsole могла работать с сервером, он должен быть зарегистрирован (Server | Register).Для этого необходимо в появившемся диалоговом окне в верхней части выбрать пункт Local Server. Затем, в поле User Name и Password указать имя пользователя и пароль, SYSDBA и masterkey соответственно, под которыми можно работать на сервере. Эти данные вводятся по умолчанию (рисунок 11). Для работы с сервером необходимо создать нового пользователя, пусть это будет пользователь `BD' с паролем `bd' (Server|User Security…=>New). Пользователи, определённые на сервере, имеют доступ ко всем базам, определённым на данном сервере, однако для доступа к данным необходимо ещё иметь разрешение на пользование таблицами базы. Возможность подключения к базе ничего не даёт, если у вас нет доступа к таблицам этой базы. А входящие в базы данных таблицы имеют свою дополнительную систему разрешений.

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

Рисунок 11- Диалоговое окно регистрации и подключения

После этого в поле Database Options вводятся параметры базы данных «Default Character Set WIN1251» (рисунок 10). Эта строка необходима, для того, чтобы в базе данных можно было сохранять строковые данные, содержащие символы кириллицы. После нажатия на кнопку «OK», эта программа создаст файл базы данных с именем Diplom.gdb.

Для работы с базами данных в составе IBConsole имеется дополнительный инструмент - программа для интерактивной работы с SQL-запросами Interactive SQL(Tools| Interactive SQL…)

В базе данных Diplom.gdb. создаются таблицы, которые были спроектированы в пункте 3.2.2, а именно:

* справочники «Оборудования», «Подразделений», «Типов оборудования», «Изготовителей», «Типов обслуживания», «Узлов/Деталей», «Вспомогательных материалов», «Единиц измерения», «Периодичностей обслуживания»;

* таблицы «Оборудование_Подразделения», «Оборудование_Обслуживание», «Оборудование_Узлы/Детали», «Обслуживание_Используемые_Узлы/Детали», «Обслуживание_Используемые_Материалы», «Периодичность_Обслуживания»;

* планы использования Узлов/Деталей и использования материалов;

* таблица «Пользователи».

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

Ниже перечислены типы данных доступные в SQL инструкциях InterBase:

BLOB - Большой двоичный объект. Сохраняет данные большого объема, такие как графика, текст и цифровой звук.

CHAR - Фиксированной длины CHAR или строка текста.

DATE - Дата.

DECIMAL - Сохраняет числа точно в следующем формате: ppppppp.sss

DOUBLE PRECISION - Для научных вычислений: 15 цифр точности.

FLOAT - Одиночная точность: 7 цифр точности.

INTEGER - Длинное целое со знаком (long, longword).

NUMERIC - Сохраняет числа точно в следующем формате: ppppppp.sss

SMALLINT - Короткое целое со знаком. (shot, word).

VARCHAR - Переменной длины CHAR или строка текста.

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

Структуры таблиц, домены, хранимые процедуры, роли и тени - это данные об объектах базы данных. Такие объекты создаются при помощи запросов языка определения данных - DDL (data definition language). DDL - это часть языка SQL, и объекты, создаваемые с помощью DDL, называются метаданными. Запросы DDL всегда начинаются со слов CREATE, ALTER или DROP.

Далее приводятся примеры текстов запросов:

Ш создание доменов:

CREATE DOMAIN T_COMMENTS AS VARCHAR (150) CHARACTER SET WIN1251;

CREATE DOMAIN T_IZGOTOVITEL_ID AS INTEGER NOT NULL;

CREATE DOMAIN T_KAPREM_LAST_DATE AS TIMESTAMP NOT NULL;

CREATE DOMAIN T_MESTOPOLOGENIE AS CHAR (50) CHARACTER SET WIN1251 NOT NULL;

CREATE DOMAIN T_OBOR_ID AS INTEGER NOT NULL;

CREATE DOMAIN T_OBOR_INVENT_ID AS INTEGER NOT NULL;

CREATE DOMAIN T_OBOR_NAME AS CHAR (50) CHARACTER SET WIN1251 NOT NULL;

CREATE DOMAIN T_PODRAZDELENIE_ID AS INTEGER NOT NULL;

CREATE DOMAIN T_PRODUCTION_DATE AS TIMESTAMP NOT NULL;

CREATE DOMAIN T_TIP_OBOR_ID AS INTEGER NOT NULL;

CREATE DOMAIN T_TIP_OBSL_ID AS INTEGER NOT NULL;

CREATE DOMAIN T_TO_LAST_DATE AS TIMESTAMP NOT NULL;

CREATE DOMAIN T_VIPOLNENIE_DATE AS TIMESTAMP NOT NULL;

CREATE DOMAIN T_VVOD_V_EXSP_DATE AS TIMESTAMP NOT NULL.

Остальные домены создаются аналогично.

Ш создание таблиц (на примере таблиц «Оборудование_Подразделения», справочника «Оборудование» и «Оборудование_Обслуживание»)

CREATE TABLE OBORYDOVANIYE_PODRAZDELENIYA (

PODRAZDELENIE_ID T_PODRAZDELENIE_ID NOT NULL,

OBOR_INVENT_ID T_OBOR_INVENT_ID NOT NULL,

OBOR_ID T_OBOR_ID,

IZGOTOVITEL_ID T_IZGOTOVITEL_ID,

PRODUCTION_DATE T_PRODUCTION_DATE,

VVOD_V_EXSP_DATE T_VVOD_V_EXSP_DATE,

KAPREM_LAST_DATE T_KAPREM_LAST_DATE,

TO_LAST_DATE T_TO_LAST_DATE,

MESTOPOLOGENIE T_MESTOPOLOGENIE,

COMMENTS T_COMMENTS,

CONSTRAINT PK_OBORYDOVANIYE_PODRAZDELENIYA PRIMARY KEY (PODRAZDELENIE_ID, OBOR_INVENT_ID));

CREATE TABLE SPRAVOCHNIK_OBORYDOVANIYA (

TIP_OBOR_ID T_TIP_OBOR_ID NOT NULL,

OBOR_ID T_OBOR_ID NOT NULL,

OBOR_NAME T_OBOR_NAME,

PRIMARY KEY (OBOR_ID));

CREATE TABLE OBORYDOVANIE_OBSLYGIVANIE (

OBOR_INVENT_ID T_OBOR_INVENT_ID NOT NULL,

PODRAZDELENIE_ID T_PODRAZDELENIE_ID NOT NULL,

TIP_OBSL_ID T_TIP_OBSL_ID NOT NULL,

VIPOLNENIE_DATE T_VIPOLNENIE_DATE NOT NULL,

PRIMARY KEY (OBOR_INVENT_ID, PODRAZDELENIE_ID, VIPOLNENIE_DATE));

ALTER TABLE OBORYDOVANIE_OBSLYGIVANIE ADD FOREIGN KEY (TIP_OBSL_ID) REFERENCES SP_TIP_OBSLYGIVANIYA (TIP_OBSL_ID);

Аналогично создаются и остальные таблицы.

Сервер InterBase следует расширенному синтаксису SQL-92 и способен защищать таблицы базы данных от несанкционированного доступа на основе прав и ролей. Сразу после создания таблицы правом неограниченного её использования обладает её собственник(то есть создавший её пользователь, в данном случае это пользователь BD) и системный администратор SYSDBA. Любой из них может передавать некоторые (или все) права владения таблицей другому пользователю или группе пользователей.

Для передачи прав используется запрос:

GRANT DELETE, INSERT, SELECT, UPDATE, REFERENCES ON OBORYDOVANIYE_PODRAZDELENIYA TO OLGA;

Здесь пользователю Ольга передаются все права, кроме прав Execute и Role на пользование таблицей Установленного оборудования.

Если права передаются любому пользователю, указывается зарезервированное слово PUBLIC.

Сервер позволяет устанавливать права на конкретные столбцы, отбирать права. Можно создать также именованный набор прав (роли), передать созданной роли права, а затем выделить конкретному пользователю ту им иную роль. Права доступа к таблицам InterBase можно посмотреть в таблице 3.

Таблица 3 - Права доступа к таблицам InterBase

Право	Описание
All	Все права, кроме прав Execute и Role
Select	Право чтения данных
Delete	Право уничтожения данных
Insert	Право записи новых данных
Update	Право изменения существующих данных
Execute	Право вызова хранимой процедуры
References	Право установления реляционного отношения
role	Все права, связанные с данной ролью

На сервере были созданы несколько пользователей с разными ролями и соответственно разными правами.

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

gbak -b - user SYSDBA-password master key d:\Diplom\Diplob.gdb c:\Database\db.gbk

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

gbak {-C|-R} [options] <файл _ резервной _ копии _источник>

<файл создаваемой базы данных>

Создавая таблицу, предполагается, что к хранящимся в ней данным будут обращаться. Причём в некоторых случаях может понадобиться в ней, что-то найти, иногда просмотреть её записи, упорядочив их по какому-нибудь признаку. Для ускорения операций поиска и сортировки SQL-сервера предусматривают механизм, называемый индексом. Сервер InterBase автоматически генерирует уникальные индексы для первичных ключей, но поиск может проводиться не только по полям, заданным в качестве первичного ключа, но и по другим (на усмотрение разработчика базы). Например, в справочнике «Оборудования» поиск производится также и по полю наименования оборудования(OBOR_NAME). Для этих целей создан дополнительный индекс:

CREATE INDEX IND_obor_name ON Sp_Oborydovaniya(obor_name).

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

Выполняя запросы на сервере, создаются, изменяются или удаляются какие-нибудь данные. Изменение данных на сервере производятся в виде транзакций.[2]

По умолчанию каждый запрос является отдельной транзакцией. Транзакция считается выполненной только после специального подтверждения (commit), до этого результаты ее не видны другим пользователям. Неподтвержденная транзакция является активной. Для подтверждения изменений, сделанных в рамках транзакции, существует специальный запрос COMMIT. В то же время, когда создаются метаданные, удобнее, если каждый запрос закрывался сразу же после выполнения. Для этого в программе Interactive SQL имеется специальный режим «Autocommit». В этом режиме все запросы DDL сразу же закрываются и становятся видимыми всем пользователям.

В СУБД InterBase процедура хранится непосредственно в базе данных и контролируется ее администратором. Она имеет параметры и возвращает значение. Процедура базы данных создается оператором CREATE PROCEDURE (СОЗДАТЬ ПРОЦЕДУРУ) и содержит определения переменных, операторы SQL (например, SELECT, INSERT), операторы проверки условий (IF/THEN/ELSE) операторы цикла (FOR, WHILE), а также некоторые другие.

Таким способом, в разрабатываемом приложении базы данных «Учет комплектующих и ремонт оборудования», созданы хранимые процедуры для вставки, изменения, удаления записей и процедуры извлечения из базы данных информации о типе данных по его коду. Ниже приведены хранимые процедуры, созданные для таблицы «Тип оборудования»(Sp_Tip_Oborydovaniya):

/* процедура удаления записи /*

SET TERM ^;

CREATE PROCEDURE DEL_TIP_OBOR (TIP_OBOR_ID INTEGER) AS

Begin

Delete from sp_tip_oborydovaniya

Where tip_obor_id=:tip_obor_id;

Suspend;

End^

SET TERM; ^

/* извлечения из базы данных информации о типе данных по его коду /*

SET TERM ^;

CREATE PROCEDURE GET_TIP_OBOR (V_TIP_OBOR_ID INTEGER)

RETURNS (TIP_OBOR_NAME CHAR (50))

AS

Begin

SELECT tip_obor_name FROM sp_tip_oborydovaniya

WHERE tip_obor_id=:v_tip_obor_id

INTO: tip_obor_name;

Suspend;

Suspend;

End^

SET TERM; ^

/* процедура вставки записи /*

SET TERM ^;

CREATE PROCEDURE INS_TIP_OBOR (TIP_OBOR_NAME CHAR (50))

AS

Begin

Insert into sp_tip_oborydovaniya (tip_obor_name)

Values (:tip_obor_name);

Suspend;

End^

SET TERM; ^

/* процедура изменения записи /*

SET TERM ^ ;

CREATE PROCEDURE UPD_TIP_OBOR (TIP_OBOR_NAME CHAR (50), TIP_OBOR_ID INTEGER)

AS

Begin

Update sp_tip_oborydovaniya set

tip_obor_name=: tip_obor_name

Where

tip_obor_id=: tip_obor_id;

suspend;

end^

SET TERM; ^

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

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

Для такого механизма необходимы два компонента: генератор уникального значения и триггер, который присваивал это значение при вставке новой записи. Для создания генератора необходимо выполнить запрос CREATE GENERATOR, а для присвоения уникального значения первичному ключу - создать триггер типа BEFORE INSERT.

Например, если таблица Sp_Tip_Oborydovaniya содержит поле tip_obor_id, значение которого должен задавать генератор, то имя поля этого генератора будет GEN_SCET_ID. Запрос на создание генератора для этого поля будет иметь вид

CREATE GENERATOR TIP_OBOR_ID_GEN;

А запрос для создания триггера будет иметь вид:

SET TERM!! ;

CREATE TRIGGER tip_obor_id_gen FOR Sp_Tip_Oborydovaniya

BEFORE INSERT AS

BEGIN

new. tip_obor _id = gen_id(tip_obor _id_gen, 1);

END!!

SET TERM;!!

Подобные SQL-запросы созданы для каждой таблицы базы данных «Учет комплектующих и ремонт оборудования», имеющей автоинкрементный ключ.

Все эти технологии, объединенные с простотой установки и конфигурировании SQL-сервера, делают Borland InterBase чрезвычайно мощным и удобным в работе сервером[3,5].

4. Структура и основные функции информационной системы

4.1 Выбор инструментальной среды (реализация информационной системы)

Клиентское приложение разработано в среде объектно-ориентированного программирования Delphi 7.0.

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

Delphi - это достаточно новый продукт Borland International для быстрого создания приложений (RAD). Это высокопроизводительный инструмент визуального построения приложений, работающих с базами данных в архитектуре клиент-сервер, Internet / Intranet, а также для локальных машин и файл - серверной архитектуры. Этот инструментарий включает в себя настоящий компилятор кода и предоставляет средства визуального программирования, несколько похожие на те, что можно обнаружить в Microsoft Visual Basic или в других инструментах визуального проектирования. В основе Delphi лежит язык - Object Pascal, который является расширением объектно-ориентированного языка Pascal. Поскольку в архитектуре клиент-сервер де-факто сложилось такое положение, что клиентские станции работают, как правило, в Windows-среде, а SQL-сервер - в операционной системе UNIX, Delphi Client-Server может служить удобным инструментом для скоростной разработки приложений.

Мощность и гибкость Delphi при работе с базами данных основана на низкоуровневом ядре - процессоре баз данных Borland Database Engine (BDE) позволяет осуществлять доступ к данным как с использованием традиционного record-ориентированного (навигационного) подхода, так и с использованием set-ориентированного подхода, используемого в SQL-серверах баз данных. Все инструментальные средства баз данных Borland - Paradox, dBase, Database Desktop - используют BDE. Все особенности, имеющиеся в Paradox или dBase, “наследуются” BDE, и поэтому этими же особенностями обладает и Delphi[6].

Преимущества Delphi по сравнению с аналогичными программными продуктами:

· Быстрота разработки приложения.

· Высокая производительность разработанного приложения.

· Низкие требования разработанного приложения к ресурсам компьютера.

· Наращиваемость за счет встраивания новых компонент и инструментов в среду Delphi.

· Возможность разработки новых компонент и инструментов собственными средствами

· Удачная проработка иерархии объектов

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

- Доступ через Borland Database Engine (BDE).

- Механизм доступа через ActiveX Data Objects (ADO).

- Механизм DBExpress.

- InterBase Express (IBX).

При конструировании приложения базы данных «Учёт комплектующих и ремонта оборудования» был выбран механизм BDE. Главное удобство BDE в том, что все связанные с базой данных настройки находятся отдельно от клиентского приложения. Программисту можно вообще о них не задумываться - достаточно указать некоторое условное имя, и программа сама найдёт и включит связанные с ним настройки. Это условное имя называется альясом.

Таким образом, чтобы программа могла манипулировать данными из базы, в первую очередь необходимо настроить BDE: создать альяс и связать его с базой данных. Разработчики Delphi предусмотрели для этого специальную утилиту - BDE Administrator(Пуск |Программы |Borland Delphi 7| BDE Administrator).

В программе BDE Administrator создан альяс “DIPLOM” , связанный с созданной ранее базой данных DIPLOM.GDB (Приложение А, рисунок А2).

Компоненты доступа по механизму BDE находятся на страничке палитры «BDE».

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

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

procedure StartTransaction;

При необходимости сохранить все сделанные в рамках текущей транзакции изменения используется метод procedure Commit;

Если выполненные действия нужно отменить, применятся метод procedure Rollback.

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

Класс TDataSet является базовым классом иерархии, он инкапсулирует абстрактный набор данных и реализует максимально общие методы работы с ним. В него можно передать записи из таблицы базы данных. На основе базового класса реализованы специальные компоненты для доступа к данным. К ним относятся: TDataSet, TTable, TQuery, TStoredProc.

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

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

SELECT * FROM OBORYDOVANIYE_PODRAZDELENIYA TO OLGA;

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

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

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

Компонент TDataSet предназначен для представления в приложении наборов данных от сложных запросов. При этом набор данных остается редактируемым. Это достигается возможностью задать дополнительные запросы на удаление, изменение и добавление данных. Аналогичным образом работает стандартный компонент TUpdateSQL. Однако в компоненте TDataSet интегрированы одновременно и сам основной запрос, и вспомогательные запросы.

Большинство приложений имеет главное меню, содержащее перечень допустимых операций. Пункты главного меню иначе называют еще элементами меню нулевого (верхнего) уровня, поскольку с каждым из них может быть связано выпадающее подменю, содержащее элементы меню первого уровня и т. д. Кроме того, с каждым элементом меню может быть связана некоторая процедура, которая будет выполняться при щелчке мышью по элементу меню. В Delphi для создания главного меню имеется не визуальный компонент TMainMenu. («Standard»). В приложении создано главное меню, содержащее элементы , представленные в (Приложение Б, рисунок Б1). Это меню находится на первой форме приложения. С помощью его пунктов можно вызвать ту форму, которую необходимо, предварительно описав процедуры, которые будут связаны с тем или иным пунктом подменю.

Средства Delphi имеют несколько стандартных компонентов для работы с наборами данных, описанные выше. Источник данных (data source) представляет собой промежуточный элемент, который применяется для связи набора данных с визуальными компонентами. Получается как бы цепочка: «набор данных - источник данных - визуальный компонент».

Для этой цели в Delphi служит компонент DataSource. Указанный компонент имеет свойство DataSet. Оно служит для указания набора данных, с которым связан источник данных. Отметим, что визуальные компоненты для связи с источником данных используют свойство DataSource. Таким образом, в клиентском приложении для связи набора данных с визуальными компонентами DBGrid, DBEdit, DBLookupComboBox используется компонент DataSource.

Для работы с таблицами базы данных используются компоненты Transaction, Database, Table, StoredProc, описанные выше. Для этих компонент устанавливаются соответствующие свойства в «Инспекторе объектов».

Для доступа к данным задействованы такие компоненты как TQuery, TDataSource, TUpdateSQL. Для осуществления ввода информации в таблицfах базы данных, используются визуальные компоненты: TDateTimePicker - ввод даты и времени.

TEdit - ввод текста.

TDBLookupComboBox - список синхронного просмотра (выпадающий список).

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

TDBNavigator - перемещение или навигация по набору данных, например в компоненте TDBGrid.

TBitBtn - кнопка.

Так как в таблицы базы данных будет осуществляться ввод новых записей, то необходимо обеспечить присвоение значениям полям первичных индексов. При сохранении новой записи поле первичного индекса будет инкрементировано средствами InterBase (соответствующими триггером и генератором). Чтобы получить это значение в приложении в компоненте TQuery используется свойство GeneratorField. В редакторе этого свойства задается нужный генератор базы данных, указывается шаг прибавляемого значения и инкрементируемое поле набора данных. В свойстве Update Object, компонента TQuery, указывается компонент TUpdateSQL для редактирования записей.

Для компонента TUpdateSQL генерируются SQL-запросы на вставку, добавление, обновления и удаления информации о проводке в свойствах DeleteSQL, InsertSQL, ModifySQL, RefreshSQL.

Так же в приложении создаются отчеты. Для их создания используются компоненты с вкладки QReport. Компонент QuickRep - является базовым компонентом отчета. Данный компонент представляет собой форму для создания вида отчета, с его помощью можно размещать полосы, которые являются основными элементами отчета. Отчет связывается с наборами данных TQuery, для которого он создается, с помощью компонента DataSet. Следующий компонент, который используется при создании отчета, это QRBand. Он представляет собой простую полосу отчета, на которой могут размещаться другие компоненты, такие как: QRLabel - служит для размещения любого текста, QRDBText - позволяет отображать текстовые данные, связанные с содержимым одного из полей набора данных, в отчете. Свойство DataSet дает возможность связать компонент с набором данных. После выбора значения этого свойства можно выбрать название поля набора данных, делается это с помощью свойства DataField.

В приложении реализованы поиск данных (с помощью метода Locate) и фильтрация данных (с помощью свойства компонента Query - Filter)[3,6].

4.2 Структура программной системы

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

Программа должна обладать неким общим планом, по которому бы строилось программное приложение. Основным принципом такого плана является модульность. Это означает, что приложение должно состоять из отдельных программных частей, выделенных по некоторому признаку. В среде Delphi уже заложено деление по «формам» - программным окнам, причем каждой форме соответствует свой собственный программный модуль - unit. В тоже время, при компиляции и сборке программы все эти модули объединяются в один исполняемый файл.

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

uMain - модуль главной формы программы;

uLogin - модуль формы авторизации пользователя (ввод пароля и логина);

uYstObor - модуль содержащий информацию об установленном в конкретном подразделении оборудовании.

uRedInsYstObor - модуль для добавления нового оборудования в подразделение и редактирования уже имеющейся информации об установленном оборудовании.

uYstYzDet - модуль содержащий информацию об установленных узлах/деталях и их и количественном составе на конкретной единице оборудования.

uRedInsYstYzDet - модуль для добавления новых узлов/деталей на единицу оборудования и редактирования уже имеющейся информации об установленных узлах/деталях.

uPrRem - модуль содержащий информацию о уже проведённых ремонтных работах.

uOPrRem - печать выполненных работ на заданный период по наименованию оборудования

uPlRem - модуль содержащий информацию о планируемых ремонтных работах.

uOPlRem - печать информации о планируемых ремонтных работах.

uPlIspDY -модуль планирования использования узлов/деталей при дальнейшем обслуживании.

uPlIspMat -модуль планирования использования вспомогательных материалов пр...