Афанасьев Павел Александрович Разработка электронного справочник

Вид материала

Справочник

Содержание 3. Энергоресурсы и специфика их сбыта 3.2. МЕСТО ЗАО «ГОРЭЛЕКТРОСЕТИ» в системе энергоснабжения 3.3. оперативно диспетчерская служба 4. Алгоритмы и структуры данных 4.1.1. основные объекты предметной области 4.1.1.1. Объект «подстанция» 4.1.1.2. объект «здание» 4.1.1.3. объект «организация» 4.1.1.4. объект «абонент» 4.1.3. Хранимые процедуры и триггеры 4.2. алгоритмы и структуры данных клиентской части программы 4.2.2. компоненты визуализации данных 4.2.3. компоненты для связи с базой данных 4.2.4. Использование механизма отложенных изменений

Подобный материал:

• Виктор Александрович Афанасьев © Евгений Сергеевич Романов © Александр Алексеевич Никишов, 592.86kb.
• Вадим Александрович Чернобров, Александр Борисович Петухов, Иван Анатольевич Соболев:, 3271.24kb.
• Вадим Александрович Чернобров, Александр Борисович Петухов, Иван Анатольевич Соболев, 3270.03kb.
• Дмитрий Сергеевич Лихачёв, Борис Александрович Рыбаков, Алексей Александрович Шахматов., 279.29kb.
• Афанасьев Андрей Александрович исследование, 1325.47kb.
• Планы семинарских занятий по дисциплине «экономика зарубежных стран», 95.91kb.
• Орская навигация, 48.92kb.
• Заочной формы обучения, 10.66kb.
• Исследование и прогнозирование рынков, 7.92kb.
• Кокарев Павел Александрович, 62.06kb.

3. Энергоресурсы и специфика их сбыта

3.1.Первая электростанция в томске

Рис. 2 ЗАО "Горэлектросети"
В апреле 1895г. в Томске было учреждено Товарищество «Технико-промышленное бюро и Кампания». На месте впадения Ушайки в Томь концессионеры построили Городскую электростанцию. Вечером 31 декабря 1895г. станция дала первый ток. Цепь городских фонарей осветила улицы Миллионную, Магистратскую и Набережную Ушайки. Первенец сибирской энергетики дал городу электричество. Свет фонарей вызвал к жизни Городские электрические сети. Это было начало. Долгое время электрические сети города оставались структурным подразделением ГЕС-1. Все энергопредприятия в то время располагались в одном знании – на Конной площади, 10. Обслуживание горсетей осуществлялось двумя машинами и конным обозом.

С 60-х Томск стал бурно строиться. Активно возводились промышленные, социальные объекты, жилье. Затем наступила эра нефтегазовой отрасли. И вслед за разработчиками земных недр энергетики продвигались на Север области. Деятельность «Томскэнерго» приобретала областной характер. А электрохозяйство Томска становилось все более специализированно-городским. И однажды для обслуживания коммунально-бытовых потребителей Томска были образованы «Городские электрические сети». Это произошло 1 апреля 1964 года.

3.2. МЕСТО ЗАО «ГОРЭЛЕКТРОСЕТИ» в системе энергоснабжения

З
АО «Горэлектросети» по своей природе является предприятием-посредником. Покупая электроэнергию у «Томскэнерго» оно обеспечивает бесперебойное электроснабжение города. Схематично место «Горэлектросети» в структуре энергоснабжения можно представить на рисунке 3.

Рис. 3 Место ЗАО «Горэлектросети» в системе энергоснабжения города


С
труктура потребителей «Горэлектросети» представлена на рисунке 4.

Рис. 4 Структура потребителей электроэнергии

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

Оперативно-диспетчерская служба является структурным подразделением предприятия и находится в прямом подчинении главного инженера. Среди задач решаемых оперативно-диспетчерской службой такие как:

1. Круглосуточный контроль над состоянием системы энергоснабжения.
   
2. Принятие решений по устранению аварийных ситуаций.
   
3. Накопление и обобщение статистики.
   
4. Прием в эксплуатацию новых объектов.
   
5. Планирование развития системы энергоснабжения, на основании накопленной статистики.
   
6. Планирование мероприятий по плановому обслуживанию объектов системы энергоснабжения.
   

4. Алгоритмы и структуры данных

4.1. структура базы данных

Представленная база данных соответствует реляционной технологии построения баз данных (БД). Реляционная схема БД представлена в приложении 4. Все таблицы БД можно условно разделить на три группы:

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

Таблицы первого типа предназначены для хранения информации об основных объектах предметной области. К таким таблицам относятся:

• 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 – внешний ключ, код улицы на которой расположена организация;
  
• HOUSE – номер здания, в котором находится организация;
  
• FLAT – номер помещения, в котором находится организация;
  
• ADD_INF – реквизиты и другая произвольная текстовая информация;
  

4.1.1.4. объект «абонент»

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

• ID – уникальный идентификатор абонента (лицевой счет);
  
• FIRSTNAME – имя абонента;
  
• FATHERNAME – отчество абонента;
  
• LASTNAME – фамилия абонента;
  
• FULLNAME – полное имя абонента, вычисляемое поле, формируется из FIRSTNAME, FATHERNAME и LASTNAME;
  
• STREET_ID – внешний ключ, код улицы, на которой проживает абонент;
  
• HOUSE – номер здания в котором проживает абонент;
  
• FLАТ – номер квартиры, в которой проживает абонент;
  
• PHONE – номер телефона абонента;
  

4.1.2. таблицы-справочники

Таблицы-справочники предназначены для хранения информации, которая часто используется в определении свойств некоторых объектов предметной области, и при этом редко изменяется и дополняется. К таблицам справочникам относятся:

• ABONENT_KINDS – содержит возможные виды зданий и сооружений потребляющих электроэнергию и их категории. Категория абонента означает степень его важности с точки зрения возможного отключения электроэнергии. К наивысшей первой категории относятся, например, спецлаборатории, больницы, поликлиники и корпуса ВУЗов; ко второй – детский сады и школы; к третьей – административные здания и жилые дома.
  
• ADD_EQUIPMENT – содержит информацию о дополнительном оборудовании которое может находится на подстанции. К дополнительному оборудованию относятся, например, ящик с песком, изоляционные коврики, ограждения и так далее.
  
• ACTION_KINDS – отражает возможные типы событий записанные в журнале подстанции. Например, текущий ремонт, осмотр, монтаж и так далее.
  
• CELL_KINDS – содержит возможные типы высоковольтных ячеек подстанции;
  
• SECTION_KINDS – содержит описание типов секций подстанции;
  
• STATION_KINDS – содержит типы подстанций;
  

Все таблицы-справочники состоят из первичного ключа ID и поля NAME, которое содержит описание характеристики.

4.1.3. Хранимые процедуры и триггеры

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

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

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

4.2. алгоритмы и структуры данных клиентской части программы

4.2.1. Навигация по данным

Структура базы данных, взаимосвязи объектов, их свойства представлены пользователю посредством визуальной компоненты TTreeView. Эта компонента является стандартным классом Windows и используется во многих приложениях Windows, например, в приложении Windows Explorer. Компонента предназначена для отображения информации в древовидной форме, то есть, способна отобразить некоторую иерархическую структуру объектов, находящихся в таких отношениях как «есть часть», «находится в», «обеспечивает электроэнергией» и другие. Таким образом, пользователь осуществляет навигацию по объектам в порядке их подчиненности друг другу. То есть навигация по данным организована так, что, начав с любого объекта, пользователь по его связям может перейти к любому связанному объекту.

4.2.2. компоненты визуализации данных

Для визуализации данных в программе использованы следующие компоненты Delphi:

• TLabel – используется для отображения названия характеристики или свойства объекта;
  
• TDBText – отображает текстовую информацию из базы данных, возможность редактирования информации отсутствует;
  
• TDBEdit – отображает текстовую информацию из базы данных, с возможностью редактирования;
  
• TDBMemo – отображает большие объемы текстовой информации из полей базы данных, имеющих тип BLOB.
  
• TDBTreeView – отображает текстовую информацию из базы данных в древовидной форме;
  

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

4.2.3. компоненты для связи с базой данных

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

• TDatabase – так называемый псевдоним базы данных;
  
• TQuery – компонента содержащая набор данных, полученных в результате выполнения SQL-запроса к серверу баз данных;
  
• TDataSourse – компонента-посредник между набором данных и компонентами визуального отображения данных;
  
• TUpdateSQL – компонента осуществляющая модификацию базы данных при помощи SQL-запросов, которые в ней содержатся;
  

Компонента TDatabase используется для переопределения параметров соединения приложения с базой данных. Вообще параметры соединения указываются при создании алиаса в утилите BDE, однако при необходимости внести изменения параметры соединения без использования компоненты TDatabase пользователь должен вручную настроить алиас в помощью утилиты BDE. Использование компоненты TDatabase дает возможность автоматически при необходимости изменять параметры соединения с базой данных без использования каких-либо утилит, в скрытом от пользователя режиме.

Для каждой таблицы базы данных в приложении имеются три компоненты: TQuery, TDataSource и TUpdateSQL. Компонента TQuery содержит набор данных полученных от сервера в результате SQL-запроса. Однако данные, возвращенные сервером, имеют атрибут «только для чтения», и не могут быть изменены. Использование компоненты TUpdateSQL дает пользователя иллюзию работы с «живыми» данными, то есть, внося изменения в свои локальные данные, они автоматически изменяются на сервере. Для связи компонентов визуализации данных и компонентов, которые получают информацию из базы данных, используется компонента TDataSource.

4.2.4. Использование механизма отложенных изменений

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

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

• меньшее количество транзакций;
  
• сокращение времени транзакций;
  
• сокращение сетевого трафика;