Сетевое управление
Функциональные группы задач управления. Архитектуры систем управления сетями. Разработка клиент-серверной системы управления базой данных в Delphi. Разработка структуры базы данных, клиентской программы. Управление пользователями. Форма остатков товаров.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 02.05.2012 |
| Размер файла | 2,2 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Введение
Любая сложная вычислительная сеть требует дополнительных специальных средств управления помимо тех, которые имеются в стандартных сетевых операционных системах. Это связано с большим количеством разнообразного коммуникационного оборудования, работа которого критична для выполнения сетью своих основных функций. Распределенный характер крупной корпоративной сети делает невозможным поддержание ее работы без централизованной системы управления, которая в автоматическом режиме собирает информацию о состоянии каждого концентратора, коммутатора, мультиплексора и маршрутизатора и предоставляет эту информацию оператору сети. Обычно система управления работает в автоматизированном режиме, выполняя наиболее простые действия по управлению сетью автоматически, а сложные решения предоставляя принимать человеку на основе подготовленной системой информации. Система управления должна быть интегрированной. Это означает, что функции управления разнородными устройствами должны служить общей цели обслуживания конечных пользователей сети с заданным качеством.
Сами системы управления представляют собой сложные программно-аппаратные комплексы, поэтому существует граница целесообразности применения системы управления - она зависит от сложности сети, разнообразия применяемого коммуникационного оборудования и степени его распределенности по территории. В небольшой сети можно применять отдельные программы управления наиболее сложными устройствами, например коммутатором, поддерживающим технику VLAN. Обычно каждое устройство, которое требует достаточно сложного конфигурирования, производитель сопровождает автономной программой конфигурирования и управления. Однако при росте сети может возникнуть проблема объединения разрозненных программ управления устройствами в единую систему управления, и для решения этой проблемы придется, возможно, отказаться от этих программ и заменить их интегрированной системой управления.
1. Сетевое управление
1.1 Функциональные группы задач управления
Системы управления корпоративными сетями существуют не очень давно. Одной из первых систем такого назначения, получившей широкое распространение, был программный продукт SunNet Manager, выпущенный в 1989 году компанией SunSoft. SunNet Manager был ориентирован на управление коммуникационным оборудованием и контроль трафика сети. Именно эти функции имеют чаще всего в виду, когда говорят о системе управления сетью.
Независимо от объекта управления, желательно, чтобы система управления выполняла ряд функций, которые определены международными стандартами, обобщающими опыт применения систем управления в различных областях. Существуют рекомендации ITU-T X.700 и близкий к ним стандарт ISO 7498-4, которые делят задачи системы управления на пять функциональных групп:
- управление конфигурацией сети и именованием;
- обработка ошибок;
- анализ производительности и надежности;
- управление безопасностью;
- учет работы сети.
Рассмотрим задачи этих функциональных областей управления применительно к системам управления сетями.
Управление конфигурацией сети и именованием (Configuration Management).Эти задачи заключаются в конфигурировании параметров как элементов сети (Network Element, NE), так и сети в целом. Для элементов сети, таких как маршрутизаторы, мультиплексоры и т.п., с помощью этой группы задач определяются сетевые адреса, идентификаторы (имена), географическое положение и пр.
Для сети в целом управление конфигурацией обычно начинается с построения карты сети, то есть отображении реальных связей между элементами сети и изменении связей между элементами сети - образование новых физических или логических каналов, изменение таблиц коммутации и маршрутизации.
Обработка ошибок (Fault Management). Эта группа задач включает выявление, определение и устранение последствий сбоев и отказов в работе сети. На этом уровне выполняется не только регистрация сообщений об ошибках, но и их фильтрация, маршрутизация и анализ на основе некоторой корреляционной модели, Фильтрация позволяет выделить из весьма интенсивного потока сообщений об ошибках, который обычно наблюдается в большой сети, только важные сообщения, маршрутизация обеспечивает их доставку нужному элементу системы управления, а корреляционный анализ позволяет найти причину, породившую поток взаимосвязанных сообщений (например, обрыв кабеля может быть причиной большого количества сообщений о недоступности сетей и серверов).
Устранение ошибок может быть как автоматическим, так и полуавтоматическим. В первом случае система непосредственно управляет оборудованием или программными комплексами и обходит отказавший элемент за счет резервных каналов и т.п. В полуавтоматическом режиме основные решения и действия по устранению неисправности выполняют люди, а система управления только помогает в организации этого процесса - оформляет квитанции на выполнение работ и отслеживает их поэтапное выполнение (подобно системам групповой работы).
Анализ производительности и надежности (Performance Management). Задачи этой группы связаны с оценкой на основе накопленной статистической информации таких параметров, как время реакции системы, пропускная способность реального или виртуального канала связи между двумя конечными абонентами сети, интенсивность трафика в отдельных сегментах и каналах сети, вероятность искажения данных при их передаче через сеть, а также коэффициент готовности сети или ее определенной транспортной службы. Функции анализа производительности и надежности сети нужны как для оперативного управления сетью, так и для планирования развития сети.
Результаты анализа производительности и надежности позволяют контролировать соглашение об уровне обслуживания (Service Level Agreement, SLA), заключаемое между пользователем сети и ее администраторами (или компанией, продающей услуги). Обычно в SLA оговариваются такие параметры надежности, как коэффициент готовности службы в течение года и месяца, максимальное время устранения отказа, а также параметры производительности, например, средняя и максимальная пропускная способности при соединении двух точек подключения пользовательского оборудования, время реакции сети (если информационная служба, для которой определяется время реакции, поддерживается внутри сети), максимальная задержка пакетов при передаче через сеть (если сеть используется только как транзитный транспорт). Без средств анализа производительности и надежности поставщик услуг публичной сети или отдел информационных технологий предприятия не сможет ни проконтролировать, ни тем более обеспечить нужный уровень обслуживания для конечных пользователей сети.
Управление безопасностью (Security Management). Задачи этой группы включают в себя контроль доступа к ресурсам сети (данным и оборудованию) и сохранение целостности данных при их хранении и передаче через сеть. Базовыми элементами управления безопасностью являются процедуры аутентификации пользователей, назначение и проверка прав доступа к ресурсам сети, распределение и поддержка ключей шифрования, управления полномочиями и т.п. Часто функции этой группы не включаются в системы управления сетями, а реализуются либо в виде специальных продуктов (например, системы аутентификации и авторизации Kerberos, различных защитных экранов, систем шифрования данных), либо входят в состав операционных систем и системных приложений.
Учет работы сети (Accounting Management). Задачи этой группы занимаются регистрацией времени использования различных ресурсов сети - устройств, каналов и транспортных служб. Эти задачи имеют дело с такими понятиями, как время использования службы и плата за ресурсы - billing. Ввиду специфического характера оплаты услуг у различных поставщиков и различными формами соглашения об уровне услуг, эта группа функций обычно не включается в коммерческие системы и платформы управления типа HP Open View, а реализуется в заказных системах, разрабатываемых для конкретного заказчика.
1.2 Архитектуры систем управления сетями
Схема менеджер - агент
В основе любой системы управления сетью лежит элементарная схема взаимодействия агента с менеджером. На основе этой схемы могут быть построены системы практически любой сложности с большим количеством агентов и менеджеров разного типа.
Рисунок 1.1. Взаимодействие агента, менеджера и управляемого ресурса
Агент является посредником между управляемым ресурсом и основной управляющей программой-менеджером. Чтобы один и тот же менеджер мог управлять различными реальными ресурсами, создается некоторая модель управляемого ресурса, которая отражает только те характеристики ресурса, которые нужны для его контроля и управления. Например, модель маршрутизатора обычно включает такие характеристики, как количество портов, их тип, таблицу маршрутизации, количество кадров и пакетов протоколов канального, сетевого и транспортного уровней, прошедших через эти порты.
Менеджер получает от агента только те данные, которые описываются моделью ресурса. Агент же является некоторым экраном, освобождающим менеджера от ненужной информации о деталях реализации ресурса. Агент поставляет менеджеру обработанную и представленную в нормализованном виде информацию. На основе этой информации менеджер принимает решения по управлению, а также выполняет дальнейшее обобщение данных о состоянии управляемого ресурса, например, строит зависимость загрузки порта от времени.
Для получения требуемых данных от объекта, а также для выдачи на него управляющих воздействий агент взаимодействует с реальным ресурсом некоторым нестандартным способом. Когда агенты встраиваются в коммуникационное оборудование, то разработчик оборудования предусматривает точки и способы взаимодействия внутренних узлов устройства с агентом. При разработке агента для операционной системы разработчик агента пользуется теми интерфейсами, которые существуют в этой ОС, например интерфейсами ядра, драйверов и приложений. Агент может снабжаться специальными датчиками для получения информации, например датчиками релейных контактов или датчиками температуры.
Менеджер и агент должны располагать одной и той же моделью управляемого ресурса, иначе они не смогут понять друг друга. Однако в использовании этой модели агентом и менеджером имеется существенное различие. Агент наполняет модель управляемого ресурса текущими значениями характеристик данного ресурса, и в связи с этим модель агента называют базой данных управляющей информации - Management Information Base, MIB. Менеджер использует модель, чтобы знать о том, чем характеризуется ресурс, какие характеристики он может запросить у агента и какими параметрами можно управлять.
Менеджер взаимодействует с агентами по стандартному протоколу. Этот протокол должен позволять менеджеру запрашивать значения параметров, хранящихся в базе MIB, а также передавать агенту управляющую информацию, на основе которой тот должен управлять устройством. Различают управление inband, то есть по тому же каналу, по которому передаются пользовательские данные, и управление out-of-band, то есть вне канала, по которому передаются пользовательские данные. Например, если менеджер взаимодействует с агентом, встроенным в маршрутизатор, по протоколу SNMP, передаваемому по той же локальной сети, что и пользовательские данные, то это будет управление inband. Если же менеджер контролирует коммутатор первичной сети, работающий по технологии частотного уплотнения FDM, с помощью отдельной сети Х.25, к которой подключен агент, то это будет управление out-of-band. Управление по тому же каналу, по которому работает сеть, более экономично, так как не требует создания отдельной инфраструктуры передачи управляющих данных. Однако способ out-of-band более надежен, так как он предоставляет возможность управлять оборудованием сети и тогда, когда какие-то элементы сети вышли из строя и по основным каналам оборудование недоступно.
Обычно менеджер работает с несколькими агентами, обрабатывая получаемые от них данные и выдавая на них управляющие воздействия. Агенты могут встраиваться в управляемое оборудование, а могут и работать на отдельном компьютере, связанном с управляемым оборудованием по какому-либо интерфейсу. Менеджер обычно работает на отдельном компьютере, который выполняет также роль консоли управления для оператора или администратора системы.
Структуры распределенных систем управления
В крупной корпоративной сети полностью централизованная система управления, построенная на базе единственного менеджера, вряд ли будет работать хорошо по нескольким причинам. Во-первых, такой вариант не обеспечивает необходимой масштабируемости по производительности, так как единственный менеджер вынужден будет обрабатывать весь поток сообщений от всех агентов, что при нескольких тысячах управляемых объектов потребует очень высокопроизводительной платформы для работы менеджера и перегрузит служебной управляющей информацией каналы передачи данных в той сети, где будет расположен менеджер. Во-вторых, такое решение не обеспечит необходимого уровня надежности, так как при отказе единственного менеджера будет потеряно управление сетью. В-третьих, в большой распределенной сети целесообразно располагать в каждом географическом пункте отдельным оператором или администратором, управляющим своей частью сети, а это удобнее реализовать с помощью отдельных менеджеров для каждого оператора.
Схема «менеджер - агент» позволяет строить достаточно сложные в структурном отношении распределенные системы управления.
Обычно распределенная система управления включает большое количество связок менеджер - агент, которые дополняются рабочими станциями операторов сети, с помощью которых они получают доступ к менеджерам (рис. 1.2).
Каждый агент собирает данные и управляет определенным элементом сети. Менеджеры, иногда также называемые серверами системы управления, собирают данные от своих агентов, обобщают их и хранят в базе данных. Операторы, работающие за рабочими станциями, могут соединиться с любым из менеджеров и с помощью графического интерфейса просмотреть данные об управляемой сети, а также выдать менеджеру некоторые директивы по управлению сетью или ее элементами.
Рисунок 1.2. Распределенная система управления на основе нескольких менеджеров и рабочих станций
Наличие нескольких менеджеров позволяет распределить между ними нагрузку по обработке данных управления, обеспечивая масштабируемость системы.
Как правило, связи между агентами и менеджерами носят более упорядоченный характер, чем тот, который показан на рисунке 1.2. Чаще всего используются два подхода к их соединению - одноранговый (рис. 1.3) и иерархический (рис. 1.4).
Рисунок 1.3. Одноранговые связи между менеджерами
Рисунок 1.4. Иерархические связи между менеджерами
В случае одноранговых связей каждый менеджер управляет своей частью сети на основе информации, получаемой от нижележащих агентов. Центральный менеджер отсутствует. Координация работы менеджеров достигается за счет обмена информацией между базами данных каждого менеджера.
Одноранговое построение системы управления сегодня считается неэффективным и устаревшим. Обычно оно вызвано тем обстоятельством, что элементарные системы управления построены как монолитные системы, которые первоначально не были ориентированы на модульность системы (например, многие системы управления, разработанные производителями оборудования, не поддерживают стандартные интерфейсы для взаимодействия с другими системами управления). Затем эти менеджеры нижнего уровня стали объединяться для создания интегрированной системы управления сетью, но связи между ними оказалось возможным создавать только на уровне обмена между базами данных, что достаточно медленно. Кроме того, в базах данных таких менеджеров накапливается слишком детальная информация об управляемых элементах сети (так как первоначально эти менеджеры разрабатывались как менеджеры нижнего уровня), вследствие чего такая информация малопригодна для координации работы всей сети в целом. Такой подход к построению системы управления называется подходом «снизу вверх».
Гораздо более гибким является иерархическое построение связей между менеджерами. Каждый менеджер нижнего уровня выполняет также функции агента для менеджера верхнего уровня. Такой агент работает уже с гораздо более укрупненной моделью (MIB) своей части сети, в которой собирается именно та информация, которая нужна менеджеру верхнего уровня для управления сетью в целом. Обычно для разработки моделей сети на разных уровнях проектирование начинают с верхнего уровня, на котором определяется состав информации, требуемой от менеджеров-агентов более низкого уровня, поэтому такой подход назван подходом «сверху вниз». Он сокращает объемы информации, циркулирующей между уровнями системы управления, и приводит к гораздо более эффективной системе управления.
Модель TMN в наибольшей степени соответствует иерархической архитектуре связей между менеджерами, хотя известны реализации принципов TMN и в одноуровневых архитектурах.
2. Разработка клиент-серверной системы управления базой данных в Borland Delphi
2.1 Разработка структуры базы данных
Создание новой нормализованной реляционной базы данных Access осуществляется в соответствии с ее структурой, полученной в результате проектирования. Структура реляционной базы данных определяется составом таблиц и их взаимосвязями. Взаимосвязи между двумя таблицами реализуются через ключ связи, входящий в состав полей связываемых таблиц
Создание реляционной базы данных с помощью СУБД начинается с формирования структуры таблиц. При этом определяется состав полей и задается их описание. После определения структуры таблиц создается схема данных, в которой устанавливаются связи между таблицами.
Рисунок 2.1 - Схема данных БД «Магазин»
2.2 Создание базы данных
В данной работе представлено создание приложения и базу данных для архитектуры клиент-сервер. При использовании архитектуры клиент-сервер, сами базы данных находятся на ПК, который выполняет роль сервера. При этом сервером называют не только сам компьютер, но и программу, которая обеспечивает работу с базами данных: позволяет подключаться к ним зарегистрированным пользователям, следит за целостностью и непротиворечивостью данных, имеет удобные средства для архивации и восстановления баз данных.
InterBase
InterBase представляет собой полнофункциональный SQL-сервер. Сервер баз данных - это программа или служба, которая выполняется на сетевом компьютере (сервере), где физически расположена сама база данных. InterBase - очень надежный сервер БД, при этом он не требователен к ресурсам ПК, благодаря чему является одним из самых популярных SQL-серверов на рынке программного обеспечения.
2.2.1 Создание таблиц
Создание таблиц осуществляется запросом CREATE TABLE, который можно выполнить с помощью утилиты IBConsole. Полный синтаксис запроса такой:
CTRATE TABLE Имя_таблицы [EXTERNAL [FILE] Имя_файла] (<описание_столбца_1> [, …, <описание_столбца_n>] | <ограничение_таблицы> …);
Рисунок 2.2 - Создание таблицы Производители
Рисунок 2.3 - Создание таблицы Производители
Рисунок 2.4 - Создание таблицы Права пользователей
Рисунок 2.5 - Создание таблицы Продажи
Рисунок 2.6 - Создание таблицы Товары
2.2.2 Реализация автоинкрементного поля
Для создания поля, значение которого автоматически увеличивается на единицу, нужно сделать несколько действий:
1. Создать генератор для ключевого поля. Ключевое поле должно иметь тип INTEGER, быть NOT NULL и объявлено как PRIMARY KEY. Собственно, генератор можно использовать для любого автоинкрементного поля, не обязательно ключевого. Но чаще всего генераторы используют именно для ключевых полей.
2. Присвоить генератору значение 0 (или иное, если таблица перенесена из другой БД, и уже содержит записи).
3. Создать триггер BEFORE INSERT, увеличивающий это значение на 1.
В базе данных имеется таблица Tovars, в которой первое поле ID объявлено как INTEGER NOT NULL. К сожалению, поле не было объявлено, как ключевое PRIMARY KEY. Изменим таблицу, добавив в нее первичный ключ по полю ID:
ALTER TABLE TOVAR ADD PRIMARY KEY (ID);
Теперь сделаем это поле автоинкрементным:
/*Создаем генератор*/
CREATE GENERATOR Gen_Tovar;
/*Присваиваем генератору начальное значение*/
SET GENERATOR Gen_Tovar TO 0;
/*Создаем триггер*/
SET TERM ^;
CREATE TRIGGER Tr_Tovar FOR Tovar
ACTIVE BEFORE INSERT
AS
BEGIN
IF (NEW.ID IS NULL) THEN
NEW.ID = GEN_ID (Gen_Tovar, 1);
END^
SET TERM;^
/* Завершаем транзакцию: */
COMMIT;
Операторы из данного примера создают автоматическое увеличение значения поля на 1. Таким образом, вставка первой же записи установит значение 1. Следующая запись будет 2 и так далее. Все это реализуется в пределах транзакции, то есть даже если множество пользователей вносит изменения в таблицу, значения генератора всегда будут уникальны.
2.3 Разработка клиентской программы
2.3.1 Разработка формы авторизации пользователя
Соединение клиентской программы с базой данных производится с помощью одного из механизмов управления БД. Из стандартной библиотеки компонентов это, как правило, BDE, dbExpress и InterBase Express (IBX).
Создадим форму входа в программу разместим элементы TDBLookupComboBox (для выбора логина) и TMaskEdit (для ввода пароля). Для связи с базой данных нам потребуются компоненты Database и Table вкладки BDE, а также DataSource с вкладки Data Access для связи таблицы с элементами управления.
Рисунок 2.7 - Форма авторизации пользователя
Далее, с компонентом Database нужно сделать некоторые настройки:
- В свойстве AliasName выберите псевдоним BDMagazin.
- В свойстве DatabaseName указать название базы данных BDMagazin.
- Свойство LoginPrompt переводим False, чтобы программа при запуске не запрашивала имя пользователя и пароль.
Раскрываем сложное свойство Params и указываем туда следующие параметры:
Рисунок 2.8. - Редактирование свойства Params
Теперь свойство Connected можно перевести в True.
Для обработчика события onClick кнопки Ок прописывается обработчик, который определяет, правильно ли введен пароль или нет.
procedure TfrmVxod.btnOkClick (Sender: TObject);
var
pravo: boolean;
begin
// Проверка на пустые значения
if cmbLogin. Text='. 'then
begin
ShowMessage ('Не заполнено поле Логин!');
exit;
end;
// проверка на соответсвие пароля
if cmbLogin. KeyValue = edtPassword. Text then
begin
// открытие главной формы
frmmain. Show;
frmVxod. Hide;
// заполнение значений глобальных переменных прав пользователя
id_user:= ID.text;
name_user:= cmbLogin. Text;
frmmain. Caption:= 'БД «Магазин» /'+ name_user;
if read. Text='+' then pravo:=true else pravo:=false;
user_read:=pravo;
if date. Text='+' then pravo:=true else pravo:=false;
user_tovar:=pravo;
if sale. Text='+' then pravo:=true else pravo:=false;
user_sale:=pravo;
if admin. Text='+' then pravo:=true else pravo:=false;
user_admin:=pravo;
if not user_read then
frmmain.dbgTovars. Visible:=FALSE
ELSE
frmmain.dbgTovars. Visible:=TRUE
end
else
ShowMessage ('Логин или пароль неверный!');
end;
серверный программа товар сетевой
2.3.2 Разработка формы списка остатков товара
На основной форме приложения отображаются данные об остатках товара в магазине. Для этой цели используется компонент TDBGrid и связи с базой данных используются компоненты Table (вкладки BDE), а также DataSource с вкладки Data Access для связи таблицы с сеткой.
Рисунок 2.9 - Основная форма приложения
С основной формы вызвать формы для добавления, редактирования и удаления товара, для просмотра списка продаж, формы администрирования базы и пользователей. Все действия можно выполнять только при наличии у пользователя необходимых прав. Для вызова данных функции используется компонент TToolBar, действия с товарами можно вызвать как из главного меню, так и с помощью панели инструментов.
Листинг формы представлен в приложении.
Рисунок 2.10 - Форма добавления товара
Обработчик события нажатия на кнопку Ок (добавление нового товара).
// Проверка на пустые значения
if edtName. Text='. 'then
begin
ShowMessage ('Не заполнено поле Наименование!');
exit;
end;
if cmProizvod. Text=''then
begin
ShowMessage ('Не заполнено поле Производитель!');
exit;
end;
// добавление записи в таблицу Товары
Query.SQL. Clear;
s:='insert into tovars (name, price, kol, id_supplier) values (' + QuotedStr (edtname. Text)+', '+ edtPrice. Text + ', '+ edtkol. Text+', '+VarToStr (cmProizvod. KeyValue)+')';
Query.SQL. Add(s);
Query. ExecSQL;
tbltovar. Refresh;
// закрыите окна
frmaddtovar. Close;
2.3.3 Управление пользователями
У каждого пользователя приложения существует 4 вида полномочий:
- Только чтение - пользователь может просматривать данные о товарах и покупках, но не может их изменять.
- Добавление / Редактирование покупок - пользователь может вводить новые покупки, а также удалять уже существующие.
- Право администрирования - пользователь имеет право добавлять, редактировать, удалять пользователей, делать резервное копирование базы.
Рисунок 2.11 Окно формы редактирования данных пользователя
2.3.4 Резервирования базы данных
Для реализации функции архивирования базы данных необходимо использовать компонент с вкладки InterBase admin - TIBBackupService, который осуществляет архивацию базы данных.
Рисунок 2.12 Окно формы резервирования базы данных
Обработчик события нажатия на кнопку Архивация (создание резервной копии базы).
procedure TForm1. Button1Click (Sender: TObject);
begin
// проверяем задание условий
if Edit1. Text='' then
begin
ShowMessage ('Не задан архивный файл!');
Exit
end;
if (Edit2. Text='') or not FileExists (Edit2. Text) then
begin
ShowMessage ('Не задан или не существует файл БД!');
Exit
end;
if (Edit3. Text='') or not FileExists (Edit3. Text) then
begin
ShowMessage (' Не задан или не существует файл сервера!');
Exit
end;
// Архивируем:
with IBBackupService1 do
begin
if FileExists (Edit1. Text) then
DeleteFile (Edit1. Text);
BackupFile. Clear;
BackupFile. Add (Edit1. Text);
Params. Clear;
Params. Add ('USER_NAME='+Edit4. Text);
Params. Add ('PASSWORD='+Edit5. Text);
DatabaseName:= Edit2. Text;
ServerName:= Edit3. Text;
Active:= True; // соединяемся с БД
Screen. Cursor:= crHourGlass;
Label5. Caption:= 'Идет архивация…';
ServiceStart; // Стартуем архивацию
while IsServiceRunning do // Конец?
Application. ProcessMessages; // - Нет
Active:= False; // Отсоединяемся от бд
ShowMessage ('Архивация базы заверешена.');
Label5. Caption:='';
Screen. Cursor:= crDefault;
end;
end.
Заключение
Мониторинг и анализ сети представляют собой важные этапы контроля работы сети. Для выполнения этих этапов разработан ряд средств, применяемых автономно в тех случаях, когда применение интегрированной системы управления экономически неоправданно.
В состав автономных средств мониторинга и анализа сети входят встроенные средства диагностики, анализаторы протоколов, экспертные системы, сетевые анализаторы, кабельные сканеры и тестеры, многофункциональные приборы.
Анализаторы протоколов чаще всего представляют собой специальное программное обеспечение для персональных компьютеров и ноутбуков, которое переводит сетевой адаптер компьютера в режим «беспорядочного» захвата всех кадров. Анализатор протоколов выполняет декодирование захваченных кадров для вложенных пакетов протоколов всех уровней, включая прикладной.
Сетевые анализаторы представляют собой прецизионные приборы для сертификации кабельных систем по международным стандартам. Кроме того, эти устройства могут выполнять некоторые функции анализаторов протоколов.
Кабельные сканеры являются портативными приборами, которые могут измерить электрические параметры кабелей, а также обнаружить место повреждения кабеля. Кабельные тестеры представляют собой наиболее простые портативные приборы, способные обнаружить неисправность кабеля.
Многофункциональные портативные приборы сочетают в себе функции кабельных сканеров и анализаторов протоколов. Они снабжены многострочными дисплеями, контекстно-чувствительной системой помощи, встроенным микропроцессором с программным обеспечением и позволяют выполнять комплексную проверку сегментов сети на всех уровнях, от физического (что не умеют делать анализаторы протоколов), до прикладного. Отличаются от анализаторов протоколов поддержкой только базового набора протоколов локальных сетей.
Список литературы
1. Олифер В.Г., Н.А. Олифер. Компьютерные сети. Принципы, технологии, протоколы. Учебник. СПб.:Питер
2. Фаронов В.В. Программирование баз данных в Delphi 7. Учебный курс - СПб.:Питер, 2006
3. Ачкасов В.Ю. Учебный курс - Программирование баз данных в Delphi.
Приложение
Листинг основной формы
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, DB, DBTables, StdCtrls, ExtCtrls, DBCtrls, Grids, DBGrids, Unit2,
ComCtrls, ToolWin, unit3, unit5, unit7, Menus, ImgList;
type
TfrmMain = class(TForm)
dbgTovars: TDBGrid;
AddSale: TButton;
tblTovars: TTable;
dtsrTovars: TDataSource;
ToolBar1: TToolBar;
btnAddTovar: TToolButton;
ToolButton2: TToolButton;
StatusBar1: TStatusBar;
Panel2: TPanel;
ToolButton1: TToolButton;
btnEdit: TToolButton;
ToolButton4: TToolButton;
btnDelete: TToolButton;
ToolButton7: TToolButton;
btnRefref: TToolButton;
tblTovarsID: TIntegerField;
tblTovarsNAME: TStringField;
tblTovarsPRICE: TFloatField;
tblTovarsKOL: TFloatField;
tblTovarsID_SUPPLIER: TSmallintField;
dtsrSupplier: TDataSource;
tblSupplier: TTable;
tblTovarsProizvod: TStringField;
MainMenu1: TMainMenu;
N1: TMenuItem;
users: TMenuItem;
N2: TMenuItem;
N3: TMenuItem;
N4: TMenuItem;
N5: TMenuItem;
N6: TMenuItem;
N7: TMenuItem;
ImageList: TImageList;
N8: TMenuItem;
N9: TMenuItem;
procedure tnSddTovarClick (Sender: TObject);
procedure btnRefrefClick (Sender: TObject);
procedure btnDeleteClick (Sender: TObject);
procedure btnEditClick (Sender: TObject);
procedure AddSaleClick (Sender: TObject);
procedure FormClose (Sender: TObject; var Action: TCloseAction);
procedure N6Click (Sender: TObject);
procedure usersClick (Sender: TObject);
procedure N9Click (Sender: TObject);
procedure N7Click (Sender: TObject);
private
{Private declarations}
public
{Public declarations}
end;
var
frmMain: TfrmMain;
implementation
uses Unit8, Unit10, UnitBackUp;
{$R *.dfm}
procedure TfrmMain.tnSddTovarClick (Sender: TObject);
begin
// обработчик нажатия на кнопку Добавить товар
if user_tovar then
frmAddTovar. Visible:=true
else
ShowMessage ('Нет прав на добавление нового товара!');
end;
procedure TfrmMain.btnRefrefClick (Sender: TObject);
begin
// обновление списка товаров
tbltovars. Refresh
end;
procedure TfrmMain.btnDeleteClick (Sender: TObject);
begin
// обработчик нажатия на кнопку Удалить товар
if user_tovar then
BEGIN
if MessageDlg ('Вы действительно хотите удалить?', mtConfirmation, [mbYes, mbNo], 0) = mrYes then
tbltovars. Delete;
end
else
ShowMessage ('Нет прав на удаление товара!');
end;
procedure TfrmMain.btnEditClick (Sender: TObject);
begin
// обработчик нажатия на кнопку Редактировать товар
if user_tovar then
frmEdit. Visible:=true
else
ShowMessage ('Нет прав на редактирование товара!');
end;
procedure TfrmMain. AddSaleClick (Sender: TObject);
begin
// обработчик нажатия на кнопку Продажи
if user_read then
frmSale. Visible:=true
else
ShowMessage ('Нет прав на просмотр!');
end;
procedure TfrmMain. FormClose (Sender: TObject; var Action: TCloseAction);
begin
// закрытие проложения
Application. Terminate;
end;
procedure TfrmMain.N6Click (Sender: TObject);
begin
// закрытие проложения
Application. Terminate;
end;
procedure TfrmMain.usersClick (Sender: TObject);
begin
// открыть окно учетной записи
if user_admin then
frmUsers. Show
else
ShowMessage ('Нет прав администратора!');
end;
procedure TfrmMain.N9Click (Sender: TObject);
begin
// открываем окно для резервного копирования
if user_admin then
form1. Show
else
ShowMessage ('Нет прав администратора!');
end;
procedure TfrmMain.N7Click (Sender: TObject);
begin
// закрытие проложения
Application. Terminate;
end;
end.
Размещено на Allbest.ru
Подобные документы
Даталогическая и инфологическая модели системы управления базой данных футбольного клуба. Обоснование выбора даталогической модели данных. Разработка структуры и системы управления базой данных. Выбор системы программирования, создание форм ввода.
курсовая работа [406,0 K], добавлен 24.12.2014Классификация баз данных. Выбор системы управления базами данных для создания базы данных в сети. Быстрый доступ и получение конкретной информации по функциям. Распределение функций при работе с базой данных. Основные особенности иерархической модели.
отчет по практике [1,2 M], добавлен 08.10.2014Разработка информационной системы административного управления. Выбор языка и среды программирования. Структура взаимодействия информации. Требования к программно-аппаратному окружению. Создание программы в Delphi и связывание ее с базой данных.
курсовая работа [1010,9 K], добавлен 08.10.2015Появление системы управления базами данных. Этапы проектирования базы данных "Строительная фирма". Инфологическая и даталогическая модель данных. Требования к информационной и программной совместимости для работы с базой данных "Строительная фирма".
курсовая работа [93,0 K], добавлен 31.03.2010Создание системы управления базой данных для управления массивом информации множеством одновременно работающих пользователей. Изучение и оценка потерь при данном уровне автоматизации. Разработка схемы потоков для выбранного объекта автоматизации.
отчет по практике [59,7 K], добавлен 05.03.2011Проектирование физической и логической моделей удаленной базы данных для АЗС. Разработка базы данных в СУБД Firebird с помощью утилиты IBExpert. Создание клиентского приложения для Windows с использованием клиент-серверной технологии в среде C++ Builder.
курсовая работа [3,9 M], добавлен 18.01.2017Теоретические аспекты СУБД. Основные понятия. Функциональные возможности СУБД. Архитектура систем управления. Разработка базы данных. Крупные массивы данных размещают, как правило, отдельно от исполняемого программы, и организуют в виде базы данных.
курсовая работа [30,5 K], добавлен 23.02.2006СУБД - многопользовательские системы управления базой данных, специализирующиеся на управлении массивом информации. Запросы на выборку и изменение данных, формирование отчетов по запросам выборки. Схема базы данных. Программа по управлению базой данных.
реферат [1,9 M], добавлен 27.12.2013Назначение, классификация, перспективы развития автоматизированных систем управления персоналом. Разработка программы: назначение и условия применения, характеристика объекта автоматизации, разработка структуры базы данных, объекты конфигурации системы.
дипломная работа [1,8 M], добавлен 21.04.2009Реляционные базы данных как часть корпоративных информационных систем, их построение по принципам клиент-серверной технологии. Основные характеристики СУБД Firebird. Проектирование базы данных для информационной системы "Компьютерные комплектующие".
курсовая работа [1,9 M], добавлен 28.07.2013
