Учебная работа. Курсовая работа: Контроль и учет технического состояния магистральных трубопроводов транспортирующих огнеопасные продукты

Учебная работа. Курсовая работа: Контроль и учет технического состояния магистральных трубопроводов транспортирующих огнеопасные продукты

ЗАДАНИЕ

на курсовую работу

I. Тема работы: Контроль и учет технического состояния магистральных трубопроводов, транспортирующих огнеопасные продукты.

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

III. Объём и содержание проекта (графических работ 2 листа). база данных, и программное средство, состоящее из программки взаимодействующей с базой. Объяснительная записка, содержащая: введение, аналитическую часть, описывающую главные концепции разработки баз данных, конструкторскую и технологическую часть описывающих архитектуру программного средства и работу с ним, заключение и перечень литературы.

Оглавление

ВВЕДЕНИЕ
1 АНАЛИТИЧЕСКАЯ часть
1.1 Постановка задачки
1.2 Сути, дела и их характеристики
1.3 Условия целостности
1.4 Обычные формы таблиц
1.5 бизнес правила
1.6 Требования к БД
2 КОНСТРУКТОРСКАЯ часть
2.1 Структура системы
2.2 Проектирование базы данных
2.3 Хранимые процедуры
2.4 Запросы
2.5 Выбор модели базы данных
2.6 Организация взаимодействия с юзером
3 ТЕХНОЛОГИЧЕСКАЯ часть
3.1 Выбор средства разработки
3.2 Выбор СУБД
3.3 Описание системы
3.4 Синхронизация при работе в сети
3.5 Технические свойства программки
4 ИССЛЕДОВАТЕЛЬСКАЯ часть
ЗАКЛЮЧЕНИЕ
СПИСОК ЛИТЕРАТУРЫ
приложение 1

ВВЕДЕНИЕ

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

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

· удачный и малогабаритный метод хранения данных;

· возможность многопользовательского доступа упрощающего формирование базы данных;

· возможность удаленного доступа;

· возможность построения систем поисков, сортировок и, как следует, повышение скорости работы с большенными массивами документов.

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

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

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

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

1 АНАЛИТИЧЕСКАЯ ЧАСТЬ

1.1 Постановка задачки

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

· Детальная разработка структуры базы данных и ее главных связей;

· анализ имеющихся СУБД. Выбор одной СУБД, отвечающей требованиям надежности и имеющие нужны для сотворения таковой системы инструментарий;

· Создание базы данных.

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

· доступ к базе через локальную вычислительную сеть;

· редактирование данных в базе;

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

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

1.2 Сути, дела и их характеристики

При описании предметной области исходя из убеждений концептуальной модели, до этого всего, следует найти сути, принадлежащие данной для нас области, и связи меж ними. Под сутью, в таком подходе, понимается то, о чем обязана скапливаться и обрабатываться информация. К примеру, при разработке схемы функционирования факультета сущностями могут выступать студенты факультета, педагоги, читаемые предметы, методический и научно-исследовательский материал, разрабатываемый факультетом, семинары и конференции, проводимые на данном факультете и так дальше. Любая суть характеризуется при помощи ограниченного набора параметров и связей с иными сущностями. Группа сущностей, характеризующаяся одним и этим же набором параметров, образует набор сущностей. Так, к примеру, перечень студентов образует набор сущностей, который мы назовем СТУДЕНТ, и он будет характеризоваться последующими качествами: фамилия, имя и отчество; номер студенческого билета; группа; пространство жительства; год поступления; наличие либо отсутствие стипендии и тому схожее. характеристики набора сущностей именуют атрибутами, а огромное количество допустимых значений атрибутов именуют доменом. Исходя из убеждений датологической модели при описании атрибутов всякого из набора сущностей, следует указать не только лишь имя атрибута, да и тип данных, описывающих данный атрибут. Тип данных, применяемых при описании атрибута, зависит от того смысла, который вкладывается в этот атрибут при проектировании модели объектной области. К примеру, если в наборе объектов СТУДЕНТ атрибут «стипендия» охарактеризовывает лишь ее наличие либо отсутствие, другими словами домен этого атрибута состоит всего только из 2-ух значений, то для его описания следует применять логический тип. Если же этот атрибут обрисовывает настоящее к примеру, рядовая, завышенная, именная и так дальше, то тип данных, отвечающих такому атрибуту, следует задать литерным.

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

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

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

Связь меж наборами объектов быть может 3-х типов. 1-ый тип – связь один к одному (обозначение 1:1), когда меж записями 2-ух наборов сущностей устанавливается связь, характеризующаяся взаимно конкретным соответствием меж сущностями, входящими в любой из наборов. к примеру, если один из наборов сущностей – это номера проданный на данный рейс билетов, а иной – это перечень пассажиров, то связь меж ними будет один к одному. При нарушении этого принципа должен выдаваться сигнал ошибки, потому что на одно и то же пространство будет продано несколько билетов. 2-ой тип связи – это один ко почти всем (1:М), либо оборотный вариант – почти все к одному (М:1). к примеру, если один набор сущностей это клиенты некого банка, а иной – счета банка, то если у клиента в банке допускается несколько счетов, то будет установлена связь один ко почти всем. В случае, когда первичным рассматривается счет, то связь будет трактоваться как почти все к одному. 3-ий вид связи – это почти все ко почти всем (M:N), когда нескольким записям 1-го набора сущностей соответствует несколько записей другого набора. В качестве примера можно разглядеть перечень студентов некого факультета и перечень предметов, читаемых на этом факультете. Связь меж этими наборами сущностей будет как раз определяться как почти все ко почти всем, при этом она усложнится, если для студентов на факультете допускается некий выбор изучаемых предметов.

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

1.3 Условия целостности

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

· категорийная целостность;

· ссылочная целостностью

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

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

1.4 Обычные формы таблиц

1-ая обычная форма.

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

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

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

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

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

2-ая обычная форма.

Для определения 2-ой обычной формы нужно ввести теорию многофункциональной зависимости. Это зависимость, связывающая атрибуты в одной таблице с единственным значением в иной таблице. Многофункциональную зависимость для таблиц А и В принято обозначать как А—В. Это понятие подводит «на один шаг» к схожей концепции объединения таблиц в дела типа 1:1 либо 1:М.

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

Избыточность 1НФ может послужить предпосылкой появления заморочек и при удалении либо добавлении. Аномалия вставки может проявиться в том случае, когда при добавлении в таблицу с первичным ключом какой-нибудь записи вы обязаны поместить в поле первичного ключа или пустое, или уже имеющееся

3-я обычная форма.

Если A является элементом кандидатного ключа, то будем именовать A первичным атрибутом. Под очевидной многофункциональной зависимостью тут понимается зависимость типа xA -> A. Эта зависимость элементарна, так как Х не воспринимает роли в идентификации первичного атрибута, только предполагается в его определении.

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

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

Таблица Х представлена в обычной форме Бойса-Кодда (БКНФ), если в каждой нетривиальной многофункциональной зависимости В -> А, В является суперключом.

Уместно создать несколько замечаний о недочетах, присущих даже таблицам, представленным в ЗНФ. Есть варианты, когда имеет смысл поделить таблицу на наиболее маленькие таблицы, если часть представленных в ней данных непостоянна и нередко обновляется, а другие данные пассивны и меняются в редчайших вариантах. Также есть смысл соединить таблицы, когда нужно обеспечить высшую быстроту реакции на запрос. Можно даже пойти на дублирование данных в таблицах, если это дозволит понизить Издержки на обработку запросов, хотя формально не следовало бы этого созодать. время от времени приходится отойти от принципа полной нормализации данных проекта. Это быть может вызвано последующими причинами:

· временем выполнения запросов;

· временем проведения обновлений;

· общим нужным объемом хранилища данных;

· аномалиями удаления, которые могут вызвать утрату целостности данных.

И ЗНФ и БКНФ являются теоретическими конструкциями, в то время как большая часть разрабов баз данных работают в настоящем мире.

4-ая и 5-ая обычные формы.

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

Неоднозначная зависимость определяется последующим образом.

В таблице Х существует неоднозначная зависимость А -> В, если в данной для нас таблице можно найти ситуации, в каких пара строк содержит дублирующееся

До этого всего, для существования неоднозначной зависимости требуется существование пар строк. А и В могут быть как отдельными атрибутами, так и объединением некого набора атрибутов. Очевидная неоднозначная зависимость для А -> В существует в случае, когда В является подмножеством А либо А соединяет воединыжды B = xS (наиболее большая таблица содержит начальную таблицу). Существование неоднозначной зависимости порождает аномалию обновления. 4-ая обычная форма избавляет нетривиальную неоднозначную зависимость в таблице средством сотворения наименьших таблиц. процесс нормализации представляет собой создание как можно большего числа все наиболее маленьких таблиц в целях сокращения избыточности данных.

Определим четвертую нормальную форму.

Таблица Х представлена в 4НФ и тогда лишь тогда, когда она представлена в БКНФ и для хоть какой неоднозначной зависимости А -> В в данной для нас таблице можно сказать, что эта зависимость или является очевидной, или А является суперключом таблицы X.

И крайнее. Разглядим пятую нормальную форму.

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

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

1.5 бизнес правила

I. Факты

· При разработке трубопровода создается участок трубопровода.

II. Ограничения

· юзер не может удалить участок трубопровода, если их количество не превосходит 1-го.

· Юзер не может сохранить конфигурации в базе пока не введет все нужные данные.

III. Активаторы

· Если срок эксплуатации участка трубопровода вышел, то нужно уведомить юзера о этом.

· Если в базе хранятся не все нужны данные о трубопроводе, то нужно уведомить юзера о этом.

IV. Вывод

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

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

V. Вычисления

· Общая длина трубопровода рассчитывается как сумма длин участков трубопровода.

· При вводе даты крайнего обследования и выбора периодичности обследования, рассчитывается дата последующего обследования.

1.6 Требования к БД

· доступ через локальную вычислительную сеть;

· вся информация обязана представляться в определенном виде в согласовании с разработанной структурой;

· в БД должен предусмотрен поиск;

· в качестве малых входных данных должны рассматриваться:

— вид трубопровода;

— тип трубопровода;

— наименование трубопровода.

· предупреждать юзера если он не ввел все данные о трубопроводе либо участке трубопровода;

· выдавать сообщения юзеру о более принципиальных конфигурациях в состоянии трубопровода и не введенных более принципиальных данных.

2 КОНСТРУКТОРСКАЯ часть


2.1 Структура системы

Для реализации поставленной задачки нужно создать три подсистемы:

· подсистема хранения данных;

· подсистема доступа к базе данных;

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

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

2.2 Проектирование базы данных

Для реализации поставленной задачки нужно сделать таблицы:

· «Трубопроводы»,

· «Участки трубопроводов»,

· «Примечание»,

· «Обследование с целью продления срока службы»,

· «Ремонт на участках»,

· «Ревизия участков трубопроводов»,

· «Диагностика участков трубопроводов»,

· «Испытание участков трубопроводов»,

· «Отказы на участках».

«Трубопроводы». В данной для нас таблице хранятся главные данные.

— «Вид».

— «Наименование трубопровода». Значением этого атрибута является заглавие трубопровода, задаваемое юзером.

— «Наименование начала полосы(трубы)». Значением этого атрибута является заглавие начала полосы, задаваемой юзером.

— «№ точки подключения». Значением этого атрибута является номер точки подключения, задаваемой юзером.

— «Наименование конца полосы(трубы)». Значением этого атрибута является заглавие конца полосы, задаваемой юзером.

— «Количество отказов». Значением этого атрибута является числовое

— «Категория трубопровода». Значением этого атрибута является категория трубопровода, избираемая юзером из справочника «Категория трубопровода».

— «Транспортируемый продукт». Значением этого атрибута является транспортируемый продукт, избираемый юзером из справочника «Транспортируемые продукты».

— «Регистрационный № ФСТН». Значением этого атрибута является номер регистрации в ФСТН, который выдается при регистрации объекта.

— «Дата регистрации в ФСТН». Значением этого атрибута является дата регистрации в ФСТН.

— «Регистрационный № СТН(ОТН)». Значением этого атрибута является номер регистрации в СТН, который выдается при регистрации объекта.

— «Дата регистрации в СТН(ОТН)». Значением этого атрибута является дата регистрации в СТН.

— «Регистрационный № СПК». Значением этого атрибута является номер регистрации в СТН, который выдается при регистрации объекта

— «Дата регистрации в СПК». Значением этого атрибута является дата регистрации в СПК.

— «Дата снятия с регистрации в ФСТН». Значением этого атрибута является дата снятия с регистрации в ФСТН.

— «Дата снятия с регистрации в СТН(ОТН)». Значением этого атрибута является дата снятия с регистрации в СТН.

— «Дата снятия с регистрации в СПК». Значением этого атрибута является дата снятия регистрации в СПК.

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

— «Месторождение». Значением этого атрибута является наименования месторождение, выбираемое юзером из справочника «Месторождения».

— «Пространство установки». Значением этого атрибута является наименование компании, где установлен трубопровод.

— «Отношение к ОПО». Значением этого атрибута является наименование небезопасных промышленных объектов, который выбирается юзером.

— «Обладатель». Значением этого атрибута является наименование обладателя компании которому принадлежит трубопровод.

— «Доборная информация». Значением этого атрибута является доп сведения о трубопроводе, вводимые юзером.

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

— «Трубопровод». Значением этого атрибута является указатель на трубопровод к которому принадлежит примечание.

— «Наименование участка». Значением этого атрибута является заглавие участка трубопровода, задаваемое юзером.

— «Дата врезки». Значением этого атрибута является дата, когда была осуществлена врезка трубопровода.

— «Протяженность (м)». Значением этого атрибута является протяженность участка трубопровода.

— «Марка стали, ГОСТ либо ТУ». Значением этого атрибута является марка стали из которой изготовлен трубопровод.

— «Внешний поперечник (мм)». Значением этого атрибута является внешний поперечник трубопровода.

— «Рабочее давление, кгс/кв.см(Мпа)». Значением этого атрибута является рабочее давление трубопровода.

— «Рабочая температура стены, град. С». Значениме этого атрибута является рабочая температура стены участка трубопровода.

— «Тип изоляции». Значением этого атрибута является тип изоляции, избираемый юзером из справочника «Тип изоляции».

— «Тип попутного подогрева». Значением этого атрибута является тип попутного подогрева, избираемый юзером из справочника «Тип попутного подогрева».

— «Марка ингибитора». Значением этого атрибута является марка ингибитора, избираемая юзером из справочника «Марка ингибитора».

— «Номинальная толщина (мм)». Значением этого атрибута является номинальная толщина участка трубопровода.

— «Фактическая толщина стен (мм)». Значением этого атрибута является фактическая толщина стен, которая рассчитывается при проведении экспертизы.

— «Скорость коррозии, мм/год». Значением этого атрибута является скорость коррозии трубопровода.

— «Номер проекта». Значением этого атрибута является номер проекта.

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

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

— «Дата окончания строительства». Значением этого атрибута является дата окончания строительства участка трубопровода.

— «Дата ввода в эксплуатацию». Значением этого атрибута является дата ввода в эксплуатацию участка трубопровода.

— «Дата окончания службы». Значением этого атрибута является дата окончания срока службы участка трубопровода.

— «Выявленные отличия от технических характеристик». Значением этого атрибута является выявленные отличия от технических характеристик в процессе эксплуатации.

— «Дата вывода из эксплуатации». Значением этого атрибута является дата вывода участка трубопровода из эксплуатации.

— «Причина вывода из эксплуатации». Значением этого атрибута является инфы содержащая предпосылки вывода участка трубопровода из эксплуатации.

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

— «Трубопровод». Значением этого атрибута является указатель на трубопровод к которому принадлежит примечание.

— «Дата примечания». Значением данного атрибута является дата, когда примечание было добавлено.

— «Примечание». Значением этого атрибута является доп сведения о трубопроводе, вводимые юзером.

«Обследование с целью продления срока службы». В данной для нас таблице хранятся данные, содержащие информацию о обследовании проводившегося с целью продления срока службы трубопровода.

— «Трубопровод». Значением этого атрибута является указатель на трубопровод к которому принадлежит обследование.

— «Дата обследования с целью продления службы». Значением этого атрибута является дата проведения обследование для продления срока службы трубопровода.

— «Наименование организации, проводившей обследование». Значением этого атрибута является наименование организации проводившей обследование.

— «Ф.И.О. профессионала». Значением этого атрибута является Ф.И.О. профессионала, который проводил обследование трубопровода.

— «Выявленные отличия от технических характеристик». Значением этого атрибута является выявленные профессионалом отличия от нормы.

— «Дата окончания эксплуатации». Значением этого атрибута является дата окончания эксплуатации трубопровода.

— «Заключение». Значением этого атрибута является заключение составленное профессионалом в итоге обследования трубопровода.

— «Номер заключения». Значением этого атрибута является номер заключения.

— «Регистрационный номер заключения в ФСТН». Значением этого атрибута является номер заключения в ФСТН, которое регится опосля обследования трубопровода и составления профессионалом заключения.

«Ревизия участков». В данной для нас таблице хранятся данные, содержащие всю информацию о проводившихся ревизиях на участке трубопровода.

— «Участок трубопровода». Значением этого атрибута является указатель на участок трубопровода к которому относится ревизия.

— «Дата обследования». Значением этого атрибута является дата проведения ревизии на участке трубопровода.

— «Наименование организации, проводившей обследование». Значением этого атрибута является наименование организации проводившей ревизию участка трубопровода.

— «Ф.И.О. профессионала». Значением этого атрибута является Ф.И.О. профессионала, который проводил ревизию участка трубопровода.

— «Дата последующего обследования». Значением этого атрибута является дата последующего проведения ревизии.

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

— «Дата заключения». Значением этого атрибута является дата заключения, когда было изготовлено заключение на базе ревизии.

— «Номер заключения». Значением этого атрибута является номер заключения.

— «Заключение». Значением этого атрибута является заключение которое было изготовлено профессионалом в процессе проведения ревизии.

«Тесты участков». В данной для нас таблице хранятся данные, содержащие всю информацию о проводившихся испытаниях на участке трубопровода.

— «Участок трубопровода». Значением этого атрибута является указатель на участок трубопровода к которому относится испытание.

— «Дата обследования». Значением этого атрибута является дата проведения тесты на участке трубопровода.

— «Наименование организации, проводившей обследование». Значением этого атрибута является наименование организации проводившей испытание участка трубопровода.

— «Ф.И.О. профессионала». Значением этого атрибута является Ф.И.О. профессионала, который проводил испытание участка трубопровода.

— «Дата последующего обследования». Значением этого атрибута является дата последующего проведения тесты.

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

— «Дата заключения». Значением этого атрибута является дата заключения, когда было изготовлено заключение на базе тесты.

— «Номер заключения». Значением этого атрибута является номер заключения.

— «Заключение». Значением этого атрибута является заключение которое было изготовлено профессионалом в процессе проведения тесты.

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

— «Участок трубопровода». Значением этого атрибута является указатель на участок трубопровода к которому относится смерти).

— «Дата обследования». Значением этого атрибута является дата проведения диагностики на участке трубопровода.

— «Наименование организации, проводившей обследование». Значением этого атрибута является наименование организации проводившей диагностику участка трубопровода.

— «Ф.И.О. профессионала». Значением этого атрибута является Ф.И.О. профессионала, который проводил диагностику участка трубопровода.

— «Дата последующего обследования». Значением этого атрибута является дата последующего проведения диагностики.

— «Периодичность». Значением этого атрибута является периодичность проведения диагностик на участке трубопровода.

— «Дата заключения». Значением этого атрибута является дата заключения, когда было изготовлено заключение на базе диагностики.

— «Номер заключения». Значением этого атрибута является номер заключения.

— «Заключение». Значением этого атрибута является заключение которое было изготовлено профессионалом в процессе проведения диагностики.

«Ремонт участков». В данной для нас таблице хранятся данные, содержащие всю информацию о проводившихся ремонтах на участке трубопровода.

— «Участок трубопровода». Значением этого атрибута является указатель на участок трубопровода к которому относится ремонт.

— «Дата поломки». Значением этого атрибута является дата поломки участка трубопровода.

— «Дата начала ремонта». Значением этого атрибута является дата начала ремонта участка трубопровода.

— «Заключение о поломке». Значением этого атрибута является заключение о поломке участка трубопровода.

— «Дата конца ремонта». Значением этого атрибута является дата окончания ремонта участка трубопровода.

— «Выполненные работы». Значением этого атрибута является информация которая содержит список всех выполненных работ в процессе ремонта участка трубопровода.

Описанные сути представлены на ER-диаграмме на рис. 1.

Рис. 1. ER – диаграмма.

Переход от ER-диаграммы к схеме базы данных осуществляется по последующим правилам:

· сути преобразуются в таблицы,

· связи один ко почти всем преобразуются во наружные ключи,

· связи почти все ко почти всем преобразуются в таблицы.

Приобретенная по сиим правилам схема базы данных размещена на рисунке 2.

Рис. 2.

2.3 Хранимые процедуры

Хранимая процедура для удаления записи из таблицы «Трубопроводы»:

CREATE PROCEDURE spDelPipeline(@Id uniqueidentifier) AS

DELETE FROM CommentaryPipeline

WHERE Id_Pipeline = @id

DELETE FROM InspectionPipeline

WHERE Id_Pipeline = @id

Delete from RevisionPartsPipeline where

RevisionPartsPipeline.id_RevisionPartsPipeline in

(select RevisionPartsPipeline.id_RevisionPartsPipeline from

((Pipeline inner join PartsPipeline on Pipeline.id_Pipeline = PartsPipeline.id_Pipeline) inner join

RevisionPartsPipeline on PartsPipeline.id_PartsPipeline = RevisionPartsPipeline.id_PartsPipeline)

where Pipeline.id_Pipeline=@id)

Delete from TestPartsPipeline where

TestPartsPipeline.id_TestPartsPipeline in

(select TestPartsPipeline.id_TestPartsPipeline from

((Pipeline inner join PartsPipeline on Pipeline.id_Pipeline = PartsPipeline.id_Pipeline) inner join

TestPartsPipeline on PartsPipeline.id_PartsPipeline = TestPartsPipeline.id_PartsPipeline)

where Pipeline.id_Pipeline=@id)

Delete from RefusalPartsPipeline where

RefusalPartsPipeline.id_RefusalPartsPipeline in

(select RefusalPartsPipeline.id_RefusalPartsPipeline from

((Pipeline inner join PartsPipeline on Pipeline.id_Pipeline = PartsPipeline.id_Pipeline) inner join

RefusalPartsPipeline on PartsPipeline.id_PartsPipeline = RefusalPartsPipeline.id_PartsPipeline)

where Pipeline.id_Pipeline=@id)

Delete from DiagnosticPartsPipeline where

DiagnosticPartsPipeline.id_DiagnosticPartsPipeline in

(select DiagnosticPartsPipeline.id_DiagnosticPartsPipeline from

((Pipeline inner join PartsPipeline on Pipeline.id_Pipeline = PartsPipeline.id_Pipeline) inner join

DiagnosticPartsPipeline on PartsPipeline.id_PartsPipeline = DiagnosticPartsPipeline.id_PartsPipeline)

where Pipeline.id_Pipeline=@id)

Delete from RepairPartsPipeline where

RepairPartsPipeline.id_RepairPartsPipeline in

(select RepairPartsPipeline.id_RepairPartsPipeline from

((Pipeline inner join PartsPipeline on Pipeline.id_Pipeline = PartsPipeline.id_Pipeline) inner join

RepairPartsPipeline on PartsPipeline.id_PartsPipeline = RepairPartsPipeline.id_PartsPipeline)

where Pipeline.id_Pipeline=@id)

DELETE FROM PartsPipeline

WHERE Id_Pipeline=@id

DELETE FROM Pipeline

WHERE Id_Pipeline=@Id

GO

Хранимая процедура для удаления записи из таблицы «Транспортируемые продукты» :

CREATE PROCEDURE SPDelDic_ClassTransportProductTE(@idrec uniqueidentifier) AS

DECLARE @ins_error int, @ROWCOUNT int

BEGIN TRANSACTION TranName

DELETE FROM DIC_CLASSTRANSPORTPRODUCTTE

WHERE Id_Dic_ClassTransportProductTE = @idrec

select @ROWCOUNT=@@ROWCOUNT, @ins_error=@@error

if @ins_error=0

begin

COMMIT TRANSACTION TranName

return (0)

end

else

begin

ROLLBACK TRAN TranName

return (1)

end

GO

2.4 Запросы

запрос на прибавления записи в таблицу «Трубопроводы»:

SQLStr.Add(‘INSERT INTO dbo.PartsPipeline (Id_PartsPipeline, Id_Pipeline, ‘+

‘NameParts, NameProjectOrganizations, DateEndConstract, DatePuttingactiveXDateEndServiceLife, DateLeavePutting, DepartureTehPar, ‘+ ‘Id_Dic_ClassDBAOrganizationsTE, ‘Id_Dic_ClassTypeIsolationTE, ‘+ Id_Dic_ClassTypeHeatingTE, Id_Dic_ClassTypeInhibitorTE, ‘+

‘IncutDate, Length, StellGrade, OuterDiameter, WorkingPressure, WorkingTemperature, ‘+

‘NominalThickness, ActualThickness, VelocityCorrosion, ‘+

‘MotiveLeavePutting, NumberProject) ‘+

‘VALUES (»’+ Id_PartsPipeLine +»’, ‘+

»»+ Id_Pipeline +»’, ‘+

»»+ memNameParts.text +»’, ‘+

»»+ memNameProjectOrg.text +»’,’+

»+ DateTimeToStrDB(deDateEndConstract.Date,’ : ‘) +’, ‘+

»+ DateTimeToStrDB(deDatePutting.Date,’ : ‘) +’, ‘+

»+ DateTimeToStrDB(deDateEndServiceLife.Date,’ : ‘) +’, ‘+

»+ DateTimeToStrDB(deDateLeavePutting.Date,’ : ‘) +’, ‘+

»»+ memDepartureTehPar.text +»’, ‘+

Id_ClassDBAOrganizations +’, ‘+

Id_ClassTypeIsolation +’, ‘+

Id_ClassTypeHeating +’, ‘+

Id_ClassTypeInhibitor +’, ‘+

»+ DateTimeToStrDB(deIncutDate.Date,’ : ‘) +’, ‘+

»»+ edtLength.text +»’, ‘+

»»+ edtStellGrade.text +»’, ‘+

»»+ edtOuterDiameter.text +»’, ‘+

»»+ edtWorkingPressure.text +»’, ‘+

»»+ edtWorkingTemperature.text +»’, ‘+

»»+ edtNominalThickness.text +»’, ‘+

»»+ edtActualThickness.text +»’, ‘+

»»+ edtVelocityCorrosion.text +»’, ‘+

»»+ memMotiveLeavePutting.text +»’, ‘+

»»+ edtNumberProject.text +»’)’);

запрос на обновление записи примечания к трубопроводу в таблице «Примечания»:

MemberCommentary.Add(‘UPDATE dbo.CommentaryPipeline SET ‘+

‘Commentary = »’+ Data.Commentary +»’, ‘+

‘DateCommentary = ‘+ ConvertFormatDate(Data.DateCommentary) +’ ‘+

‘ WHERE Id_CommentaryPipeline = »’+ Data.Id_Commentary +»’ ‘);

2.5 Выбор модели базы данных

Существую три дореляционных подхода к организации баз данных:

· системы, основанные на инвертированных перечнях,

· иерархические системы,

· сетевые системы.

Одними из современных подходов к организации баз данных являются объектно-ориентированный и реляционный.

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

2.6 Организация взаимодействия с юзером

Пользовательский интерфейс должен предоставлять последующие функции:

· поиск по типу;

· поиск по виду;

· поиск по наименованию трубопровода;

· поиск по группы трубопровода;

· поиск по транспортируемым продуктам;

· поиск по регистрационному номеру ФСТН;

· поиск по дате регистрации в ФСТН;

· поиск по регистрационному номеру СТН;

· поиск по дате регистрации в СТН;

· поиск по месторождению;

3. ТЕХНОЛОГИЧЕСКАЯ часть

3.1 Выбор средства разработки

Для реализации данного проекта был избран язык Delphi. Будучи языком высочайшего уровня, он всё же предоставляет программеру полный контроль над машинкой, дозволяет перебегать на язык наиболее низкого уровня (ассемблер). Delphi является эталоном для приложений, где необходимо быстродействие и малый размер кода при довольно глобальных масштабах проекта.

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

3.2 Выбор СУБД

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

· реляционная модель представления данных,

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

· работа на платформе Windows 2000 и выше.

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

· Microsoft SQL Server 2000,

· Oracle,

· IBM DB-2.

СУБД DB-2 может обслуживать до 64 000, а Oracle до 10 000 сразу работающих юзеров [8]. Внедрение их в рамках данного проекта является не целесообразным расходованием ресурсов.

На шаге разработки системы была построена реализация с внедрением базы данных на MS Access. Тестовая эксплуатация в сети веб показала корректность избранных способов решения поставленной задачки. Было выявлено, что MS Access не выдерживает нужные перегрузки, это выражается в увеличении времени ответа системы. Система интерактивная и подобные задержки недопустимы.

Из выше перечисленного следует, что в данном проекте нужно применять СУБД MS SQL Server 2000.

3.3 Описание системы

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

Пользовательский интерфейс

Пользовательский интерфейс системы состоит из 3-х панелей. В верхней части экрана размещена «Инструментальная» панель. Панель содержит клавиши для управления записями в базе данных.

На верхней панели размещена форма «Трубопроводы». Форма создана для отображения главных сведений о трубопроводе.

На нижней панели размещена форма «Участки трубопровода». В процессе работы с системой показывает все участки выделенного трубопровода.

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

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

Форма прибавления новейшего «Трубопровода».

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

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

Форма редактирования «Трубопровода».

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

Форма просмотра «Трубопровода».

При выбирании юзером режима просмотра, поля на форме автоматом заполняются данными, которые содержаться в базе. юзер может производить лишь просмотр данных в этом режиме.

Форма прибавления новейшего «Участка трубопровода».

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

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

Форма редактирования «Участка трубопровода».

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

Форма просмотра «Трубопровода».

При выбирании юзером режима просмотра, поля на форме автоматом заполняются данными, которые содержаться в базе. юзер может производить лишь просмотр данных в этом режиме.

Форма поиска «Трубопровода».

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

3.4 синхронизация при работе в сети

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

3.5 Технические свойства программки

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

Малые требования:

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

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

Может быть расширение сделанного программного средства, включив в него возможность автоматического сотворения отчетов и актов.

СПИСОК ЛИТЕРАТУРЫ

1. Методическое пособие по выполнению курсового проекта по курсу “Базы данных”, Просуков

2. Дейт К. Дж. Введение в системы баз данных, 7-е изд. — М.: Издательский дом «Вильямс», 2001.

3. Проектирование и реализация баз данных Microsoft SQL Server 2000. Учебный курсMCAD/MCSE, MCDBA .- Пер. с англ.-2-е изд., испр.- М.: Издательско-торговый дом «Российская редакция», 2003.-512 стр.: ил.

4. Программирование в SQL-Server 2000. Ребекка М. Риордан, ЭКОМ, Москва, 2002.

5. Microsoft MSDN.

6. Информационные и учебные ресурсы веб.

Приложение 1.

Файл конфигурации

Database
.
ini
.

[Database]

Provider=SQLOLEDB.1

Database=PIPELINE

ServerName=KONTORA

[DLL]

DLLPath=C:БДbin

]]>