Министерство образования Российской ФедерацииТомский государственный университет факультет информатики кафедра теоретических основ информатикиДОПУСТИТЬ К ЗАЩИТЕ В ГАК Зав. каф., к.т.н., доцент _________ Ю.Л. Костюк «___»___________2000г. Афанасьев Павел АлександровичРазработка электронного справочника оперативно-диспетчерских служб предприятий электроэнергетики Дипломная работаНаучный руководитель начальник отдела АСУ ЗАО «Горэлектросети» _______________ В.В. Чебаков Исполнитель _____________П.А. АфанасьевЭлектронная версия отчета помещена в электронную библиотеку. Администратор_____________Томск 2000 реферат Дипломная работа на 52 страницах, 6 приложений, 23 иллюстрации, 5 источников.^ СУБД, АВТОМАТИЗАЦИЯ, INTERBASE, ЭЛЕКТРОННЫЙ СПРАВОЧНИК, ОПЕРАТИВНО ДИСПЕТЧЕРСКАЯ СЛУЖБА, ЭЛЕКТРОСЕТЬОбъект исследования – информационные потоки оперативно-диспетчерских служб предприятий электроэнергетики. Цель работы – разработка программного продукта, обеспечивающего поиск и хранение информации, отражающей структуру и основные параметры системы электроснабжения города. Разработан программный комплекс, автоматизирующий часть работы оперативно-диспетчерских служб предприятий электроэнергетики, связанной с поиском и хранением информации, необходимой для принятия оперативных решений. ОГлавление реферат 3 ОГлавление 4 ВВЕДЕНИЕ 6 1.инструменты разработки 7 1.1. Среда визуального программирования BORLAND DELPHI. 7^ 1.2. BORLAND DATABASE ENGINE 7 1.3. СУБД interbase server 7 2. Теоретические основы 9 2.1. Основные функции субд 11 2.2. базовые понятия реляционных БД 13 2.3. Язык реляционных баз данных SQL 14 2.4. архитектура «клиент-сервер» 15 3. Энергоресурсы и специфика их сбыта 17 3.1.Первая электростанция в томске 17 3.2. МЕСТО ЗАО «ГОРЭЛЕКТРОСЕТИ» в системе энергоснабжения 17 3.3. оперативно диспетчерская служба 18 4. Алгоритмы и структуры данных 19 4.1. структура базы данных 19 4.1.1. основные объекты предметной области 20 4.1.1.1. Объект «подстанция» 20 4.1.1.2. объект «здание» 20 4.1.1.3. объект «организация» 22 4.1.1.4. объект «абонент» 23 4.1.2. таблицы-справочники 23 4.1.3. Хранимые процедуры и триггеры 24 4.2. алгоритмы и структуры данных клиентской части программы 24 4.2.1. Навигация по данным 24 4.2.2. компоненты визуализации данных 25 4.2.3. компоненты для связи с базой данных 25 4.2.4. Использование механизма отложенных изменений 26 5. организация интерфейса пользователя 27 5.1. общие принципы 27 5.2. объектная модель представления информации 28 5.3. схема организации интерфейса пользователя 30 5.4. изменение и дополнение справочников 31 Заключение 32 список литературы 33 приложение 1. Руководство программиста 34 П1.1. Общие сведения 34 П1.2. Установка 34 п1.3. Структура приложения 34 приложение 2. Руководство пользователя 35 п2.1. Общие сведения 35 П2.1.1. особенности интерфейса 35 П2.1.2. главное окно и дерево объектов 36 П2.2. работа с подстанциями 37 П2.2.1. просмотр изменение и удаление инФОРМАЦИИ О ПОДСТАНЦИИ 37 П2.2.2.Просмотр и запись в журнал подстанции 39 П2.2.3. Выбор ячейки источника 39 П2.2.4. Работа с секциями подстанций 40 П2.2.5.Работа с ячейками секций 40 П2.2.6.Работа с распределительными устройствами 41 П2.2.7. Работа с вводными устройствами потребителя 42 П2.3. Работа со зданиями и сооружениями 42 П2.4. Работа с организациями 43 П2.5. работа с абонентами – физическими лицами 44 П2.6. поиск информации 45 приложение 3: список файлов 46 Приложение 4: реляционная схема БД 47 приложение 5: SQL-описание базы данных 48 приложение 6: список файлов в электронной версии отчета 53 ВВЕДЕНИЕ Автоматизация процессов хранения и обработки информации коснулась всех без исключения сфер деятельности человека. В силу неоспоримых преимуществ, бумажные носители информации вытесняются электронными. Представленная дипломная работа делает еще один маленький шаг на пути к повсеместному использованию электронных носителей информации. Среди преимуществ электронного хранения информации такие как: возможность хранения больших объемов информации в небольшом объеме физического пространства; возможность быстрого поиска необходимой информации; возможность быстрого обмена и передачи информации. Задачей представленного дипломного проекта является разработка электронного справочника оперативно диспетчерских служб предприятий электроэнергетики. Справочник должен удовлетворять следующим условиям: хранение больших объемов информации; быстрый поиск; удобный интерфейс пользователя.^ инструменты разработки 1.1. Среда визуального программирования BORLAND DELPHI. Borland Delphi – это интегрированная среда для разработки приложений под Windows, включающая следующие компоненты: Высокопроизводительный компилятор с языка высокого уровня в машинный код; Объектно-ориентированные модули и компоненты; Визуальное построение приложений из прототипов; Средства построения баз данных. Компилятор, встроенный в Delphi, обеспечивает высокую производительность, необходимую для построения приложений в архитектуре клиент/сервер. Этот компилятор в настоящее время является самым быстрым в мире (неофициальные данные). Он предлагает лёгкость разработки и быстрое время проверки готового программного блока, характерного для языков четвёртого поколения (4GL) и в то же время обеспечивает качество кода, характерного для компилятора 3GL.^ 1.2. BORLAND DATABASE ENGINE Мощность и гибкость Delphi при работе с базами данных основана на низкоуровневом ядре - процессоре баз данных Borland Database Engine (BDE). Его интерфейс с прикладными программами называется Integrated Database Application Programming Interface (IDAPI). В принципе, сейчас не различают эти два названия (BDE и IDAPI) и считают их синонимами. BDE позволяет осуществлять доступ к данным как с использованием традиционного record-ориентированного (навигационного) подхода, так и с использованием set-ориентированного подхода, используемого в SQL-серверах баз данных. Кроме BDE, Delphi позволяет осуществлять доступ к базам данных, используя технологию (и, соответственно, драйверы) Open DataBase Connectivity (ODBC) фирмы Microsoft. Но, как показывает практика, производительность систем с использованием BDE гораздо выше, чем оных при использовании ODBC. ODBC драйвера работают через специальный "ODBC socket", который позволяет встраивать их в BDE. ^ 1.3. СУБД interbase server SQL-сервер InterBase предназначен для хранения и обработки больших объемов информации в условиях одновременной работы с БД множества клиентских приложений. Масштаб информационной системы при этом произволен – от системы уровня рабочей группы (под управлением Novel Netware или Windows 32 на базе IBM-совместимых ПК) до системы уровня большого предприятия (на базе серверов IBM, Hewlett-Packard, SUN).Ниже приведены некоторые технические характеристики SQL-сервера InterBase: Характеристика Значение Максимальный размер одной БД Рекомендуется не выше 10 Gb Максимальное количество таблиц в одной БД 65536 Максимальное количество полей в одной таблице 1000 Максимальное количество записей в одной таблице Не ограничено Максимальная длина записи 64 К (не считая полей BLOB) Максимальная длина поля 32 К (кроме полей BLOB) Максимальная длина поля BLOB Не ограничена Максимальное количество индексов в БД 65536 Максимальное количество полей в индексе 16 Максимальный уровень вложенности SQL-запроса 16 Максимальный размер хранимой процедуры 48 К Максимальное количество UDF Не ограниченно ^ 2. Теоретические основы Активная деятельность по отысканию приемлемых способов обобществления непрерывно растущего объема информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых "Системы управления базами данных" (СУБД). Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных" (БД).^ Язык запросов СУБД позволяет обращаться за информацией как из программ, так и с терминалов (см.рис.1). Рис. 1 Связь программ и данных при использовании СУБДРассмотрим общий смысл понятий БД и СУБД. Начнем с того, что с самого начала развития вычислительной техники образовались два основных направления ее использования. Первое направление – применение вычислительной техники для выполнения численных расчетов, которые слишком долго или вообще невозможно производить вручную. Становление этого направления способствовало интенсификации методов численного решения сложных математических задач, развитию класса языков программирования, ориентированных на удобную запись численных алгоритмов, становлению обратной связи с разработчиками новых архитектур ЭВМ. Второе направление – это использование средств вычислительной техники в автоматических или автоматизированных информационных системах. В самом широком смысле информационная система представляет собой программный комплекс, функции которого состоят в поддержке надежного хранения информации в памяти компьютера, выполнении специфических для данного приложения преобразований информации и/или вычислений, предоставлении пользователям удобного и легко осваиваемого интерфейса. Обычно объемы информации, с которыми приходится иметь дело таким системам, достаточно велики, а сама информация имеет достаточно сложную структуру. Классическими примерами информационных систем являются банковские системы, системы резервирования авиационных или железнодорожных билетов, мест в гостиницах и т.д. Эти системы главным образом ориентированы на хранение, выбор и модификацию постоянно существующей информации. Структура информации зачастую очень сложна, и хотя структуры данных различны в разных информационных системах, между ними часто бывает много общего. На начальном этапе использования вычислительной техники для управления информацией проблемы структуризации данных решались индивидуально в каждой информационной системе. Производились необходимые надстройки над файловыми системами (библиотеки программ), подобно тому, как это делается в компиляторах, редакторах и т.д. Но поскольку информационные системы требуют сложных структур данных, эти дополнительные индивидуальные средства управления данными являлись существенной частью информационных систем и практически повторялись от одной системы к другой. Стремление выделить и обобщить общую часть информационных систем, ответственную за управление сложно структурированными данными, явилось, первой побудительной причиной создания СУБД. Очень скоро стало понятно, что невозможно обойтись общей библиотекой программ, реализующей над стандартной базовой файловой системой более сложные методы хранения данных. Понятие согласованности данных является ключевым понятием баз данных. Фактически, если информационная система поддерживает согласованное хранение информации в нескольких файлах, можно говорить о том, что она поддерживает базу данных. Если же некоторая вспомогательная система управления данными позволяет работать с несколькими файлами, обеспечивая их согласованность, можно назвать ее системой управления базами данных. Уже только требование поддержания согласованности данных в нескольких файлах не позволяет обойтись библиотекой функций: такая система должна иметь некоторые собственные данные (метаданные) и даже знания, определяющие целостность данных. Но это еще не все, что обычно требуют от СУБД. Среди прочих требований: поддержание логически согласованного набора файлов; обеспечение языка манипулирования данными; восстановление информации после разного рода сбоев; реально параллельная работа нескольких пользователей. Можно считать, что если прикладная информационная система опирается на некоторую систему управления данными, обладающую этими свойствами, то эта система управления данными является системой управления базами данных (СУБД).^ 2.1. Основные функции субд Более точно, к числу функций СУБД принято относить следующие: 1. Непосредственное управление данными во внешней памяти Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным в некоторых случаях (обычно для этого используются индексы). ^ 2. Управление буферами оперативной памяти СУБД обычно работают с БД значительного размера; по крайней мере, этот размер обычно существенно больше доступного объема оперативной памяти. Практически единственным способом реального увеличения скорости работы системы является буферизация данных в оперативной памяти. При этом даже если операционная система производит общесистемную буферизацию, этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов. ^ 3. Управление транзакциями Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Таким образом, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД. То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения, делает очень удобным использование понятия транзакции как единицы активности пользователя по отношению к БД. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может в принципе ощущать себя единственным пользователем СУБД. 4. Журнализация Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД. Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода. ^ 5. Поддержка языков БД Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language).^ 2.2. базовые понятия реляционных БД Основными понятиями реляционных баз данных являются тип данных, домен, атрибут, кортеж, первичный ключ и отношение. Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в современных реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как "деньги"), а также специальных "темпоральных" данных (дата, время, временной интервал). Достаточно активно развивается подход к расширению возможностей реляционных систем абстрактными типами данных. Понятие домена более специфично для баз данных, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования. Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа. Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. Заметим, что в большинстве реляционных СУБД понятие домена не используется, хотя в InterBase оно уже поддерживается. ^ Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}. Степень или "арность" схемы отношения - мощность этого множества. Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута).Схема БД (в структурном смысле) - это набор именованных схем отношений. Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или "арность" кортежа, т.е. число элементов в нем, совпадает с "арностью" соответствующей схемы отношения. Попросту говоря, кортеж - это набор именованных значений заданного типа. Отношение - это множество кортежей, соответствующих одной схеме отношения. На самом деле, понятие схемы отношения ближе всего к понятию структурного типа данных в языках программирования. Во многих реализациях допускается и изменение схемы базы данных: определение новых и изменение существующих схем отношения. Это принято называть эволюцией схемы базы данных. Обычным житейским представлением отношения является таблица, заголовком которой является схема отношения, а строками - кортежи отношения-экземпляра; в этом случае имена атрибутов именуют столбцы этой таблицы. Поэтому иногда говорят "столбец таблицы", имея в виду "атрибут отношения". Этой терминологии придерживаются в большинстве коммерческих реляционных СУБД. Реляционная база данных - это набор отношений, имена которых совпадают с именами схем отношений в схеме БД. Как видно, основные структурные понятия реляционной модели данных (если не считать понятия домена) имеют очень простую интуитивную интерпретацию, хотя в теории реляционных БД все они определяются абсолютно формально и точно.^ 2.3. Язык реляционных баз данных SQL Язык для взаимодействия с БД SQL появился в середине 70-х и был разработан в рамках проекта экспериментальной реляционной СУБД System R. Исходное название языка SEQUEL (Structered English Query Language) только частично отражает суть этого языка. Конечно, язык был ориентирован главным образом на удобную и понятную пользователям формулировку запросов к реляционной БД, но на самом деле уже являлся полным языком БД, содержащим помимо операторов формулирования запросов и манипулирования БД средства определения и манипулирования схемой БД; определения ограничений целостности и триггеров; представлений БД; возможности определения структур физического уровня, поддерживающих эффективное выполнение запросов; авторизации доступа к отношениям и их полям; точек сохранения транзакции и откатов. В языке отсутствовали средства синхронизации доступа к объектам БД со стороны параллельно выполняемых транзакций: с самого начала предполагалось, что необходимую синхронизацию неявно выполняет СУБД. Но, несмотря на недостаточную техническую проработку, в идейном отношении язык содержал все необходимые средства, позволяющие использовать его как базовый язык СУБД. Язык SQL сочетает средства SDL и DML, т.е. позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (для реляционной БД - именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов. Язык SQL содержит специальные средства определения ограничений целостности БД. Опять же, ограничения целостности хранятся в специальных таблицах-каталогах, и обеспечение контроля целостности БД производится на языковом уровне, т.е. при компиляции операторов модификации БД компилятор SQL на основании имеющихся в БД ограничений целостности генерирует соответствующий программный код. Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить видимость БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне. Наконец, авторизация доступа к объектам БД производится также на основе специального набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу БД, обладает полным набором полномочий для работы с этой таблицей. В число этих полномочий входит полномочие на передачу всех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне. В настоящее время SQL реализован практически во всех коммерческих реляционных СУБД, все фирмы провозглашают соответствие своей реализации стандарту SQL, и на самом деле реализованные диалекты SQL очень близки. Можно сказать, что базовый набор операторов SQL, включающий операторы определения схемы БД, выборки и манипулирования данными, авторизации доступа к данным, поддержки встраивания SQL в языки программирования и операторы динамического SQL, в коммерческих реализациях относительно устоялся и более или менее соответствует стандарту.^ 2.4. архитектура «клиент-сервер» До появления клиент-серверных вычислений общепринятая конфигурация включала терминалы ввода-вывода, подключенные к большой обслуживающей машине. Ввод каждого символа и любая другая обработка, необходимая для терминала ввода-вывода, должна была выполняться главной машиной (обычно типа мэйнфрейма). Тем самым к производительности центрального процессора и памяти главной машины предъявлялись высокие требования. С появлением оболочек и операционных систем с GUI-интерфейсом (графический пользовательский интерфейс) наподобие MS Windows пользователи получили возможность использовать для обработки данных все средства своих персональных компьютеров вместо того, чтобы подключать терминал ввода-вывода к более мощному мэйнфрейму. Они также получили простые в использовании, но мощные и гибкие платформы, поддерживающие графический интерфейс пользователя. В клиент-серверной системе можно выполнять некоторые программы на машине клиента (возможно, персональном компьютере), а другие – а сервере (например, средствами СУБД Oracle на машине UNIX), соединив машины между собой некоторым способом (возможно с помощью локальной сети). Программы, работающие на персональном компьютере, используют его процессор и память, а не аппаратные средства главной машины. При необходимости связаться с базой данных по сети на сервер направляются соответствующие операторы, где они и обрабатываются, а результаты возвращаются на машину клиента. Применительно к системам баз данных архитектура "клиент-сервер" интересна и актуальна главным образом потому, что обеспечивает простое и относительно дешевое решение проблемы коллективного доступа к базам данных в локальной сети. В некотором роде системы баз данных, основанные на архитектуре "клиент-сервер", являются приближением к распределенным системам баз данных, конечно, существенно упрощенным приближением, но зато не требующим решения основного набора проблем действительно распределенных баз данных.^ 3. Энергоресурсы и специфика их сбыта 3.1.Первая электростанция в томске Рис. 2 ЗАО "Горэлектросети" В апреле 1895г. в Томске было учреждено Товарищество «Технико-промышленное бюро и Кампания». На месте впадения Ушайки в Томь концессионеры построили Городскую электростанцию. Вечером 31 декабря 1895г. станция дала первый ток. Цепь городских фонарей осветила улицы Миллионную, Магистратскую и Набережную Ушайки. Первенец сибирской энергетики дал городу электричество. Свет фонарей вызвал к жизни Городские электрические сети. Это было начало. Долгое время электрические сети города оставались структурным подразделением ГЕС-1. Все энергопредприятия в то время располагались в одном знании – на Конной площади, 10. Обслуживание горсетей осуществлялось двумя машинами и конным обозом. С 60-х Томск стал бурно строиться. Активно возводились промышленные, социальные объекты, жилье. Затем наступила эра нефтегазовой отрасли. И вслед за разработчиками земных недр энергетики продвигались на Север области. Деятельность «Томскэнерго» приобретала областной характер. А электрохозяйство Томска становилось все более специализированно-городским. И однажды для обслуживания коммунально-бытовых потребителей Томска были образованы «Городские электрические сети». Это произошло 1 апреля 1964 года.^ 3.2. МЕСТО ЗАО «ГОРЭЛЕКТРОСЕТИ» в системе энергоснабжения ЗАО «Горэлектросети» по своей природе является предприятием-посредником. Покупая электроэнергию у «Томскэнерго» оно обеспечивает бесперебойное электроснабжение города. Схематично место «Горэлектросети» в структуре энергоснабжения можно представить на рисунке 3. Рис. 3 Место ЗАО «Горэлектросети» в системе энергоснабжения городаСтруктура потребителей «Горэлектросети» представлена на рисунке 4.Рис. 4 Структура потребителей электроэнергии^ 3.3. оперативно диспетчерская служба Оперативно-диспетчерская служба является структурным подразделением предприятия и находится в прямом подчинении главного инженера. Среди задач решаемых оперативно-диспетчерской службой такие как: Круглосуточный контроль над состоянием системы энергоснабжения. Принятие решений по устранению аварийных ситуаций. Накопление и обобщение статистики. Прием в эксплуатацию новых объектов. Планирование развития системы энергоснабжения, на основании накопленной статистики. Планирование мероприятий по плановому обслуживанию объектов системы энергоснабжения.^ 4. Алгоритмы и структуры данных 4.1. структура базы данных Представленная база данных соответствует реляционной технологии построения баз данных (БД). Реляционная схема БД представлена в приложении 4. Все таблицы БД можно условно разделить на три группы: Таблицы, содержащие информацию о реальных объектах и их свойствах (подстанциях, зданиях и т.п.). Таблицы, отражающие информацию о связях между объектами реального мира и их свойствах. Таблицы-справочники, хранящие типовые значения некоторых свойств реальных объектов. Таблицы первого типа предназначены для хранения информации об основных объектах предметной области. К таким таблицам относятся: STATIONS – содержит информацию о трансформаторных подстанциях и фидерных пунктах, их основных характеристиках; SECTIONS,CELLS,ABONENT_DEVICE,DIST_DEVICE – хранят информацию о структурных частях трансформаторных подстанций и их основных параметрах; OBJECTS – хранит информацию о зданиях и сооружениях на которые поступает электроэнергия; ORGS – содержит данные об организациях - абонентах электрической сети; ABONENTS – хранит информацию об абонентах – физических лицах; Таблицы, отражающие связи объектов предназначены для хранения свойств этих связей, а так же для идентификации объектов по их связям. Примером такой таблицы является таблица STATION_HAS_EQUIPMENT, связывающая таблицы STATIONS и ADD_EQUIPMENT связью типа «многие-ко-многим». Связь отражает количество дополнительного оборудования, имеющегося на подстанции или фидерном пункте. Собственным свойством данной связи является количество дополнительного оборудования. К таблицам-справочникам необходимо отнести следующие таблицы:STREETS – содержит названия улиц города;OBJECT_KINDS – хранит информацию и видах зданий с точки зрения их предназначения и категории;STATION_KINDS – виды трансформаторных подстанций и фидерных пунктов;ACTION_KINDS – содержит возможные типы событий, отраженных в журнале подстанции;^ 4.1.1. основные объекты предметной области Основными объектами предметной области являются: трансформаторные подстанции и фидерные пункты, строительные здания и сооружения, участвующие в системе энергоснабжения, организации, являющиеся абонентами электросети как в качестве владельцев зданий и сооружений, снабжаемых электроэнергией.^ 4.1.1.1. Объект «подстанция» Под объектом «Подстанция» подразумеваются некоторые пункты – узлы системы энергоснабжения, предназначенные для обеспечения электроэнергией подключенных к ним зданий и сооружений, изменения параметров электроэнергии (уменьшения напряжения и т.п.), защиты от перегрузок и так далее. Информация о подстанциях хранится в таблице STATIONS, таблица содержит следующие поля: ID – уникальный идентификатор подстанции, служебное поле, используется как внешний ключ в других таблицах; KIND_ID – внешний ключ, ссылается на таблицу-справочник содержащую возможные типы подстанций; ORG_ID – внешний ключ, указывающий код организации-владельца подстанции в таблице ORGS; CELL610_ID – код ячейки подстанции, от которой данная подстанция получает электроэнергию, информация об ячейках содержится в таблице CELLS; NAME – название подстанции занесенное в документы, по этому названию осуществляется поиск; ADRESS – адрес ближайшего от подстанции строительного сооружения; ADD_IF – дополнительная текстовая информация любого характера;^ 4.1.1.2. объект «здание» Под объектом «ЗДАНИЕ» следует понимать любое строительное или иное сооружение участвующее в системе энергоснабжения, то есть получающие электроэнергию от одной из подстанций. Подключение сооружения осуществляется к вводному устройству потребителя, находящемуся в подстанции, которая осуществляет энергоснабжение данного объекта. Вводное устройство потребителя находится в свою очередь в одной из секций подстанции. Информация об объектах типа «ЗДАНИЕ» содержится в таблице OBJECTS, которая имеет следующие поля: ID – уникальный идентификатор строительного сооружения, служебное поле, используется как внешний ключ в других таблицах; KIND_ID – внешний ключ, ссылка на таблицу-справочник OBJECT_KINDS, содержащую возможные типы объектов и их категории; NAME – название объекта STREET_ID – внешний ключ, код улицы, ссылка на таблицу-справочник STREETS, содержащую список улиц; HOUSE – номер здания на улице; SQUARE – общая площадь сооружения; LIVESQUARE – жилая площадь сооружения (для нежилых объектов равна нулю); BUILTSQUARE – общая площадь застройки; WIDTH – ширина сооружения; LENGTH – длина сооружения; HEIGHT – высота сооружения; PROJECT – ссылка на документ, содержащий проект данного сооружения; Как отмечено выше каждый объект подключается к вводному устройству потребителя, информация о котором содержится в таблице ABONENT_DEVICE, которая имеет следующие поля: ID – уникальный идентификатор строительного сооружения, служебное поле, используется как внешний ключ в других таблицах; DIST_DEVICE_ID – внешний ключ, идентификатор распределительного устройства, в составе которого находится данное вводное устройство потребителя; OBJECT_ID – идентификатор строительного сооружения, которое питается через данное вводное устройство потребителя; NAME – название вводного устройства потребителя; DESIGN_LOAD – расчетная нагрузка устройства; Вводное устройство потребителя, в свою очередь, находится в составе распределительного устройства – еще одного элемента трансформаторной подстанции. Информация о распределительных устройствах находится в таблице DIST_DEVICE, которая содержит следующие поля: ID – уникальный идентификатор распределительного устройства, служебное поле, используется как внешний ключ в других таблицах; SECTION_ID – код секции, в которой находится данное распределительное устройство; NAME – название распределительного устройства; ISOLATOR_TYPE – тип опорных изоляторов; ENTER_TYPE – тип ввода; NOM_VOLTAGE – номинальное напряжение; NOM_AMPERAGE – номинальный ток; DYNAMIC_STABILITY – ток динамической устойчивости; THERMO_STABILITY – ток термической устойчивости; Распределительное устройство находится в составе секции трансформаторной подстанции. Информация о секциях трансформаторной подстанции находится в таблице SECTIONS, которая имеет следующие поля: ID - уникальный идентификатор секции, служебное поле, используется как внешний ключ в других таблицах; STATION_ID – внешний ключ, код подстанции, частью которой является данная секция; SECTION_KIND – внешний ключ, ссылается на таблицу справочник SECTION_KINDS, которая содержит возможные типы секций; NUMBER – номер секции внутри подстанции; NAME – название секции; NOM_VOLTAGE – номинальное напряжение;^ 4.1.1.3. объект «организация» Объекты данного типа рассматриваются с двух точек зрения. Первая – это организация как владелец объекта, на который подается электроэнергия. Вторая – организация, которая участвует в системе энергоснабжения как владелец одной или нескольких подстанций. Это, как правило, крупные организации, например заводы. Информация об организациях хранится в таблице ORGS, которая имеет следующие поля: ID - уникальный идентификатор организации, служебное поле, используется как внешний ключ в других таблицах; NAME – название организации; STREET_ID – внешний ключ, код улицы на которой распол