Конспект лекций по курсу СД.Ф.2.Корпоративные информационные системы
advertisement
Конспект лекций
по курсу
СД.Ф.2.Корпоративные информационные системы
1
Лекция № 1. Понятие о сетях. Корпоративные информационные системы. Структура и
назначение КИС. Характеристика. Требования к организации КИС. Процессы. Многоуровневая
организация КИС. ....................................................................................................................................... 6
1.1
Понятие о сетях. Что такое сеть. ............................................................................................... 6
1.2
Компоненты сети. ....................................................................................................................... 7
1.3
Понятие об корпоративных информационных системах. ....................................................... 8
1.4
Структура КИС............................................................................................................................ 9
1.5
Назначение КИС. ...................................................................................................................... 11
1.6
Характеристика. ........................................................................................................................ 11
1.7
Требования к организации КИС. ............................................................................................. 12
1.8
Процессы.................................................................................................................................... 13
1.9
Многоуровневая организация сети. ........................................................................................ 14
1.10 Литература ................................................................................................................................. 16
2
Лекция № 2. Базовые концепции сетевой архитектуры. Обмен между уровнями.
Горизонтальные отношения – протоколы. Вертикальные отношения – интерфейсы. Передача и
приём данных по сети. .............................................................................................................................. 16
2.1
Базовые концепции сетевой архитектуры. ............................................................................. 16
2.2
Обмен между уровнями ............................................................................................................ 16
2.3
Горизонтальные отношения – протоколы .............................................................................. 17
2.4
Вертикальные отношения – интерфейсы................................................................................ 17
2.5
Передача и приём данных по сети. ......................................................................................... 17
2.6
Литература ................................................................................................................................. 18
3
Лекция № 3. Физические среды установления соединения. Построение локальных и
глобальных связей. Определение критериев. Технология. Каналы передачи данных. ..................... 18
3.1
Физические среды установления соединения. ....................................................................... 18
3.2
Построение локальных и корпоративных связей. ................................................................ 19
3.3
Литература ................................................................................................................................. 22
4
Лекция № 4. Административное управление КИС. Функции. Организация. Управление
сетевой адресацией. Протокол TCP/IP .................................................................................................... 22
4.1
Административное управление КИС. ..................................................................................... 22
4.2
Функции административного управления. ............................................................................. 23
4.3
Организация административного управления. ...................................................................... 24
4.4
IP-адреса..................................................................................................................................... 26
4.5
Литература ................................................................................................................................. 27
5
Лекция № 5. Структура корпораций и предприятий. Архитектура корпоративных
информационных систем (КИС). Исследования настоящей сети. Установка приоритетов.
Интегрирование сетей с использованием модели, основанной на сервисах. Создание
информационного плана. ......................................................................................................................... 27
5.1
Структура корпораций и предприятий. .................................................................................. 28
5.2
Архитектура корпоративных информационных систем (КИС). .......................................... 28
5.3
Интегрирование сетей с использованием модели, основанной на сервисах. ..................... 31
5.4
Сервисы уровня предприятия .................................................................................................. 32
5.5
Сервисы уровня подразделения ............................................................................................... 33
5.6
Сервисы уровня отдела............................................................................................................. 33
5.7
Сервисы уровня рабочего места .............................................................................................. 34
5.8
Создание информационного плана. ........................................................................................ 34
5.9
Литература ................................................................................................................................. 36
6
Лекция № 6. Пример диаграммы сети предприятия. Общие принципы именований ПК.
Программное обеспечение ПК. Доменная структура организации. ................................................... 36
6.1
Общие принципы именований ПК .......................................................................................... 36
1
6.2
Программное обеспечение ПК. ............................................................................................... 37
6.3
Основные понятия доменной структуры организации. ........................................................ 38
6.4
Планирование доменной структуры организации. ................................................................ 40
6.5
Множество независимых направлений бизнеса .................................................................... 41
6.6
Крупная организация ................................................................................................................ 42
6.7
Офисы подразделений .............................................................................................................. 43
6.8
Защищённые домены ................................................................................................................ 43
6.9
Рекомендации по управлению и администрированию.......................................................... 44
6.10 Рекомендации по расположению ............................................................................................ 44
6.11 Литература ................................................................................................................................. 45
7
Лекция № 7 Контроль доступа. Бюджеты пользователей. Подсчёт времени репликации.
Организация безопасности и уровень защиты C2. Соглашение об именах. Устранение
неисправностей ......................................................................................................................................... 45
7.1
Контроль доступа ...................................................................................................................... 45
7.2
Бюджеты пользователей ........................................................................................................... 45
7.3
Права пользователя ................................................................................................................... 46
7.4
Формирование групп пользователей с одинаковыми потребностями ................................. 49
7.5
Субъекты и имперсонация ....................................................................................................... 50
7.6
Информация по безопасности объектов (права доступа) ..................................................... 51
7.6.1
Типы объектов ................................................................................................................... 51
7.6.2
Список контроля доступа и его элементы ...................................................................... 51
7.6.3
Маски доступа ................................................................................................................... 52
7.6.4
Наследование контроля доступа...................................................................................... 53
7.6.5
Проверка доступа .............................................................................................................. 53
7.7
События безопасности, подлежащие аудиту ......................................................................... 53
7.8
Подсчёт времени репликации .................................................................................................. 55
7.9
Организация безопасности и уровень защиты C2 ................................................................. 56
7.10 Соглашение об именах доменов .............................................................................................. 56
7.11 Соглашение об именах групп .................................................................................................. 57
7.12 Соглашение об именах пользователей.................................................................................... 57
7.13 Матрица выбора домена ........................................................................................................... 57
7.14 Вопросы, помогающие выбрать схему расположения .......................................................... 58
7.14.1 Требования к аппаратуре.................................................................................................. 58
7.14.2 Необходимое количество доменов .................................................................................. 59
7.14.3 Необходимое количество BDC ........................................................................................ 59
7.14.4 Устранение неисправностей ............................................................................................ 60
7.15 Просмотр разделяемых ресурсов ............................................................................................ 60
7.16 Доступ к разделяемым ресурсам сервера ............................................................................... 60
7.17 Не способность BDC аутентифицировать пользовательский пароль .................................. 60
7.18 Предотвращение существования нескольких PDC в одном домене.................................... 61
7.19 Специальные символы в имени домена .................................................................................. 61
8
Лекция № 8. Сервис NetLogon. Журнал изменений. Частичная и полная синхронизация.
Аутентификация пользователя. Доверительные отношения. Политика доменной безопасности.
Вход в систему и процесс аутентификации ........................................................................................... 61
8.1
Сервис NetLogon ....................................................................................................................... 62
8.2
Журнал изменений .................................................................................................................... 62
8.3
Частичная и полная синхронизация ........................................................................................ 62
8.4
Аутентификация пользователя ................................................................................................ 62
8.5
Домены серверов Windows ...................................................................................................... 63
8.5.1
Серверы-члены домена ..................................................................................................... 63
8.5.2
Доверительные отношения .............................................................................................. 63
8.5.3
Политика доменной безопасности .................................................................................. 64
8.6
Бюджеты компьютеров и защищенные каналы связи ........................................................... 64
8.7
Безопасность в смешанных операционных средах ................................................................ 65
2
8.8 Клиенты рабочих групп .................................................................................................. 65
8.9
Клиенты Windows ..................................................................................................................... 66
8.9.1
Вход в систему и процесс аутентификации ................................................................... 66
8.9.2
Интерактивный и удаленный вход .................................................................................. 67
9
Лекция № 9 Оптимизация существующей сети. Рекомендации сетевым инженерам. Аппаратные
средства клиента и сервера сети ............................................................................................................ 67
9.1
Исходные данные ...................................................................................................................... 68
9.2
Рекомендации сетевым инженерам ......................................................................................... 69
9.2.1
Шаг 1: Определение факторов, влияющих на работу системы .................................... 69
9.2.2
Шаг 2: Определение идеальной "золотой" конфигурации ........................................... 69
9.2.3
Шаг 3: Определение стоимости модернизации ............................................................. 70
9.2.4
Шаг 4: Разработка плана мероприятий ........................................................................... 70
9.3
Аппаратные средства клиента и сервера сети ........................................................................ 71
9.4
Какое оборудование установлено в сети ................................................................................ 72
9.5
Как достичь желаемых результатов ........................................................................................ 73
9.6
Серверы ...................................................................................................................................... 73
9.7
Аппаратные средства поддержки соединения ....................................................................... 74
9.8
Коммутаторы (Ethernet) ............................................................................................................ 74
9.9
Ценовая конкуренция и разумное приобретение ................................................................... 75
9.10 Протоколы ................................................................................................................................. 75
9.11 Поддержка клиентов сети ........................................................................................................ 76
9.12 Резюме ........................................................................................................................................ 76
10
Лекция № 10 Развёртывание новой сети. Состав группы разработки. Определение
коммерческих требований. Определение сетевой модели. Принятие окончательных решений.
Разработка стандартов. Разработка мероприятий восстановления работоспособности. Система
мониторинга сети. Обучение пользователей ....................................................................................... 77
10.1 Состав группы разработки ....................................................................................................... 78
10.2 Определение коммерческих требований ................................................................................ 79
10.3 Разбиение сети ........................................................................................................................... 80
10.4 Создание логической структуры ............................................................................................. 80
10.5 Создание физической структуры............................................................................................. 80
10.6 Определение сетевой модели ................................................................................................... 81
10.7 Принятие окончательных решений ......................................................................................... 82
10.8 Создание тестовой лаборатории .............................................................................................. 84
10.9 Оценка пропускной способности ............................................................................................ 85
10.10
Выбор аппаратных средств установления соединений ..................................................... 85
10.11
Документация ........................................................................................................................ 86
10.12
Определение стоимости и времени реализации проекта .................................................. 87
10.13
Организация узла эксплуатационных испытаний ............................................................. 87
10.14
Разработка стандартов .......................................................................................................... 88
10.15
Администрирование ............................................................................................................. 90
10.16
Разработка мероприятий восстановления работоспособности и поддержки сети ......... 91
10.17
Система мониторинга сети................................................................................................... 92
10.18
Реализация ............................................................................................................................. 93
10.19
Обучение пользователей ...................................................................................................... 93
10.20
Анализ мнений пользователей ............................................................................................. 94
10.21
«Разбор полетов» .................................................................................................................. 94
10.22
Резюме .................................................................................................................................... 95
11
Лекция № 11 Введение в базы данных. Определение термина «база данных». История баз
данных ........................................................................................................................................................ 95
11.1 Введение в базы данных ........................................................................................................... 95
11.2 Определение термина «база данных» ..................................................................................... 96
11.2.1 Самодокументированность .............................................................................................. 96
11.2.2 База данных — это собрание интегрированных записей .............................................. 97
3
11.2.3 База данных является моделью модели .......................................................................... 97
11.3 История баз данных .................................................................................................................. 98
11.4 Организационный контекст ..................................................................................................... 98
11.5 Реляционная модель ................................................................................................................. 99
11.6 Коммерческие СУБД для микрокомпьютеров ....................................................................... 99
11.7 Клиент-серверные приложения баз данных ......................................................................... 100
11.8 Базы данных с использованием интернет-технологий........................................................ 101
11.9 Распределенные базы данных ................................................................................................ 101
11.10
Объектно-ориентированные СУБД ................................................................................... 102
11.11
Резюме .................................................................................................................................. 102
12
Лекция № 12 Введение в разработку баз данных. СУБД. Создание базы данных.
Компоненты приложения. Процесс разработки базы данных ............................................................ 103
12.1 Введение в разработку баз данных........................................................................................ 103
12.2 База данных ............................................................................................................................. 103
12.3 Данные пользователя .............................................................................................................. 104
12.4 Метаданные ............................................................................................................................. 105
12.5 Индексы ................................................................................................................................... 106
12.6 Метаданные приложений ....................................................................................................... 107
12.7 СУБД ........................................................................................................................................ 107
12.8 Подсистема средств проектирования .................................................................................... 107
12.9 Подсистема обработки............................................................................................................ 108
12.10
Ядро СУБД .......................................................................................................................... 108
12.11
Создание базы данных ........................................................................................................ 108
12.12
Пример схемы базы данных ............................................................................................... 109
12.13
Таблицы ............................................................................................................................... 109
12.14
Связи..................................................................................................................................... 109
12.15
Домены ................................................................................................................................. 109
12.16
Деловой регламент .............................................................................................................. 110
12.17
Создание таблиц .................................................................................................................. 110
12.18
Определение связей ............................................................................................................ 110
12.19
Компоненты приложения ................................................................................................... 111
12.20
Формы .................................................................................................................................. 111
12.21
Процесс разработки базы данных ..................................................................................... 112
12.22
Общие стратегии ................................................................................................................. 112
12.23
Моделирование данных ...................................................................................................... 113
12.24
Моделирование данных как делание выводов ................................................................. 113
12.25
Моделирование в многопользовательских системах ...................................................... 114
12.26
Недоразумения по поводу термина «модель» .................................................................. 114
12.27
Резюме .................................................................................................................................. 114
13
Лекция № 13 Реляционная модель и нормализация. Функциональные зависимости. .......... 115
13.1 Реляционная модель ............................................................................................................... 116
13.2 Функциональные зависимости .............................................................................................. 117
13.3 Ключи ....................................................................................................................................... 118
13.4 Резюме ...................................................................................................................................... 119
14
Лекция № 14 Язык SQL. Основные операторы языка SQL ...................................................... 120
14.1 Язык SQL ................................................................................................................................. 121
14.2 Основные операторы языка SQL ........................................................................................... 121
14.3 Основные соглашения по языку SQL ................................................................................... 121
14.4 Группы операторов языка SQL.............................................................................................. 122
14.5 Операторы описания данных ................................................................................................. 122
14.6 Создание базы данных ............................................................................................................ 122
14.7 Операторы прав доступа ........................................................................................................ 124
14.8 Операторы выполнения и "отката" транзакций ................................................................... 124
14.9 Транзакция ............................................................................................................................... 124
4
14.10
Операторы манипуляции данными ................................................................................... 125
14.11
Расширения языка SQL ...................................................................................................... 130
14.12
Выводы ................................................................................................................................. 130
15
Лекция №15: Открытый интерфейс доступа к базам данных – ODBC ................................. 130
15.1 Функциональная модель ODBC ............................................................................................ 130
15.2 Основа ODBC .......................................................................................................................... 130
15.3 Архитектура ODBC................................................................................................................. 131
15.4 Функции ODBC API ............................................................................................................... 132
15.5 Соотношение стандарта ODBC и стандарта интерфейса уровня вызовов (CLI) .............. 132
15.6 Создание источника данных .................................................................................................. 134
15.7 Утилита ODBC ........................................................................................................................ 134
15.8 Создание источника данных с использованием ODBC API ............................................... 135
15.9 Коды возврата.......................................................................................................................... 137
16
Лекция 18. Документирование в процессах жизненного цикла ПО. Стандарты управления
жизненным циклом автоматизированной системы ............................................................................. 138
16.1 Документация и ее роль в обеспечении качества ................................................................ 138
16.1.1 Стандарты управления жизненным циклом автоматизированной системы ............. 144
16.2 3.3. Требования стандартов к программной документации................................................ 144
5
1
Лекция № 1. Понятие о сетях. Корпоративные информационные системы.
Структура и назначение КИС. Характеристика. Требования к организации
КИС. Процессы. Многоуровневая организация КИС.
1.1 Понятие о сетях. Что такое сеть.
Как известно, первые Персональные Компьютеры (ПК) предназначались для решения
математических задач. Однако вскоре стало очевидно, что главной сферой их применения должна
стать обработка информации, при которой персональные компьютеры уже не могут работать в
автономном режиме, а должны взаимодействовать с другими ПК, с источниками и потребителями
информации. Результатом этого явились информационно-вычислительные сети (ИВС), которые к
настоящему времени получили широкое распространение в мире.
Сеть (network) - два (или более) компьютера и подключенные к ним устройства,
соединенные средствами связи.
Сервер (server) - это:
Компонент сетевой ОС, предоставляющий клиентам доступ к сетевым ресурсам. Для
каждого вида ресурсов в сети может быть создан один или несколько серверов. Чаще
всего применяются серверы файлов, печати, баз данных, удаленного доступа и т. д.
Компьютер, выполняющий программу сервера и предоставляющий свои ресурсы в
совместное использование в сети.
Сеть на основе сервера (server-based network) - сеть, в которой функции компьютеров
дифференцированы на функции серверов и клиентов. Стала стандартом для сетей,
обслуживающих более 10 пользователей.
Одноранговая сеть (peer-to-peer network) - сеть, в которой нет выделенных серверов и
иерархии компьютеров. Все компьютеры считаются равноправными. Обычно каждый компьютер
выступает в роли и сервера, и клиента.
Клиент (client) - любой компьютер или программа, подключающаяся к службам другого
компьютера или программы. Например, Windows 2000 Professional является клиентом Active
Directory. Этот термин также иногда относится к ПО, позволяющему компьютеру или программе
создать подключение. Например, для подключения компьютера с Windows 95 к Active Directory на
компьютере с Windows 2000 необходимо установить на первом компьютере клиент Active
Directory для Windows 95.
Сеть состоит из:
аппаратных средств (серверы, рабочие станции, кабели, принтеры и др.)
программного обеспечения (операционные системы (ОС) и приложения).
Локальная Вычислительная Сеть (ЛВС) ~ Local Area Network (LAN) — компьютеры,
соединенные средствами передачи данных в сеть для совместного использования на ограниченной
территории (например, в одной комнате, одном здании, группе близлежащих зданий).
Рассмотрим работу сети с общей точки зрения. Вероятно, потребуется установить
электронное оборудование, которое позволит пользователям ПК подключаться к сети. В простых
(одноранговых) сетях (рис 0.1) доставка сообщений между двумя устройствами осуществляется
довольно просто.
6
.
Каждому устройству присваивается адрес (числовое имя). Когда устройству А требуется послать
сообщение устройству В, первое просто вводит в сообщение в адрес второго и помещает
сообщение в сеть. Устройство В осуществляет поиск в сети всех сообщении, которые
соответствуют его адресу. Если устройство В обнаруживает сообщение, содержащее его адрес,
оно выбирает это сообщение. Остальные устройства, например, устройство Б, просто
проигнорируют сообщения, которые им не адресованы.
Однако работа больших сетей намного сложнее. Задачи, которые необходимо решить для
доставки сообщений через сложные сети:
Каждое устройство должно обладать идентификатором своего места в сети, т.е.
уникальным адресом, называемом адресом устройства,
Каждый промежуточный и конечный пункт назначения должен обладать собственным
идентификатором, должен существовать механизм локальной доставки сообщений,
который позволяет устройствам помещать сообщения в среду передачи данных и
выбирать сообщения, которые им адресуются,
Процедуры маршрутизации сообщений должны быть между исходным и конечным
пунктами назначения, т.е. должен существовать механизм доставки сообщений,
который распространяется по всей объединённой сети,
Если промежуточный пункт отличается от исходного и/или конечного пункта
назначения, в процедурах доставки сообщений всё должно быть согласовано таким
образом, чтобы не возникло путаницы, т.е. должен существовать способ определения
надёжных путей маршрутизации сообщений,
Когда возникают проблемы доставки сообщений, должны использоваться механизмы
обнаружения и исправления ошибок.
Глобальная Вычислительная Сеть (ГВС) ~ Wide Area Network (WAN) — компьютерная
сеть, использующая средства связи дальнего действия. Состоит из компьютеров, разделенных
большими расстояниями. На рис. 0.2 приведена сильно упрощённая глобальная сеть.
Приведённая на рисунке сеть состоит из нескольких соединённых друг с другом сетей. Это «сеть
сетей», которая обычно называется объединённой сетью или интерсетью или просто internet.
1.2 Компоненты сети.
Все сети, даже наиболее сложные, содержат три строительных компонента:
Устройства, обеспечивающие сетевое обслуживание,
Устройства, использующие службы сети,
Среду, позволяющую связывать устройства.
7
1.3 Понятие об корпоративных информационных системах.
Информационно-Вычислительная Сеть (ИВС) – это территориально распределённая
система коллективного использования средств связи и вычислительных ресурсов,
обеспечивающая повышение эффективности функционирования линий передачи информации и
вычислительных средств при решении сложных задач обработки информации.
В структуре ИВС принято выделять два основных направления:
Средства сбора, хранения и обработки информации, которые базируются на
компьютерах с их запоминающими устройствами и аппаратурой ввода-вывода
информации;
Средства передачи информации, предназначенные для обеспечения взаимосвязи
между компьютерами, а также дистанционного доступа к компьютерам удалённых
абонентских пунктов.
Средства передачи информации в ИВС представляют собой самостоятельную сеть
специализированных вычислительных машин, функцией которых является транспортировка
информации между абонентскими пунктами и вычислительными машинами, осуществляющими
обработку информации и предоставляющими пользователям разнообразные услуги по
организации вычислительных работ на ПК, доступу к информационно- поисковым системам
(базам данных), сбору, обработке и накоплению информации.
Специфика и эффективность работы ИВС в значительной степени определяются
особенностями (протоколами) организации информационного обмена в сети, к которой
подключены ПК и абонентские пункты пользователей.
8
Корпоративная сеть (КС/IntraNet) - термин, описывающий способ использования в
соответствии с технологией Web серверов и броузеров для создания частного пространства
Internet.
Глобальная сеть (ГС/WAN) – сеть, разработанная для обслуживания больших
географических районов. Корпоративные глобальные сети (КГС) с помощью различных
телекоммуникационных технологий объединяют разбросанные по всему миру офисы.
Корпоративные Информационные Системы (КИС) – корпоративные глобальные сети,
созданные предприятием или группой предприятий, объединённых общей производственной
целью для совместных действий, т.е. самодельные информационно-вычислительные сети на
основе протокола TCP/IP, выполняющие те же функции, которые возложены на ГС, но
распространяющие и поддерживающие информацию только в пределах одной организационной
структуры предприятий.
В КИС используется программное обеспечение World Wide Web (WWW) для:
распространения внутренней корпоративной информации,
опубликования маркетинговой информации,
хранения баз данных,
обслуживания собственных производственных задач,
объединения усилий пользователей для решения совместных производственных задач.
TCP/IP (Transmission Control Protocol/Internet Protocol) – протокол управления
передачей/межсетевой протокол. Два самых известных протокола Internet, которые часто
ошибочно рассматриваются как один. Протокол ТСР соответствует транспортному уровню
(четвёртый уровень модели OSI), и отвечает за надёжную передачу данных. Протокол IP
соответствует сетевому уровню (третьему уровню модели OSI) и представляет сетевое
обслуживание передачи данных без установления соединения.
1.4 Структура КИС.
Для создания крупномасштабных систем передачи, хранения и обработки информации
(данных) ПК и вычислительные комплексы предприятий объединяются с помощью средств
передачи данных в КИС, обеспечивающие пользователям различные услуги.
Организационно КИС можно разделить на две равнозначные части:
Структуру корпораций и предприятий
Структуру сети
Структура корпораций и предприятий в свою очередь состоит из:
КИС для автоматизированного управления
КИС для административного управления
Структура сети КИС включает три взаимосвязанные подсети (рис 1.1):
Базовую сеть передачи данных (СПД),
Компьютерную сеть (магистрали),
Локальную/Терминальную сеть.
9
Рис 1.1
Базовая сеть передачи данных (СПД) – совокупность средств передачи данных между
компьютерами – состоит из линий связи и узлов связи (УС).
Узел связи (УС) – совокупность средств коммутации и передачи данных в одном пункте –
принимает данные, поступающие по каналам связи, и передаёт данные в каналы, ведущие к
абонентам. УС реализуется на основе коммутационной вычислительной машины (КВМ),
транспортных серверов и аппаратуры передачи данных. КВМ и ТС управляют приёмом и
передачей данных и выбирают целесообразный путь передачи данных.
Базовая СПД – ядро вычислительной сети. Она обеспечивает физическое объединение ПК и
прочих устройств в сеть, которая включает в себя главные, персональные и терминальные
вычислительные машины. Главные вычислительные машины (ГВМ) или Сервера выполняют
задания абонентов сети (пользователей) по обработке и хранению информации. Терминальные
вычислительные машины (ТВМ) или Терминальные сервера предназначены для сопряжения
терминалов и модемов с базовой СПД. Основная функция сопряжения сводится к
преобразованию данных в форму, обеспечивающую их передачу средствами базовой сети и вывод
данных на терминалы. В качестве синонима иногда используется выражение «сервер удалённого
доступа» (access server).
Терминальная /Локальная/ сеть – совокупность терминалов и локальной сети передачи данных.
Терминалы /Персональные Компьютеры (ПК)/ - устройства ввода-вывода и отображения
данных, а также решения математических и иных прикладных задач. В терминальной/локальной
сети могут использоваться интеллектуальные терминалы и абонентские пункты.
В состав интеллектуального терминала (ПК) входит процессор, обеспечивающий
локальную обработку данных – редактирование текстов, отображение данных в специальной
форме, хранение данных и манипуляции с ними и т.д.
10
Абонентский пункт состоит из взаимосвязанных устройств ввода-вывода, обеспечивающих ввод
данных от нескольких источников и вывод данных в различной форме: на экраны
мониторов/дисплеев, устройства печати (принтеры), устройства вывода графической информации
(плоттеры), устройства хранения информации (дискеты, CD-диски и т.п.). Для подключения
терминалов к ВМ используются линии связи и обслуживающие их удалённые мультиплексоры
передачи данных (УМПД), в совокупности образующие локальную/терминальную сеть
передачи данных.
Мультиплексор – устройство, используемое для комбинирования данных, полученных от многих
устройств с низкой и средней скоростью передачи, в передаваемый с более высокой скоростью
поток. Для достижения этого результата используются различные методики
мультиплексирования, включая разделение времени, разделение частоты, статистическое
разделение времени, разделение длин волн. Мультиплексор иногда называют концентратором.
Контроль состояния КИС и управление её функционированием обеспечиваются
административной системой, включающей в себя ПК, сетевое (терминальное) оборудование и
программные средства, с помощью которых производится включение и выключение сети и её
компонентов, контролируется её работоспособность, устанавливается режим функционирования
компонентов, систем сети в целом, учитывается объём услуг, предоставляемым абонентам сетью,
и т.д.
Отдельные КИС могут быть связаны между собой с помощью линий связи, подключаемым
к узлам межсетевой связи. В узле межсетевой связи используется вычислительная машина,
обеспечивающая согласование и преобразование данных при передаче их от одной сети к другой.
1.5 Назначение КИС.
Основной эффект КИС – полная доступность ресурсов сети для внутренних пользователей.
Пользователи, подключенные к сети, имеют доступ ко всем главным компьютерам, входящим в
сеть, следовательно, получают возможность использовать память этих компьютеров для хранения
данных и процессоры для их обработки. Пользователям доступны программное обеспечение,
имеющееся в сети, и базы данных в компьютерах, что позволяет им оперативно их использовать.
Сети предоставляют возможность параллельно обрабатывать данные сразу несколькими ПК.
Возможно построение распределённых баз данных, а за счёт этого – создание сложных
информационных структур. Информационные связи между пользователями позволяют группам
пользователей решать задачи моделирования сложных систем, выполнять проектные и другие
работы, опирающиеся на распределённые между многими компьютерами программное
обеспечение и базы данных.
Таким образом, сетевая обработка и хранение данных – качественно новая организация
обработки, при которой в значительной мере увеличиваются сложность и скорость решения задач,
требующих участия большого числа пользователей.
КИС позволяет повысить уровень загрузки ПК, программного обеспечения и баз данных.
Это обусловлено тем, что:
КИС обслуживает большое количество пользователей, поэтому нагрузка, создаваемая
всеми пользователями, в меньшей степени подвержена колебаниям, чем нагрузка,
создаваемая отдельным пользователем или группой.
Стабилизируется загрузка сети, когда сеть охватывает территорию, расположенную в
нескольких часовых поясах. Эффект стабилизации существен для эксплуатации
специализированных и проблемно-ориентированных ПК, аналого-цифровых
вычислительных комплексов, информационно-справочных систем.
1.6 Характеристика.
Основными характеристиками КИС являются:
1) Операционные возможности,
11
2) Время доставки сообщений,
3) Производительность сети,
4) Стоимость обработки данных.
Операционные возможности сети – перечень основных действий по обработке и хранению
данных.
Главные компьютеры (сервера), входящие в состав сети, предоставляют пользователям
следующие виды услуг:
Передача файлов (наборов данных) между ПК сети;
Доступ к пакетам прикладных программ, базам данных и удалённым файлам –
обработку файлов, хранимых в удалённых ПК;
Передача текстовых, аудио и видео сообщений между ПК (пользователями);
Распределённые базы данных
Удалённый ввод заданий – выполнение заданий, поступающих с любых ПК, на
любой главной ЭВМ в пакетном или диалоговом режиме;
Защита данных и ресурсов от несанкционированного доступа;
Выдача справок об информационных и программных ресурсах;
Автоматизация программирования и распределённая обработка – параллельное
выполнение задачи несколькими ПК.
Время доставки сообщений – статистическое среднее время от момента передачи сообщения
в сеть до момента получения сообщения адресатом.
Производительность сети – суммарная производительность главных компьютеров (серверов).
При этом обычно производительность главных компьютеров (серверов) означает номинальную
производительность их процессоров.
Стоимость обработки данных – формируется с учётом средств, используемых для вводавывода, передачи, хранения и обработки данных. На основе цен рассчитывается стоимость
обработки данных, которая зависит от объёма используемых ресурсов вычислительной сети
(количество передаваемых данных, процессорное время), а также от режима передачи и обработки
данных.
Характеристики зависят от структурной и функциональной организации сети, основные из
которых:
Топология (структура) КИС (состав ПК, структура базовой СПД и терминальной
сети),
Метод передачи данных в базовой сети,
Способы установления соединений между взаимодействующими пользователями,
Выбор маршрутов передачи данных.
Нагрузки, создаваемой пользователями.
Топология - физическая структура и организация сети. Наиболее распространёнными
топологиями являются:
магистраль,
дерево,
кольцо
звезда.
Нагрузка определяется числом активных пользователей и интенсивностью взаимодействия
пользователей с сетью. Последний параметр характеризуется количеством данных, вводимых выводимых ПК за единицу времени, и потребностью в ресурсах главных машин для обработки
этих данных.
1.7 Требования к организации КИС.
Организация КИС должна удовлетворять следующим основным требованиям:
12
1) Открытость – это возможность включения дополнительно главных компьютеров
(серверов), терминалов, ПК, узлов и линий связи без изменения технических и
программных средств действующих компонентов,
2) Гибкость – возможность работы любых главных компьютеров (серверов) с терминалами
или ПК различных типов, допустимость изменения типа ПК и линий связи,
3) Надёжность – сохранение работоспособности при изменении структуры в результате
выхода из строя ПК, узлов и линий связи,
4) Эффективность – обеспечение требуемого качества обслуживания пользователей при
минимальных затратах,
5) Безопасность – программные или аппаратно-программные средства защиты тем или иным
способом информации, которая обрабатывается и передаётся в сети
Указанные требования реализуются за счёт модульного принципа организации управления
процессами в сети по многоуровневой схеме, в основе которой лежат понятия процесса, уровня
управления, интерфейса и протокола.
1.8 Процессы.
Функционирование КИС представляется в терминах процессов.
Процесс – это динамический объект, реализующий собой целенаправленный акт обработки
данных. Процессы подразделяются на два класса:
Прикладные
Системные
Прикладной процесс - выполнение прикладной или обрабатывающей программы операционной
системы ПК, а также функционирование ПК, т.е. пользователя, работающего на ПК.
Системный процесс – выполнение программы (алгоритма), реализующей вспомогательную
функцию, связанную с обеспечением прикладных процессов. Например, активизация ПК или
терминала для прикладного процесса, организация связи между процессами.
Модель
процесса представлена на рис 1.2
Процесс порождается программой или пользователем и связан с данными, поступающими извне в
качестве исходных и формируемыми процессом для внешнего пользования. Ввод данных,
необходимых процессу, и вывод данных производятся в форме сообщений – последовательности
данных, имеющих законченное смысловое значение. Ввод сообщений в процесс и вывод
сообщений из процесса производится через логические (программно организованные) точки,
называемые портами. Порты подразделяются на входные и выходные.
Таким образом, процесс как объект представляется совокупностью портов, через которые он
взаимодействует с другими процессами сети.
13
Взаимодействие процессов сводится к обмену сообщениями, которые передаются по каналам,
создаваемым средствами сети (рис 1.3) .
Промежуток времени, в течение которого взаимодействуют процессы, называется сеансом
(сессией). В КИС единственная форма взаимодействия процессов – обмен сообщениями. В ПК и
вычислительных комплексах взаимодействия процессов обеспечивается за счёт доступа к общим
для них данным, общей памяти и обмена сигналами прерывания.
Это различие связано с территориальной распределённостью процессов в КИС, а также с тем,
что для физического сопряжения компонентов сети используются каналы связи, которые
обеспечивают передачу сообщений, но не отдельных сигналов.
1.9 Многоуровневая организация сети.
Передающая среда сети может иметь любую физическую природу и представлять собой
совокупность проводных оптико-волоконных, радиорелейных, тропосферных, спутниковых линий
(каналов) связи. В каждой из систем сети существует некоторая совокупность процессов.
Процессы, распределённые по разным системам, взаимодействуют через передающую среду
путём обмена сообщениями.
Для обеспечения открытости, надёжности, гибкости, эффективности и безопасности сети
управление процессами организуется по многоуровневой схеме (рис 1.4). Открытая системная
интеграция (далее называемая OSI – Open System Integration) описывает модель, представляющую
общие понятия для определения сетевых компонентов. Модель OSI обычно применяется при
планировании полного набора сетевых протоколов.
В табл. 1.1 представлен подход, применяемый при использовании модели OSI. Процесс
создания сетевых коммуникаций разделён на семь этапов.
Таблица 1.1
Application (Приложения)
Presentation (Представления)
Session (Сеанс)
Transport (Транспорт)
Network (Сеть)
Data Link (Связь данных)
Physical (Физический)
В каждой из систем прямоугольниками обозначены программные и аппаратные модули,
реализующие определённые функции обработки и передачи данных.
Модули распределены по уровням 1…7. Уровень 1 является нижним, уровень 7 - верхним.
Модуль уровня N физически взаимодействует только с модулями соседних уровней N+1 и N-1.
Модуль уровня 1 взаимодействует с передающей средой, которая может рассматриваться как
объект уровня 0 (ноль). Прикладные процессы принято относить к верхнему уровню иерархии, в
данном случае к уровню 7. Физически связь между процессами обеспечивается передающей
средой. Взаимодействие прикладных процессов с передающей средой организуется с
14
использованием шести промежуточных уровней управления 1…6, которые рассмотрим, начиная
с нижнего.
Уровень 1 – физический - реализует управление каналом связи, что сводится к подключению
и отключению канала связи и формированию сигналов, представляющих передаваемые данные.
Из-за наличия помех в передаваемые данные вносятся искажения и снижается достоверность
передачи: вероятность ошибки 10-4...10 -6.
Уровень 2 – канальный/связи данных– обеспечивает надёжную передачу данных через
физический канал, организуемый на уровне 1. Вероятность искажения данных 10 -8...10 -9. При
обнаружении ошибки производится перезапрос данных.
Уровень 3 – сетевой – обеспечивает передачу данных через базовую сеть передачи данных
(СПД). Управление сетью на этом уровне состоит в выборе маршрута передачи данных по линиям,
связывающим узлы сети.
Уровни 1…3 организуют базовую СПД между пользователями сети.
Уровень 4 – транспортный – реализует процедуры сопряжения пользователей сети (главных и
персональных компьютеров) с базовой СПД. На этом уровне возможно сопряжение различных
систем с сетью, и тем самым организуется транспортная служба для обмена данными между
сетью и системами сети.
Уровень 5 – сеансовый – организует сеансы связи на период взаимодействия процессов. На
этом уровне по запросам процессов создаются порты для приёма и передачи сообщений и
организуются соединения – логические каналы.
Уровень 6 – представления – осуществляет трансляцию различных языков, форматов данных
и кодов для взаимодействия разнотипных ПК, оснащённых специфичными ОС и работающих в
различных кодах между собой и ПК и терминалами разных типов. Взаимодействие процессов
организуется на основе стандартных форм представления заданий и наборов данных. Процедуры
уровня представления интерпретируют стандартные сообщения применительно к конкретным
системам – ПК и терминалам. Этим создаётся возможность взаимодействия одной программы с
ПК разных типов.
Уровень 7 – прикладной (приложений) – создан только для выполнения определённой
функции обработки данных без учёта структуры сети, типа каналов связи, способов выбора
маршрутов и т.д. Этим обеспечивается открытость и гибкость системы.
Число уровней и распределение функций между ними существенно влияют на сложность
программного обеспечения ПК, входящих в сеть, и на эффективность сети. Рассмотренная
семиуровневая модель (эталонная модель взаимодействия открытых систем – ЭМВОС),
именуемая архитектурой открытых систем, принята в качестве стандарта Международной
15
организацией по стандартизации (МОС) и используется как основа при разработке КИС и ИВС в
целом.
Для помощи в освоении предмета приведём слова-ловушки, первые символы которых
совпадают с именами уровней в таком же порядке:
All (Все)
People (Люди)
Seem (Кажется)
To (В)
Need (Нуждается)
Data (Данные)
Processing (Обработка)
(Все люди, кажется, нуждаются в обработке данных.)
Эту ключевую фразу легко запомнить, и она поможет администратору локальной сети
чувствовать свою ответственность.
1.10 Литература
Мельников Д.А. «Информационные процессы в компьютерных сетях. Протоколы, стандарты, интерфейсы,
модели…» - М: КУДИЦ-ОБРАЗ, 1999, Предисловие. Введение, Глава 1, Стр. 3-12;
Мельников Д.А. «Информационные процессы в компьютерных сетях. Протоколы, стандарты, интерфейсы,
модели…» - М: КУДИЦ-ОБРАЗ, 1999, Глава 7, Стр. 72-75
Спортак М и др. «Высокопроизводительные сети. Энциклопедия пользователя», Пер. с англ., - К: Издательство
«ДиаСофт», 1998, Глава 29, Стр. 388-406
Хейвуд Дрю «Внутренний мир Windows NT Server 4» Пер. с англ., - К.: Издательство «Диа-Софт», 1997, Глава 9,
Стр. 240-242; Приложение А, Стр. 488-489
2
Лекция № 2. Базовые концепции сетевой архитектуры. Обмен между
уровнями. Горизонтальные отношения – протоколы. Вертикальные
отношения – интерфейсы. Передача и приём данных по сети.
2.1 Базовые концепции сетевой архитектуры.
Для обеспечения коммуникаций и обмена данными между компьютерами сетевое
программное обеспечение должно иметь следующий набор функций:
Перенаправление ввода/вывода и устройств
Регистрация адресов процесса
Межпроцессорные коммуникации (IPC)
Шифрование и расшифровка паролей
Сегментация и десегментация (сборка) сообщений
Ограничение фреймов и арбитраж доступа к передающей среде
Импульсное кодирование битов
Для уменьшения сложности разработки компьютерных сетей, эти функции организованы в
несколько групп, находящихся на различных уровнях. Целью каждого уровня является
предоставление сервиса для другого уровня, причём уровни не должны заботиться о деталях того,
как в действительности осуществляется необходимый им сервис. Сервисы, обеспечиваемые
определённым уровнем, являются продуктов сетевых функций, определённых для этого уровня.
Они обычно разрабатываются на основе сервисов, которые предлагаются другими уровнями.
Структура набора уровней и методов их взаимодействия и составляет архитектуру сети.
2.2 Обмен между уровнями
16
Обмен между уровнями, расположенными в пределах одного ПК, производится не так, как
между двумя уровнями на разных ПК. В пределах одного ПК уровни общаются друг с другом,
используя вертикальные интерфейсы. Одноимённые уровни на различных ПК сообщаются с
использованием определённых протоколов.
2.3 Горизонтальные отношения – протоколы
Прямой обмен (peer-to-peer communication) осуществляется с помощью протоколов.
Уровень 4 на одном ПК ведёт диалог с уровнем 4 на другом ПК. Совокупность правил и
соглашений, используемых при этом диалоге, называется протоколом 4-го уровня.
Взаимодействие между уровнями называется прямым соединением. Функции, исполняемые на 4м уровне одного ПК, подключаются к уровню 4 другого ПК.
Набор семантических и синтаксических правил, которые определяют поведение систем или
устройств (частей систем или устройств), выполняющих определённые логически связанные
группы функций при передаче данных (правила взаимодействия процессов на основе обмена
сообщениями), называется протоколом.
Протоколы имеют следующие особенности:
Параллелизм взаимодействующих процессов
Взаимная неопределённость состояния процессов, связанная с отсутствием у
каждого из них полной информации о состоянии другого процесса
Отсутствие однозначной зависимости между событиями и действиями,
выполняемыми при их наступлении
Отсутствие полной гарантии доставки сообщений
При описании протокола принято выделять его логическую и процедурную
характеристики.
Логическая характеристика протокола – структура (формат) и содержание (семантика)
сообщений. Логическая характеристика задаётся перечислением типов сообщений и их смысла.
Правила выполнения действий, предписанных протоколом взаимодействия, называются
процедурной характеристикой протокола. Процедурная характеристика протокола может
представляться в различной математической форме: операторными схемами алгоритмов,
автоматными моделями, сетями Петри и пр.
2.4 Вертикальные отношения – интерфейсы
Каждый уровень взаимодействует с таким же уровнем на другом ПК, но никакие данные не
перемещаются напрямую с уровня 4 одного ПК на уровень 4 другого ПК. Вместо этого каждый
уровень передаёт данные и управляющую информацию на смежный нижележащий уровень до тех
пор, пока данные не достигнут самого низкого уровня, откуда они передаются в сетевую среду
передачи (network media). Принимающий ПК затем перемещает данные и управляющую
информацию от уровня к уровню до того момента, пока данные не достигнут уровня 4.
Между каждой парой уровней существует хорошо определённый интерфейс. Интерфейс
определяет, какой сервис предлагает нижний уровень верхнему, и как к этому сервису получит
доступ.
Взаимодействие между уровнями одной системы называется интерфейсом, который
определяет структуру данных и способ (алгоритм) обмена данными между соседними уровнями.
2.5 Передача и приём данных по сети.
Когда два компьютера передают данные по сети, один из них является отправителем (передающим
компьютером), а другой – получателем (принимающим компьютером). Данные передаются в виде
фреймов или пакетов, которые представляют собой сообщения, разбитые на более мелкие части,
17
к которым присоединены транспортные заголовки. Чтобы понять принципы передачи фреймов по
сети, необходимо рассмотреть точку передачи и точку приёма.
Передача.
Фреймы данных формируются в тот момент, когда передающий компьютер инициирует запрос на
связь. Формирование фрейма начинается на самом высоком уровне и продолжается через каждый
последующий уровень. На каждом уровне данные дополняются управляющей информацией в
форме заголовка (header) и/или завершающего блока (trailer), который иногда называется
«хвостом». Когда данные проходят через все уровни стека протоколов, они передаются в сетевую
среду передачи.
Приём.
При приёме фрейм передаётся от уровня к уровню снизу вверх в порядке, определённом
межуровневыми интерфейсами. Протокол на каждом уровне интерпретирует только ту
информацию, которая содержится в заголовке или завершающем блоке, которые были добавлены
к фрейму одноимёнными уровнями при передаче данных. Остальную часть фрейма протокол
рассматривает как данные, и передаёт их на вышележащий уровень.
2.6 Литература
Сетевые средства Microsoft WINDOWS NT Server 4.0 : Пер. С англ. – СПб.: BHV – Санкт-Петербург, 1999, Глава
1, Стр. 17-19
Мельников Д.А. «Информационные процессы в компьютерных сетях. Протоколы, стандарты, интерфейсы,
модели…» - М: КУДИЦ-ОБРАЗ, 1999, Глава 1 Стр.152-20
3
Лекция № 3. Физические среды установления соединения. Построение
локальных и глобальных связей. Определение критериев. Технология.
Каналы передачи данных.
3.1 Физические среды установления соединения.
Для всех сетей существует три принципиальные схемы соединения:
С помощью витой пары,
Коаксиальным кабелем,
Волоконно-оптическим кабелем.
Для передачи информации также могут использоваться спутники, лазеры, микроволновое
излучение. В табл. 2.1 представлены сравнительные характеристики физических сред.
Таблица 2.1
Среда
1. Витая пара
Преимущества
Низкая стоимость, развертывание
не представляет сложности
2. Коаксиальный
кабель
Относительно высокая скорость
передачи данных на короткие
расстояния
Высокая скорость передачи на
длинные расстояния голосовой,
цифровой и видеоинформации
3. Волоконнооптический кабель
Недостатки
Недостаточная безопасность,
сильная восприимчивость к
помехам (шуму)
Недостаточная безопасность,
значительная восприимчивость
к помехам (шуму)
Высокая стоимость, сложности
при развёртывании
Витая пара (twisted-pair cable) - два скрученных изолированных провода, используемых для
передачи электрических сигналов. Скручивание проводов уменьшает влияние внешних
электромагнитных помех. Несколько витых пар часто помещают в защитную оболочку. Витая
пара бывает экранированной и неэкранированной. Последняя распространена в телефонных сетях.
18
Коаксиальный кабель (coaxial cable (coax)) - электрический кабель, имеющий расположение
центрального проводника, окруженного изолятором, и внешнего проводника, выполненного в
виде проволочной оплетки. Снаружи коаксиальный кабель покрыт еще одним защитным слоем
изолятора. Коаксиальный кабель менее подвержен помехам и ослаблению сигнала по сравнению с
другими типами кабеля (например, неэкранированной витой парой).
Волоконно-оптический кабель (оптоволоконный кабель, fiber-optic cable) - кабель, по
которому цифровые данные передаются в виде модулированных световых импульсов. Состоит из
чрезвычайно тонкого стеклянного цилиндра (ядро), окруженного слоем стекла (покрытие) с
другим коэффициентом преломления.
Выбор высокопроизводительных стандартов ИВС включает такие сетевые технологии, как Fast
Ethernet, Fibre Channel, FDDI и АТМ, которые стали вытеснять своих предков – Token Ring и
Ethernet. Опишем основные типы технологий локальных сетей.
Fast Ethernet (100base-XX)
В зависимости от типа среды различают следующие разновидности Fast Ethernet:
100base-T4 (4 витые пары)
100base-TX (2 витые пары)
100base_FX (Волоконно-оптический кабель)
Являясь высокоскоростной разновидностью устаревшей технологии 10base-X Ethernet, сети
стандарта 100base-XX в состоянии передавать данные со скоростью 100 Мбит/с.
Распределённый интерфейс передачи данных по волоконно-оптическим каналам
(FDDI)
FDDI (Fiber Distributed Data Interface) является стабильной волоконно-оптической средой,
поддерживающий скорость передачи данных 100 Мбит/с. Часто используется в качестве
магистрали больших сетей, а также в качестве промежуточной локальной сети
высокопроизводительных ПК. FDDI поддерживает топологию Token Ring, но для обмена
информацией использует не одно кольцо, а два. Первое кольцо считается основным, второе –
резервным. С целью уменьшения количества ошибок передача данных в кольцах осуществляется
в противоположных направлениях.
Волоконно-оптическим канал (Fibre Channel)
Fibre Channel (FC) – новая схема соединения, поддерживающая не только собственный протокол,
то также протоколы FDDI, SCSI, IP и некоторые другие. Это позволило создать единый стандарт
для сетевого и обычного обмена данными, равно как и для накопления данных. Первоначально
разработанный для глобальных сетей (WAN) с помощью коммутаторов стандарт FC может быть
адаптирован к локальной сети. Волоконно-оптическим канал позволяет порту прослушивать
канальные и сетевые интерфейсы, снижая при этом нагрузку на станцию. Канал поддерживает как
электрические, так и оптические среды установления соединения, имеющие пропускную
способность от 133 до 1062 Мбит/с.
Режим асинхронной передачи (АТМ)
АТМ (Asynchronous Transfer Mode) – это предложенный стандарт для широкополосных каналов
ISDN. АТМ считается чрезвычайно производительным решением как для локальных, так и для
глобальных сетей. Стандарт АТМ предполагает использование специальных высокоскоростных
коммутаторов, подключенных к ПК с помощью волоконно-оптических каналов (один канал
используется передачи информации, другой - для приёма). АТМ поддерживает одновременную
передачу по одному каналу голосовой, цифровой и видеоинформации. Скорость передачи данных
25 Мбти/с., хотя в исходных спецификациях конфигурирует значение 155 Мбит/с. (см. также
главу 18, «Технология АТМ», «Высокопроизводительные сети. Энциклопедия пользователя»)
3.2 Построение локальных и корпоративных связей.
Выбор «конкретной» корпоративной сети невозможен без набора определённых критериев,
которые позволяют судить о производительности сети. Для выбора типа корпоративной сети
19
прежде всего необходимо сформулировать подходящие критерии. С их помощью можно будет
выбрать необходимые сетевые технологии, определить предполагаемый трафик и оптимизировать
топографическую структуру корпоративной сети.
Определение критериев.
Эта задача относится к числу тех, которые легко сформулировать, но очень трудно
осуществить на практике. Например, всем потенциальным пользователям корпоративной сети
следует присвоить имена. Одновременно возникает необходимость определить их точное
количество в каждой географической области. Но это ещё не всё. Достаточно сложно оценить
интенсивность использования каждым пользователем полосы пропускания.
Для оценки предполагаемых параметров полосы пропускания необходимо выяснить все
тонкости работы пользователей. Можно оценивать следующие параметры:
Тип сеанса соединения (интенсивность передачи данных, обработка интерактивных
транзакций, доступ к ресурсам WEB, видеоконференции и т.п.)
Интенсивность использования
Время максимальной нагрузки
Максимальный объём трафика
Средняя продолжительность сеансов соединения
Среднее количество байтов, переданных за сеанс
Перечень ресурсов, к которым чаще всего обращаются группы пользователей и
отдельные пользователи
Примечание. К сетевым технологиям термин «Байт» обычно не употребляется. Но
поскольку большинство сотрудников в силу своих обязанностей занимается обработкой данных и
привыкло мыслить в байтах, а не в октетах, в данном случае этот термин уместен.
При сборе данных следует необходимо учитывать специфику использования сети.
Необходимо знать, будет ли полоса пропускания зарезервирована под интенсивную передачу
данных или же будет выделена под обслуживание интерактивной видеоконференции. Упомянутые
режимы выдвигают совершенно противоположные требования к производительности сети.
Интенсивная передача предполагает обеспечение целостности принимаемых данных –
допускаются задержки в доставке пакетов. На время обслуживания интерактивной
видеоконференции основное внимание уделяется своевременной доставке пакетов. Опоздавшие
пакеты, как и поврежденные, игнорируются.
Вывод: требования к производительности глобальной сети в значительной степени влияют
на процесс её разработки.
В обязательном порядке следует определить параметры сетей, которые будут объединены в
корпоративную сеть:
Тип и производительность каждой локальной сети
Количество подключенных пользователей
Количество хост-компьютеров, подключенных к локальной сети
Возможности несанкционированного доступа
Маршрутизируемость протокола (IP, IPX и пр.)
Количество подключенных маршрутизаторов и протоколов маршрутизации
Схему адресации Intranet
Эта информация должна быть получена от каждого пользователя или группы пользователей,
которые будут пользоваться корпоративной сетью. Располагая необходимым набором данных
можно заняться двумя основными вопросами – технологией и топологией сетей.
Технология.
Понятие технология корпоративной сети включает в себя следующие характеристики:
20
Каналы передачи данных
Модули обслуживания канала (CSU – Channel Service Units)
Цифровые сервисные блоки (Digital Service Units - DSU)
Краевые устройства типа маршрутизаторов и коммутаторов
Адресацию Intranet
Протоколы маршрутизации
Необходимо определить соответствие параметров каждой из этих технологий предполагаемому
трафику и требованиям к производительности корпоративной сети.
Каналы передачи данных.
Информационный обмен между пользователями может осуществляться тремя различными
способами (рис 2.1):
Коммутацией каналов
Коммутацией сообщений
Коммутацией пакетов
Коммутация каналов позволяет создавать между двумя конечными ПК выделенные
маршруты следования данных и обеспечивает выделение физического канала для прямой
передачи данных между пользователями. Пример - телефонная связь. Стандартной линией связи с
коммутацией каналов считается выделенная двухточечная частная линия. Подобные линии
выделяются из местной телефонной сети (Local Exchange Carrier –LEC). Они могут быть
аналоговыми или цифровыми, поддерживать скорость передачи данных до 1.544 Мбит/с. (канал
типа DS-1) или 44.476 Мбит/с (канал типа DS-3), использовать электрические или световые
21
сигналы. Допускается разделение общей полосы пропускания на дробные каналы с пропускной
способностью 9.6 Кбит/с.
Процесс происходит следующим образом: пользователь Аi инициирует установление связи
с пользователем Aj. Узел связи А, реагируя на адрес пользователя Aj, проключает соединение, в
результате чего линия пользователя Аi коммутируется с линией, соединяющий узел А с узлом В.
затем процедура проключения соединения повторяется с узлами В, С, D. В результате чего между
пользователями Аi и Aj коммутируется канал. По окончании коммутации узел D посылает сигнал
обратной связи, после получения которого пользователь Ai начинает передавать данные. Значение
U1 определяет время доставки сообщения.
Коммутация сообщений производится путём передачи сообщения, содержащего
заголовок и данные, по маршруту, определяемому узлами сети. В заголовке сообщения
указывается адрес пользователя Ai – получателя сообщения. Сообщение генерируется
пользователем Ai, принимается узлом А и хранится в памяти узла. Узел А обрабатывает заголовок
сообщения и определяет маршрут передачи сообщения, ведущий к узлу В. Узел В принимает
сообщение, размещая в памяти, а по окончании приёма обрабатывает заголовок и выводит
сообщение из памяти на линию связи, ведущую к следующему узлу. Процесс повторяется
последовательно всеми узлами на маршруте от пользователя Ai к пользователю Ai. Значение U2
определяет время доставки сообщения.
Коммутация пакетов производится путём разбивки сообщения на пакеты – элементы
сообщения, снабжённые заголовком и имеющие фиксированную длину, - и последующей
передачи пакетов по маршруту, определяемому узлами сети. Передача данных при коммутации
пакетов происходит так же, как и при коммутации сообщений, но данные разделяются на
последовательность пакетов 1,2,…, длина которых ограничена предельным значением, например,
1024 бит. В сетях коммутация пакетов – основной способ передачи данных. Это обусловлено тем,
что коммутация пакетов приводит к малым задержкам при передаче данных через сеть, а также
следующими обстоятельствами.
1) Способ коммутация каналов требует, чтобы все соединительные линии имели одинаковую
пропускную способность, что сильно ужесточают требования к сети. Коммутация
сообщений и пакетов позволяет передавать данные по линиям связи с любой пропускной
способностью
2) Представление данных пакетами создаёт наилучшие условия для мультиплексирования
потоков данных.
3) Малая длина пакетов позволяет выделять для промежуточного хранения передаваемых
данных меньшую ёмкость памяти, чем требуется для сообщений.
4) Надёжность передачи данных по линиям связи невелика. Пакеты, имея незначительную
длину, в большей степени гарантированы от искажения, чем сообщения.
Значение U3 определяет время доставки пакетов.
3.3 Литература
Мельников Д.А. «Информационные процессы в компьютерных сетях. Протоколы, стандарты, интерфейсы,
модели…» - М: КУДИЦ-ОБРАЗ, 1999, Глава 2 Стр. 20-26
Спортак М и др. «Высокопроизводительные сети. Энциклопедия пользователя», Пер. с англ., - К: Издательство
«ДиаСофт», 1998, Главы 11. Стр.145-160
4
Лекция № 4. Административное управление КИС. Функции. Организация.
Управление сетевой адресацией. Протокол TCP/IP
4.1 Административное управление КИС.
Для управления сетью создаётся служба административного управления. Эта служба по
своим функциям выше прикладного уровня, но реализуется совокупностью специальных
22
системных процессоров, относимых к прикладному уровню 7 OSI. Административное управление
реализуется администраторами/операторами сети, функции которых распространяются на
отдельные составляющие сети, её области, включающие в себя близлежащие ПК, узлы и канала
связи, а также на ИВС в целом. Работа администраторов сети поддерживается ПК и терминальным
оборудованием, через которое вводятся команды управления, управляющая информация. На
мониторе администратора отображается информация о состоянии сети и её компонентов,
необходимая для контроля процессов функционирования сети и для принятия управленческих
решений. Для управления сетью специально выделяются ПК (сервера), к которым подключаются
ПК операторов (пользователей) сети. Часть функций административного управления возлагается
на главные, персональные и связные компьютеры и реализуется соответствующими системными
программами. Место размещения администраторов и соответствующей аппаратуры называется
центром административного управления (ЦАУ).
4.2 Функции административного управления.
Административная служба реализует следующие основные функции:
Обслуживание пользователей,
Управление конфигурацией,
Организацию технического обслуживания,
Управление режимами функционирования,
Учёт использования ресурсов,
Сбор статистики.
Управление безопасностью
Обслуживание пользователей состоит в обеспечении их доступа к средствам
административного управления. Каждое из средств реализуется соответствующими программами,
размещёнными на серверах ЦАУ и отчасти в остальных компьютерах сети. С помощью
специальных команд пользователи могут выполнять следующие действия:
Включать и отключать сеть,
Получать информацию о состоянии сети и её компонентов,
Подключать и отключать системы и компоненты сети,
Контролировать работоспособность и диагностировать неисправность сети и её
компонентов,
Собирать статистику о работе сети.
Эти команды инициируют соответствующие системные программы, реализуемые в серверах сети.
Системные программы могут вступать во взаимодействие с системными программами,
размещёнными в других ЦАУ или ПК сети. Для этого используются стандартные средства
установления соединений и передачи данных между процессами.
Управление конфигурацией сети сводится к подключению и отключению компонентов
сети – каналов и узлов связи, также рабочих ПК. Компонент подключается с использованием
средств, содержащихся в нём, например, с помощью программы начальной загрузки и
активизации сетевых процессов в компьютерах. Если компонент не имеет собственных средств
для хранения программ, перед активизацией необходимые программные средства передаются из
других пунктов сети. При активизации вводятся таблицы определения систем сети,
устанавливающие общесетевые адреса и значения параметров функционирования (таблицы
маршрутизации, размеры окон, число разрешений на передачу пакетов и др.). Параметры в
дальнейшем могут изменяться по командам администраторов, оптимизирующих работу ИВС. Так,
администраторы сети имеют возможность изменять таблицы маршрутизации при превышении
допустимых уровней загрузки помех в каналах, при отключении и отказах каналов и узлов связи и
т.п. При отключении компонентов сети формируются предупреждения, по которым принимаются
меры для сохранения данных о прерываемых работах для завершения работ.
23
Администраторы контролируют состояние сети путём запроса у систем сети данных об
именах и адресах активизированных в них процессов; таблиц определения, содержащих сведения
о значениях параметров, с которыми работают системы; данных о сессиях, логических каналах,
наличии разрешений и т.д.; данных о загрузке ресурсов систем – каналов связи, процессоров,
памяти и т.п.
Техническое обслуживание сети сводится к наблюдению за её состоянием, контролю
работоспособности компонентов и поиску неисправностей. Администраторы
сети имеют возможность проверять активность компонентов сети, инициировать тестирование
каналов, узлов связи и ПК, получать эксплутационную статистику о числе отказов и рестартов в
каналах, узлах связи, терминальных и главных компьютерах.
Способ тестирования и поиска неисправностей зависит от типа средств, реализующих
сетевые функции. Наиболее широко применяется способ эхо-контроля, основанный на передаче
специальных пакетов, возвращаемых тестируемым элементом в систему – источник пакетов.
Программа контроля сети проверяет работоспособность элементов сети (уровней 1…4 OSI) путём
посылки контрольных пакетов, адресованных требуемым элементам сети – оконечному
оборудованию каналов, средствам управления в узлах связи, уровневым средствам управления
ПК. Элементы в ответ на контрольные пакеты формируют эхо-пакеты, получение которых
свидетельствует о работоспособности тракта контролируемого элемента. Получаемая информация
позволяет диагностировать отказавший элемент.
Управление функционированием сети направлено на оптимизацию работы сети за счёт
выбора параметров, наилучшим образом соответствующих текущей конфигурации сети, нагрузке
и требованиям к качеству обслуживания пользователей. Оптимизация может достигаться за счёт
передислокации программ и файлов между серверами.
Для учёта использования ресурсов сети сервера, узлы связи и ПК оснащаются
программными мониторами – измерительными системами. Данная операция называется
мониторинг системы. Мониторинг регистрирует виды и объём связных услуг, а также
процессорное время и ёмкость памяти, предоставляемые пользователю в каждом сеансе
взаимодействия с сетью. Результаты измерений обрабатываются для оценки объёмов
предоставленных ресурсов и начисления платы за их использование, а также для учёта
использования ресурсов сети. На основе получаемых данных решаются задачи развития ИВС:
увеличения числа ПК и количества пользователей, мощности ПК, пропускной способности СПД.
Сетевые системы позволяют быстро распространять необходимую информацию среди всех
сотрудников организации. Хотя сеть значительно повышает скорость доступа к информации, она
также способствует появлению возможности уничтожения ценной информации или доступе к ней
случайных пользователей. Процесс устранения таких возможностей получил название
управление безопасностью.
4.3 Организация административного управления.
Для взаимодействия доменов между собой и прочими системами сети используются общие
для сети протоколы. В рабочие системы на каждом уровне встроены средства, реализующие
необходимые процедуры административного управления: предоставление данных о состоянии
уровня управления, приём значений параметров, влияющих на функционирование средств, эхоконтроль и др.
В ИВС с малым числом узлов административное управление осуществляется с
единственного сервера. В крупномасштабных сетях функции управления распределяются между
несколькими пунктами административного управления.
Управление сетевой адресацией.
Присвоение адресов всем станциям сети является одной из первых задач, решаемых сразу
же после развёртывания новой сети. С технической точки зрения эта задача решается в процессе
24
развёртывания сети, но поддержка набора адресов и внесение изменений в конфигурации рабочих
станций через некоторое время относится уже к функциям сетевого администрирования.
Каждой станции сети необходимо присвоить свой уникальный номер, который бы отличал
её от других станций и позволял передавать сообщения, предназначенные только для неё. Эти
адреса автоматически «прошиты» в каждом сетевом адаптере производителем. Такой адрес,
называемый адресом управления доступом к среде (Media access control - MAC) или
физическим адресом, состоит из 16 шестнадцатеричных цифр. Первые 8 определяют
производителя сетевого адаптера, а оставшиеся являются чем-то вроде последовательного номера.
В сети могут быть установлены сетевые адаптеры, изготовленные различными компаниями в
различное время и поэтому предлагающие немного различающиеся списки адресов МАС. Хотя
каждый адрес уникальный, только с его помощью невозможно определить, какой станции
соответствует какой адрес и как к нему добраться на физическом уровне.
Сети используют адреса для идентификации рабочих станций и упрощения процесса
доставки сообщений. Эти логические адреса называются сетевыми адресами. Сетевой адрес
состоит из номера сети и номера станции. Номер сети соответствует номеру сегмента сети,
которому принадлежит данная станция., а номер станции однозначно определяет станцию в
сегменте.
Каждый сетевой протокол использует свою собственную схему сетевой логической
адресации. В IPX сетевой номер и номер станции обрабатываются отдельно. В TCP/IP они
объединены в одном адресе IP, который анализируется с помощью второго параметра,
называемого маской подсети.
Использование протокола TCP/IP
TCP/IP – это наиболее распространённый сетевой протокол, в частности, в объединённых
сетях, с отличными возможностям организации сетей. Протокол управления передачей/протокол
Internet (Transmission Control Protocol/Internet Protocol, TCP/IP) – это промышленный стандарт
протокола для глобальных сетей. Он был разработан в 1969 году организацией Defence Advanced
Research Project Agency (DARPA) как научный проект по соединению в сетях.
Организация DARPA разработала TCP/IP для того, чтобы объединить свои научные сети. Эта
комбинация сетей продолжала расти и теперь включает много агентств, университетов и
корпораций. Эта глобальная сеть носит название Internet.
Функции протокола TCP/IP:
Обеспечивает взаимосвязь между операционными системами и аппаратными
платформами
Обеспечивает доступ в Internet
Обеспечивает маршрутизируемый протокол
Поддерживает Простой протокол управления сетью (Simple Network Management
Protocol, SNMP)
Поддерживает Протокол динамической конфигурации хостов (Dynamic Host
Configuration Protocol, DHCP), который обеспечивает динамические назначения IPадресов
Поддерживает Сервис имен Internet для Windows (Windows Internet Name Service,
WINS), который обеспечивает динамически обновляемую базу данных, проецирующую
IP-адреса на соответствующие им имена NetBIOS
Параметры TCP/IP определены под следующим ключом реестра:
Hkey_Local_Machine\System\CurrentControlSet\Services\Tcpip
Популярности протоколов TCP/IP способствовал ряд следующих факторов:
Завершённость. Определение протоколов TCP/IP началось в 1970 г. для
удовлетворения выдвинутых Министерством обороны США требований в отношении
надёжного протокола для организации глобальных сетей. Протокол TCP/IP получил
25
широкое распространение, когда был встроен в версию Berkley Standard Distribution
(BSD) Unix, и на долгое время стал стандартом реализации Unix.
Открытость. TCP/IP является единственной совокупностью протоколов с открытым
процессом определения стандартов.
Отсутствие прав собственности. Протокол TCP/IP принадлежит всему сообществу
пользователей. Другие протоколы, за небольшим исключением, являются частными
протоколами, правами на которые владеют их поставщики. Производители
программного обеспечения нередко должны платить определённую плату за лицензию,
чтобы встроить частные протоколы в свои продукты.
Избыточность TCP/IP является совокупностью протоколов, которая обеспечивает
множество возможностей
Совместимость TCP/IP является единственным набором протоколов, которая
работает почти на всех платформах. Наличие поддержки протокола TCP/IP теперь
рассматривается как требование к системе.
Протокол TCP/IP основывается на физических адресах для доставки сообщений в
локальной сети.
Компьютеры, работающие в сетях с протоколом TCP/IP, называются узлами (hosts). В
протоколе TCP/IP каждая локальная сеть называется подсетью (subnet). Когда сообщение не
предназначено для устройства в локальной подсети, оно должно быть маршрутизировано. Каждой
подсети присваивается соответствующий адрес. Каждый ПК конфигурируется со стандартным
маршрутизатором, которому он посылает сообщения, подлежащие пересылке в удалённую
подсеть.
Ответственность за определение способа адресации сообщения составляет одну из задач
межсетевого протокола IP. Этот протокол определяет, предназначено ли данное сообщение ПК в
локальной сети или же его следует переслать стандартному маршрутизатору. Протокол использует
адреса, называемые адресами межсетевого протокола или IP-адресами, для логического
обозначения подсетей и устройств.
4.4 IP-адреса
Сетевые адреса, в отличие от физических, не программируются в ПЗУ каких-либо аппаратных
средств. Сетевые адреса присваиваются сетевыми администраторами и логически
конфигурируются в сетевых устройствах.
Помимо подсетей, протокол TCP/IP также присваивает логические адреса каждому узлу сети.
Логические IP-адреса усложняют установку сети, но имеют некоторые преимущества:
Не зависят от конкретной реализации физического уровня. Процессы верхних
уровней могут использовать логические адреса, не заботясь о формате адреса нижнего
физического уровня
Устройство может сохранять тот же логический IP-адрес, даже если его физический
уровень изменится. Переход от одной сети (Token Ring) к сети типа Ethernet не
оказывает никакого влияния на IP-адрес.
Формат IP-адреса
IP-адреса представляют собой 32-разрядные числа, которые содержат оба адреса – подсети
и узла. Пример IP-адреса:
11000001000010100001111000000010
Не так то просто его проанализировать. Чтобы облегчить работу с IP-адресами, 32-разрядные
адреса разделяют на четыре октета (т.е. 8-разрядных части):
26
1100001 00001010 00011110 00000010
Каждый из октетов может быть преобразован в десятичное число в пределах от 0 до 255. это
приводит к более удобному способу представления приведённого примера IP-адреса:
193. 10. 30. 2
Классы IP-адресов
Каждый IP-адрес состоит из двух полей:
Поля идентификатор сети (netid), являющегося логическим сетевым адресом
подсети, к которой подключен данный ПК
Поля идентификатор узла (hostid), являющегося логическим адресом устройства,
который уникальным образом обозначает каждый узел или подсеть.
IP-адреса организованы в классы. Определить класс IP-адреса можно путём определения его
первого октета:
От 0 до 127, то это адрес класса А. Доступны 126 адресов, каждый из которых
может поддерживать 16777214 узлов.
От 128 до 191, то это адрес класса В. Доступны 16384 адресов, каждый из которых
может поддерживать 65534 узлов.
От 192 до 223 , то это адрес класса С. Доступны 209792 адресов, каждый из которых
может поддерживать 254 узлов.
В табл. 3.1 показано, каким образом организованы октеты для каждого класса.
Таблица 3.1
Класс А
Класс В
Класс С
NNNNNNNN
HHHHHHHH
HHHHHHHH
NNNNNNNN
NNNNNNNN
HHHHHHHH
NNNNNNNN
NNNNNNNN
NNNNNNNN
N – Идентификатор сети H - идентификатор узла
HHHHHHHH
HHHHHHHH
HHHHHHHH
Примечание. Класс адреса определяется крайними слева разрядами в первом октете:
Если 1 разряд = 0, то это адрес класса А
Если два 1-х разряда = 10, то это адрес класса В
Если три 1-х разряда = 110, то это адрес класса С
Если четыре 1-х разряда = 1110, то это адрес класса D
Если пять 1-х разрядов = 1111, то это адрес класса E
Классы D и E недоступны для адресации стандартной сети.
4.5 Литература
Сетевые средства Microsoft WINDOWS NT Server 4.0 : Пер. С англ. – СПб.: BHV – Санкт-Петербург, 1999, Глава
4, Стр. 163-187; Приложение H, Стр. 817-822;
Мельников Д.А. «Информационные процессы в компьютерных сетях. Протоколы, стандарты, интерфейсы,
модели…» - М: КУДИЦ-ОБРАЗ, 1999, Глава 7 Стр. 72-75
Спортак М и др. «Высокопроизводительные сети. Энциклопедия пользователя», Пер. с англ., - К: Издательство
«ДиаСофт», 1998, Главы 29. Стр. 388-406
Собственное изложение материала.
5 Лекция № 5. Структура корпораций и предприятий. Архитектура
корпоративных информационных систем (КИС). Исследования настоящей
27
сети. Установка приоритетов. Интегрирование сетей с использованием
модели, основанной на сервисах. Создание информационного плана.
5.1 Структура корпораций и предприятий.
Структура (от лат. Structura – строение, расположение, порядок) – совокупность устойчивых
связей объекта, обеспечивающих его целостность и тождественность самому себе, т.е. сохранение
основных свойств при различных внешних и внутренних изменениях.
Корпорация (от позднелат. Corporation - объединение) – 1) союз, общество; 2) (Юрид.)
объединённая группа, круг лиц одной профессии, объединившихся для достижения какой-либо
цели; является юридическим лицом. Например, публичные корпорации – муниципалитеты,
частные – акционерные общества. Одна из форм монополистического объединения.
Корпоративный – узкогрупповой, замкнутый пределами корпорации.
Предприятие – объединение людей, совместно реализующих программу или цель и действующих
на основе определённых правил и процедур, используя средства труда.
Структура корпораций и предприятий может носить совершенно произвольный характер и
определяться целями и задачами данного конкретного предприятия или корпорации в целом.
Структура корпораций и предприятий характеризуется:
Местоположением
Количеством подразделений
Производственными задачами
Производственными возможностями
Сервисами (услугами, производимыми на рынок товаров и услуг)
Как правило, стиль организации корпораций является интернациональным.
5.2 Архитектура корпоративных информационных систем (КИС).
В настоящее время корпоративные компьютерные среды являются гетерогенными. Это
значит, что в качестве стандарта в таких средах приняты, по крайней мере, две различные сетевые
операционные системы, которые должны работать как с современными средами клиент-сервер,
так и с устаревшими (legacy) компьютерами и приложениями.
Сетевые администраторы должны добиваться совместной работы этих систем. В процессе
интеграции они часто обнаруживают, что различные сетевые ОС не используют один и тот же
стандартный протокол. В различных частях таких сетей вполне возможно существование
нестандартных или даже закрытых протоколов (proprietary protocols). Если такая ситуация
возникает, необходимо искать пути для объединения этих сетей с тем, чтобы они могли
взаимодействовать и дополнять друг друга.
Чтобы проиллюстрировать проблемы, возникающие при объединении гетерогенных сред, а также
способы их решения, рассмотрим сеть для гипотетической компании, которую назовём «Трест
НефтеПромКом». Эта вымышленная компания в международном масштабе занимается
геологическими изысканиями пластов, разведкой месторождений, их разработкой и освоением,
добычей, а также дальнейшей консервацией полезных ископаемых, и соблюдением проблем,
связанных с экологией при разработке, освоении и добыче. «Трест НефтеПромКом» будет
служить примером компании с гетерогенными сетями, иллюстрирующим разработку и внедрение
плана объединения информационных систем. Разработанный план будет полностью
соответствовать бизнесу компании и её целям.
28
Знакомство с «Трест НефтеПромКом». История корпорации.
«Трест НефтеПромКом» является интернациональной корпорацией. Когда корпорация
«Трест НефтеПромКом» только начинала свою деятельность, она состояла из одного управления,
находящегося в г. Самара РФ, которое начало свою деятельность 1943 году. Разведка
значительных запасов нефти привела к необходимости создания собственных служб разведки
площадей, анализа пластов, интерпретации геофизических материалов, бурения, добычи,
капитального ремонта скважин, вспомогательных служб (автотранспорт, столовые, научные и
учебные учреждения, строительные участки, ремонтные мастерские, цеха изготовления
собственной продукции, ЖКХ (ТСЖ) и ДОУ и пр.)
По мере роста компании началось заключение контрактов с иностранными фирмами по оказанию
услуг этим фирмам.
В начале 90-х годов корпорация акционировалась и предложила акции на биржевой рынок.
Основные направления бизнеса корпорации:
Геологоразведка
Сейсморазведка
Бурение
Добыча
Реализация сырой нефти
Перегонка нефти
Научные изыскания
Организация корпорации «Трест НефтеПромКом».
В настоящее время в составе корпорации «Трест НефтеПромКом» имеются три основных
подразделения:
УБР (Управление буровых работ)
НГДУ (Нефтегазодобывающее управление)
УПНП и КРС (Управление и капитальный ремонт скважин)
и шесть вспомогательных подразделений:
УТТ (Управление технологического транспорта)
НТУ (Научно-техническое управление)
СУ (Строительное управление)
РМУ (Ремонтно-механическое управление)
Комбинат питания
Нефтяной колледж
УЖКХ (Управление жилищно-коммунального хозяйства) и ДОУ (Дошкольные
образовательные учреждения)
Центральные офисы корпорации и некоторых подразделений находятся в г. Самара. Каждое
подразделение ведёт деловые операции как в пределах РФ, так и за границей РФ: в странах
ближнего зарубежья (Казахстан, Белоруссия), Африке (Ангола, Ливия), Ближний Восток (Сирия,
Иран, Кувейт).
До последнего времени каждое основное подразделение корпорации «Трест НефтеПромКом»
работало как отдельная компания, осуществляя независимую политику, которую менеджеры
данного подразделения считали необходимой и важной для бизнеса. Автономность каждого
подразделения была результатом быстрого роста, а также того факта, что все эти подразделения
работали вместе очень хорошо, несмотря на некоторую неэффективность.
Перестройка сети «Трест НефтеПромКом».
Просуммировав основные факты использования сети каждым подразделением для бизнеспроцессов и операций, администратор по информационным технологиям начинает анализ деловых
29
и технических проблем. Это делается для того, чтобы создать план перестройки сети.
Планирование будет производиться в три этапа:
Исследование существующей сети
Распределение целей разработки по уровням приоритетов
Разработка пути интегрирования сети как модели, основанной на сервисах
Исследования настоящей сети.
Для изучения существующей сети администратор по информационным технологиям должен
предпринять следующие шаги:
Описать всю аппаратуру сети, включая клиентов, рабочие станции и серверы. Эта
информация должна быть достаточно детализирована для того, чтобы помочь принять
решение о том, какое оборудование должно быть улучшено
Описать географическое расположение как локальных сетей, так и сетей WAN,
включая передающую среду, использованную в ЛВС и в WAN
Определить местоположение сетевых компонентов и операционных систем
Получить информацию о пропускной способности
Определить конкретные задачи, стояще перед пользователями, количество
пользователей, решающих эти задачи, и интенсивности использования сети
Определить специфические задачи, такие как сохранение файлов, резервирование
серверов, пересылка данных в базе данных, репликация данных и распределение
приложений.
Установка приоритетов.
Цели должны быть организованы со следующими уровнями приоритетов:
Цели, важнейшие для бизнеса
Стратегические задачи
Задачи улучшения условий работы пользователей
Перспективные цели
Цели, важнейшие для бизнеса
Жизненно важными для бизнеса являются те цели, выполнение которых требуется для
текущего поддержания и расширения бизнеса. Они должны быть достигнуты настолько
быстро, насколько это возможно. Корпорация «Трест НефтеПромКом» определяет
следующие цели, на выполнение которых отведено не боле трёх месяцев:
Физически соединить пять сетей
Перейти на общий сетевой протокол
Определить параметры безопасности для аутентификации входа в систему
Позволить пользователям разделять необходимые файлы и принтеры
Интегрировать существующие системы для интенсификации деловых
процессов
Уменьшить расходы на обучение
Предоставить возможность ведения бизнеса с использованием Internet
Стратегические задачи
Стратегические задачи обеспечивают чистую выгоду от бизнеса. Эти цели могут быть
выполнены в течении 3-6 месяцев без какого-либо вреда или потерь для бизнеса. Корпорация
«Трест НефтеПромКом» имеет следующие стратегические цели:
Централизовать пользовательские бюджеты
Централизовать администрирование сети и резервное копирование данных
Централизовать распространение приложений
30
Расширить сеть корпорации «Трест НефтеПромКом» и предоставить её услуги всем
работникам
Создать центральные информационные хранилища и приложения
Позволить динамическую IP-адресацию сети
Предоставить всем работникам сервис электронной почты
Распространять электронным способом информацию, касающуюся всей корпорации
Задачи улучшения условий работы пользователей
Поддержка работы пользователей призвана увеличивать продуктивность и эффективность
их деятельности. Поставленные задачи могут быть решены в течении 6-12 месяцев без каких-либо
потерь или нанесения ущерба бизнесу. Корпорация «Трест НефтеПромКом» определила
следующие задачи по улучшению условий работы пользователей:
Доступ для работников в Internet
Возможность работы по телефонным и иным каналам
Перспективные цели
Перспективными являются цели, которые хорошо было бы достигнуть, но они не являются
насущными в настоящее время. Эти цели могут быть выполнены в любое время. Корпорация
«Трест НефтеПромКом» имеет одну перспективную цель – внедрить пространство имён DSN,
используя полные имена доменов, такие, как ubr.neftpromcom.com.
5.3 Интегрирование сетей с использованием модели, основанной на
сервисах.
Сервисы, предоставляемые сетью, могут быть рассмотрены независимо от структуры сети
подразделения. Модель интегрирования сети группирует ПК по признаку того сервиса, который
они обеспечивают компании, а не принадлежности к подразделениям. Сервисы могут быть
сгруппированы в 4 категории, называемые уровнями:
Уровень предприятия
Уровень подразделения
Уровень отдела
Уровень рабочего места
Таблица 4.1
Сетевой
уровень
предприятие
Поставляемый сервис
Количество
пользователей
Поддержка
глобальной
сети
(такая
как 40 000
централизованное создание бюджетов пользователей и
обслуживание сети) Создание и хранение главных
копий информации, используемой всей организацией
подразделение Централизованный файловый и принтерный сервис и 100-3000
доступ к приложениям, обеспечивающий базовые
деловые операции
отдел
Локальный файловый и принтерный сервис и доступ к 25-100
приложениям, обеспечивающий текущие деловые
операции
рабочее место Локальный файловый и принтерный сервис и доступ к 1-25
приложениям, обеспечивающий персональные деловые
операции
Новая модель также даёт возможность производить изменения в других областях деятельности:
Интеграция работников информационных структур
31
Централизация поддержки сети
Разработка бюджета и слежение за денежными расходами
5.4 Сервисы уровня предприятия
Серверы этого уровня предназначены для поддержки глобальной сети (централизованное
управление бюджетами пользователей и администрирование) и поддержка главной копии общей
информации в масштабах организации. Серверы предприятия непосредственно подключены к
корпоративной или удалённой магистрали (backbone)/ они содержаться в защищённых средах и
находятся в ведении сетевых администраторов. Такие серверы обычно работают на линиях со
скоростью 100 Мбит/с. (FDDI, CDDI или Fast Ethernet). Сервер предприятия может обеспечивать
сетевой сервис для 40 000 пользователей.
Степень доступности сервера для пользователей определяет, какие сервисы существуют на
определённом уровне. Когда большое расстояние разделяет сервер и пользователей, то трафик
основной магистрали может сделать доступ к серверу затруднённым. Связи по WAN могут быть
низкоскоростными и дорогими. Для создания и обновления информации, которую пользователи
могут разделять, имеет смысл назначить серверам самый высший уровень (предприятие).
Сервисы, которые обычно предлагаются на этом уровне, включают следующие виды:
Аутентификация при входе. Этот сервис следит за тем, чтобы пользователи,
входящие в сеть и предпринимающие определённые действия, могли сделать только то, на
что они имеют права.
Репликация базы данных бюджетов пользователей. Этот сервис позволяет
реплицировать копии базы данных каталогов (Directory Database) на другие серверы,
эффективно распределяя процесс аутентификации входа.
Централизованные сетевые сервисы. Эти сервисы позволяют администраторам
конфигурировать сервисы сети так, что они будут воздействовать на всю сеть и делать
любые административные изменения с одного места.
Распознавание имён. Этот сервис централизует распознавание уникальных
пользовательских имён и адресов, которые предоставляют доступ к компьютерным
ресурсам сети.
Резервное копирование. Обычно серверы любого уровня обеспечивают сервис
резервного копирования для серверов более низкого уровня. Серверы предприятия
выполняют эту функцию для серверов на уровне подразделений, которые в свою очередь
выполняют резервное копирование для серверов уровня отдела. Серверы предприятия
обычно не выполняют резервное копирование на уровне отделов.
Ограничение количества поддерживаемых протоколов. Для уменьшения сетевого
трафика по магистрали предприятия серверы этого уровня могут поддерживать только
один или два сетевых протокола. Обычно это протокол TCP/IP.
Сервисы Internet, использующие информационный сервер Internet (сервис IIS). Эти
сервисы могут быть использованы для создания WEB-серверов, в которые может войти
любой пользователь Internet, для получения корпоративной информации и информации для
клиентов.
Сервисы Intranet, использующие информационный сервер Internet. Эти серверы
сохраняют информацию, которая доступна всем пользователям внутри корпоративной сети
и недоступна пользователям, находящимся вне компании или организации.
Площадки. Эти сервисы воздействуют на площадки организации, но скрыты от
пользователей. Например, серверы предприятий могут работать как хранилища и главные
источники распространения программного обеспечения, поддерживаемого организацией.
Сервис репликации распространяет ПО на уровень подразделения для распространения на
более низкие уровни.
32
5.5 Сервисы уровня подразделения
Этот уровень обычно содержит централизованные файловые и принтерные приложения,
которые поддерживают деловые операции. Серверы уровня подразделения часто обеспечивают
сетевой сервис до тысячи пользователей, хотя они могут быть масштабированы для поддержки
большего количества пользователей.
Если расположение подразделения или района требуют соединения по низкоскоростным линиям
WAN, тогда серверы могут быть поддержаны на этом уровне.
Уровень подразделения обычно включает следующие сервисы:
Гетерогенные файловые и принтерные интерфейсы. Эти интерфейсы служат для
совместной работы с другими серверами, включая UNIX, NetWare, LAN Server/
Интеграция. Этот уровень может обеспечивать гетерогенные протоколы, такие как
TCP/IP, IPX/SPX,которые позволяют интеграцию с сервисами предполагаемыми UNIX,
NetWare, мейнфреймами.
Информационный сервис Intranet с использованием IIS. Эти серверы предоставляют
корпоративную информацию, которая касается подразделения. Например, здесь хранятся
планы проектов, графики, обзоры, презентации и другая информация для подразделения.
Данные обзора продуктов, сравнение и спецификация могут также здесь храниться для
более лёгкого доступа персонала, работающего в области производства и маркетинга.
Резервное копирование. Серверы на любом уровне обычно обеспечивают резервное
копирование для серверов более низкого уровня. Например, серверы подразделений
выполняют эти функции для серверов уровня отдела.
5.6 Сервисы уровня отдела
Серверы этого уровня решают задачи бизнеса. Эти серверы обеспечивают локальный
сервис файлов, печати и приложений. Они также обеспечивают временное хранение файлов для
проектов рабочих групп, домашние каталоги и каталоги для периодического резервного
копирования. В типичном сценарии для этого уровня серверы организованы в рабочие группы или
отделы, чтобы обеспечить сетевой сервис для 25-100 пользователей.
На уровне предприятия несколько дорогих высокопроизводительных серверов
централизованно выполняют необходимые операции для всей организации.
На уровне подразделений менее дорогие серверы обеспечивают адекватную производительность
для меньших групп. На уровне отделов серверы могут быть машинами класса рабочих станций,
таких как компьютеры Pentium 3 c 256 Мб ОЗУ, работающие под управлением ОС Windows 2000
Server, Windows XP, и даже Windows NT Server.
Серверы уровня отдела обычно обеспечивают следующие сервисы:
Проекты отделов или филиалов. Хранится информация о задачах отделов или
проекта рабочих групп. Серверы уровня предприятия и подразделения могут иметь доступ
к этой информации, для составления отчётов.
Информационные сервисы Intranet (с использованием сервиса Internet Information
Server). Эта информация касается определённого отдела. Отчёты о состоянии и другая
информация посылается сюда для её просмотра работниками отдела.
Сервисы Internet (с использованием сервиса Internet Information Server). На этом
уровне WEB-серверы, относящиеся к определённым проектам, могут быть созданы и
включены в Internet.
Резервное копирование. Серверы на любом уровне обычно обеспечивают сервис
резервного копирования для серверов или компьютеров более низкого уровня. Серверы
отделов выполняют эту функцию для компьютеров уровня рабочего места.
33
5.7 Сервисы уровня рабочего места
В большом количестве корпораций компьютеры на рабочих местах являются основой для
продуктивной работы. Они работают под управлением ОС Windows 2000 SP4 или Windows XP
SP2 с различными приложениями, такими как Microsoft Office 2003, и программным обеспечением
для определённых деловых операций. Основная задача в данном случае состоит в том, чтобы
обеспечить сервисы для удалённого мобильного клиента и клиентского рабочего места.
Логическое разграничение групп рабочих мест может включать как небольшие отделы от 5 до 20
человек, так и тысячи отдельно стоящих компьютеров.
Сервисы, предлагаемые здесь, включают следующие функции:
Хранение персональных файлов. Рабочее место обеспечивает хранение персональных
файлов и данных для деловых приложений.
Локальные приложения. Для повышения производительности рабочих мест
локальным приложением может быть Microsoft Office Professional. Для рабочих мест
разработчиков приложением могут быть компиляторы Microsoft С++ и отладочные версии
ОС. Для разработчиков сервиса баз данных необходимы SQL-приложения.
5.8 Создание информационного плана.
Годовой план компании заключается в том, чтобы решить все жизненно важные задачи и
достичь как можно большего в области стратегических направлений развития компьютерной сети.
Для интегрирования информационной системы будет применена сеть Windows 2003 Server
и её сервисы, а также некоторые сервисы сторонних производителей. На новом оборудовании,
которое покупает компания, будут установлены ОС Windows 2003 Server, Windows XP, Windows
2000 Advancer Server и Windows 2003 SP1. Это – наиболее подходящие продукты для решения
поставленных задач переустройства сети компании.
Информационный план определяет технические решения, которые позволят достичь
поставленных целей. Это показано в таблице 4.1.
Таблица 4.1.
Приоритет
задачи
Важнейшая
Важнейшая
Важнейшая
Важнейшая
Задача
Физическое
объединение сетей
Предоставление
пользователям
возможности
разделения файлов и
принтеров
Интеграция всех
существующих систем
с целью повышения
эффективности бизнеспроцесса
Уменьшение затрат на
обучение
Техническое решение
Покупка маршрутизаторов и коммутаторов,
необходимых для эффективного соединения
сетей.
Файловый и принтерный сервис Windows
2003 Server (или PCNFS для клиентов UNIX)
Необходимо произвести более детальный
анализ деловых прикладных программ. Это
вызвано
двумя
причинами:
нужно
определить то лучшее, что содержится в
каждом приложении и, кроме того,
необходимо разработать план по разработке
прикладных программ для сервера и рабочей
станции, которые позволят эффективно
вести бизнес.
Разработка
логически
правильно
построенного,
дружественного
пользователю интерфейса как на рабочем
месте, так и на сервере. Организация
34
Приоритет
задачи
Задача
Важнейшая
Ведение бизнеса через
Internet
Важнейшая
Переход на
однородный сетевой
протокол
Распознавание
информации
безопасности и
централизованная
аутентификация
запросов на вход в
систему
Создание
централизованной базы
данных бюджетов
пользователей
Важнейшая
Стратегическая
Стратегическая
Стратегическая
Стратегическая
Техническое решение
возможности
присоединения
к
гетерогенным
системам
посредством
логичного интерфейса.
Необходимо организовать маркетинговые
WEB-страницы для Internet. На этих
страницах будут помещены графические
изображения производимой продукции.
WEB-страницы также будут содержать
список услуг, оказываемых населению, часы
работы, информацию по истории компании,
наличию товаров на складах. Внутренние
отделы, осуществляющие поддержку WEBстраниц, получат доступ к этим страницам.
Установка и конфигурирование протокола
TCP/IP на всех сетевых платформах.
Для аутентификации и обеспечения единого
входа в сеть будет использован сервис
Windows 2003 Server.
Для обеспечения возможности работы
пользователя с одним бюджетом в сети
вcего предприятия, будет использован
сервис каталогов Windows 2003 Server,
между доменами будут установлены
доверительные
отношения,
которые
обеспечат единый вход во всю сеть
Централизованное
Использование
сервиса
репликации
администрирование и
Windows 2003 Server для баз данных уровня
управление сетью и
предприятия, а также сервисов WINS, DNS и
резервное копирование DHCP.
Для
текущего
резервного
данных
копирования
данных
планируется
использование
единого
программного
продукта BackUp.
Предоставление
Использование
встроенного
сервиса
возможности работы в
удаленного доступа Windows 2003 Server
компьютерной сети
(RAS) для присоединения мобильных
корпорации работникам пользователей. Использование Windows
предприятия
2003 Server PPTP для соединения с
удалёнными площадками корпорации через
Internet по защищённому каналу. Создание
защищённого канала между площадками и
центральным офисом.
Создание центрального Анализ прикладного ПО и применение
хранилища данных
лучших
программных
продуктов.
Определение требуемого прикладного ПО.
Автоматизация ручного труда там, где это
возможно
в
таких
областях,
как
производственные
линии
и
центры
35
Приоритет
задачи
Задача
Техническое решение
распространения
Стратегическая
Стратегическая
Стратегическая
Установление
динамической IPадресации в сети
Предоставление всем
работникам корпорации
электронной почты
Организация
электронного
распространения
информации в
масштабах корпорации
Использование Windows 2003 DHCP Server
и активация всех возможных клиентов
DHCP
Установка почтовой системы Microsoft
Exchange
Для
электронного
распространения
информации в масштабах корпорации
планируется
использование
Internet
Information Server и Internet Explorer
5.9 Литература
Сетевые средства Microsoft WINDOWS NT Server 4.0 : Пер. С англ. – СПб.: BHV – Санкт-Петербург, 1999, Глава
4, Стр. 163-184
6
Лекция № 6. Пример диаграммы сети предприятия. Общие принципы
именований ПК. Программное обеспечение ПК. Доменная структура
организации.
Диаграмма, приведённая в данном изложении, иллюстрирует новую сетевую модель корпорации
«Трест НефтеПромКом». Показаны все основные сервисы и системы компьютеров. Для краткости
отображена только часть сети, относящаяся к Управлению по реализации сырой нефти и
перегонки нефти.
6.1 Общие принципы именований ПК
Каждый компьютер имеет описание, которое включает следующую информацию:
Компьютерное имя для сервера
IP-адрес сервера
Сервисы, работающие на этом компьютере
Первая строка под каждым компьютером содержит компьютерное имя длиной до 12 символов.
Оно соответствует специальному соглашению об именах, по которому каждый символ
представляет дополнительную информацию о ПК.
Символы 1 и 2. первые два символа показывают домен, в котором находится
компьютер. Корпорация «Трест НефтеПромКом» использует следующие доменные
символы:
SA – представляет домен Самары
NE - представляет домен Западной Сибири и Казахстана
AF - представляет домен Африки
EE- представляет домен Ближнего Востока
Символы 3-7. Пять следующих символов представляют ОС,
которой работает компьютер.
36
под управлением
Таблица 6.1 содержит список пятисимвольных кодов для каждой системы.
Таблица 6.1 Коды операционных систем
Код
IOS02
UNI50
MSD62
WIN00
WIN03
WINXP
WIN98
WIN95
NW410
NTS40
Название операционной системы
IBM OS/2
DEC UNIX c PATHWORKS 5.0
MS DOS 6.22
Microsoft Windows 2000 Server
Microsoft Windows 2003 Server
Microsoft Windows XP
Microsoft Windows 98
Microsoft Windows 95
Novell NetWare 4.10
Microsoft Windows NT Server 4.0
Символы 8-10. Эти символы представляют трёхсимвольный код уровня сервиса:
ENT – уровень предприятия
DIV – уровень подразделения
DPT – уровень отдела
DSK – уровень рабочего места
Символы 11 и 12. Эти символы
представляют идентификационный номер
компьютера. Компьютер может иметь номер, лежащий в диапазоне от 1 до 99.
6.2 Программное обеспечение ПК.
На ПК было установлено разное программное обеспечение. Эти системы используются для
обеспечения сервисов в сети. Первая текстовая строка в описаниях ПК на сетевой диаграмме
зарезервирована для компьютерных имён, а вторая – для IP-адреса ПК. Оставшаяся часть текста
определяет программное обеспечение, загруженное на каждый компьютер. Табл. 6.2 содержит
список кодов и описаний программного обеспечения, соответствующего каждому коду:
Таблица 6.2 коды программного обеспечения
Код
IIS (Internet)
Описание программного обеспечения продукта
Internet Information Server для соединения с Internet
Туннелирующий протокол типа точка-точка (Point-to-Point Tunneling
Protocol), используемый для построения безопасных каналов связи
через Internet. С его помощью корпорация «Трест НефтеПромКом»
планирует создать защищённый канал связи через Internet между
площадками в Самаре, Западной Сибири, Казахстане, Африке и
Ближнем Востоке
Сервер
Большой сервер в Информационном Центре головной организации в
распространения Самаре. Обычно он используется для проектов. Например, вся
документация и файлы для проекта перехода сохраняются на этом
сервере.
IIS (Intranet)
Internet Information Server для внутренней корпоративной сети
Intranet
F&P
Программы доступа к файлам и принтерам
Сервер - член
Сервер, работающий под Windows 200x Server, но не являющийся
домена
PDC или BDC
PPTP
37
Резервный RAS
Центральный
SMS
SA PDC
NE PDC
AF PDC
EE PDC
DHCP
WINS
DNS
Intranet Server
ORACLE
X/Windows
MS DOS 6.22
Редиректор NFS
MPR
SA BDC
NE BDC
AF BDC
EE BDC
Система Windows 200x Server, на которой работает RAS, сервис
восстановления
после
сбоев
и
сервис
аутентификации.
Предназначена для разгрузки основного сервера RAS
Центральный узел Microsoft Management Server
PDC домена Самары, используемый для аутентификации доступа в
сеть и к сетевым ресурсам
PDC домена Западной Сибири и Казахстана, используемый для
аутентификации доступа в сеть и к сетевым ресурсам
PDC домена Африки, используемый для аутентификации доступа в
сеть и к сетевым ресурсам
PDC домена Ближнего Востока, используемый для аутентификации
доступа в сеть и к сетевым ресурсам
Протокол
динамической
конфигурации
хостов
(DHCP),
используемый
для
динамического
назначения
IP-адреса
компьютерам, когда они перемещаются в другую подсеть
Сервис Windows по распознаванию имён Internet, используется для
динамического отображения имён NetBIOS в адреса TCP/IP
Domain Name System, используется для обеспечения отображения
полных имён доменов в их IP-адреса
Внутренний сервер корпоративной сети, используемый для
предоставления пользователям интерактивного информационного
обеспечения через протоколы Internet, такие как HTTP, FTP, Gopher
Загружаемый модуль ORACLE
Оконная среда для систем UNIX в альтернативной модели клиентсервер
Microsoft DOS v.6.22
Даёт возможность соединения с сервером, обеспечивая доступ к
Network File System (NFS), обычно системы UNIX
Мультипротокольный
маршрутизатор,
выполняющий
маршрутизацию IP-пакетов между подсетями
Резервный контроллер домена г. Самары, используемый для
аутентификации и репликации базы данных каталогов, сохраняемой
на PDC
Резервный контроллер домена Западной Сибири и Казахстана,
используемый для аутентификации и репликации базы данных
каталогов, сохраняемой на PDC
Резервный контроллер домена Африки, используемый для
аутентификации и репликации базы данных каталогов, сохраняемой
на PDC
Резервный контроллер домена Ближнего Востока, используемый для
аутентификации и репликации базы данных каталогов, сохраняемой
на PDC
6.3 Основные понятия доменной структуры организации.
Домен (domain) — в Windows 200’X и в службе каталогов Active Directory — семейство
компьютеров, определяемое администратором сети Windows 200’X Server, которое имеет общую
базу данных каталогов. Домен имеет уникальное имя и обеспечивает доступ к централизованному
набору учетных записей пользователей и групп, который поддерживается администратором
домена. Каждый домен имеет собственные политики безопасности и доверительные отношения с
38
другими доменами и определяет область безопасности сети компьютеров с Windows 200’X/XP.
Служба каталогов Active Directory состоит из одного или нескольких доменов, каждый из которых
может включать несколько физических мест. Для службы DNS доменом является любое дерево
или поддерево в пространстве имен DNS. Хотя имена доменов DNS часто соответствуют именам
доменов службы каталогов Active Directiry, не следует путать домены DNS с сетевыми доменами
Windows 200’X и Active Directory.
Служба каталогов Active Directory (Active Directory services) — служба каталогов,
поставляемая с Windows 200’X Server. Хранит информацию обо всех объектах сети и
предоставляет ее пользователям и администраторам сети. Позволяет пользователям сети
осуществлять доступ к предусмотренным ресурсам в рамках одного процесса подключения.
Кроме того, Active Directory предоставляет администраторам сети интуитивное иерархическое
представление сети и позволяет централизованно управлять всеми ее объектами.
Доверительные отношения (trust relationship) — логическая связь между доменами,
обеспечивающая сквозную аутентификацию, при которой домен доверяет проверке подлинности,
выполненной в доверенном домене. Учетные записи пользователей и глобальные группы,
определенные в доверенном домене, могут получить права и разрешения на ресурсы в доменедоверителе даже в тех случаях, когда эти учетные записи не существуют в справочной базе
данных домена-доверителя.
Проверка подлинности (authentication) — процесс проверки регистрационных сведений,
предоставленных пользователем. Имя пользователя и пароль проверяются по списку
пользователей, которым разрешен доступ в систему. Если данные обнаружены, пользователю
предоставляется доступ, определяемый набором соответствующих разрешений. При входе
пользователя в компьютер, на котором выполняется Windows 200’X Professional, проверка
подлинности осуществляется этой рабочей станцией. Если пользователь входит в домен на
компьютере, где выполняется Windows 200’X Server, проверка подлинности может быть
выполнена любым сервером в этом домене.
Группа (group) — совокупность пользователей, компьютеров, контактов и других групп.
Группы применяют для управления доступом или в качестве списков рассылки. Группы
распространения применяются только в электронной почте. Группы безопасности используются
как для управления доступом, так и в качестве списков рассылки.
Локальная группа (local group) — группа на компьютере с Windows 200’X Professional
или рядовом сервере, которой могут быть предоставлены разрешения и права с локального
компьютера и, если этот компьютер участвует в домене, в которую могут быть добавлены учетные
записи пользователей из собственного или доверенных доменов.
Локальная группа домена
(domain local group) — группа безопасности или распространения, которая может содержать
универсальные группы, глобальные группы и учетные записи из любого домена, входящего в
дерево доменов или лес. Локальная группа может также содержать другие локальные группы из
своего собственного домена. Права и разрешения допустимо назначать только в домене,
содержащем группу.
Группа безопасности (security group) — группа, которую разрешено включать в
избирательные таблицы управления доступом Discretionary Access Control List (DACL),
определяющие разрешения для ресурсов и объектов. Группу безопасности можно также
использовать в качестве адресата электронной почты. Сообщение электронной почты,
отправленное группе, рассылается всем членам группы. Группа распространения Discretionary
Access Control List (DACL) — список, часть дескриптора безопасности объекта, представляющий
или отменяющий разрешения для конкретных пользователей и групп.
Группа распространения (distribution group) — группа, предназначенная исключительно
для распространения почты и не содержащая средств безопасности. Ее запрещено включать в
избирательные списки управления доступом (DACL), определяющие разрешения для ресурсов и
объектов. Используются только приложениями электронной почты (например, Microsoft Exchange)
для отправки сообщений нескольким пользователям. Если группа для обеспечения безопасности
не требуется, вместо группы безопасности следует создать группу распространения.
Дерево (tree) — группа доменов Windows 200’X/XP с общим связанным пространством
имен.
39
Лес (forest) — объединение нескольких доменов Windows 200’X, совместно использующих
общую схему, конфигурацию и глобальный каталог, а также связанные транзитивными
двусторонними доверительными отношениями.
Глобальный каталог (global catalog) — служба и физическое хранилище, содержащее
реплики определенных атрибутов всех объектов Active Directory.
Глобальная группа (global group) — группа Windows 200’X Server, которой можно
предоставить права и разрешения и которая может стать членом локальных групп своего домена,
его серверов и рабочих станций, а также доменов-доверителей. В этой группе содержатся учетные
записи пользователей только из собственного домена. Глобальные группы обеспечивают удобный
способ создания наборов пользователей домена, которые применяются как внутри, так и вне
домена. Нельзя создавать или обслуживать глобальные группы на компьютерах с операционной
системой Windows 200’X Professional. Однако на компьютерах под управлением Windows 200’X
Professional/XP, включенных в домен, глобальные группы домена могут получить права и
разрешения для этих рабочих станций и стать членами локальных групп на этих рабочих
станциях.
Учетная запись группы (group account) — набор учетных записей пользователей. При
включении учетной записи пользователя в группу соответствующей пользователь получает все
права и разрешения, предоставленные этой группе.
Учетная запись компьютера (computer account) — учетная запись, создаваемая
администратором домена и однозначно определяющая компьютер в домене. Учетная запись
компьютера Windows 200’X соответствует имени компьютера в домене.
Учетная запись пользователя (user account) — запись, содержащая все сведения,
определяющие пользователя в операционной системе Windows 200’X. Это имя пользователя и
пароль, требуемые для входа пользователя в систему, имена групп, членом которых пользователь
является, а также права и разрешения, которые он имеет при работе в системе и доступе к ее
ресурсам. В Windows 200’X Professional/XP и на рядовых серверах учетные записи пользователей
управляются оснасткой Local User and Groups (Локальные пользователи и группы). На
контроллерах домена с Windows 200’X Server работа с учетными записями пользователей
выполняется в оснастке Active Directory Users and Computers (Active Directory — пользователи и
компьютеры).
Учётная политика (account policy) — метод управления характеристиками паролей всех
учетных записей домена или отдельного компьютера.
Имя пользователя (user name) — уникальное имя, определяющее учетную запись
пользователя в Windows 200’X/XP. Имя пользователя, определенное в учетной записи, не может
совпадать с каким-либо другим именем группы или именем пользователя в том же домене или
рабочей группе.
6.4 Планирование доменной структуры организации.
Имя домена (domain name) — в Windows 200’X Server и Active Directory имя, задаваемое
администратором набору сетевых компьютеров, совместно использующих одну справочную базу
данных (каталог). Доменные имена DNS представляют собой названия конкретных узлов в дереве
пространства имен. Они состоят из меток, соединенных вместе точками (.), обозначающими
уровни узлов в пространстве имен. См. также Domain Name System (DNS); пространство имен.
Контроллер домена (domain controller) — компьютер, расположенный в домене Windows
200’X Server, работающий под управлением этой ОС и управляющий входом пользователей в
сеть, проверкой их подлинности и доступом к каталогу и общим ресурсам.
Основной контроллер домена (primary domain controller (PDC)) — самый первый в
домене компьютер, на который устанавливается Windows 200’X Server. Хранит главную копию БД
учетных записей домена, аутентифицирует пользователей; может работать как сервер файлов,
сервер печати и сервер приложений. В каждом домене допустим только один PDC.
Резервный контроллер домена (backup domain controller (BDC)) — в домене Windows
200’X Server— компьютер, который хранит копию политики безопасности домена и базы учетных
40
данных домена и производит аутентификацию регистрирующихся в сети пользователей. Служит
резервом, если основной контроллер домена недоступен. Наличие резервного контроллера в
домене необязательно, но рекомендуется.
Родительский домен (parent domain) — домен, расположенный в дереве пространства
имен DNS непосредственно над другими производными доменными именами (дочерними
доменами). Например, microsoft.com мог бы быть родительским доменом дочернего домена
example.microsoft.com.
Дочерний домен (child domain) — домен, расположенный в дереве пространства имен на
один уровень ниже родительского домена. Например, example.microsoft.com мог бы быть
дочерним доменом родительского домена microsoft.com. Также называется поддоменом
(subdomain).
При использовании доверительных отношений применяются три типа доменных моделей:
Модель одиночного домена (single domain model)
Модель одиночного основного домена (single master domain model)
Модель множества основных доменов (multiple master domain model)
Доверительные отношения обеспечивают гибкость. Выбираемая для организации доменная
модель должна соответствовать тому способу, которым будет осуществляться управление
организацией. Количество пользователей в организации, топология сети и расположение
компьютеров также будут влиять на доменную структуру и распределение ресурсов. Программное
обеспечение мало налагает ограничений, которые могут повлиять на доменную структуру.
Поэтому в принятии решения о структуре доменной модели необходимо сделать следующие
предположения:
В отличие от программного обеспечения, аппаратная часть сервера ограничивает
количество активных пользователей или одновременных сеансов, которые он может
поддерживать
Реальные ограничения системы Windows 200x Server зачастую значительно
превышают возможности сервера
Процесс разработки и выбора является рекурсивным. Решения, которые
принимаются на ранних стадиях процесса планирования, должны быть проверены в свете
информации, полученной впоследствии. Нужно быть готовым к тому, что придётся
выполнить несколько итераций прежде, чем будет принято окончательное решение, и
начата его реализация.
6.5 Множество независимых направлений бизнеса
Корпорация «Трест НефтеПромКом» имеет несколько независимых направлений бизнеса,
например, управления по бурению, добыче и ремонту скважин; управление по реализации сырой
нефти и перегонки нефти; научно-техническое управление; управление технологического
транспорта; ремонтно-механическое управление; группы маркетинга и обработки данных внутри
каждого из этих подразделений. Центр фирмы – это не большая группа, основной деятельностью
которой является функциональный сервис. В состав этой группы должны входить:
Аппарат управления
Бухгалтерия
Отдел финансов
Отдел кадров
Отдел лизинговых услуг
Отдел консалтинга
Отдел механика
41
НТУ
Вычислительный Центр
Управления по бурению
Управление по реализации
Ресурсные
домены
Ресурсные домены
Ресурсные домены
Рис. 6.1. Доменная модель для организации, в которой существует множество независимых направлений
бизнеса
Обычно пользователи требуют доступа только к ресурсам своего подразделения. Но в ряде
случаев требуется доступ к ресурсам другого подразделения. Это означает, что основные домены
(master domains) должны быть взаимосвязаны (рис. 6.1).
Модель множества основных доменов – лучший выбор для данного случая, потому что
организация испытывает недостаток в персонале, занятом на обработке данных в центральном
подразделении. Доменная модель должна быть разработана таким образом, чтобы обеспечивать
автономную обработку данных в подразделениях. При необходимости, между доменами могут
быть созданы доверительные отношения.
6.6 Крупная организация
Крупное подразделение (с численностью сотрудников до 100 тысяч человек) может иметь
множество площадок. При использовании основных доменов, количество пользователей на один
основной домен может достигать 40 тысяч, потому что компьютерные бюджеты находятся в
ресурсных доменах (resource domains). Например, можно создать три основных домена по 33
тысячи пользователей в каждом или, предполагая дальнейший рост количества пользователей, 4
основных по 25 тысяч пользователей в каждом (рис. 6.2).
Самара
Западная Сибирь, Казахстан
Африка
42
Ближний Восток
Ресурсные домены Ресурсные домены Ресурсные домены Ресурсные домены
Рис. 6.2. Доменная модель крупной организации
Структура домена, в котором определён пользователь, может быть основана на принципе
группировки в алфавитном порядке, по подразделениям, по отделам, по месту расположения. В
каком домене определяется конкретный пользователь, большого значения не имеет, потому что
между каждым ресурсным доменом и каждым основным доменом существуют доверительные
отношения.
6.7 Офисы подразделений
В офисах подразделений обычно используется модель одиночного домена или модель
одиночного основного домена. Компании с большим количеством небольших подразделений
могут группировать эти подразделения в региональные домены, обеспечивающие
администрирование подразделений.
Когда подразделение связано с PDC посредством коммуникационной линии или модема, то
сервер BDC должен находиться в подразделении. BDC управляет локальной аутентификацией и
локальным файловым и принтерным сервисом. Для повышения устойчивости при аварийных
ситуациях можно добавить второй BDC (рис. 6.3).
PDC
BDC
Управление
Ценральный
BDC
BDC
офис
Управление
Управление
BDC
Управление
Рис. 6.3 Доменная модель подразделения
6.8 Защищённые домены
Модель множества основных доменов предполагает доверительные отношения. Пользователи
во всех доменах за счёт этого могут иметь доступ к ресурсам в любом домене. Однако некоторую
конфиденциальную информацию необходимо скрыть. В этом случае следует создавать домены,
включающие одно подразделение, работающее с информацией ограниченного распространения.
Эти домены являются доверяемыми по отношению к основному домену, но не имеют
доверительных отношений с другими доменами. Пользователи таких доменов имеют доступ к
ресурсам основного домена, но их собственные ресурсы остаются в безопасности.
Односторонние
доверительные отношения
Отдел
Односторонние
доверительные отношения
Основной домен
Отдел
43
Ресурсные домены Ресурсные домены Ресурсные домены Ресурсные домены
6.9 Рекомендации по управлению и администрированию
ОС даёт возможность управлять пользовательскими бюджетами как централизовано, так и
децентрализовано. При использовании централизованного управления существуют обычно одна
база данных каталога и один основной домен, в котором сохранена вся пользовательская
информация. Пользователи определяются в сети только один раз, и им даётся разрешение на
доступ к ресурсам на основании их входной идентификационной информации в центральной
пользовательской базе данных. Модель одиночного домена и модель одиночного основного
домена управляется централизовано. Модель множества основных доменов также может
управляться централизовано путём добавления администраторов к соответствующим группам
Admin.
При децентрализованном управлении существует несколько баз данных каталога, содержащих
информацию о различных пользователях организации. Чтобы дать возможность пользователям
одних доменов иметь доступ к ресурсам других доменов, можно создать доверительные
отношения. Для децентрализованного управления может быть использована модель множества
основных доменов и модель одиночного домена. При планировании доменной модели потребуется
установить административную политику и процедуры для следующих задач:
Управление и поддержка доменов и пользователей
Управление и поддержка ресурсов
Установка адресации и соглашений по именам
6.10 Рекомендации по расположению
Два наиболее важных момента:
Где поместить резервные контроллеры доменов (BDC)
Планирование трафика, возникающего при синхронизации по линиям WAN
Если скорость и полоса пропускания линии WAN низка, лучше, чтобы пользователи входили с
сеть с помощью локального BDC.
Ещё один фактор – географическое расположение организации. Организация может состоять из
одной площадки (site) или из нескольких площадок, соединённых линиями WAN. На каждой
имеется надёжная локальная сеть, которая может соединяться по скоростным линиям связи, таким
как мосты и маршрутизаторы (но не по асинхронным линиям WAN типа T-1, 56К или ISDN).
Площадка в основном соответствует физическому местоположению, такому как Самара, Астана
(Казахстан) или Лангепас (Западная Сибирь).
Физическое распределение серверов BDC определяется несколькими факторами:
скоростью и надёжностью линии
административным доступом
протоколом
требованием по аутентификации пользователей
количеством пользователей, которые поддерживаются на площадке
доступными локальными ресурсами
Приведённая ниже диаграмма показывает часть сетевой топологии, которая обслуживается
доменами. Сетевые концентраторы (hubs) находятся в Самаре, Астане, и Лангепасе. Все эти
площадки принадлежат домену Еврозона: основной домен PDC помещается в Самаре, там же
44
помещается основной концентратор. Основной домен PDC
данных на BDC каждой площадки.
Самары реплицирует свою базу
Лангепас для
Самары
BDC
Астана для
Самары
BDC
Самара
PDC
6.11 Литература
Сетевые средства Microsoft WINDOWS NT Server 4.0 : Пер. С англ. – СПб.: BHV – Санкт-Петербург, 1999, Глава
2, Стр. 109-135; Глава 4, Стр. 185-190
7
Лекция № 7 Контроль доступа. Бюджеты пользователей. Подсчёт времени
репликации. Организация безопасности и уровень защиты C2. Соглашение
об именах. Устранение неисправностей
7.1 Контроль доступа
ОС обеспечивает контроль действий пользователей в сети, определяя для каждого
пользователя разрешённые и запрещённые действия. Кроме того, она предоставляет
пользователям доступ к запрашиваемым ими ресурсам сети. Администратор может позволить
некоторым пользователям устанавливать соединения с ресурсами (например, принтерами) и/или
производить определённые действия (например, модифицировать файлы), в то время как другим
пользователям это будет запрещено. Доступ можно ограничить с помощью следующих средств:
Бюджет пользователя
Права пользователя
Группы пользователей
Субъекты и имперсонация (impersonation)
Информация по безопасности объектов (права доступа)
Реализация системы безопасности в сети включает использование доменов и доменных
контроллеров.
7.2 Бюджеты пользователей
Человек, который принимает участие в работе домена, должен иметь бюджет пользователя (user
account) для входа в сеть и получения доступа к её ресурсам (файлам, каталогам, принтерам).
Администратор должен создать бюджет пользователя, указав пользовательское имя бюджета и
другие идентификационные данные пользователя и определив права пользователя в системе.
Идентификаторы включают информацию о пользователе, его членстве в группах, и информацию
политики безопасности. После того, как эта информация для вновь созданного бюджета
пользователя будет введена, сервер определяет для пользователя уникальный идентификатор
безопасности (Unique Security Identifier, SID). Каждый SID всегда является уникальным.
45
Когда пользователь регистрируется, сервер создаёт маркер безопасного доступа (security-access
token). Он включает SID пользователя, идентификаторы безопасности групп, к которым он
принадлежит, и другую информацию, в том числе имя пользователя и имена групп, к которым он
принадлежит.
7.3 Права пользователя
Права пользователя (User rights) – это правила, определяющие действия пользователя, которые он
может произвести. Если ПК не является контроллером домена, эти права относятся только к
локальному ПК. Если это – контроллер домена, то эти права распространяются на все
контроллеры в домене.
Права могут быть определены индивидуальному пользователю, но обычно (и более
эффективно) они определяются для групп. Заранее определенные (встроенные) группы уже
имеют набор пользовательских прав, определенный для них при установке системы.
Администраторы обычно предоставляют права пользователям путем занесения их имен в
список членов одной или нескольких заранее определенных групп. При необходимости
можно создать новую группу и наделить ее специфическими правами. Пользователи,
которые
добавлены
в
группу,
автоматически
получают пользовательские права,
определенные для этой группы. Существует набор прав пользователей, которые
администраторы сетей с повышенными требованиями к безопасности должны подвергать
аудиту. Такие виды доступа, как Log on Locally (Локальная регистрация в системе) и Shut
down the system (Останов системы) должны быть строго ограничены, а назначения этих
прав, сделанные по умолчанию, должны быть изменены.
Таблица 6.1. Пользовательские права, устанавливаемые по умолчанию,
которые могут быть изменены
Право пользователя
Группы, обладающие
этим правом по
умолчанию
Рекомендуемые
изменения
Локальная регистрация.
Поэволяет пользователю локально
зарегистрироваться на
компьютере с помощью
клавиатуры
Administrators, Backup
Лишить этого права
Operators, Everyone,
группы Everyone и
Guests, Power Users, Users Guests
Guests
Завершить работу системы.
(SeShutdownPrivilege) Поэволяет
пользователю завершить работу
операционной системы Windows
Administrators, Backup
Лишить этого права
Operators, Everyone,
группы Everyone и
Guests, Power Users, Users Guests
Права пользователя, приведенные в табл. 6.1, обычно не требуют переустановки значений,
заданных по умолчанию. Это касается даже систем с повышенными требованиями к безопасности.
Таблица 6.2. Пользовательские права, установленные по умолчанию
Право пользователя
Получать доступ к компьютеру
через сеть
Работать как часть
операционной системы
{SeTcbPrivilege)
Описание
Группы, получающие это
право при установке системы
Пользователь,
Administrators, Everyone,
обладающий этим правом, Power Users
может устанавливать с
данным компьютером
соединение
Позволяет процессу
работать
как защищенная часть ОС.
46
Право пользователя
Добавить рабочую станцию к
домену
(SeMachineAccountPrivilege)
Производить резервное
копирование файлов и
каталогов (SeBackupPrivilege)
Не подвергаться
промежуточным проверкам
(SeChangeNotifyPrivilege)
Изменять системное время
(SeSystemTimePrivilege)
Создавать файл pagefile.sys
Создавать маркер доступа
(SeCreateTokenPrivilege)
Создавать постоянные
раэделяемые объекты
(SeCreatePermanentPrivilege)
Отлаживать программы
(SeDebugPrivilege)
Остановить удаленнуюсистему
(SeRemoteShutdownPrivilege}
Генерировать отчеты по
аудиту (SeAuditPrivilege)
Повышать квоты
(SelncreaseQuotaPrivilege)
Повышать приоритет
(SelncreaseBasePriorityPrivilege)
Описание
Предоставляется
некоторым подсистемам
Не действует на
компьютере
с Windows NT
Пользователи, имеющие
это право, могут
выполнять резервное
копирование файлов
и каталогов. Это право
заменяет права на доступ
к файлам и каталогам
Позволяет пользователю
переходить в каталог и
получать доступ к файлам
и подкаталогам, даже если
он не имеет доступа к
родительскому каталогу
Дает пользователю
возможность
устанавливать системное
время компьютера
Не имеет никакого
влияния в текущих
версиях Windows
Право процесса
создавать маркеры
доступа. Это может
делать только LSA
Позволяет пользователю
создавать специальные по
стоянные обьекты,
такие как
\\Device, для внутреннего
использования Windows
Право пользователя
отлаживать различные
низкоуровневые обьекты
(например, нити).
Позволяет пользователю
производить
принудительный останов
удаленной системы
Право процесса
генерировать записи в
журнал аудита
Не работает в текущей
версии Windows
Позволяет пользователю
увеличить базовый
приоритет процесса
47
Группы, получающие это
право при установке системы
Administrators, Backup
Operators
Everyone
Administrators, Power Users
Administrators
Administrators
Administrators
Administrators, Power Users
Право пользователя
Загрузка и выгрузка драйверов
устройств
(SeLoadDriverPrivilege)
Фиксация страниц в памяти
(SeLockMemoryPrivilege)
Регистрация в системе под
видом пакетного задания (batch
file)
Регистрация в системе в
качестве сервиса
Локальная регистрация в
системе
Управление журналом аудита и
безопасности
(SeSecurityPrivilege)
Модификация параметров
аппаратной среды
(SeSystemEnvironmentPrivilege)
Описание
Позволяет пользователю
устанавливать и удалять
драйверы устройств
Позволяет пользователю
эафиксировать страницы
памяти таким образом,
чтобы они стали
неперемещаемыми и не
могли быть выгружены на
жесткий диск в файл
pagefile.sys
Не оказывает никакого
влияния в текущей
версии Windows
Позволяет процессу
эарегистрироваться в
качестве сервиса
Позволяет пользователю
зарегистрироваться в
системе с клавиатуры
локального компьютера
Позволяет пользователю
указать системе
безопасности, какие типы
доступа к ресурсам
(например, получение
доступа к файлам)
подлежат аудиту.
Кроме того, такой
пользователь имеет право
на просмотр и очистку
журнала безопасности
(security log). Однако,
наличие этого права не
дает пользователю
возможности
устанавливать системную
политику аудита с
использованием опции
Audit из меню Policy
утилиты User Manager.
Члены группы
Administrators всегда
могут просматривать и
очищать журнал системы
безопасности
Позволяет пользователю
модифицировать
системные переменные
окружения, хранящиеся в
памяти NVRAM для
систем, поддерживающих
48
Группы, получающие это
право при установке системы
Administrators
Administrators, Backup
Operators, Guests, Power
Users, Users
Administrators
Administrators
Право пользователя
Описание
этот тип конфигурации
Позволяет пользователю
производить
профилирование (замер
производительности)
одиночных процессов
Профилирование произПозволяет
водительности системы
пользователю
(SeSyslemProfilePrivilege)
производить
профилирование (замер
производительности)
всей системы
Замена маркера безопасного
Позволяет пользователю
доступа на уровне
Производить
процессов
модификацию
(SeAssignPrimaryTokenPriviiege) маркера безопасного
доступа
для процесса. Это право
предоставляет доступ к
системе безопасности и
поэтому используется
только системой
Восстановление файлов и
Позволяет пользователю
каталогов (SeRestorePrivilege)
восстанавливать файлы и
каталоги с помощью
резервных копий.
Это право обладает
приоритетом по
отношению к правам
доступа на файлы и
каталоги
Завершение работы системы
Позволяет пользователю
(SeShutDownPrivilege)
завершить работу системы
Присвоение прав владельца на
Позволяет пользователю
файлы и другие объекты
захватывать права
(SeTakeOwnershipPrivilege)
владельца на файлы,
каталоги, принтеры и
другие объекты системы.
Это право имеет
приоритет перед правами,
защищающими объекты
Профилирование одиночных
процессов
(SePrafSinglePrivilege)
Группы, получающие это
право при установке системы
Administrators, Power Users
Administrators
Administrators, Backup
Operators
Administrators, Backup
Operators, Power Users
Administrators
7.4 Формирование групп пользователей с одинаковыми
потребностями
Администраторы обычно группируют пользователей в соответствии с тем доступом в сеть,
который им необходим для работы. Например, большое количество бухгалтеров, работающих на
определенном уровне, нуждаются в доступе к одним и тем же серверам, каталогам и файлам.
Используя группы, администраторы могут одновременно назначать права доступа множеству
пользователей. Другие пользователи могут быть добавлены к существующим группам в любое
49
время, очень быстро получая права доступа, определенные для той группы, членом которой они
являются.
Существует два типа групп:
Глобальная группа
(global group)
состоит
из
различных
бюджетов
пользователей одного домена, группируемых под одним именем
Глобальная группа может содержать имена пользователей только одного домена, в
котором она создана. Слово «глобальная» говорит о
том, что группа может быть наделена правами доступа для использования ресурсов в
множестве глобальных доменов. Глобальная группа
может содержать только бюджеты пользователей (но не может содержать бюджеты
других групп). Глобальная группа не может быть
создана на компьютере, работающем под управлением Windows NT, или на
компьютере, выполняющем в домене роль сервера (member server).
Локальная группа (local group) может включать сгруппированные вместе под
одним именем пользовательские бюджеты и глобальные группы одного или
нескольких доменов. В локальные группы могут быть добавлены пользователи и
глобальные группы, принадлежащие к внешним доменам, если внешний домен является
доверяемым по отношению к локальному домену. Слово «локальная» означает, что
группе могут быть выделены права доступа на использование ресурсов, находящихся
только в одном локальном домене. Локальные группы могут содержать пользователей и
глобальные группы, но не могут содержать других локальных групп
При работе с группами рекомендуется использовать следующие правила:
Лучше назначать права доступа локальным группам и использовать
глобальные группы как метод включения пользователей в локальные
группы.
Глобальная группа - это лучший метод для одновременного включения множества
пользователей в другой домен. Необходимые права и доступ обеспечиваются локальной
группой, в которую добавляется глобальная группа
Глобальные группы могут быть добавлены к локальным группам того же домена
или доверяющего домена. Они также могут быть добавлены к компьютерам,
работающим под управлением Windows NT Server и расположенным в том же домене
или в доверяющем домене
Windows 200’X Server имеет встроенные локальные и глобальные пользовательские группы.
7.5 Субъекты и имперсонация
Одна из целей модели безопасности Windows состоит в том, чтобы обеспечить любой
программе, активизированной пользователем, такие права доступа к объектам, которые не
превышали бы прав, которые имеет сам пользователь. Это значит, что если пользователю
предоставлены права на чтение определенного файла, и он запускает программу, то эта программа
не сможет выполнять запись в этот файл, поскольку как и пользователь, будет иметь право только
на чтение.
Субъектом (subject) называется комбинация маркера доступа пользователя и программы, которая
работает от имени пользователя. Windows использует субъекты для слежения и управления
доступом программ, используемых пользователем. Когда программа или процесс запускается от
имени пользователя, то говорят, что эта программа работает в контексте безопасности данного
пользователя. Контекст безопасности (security context) контролирует тот доступ к объектам и
системным сервисам, который имеет данный субъект.
Модель клиент-сервер операционной системы Windows определяет два класса субъектов внутри
архитектуры безопасности:
50
Простой субъект (simple subject) — это процесс, который активизируется в
контексте безопасности пользователя при входе в сеть. Он не является защищенным
сервером, который может иметь других субъектов в качестве своих клиентов
Серверный субъект(server subject) является процессом, применяемым как
защищенный сервер (примером может служить подсистема Win32). Другие субъекты
являются клиентами защищенного сервера. В этой роли серверный субъект обычно
имеет контекст безопасности тек клиентов, от имени которых он работает
Когда субъект вызывает объектный сервис через защищенную подсистему, маркер
субъекта определяет, кто сделал вызов, и имеет ли сделавший вызов субъект достаточно прав,
чтобы его запрос был выполнен.
Windows позволяет одному процессу брать атрибуты безопасности другого процесса. Это делается
с помощью технологии, называемой имперсонациеи (impersonation). Например, серверный процесс
обычно действует от лица клиентского процесса, если для выполнения задачи требуется доступ к
объектам, к которым сам сервер доступа не имеет.
7.6 Информация по безопасности объектов (права доступа)
Вес именованные объекты Windows, а также некоторые объекты, не имеюшие имен, могут быть
защищены. Дескриптор безопасности (security descriptor) описывает атрибуты безопасности
объекта. Дескриптор безопасности для объекта включает в свой состав четыре части:
SID владельца, который определяет пользователя или группу, владеющую
объектом. Владелец объекта может изменять уровень доступа к объекту
Групповой SID, который используется только подсистемой POSIX и игнорируется
другими подсистемами Windows
Избирательный список контроля доступа (access control list, ACL),
идентифицирующий пользователей и группы, которым предоставлен или запретен
определенный вид доступа. ACL контролируется владельцем объекта
Системный ACL, контролирующий сообщения аудита, генерируемые системой.
Системный ACL контролируется администратором системы безопасности
7.6.1 Типы объектов
Права доступа к объектам, которые могут быть предоставлены или нет, зависят от типа
объектов. Например, для очереди заданий на принтер можно указать такие права доступа, как
Manage Documents (Управление документами) или Print (Печать), для каталога - Read (Чтение),
Write (Запись) и Execute (Запуск файлов на выполнение).
Права доступа к объекту также определяются тем, является ли объект контейнерным (container
object) или неконтейнерным (noiicontainer object). Контейнерный объект — это объект, который
имеет логические связи с другими объектами, неконтейнерный объект не имеет логических
связей с другими объектами. Например, каталог - это контейнерный объект, который логически
связан с объектами типа «файл» и другими каталогами. Файлы являются неконтейнерными
объектами. Эта разница между контейнерными и неконтейперными объектами очень важна,
потому что объекты, содержащиеся внутри контейнерных объектов, могут наследовать
определенные типы прав доступа от родительского контейнера.
Замечание
NTFS поддерживаег наследование ACL от объекта "каталог" объектом "файл", который создастся
внутри этого каталога.
7.6.2 Список контроля доступа и его элементы
Каждый ACL состоит из элементов списка контроля доступа (Access control entries, АСЕ),
которые определяют право доступа к объекту или разрешение на аудит объекта одному
51
пользователю или группе. Существует три типа АСЕ. Два из них предназначены для
избирательного контроля доступа (discretionary access control), а один — для определения
системной безопасности.
Элементами ACL, определяющими избирательный контроль доступа, являются AccessAllowed
(доступ разрешен) и AccessDenied (доступ запрещен). Они явным образом разрешают или
запрещают доступ к объекту для пользователя или группы пользователей. Первый встретившийся
АСЕ типа AccessDenied отклоняет доступ пользователя к ресурсу, и дальнейшей обработки АСЕ
не происходит.
Замечание
Существует очень важное отличие между ситуацией, когда в ACL нет ни одного элемента, то есть он
пуст, и ситуацией, когда существует объект, у которого вообще нет ACL. В случае, когда ACL пуст,
права доступа явным образом не указаны, и соответственно, доступ неявно запрещен. Для объекта,
который совсем не имеет ACL, не существуем зашиты, определенной для этого объекта, и, соответственно, любые пользователь и группа могут получить доступ к этому объекту.
Элементом списка ACL, определяющим системную безопасность, является элемент System Audit.
Он используется для ведения журнала событий, связанных с безопасностью (log of security events)
этого объекта и генерации сообщений аудита безопасности.
7.6.3 Маски доступа
Каждый элемент списка имеет маску доступа (access mask), которая определяет
всевозможные действия для объекта определенного типа. Маска доступа похожа на меню, из
которого осуществляется выбор типов прав доступа, которые нужно либо предоставить, либо нет.
Специфические типы (specific types) определяют вид доступа, который соответствует
объекту определенного типа. Для каждого типа объекта можно определить до 16 специфических
типов доступа. Совокупность специфических типов доступа для определенного типа объекта
называется специфической маской доступа. Специфические типы и специфическая маска доступа
определяются в момент определения типа объекта. Например, файлы Windows имеют следующие
специфические типы доступа:
Read Data
ReadEA
ReadAttribules
Write Data
WriteEA
WriteAttributes
AppendData Execute
Стандартные типы (standard types) относятся ко всем объектам и состоят из следующих
прав доступа:
SYNCHRONIZE. Используется для синхронизации доступа и для разрешения
процессу ожидать, когда объект перейдет в необходимое сигнальное состояние (signaled
state).
WRITE_OWNER. Используется для назначения с правом записи владельца.
WRITE_DAC. Используется для разрешения или запрещения доступа с правом
записи к избирательному ACL.
READ_CONTROL. Используется для разрешения или запрещения доступа с правом
чтения к дескриптору безопасности и владельцу.
DELETE. Используется для разрешения или запрещения доступа с правом удаления.
Общие или родовые типы (generic types) — это широкий набор типов доступа,
используемых при защите объекта. Точное применение этих типов устанавливается приложением,
определяющим объект. Например, для того, чтобы проигрывать и редактировать объект голосовой
аннотации (voice annotation), приложение, которое определяет объект, может указать специфические виды доступа, используя VOICE_PLAY и VOICE_EDIT. Кроме того, это приложение
может установить структуру соответствия общего и специфического типов доступа, в которой
GENERIC_EXECUTE соответствует VOICE_PLAY, a GENERIC_WR1TE соответствует
VOICE_EDIT.
52
Специфические стандартные типы детально отражаются в журнале безопасности. Общие
типы в журнале безопасности не появляются. Вместо этого туда записывается соответствующий
специфический или стандартный тип.
7.6.4 Наследование контроля доступа
Когда внутри контейнерного объекта создается новый объект, он по умолчанию наследует
защиту доступа от родительского объекта.
Изменение прав доступа на каталог действует на весь каталог и файлы, которые находятся в нем,
но не относится автоматически к существующим подкаталогам и их содержимому. Для того чтобы
права доступа действовали на подкаталоги, надо в диалоговом окне Directory Permissions установить флажки Replace Permissions On Existing Files и Replace Permissions On Subdirectories.
7.6.5 Проверка доступа
Когда пользователь пытается получить доступ к объекту, Windows сравнивает информацию
о безопасности в пользовательском маркере доступа с информацией безопасности, содержащейся
в дескрипторе безопасности объекта.
Для субъекта создается желаемая маска доступа (desired access mask), основанная на типе
доступа, который пытается получить пользователь. Эта маска доступа, обычно создаваемая
программой, которую активизировал пользователь, сравнивается с ACL объекта. (Все общие типы
доступа приводятся в соответствие со стандартными и специфическими типами доступа.) Каждый
элемент списка проверяется следующим образом:
Идентификатор безопасности в АСЕ сравнивается с набором идентификаторов
безопасности в маркере доступа пользователя. Если совпадение не найдено, то данный
АСЕ пропускается. Дальнейшая обработка основана на типе АСЕ. Элементы ACL типа
AccessDenied предшествуют в списке элементам ACL типа AcccssAl-lowed и,
следовательно, обрабатываются ранее.
Если доступ запрещен, система проверяет, содержит ли первоначальная желаемая
маска доступа только ReadControI и WRITE_DAC. Если
это так, система проверяет, является ли тот, кто сделал запрос, владельцем объекта. Если
это так, доступ разрешается.
Для АСЕ AccessDenied, действия в маске доступа АСЕ сравниваются с
действиями, описанными в желаемой маске доступа. Если какое-либо
право доступа найдено в обеих масках, то доступ запрещается. В противном случае
обработка продолжается проверкой следующего запрошенного АСЕ.
Для АСЕ AccessAllowed действия в маске доступа АСЕ сравниваются с
соответствующими действиями, описанными л желаемой маске доступа. Если все доступы
в желаемой маске доступа совпадают с АСЕ, то
дальнейшая обработка не требуется, и доступ предоставляется. В противном случае
обработка продолжается со следующего АСЕ.
Если для содержимого желаемой маски доступа не найдено полного
совпадения при том, что уже достигнут конец списка контроля доступа (ACL), доступ
неявно отклоняется.
7.7 События безопасности, подлежащие аудиту
Windows включает возможности аудита, которые можно использовать для сбора
информации о том, как используется система. Эти возможности позволяют следить за событиями,
имеющими отношение к безопасности системы, идентифицировать слабые места в системе
53
безопасности и определять местонахождение и масштабы любого повреждения. Уровень аудируемых событий может быть изменен для того, чтобы как можно лучше соответствовать
требованиям конкретной организации. Некоторые организации требуют небольшого количества
информации аудита, в то время как другие находят необходимым пожертвовать
производительностью и некоторой частью диска для сохранения детальной информации, которую
они могут использовать для анализа безопасности системы.
Замечание
Если вы активизируете аудит, помните, что каждая аудиторская проверка требует небольших
накладных расходов (overhead), что отражается на производительности системы.
Windows может следить за событиями, имеющими отношение как к самой операционной
системе, так и к индивидуальному приложению. Каждое приложение может определять свои
собственные аудируемые события. Определения этих событий добавляются в реестр при
установке приложения на компьютере с Windows.
Аудируемые события идентифицируются системой по имени исходного модуля (который
соответствует специфическому типу события в реестре) и идентификатору события.
С помощью утилиты Event Viewer события, занесенные в журнал безопасности, могут быть
отражены по категориям и по идентификатору события. В журнал безопасности могут быть
занесены следующие категории событий (категории, заключенные в скобки, можно найти в
диалоговом окне Audit Policy в User Manager);
Таблица 6.3. События безопасности, которые могут быть подвергнуты аудиту
Категория
Управление
бюджетами (User
and Group Man
agement)
Детальное
прослеживание
процессов (Process
Tracking)
Вход/Выход
(Logon/Logoff)
Доступ к обьекту
(File and Object
Access)
Изменение
политики (Security
Policy Change)
Использование
привилегий (Use of
User Rights)
Системное событие
(System)
Значение
Описывают изменения, происходящие в базе данных бюджетов
пользователей, например, создание пользователя или изменение
членства в группе. Потенциально может быть выполнен более
детальный аудит на уровне объектов
Предоставляют детальную информацию о таких событиях,
как активизация программы, дублирование дескрипторов,
непрямой доступ к объекту и так далее
Предоставляют информацию о единичной попытке входа в
сеть или выхода из сети, независимо от того, окончились
ли эти действия успешно или нет. В описание входа включается
информация о типе входа (т. е. интерактивный, сетевой или
сервисный)
Описывают успешный или неуспешный доступ к защищенным
объектам
Описывают изменения высокого уровня в базе данных политики
безопасности, такие как предоставление привилегий или
возможностей входа. Потенциально может быть выполнен более
детальный аудит на уровне объектов (См. предыдущую
категорию)
Описывают успешную или неудачную попытку использования
привилегий. В данную категорию включена информация о
предоставлении
специальных
привилегий.
Специальные
привилегии подвергаются аудиту только в момент их
предоставления. Во время использования аудит этих привилегий
не производится
Отражают всё, что происходит в системе и затрагивает ее
безопасность или записывается в журнал аудита
54
7.8 Подсчёт времени репликации
Управление сетевым трафиком с целью обеспечения приемлемого времени ответа является
важной задачей администрирования. Когда PDC подключён через WAN или модемную линию,
можно подсчитать уровень трафика и время, необходимое для репликации изменений в базе
данных каталога к и от PDC. Полученные данные позволяют организовать трафик так, чтобы
интересы площадки были учтены наилучшим образом.
Репликация (replication) - процесс копирования данных из хранилища или из файловой
системы на несколько компьютеров для синхронизации данных. Active Directory обеспечивает
репликацию с несколькими хозяевами между контроллерами домена в пределах данного домена.
Во всех контроллерах домена разрешено сохранение изменений в реплике каталога. Это позволяет
обновлять любые реплики в данном домене. Служба репликации автоматически копирует
изменения из данной реплики во все другие реплики.
Расчёт месячного времени репликации представлен в табл. 6.4
Таблица 6.4
Условия
Количество изменений
пароля за месяц
Факторы
Количество пользовательских бюджетов
№
A
B
Срок жизни паролей (в календарных днях)
B/30
Дополнительные
ежемесячные изменения
Ежемесячный объём
реплицируемых данных
Полное время
репликации ежемесячно
C
Количество изменений в пользовательских
бюджетах, A+C
Если это число неизвестно, используйте значение
5% от D
Количество новых пользовательских бюджетов
D
Количество изменений в группах *4
G
Количество изменений бюджетов компьютеров *5
H
D+E+F+G+H
I
Пропускная способность: скорость модемной
линии (байт в секунду), если скорость дана в
Килобайт/сек, умножьте значение на 1024,
например, 56 Килобайт/сек.= 57344 байт/сек
J1*8 (бит в байте)
J1
J2*60 (секунд в минуте)
J3
J3*60 (минут в часе)= общая пропускная
способность
J
О = полное время репликации (часов в месяц)
K
55
E
F
J2
7.9 Организация безопасности и уровень защиты C2
Уровни защиты распределяются от «А» до «D». Уровень А представляет наивысшую защиту.
Уровень C обычно применяется для программного обеспечения в бизнесе. Каждый уровень
подразделяется на несколько классов. Например, уровень C подразделяется на C1 и C2. С2
определяет более высокий уровень защиты.
Требования для ОС, которые претендуют на соответствие стандарту C2:
регламентированный доступ и его контроль
идентификация и аутентификация
аудит
повторное использование объектов
Для организации доступа и контроля ОС даёт администратору или пользователю возможность
определять, кто может иметь доступ к файлам, и какие операции с этими файлами могут быть
произведены. В Windows 200’X Server могут быть проконтролированы объекты и ресурсы, такие
как доступ к принтерам и разделяемым областям на сетевых серверах.
Идентификация и аутентификация производятся с помощью средств защищённой регистрации
в системе. Для начала работы с Windows 200’X Server все пользователи должны войти в систему.
При локальном входе в систему пользователи Windows 200X Server, чтобы убедиться, что в
системе не работают программы типа «троянский конь», должны сначала нажать комбинацию
клавиш <CTRL>+<ALT>+<DEL>. (Программа типа «троянский конь» может перехватить
пользовательскую информацию входа, обеспечивая себе таким образом сетевой доступ). Так как
каждый пользователь имеет уникальное пользовательское имя, доменное имя, а также пароль,
Windows 200’X Server может обеспечивать ему уникальную идентификацию.
Используя Windows 200’X Server, системный администратор может проводить аудит всех
событий, имеющих отношение к безопасности, а также всех пользовательских действий. Утилита
User Manager даёт возможность администраторам указать, какие события (например, вход в
систему или доступ к файлам) будут подвергаться мониторингу. Вся информация по аудиту
сохраняется в журнале событий, который может быть просмотрен с помощью приложения Event
Viewer.
Процесс оценки ПО очень сложен. Такого рода оценка базируется на наборе стандартов,
опубликованных в так называемой «Оранжевой книге» («Orange Book»). Все дополнительные
документы, которые описывают процесс оценок, носят название «Радужные серии» («Rainbow
Series»).
Модель безопасности разработана с учётом уровня безопасности C2 в соответствии с
определением, данным Департаментом обороны США.
Основные требования уровня безопасности C2:
Владелец ресурса (например, файла) должен иметь возможность контроля доступа к
этому ресурсу
ОС должна защищать объекты таким образом, чтобы исключить их случайное
использование другими процессами
Перед тем как пользователю будет предоставлен доступ в систему, он должен
идентифицировать себя путём ввода уникального имени и пароля. Система должна иметь
возможность использования этих уникальных идентификаторов для отслеживания
действий пользователей
Системный администратор должен иметь возможность аудита всех событий,
связанных с безопасностью. Доступ к этим данным должен представляться только
авторизованным администраторам.
Система должна защищать себя от внешнего воздействия. Такого как модификация
работающей подсистемы или системных файлов, сохранённых на диске
7.10 Соглашение об именах доменов
56
При планировании доменной структуры необходимо уделить большое внимание именам
доменов. Не рекомендуется менять уже разработанную систему имён. Изменение имени домена
требует переустановки каждого сервера, относящегося к этому домену. На практике используются
имена, отражающие основные целевые назначения доменов.
7.11 Соглашение об именах групп
Корпорация может создать глобальную группу для каждого ресурсного домена. Эта группа
может включать в свой состав всех, кто использует этот домен, как свою основную (primary) базу
ресурсов. Для всех подразделений или площадок могут быть созданы другие глобальные группы.
Работники каждого подразделения могут автоматически становиться членами этой группы. Имя
группы должно отражать домен и подразделение, к которым она относится, например: отдел
кадров может быть назван Dpt_Pers.Для работников отдела и категории работ может быть создана
группа, например, Dpt_Pers_Manager.
7.12 Соглашение об именах пользователей.
В идеале один пользовательский идентификатор и пароль должны предоставлять доступ ко
всем пользовательским ресурсам. Если пользовательский пароль нельзя передать другим
системам, то самое лучшее, что можно сделать – это создать последовательную и
непротиворечивую структуру имён пользователей в каждой организации, входящей в состав
компании. Желательно в имени пользователя в первых трёх символах указывать наименование
подразделения, в остальных в произвольной форме личное имя и личный номер пользователя.
Например, если условный номер подразделения в классификации компании 057 и необходимо
создать имя для пользователя с личным номером 5, то данное имя должно выглядеть следующим
образом: U057I005 для случая, если в подразделении работает не более 100 человек. Для
подразделения свыше 100 человек, данный номер будет выглядеть таким образом: U057I0005.
7.13 Матрица выбора домена
С точки зрения удобства администрирования предпочтительной моделью доменной
структуры является модель одиночного домена. Если модель одиночного домена не может быть
использована, то следует попытаться применить модель одиночного основного домена.
Для того, чтобы выбрать по характеристикам и положительным качествам модель,
наиболее подходящую для организации, очень полезно бывает сравнить характеристики доменных
моделей.
Таблица 6.5.Матрица выбора домена
Атрибут домена
Менее 40000
пользователей на
домен
Более 40000
пользователей на
домен
Централизованное
Одиночный
домен
Одиночный
основной
домен
Множество
основных
доменов
Х
Х
Х
X
X
X
57
Независимые
одиночные
домены с
доверительными
отношениями
Атрибут домена
Одиночный
домен
управление
бюджетами
Централизованное
управление
ресурсами
Децентрализованное
управление
бюджетами
Децентрализованное
управление
ресурсами
Одиночный
основной
домен
Множество
основных
доменов
Независимые
одиночные
домены с
доверительными
отношениями
X
X
X
X
X
X
X
7.14 Вопросы, помогающие выбрать схему расположения
Для выбора расположения сообществ пользователей, ответьте на следующие вопросы:
где пользователь будет входить в сеть?
Ему необходимо обеспечить доступ к аутентифицирующему резервному контроллеру домена
(BDC)
необходимо ли пользователю иметь возможность входить в сеть с нескольких рабочих
мест?
Если это так, бюджеты пользователей не могут быть связаны с одним местоположением. Следует
рассматривать использование модели одиночного основного домена или множества основных
доменов
доступ к каким ресурсам требуется?
Требуется ли пользователю вход в сеть, даже если линия связи с центальной площадкой не
работает?
Являются ли все данные централизованными таким образом, что никакая обработка не может
быть произведена локально, без линии WAN?
Насколько быстрыми являются линии WAN?
Скорость линии WAN, которая соединяет площадки, определяется исходя из использования
ресурсов с помощью этих линий и частоты изменений установок для пользователей или групп.
7.14.1
Требования к аппаратуре
Когда выбирается ПК в качестве главного (PDC) или резервного (BDC) контроллера домена,
используйте рекомендации по выбору аппаратуры из табл. 6.6.
Количество
бюджетов
пользователей
Менее 3000
До 7500
До 10000
До 15000
До 20000
До 30000
Размер
SAM
Размер
реестра
5
10
15
20
30
45
25
25
25
30
50
75
Страничный
пул
50
50
50
75
100
128
58
Мощность
CPU
Pagefile
RAM
РII/233
РII/233
РIII/450
РIII/450
РIV/1800
РIV/2400
64
128
192
256
512
1024
32
64
96
128
256
512
Количество
бюджетов
пользователей
До 40000
До 50000
7.14.2
Размер
SAM
Размер
реестра
60
75
102
102
Страничный
пул
128
128
Мощность
CPU
Pagefile
RAM
РIV/3000
РIV/3600
1024
2048
512
1024
Необходимое количество доменов
Количество пользователей в домене зависит от размера базы данных каталога. Таблица 6.7
определяет нужное количество доменов. Встроенные локальные группы для доменов включает
такие группы, как Administrator, Domain Admins, Users, Domain Users, Guests, Domain Guests…
Расчёт размера
данных SAM
Факторы
базы Кол-во пользователей, умноженное на 1 Кб
Кол-во ПК, умноженное на 0.5 Кб (необходимо
учесть рабочие станции, серверы, принтеры и т.д.)
Кол-во индивидуальных групп, умноженное на 4
Кб
Встроенные локальные группы
Общий размер базы данных SAM:
A+B+C+D =
Размер SAM необходимо преобразовать в Mb,
умножив E на .001024
MIN кол-во доменов = F/401 (округляется до
следующего целого)
7.14.3
A
B
C
D
E
F
Необходимое количество BDC
Соотношение между количеством рабочих станций и серверов в домене определяет время при
начальном входе в систему. Чем больше в домене резервных контроллеров (BDC), тем больше
пользователей могут войти в сеть одновременно. Один BDC может поддерживать до 2000
пользовательских бюджетов.
Табл. 6.8 Кол-во BDC на кол-во пользователей
Кол-во рабочих
станций
10
100
500
1000
2000
5000
Кол-во серверов,
выполняющих роль BDC
1
1
1
1
1
2
10000
5
20000
10
30000
15
59
Рекомендуется производить начальную установку всех BDC на локальной площадке, или с
помощью высокоскоростных линий, т.к. каждый новый BDC потребует полной синхронизации с
главным контроллером домена (PDC).
7.14.4
Устранение неисправностей
Категории типичных проблем:
Невозможность просмотра разделяемых ресурсов сервера
Проблема доступа к разделяемым ресурсам
Резервный
контроллер
домена
(BDC)
не
может
аутентифицировать
пользовательский пароль
Проблемы, вызванные наличием нескольких главных контроллеров (PDC) в домене
Проблемы, вызванные специальными символами в имени домена
7.15 Просмотр разделяемых ресурсов
Предположим, работник под именем Polsn входит в домен RCI с паролем SerNik и хочет
просмотреть разделяемые ресурсы на сервере, имя которого \\Products, но его пароль здесь Hooray.
Polsn увидит сообщение:
Error 5: Access has been denied.
(Ошибка 5 : Доступ запрещён)
Polsn просит администратора сервера \\Products изменить его пароль, но администратор оставляет
установленным флажок: Вы должны изменить пароль при следующем входе. Когда Polsn пытается
опять просмотреть разделяемые ресурсы сервера, он увидит сообщение:
Error 2242: The password of this user has expired.
(Ошибка 2242 : Срок действия пароля этого пользователя истёк)
Когда администратор сервера \\Products сбросит данный флажок, Polsn будет иметь возможность
видеть серверные разделяемые ресурсы.
7.16 Доступ к разделяемым ресурсам сервера
Два примера помогут объяснить некоторые вопросы доступа.
Предположим, работник Korsi хочет иметь доступ к разделяемому каталогу на
сервере, но не имеет бюджета пользователя в этом домене. Он может получить доступ к
этому ресурсу с помощью бюджета Guest на \\Products, получая ассоциированное с этим
бюджетом право доступа
Предположим Polsn вошёл в домен с паролем SerNik. Он хочет присоединиться к
разделяемому каталогу на \\Products, где его пароль Hooray. Так как для Polsn существует
бюджет пользователя, он не имеет возможности получить доступ, используя бюджет Guest.
Вместо этого ОС предложит Polsn ввести правильный пароль для регистрации на сервере
\\Products.
7.17 Не способность BDC аутентифицировать пользовательский
пароль
Пользователь пытается присоединиться к домену, где определён его бюджет, но резервный
контроллер (BDC) этого домена не может распознать пользовательский пароль. Эта ситуация
возникает, когда пароль изменился, но на момент входа данного пользователя в систему BDC ещё
не синхронизирован с PDC. В этом случае BDC передаёт запрос на вход к PDC в том же самом
домене.
60
Мера, которая может предотвратить подобную ситуацию, заключается в том, что пользователь
должен зарегистрироваться на всех ПК, к которым он имеет доступ, в течении 15 минут после
изменения пароля. При этом все кешированные входные параметры пользователя обновляются на
каждом ПК. Тогда пользователь будет иметь возможность входа в сеть, и при этом будет
использоваться кешированная информация входа, даже если PDC на момент регистрации
недоступен.
7.18 Предотвращение существования нескольких PDC в одном домене
Нельзя конфигурировать несколько главных контроллеров (PDC) в одном домене.
Предположим, администратор устанавливает ПК с Windows 200’x Server с именем ПК \\Main_unit.
При установке он сконфигурирован как PDC домена с именем MainDomain.
После этого администратор отключает \\Main_unit. Затем он устанавливает другой сервер,
называемый \\Second_unit, который тоже устанавливается как PDC для MainDomain. Так как
\\Main_unit на момент установки второго сервера не работает, первоначальный MainDomain
неизвестен, поэтому установки \\Second_unit и создание нового домена MainDomain происходит
без ошибки. Два домена с одинаковыми именами не идентичны – они имеют различные
идентификаторы безопасности.
Когда администратор включает \\Main_unit , сервис NetLogon обнаруживает в сети ещё
один PDC. При этом NetLogon перестаёт работать, и ПК \\Main_unit не может присоединится к
домену. Администратор имеет серьёзную проблему. Просто перекофигурировать \\Main_unit из
PDC в BDC и продолжить работу невозможно. Идентификатор безопасности (SID) для \\Main_unit
не будет распознан в текущем PDC, который имеет имя \\Second_unit. Таким образом, ПК
\\Main_unit не сможет присоединиться к домену MainDomain.
Эта ситуация происходит потому, что уникальный доменный SID создаётся каждый раз,
когда создаётся PDC. Все резервные контроллеры домена (BDC) и бюджеты пользователей внутри
домена распределяют этот доменный SID. Он является префиксом к их собственному SID.
Префикс SID \\Second_unit, установленного как PDC, отличается от префикса SID \\Main_unit, и
эти два ПК не могут одновременно участвовать в одном и том же домене.
Администратор не может изменить имя \\Main_unit и заставить его заново вступить в MainDomain,
потому что SID был зафиксирован, когда устанавливалась ОС. Если \\Main_unit должен быть PDC
домена MainDomain, администратор должен выключить оба сервера и запустить \\Main_unit, а
затем переустановить ОС ПК \\Second_unit и при этом сконфигурировать его как BDC.
Чтобы избежать этих проблем, сервер \\Second_unit должен быть установлен как резервный
контроллер домена в тот момент, когда включён \\Main_unit. Затем, если \\Main_unit выключается,
\\Second_unit может быть переконфигурирован в состояние BDC.
SID для \\Main_unit
воспринимается сервером \\Second_unit. Когда \\Main_unit включается, он опять становится PDC.
7.19 Специальные символы в имени домена
В именах доменов не допускается использование следующих спецсимволов:
* пробел “ \\ / [ ] : | < > + = ; , ?
Хотя некоторые спецсимволы, например, точка (.) являются допустимыми, лучше использовать в
именах доменов символы подчёркивания (_) или дефиса (-).
8
Лекция № 8. Сервис NetLogon. Журнал изменений. Частичная и полная
синхронизация. Аутентификация пользователя. Доверительные
отношения. Политика доменной безопасности. Вход в систему и процесс
аутентификации
61
8.1 Сервис NetLogon
Сервис NetLogon обеспечивает пользователей единой точкой входа в доменный PDC и все
BDC. Сервис Net Logon синхронизирует изменения в базе данных каталога, сохраненные на PDC и
всех доменных контроллерах. Размер базы данных каталога ограничен только допустимым
количеством записей в реестре и производительностью компьютера.
Сервис NetLogon системы Windows Server автоматически синхронизирует базу данных каталога. В
соответствии с установками в реестре PDC посылает периодические извещения, сигнализирующие
I3DC о том, что надо запросить у PDC изменения в базе данных. Извещения посылаются таким
образом, чтобы не все BDC запрашивали изменения одновременно. Когда BDC запрашивает
изменения, он информирует PDC о последнем изменении, которое было им получено. Таким
образом, PDC всегда «знает», какие BDC нуждаются в получении изменений. Если на определенном BDC база данных совпадает с актуальной, тогда сервис NetLogon на BDC не запрашивает
изменений.
8.2 Журнал изменений
Изменения в базе данных каталога включают ввод новых или измененных паролей, новых
или измененных бюджетов пользователей или групп, а также другой пользовательской или
групповой информации и любых изменений ассоциированного членства в группах и прав
пользователей.
Изменения в доменной базе данных каталога записываются в журнале изменений (change log).
Размер этого журнала определяется тем, как долго необходимо хранить изменения. По
умолчанию, сервис NetLogon обновляет журнал каждые 5 минут, и этот журнал содержит около
2000 изменений. Как только добавляется новое изменение, самое старое изменение удаляется.
Когда BDC запрашивает изменения, то ему передаются все изменения, которые произошли с
момента последней синхронизации.
Журнал изменений хранит только последние изменения. Если I3DC не производит периодических
запросов изменений, то вся доменная база данных каталога должна быть скопирована на этот
BDC. Например, если BDC отключен в течение некоторого времени, может оказаться, что за это
время произошло больше изменений, чем было сохранено в журнале.
8.3 Частичная и полная синхронизация
Частичная синхронизация (partial synchronisation) - это периодическая автоматическая
репликация изменений базы данных каталога, которые произошли с момента предыдущей
синхронизации, на все BDC.
Полная синхронизация (full synchronisation) - это копирование всей базы данных каталога на BDC.
Полная синхронизация производится автоматически, когда изменения были удалены из журнала
перед тем, как произошла репликация или когда к домену добавляется новый BDC. По
умолчанию, установки сервиса NetLogon предполагают периодические изменения (каждые 5
минут), и размер журнала изменений может содержать около 2000 записей. Такие установки
гарантируют, что при обычных условиях полная синхронизация не требуется.
Сервис NetLogon принимает запросы на вход от любого клиента и обеспечивает полную
информацию для аутентификации из базы данных каталога.
Сервис NetLogon работает на любом компьютере с Windows Server, который является членом
домена. Для работы NetLogon требуется сервис рабочей станции (Workstation). Он также требует
права Access This Computer Nот the Network, которое устанавливается утилитой User Manager на
компьютерах, работающих под управлением Windows Server, или User Manager for Domains — на
доменных контроллерах. Доменный контроллер также требует, чтобы был активизирован сервис
сервера (Server).
8.4 Аутентификация пользователя
62
На ПК, работающем под управлением Windows 200’X Server, по не являющемся
контроллером домена, сервис NetLogon обрабатываем запросы на вход для локального
компьютера и передает их контроллеру домена.
Ниже приведена последовательность этапов аутентификации запросов на вход в систему,
обрабатываемых сервисом NetLogon:
Определение (Discovery).
Установка защищенного канала.
Сквозная аутентификация (если необходимо).
8.5 Домены серверов Windows
Домен (domain) — это логическая группировка сетевых серверов и других компьютеров,
которые разделяют общую систему безопасности и информацию о бюджетах пользователей.
Внутри доменов администраторы создают один бюджет пользователя для каждого пользователя.
Зарегистрировавшись в домене, пользователи не должны регистрироваться на каждом из его
индивидуальных серверов.
фиксации пользователей, входящих в домены, доменный контроллер Windows использует
информацию, содержащуюся е базе данных каталога. Существуют два типа доменных
контроллеров:
Главный контроллер домена (Primary Domain Controller, PDC), который следит за
изменениями, производимыми над информацией о бюджетах домена, и сохраняет
информацию в базе данных каталога. Каждый домен имеет один PDC
Резервный контроллер домена (Backup Domain Controller, BDC), который хранит копию
базы данных каталога. Он периодически выполняет синхронизацию этой копии с базой
данных каталога, находящейся »а PDC. Домен может иметь множество BDC
8.5.1 Серверы-члены домена
Компьютеры, работающие под управлением операционной системы Windows Server, могут
быть сконфигурированы как серверы-члены домена. Такие серверы не сохраняют информацию
о базе данных каталога и поэтому не производят аутентификацию пользователей и не
принимают синхронизированных копий базы данных каталога. Эти серверы выполняют другие
функции, например, работают в качестве как принтерного или файлового сервера или сервера
приложений (если на сервере работает приложение, обрабатывающее большие объемы данных,
такие как базы данных).
8.5.2 Доверительные отношения
Сервис каталога Windows Server обеспечивает безопасность взаимодействия между множеством
доменов посредством доверительных отношений. Доверительные отношения - это связь,
соединяющая два домена в один административный блок, который может давать доступ к
ресурсам обоих доменов.
Существует два типа доверительных отношений:
Односторонние доверительные отношения (one-way trust relationship).
Эти отношения подразумевают, что один домен доверяет пользователям другого
домена использовать свои ресурсы. Более точно, один
домен доверяет контроллерам другого домена проверку бюджетов
пользователей на предмет возможности использования ими ресурсов
первого домена. Ресурсы, которые становятся доступными пользователям, находятся в
доверяющем домене (trusting domain), а имена
пользователей и пользовательская информация, которая проверяется
для доступа пользователей к этим ресурсам, находятся в доверяемом
63
домене (trusted domain). Если пользователь находится в доверяющем домене, и ему
необходимо использовать ресурсы, находящиеся в доверяемом домене, это требует
двусторонних доверительных отношений
Двусторонние доверительные отношения (two-way trust relationship) — это два
односторонних доверительных отношения. Каждый домен доверяет пользователям
другого домена. Пользователи могут входить в свой домен или в другой домен с
компьютеров, находящихся в любом домене. Каждый домен имеет свои собственные
бюджеты и ресурсы. Для определения прав доступа к ресурсам в каждом из двух доменов
могут быть использованы глобальные бюджеты пользователей и глобальные группы
любого из двух доменов
С помощью File Manager пользователям из доверяемого домена можно предоставить права
доступа к объектам в доверяющем домене, как будто они являются членами доверяющего
домена. Пользователи в доверяемом домене могут просматривать ресурсы в доверяющем домене
в соответствии со своими правами.
Например, предположим, что домен Samara доверяет домену Langepas в
корпоративной сети. Пользователь Э.П., который является членом домена
Langepas, хочет получить доступ к файлу Myfile.txt, который находится на
компьютере,
принадлежащем
домену
Samara.
Когда
Э.П.
пытается
зарегистрироваться в домене Samara, его пользовательская информация не
передается в базу данных бюджетов пользователей домена Samara. Поскольку
домен Samara доверяет домену Langepas, он имеет доступ к пользовательской
информации базы данных бюджетов пользователей в домене Langepas.
8.5.3 Политика доменной безопасности
Установка Windows Server может обеспечивать различные уровни безопасности для
действий пользователя в домене и на компьютере соответственно.
Можно определить четыре типа политики безопасности, которая применяется целиком к
домену:
Политика бюджетов (Account policy) контролирует, как пользователи используют пароли
Политика аудита (Audit policy) контролирует типы событий, записываемых в журнал
безопасности
Политика доверительных отношений (Trust relationship policy) контролирует, какой домен
является доверяемым, какой — доверяющим. Доверительные отношения требуют двух
или более доменов. Политика эта возможна также и при использовании модели
единичного домена (где существует только один домен), если только административным
компьютером в домене является контроллер домена
Политика прав пользователя (User Rights policy) контролирует права доступа,
назначенные групповым и пользовательским бюджетам. Права пользователей работают
на уровне домена и также влияют на общую безопасность домена.
8.6 Бюджеты компьютеров и защищенные каналы связи
Каждый компьютер, работающий под управлением Windows Server и входящий в домен,
имеет свой собственный бюджет в базе данных каталога, называемый компьютерным
бюджетом (computer account). Компьютерный бюджет создается, когда компьютер впервые
идентифицирован в домене (а не в рабочей группе) по время установки сети, или когда
администратор использует утилиту Server Manager для создания компьютерного бюджета.
Когда компьютер, работающий под управлением Windows Server, входит в сеть, сервис
NetLogon на клиентском компьютере создает защищенный канал связи (secure communication
64
channel) с сервисом NetLogon на сервере. Защищенный канал связи существует, когда компьютеры
на каждом конце соединения убеждены, что компьютер на другом конце правильно себя
идентифицировал. Компьютер идентифицирует себя, используя компьютерный бюджет. Когда
установлен защищенный канал связи, между двумя компьютерами может быть начат сеанс связи.
Для поддержки безопасности в течение сеанса связи между рабочей станцией и сервером,
между главным и резервным контроллерами домена и между обоими доменами в
доверительных отношениях образуются внутренние доверительные бюджеты.
Компьютерные бюджеты и защищенные каналы обеспечивают администраторам возможность
удаленного управления рабочими станциями и серверами. Кроме того, они влияют на
отношения между рабочими станциями и серверами домена, а также между основным и
резервными контроллерами домена.
Компьютерный бюджет является частью прямых односторонних доверительных отношений
между клиентским компьютером и контроллером его домена, рабочие станции запрашивают
аутентификацию входа пользователя в систему у доменного сервера тем же путем, каким
серверы доверяющего домена запрашивают проверку у сервера в доверяемом домене. Эти
доверительные отношения дают возможность администратору выбирать рабочую станцию или
сервер домена для администрирования так же, как они выбирают домен.
При создании компьютерного бюджета для рабочей станции или сервера к их локальной
группе Administrators автоматически присоединяется глобальная группа Domain Admins.
Администраторы доменов могут затем использовать утилиты Windows NT Server для
удаленного управления бюджетами компьютеров, пользователей или групп, включая
присоединение глобальных групп к компьютерным локальным группам. На самом компьютере
администраторы домена могут выполнять любые функции, которые позволены локальной
группе Administrators.
Для доменных контроллеров компьютерные бюджеты связывают BDC с PDC и объединяют
пары доверяющих и доверяемых доменов. Серверные доверительные бюджеты, которые
создаются при образовании защищенного канала связи, позволяют BDC копировать основную
базу с PDC. Междоменные бюджеты доверия позволяют доменным контроллерам в доверяемом
домене производить аутентификацию бюджетов пользователей для доверяющего домена.
8.7 Безопасность в смешанных операционных средах
Windows Server имеет открытую сетевую архитектуру, которая обеспечивает гибкость при
соединении с другими сетевыми продуктами. Клиентские компьютеры, на которых запущены
системы, отличные от Windows Server, могут взаимодействовать с компьютерами в домене
Windows Server. Однако они не имеют доменных компьютерных бюджетов и поэтому не имеют
системы безопасности, характерной для Windows Server. Пользователи других операционных
систем могут иметь пользовательские бюджеты, сохраненные в базе данных, но компьютер сам по
себе не имеет системы безопасности, которая ограничивает доступ к его собственным ресурсам.
Компьютеры, работающие под управлением Windows Server, могут взаимодействовать с
серверами и клиентами других операционных систем различные протоколы и другое программное
обеспечение, которое делает возможным подобное взаимодействие, включено в дистрибутив
Windows NT Server или может быть получено отдельно.
8.8 Клиенты рабочих групп
Рабочая группа (workgroup) — это совокупность компьютеров (не пользователей), которые
формируют административный блок и не принадлежат к I домену. 13 рабочей группе каждый
компьютер содержит собственную информацию по бюджетам пользователей и групп, и, в
отличие от доменных контроллеров, не разделяет эту информацию с другими компьютерами рабочей группы.
Члены рабочей группы регистрируются только на рабочей станции и могут по сети
просматривать каталоги других членов рабочей группы.
65
Компьютеры, работающие под управлением Windows NT Workstation, Windows Server, Windows
for Workgroups или Windows 95, могут принимать участие в домене или рабочей группе. Когда для
работы в сети устанавливается один из этих компьютеров, вы указываете имя компьютера и имя
рабочей группы. Если имя рабочей группы совпадает с именем домена, то имя компьютера
появляется в списке просмотра имен компьютеров для данного домена. Компьютер может
просматривать компьютеры, работающие под управлением Windows NT Server или Windows
NT Workstation, которые входят в домен или рабочую группу. При установке Windows NT вы
можете указывать, должен ли компьютер входить в домен Windows NT Server или в рабочую
группу.
8.9 Клиенты Windows
Доступ в сеть под управлением Windows NT Server встроен в Windows 95. Пользователи,
работающие под управлением Windows 95 и имеющие бюджет в домене, могут регистрироваться
на сервере или в домене таким же образом, как пользователи, работающие с Windows NT
Workstation. Пользователи Windows 95 при входе в сеть проверяются как доменными контроллерами Windows NT Server, так и доменными контроллерами LAN Manager 2.x.
8.9.1 Вход в систему и процесс аутентификации
Перед тем, как что-то сделать в системе Windows, пользователь должен войти в эту
систему, сообщив ей свое имя и пароль. Пользователь Windows использует имя для
идентификации и пароль для проверки. На различных уровнях ресурсы защищаются различными
процессами, но безопасность при входе защищает всю систему и весь доступ к домену или
компьютеру. Процесс входа в систему требует от пользователя его идентификации в домене или
компьютере. Имя и пароль, которые пользователь вводит в диалоговом окне Logon Information,
проверяются в каждой из компьютерных баз данных (если пользователь входит в
пользовательский бюджет, определенный на этом компьютере) или в доменной базе данных
каталога (если пользователь входит в доменный пользовательский бюджет).
После того как бюджет пользователя аутентифицирован. он может быть использован для работы
всеми сетевыми сервисами Windows Server и совместимыми серверными приложениями, такими
как набор серверных продуктов Microsoft BackOffice™. Через сервис каталогов аутентификация
даёт возможность пользователю, входящему в один домен Windows Server, использовать
другие приложения, такие как Microsoft SQL Server и Microsoft Exchange Server, и сетевые
сервисы, такие как Services for Macintosh.
Начальный процесс входа в Windows Server является интерактивным. Это значит, что
пользователь должен вводить информацию с клавиатуры в ответ на запросы диалогового окна,
которое появляется на экране. Система Windows предоставляет или запрещает доступ,
основываясь на информации, которую сообщает пользователь.
Интерактивный процесс входа в сеть и проверки пользователя состоит из следующих шагов:
Пользователь нажимает комбинацию клавиш <Ctrl>+<Ali>+<Del>.
Когда пользователь сообщает свое имя и пароль, процесс входа в систему вызывает LSA.
LSA запускает соответствующий пакет аутентификации.
Пакет аутентификации проверяет базу данных бюджетов пользователей с целью
установить, определен ли пользователь локально. Если это так, имя пользователя и его
пароль проверяются в соответствии с информацией, записанной в базе данных
пользовательских бюджетов. Если пользователь не определен в локальной базе данных,
то запрос на вход в сеть перенаправляется альтернативному пакету аутентификации.
Когда бюджет пользователя проверен, SAM (который владеет базой бюджетов
пользователей) возвращает идентификатор безопасности пользователя и идентификатор
безопасности любой глобальной группы, к которой принадлежит пользователь.
Пакет аутентификации создает сеанс входа (logon session) и передает этот сеанс и
пользовательский идентификатор безопасности в LSA.
66
Если вход в сеть отклонен, то сеанс регистрации уничтожается, и процессу возвращается
код ошибки. Если вход в систему не отклонен, то создается маркер доступа, содержащий
пользовательский идентификатор безопасности, а также идентификатор безопасности для
группы Everyone и других групп. Кроме того, маркер доступа содержит права пользователя
(описанные в следующем разделе), которые даны всем вышеперечисленным идентификаторам безопасности. Этот маркер доступа возвращается процессу вместе со статусом
Success (Успех).
Для создания процесса и присоединения к нему маркера доступа сеанс входа вызывает
подсистему Win32, создавая таким образом субъект для пользователя. (Субъект описан
ранее в этой главе в разделе, посвященном субъектам и имперсонации.)
Для интерактивного сеанса Windows подсистема Win32 активизирует пользовательский
desktop.
После завершения процесса проверки запускается процесс оболочки пользователя (то есть
процесс, активизирующий desktop пользователя), и ему передастся маркер доступа.
Информация в маркере доступа отражает все, что пользователь делает или любой процесс,
который он запускает.
Замечание
Windows имеет возможность поддерживать множество пакетов аутентификации, которые
реализованы в пиле модулей DLL. Эта гибкость позволяет разработчикам программного
обеспечения третьих фирм интегрировать с Windows пакеты аутентификации собственной
разработки. Например, если разработчика сетевого программного обеспечения не устраивает
стандартный пакет аутентификации Windows NT, он может добавить еще один пакет,
который позволит пользователям одновременно с входом в сеть Windows NT входит и в
его сеть.
8.9.2 Интерактивный и удаленный вход
Процесс аутентификации активизируется двумя процессами входа в систему:
Интерактивный вход (Interactive Logon)
Удаленный вход (Remote Logon)
Аутентификация при интерактивном входе
Интерактивный вход в систему имеет место, когда пользователь вводит информацию в
диалоговом окне Logon Information. В зависимости от того, где создан бюджет пользователя, в
поле Domain пользователь выбирает имя домена или имя компьютера, которое будет
использовано при входе. Если компьютер является членом рабочей группы, а не домена, то
диалоговое окно Logon Information не будет содержать поле ввода имени домена.
9
Лекция № 9 Оптимизация существующей сети. Рекомендации сетевым
инженерам. Аппаратные средства клиента и сервера сети
В настоящее время подключенный к сети компьютер все больше и больше необходим
каждому - от начальника и локального пользователя до настоящих маньяков Web. Естественно,
все забывают об администраторах сети, на плечи которых ложатся заботы по поддержанию
сети в работоспособном состоянии. Руководство почему-то ожидает значительного
повышения производительности после минимальных вложений и модернизацию сети. Нет
смысла постоянно придумывать способы повышения производительности работы сети и
пропускной способности, если удовлетворить постоянно растущие требования коллектива
пользователей практически невозможно.
67
В чем же тогда заключается работа сетевого инженера?
9.1 Исходные данные
В идеальном мире каждый сетевой инженер может с самого первого дня своей работы
начать отчитываться перед руководством о текущем состоянии сети или «с нуля» создать
сеть, разработанную специально для удовлетворения уникальных требований компании в
области обработки данных. В этом мире каждому сетевому инженеру предоставляется
достаточно средств для приобретения лучших аппаратных средств (рабочих станций,
серверов, концентраторов), программного обеспечения (сетевые и клиентские операционные
системы, приложения клиент/сервер) и других расходов (прокладки кабелей, подключения к
внешней сети и т. д.). Не нужно забывать и о достаточном количестве времени, выделяемом
для создания основной базы данных, прокладки кабеля, анализа, конфигурирования и
тестирования каждой части сети. Работа будет вестись до тех пор, пока не будет обеспечена
стопроцентная вероятность доставки пакетов данных. К сожалению, достичь этого
практически невозможно. Первые дни (а иногда и недели) работы нового сотрудника чаше
всего уходят на анализ текущей топологии сети, её служб и технологических ресурсов.
Одновременно он пытается приспособиться к принципам работы данного офиса, оценить
профессионализм сотрудников и, конечно же, произвести хорошее впечатление на
руководство. Данные, полученные в результате такого анализа, как правило, оказываются
весьма полезными при поиске способов оптимизации развернутой сети компании. Чаще
всего руководство поддерживает те проекты, которые выполняются за короткие промежутки
времени и воплощение в жизнь которых требует небольших затрат. Если такой проект будет
успению выполнен кем-нибудь из сотрудников компании, этот сотрудник сразу признается
специалистом экстракласса, который не только производит хорошее впечатление на
руководство, но и полностью соответствует своей должности.
Даже
если
группа
поддержки
работы
сети
является
сплоченной
и
высокопрофессиональной, существует угроза сбоя работы всей инфраструктуры из-за
нестандартных или некорректно функционирующих аппаратных или программных средств.
Такие сбои могут привести к непредвиденным затратам и оставляют минимум времени на
планирование предстоящих мероприятий модернизации. Поддержание нормальной работы
текущей системы компании является первоочередной задачей сетевого отдела, поскольку
любое изменение сетевой производительности будет сразу же замечено пользователями сети
и эта информация будет передана руководству. Как правило, такие сообщения просто
шокируют далеких от техники руководителей, которые знают об используемой технологии
настолько мало, насколько возможно, и, несмотря на это, обладают правом решающего
голоса при принятии решения.
Как правило, ничтожной части бюджета, выделяемой сетевым отделам, хватает
только на текущую небольшую модернизацию (расширение памяти, установку одного или
двух дополнительных процессоров и т.д.). Сетевые специалисты вынуждены любыми
способами поддерживать работоспособность сети до следующей такой модернизации.
Картина - весьма удручающая, особенно когда понимаешь, что очень редко встречаются
организации, готовые выложить тысячи или даже миллионы долларов для приобретения
последних разработок в области компьютерных средств телекоммуникаций, даже несмотря
на то, что сети большинства организаций морально устарели. Единственным выходом из
создавшейся ситуации для них является скорейшая кардинальная модернизация
существующих сетей. Можно предсказать, что для сетевых инженеров наступают весьма
интересные времена. Тем не менее, не стоит расстраиваться - в конце туннеля имеется
проблеск света.
68
9.2 Рекомендации сетевым инженерам
Даже если модернизация кажется невозможной, всегда существует множество
эффективных способов повышения общей производительности сети. Из-за неоднородности,
а также большого количества сетевых конфигураций и непостоянных требований
пользователей возможного решения (или их определенные комбинации) будут заметно
отличаться для каждой конкретной сети. Нет универсального способа решения проблем,
связанных с неправильной работой аппаратных и программных средств или их
неправильной конфигурацией. Поэтому перед выполнением каких-либо решительных
действий, приводящих к кардинальному изменению всей сетевой среды, рекомендуется все
тщательно проанализировать. Детальный анализ может показать, что планируемая
модернизация не так уж и необходима.
9.2.1 Шаг 1: Определение факторов, влияющих на работу системы
Определение факторов, влияющих на работу системы, всегда представляло собой весьма
непростую задачу. На первый взгляд, ее решение не составляет большого труда, однако не
стоит останавливаться сразу после определения одной или двух второстепенных
неисправностей, устранение которых вызывает лишь частичное восстановление системы.
Сеть и в прямом, и в переносном смысле создана из набора уровней, состоящих, в свою
очередь, из неоднородных комбинаций аппаратного и программного обеспечения. Практически
незаметные проблемы могут служить симптомами действительно серьезных недостатков,
заложенных глубоко внутри сети.
В некоторых случаях проблемы в работе сети довольно понятны и решаются относительно
несложно. Если, например, проблема сводится к отсутствию свободных портов для
подключения пользовательских компьютеров, а все остальные аспекты работы сети не
вызывают беспокойства, остается просто проложить дополнительные кабели и установить,
или модернизировать один или два концентратора. Большинство же неисправностей, к
сожалению, гораздо более сложны и перед проведением серьезных мероприятий необходимо
потратить немного времени на анализ ситуации.
9.2.2 Шаг 2: Определение идеальной "золотой" конфигурации
Следующий шаг "магической процедуры расширения" требует определения всех аспектов
идеальной сети, которая бы одновременно удовлетворила вас, пользователей и руководство.
Несмотря на то, что этот процесс анализа может достаточно потрепать нервы, ваши усилия
будут вознаграждены легкостью администрирования и удовлетворением требований всех
пользователей.
Стоит ли устанавливать новое (или дополнительное) кабельное оборудование для
увеличения пропускной способности сети или снижения времени задержек? Если
организация ставит перед собой глобальные задачи, ее сеть должна предоставлять доступ к
критически необходимым для работы ресурсам (лазерным принтерам, массивам RAID,
оптическим дисководам или службам новостей). В некоторых случаях программные средства
безопасности типа брандмауэров могут закрыть для пользователя доступ к определенным типам
данных, в частности, к ресурсам Internet, обеспечивающим передачу аудио- и
видеоинформации, интерактивной службе America Online или службам новостей UseNet.
Проблемы такого рода решаются с помощью прокси-сервера.
После определения необходимых служб и характеристик идеальной конфигурации сети
следует заручиться одобрением (и финансовой поддержкой) начальника, что поможет
воплотить все ваши фантазии (извините, я хотел сказать, «тщательно продуманные
решения») в жизнь.
69
9.2.3 Шаг 3: Определение стоимости модернизации
Любой специалист мечтает об установке самых последних разработок вроде серверов
Alpha, рабочих станций Sparc, волоконно-оптических технологий и т.п. В этом нет ничего
предосудительного, однако шансы того, что начальник профинансирует все эти дорогие
«игрушки» (особенно если эти продукты и услуги не являются предметами первой
необходимости), практически равны нулю.
Для оценки приблизительной суммы, необходимой для модернизации, составьте план,
отражающий требования (или пожелания) организации с точки зрения коллектива
пользователей, и добавьте к полученной сумме 10—15% на дополнительные расходы.
9.2.4 Шаг 4: Разработка плана мероприятий
На этой стадии работы придется потратить немало времени, усилий и энергии на
составление подходящего плана модернизации или расширения сети. Предполагается, что
вы уже успешно определили основные проблемы, описали «идеальную конфигурацию» сети,
получили молчаливое согласие и финансовую поддержку от босса. Самое время приступить к
модернизации, результаты которой должны удовлетворить все участвующие стороны.
Однако существует одна проблема: даже на время перехода на новые технологии или простой
модернизации сети каждому ее пользователю необходим доступ к ресурсам.
Еще одна головоломка, предстающая иногда перед сетевыми инженерами и системными
администраторами, заключается в том, что критичные для работы организации службы не
могут во время модернизации работать автономно. Это создает определенные трудности.
Для некоторых компаний данный фактор может оказаться более важным, чем для всех
остальных. Рассмотрим в качестве примера Web узел фирмы ABC, abc.com. Если какая-либо
часть внутренней сети будет отключена для установки нового аппаратного или программного
обеспечения, существуют все предпосылки для того, что большая часть критичных для
бизнеса ресурсов, например, издательские системы и базы данных фотоснимков, будет
недоступна, что приведет к остановке работы компании.
Чтобы избежать таких ситуаций, администраторы Internet должны убедиться в
максимальной прозрачности предполагаемой модернизации, выполняя се в точно
определенное время или на изолированных участках сети, которые наиболее легко могут
быть выведены из эксплуатации. Надежность работы сети в организациях, специфика
которых не требует выполнения максимальных объемов работы за минимальный
промежуток времени (например, в юридических фирмах, консультационных компаниях,
университетах и т.п.), хотя и не является критической, но тоже очень важна. Коммерческие
организации просто не захотят тратить массу денег на инсталляцию новых или
модернизацию уже развернутых сетей лишь для того, чтобы я конце-концов убедиться в
том, что разработанная сеть больше сбоит, чем используется.
В качестве примера такой неряшливости приведу случай из своего далекого прошлого.
Во времена расцвета газеты PolitfCsNow мне вместе с группой сотрудников изо дня в день
приходилось страдать от постоянных проблем в работе одной издательской системы,
которая сбоила множество раз в день, С этим приходилось мириться, поскольку она была
лучшей среди продуктов, обладающих необходимыми для работы функциональными
возможностями. После того как программисты компании-разработчика, расположенной в
Голландии, внесли некоторые изменения в серверные и клиентские версии своего
программного продукта, техническая группа этой же компании должна была установить
эти новшества в сети нашей организации. Проблема заключалась в том, что модернизация
определенных частей системы требовала отключения базы данных сервера и
издательской системы и приводила к необходимости выполнения бесконечного числа
повторных инсталляций и изменений конфигураций рабочих станций пользователей.
Особенности издательского бизнеса таковы, что даже секундное отключение всех
пользователей отрицательно влияет на работу организации и создает непреодолимые
трудности.
70
Администраторы сети (нравится это им или нет) должны учитывать при планировании
всех мероприятий интересы пользователей. Перерывы в работе всей сети или какой-либо ее
части должны быть расписаны заранее (и одобрены руководством, что тоже немаловажно).
Только в этом случае модернизация причинит пользователям минимум неудобств.
Второе, более рискованное решение заключается в остановке работы всей сети ночью,
когда она наименее используется. Хотя зачастую этот метод внесения крупномасштабных
изменений в сети оказывается оптимальным (поскольку времени для работы достаточно, а
необходимость срочного возврата системы в обычный режим функционирования
отсутствует), в некоторых случаях он может привести к еще более плачевным результатам.
Прекрасным примером такой стратегии являются проблемы интерактивной службы
America Online, хотя их описание в этой книге не стоит считать попыткой дискредитировать
эту организацию. Через некоторые интервалы времени специалисты America Online
осуществляют так называемый срыв (bounce) — полное отключение системы, выполняемое гдето около 4 часов утра по западному времени. Срыв отключает всех пользователей и
предоставляет сотрудникам AOL время для установки модемов, модернизации программного
обеспечения или любых других изменений, необходимых для поддержания эффективной
работы сети.
К сожалению, когда системы AOL отключаются, аналогичным образом поступает и
система, управляющая взаимодействием с ANS, компонентом America Online, отвечающим за
большинство соединений AOL. После завершения процесса модернизации оборудования и
перезапуска всех серверов в сети творится настоящий хаос, поскольку никто не может
получить доступ к службам из-за ошибок в соединениях AOL-ANS.
Чтобы вернуть систему в работоспособное состояние, техническому персоналу
необходимо приблизительно 19 часов — целая вечность. Не знаю, как обстоит дело в AOL, но
в других компаниях после таких форс-мажорных обстоятельств руководство уходит в
отставку.
Какой же урок можно извлечь из всего этого? Никогда ничего нельзя гарантировать!
Даже если вы досконально знаете свою сеть и се службы, все равно будьте бдительны,
поскольку лишняя самоуверенность может привести к небрежности в работе. Необходимо
быть готовым ко всему и не питать слишком больших амбиций в отношении модернизации.
Гораздо лучше разделить процесс полной модернизации на небольшие этапы, которые могут
быть выполнены в течение нескольких дней, чем инициировать процедуру, продолжающуюся
по 38 часов каждые выходные. Следует проанализировать влияние этих операций не только на
пользовательский коллектив, но и на сеть в целом и, что наиболее важно, определить
способы отказа от внесенных изменений на тот случай, если после перезагрузки
производительность системы снизится.
9.3 Аппаратные средства клиента и сервера сети
Еще одним аспектом, которому следует уделить внимание при модернизации
используемой сети, являются аппаратные средства клиента и сервера сети. Зачастую они
оказываются основными компонентами сети, определяющими производительность её
работы. Понятно, что приложения будут работать намного медленнее и менее эффективно на
непроизводительных платформах. То же можно сказать и о аппаратных средствах,
отвечающих за передачу данных по каналам сети. Несмотря на это, именно неправильно сконфигурированная работа клиентов и серверов сети может значительно снизить сетевую
производительность. Тем не менее, даже сверхбыстрые системы с высокоскоростными
сетевыми интерфейсами, использующими лучшие протоколы клиентского доступа, не
смогут значительно повысить производительность работы сети, если се другие части
обладают низкой скоростью передачи данных.
При оптимизации сетевых компьютерных систем следует уделять внимание очень
многим моментам. Большинство из того, что касалось ранее описанного выбора топологи,
71
может быть применено и для попыток улучшения аппаратных средств. Вопросы
повышения производительности сети связаны в основном с обновлением:
кабельного оборудования,
повторной сегментацией локальной сети и установкой более быстрых
концентраторов, маршрутизаторов и коммутаторов, т.е. для улучшения работы всей сети
необходимо улучшить работу ее отдельных компонентов.
Предмет обсуждения этого раздела не является исключением в этом отношении, Для
«ускорения» работы любого компьютера особое внимание следует уделить именно его
внутренним аппаратным средствам. Более быстрые процессоры, большие объемы памяти и.
конечно же, быстрые адаптеры локальных сетей, а также способ их взаимодействия и
конфигурация являются ключевыми компонентами при повышении производительности
сетевого оборудования.
Программное обеспечение, как обычно, играет второстепенную, хотя довольно важную
роль при повышении производительности сети. Не нужно подключать дополнительные
протоколы в сеть, которая и так полностью удовлетворяет требованиям пользователей. Кроме
того, стоит определить концепцию присвоения привилегий доступа к различным ресурсам и
возможность минимизации количества поддерживаемых протоколов и служб.
Наконец, еще одним важным моментом модернизации сети являются пользователи. В
очень многих локальных сетях не уделяется достаточно внимания способам взаимодействия
пользователей с сетью. Модернизация сети может значительно повлиять на возможности
пользователей подключаться к системе. Если в одно прекрасное утро персонал America
Online коренным образом изменит процедуру подключения к интерактивной службе,
возникнет шумный скандал.
9.4 Какое оборудование установлено в сети
Одной из первых задач при модернизации аппаратных средств является оценка уже
установленною оборудования. Оценивать его следует с точки зрения каждого устройства,
входящего в состав системы. Особое внимание нужно уделить всем внутренним
компонентам, таким как отдельные платы памяти, процессоры, дисководы, видеоадаптеры,
звуковые платы, сетевые адаптеры, средства резервирования, устройства ввода и мониторы.
Словом, всему.
Рассматривать систему нужно самым детальным образом, т.е. компьютер 486 DX4 100
МГц с объемом памяти 16 МБ должен рассматриваться как система в корпусе Tower с
процессором Intel 486 100 МГЦ и объемом памяти в 16 МБ, состоящей из 2 модулей по 4
МБ и 4 по 2 МБ. После этого составляется один список компьютеров, которые следует
собрать в соответствии с требованиям пользователей. (Эта процедура в дальнейшем будет
рассмотрена более подробно.) Постарайтесь распределить оборудование между
пользователями как можно равномернее (учитывая при этом их требования), обеспечив тем
самым стандартный уровень комплектации рабочих станций. Это позволит не выбрасывать
деньги на какое-нибудь специфическое оборудование, которое через шесть месяцев станет
бесполезным, поскольку начальник решится наконец-то вложить средства в приобретение
новых высокопроизводительных систем.
После этого можно подумать о будущих новшествах. Вероятно, нет смысла тратить
деньги, модернизируй систему Macintosh с процессором 6К030 до системы с 68040 —
целесообразнее приобрести PowerPC. Никто, наверное, не захочет заменять процессор 486
DX 33 Мгц на 486 DX4 100 МГц, если через шесть месяцев будет возможность установить в
систему Pentium 150 МГц. Практически невозможно предугадать, какие из аппаратных средств
упадут в цене через шесть месяцев или через год. Инвестиции в категорию кабельного
оборудования Ethernet будут бесполезными, если цены на волоконно-оптические кабели
опустятся до $O.02 за метр. Когда это произойдет? Кто знает?
72
9.5 Как достичь желаемых результатов
Планировать, планировать и еще раз планировать! Ах, да. И еще немного денег.
Планирование мероприятий очень важно как при модернизации сетевой инфраструктуры, так
и при модернизации аппаратных средств клиентов и серверов сети. Ключевыми моментами
являются тщательный анализ задач, решаемых для улучшения сетевой среды, и способность
подбирать аппаратные средства, программное обеспечение и службы в соответствии с
требованиями бизнеса.
Важно помнить, что план модернизации компьютерных систем должен быть связан с
планом модернизации всей сети. Немаловажную роль при составлении плана играют и сами
пользователи. Какая работа выполняется ими в сети? Какие у них требования? Какие службы
должны быть предоставлены? Кому из специалистов необходимы более производительные
машины? Если сеть развернута на АТС, то, вероятно, нет необходимости устанавливать в
системы операторов что-нибудь более быстрое, чем Pentium 100 МГц. Для запуска
приложений Delphi и Visual Basic потребуется значительная производительность, однако
использование с этой целью Pentium Pro 200 МГц может показаться смешным. Если в
организации имеются разработчики программного обеспечения, работающие на системах 486
DX2 80 МГц. или художники, использующие Power Macintosh 7100, то вполне логичным будет
желание пересадить их всех на рабочие станции с Pentium Pro. В случае, когда сервер 486 DX
66 МГц, работающий под управлением Linux, обслуживает доступ 25-50 пользователей к
службам Internet Mail, службам новостей, корпоративной сети или Web, установка
дополнительных дисков, памяти и более быстрых сетевых адаптеров для каждого сегмента
такой сети будет достаточно эффективным решением.
Модернизацию можно считать законченной лишь в том случае, когда ни одну часть
сети больше не надо модернизировать. Помощники директоров, менеджеры и вицепрезиденты могут пользоваться старыми, однако достаточными с точки зрения
производительности системами. Для работы директоров, финансовых аналитиков и
художников потребуются компьютеры с действительно большой мощностью, ведь именно эти
специалисты работают с наиболее громоздкими приложениями. Если финансовые
консультанты получают большие деньги, их начальник вряд ли захочет, чтобы половину
своего рабочего времени они просто сидели и ждали получения данных с сервера. Эти
специалисты должны работать, а не ждать, и S3000 инвестиций в новые аппаратные средства
могут в дальнейшем сэкономить S10000, особенно в том случае, если старые машины не
справлялись с расчетом даже простых электронных таблиц.
9.6 Серверы
С точки зрения клиента сети, сеть может быть полезна или бесполезна в зависимости от
предлагаемых услуг. Скорость же работы клиента определяется скоростью выполнения
операций различными службами. Именно поэтому роль серверов в достижении высокой
производительности работы сети чрезвычайно велика.
В зависимости or типа предоставляемых в сети служб может использоваться один или
несколько серверов. Некоторые из служб будут вообще неэффективными, если они
выполняются на одной машине. Например, если в качестве сетевой операционной системы
используется Windows NT, то нет смысла хранить совместно используемые файлы и базы
данных SQL на одной машине. Для работы таких служб необходимо очень специфическое и
тщательно настроенное оборудование. Требования к такому оборудованию зависят от объема
потоки информации, количества используемых данных и расстояний передачи. И большинства
случаев не следует жалеть средств на приобретение оборудования для серверов. Оно
значительно отличается от аппаратных средств клиентов, и, вероятно, никто не захочет
устанавливать правильную конфигурацию серверов с помощью метода проб и ошибок. Как
бы там ни было, лучше сразу проконсультироваться у разработчиков программного и
аппаратного обеспечения по поводу создания оптимально соответствующей требованиям
73
системы, определив для себя количество дисков, массивов RAID, объем памяти и
производительности процессоров. Это окажется намного безопасней и благоразумней,
особенно если в сети предоставляются описанные выше услуги.
С другой стороны, возможны случаи, когда нет возможности определить оптимальную
конфигурацию для сервера, работающего под управлением бесплатных операционных
систем. Такие бесплатные UNIX-подобные системы, как Linux, обеспечивают пользователей
основными принципами конфигурирования, с помощью которых можно определить
требования к службам и работе в сети. В различных системах эти принципы могут
значительно различаться. Так же, как и для клиентов UNIX, работающих на оборудовании
с Intel, для работы сервером UNIX требуется достаточно ''скромный" набор аппаратных
средств. Тем не менее, даже с ним обеспечивается работа тех же служб, что и у
операционных систем типа NetWare и Windows NT.
9.7 Аппаратные средства поддержки соединения
Каждый пользователь, устанавливающий соединение с локальной сетью, хочет, чтобы
независимо от используемой платформы, службы или протокола скорость соединения была
максимально возможной. Выше уже рассматривалось, каким образом с помощью простого
разделения сети на сегменты можно значительно повысим, производительность сети.
Повысить эффективность работы можно и путем обновления кабельного оборудования. С
целью более рационального использования инвестиций необходимо убедиться, что
интерфейсы между сетевым оборудованием и оборудованием конкретного компьютера
работают на максимально возможной скорости, а сделать это можно только с помощью
одного метода — метода проб и ошибок.
Такой исследовательский эксперимент достаточно прост, и для его выполнения
необходимо лишь аккуратно оценить свои аппаратные средства. Необходимо рассмотрев
тип используемой локальной сети, тип ее адаптера, подумать о модернизации
существующей инфраструктуры и сравнить все основные компоненты сети. Неоценимым
источником информации при подготовке к модернизации и перенастройке сети является
Web. Рассмотрите сетевые продукты от таких производителей, как 3Com, SMC. HewlettPackard, Digital Equipment Corporation и Novell, и проверьте их на соответствие своим
требованиям и возможностям. Рекомендуется выбирать те адаптеры, которые могут
обмениваться данными с шиной персонального компьютера на максимальной скорости,
которую она в состоянии поддерживать. Кроме того, производительность адаптеров должна
соответствовать аналогичным характеристикам серверов и кабеля. Важно проанализировать
информацию о поддержке таких устройств изготовителями. Насколько быстро тот или
иной разработчик выпустил драйвер для последних усовершенствований данной
операционной системы? Насколько быстро исправлены ошибки в последней версии
адаптера? Как долго эта компания занимается производством сетевого оборудования? Для
каких конкретных целей предназначена серия их продуктов?
9.8 Коммутаторы (Ethernet)
Коммутация Ethernet может стать одним из наиболее мощных и лучших с точки зрения
соотношения цена/эффективность решений, устраняющим такие проблемы сети, как разрыв
соединений, медленная передача данных или их искажение. Все это достигается за счет
эффективного управления потоком данных при передаче его через множество подсетей
общей сети.
Выбор технологии коммутации — достаточно надежное решение для устранения
многих неисправностей работы сети, с которыми сталкиваются сетевые инженеры при
попытке модернизации локальной сети. Эта сравнительно недорогая технология (хотя, надо
признать, осуществляют и очень производительные, но в то же время очень дорогие
74
модели коммутаторов) обладает большим количеством достоинств, к которым относятся
увеличение общей пропускной способности сети возможность работы в полнодуплекс ном
режиме (20 Мбит/с) и многое другое. Кроме того, коммутация быстрее, дешевле и проще
реализуется, чем полная модернизация сети с помощью FDDI, Fast Ethernet или других
высокоскоростных технологий. В се случае нет необходимости изменять большую часть
уже существующей сетевой инфраструктуры.
Увеличение производительности работы сети с коммутаторами базируется на принципе
их работы. Вся сеть разделяется на подсети (сегменты Ethernet), в которых соединения
устанавливаются только между небольшим количеством рабочих станций сети. За счет
разбиения всей сети на подсети и использования коммутаторов общая скорость передачи по
сети значительно повышается, поскольку теперь компьютеры, заключенные в конкретной
подсети, общаются только в своем сегменте. Если пакет данных предназначается для
компьютера другой подсети, коммутатор направляет его в нужный сегмент с минимальной
задержкой. Благодаря такому принципу организации коммутация является оптимальным
способом модернизации сети (учитывая еще и тот факт, что она обладает оптимальным
соотношением цена/качество).
9.9 Ценовая конкуренция и разумное приобретение
Приобретя некоторые системы, рекомендуется проверять их работу на некой модели
локальной сети, состоящей из подключенных клиенток и серверов. Установив новую
селевую шипу, необходимо проверить работу всей операционной системы и протоколов. На
основании этого тестирования можно принять решение о пригодности или непригодности
платы для использования в данных условиях. На такие проверки, как правило, уходит
достаточно много времени, а основное решение большей частью снизано с выбором легче
всего инсталлируемого и конфигурируемого адаптера главной вычислительной машины
сети. Дополнительными факторами, воздействующими на принятие решение, являются
основное назначение продуктов данного производителя, качество поддержки, время
исправления неисправностей и общий план модернизации. Все это в совокупности
приводит к принятию достаточно разумного решения о покупке того или иного продукта.
9.10 Протоколы
При выборе того или иного коммуникационного протокола следует руководствоваться
принципом "чем меньше, тем лучше". На многих ли современных компьютерах при
выполнении начальной загрузки для paботы Windows загружается стек TCP/IP?
Существуют ли ещё в сетях с такими компьютерами клиенты и серверы Macintosh, которые
пользуются протоколом AppleTalking? Если ответ на этот вопрос утвердительный, это очень
плохо, ведь в сети создайся дополнительный ненужный поток, который приходится
обрабатывать узлам сети. Зачем же использовать в сети и так много протоколов? Ответ,
как правило, один — незачем.
Процесс поиска общего протокола, который бы подходил для всех служб сети, может
занять много времени и привести сетевого инженера на грань нервного срыва. Эта игра всё
же стоит свеч, ведь с помощью оптимальной конфигурации можно достичь значительного
повышения скорости передачи данных. Исключение избыточности в сети приводит к
снижению вероятности возникновения конфликтов пакетов данных, а, следовательно, и к
уменьшению времени удовлетворения запросов пользователей и более быстрой передаче
информации. На вопрос относительно того, какой из протоколов наиболее широко
используется для работы самых различных служб, существует простой ответ: используемый в
Internet. Расширение популярности, функциональных возможностей и требовании к Internet
привело к появлению большого количества новых служб, для работы которых необходима
передача данных на большие расстояния и через самые различные аппаратные средства.
75
Именно благодаря этому расширению TCP/IP стал наиболее часто используемым самыми
различными службами и платформами протоколом в мире.
Так почему же не воспользоваться его преимуществами. Ведь именно уменьшение числа
используемых протоколов сети будет способствовать уменьшению сетевого трафика.
9.11 Поддержка клиентов сети
Не следует забывать о причинах установки сети. Именно обслуживание пользователей
сети является основной целью работы руководителя отдела информационных систем и
технологий, администратора сервера SQL, главною сетевого инженера или просто
сотрудника отдела поддержки, отвечающего на вопросы в службе поддержки. Они должны
обеспечить всех клиентов сети самыми дружественными и мощными продуктами, а не
предоставлять им возможность преодолевать трудности самостоятельно. Руководители не
должны настаивать на перемещении принтеров с принтерного сервера Novell на Windows NT,
если пользователям данного принтера достаточно для получения доступа к службам печати
загрузить поддержку IPX и войти в каталог NetWare. Это не только создает неудобства для
них, но и увеличит трафик локальной сети.
Отношения с пользователями сети должны быть прекрасными, особенно если
некоторые из них являются «всезнайками». Способность внимательно слушать может
принести свои плоды, поскольку некоторые «всезнайки» действительно могут помочь.
Девяносто процентов всех проблем с пользователями могут быть заблаговременно
предотвращены с помощью своевременного информирования, инструктажа, а также
создания письменных рекомендаций работы в сети и распространения их среди
пользователей. Не следует надеяться, что они сразу воспримут изменения в
функционировании сети, даже если эти изменения выглядят вполне понятными.
9.12 Резюме
Поскольку низкая производительность сети может значительно повлиять на настроение
пользователей, приводя их иногда даже и возбужденное состояние, модернизация и
оптимизация внутренних сетей организации становится чрезвычайно важной в последнее
время. К сожалению, для повышения работоспособности сети обычно требуются
значительные затраты времени, усилий и денежных средств, которые не всегда удается выбить
из руководства. Это означает, что сетевые инженеры и системные администраторы вынуждены достигать как можно большего результата с меньшими затратами, т.е. решать
наибольшее количество проблем самыми эффективными и дешевыми способами.
Модернизировать можно аппаратные и программные средства сервера, системы клиентов и все
другие элементы инфраструктуры. Во многих случаях небольшие, но довольно важные
изменения могут решить большинство наиболее важных проблем. Это предоставляет еще
больше время для рассмотрения тех вопросов, которые мешают сети получить статус
"идеальной".
Тем не менее, иногда все же случается чудо. Выделение значительных средств на
модернизацию сети означает, что можно начинать планировать и воплощать в жизнь
крупномасштабные улучшения инфраструктуры, которые не только решат текущие проблемы,
но одновременно и обеспечат повышение производительности и пропускной способности в
будущем.
В любом случае важно запомнить, что даже редкие устранения неисправностей могут
значительно уменьшить количество сетевых проблем. Проведя тщательный анализ и
выполнив планирование, можно определить, какие требования предъявляются к
оптимальной сети, и создав структуру, которая построена на аккуратно подобранных
программном, аппаратном обеспечении и кабельных системах. Каждый сотрудник
организации, от начальника до секретарши, работая в такой сети и пользуясь ее услугами,
будет чувствовать себя достаточно комфортно.
76
Ну что ж, давайте займемся делом!
10 Лекция № 10 Развёртывание новой сети. Состав группы разработки.
Определение коммерческих требований. Определение сетевой модели.
Принятие окончательных решений. Разработка стандартов. Разработка
мероприятий восстановления работоспособности. Система мониторинга
сети. Обучение пользователей
Для некоторых пользователей быстроразвивающиеся технологии сетевой обработки
компьютерных данных по-прежнему остаются чем-то совершенно модным и неизвестным.
Огромное количество компьютерных специалистов ежедневно привлекается руководством с
целью оценки, сравнения и выбора технологии для установления высокоскоростных соединений
между самыми разнородными группами пользователей и повышения производительности всего
трудового процесса. Для некоторых специалистов задача создания локальной или глобальной
сети кажется практически нереальной, многие считают себя недостаточно подготовленными
В этой лекции описано, как разбить сложный процесс создания сети на простейшие этапы,
выполнение которых пол силу даже среднему пользователю.
Для начала рассмотрим такое понятие, как «сетевая структура» (networking). Оно не
новое и не связано с какой-либо одной технологией. Независимо от того, рассматривается сеть
железных дорог или телефонная сеть, возникают ассоциации с каналами, по которым
осуществляется передача. Компьютерные сети являются электронным расширением данной
концепции. Они предназначены для установления соединений между двумя и более
клиентами с целью организации обмена информацией.
Существует основные правила, соблюдение которых позволит развернуть эффективно
работающую компьютерную сеть. Хотя они могут показаться тривиальными, их
игнорирование может принести к печальным результатам.
Итак, для организации компьютерной сети необходимо:
Располагать средствами для установления соединений между двумя или более
«клиентами»
Выбрать единый язык общения клиентов сети
Определить «этикет» диалога: Кто инициирует передачу данных по сети? Кто отвечает
на запрос?
Каким образом обрабатываются ошибки?
Большинство проблем современных сетей связано с «конструктивными» недостатками либо сеть некорректно спроектирована, либо ее структура не предусматривает дальнейшего
расширения. Этап проектирования является одним из важнейших в процессе создании
эффективно работающей сети. Независимо от того, какие требования предъявляются к сети и
какое количество сетей группа развернула в прошлом, создание новой сети - это своего рода
вызов. Спешка на этапе проектирования сети не только не сократит время реализации
проекта, но и добавит несколько недель на его переработку.
Документация является второстепенной, но тоже весьма важной частью процесса
разработки. Наличие документации не только подтвердит затраченные на работу усилия и
время, но и поможет протестировать сеть на наличие ошибок, которые, как правило,
появляются сразу же после начала работы. Правильно составленная документация может
сэкономить массу времени при поиске информации, необходимой для устранения
неисправности в работе сети или при внеплановой модернизации. Если дальнейшее расширение сети выходит за рамки финансовых возможностей отдела информационных систем, то
именно с помощью документации можно будет показать необходимость увеличения инвестиций в
сетевую инфраструктуру. Эти инвестиции позволят приобрести необходимые ресурсы и
нанять специалистов
77
В следующем разделе рассмотрены три показательных примера, благодаря которым
читатель сможет проверить свои способности в выборе подходящею решения (выбор худшего
решения, воплощение которого приведёт к большим дополнительным затратам, не будет стоить
вам ни цента). Это позволит в каждом случае принять свои решения и оценить их с различных
точек зрения. Следует заметить, что для компьютерных сетей не существует «правильных» или
«неправильных» решений. Существуют только «лучшие» и «более легкие» реализации проектов.
Каждый приведенный пример является лишь одним из возможных вариантов, и вам настоятельно
рекомендуется покритиковать его. Даже мысленная модернизация существующей сети является
хорошей практикой.
Изучение этой лекции должно придать уверенности в своих силах при принятии всякого
рода решений. Здесь описываются основные идеи и принципы, которыми следует
руководствоваться при выборе. Этой теме посвящено огромное количество книг и тысячи
страниц, и даже если данная лекция не предоставит вам ответы на все возможные вопросы,
время, потраченное на се изучение, будет весьма полезным.
10.1 Состав группы разработки
Члены группы разработки должны логически распределить обязанности и ответственность за
различные области проекта. Обратите внимание на слово «логически». В большинстве случаев
из-за относительной простоты разрабатываемого проекта или нехватки персонала в отделе
информационных систем один специалист может отвечать за несколько областей. Как бы там
ни было, уделять внимание следует всем областям, поскольку любая допущенная оплошность
может привести к появлению сбоев в работе всей сети.
При выполнении проекта обязанности распределяются следующим образом:
Руководитель проекта
Связывается с руководством организации для решения вопросов оплаты и отчетности
Ставит перед членами группы конкретные задачи и сроки их выполнения
Устанавливает стандарты для проекта
Решает спорные вопросы, которые могут препятствовать дальнейшей реализац ии
проекта
Проводит встречи специалистов проекта и обладает всей информацией по проекту
Коммерческий директор проекта
Поддерживает контакт с будущими пользователями сети
Доводит до сведения разработчиков пожелания пользователей
Знакомит разработчиков с историей и принципами организации работы компании
Проверяет эффективность работы сети перед ее предоставлением пользователям
Ответственный за работу сети
Координирую все действия, связанные с планированием сетевой инфраструктуры и
архитектуры
Убеждается в выполнении работы, проверяя соответствие сетевой топологии
предъявляемым требованиям
Связывается с производителями оборудования для получения необходимой информации
Устанавливает стандарты для будущего расширения сети
Ответственный за работу оборудования
Проводит настройку оборудования в соответствии с требованиями
Связывается с производителями оборудования для получения необходимой информации
Устанавливает стандарты для будущего расширения системы
Ответственный за работу приложений
Отвечает за выбор программного обеспечения пользователей
78
Проверяет соответствие уровня аппаратных средств задействованному программному
обеспечению
Оптимизирует сетевое оборудование для обработки трафика программного обеспечения
Ответственный за безопасность и надежность функционирования
Определяет необходимый уровень физической и сетевой зашиты информации компании
Присваивает пользователям различные привилегии доступа к ресурсам
Определяю уровень отказоустойчивости и резервирования в соответствии с требованиями
компании
Определяет стратегию доступа к новым или модифицированным ресурсам
Ответственный за обучение
Определяю уровни знаний пользователей
Разрабатывает способы повышения квалификации пользователей различных уровней
Рассматривает вопросы, препятствующие дальнейшему обучению пользователей
Отвечает за обучение пользователей и проверяет их знания в соответствии со специальной
программой обучения
В процессе развертывания сети иногда приходится выполнять операции, которые не
соответствуют ни одной из приведенных областей ответственности. Тем не менее в списке
приведены основные области ответственности и этою достаточно для осмысления всех факторов,
относящихся к процессу разработки проекта. Как уже указывалось выше, за несколько областей
может отвечать один специалист, а в случае нехватки денег, времени или персонала вся
ответственность ложится на одного или двух специалистов.
10.2 Определение коммерческих требований
Собрав группу разработки, необходимо побольше узнать о специфике работы организации, в
которой планируется развернуть сеть. Важно помнить, что представитель организации, который
описывает требования, скорее всего, очень плохо разбирается в технических тонкостях, поэтому
зачастую выступает лишь с коммерческими предложениями. Перед разговором с пользователями
будущей сети желательно составить список ключевых аспектов разработки. Как правило, такие
аспекты не оговариваются непосредственно и группа разработки должна уметь определить все
основные компоненты сети, которые позволят предоставить необходимые функциональные
возможности. Особое внимание следует обратить на:
1. Коммерческие цели
Чем занимается организация?
Для чего, по мнению руководящего персонала, будет использоваться данная сеть?
Какие подразделения/отделы особенно сильно затронет развертывание сети?
2. Будущий рост
Насколько быстро расширяется организация?
Планируется ли в ближайшее время создание новых подразделений или отделов''
Какой видит компанию через один тол или пять лет ее руководство?
3. Требования пользователей и групп
Как появление сети повлияет на производительность работы пользователей?
Смогут ли пользователи с помощью сети добиться повышения по службе?
Какой тип и объем ресурсов должен быть доступен для каждой конкретной группы?
4. Безопасность
Каковы уровни защиты данных в организации?
Следует ли устанавливать различные уровни защиты при работе с внешними
источниками информации?
Каков уровень физической защиты организации?
5. Отказоустойчивость
Значительно ли повлияет на работу организации сбой всей системы?
79
Каково максимальное время восстановления работоспособности сети в случае
отказа?
Насколько важны аспекты отказоустойчивости и резервирования?
6. Существующая сетевая архитектура
Развернута ли в данной организации сеть?
Возможна ли дальнейшая модернизация развернутой сети?
Каковы последствия модернизации сети?
7. Управление
Сколько времени и усилий необходимо для поддержания работоспособности сети?
Каким образом организация собирается управлять работой сети?
Прежде чем приступить к работе на одном из узлов сети компании, необходимо составить
схему взаимодействия её отделов на этом узле и в целом в сети. Это позволит провести
предварительное логическое разбиение, в котором каждый узел будет относиться к какому-нибудь
отделу. Такие взаимосвязи могут быть описаны руководящими сотрудниками среднего уровня,
которые, как правило, знакомы с требованиями и возможностями организации и в то же время
могут детально описать ежедневно выполняемые операции. Вопрос необходимо поставить таким
образом, чтобы в процессе обсуждения наиболее подробно вырисовывалась структура потоков
данных. Только полное понимание назначения этих потоков и функций раз личных отделов
позволит принять правильное решение относительно того или иною компонента и соот ветственно выбрать правильное оборудование.
Рекомендуется для каждого отдела назначить одного специалиста из группы разработки. Эти
сотрудники будут своего рода связующим звеном отдела компании с группой разработки.
10.3 Разбиение сети
Простое разбиение сетей (особенно сложных) на меньшие фрагменты позволяет уделить
больше внимания требованиям пользователей, а также значительно облегчить процесс
проектирования. Рекомендуется для каждого представительства организации создавать
отдельный узел сети. Все внешние соединения рассматриваются как соединения с глобальной
сетью, а внутренние соединения - с локальной. Из-за различий в скорости передачи данных и
технологиях локальных и глобальных сетей такой подход обычно оказывается оптимальным
методом устранения ошибок, допущенных на этапе проектировании.
10.4 Создание логической структуры
Собрав всю необходимую информацию о будущей сети, можно приступить к разработке
логической схемы сетевой среды. Она поможет найти потенциальные «узкие места», а также
определить приблизительный набор аппаратных средств, который будет в состоянии
обеспечить высокую производительность на всех участках сети.
Логическую схему необходимо сначала набросать в общем, а затем каждый ее узел опи сать
более детально.
Разрабатывая логическую схему сети, обычно делаются на прозрачных пленках три её копии. На
каждой пленке летально отображаются определенные типы трафика. Наложив пленки, можно
будет достаточно четко представить общую картину. Это позволяет индивидуально
проанализировать каждый уровень работы сети, оптимизировать его с точки зрения средств и
времени, а также рассмотреть различные альтернативные варианты разбиения.
10.5 Создание физической структуры
80
В отличие от логической структуры, связанной с трафиком данных, физическая структура
относится непосредственно к пользователям и ресурсам сети. Перечисленные вопросы являются
наиболее критичными при создании физической структуры:
Сколько пользователей подключено к каждому узлу? Каким образом?
Занимает ли каждый узел несколько этажей?
Где будет расположено центральное оборудование каждою сетевого узла?
Какие требования предъявляются к источникам питания каждого узла?
Нужно ли использовать бесперебойные источники питания и резервные генераторы?
Где будут расположены рабочие станции пользователей?
Какой вид доступа к внешним устройствам (принтерам, модемам, сканерам) необходим
пользователям?
Для каждого этажа здания организации желательно отыскать план-схему, которая поможет
не только при разработке физической структуры, но и при размещении оборудования и
определении рабочих мест пользователей. После решения всех спорных вопросов физической
структуры следует на плане этажа провести связывающие линии, соответствующие возможным
вариантам прокладки кабеля. Имейте ввиду, что способ прокладки кабеля может изменяться в
зависимости от модели сети, физической среды передачи и сложности аппаратуры. Сетевые и
системные специалисты обычно работают с схемой, описывающей реальные физические
устройства.
10.6 Определение сетевой модели
Под сетевой моделью подразумевается набор стандартов, реализованных в сети. Каждая сеть
построена на одной из таких моделей, определяющей способ хранения данных и расположение
линий связи, но которым эти данные передаются.
В настоящее время наиболее распространены четыре модели, предоставляющие пользователям
доступ к сетевым приложениям и данным:
Распределенная среда (среда "мэйнфрейма"). Эта модель была самой первой и остается
популярной по сей день. Все ресурсы сети такой модели располагаются на сервере, который
отвечает за управление и хранение всех данных компании. Каждый пользователь сети для
запуска процессов на сервере обращается к нему со своею видеотерминала или бездисковой
рабочей станции. Основные достоинства и недостатки данной среды:
Сервер является наиболее уязвимым компонентом к отказам сети
Отсутствие необходимости модернизации рабочих станций клиентов для поддержки новых
приложений
Снижение производительности сети при перегрузке сервера
Невозможность дальнейшей модернизации и расширения в случае неправильного выбора
сервера
Несложное управление вопросами безопасности физического доступа к серверу
Среда клиент/сервер
На современной стадии развития технологии совместного использования данных и ресурсов
модель клиент/сервер является наиболее популярной и может быть реализована в организациях
самого разного масштаба. На первый взгляд такая среда очень похожа на распределенную,
однако сервер используется только для предоставления доступа к приложениям и хранения
сгенерированных данных. Вся обработка данных выполняется на рабочей станции, что исключает
возможность снижения производительности работы сети при перегрузке сервера. Основные
достоинства и недостатки среды клиент/сервер:
Необходимость более тщательного по сравнению с другими моделями планирования
Возможность функционирования рабочих станций даже при отсутствии сервера
Необходимость в случае модернизации сети наращивания производительности не только
81
сервера, но и рабочей станции
Недостаточная безопасность данных, которые хранятся на рабочих станциях
Возможность расширения до уровня промышленной сети
Одноранговая среда
Эта модель разработана для небольших (до 15 рабочих станций) локальных сетей и чаше
всего разворачивается и малых офисах. Принцип ее работы построен на том, что каждая
рабочая станция функционирует в режиме сервера, предоставляя доступ к своим данным и
устройствам любой другой станции, обладающей для этого необходимыми полномочиями.
Достоинства и недостатки одноранговой модели:
Рабочим станциям предоставлен доступ ко всем ресурсам
Привлекательное отношение стоимость/эффективность, причиной чего является отсутствие
вы деленною сервера
Отсутствие централизованного управления и обеспечения безопасности
Невозможность преобразования в большую сеть
Возможность сбоя всей сети после выхода из строя отдельной рабочей станции
Среда, развернутая на базе World Wide Web
Эта относительно новая модель получила широкое распространение благодаря резкому
всплеску популярности Internet в последние пять лет. Ее структура напоминает среду
мэйнфрейма, в которой центральный сервер предоставляет пользователям свои "'страницы"
информации дли просмотра и взаимодействия с ними. Каждый пользователь такой сети может
использовать эти страницы либо на своей локальной машине, либо на сервере. Основные
достоинства и недостатки этой среды:
Заманчивое соотношение стоимость/эффективность и в случае использования с целью
объединении локальной и глобальной сети
Возможность инсталляции и обновления версий приложений без необходимости
непосредственного взаимодействия с рабочими станциями клиентов
Наиболее уязвимым к отказам звеном сети является Web-сервер
Необходимость поддержки нескольких платформ
Недостаточно надежное обеспечение безопасности из-за возможности внешнего доступа
к сети
Возможность развертывания в средах с низкой пропускной способностью или
большим трафиком
Возможность интеграции с Internet
10.7 Принятие окончательных решений
Добравшись до заключительного этапа процесса разработки, следует уделить особое внимание
рассмотрению следующих трех аспектов.
Во-первых, нужно выбрать сетевые приложения.
Во-вторых, необходимо принять решение относительно сетевой операционной системы.
В-третьих, определить требования программного обеспечения к аппаратному обеспечению.
Выбор типа приложений обычно полностью определяется сетевой моделью, хотя необходимо
учитывать также:
Стоимость и схему лицензирования
Простоту инсталляции и конфигурации
Простоту использования
Доступный уровень технической поддержки
Возможность взаимодействия данного сетевого приложения с другими приложениями
82
сети
Возможность работы данного
операционных систем
приложения
под
управлением
различных
сетевых
После выбора оптимальной сетевой модели и составления списков необходимых приложений
сетевыми специалистами и пользователями следует сравнить эти два набора данных. Такой
анализ позволит определить возможные сетевые операционные системы. Учитываемые при
принятии данного решения факторы очень похожи на рассмотренные выше:
Стоимость и схема лицензирования
Простота инсталляции и конфигурации
Простота использования
Минимум усилий для обслуживания
Доступный уровень технической поддержки
Поддержка аппаратных средств
Возможность последующей модернизации
Уровень поддержки независимых разработчиков
Возможности обучения системных администраторов
Не рекомендуется выбирать сетевую операционную систему, которая в состоянии работать с
оборудованием и программным обеспечением только одного производителя (компании Apple
и IBM, например, в начале своего развития практиковали разработку подобных программных
продуктов). Даже несмотря на то, что уровень взаимодействия между аппаратными средствами
и программным обеспечением был достаточно высоким, отсутствие какой-либо конкуренции
при выпуске таких продуктов не сделало их лучшими и своей области. Кроме того, если службы
поддержки данной компании окажутся не в состоянии корректно настроить сеть, обратиться за
помощью будет не к кому. В большинстве случаев выбирается либо сетевая операционная
система, уже установленная на различных узлах компании, либо система, которую группа
разработки посчитает наиболее подходящей.
Требования к аппаратным средствам сети можно условно разделить на три основных тина:
Требования к аппаратным средствам сервера
Требования к аппаратным средствам рабочей станции
Требования к периферийным устройствам (принтеры, модемы, сканеры и т . д . )
Выбор аппаратных средств сервера практически полностью определяется используемой
сетевой операционной системой. Рекомендуется устанавливать оборудование компании, которая
лидирует в данной области рынка и предлагает хорошую поддержку своих продуктов. Некоторые
сетевые администраторы стараются приобретать самое совершенное оборудование, обладающее
широким спектром функциональных возможностей. Необходимо в любом случае убедиться в том,
что компания-поставщик оборудования выпускает для выбранного вами сетевого оборудования
драйверы, а также в случае необходимости сможет решить проблемы несовместимости своих
аппаратных средств с аппаратными средствами других производителей.
Если аппаратные средства сервера зависят от выбранной сетевой ОС, оборудование рабочих
станций определяется приложениями, которые планируется на них запускать. Рекомендуется
при выборе оборудования рабочей станции основательно протестировать совместимость
различных ее компонентов и попытаться найти основные недостатки в работе данной
настольной системы. Если выбор сделан, рекомендуется сразу же связаться с производителями
аппаратных средств сервера для получения сведений о совместимости их оборудования с
различными компонентами сети. Обычно оборудование делится на три категории:
предназначенное для средних пользователей,
продвинутых пользователей,
разработчиков.
Если возможно, протестируйте каждый тип оборудования и попытайтесь заставить систему
«зависнуть». Для оценки правильности выбора аппаратных средств рабочих станций
постарайтесь ответить на следующие вопросы:
83
Будет ли в определенный момент времени системе не хватать локальных ресурсов
(например, оперативной или дисковой памяти)?
Какова относительная стоимость системы по сравнению с другими системами этого
уровня?
Насколько легко модернизировать или отремонтировать компоненты данной машины?
Последним пунктом рассмотрения являются периферийные устройства. Как правило, их
выбор определяется двумя основными факторами — коммерческими требованиями каждого
отдела и физической схемой узла. Примером первого может служить необходимость установки в
каком-либо отделе принтера. На основании этих коммерческих требований может быть
определено и соотношение относительная сложность/ стоимость. (Есть ли необходимость в
высококачественной печати графики? Требуется ли высокая скорость печати? Нужен ли для
работы цветной принтер?)
Принятие решения о выборе принтера, например, можно предоставить непосредственно тем
пользователям, которые будут ежедневно с ним работать. Используя физическую схему, можно
установить принтер в том месте, где он будет доступен максимальному количеству
пользователей.
Несмотря на некоторую неоднозначность при выборе, оценке и приобретении системных
аппаратных средств, не бойтесь брать на себя ответственность. Постарайтесь следовать
установленным стандартам и попросите каждого производителя оборудования описать
принципы работы своих продуктов. Необходимо лишь принять к сведению тот факт, что задача
консультантов фирмы-производителя сводится к продаже своих продуктов, поэтому все
сказанное ими следует тщательно проанализировать. Попытайтесь узнать еще чье-нибудь
мнение на этот счет.
10.8 Создание тестовой лаборатории
Эта часть создания повой сети обычно опускается по причине отсутствия бюджетных средств
или времени, необходимого на ее реализацию. В некоторых случаях, когда структура сети
достаточно проста или существует возможность вносить коррективы в процессе
развертывания сети, этот шаг вообще не нужен. Его рекомендуется использовать в качестве
вторичной проверки совместимости и производительности работы аппаратного и программного
обеспечения различных разработчиков или для предоставления пользователям возможности
оценить работу новых приложений. Многие компоненты программных и аппаратных средств
могут быть заменены в процессе тестирования, что позволяет подобрать оптимальную
конфигурацию сети. Если проверка осуществляется именно с этой целью, необходимо
предоставить пользователям возможность воочию увидеть и, если возможно, опробовать бетасистемы тестовой лаборатории. Важно, чтобы пользователи понимали, что скорости и
характеристики, полученные в лаборатории, будут немного отличаться от реальных скоростей и
характеристик сети, поскольку независимо от точности копирования сети тестовая лаборатория
никогда не сможет полностью отобразить все условия ее работы. Несмотря на это,
использование тестовой лаборатории позволяет убедиться, что все собранные воедино
компоненты сети взаимодействуют именно так, как предполагалось.
Еще одно достоинство тестовой лаборатории заключается в возможности применения ее при
обучении специалистов, знакомстве с особенностями поддержки сети и ее инсталляции. Хотя в
большинстве случаев для модернизации систем удаленного узла вполне достаточно
технической документации, гораздо больше-то эффекта можно достичь, пригласив специалиста
в лабораторию и предложив ему здесь провести «учебную» инсталляцию или модернизацию от
начала до конца. Такой подход позволит оперативно решать возникающие вопросы путем
детального рассмотрения специфики узла. Кроме всего прочего это позволяет больше внимания
уделить именно работе с оборудованием.
В качестве простейшей тестовой лаборатории можно использовать две небольшие подсети,
соединенные с помощью маршрутизатора. Для сравнения характеристик производительности
84
различных приложений следует в каждой подсети установить две рабочие станции, на одной из
которых инсталлировать стандартные клиентские приложения, а на второй - программы
отслеживания сетевых характеристик. Такой подход соответствует пассивному контролю,
который не влияет на трафик и позволяет определить истинное значение сетевой нагрузки.
Система
клиента
Подсеть
1
Система
клиент/сервер
Маршрутизатор
Подсеть
2
Система
контроля
Система
контроля
10.9 Оценка пропускной способности
После выбора окончательной конфигурации аппаратных средств сети необходимо (особенно в
больших сетях) оценить пропускную
способность.
Это позволит определить
масштабируемость сети и выяснить, в каких ее частях для равномерного распределения
нагрузки следует разместить сетевые устройства типа маршрутизаторов, мостов и шлюзов. Для
эффективною решения этой задачи подключите к тестовой лаборатории анализатор протокола
(protocol sniffer). Запуск на рабочих станциях различных сетевых приложений (сначала по
отдельности, а затем вместе) позволит определить предварительные требования к времени
передачи пакетов и пропускной способности. Анализируя результаты измерений, можно
получить ответы на следующие вопросы:
Каков размер пакетов данных?
Изменяется или остается постоянным трафик каждого из приложений?
Влияет ли работа одного приложения на эффективность другого?
Влияют ли какие-нибудь из операции одного приложения на производительность передачи
пакетов?
Сколько пользователей будет запускать данное приложение, и как их количество повлияет
на работу всей сети?
Как часто будет запускаться данное приложение (один раз в неделю, в день, в час)?
Получив ответы на перечисленные выше вопросы, можно определить способы снижения
влияния работы приложении на производительность сети. Если, например, интенсивно
передающее данные приложение ежедневно запускается в сети, целесообразно установить в
каждом сегменте сети дополнительные маршрутизаторы, что позволит пакетам данных быстрее
проходить к серверу.
10.10Выбор аппаратных средств установления соединений
Рассмотрим процесс выбора точек расположения сетевых устройств, исходя из особенностей
трафика. Для начала вернемся к инструкциям, описанным в разделе «Разбиение сети». Как
правило, сетевые устройства устанавливаются в местах подключения локальной сети к
глобальной. Это позволяет разделить весь трафик сети на трафик локальных сегментов и трафик,
предназначенный для передачи в глобальную сеть. Попытайтесь одновременно
85
проанализировать логическую схему сети и требования к производительности приложений и
ширине полосы пропускания. Дополнительное оборудование во всех сегментах локальной сети
следует устанавливать в соответствии с тремя логическими схемами. Если к передаче данных
предъявляются более высокие требования по скорости или для работы приложений необходима
высокая пропускная способность, то в этом сегменте для получении доступа от одной точки сети
к другой следует установить коммутатор или несколько маршрутизаторов. В конце концов,
основная цель установления соединения заключается именно в удовлетворении требова нии
пользователей к процедуре обмена информацией. Необходимо помнить, что увеличение
количества сетевых устройств приводит к повышению производительности, но в то же время и
к увеличению объемов работ по их установке и поддержке.
Приведенные ниже основные принципы помогут принять решение об установке в том или
ином месте сети маршрутизатора или моста. Следует заметить, что даже опытные сетевые
специалисты подчас спорят друг с другом о правильности того или иного выбора.
Мосты идеально подходят для небольших сетей, поддерживающих ограниченное
количество с глобальной сетью медленных соединений.
Мосты следует использовать в тех случаях, когда протоколы не поддерживают
инкапсуляцию или туннелирование кадров.
Мосты обладают лучшими соотношениями цена/эффективность и цена/скорость.
Для установки маршрутизаторов необходима помощь специалиста, в то время как
мосты являются самонастраивающимися устройствами.
Маршрутизаторы эффективнее осуществляют широковещательную передачу данных.
Маршрутизаторы являются более ''интеллектуальными'" и в состоянии самостоятельно
изменять размеры пакетов данных.
10.11Документация
Вы наверняка заметили, что на протяжении всей главы делался значительный акцент на
необходимости создания документации и зарисовки схем сетевых структур. Только после
выполнения всех описанных выше действий процесс разработки сети можно считать полностью
законченным. Конечная цель такой разработки заключается как в удовлетворении требований
пользователей, так и в принятии соответствующих решений относительно поддержки,
производительности и надежности работы сети. Теперь самое время собрать нее
экспериментальные данные и документацию и создать коммерческое предложение, с помощью
которого руководители проекта смогут отчитаться перед директорами компании об
удовлетворении требований и достижении ожидаемых результатов. Просмотрите еще раз все
страницы документации. Есть ли желание после всего изученного что-нибудь изменить в
структуре сети? Существуют ли какие-нибудь альтернативные решения, позволяющие
удовлетворить вес предъявляемые требования и получить при этом лучшее соотношение
цена/эффективность? Перед составлением окончательного варианта документации следует еще
раз вернуться назад и проверить правильность выбора компонентов и структуры сети. Лучше
сейчас потратить некоторое время на пересмотр проекта, чем уже после начала работ понять, что
устраняются далеко не все проблемы пользователей. Создавая документацию, необходимо по
каждому пункту давать краткие объяснения о том, какие альтернативы существовали и почему
было выбрано то или иное решение. В большинстве организаций, прежде чем выделить средства
на реализацию того или иного проекта, руководство компании подробно расспрашивает
руководителя проекта о том, как было принято оптимальное решение. Убедитесь в том, что
ответственный менеджер проекта располагает всей информацией, которая позволит ему отстоять
точку зрения команды разработчиков.
В документацию должны входить следующие сведения:
Детальное описание требований пользователей
Логическая схема
86
Физическая схема
Технические требовании к выбранным приложениям (связаны с требованиями
пользователей)
Технические требования к выбранной сетевой операционной системе
Технические требования к аппаратным средствам (делятся на требовании к серверу,
требования к трем типам рабочих станций и периферийным устройствам)
Технические требования к протоколам и физической среде передачи
Данные о тестировании приложений и их характеристиках
Логическая схема с линиями сетевых соединений
10.12Определение стоимости и времени реализации проекта
Собрав все данные, можно провести общее собрание разработчиков проекта. Основные
вопросы стоимости, эффективности и методов реализации должны быть детально рассмотрены
всеми разработчиками, что позволит точно оцепить объем необходимого финансирования. В
приведенном ниже списке перечислены типичные недостатки проекта, которым по той или
иной причине не уделяется должное внимание, поэтому перед представлением
заключительного отчета руководству их следует тщательно рассмотреть.
Может ли персонал, обслуживающий удаленный узел, самостоятельно инсталлировать
приложения?
Могут ли различные компоненты сети быть модернизированы без повторной
инсталляции, которая требует кратковременного отключения пользователей от сети?
Насколько автоматизирован процесс инсталляции?
Могут ли поставщики оборудования обеспечить совместимость своих продуктов с
продуктами других разработчиков?
Какое количество второстепенных инсталляций в день могут выполнить
администраторы сети?
В каких отделах инсталляция должна быть выполнена в первую очередь?
К кому пользователи сети могут обращаться с возникающими вопросами?
Какие дополнительные сотрудники должны быть привлечены для выполнения
инсталляции в определенный период времени?
Лишь после того, как руководитель проекта детально изучит все стадии разработки и сможет
правильно ответить на возможные вопросы, он выступает с докладом перед директорами
компании. Конечная цель этого выступления — получение достаточных средств для закупки
оборудования и найма дополнительных специалистов. Доклад руководителя проекта должен
излагаться максимально доступным языком, поскольку директора компаний не всегда обладают
достаточным уровнем технических знаний. В процессе выступления необходимо сделать акцент
на ожидаемом повышении продуктивности работы за счет автоматизации процессом, а также
указать на высокую безопасность и надежность рабочей сети.
Необходимо указывать, что на каждом уровне разработки принималось оптимальное решение,
утвержденное всеми членами группы. Если денежных средств на проект выделяется не так
мною, как хотелось бы, рекомендуется познакомить руководство компании со всеми
альтернативами и рассмотреть потенциальные убытки от принятия неправильного решения.
Нужно обязательно заставить директоров подписать проект, возложив, таким образом,
ответственность за его выполнение на их плечи.
10.13Организация узла эксплуатационных испытаний
Сразу же после принятия руководством коммерческого предложения, группа разработки
должна приступить к подготовке и осуществлению плана развертывания сети. Первым пунктом
87
в этом плане должен стоять выбор узла эксплуатационных испытаний, на котором будет
проверена работа всех систем, созданных в тестовой лаборатории. Рекомендуется установить
первый узел недалеко or лаборатории, чтобы можно было определить несовместимость между
узлами. Настроив испытательный узел, объясните будущим пользователям сети принципы
функционирования систем и попросите их периодически высказывать свое мнение относительно
всех аспектов работы сети. Пользователи не только предоставят разработчикам неоценимые
сведения о соответствии развернутого участка сети специфике работы организации, но и
смогут убедить свое руководство в необходимости расширения финансирования. К ключевым
вопросам, которые могут рассматриваться пользователями во время испытательного периода,
относится:
Позволяет ли выбранная структура сети циркулировать данным в пределах одного
отдела?
Адекватно ли предложенные приложения заменят использовавшиеся ранее способы
обработки данных?
Какой уровень безопасности должен быть обеспечен для данных?
Какие дополнительные преимущества, не учтенные на этапе разработки, были
обнаружены в процессе испытаний?
Насколько важны обрабатываемые данные?
Каким образом повлияет на работу компании случайное уничтожение данных?
Сколько времени необходимо на восстановление уничтоженных данных?
Необходимо дать пользователям немного времени для адаптации к новой системе, а самим в
это время можно заняться анализом ответов на приведенные выше вопросы. Обнаруженные
глобальные проблемы следует попытаться решить, а затем соответствующим образом обновить
системы в испытательном узле. Имейте в виду, что независимо от эффективности работы
системы, пользователи все равно будут требовать все большего и большего количества
функциональных возможностей, поэтому для успешного завершения проекта необходимо
определить критическую точку, в которой наблюдается минимальное соотношение
стоимость/эффективность. Определив оптимальную конфигурацию платформ, следует еще раз
окончательно оценить систему перед переходом к следующему этапу развертывания сети. Оценка
эта заключается в получении ответов на следующие вопросы:
Отвечает ли созданная система всем требованиям и ожиданиям?
Какой уровень знаний необходим для работы в сети?
Позволяет ли сеть эффективнее выполнять трудоемкие процессы, предоставляя таким
образом больше времени на решение организационных вопросов?
Существуют ли дополнительные рекомендации относительно работы в сети?
Ответ на первый вопрос будет касаться технических аспектов работы в сети и позволит
настроить се оптимальным образом и расширить спектр функциональных возможностей. Второй
вопрос поможет определить необходимый уровень знаний пользователей и усовершенствования,
которые появятся в следующих выпусках сетевых продуктов. Время, необходимое для
выполнения самых сложных задач вручную, при работе в автоматизированной системе
уменьшается на несколько порядков. Освободившееся время может быть направлено
непосредственно на повышение продуктивности работы каждого отдела.
10.14Разработка стандартов
Если на узле эксплуатационных испытаний была успешно проведена инсталляция всех
необходимых продуктов, а группа разработки и пользователи почувствовали, что намеченные
88
результаты достигнуты, теперь все усилия следует направить на составление списка стандартов
для инсталляции и поддержки новой сети. Именно с их помощью специалисты, которые не
входили в состав группы разработки, смогут научиться инсталлировать и поддерживать новую
сеть, а также решать возникающие в ней проблемы. Честно говоря, существуют различные
мнения относительно необходимости включения этого этапа в процесс разработки, поскольку
он не оказывает непосредственного влияния на завершение проекта. Описание стандартов
наиболее полотно при подключении к внешней сети или в случае модернизации внутренней.
Если, например, в организации нет отдела информационных систем, a на поддержку работы
определенных участков сети отвечают сетевые администраторы, то с помощью стандартов эти
специалисты могут эффективно взаимодействовать. Стандарты, выбор которых зависит от
мнений пользователей относительно работы сети, являются точкой отсчета для пересмотра
характеристик сети. Это означает, что следующая модернизация может быть проведена уже на
некоторой базе стандартов.
В приведенном ниже списке перечислены некоторые основные спецификации, входящие и
стандарты. В зависимости от уровня безопасности, количества рабочих станций, а также набора
задействованных на каждом узле технологий перечисленные спецификации помогут выбрать
поставщика, назначить администраторов и составить план предстоящих мероприятий по
модернизации сети.
Аппаратные средства настольных систем:
Производитель и модель системы (указать отдельно для рабочих станций обычных,
продвинутых пользователей и разработчиков)
Процессор
Память
Жесткие диски
Монитор
Сетевые адаптеры
Аппаратные средства сервера
Производитель и модель системы
Процессор
Память
Жесткие диски (указать все способы резервирования: зеркальное отображение,
дублирование, использование массивов RAID)
Сетевые адаптеры
Дополнительные периферийные устройства
Изготовитель и модель периферийных систем
Специфические настройки узла
Используемые интерфейсы (последовательный, параллельный или другой)
Программное обеспечение
Поддерживаемая операционная система
Требования к объему оперативной памяти
Необходимое дисковое пространство на рабочей станции
Необходимое дисковое пространство на сервере
Специфические параметры настройки узла
Работа с пользователями
Соглашения о присвоении пользовательских имен
Правила регистрации и удаления пользователей
Управление информацией
Оглашения о присвоении имен томов
89
Структура каталогов (приложения, каталоги пользователей, каталоги отделов)
Ограничения на размер каталогов (необязательно)
Управление сетью
Соглашения о присвоении имен серверов
Сведения о маршрутизаторах и шлюзах
Безопасность
Ограничение доступа с помощью паролей
Определение часов доступа
Сценарии входа в сеть/привилегии различных отделов
Учет (файлов, катало го и, пользователей)
Отслеживание/Разрешение проблем
Соглашения о присвоении стандартных названий проблемам и способам их
решении
Следует собрать все сведения и упорядочить их по типу телефонной книги. Такая
организация поможет не только при отыскании или решении сложных проблем, но и при замене
старого и приобретении нового оборудования. Вес записи следует хранить в тех местах, где
установлено оборудование серверов. Для решения возникших проблем можно использовать
следующие сведения:
Контактная информация поставщика оборудования
Условия контракта о поддержке (полезны при получении помощи от поставщика по
телефону)
Дополнительные сведения о конфигурации системы (номера запросов на прерывание и
каналов прямого доступа к памяти, диапазоны адресов виола/вывода)
Контактная информация сотрудников, отвечающих за поддержку оборудования (номера
телефонов или пейджеров)
Средства восстановления (загрузочные диски, редакторы поврежденных секторов,
определенные конфигурационные файлы сервера и т.п.).
10.15Администрирование
Понятие «сетевое администрирование» описывает все аспекты установки и поддержки
пользователей/групп или файлов/каталогов. Хотя значение этого термина одинаково для всех
сетевых сред, работа сетевых администраторов на различных узлах существенно отличается.
Уровень технических знаний и навыков работы администраторов также значительно
отличается. Каких-то результатов в области управления сетью можно достичь только путем
постоянной практики. В предыдущем разделе рассматривались возникающие вопросы и
стандарты работы сети. Работа сетевых администраторов заключается в реализации всех этих
стандартов на практике. В приведенном ниже списке перечислены вопросы, на которые сетевой
администратор должен знать ответы:
Как зарегистрировать новых пользователей?
Как удалить уже зарегистрированных пользователей?
Какова структура томов на сервере?
Какие каталоги расположены в отдельных томах?
Как спланированы мероприятия резервирования?
Существуют ли какие-либо особые требования к конфигурации узла?
Каков уровень безопасности каждого каталога отдела или пользователя?
Необходимо ли копировать данные на центральный сервер с целью резервирования их
на случай сбоя в работе локального оборудования?
Каким образом настраивается сервер?
С чем связаны возможные сбои в работе сервера?
90
Хотя в этом списке перечислены не все операции, он описывает все основные обязанности
пользователей и сетевых администраторов по поддержке нормальной работы сервера.
10.16 Разработка мероприятий восстановления работоспособности
и поддержки сети
Сеть является практически бесполезной, если она не выполняет возложенных на нее задач.
Если компания тратит деньги на разработку, развертывание сети и приветствует се
использование, а сеть не работает или постоянно выходит из строя, средства были вложены
напрасно. Для предотвращения подобной ситуации необходимо разработать план
восстановления работоспособности системы после аварийной ситуации и план поддержки
работы сети. Типичный план восстановления работоспособности сети включает следующие
моменты:
Определение уровней важности всех приложений и систем (необходимый, жизненно
важный, критически важный)
Составление описаний систем среды (электрическая, нагревание/охлаждение)
Определение групп, ответственных за устранение сбоев, и ситуаций, в которых к этим
группам следует обращаться
Определение видов поддержки, предоставляемой группами
Определение характеристик аппаратных средств (эта информация берется из
документации)
Оценка и составление плана действий на непредвиденные ситуации (простой, замена,
функционирование в автономном режиме)
Выбор руководителя, которого в первую очередь следует извещать о сбое в работе сети
Определение действий в нестандартных ситуациях (пожар, угроза взрыва бомбы, стихийное
действие)
Составление расписания отключений и тестирования критически важных систем
Несмотря на кажущуюся тривиальность и странность этих пунктов, они являются
основными ключевыми моментами не только корректного функционирования сети, но и
успешной карьеры сетевого администратора.
В правильно разработанных и настроенных сетях при появлении неисправности
выполняются следующие действия:
Специалист, нашедший неисправность, аккуратно записывает, что произошло на самом деле.
При этом укачивается, насколько серьезна данная неисправность и является ли сбой программным
или аппаратным. Сотрудники группы поддержки оставляют свои обычные рабочие места и
пытаются принести систему в нормальное состояние, причем если проблема не может быть
решена немедленно, то группа поддержки обращается к плану восстановления работоспособности
для определения последующих действий. В отчете руководству определяется степень влияния
неисправности на работу сети. Руководство, в свою очередь, на основе этих данных определяет
фронт работ группы поддержки и время, необходимое на восстановление. В случае серьезной
неисправности компании придется вложить дополнительные средства в приобретение
оборудования для замены критически важных компонентов. Если при поставке оборудования
был заключен договор о поддержке и гарантии, то отчет перед руководством является просто
жизненно необходимым. Сеть в этом случае будет полностью восстановлена путем замены
неисправных компонентов, а директора с удовольствием почувствуют, что их постоянно
информируют о состоянии сети. Проблема будет решена намного эффективней, без всяких
усилий и простоев в работе.
Особенно болезненным может оказаться отказ оборудования, используемого в
производственной сфере. Для возникновения таких неисправностей могут понадобиться годы,
однако вероятность их появления все же есть. Постарайтесь предугадать такую ситуацию и
заранее разработать комплекс мероприятий по восстановлению нормального функционирования.
Если группа разработки решила, что для сокращения времени восстановления необходимо
91
приобретение дополнительного оборудования, это решение следует представить на
рассмотрение руководства. При возникновении отказа принятие того или иного решения будет
определяться уровнем предоставляемой поддержки. Как бы там ни было, чем лучше работает отдел
информационных систем, тем лучше функционирует вся сеть в целом.
10.17Система мониторинга сети
С помощью плана восстановления работоспособности системы могут быть решены далеко не
все проблемы сети. Если, например, принтер пользователей зажевал бумагу или пользователи не
могут подключиться к сети, то это повлияет только на производительность их работы, а не на
всю сеть в целом. Тем не менее, если такая проблема все же появилась и не решается
достаточно быстро, отношение пользователей к сети, и, в частности, к отделу информационных
систем может значительно ухудшиться. Даже если какому-либо сотруднику просто необходимо
решить простой вопрос относительно работы в сети, специалисты сетевого отдела должны дать
на него понятный ответ. Именно для этих целей рекомендуется создать систему мониторинга и
обеспечить поддержкой пользователей, которым необходима помощь. Такая поддержка может
быть организована в виде центральной базы данных, к которой с вопросами обращаются
пользователи. Секретарь вводит вопрос в базу данных или просто записывает на бумаге суть
проблемы и отсылает это сообщение в группу поддержки. Специалистам не составит особого
труда создать систему мониторинга сразу же после развертывания сети. В руководстве по
использованию сети должны находиться сведения о том, что делать в случае возникновения той
или иной проблемы. Это позволит пользователям чувствовать себя комфортней при работе с
сетью.
Ниже приведен перечень полей, которые должна содержать форма запроса к базе данных.
Каждая сетевая среда являйся уникальной. По этой причине максимально подробное описание
проблемы сэкономит сотрудникам отдела информационных систем массу времени и нервов.
Итак, в форме должно быть указано:
Имя пользователя
Расположение пользователя
Отдел пользователя
Телефонный номер или другая контактная информация, по которой можно связаться с
пользователем
Категория проблемы (неисправность, вопрос, запрос)
Тип сбоя (программный или аппаратный)
Какие программные продукты связаны с возникшей проблемой
В чем заключается неисправность оборудования или проблема в работе приложения (не
всегда определяется с первого взгляда)
Существовала ли эта проблема ранее
Может ли пользователь продолжать свою работу
Влияет ли данная проблема на работу других пользователей (возможность сбоя сетевого
приложения)
Предлагаемый способ решения проблемы (заполняется при возвращении формы).
Сколько времени займет решение проблемы
Отслеживать все эти данные очень важно. Особенно полезно использовать базы данных,
поскольку если запросы заполнены в соответствии с соглашениями присвоения стандартных
имен, это позволит подсчитать количество отказов определенною типа и провести анализ.
(Постоянно ли с сбоит какой-то вид оборудования? Существуют ли какие-нибудь факторы,
влияющие на стабильность работы приложений и проигнорированные во время
тестирования?) Тщательный анализ всех проблем позволит принять верное решение о
необходимости проведения модернизации или замены какого-либо компонента секвой среды.
92
Существует еще одна выгода or использования системы мониторинга. Если в течение года
группа поддержки пыталась решить те или иные проблемы сети и не смогла эффективно
снизить частоту их появления, то, по всей видимости, необходимо увеличить количество
специалистов в этой группе. Проанализировав информацию базы данных и определив отношение
специалист/(среднее количество часов, потраченных на решение какой-либо проблемы),
руководство может принять решение о необходимости увеличения персонала отдела
информационных систем. Специалистов этого отдела обычно хорошо видно, но практически
не слышно, поэтому какой-нибудь руководитель всегда пытается определить необходимость
каждою из высокооплачиваемых работников для полдержания стабильности работы системы.
По этой причине создание системы мониторинга может рассматриваться системными
администраторами в качестве дополнительного шанса сохранить свое рабочее место.
10.18Реализация
Этот раздел связан с общением намного больше, чем все остальные. Можно провести
аналогию между реализацией проекта и битвой. Цель битвы заключается в расположении
сотрудников и оборудования в ключевых позициях, что позволит создать "линию поддержки
информации". В качестве противоборствующей стороны выступает коллектив пользователей,
чье недоверчивое отношение к новой технологии и тяготение к устаревшим системам
значительно усложняет процесс завоевания. Перед развертыванием войск и ресурсов
необходимо тщательно продумать «план битвы», включающий следующие аспекты:
Определение плана атаки (реализация проекта выполняется сразу же или разбивается на
этапы).
Засылка разведчиков (лучший способ развернуть новую технологию на узле прислушаться к советам пользователей, которые проверили работу системы в тестовой
лаборатории).
Связь с основным лагерем для вызова подкрепления (необходимо поставить в известность
руководство и, если возникнет необходимость, попросить нанять дополнительных
специалистов).
Согласованное движение армии (оплошность на любом этапе реализации может
привести к краху всего проекта).
Поддержка контакта с дивизиями (периодическая проверка функционирования отделов и
узлов сети).
Введение дополнительных резервов в области сопротивления (в случае возникновения
проблемы следует быть готовым приобрести дополнительные ресурсы для ее решения).
Закрепление успеха (координация работы всех узлов после завершения реализации
проекта и обеспечение возможности решения всех возникающих в процессе
использования проблем).
Организация (следует убедиться, что для всех узлов составлена документация и что
обслуживающий персонал готов в случае необходимости прийти на помощь
пользователям).
Отчет (следует доложить начальству о завершении проекта и любых проблемах, которые
могут проявить себя в будущем).
Благодаря такой схеме, выполнение любого проекта будет проведено без больших
трудностей, а все потенциальные проблемы будут решаться до того, как они приведут к
полному сбою в работе.
10.19Обучение пользователей
Хотя в большинство организаций для знакомства пользователей с новыми работающими
сетями и приложениями принято привлекать сетевых специалистов, это не всегда необходимо.
93
Проанализировав мнения пользователей, работавших на узле эксплуатационных испытаний,
группа разработки должна определить, с какими основными проблемами сталкивается
средний пользователь. После этого следует разработать методику обучения на новом
оборудовании, а также подготовиться отвечать на возникающие вопросы. Рекомендуется сразу
же после инсталляции новой системы обеспечить всех пользователей небольшими
руководствами, детально описывающими новые компьютеры и затрагивающие следующие вопросы:
Описание и структура сети
Описание трех типов рабочих станций клиентов (предназначенных для обычных
пользователей, продвинутых пользователей и разработчиков)
Ответы на наиболее часто задаваемые вопросы
Список специалистов отдела поддержки
Описание способа решения проблем или вопросов с помощью системы мониторинга
Резюме по каждому используемому приложению с краткой таблицей, позволяющей
пользователю немедленно начать работу с приложением
Очень важно при обучении не перегрузить пользователя, поэтому лучше разделить процесс
изучения приложений на два курса. Первый курс будет рассказывать о запуске приложения и
его основных функциональных возможностях. Во втором курсе будут рассматриваться более
специфические возможности приложения, а также способы решения потенциальных проблем и
настройки параметров. Первый курс должны закончить 80% пользователей, которым для
нормальной работы достаточно будет полученных знаний. Второй же курс необходим
оставшимся 20% и к этой части относятся продвинутые пользователи, разработчики,
сотрудники отдела поддержки и руководство технических отделов, которым также
необходимо хорошо разбираться в работе приложений.
Примечание! Если на одном удаленном узле работает несколько отделов компании, для слежения
за процессом передачи информации и оказания помощи другим пользователям рекомендуется
создать группу из продвинутых пользователей и разработчиков.
10.20Анализ мнений пользователей
Реальное функционирование сети, как правило, отличается от ожидаемого. О возникающих
в работе сети недостатках отдел информационных систем должен узнавать первым. В больших
организациях обычно довольно сложно определить, как пользователи относятся к сети. Именно
для этих целей, а также для своевременного определения недостатков и незапланированных
событий, необходимо постоянно анализировать мнения пользователей. Иногда эта обратная
связь приобретает форму замечаний различных отделов о работе группы поддержки.
Пользователи, например, могут передавать свои замечания начальнику отдела, а тот уже
непосредственно посылает их начальнику отдела информационных систем. Для передачи сведений такого типа может использоваться и обычная электронная почта, с помощью которой
пользователи могут поблагодарить работников группы поддержки за хорошую работу. Тем не
менее, независимо от формы общения, руководство компании и руководство отдела
информационных систем должны обязательно знать, что любая работа специалистов сетевого
отдела находит отклик у простых пользователей. Важно также знать о наличии или отсутствии
недостатков или проблем в развернутой инфраструктуре и способах их устранения.
10.21«Разбор полетов»
Наконец-то проект закончен. Пользователям установлены все необходимые системы. Они
обучены и могут самостоятельно решить большую часть проблем. Пришло время взглянуть на
94
проделанную работу и прикинуть, каким образом все это могло быть выполнено иначе.
Рекомендуется собрать всех специалистов информационного отдела (например, на небольшой
фуршет) и обсудить с ними различные стадии разработки и реализации проекта. Руководитель
проекта должен ответить на следующие вопросы:
Достиг ли проект результата?
Достиг ли проект ожидаемого успеха у пользователей (это иногда сильно отличается от
первого пункта)?
Какими недостатками обладает завершенный проект?
Какие аспекты были недостаточно проработаны?
Понимала ли группа разработки цели проекта? (Необходимо ещё раз напомнить
группе о целях для большей концентрации внимания.)
Были ли достигнуты преимущества, не учитываемые на этапе разработки?
Задайте группе вопрос: «Если бы мы делали этот проект еще раз, зная то, что мы знаем
сейчас, то чтобы мы изменили?» и позвольте ответить на него каждому члену группы. Ответ при
этом должен рассматриваться с точки зрения специализации данного специалиста. После
этого, посоветовавшись с группой, определите, какие области применения следует улучшить во
время будущей модернизации. Цель такого упражнения включается не только в анализе
допущенных ошибок, но и в акцентировании внимания на основных факторах, ведущих к
построению корректно функционирующей сети.
10.22Резюме
Создание сети с «нуля» очень тяжелая работа. Для ее успешного выполнения необходимо
учитывать множество факторов и ни один из них не должен быть пропущен. Особое внимание
следует уделить созданию документации и связи с пользователями. Хорошо
документированная сеть, которая постоянно выходит из строя и требует для своей работы
некоторых дополнительных ресурсов, намного лучше, чем отлично функционирующая сеть,
обслуживающий персонал которой боится дотронуться к ней и не в состоянии решить ни одну
возникшую проблему. Многие ключевые моменты создания являются не столько
техническими, сколько организационными. Основной фигурой проекта выступает его
руководитель, ведь если он недостаточно подготовлен и не имеет должной поддержки у группы
разработчиков, то проект можно считать проваленным. Как правило, технические проблемы
редко являются основными причинами провала сетевого проекта, поскольку каждый член
группы разработки - это технический профессионал, обладающий навыками работы и решения
проблем. Не следует упускать из вида и тот факт, что сеть представляет собой средство
повышения продуктивности работы коллектива пользователей, а уже вторичными момен тами
ее создания является достижение высокой производительности и надежности. Именно надежно
функционирующая сеть считается успешным окончанием любого проекта.
11 Лекция № 11 Введение в базы данных. Определение термина «база данных».
История баз данных
11.1 Введение в базы данных
Задача базы данных состоит в том, чтобы помочь людям в учете различного рода вещей. В
классических приложениях баз данных ведется учет заказов, клиентов, выполненных работ,
сотрудников, телефонных звонков и многих других вещей, представляющих интерес для
предпринимателя. В последнее время технология баз данных используется в Интернете не только
для этих традиционных нужд, но и для новых приложений, к которым относится, например,
реклама, настроенная на характеристики потребителей, и отслеживание предпочтение клиентов
95
при просмотре WEB-страниц и покупке товаров. Такие базы данных включают в себя наряду с
традиционными числовыми данными картинки, а также аудио- и видеоинформацию.
Базы данных всегда были важной темой при изучении информационных систем. Но именно
в последние годы, благодаря бурному развитию Интернета и связанному с этим технологическому
прорыву, знание технологии баз данных стало одним из наиболее популярных путей к карьере.
Технология баз данных позволяет сделать интернет-приложение чем-то большим, чем просто
средство для публикации брошюр, что было характерно для ранних приложений. В то же время
интернет-технологии обеспечивают стандартизированный и доступный способ доставки
содержимого базы данных пользователям. Ни одно из этих новых обстоятельств не отменяет
необходимости в классических приложениях баз данных, которые были незаменимы в бизнесе до
появления Интернета, — они лишь усиливают важность знаний о базах данных.
Многие студенты находят этот предмет интересным и увлекательным, хотя порой он может
быть трудным. Проектирование и разработка баз данных требуют одновременно и искусства, и
инженерных навыков. Понимание требований пользователя и воплощение этих требований в
эффективной логической структуре базы данных является искусством моделирования.
Преобразование логической структуры в физическую базу данных с функционально
завершенными, высокопроизводительными приложениями представляет собой инженерную
задачу. Оба эти аспекта сулят множество трудных и увлекательных интеллектуальных
головоломок.
Из-за крайне высокой востребованности технологии баз данных навыки и знания,
полученные вами в процессе изучения этого курса, будут иметь огромный спрос.
11.2 Определение термина «база данных»
Термин база данных (database) страдает от обилия различных интерпретаций. Он
использовался для обозначения чего угодно — от обычной картотеки до многих томов данных,
которые правительство собирает о своих гражданах. Мы будем использовать данный термин в
конкретном значении: база данных — это самодокументированное собрание интегрированных
записей. Важно понять обе части этого определения.
11.2.1
Самодокументированность
База данных является самодокументированной (self-describing): она содержит, в
дополнение к исходным данным пользователя, описание собственной структуры. Это описание
называется словарем данных (data dictionary), каталогом данных (data directory) или метаданными
(metadata).
В этом смысле база данных напоминает библиотеку, которую можно представить как
самодокументированный набор книг. Кроме книг в библиотеке имеется каталог с их описанием.
Точно так же словарь данных (являющийся частью базы данных, подобно тому, как каталог
является частью библиотеки) описывает данные, содержащиеся в базе данных.
Почему самодокументированность является столь важной характеристикой базы данных?
Во-первых, она обусловливает независимость программ от данных. Иначе говоря,
она дает возможность определить структуру и содержимое базы данных путем обращения
к самой базе данных. Нам не придется делать предположения о том, что содержит база
данных, а также отпадет необходимость как-либо внешне документировать формат записей
и файлов (как это делается в системах обработки файлов).
Во-вторых, если мы изменим структуру данных в базе (например, добавим новые
элементы данных к существующей записи), то эти изменения мы внесем только в словарь
данных. Лишь небольшую часть программ необходимо будет изменить (если таковые
вообще будут). В большинстве случаев модификации потребуют только те программы,
которые непосредственно обрабатывают элементы данных, претерпевшие изменения.
96
База данных — это собрание интегрированных записей
11.2.2
Стандартная иерархия данных выглядит следующим образом: биты объединяются в
байты, или символы; символы группируются в поля; из полей формируются записи; записи
организуются в файлы.
Биты
Байты или символы
Поля
Записи
Файлы
Есть соблазн последовать этому образцу и сказать, что файлы объединяются в базу данных. Хотя
это утверждение будет верным, оно, тем не менее, отразит суть недостаточно полно.
В базе данных действительно содержатся файлы данных пользователя, однако ими все не
исчерпывается. Как уже упоминалось ранее, в разделе метаданных база данных содержит
описание самой себя. Кроме того, база данных содержит индексы (indexes), которые представляют
связи между данными, а также служат для повышения производительности приложений базы
данных. Наконец, зачастую база данных содержит данные о приложениях, использующих эту базу
данных. Структура форм для ввода данных и отчетов иногда является частью базы данных. Эту
последнюю категорию данных мы называем метаданными приложений (application metadata).
Таким образом, база данных содержит четыре типа данных, представленных ниже:
Биты
Байты или символы
приложений
База данных.
11.2.3
Поля
Записи
Файлы+ метаданные+ индексы+ метаданные
файлы данных пользователя,
метаданные,
индексы,
метаданные приложений.
База данных является моделью модели
База данных представляет собой модель. Возникает соблазн сказать, что база данных - это
модель реальности или некоторой части реальности, относящейся к бизнесу. Однако это неверно.
База данных не моделирует реальность или какую-либо ее часть, но является моделью
пользовательской модели (user model). Например, база данных любого предприятия представляет
собой модель того, как руководство предприятия видит свой бизнес. С их точки зрения, их бизнес
состоит из клиентов, работ и поставщиков клиентов. Поэтому в базе данных представлены факты,
касающиеся этих объектов. Имена и адреса клиентов, описание и временные рамки производимых
работ, имена поставщиков клиентов — все это данные, являющиеся важными для ведения бизнеса
в представлении руководителей предприятия.
Базы данных различаются по уровню детализации. Некоторые их них просты и
примитивны. Список клиентов и сумм, которые они должны заплатить, - вот приблизительное
представление модели, существующей в голове руководителей предприятия. Более
детализированное представление включает виды работ, имена поставщиков клиентов и путь,
проделанный до места проведения каждой из работ. Очень подробное представление может
включать вид и количество использованных материалов, требуемое количество запчастей и
количество часов, ушедшее на каждую фазу работ – нормирования, измерения, обсчёта, проезда и
т. п.
Степень детализации, которая должна присутствовать в базе данных, зависит от того,
какого рода информация необходима. Ясно, что чем больше требуется информации, тем более
подробной должна быть база данных. Выбор подходящей степени детализации является важной
частью работы по проектированию базы данных. Как вы обнаружите, основополагающим
критерием здесь является уровень детализации, имеющийся в голове пользователя.
База данных представляет собой динамическую модель, поскольку бизнес имеет свойство
меняться: люди приходят и уходят, продукты появляются и устаревают, деньги зарабатываются и
97
тратятся. По мере этих изменений данные, представляющие бизнес, также должны меняться. В
противном случае они будут устаревать и представлять бизнес неадекватно.
Транзакции (transactions) являются представлением событий. Когда происходят какие-то события,
с базой данных должны быть выполнены соответствующие транзакции. Для этого кто-либо
(например, оператор ввода данных, продавец или кассир в банке) запускает программу обработки
транзакций и вводит данные для транзакций. Программа затем вызывает СУБД для внесения
изменений в базу данных. Обычно программа обработки транзакций выдает на дисплей или
распечатывает на бумаге отчет — например, подтверждение заказа или чек.
11.3 История баз данных
Базы данных изначально использовались в больших корпорациях и крупных организациях
как основа для больших систем обработки транзакций. Позднее, по мере того как популярность завоевывали микрокомпьютеры, технология баз данных также мигрировала в этом направлении и
стала использоваться для однопользовательских, персональных приложений. Затем, когда
микрокомпьютеры начали объединять в рабочие группы, технология баз данных была
модифицирована с учетом этой тенденции. Наконец, в настоящее время базы данных используются в приложениях для Интернета и интрасетей.
11.4 Организационный контекст
Исходное предназначение технологии базы данных заключалось в том, чтобы преодолеть
трудности с системами обработки файлов, речь о которых шла ранее в этой лекции. В середине
1960-х годов большие корпорации накапливали данные в системах обработки файлов с
феноменальной скоростью, но работать с этими данными становилось все сложнее, и все более
затруднительной оказывалась разработка новых систем. Более того, менеджеры хотели иметь
возможность соотносить данные из одной файловой системы с данными из другой системы.
Ограничения файловой обработки препятствовали простой интеграции данных. Технология
баз данных, однако, выполнила обещание решить эти проблемы, и крупные компании начали
разрабатывать организационные базы данных. В этих базах данных централизованно хранились и
обрабатывались данные о заказах, товарах и счетах предприятия. Эти приложения представляли
собой главным образом системы обработки транзакций организационного масштаба.
На первых порах, когда технология была еще несовершенной, приложения баз данных
были сложны в разработке и выдавали много ошибок. Даже успешно работающие приложения
были медленными и ненадежными: аппаратное обеспечение того времени было не в состоянии
быстро справиться с объемом выполняемых транзакций, разработчики еще не изобрели более
эффективные способы хранения и извлечения данных, а программисты еще не освоили работу с
базами данных, и иногда их программы работали некорректно.
Обнаружен был и еще один недостаток баз данных - их уязвимость. Если произойдет сбой в
системе обработки файлов, из строя выйдет только одно конкретное приложение. Если же сбой
случится в базе данных, то выйдут из строя все ее приложения.
Постепенно ситуация улучшилась. Разработчики аппаратного и программного обеспечения
научились создавать системы, достаточно мощные, чтобы поддерживать большое количество
параллельно работающих пользователей, и достаточно быстродействующие, чтобы справляться с
требуемым объемом транзакций. Были разработаны новые способы контроля, защиты и
резервного копирования баз данных. Усовершенствовались стандартные процедуры обработки
данных, а программисты научились писать более эффективный и легкий для поддержания код. К
середине 1970-х базы данных были в состоянии эффективно и надежно обрабатывать
организационные приложения. Многие из этих приложений используются до сих пор, более чем
через 25 лет после их создания!
98
11.5 Реляционная модель
В 1970 году Э. Ф. Кодд опубликовал свою эпохальную статью1, в которой он применил
концепции раздела математики, называемого реляционной алгеброй, к проблеме хранения
больших объемов данных. Статья Кодда положила начало движению в сфере проектирования баз
данных, которое привело несколько лет спустя к созданию реляционной модели базы данных
(relational database model). Эта модель представляет собой определенный способ структурирования
и обработки базы данных.
Преимущество реляционной модели заключается в способе хранения данных, который
минимизирует их дублирование и исключает определенные типы ошибок обработки,
возникающие при других способах хранения данных. Данные хранятся в виде таблиц со
столбцами и строками.
Согласно реляционной модели, не все виды таблиц одинаково приемлемы. С помощью
процесса, называемого нормализацией (normalization), нежелательная таблица может быть
преобразована в две или более приемлемых. Более подробно о процессе нормализации будет
рассказано ниже.
Другое преимущество реляционной модели состоит в том, что в столбцах содержатся
данные, связывающие одну строку с другой. Например, столбец CUSTOMER_ID в таблице JOB
связан со столбцом CUSTOMER_ID в таблице CUSTOMER. Это делает связи между строками
видимыми для пользователя.
Поначалу считалось, что реляционная модель позволит пользователям извлекать
информацию из баз данных без помощи профессионалов MIS (административно-информационной
системы). Доля истины в этом есть, так как таблицы представляют собой простые и интуитивно
понятные конструкции. Кроме того, поскольку связи хранятся вместе с данными, пользователи
могут при необходимости комбинировать нужные строки.
Оказалось, что этот процесс слишком сложен для большинства пользователей. По этой
причине ожидания, что реляционная модель предоставит пригодный для неспециалистов способ
доступа к базам данных, не оправдались. Оглядываясь назад, можно резюмировать: ключевым
преимуществом реляционной модели оказалось то, что она дает специалистам (таким, как вы!)
стандартный способ структурирования и обработки баз данных.
11.6 Коммерческие СУБД для микрокомпьютеров
В 1979 году небольшая компания под названием Ashton-Tate представила новый
программный продукт для микрокомпьютеров, dBase II, и назвала его реляционной СУБД.
Применяя чрезвычайно успешную рыночную тактику, Ashton-Tate почти бесплатно
распространила более 100 000 копий своего продукта среди покупателей новых в то время
микрокомпьютеров Osborne. Многие из тех, кто приобрел эти компьютеры, были пионерами
микрокомпьютерной индустрии. Они начали создавать приложения для микрокомпьютеров с
использованием dBase, и число dBase-приложений быстро росло. В результате Ashton-Tate стала
одной из первых крупных корпораций в индустрии микрокомпьютеров. Позднее она была
приобретена компанией Borland, которая в настоящее время продает продукты линии dBase.
Успех этого продукта, однако, вызвал неразбериху и путаницу в мире баз данных.
Проблема была в следующем: в соответствии с определением, которое стало преобладать в конце
70-х годов, продукт под названием dBase II вообще не являлся СУБД, а тем более реляционной.
Фактически это был язык программирования с расширенными возможностями для обработки
файлов. Около миллиона пользователей dBase II были уверены, что используют реляционную
СУБД, хотя в действительности это было не так.
Таким образом, термины система управления базами данных (database management system)
и реляционная база данных (relational database) в начале бума микрокомпьютеров использовались
достаточно произвольно. Большинство тех, кто работал с базами данных на микрокомпьютерах, на
1
Е Е Codd, «A Relational Model of Data for Large Shared Databanks», Communications of the ACM, 06 1970, с 377-387
99
самом деле занимались обработкой файлов и не получали тех преимуществ, которые характерны
для баз данных (хотя они и не замечали этого). Сегодня, когда рынок микрокомпьютеров стал
более зрелым и искушенным, ситуация стала иной. dBase IV и последующие продукты линии
dBase, такие как FoxPro, являются по-настоящему реляционными СУБД.
Хотя продукты dBase действительно были первым ориентированным на микрокомпьютеры
приложением технологии баз данных, примерно в это же время другие производители начали
переносить свои продукты с больших ЭВМ на микрокомпьютеры. В качестве примеров
коммерческих СУБД, перенесенных на микрокомпьютеры, можно упомянуть Oracle, Focus,
Informix и Ingress. Они действительно являются СУБД, и многие также согласятся с тем, что они
действительно реляционные.
Одним из следствий переноса технологии баз данных на микрокомпьютеры явилось резкое
улучшение пользовательского интерфейса СУБД. Пользователи ПК не стали бы мириться с
неуклюжим и неудобным интерфейсом, который характерен для СУБД, работающих на больших
ЭВМ. Таким образом, с разработкой коммерческих СУБД, ориентированных на
микрокомпьютеры, интерфейс этих программ стал удобнее в использовании. Это стало
возможным потому, что микрокомпьютерные СУБД работают на приспособленных под эти задачи
компьютерах, а также потому, что больше вычислительных ресурсов стало доступно для
обработки пользовательского интерфейса. Сегодняшние СУБД богаты возможностями, надежны и
имеют графический пользовательский интерфейс.
Сочетание микрокомпьютеров, реляционной модели и значительно улучшенного
пользовательского интерфейса позволило перенести технологию баз данных из контекста
организации в контекст персональных компьютеров. Когда это произошло, число мест, где
используется технология баз данных, увеличилось на порядки. В 1980 г. в США было около 10 000
мест, где использовались СУБД, сегодня же их более 40 миллионов!
11.7 Клиент-серверные приложения баз данных
В середине - конце 1980-х годов конечные пользователи начали объединять свои
компьютеры в локальные сети (local area networks, LAN). Эти сети сделали возможной передачу
данных между компьютерами с невиданными до тех пор скоростями. Первые приложения этой
технологии обеспечивали совместное использование периферийных устройств, таких как
быстродействующие дисковые накопители большой емкости, дорогие принтеры и плоттеры, и
осуществляли связь между компьютерами посредством электронной почты. В перспективе,
однако, пользователи хотели совместно использовать свои базы данных, что привело к развитию
многопользовательских приложений баз данных для локальных сетей.
Многопользовательская архитектура, применяемая в локальных сетях, значительно
отличается от многопользовательской архитектуры, применявшейся на больших ЭВМ
(mainframe). В случае последних в обработке приложения базы данных участвовал только один
процессор, а в локальных сетях для этого могут использоваться несколько процессоров.
Поскольку эта ситуация, помимо очевидной выгоды (большая производительность), влечет за
собой и новые трудности (координация действий независимых процессоров), возник новый стиль
многопользовательской обработки баз данных, называемый клиент-серверной архитектурой баз
данных (client-server database architecture).
Не все базы данных в локальных сетях используют клиент-серверную архитектуру. Более
простой, но менее устойчивый режим обработки баз данных называется архитектурой с
совместным использованием файлов (file-sharing architecture). Компания, представляющая собой
небольшую организацию с умеренными требованиями к обработке, могла бы, скорее всего,
использовать любую из этих двух архитектур. Однако для рабочих групп большего размера
потребуется клиент-серверная архитектура.
100
11.8 Базы данных с использованием интернет-технологий
Технология баз данных применяется в настоящее время в сочетании с технологией
публикации данных в Web. Эта же технология используется и для публикации приложений в
корпоративных и организационных интрасетях. Некоторые эксперты полагают, что в будущем все
приложения баз данных будут доставляться пользователям при помощи браузеров и связанных с
этим интернет-технологий — даже персональные базы данных, которые «публикуются» для
одного человека.
Существует две категории приложений, использующих интернет-технологии. Первая
категория включает в себя чистые web-приложения баз данных.
Вторая категория — традиционные персональные, коллективные и организационные базы
данных, которые не публикуются в Интернете, но используют браузеры и технологии, подобные
DHTML и XML. Поскольку называть последнюю категорию интернет-базами данных было бы
некорректно, в этой лекции обе категории объединены под термином базы данных с
использованием интернет-технологий.
Эта категория находится сегодня на переднем крае технологии баз данных. Язык XML
исключительно хорошо отвечает потребностям приложений баз данных и служит основой для
многих новых продуктов и услуг в этой сфере.
11.9 Распределенные базы данных
Прежде чем мы завершим этот исторический обзор, необходимо обсудить два аспекта
технологии баз данных, которые теоретически представляют важность, но еще не получили
широкого применения. Этими аспектами являются распределенные и объектно-ориентированные
базы данных.
Организационные базы данных решают проблемы, характерные для систем обработки
файлов, и обеспечивают более целостную обработку данных организации. Персональные и
коллективные базы данных переносят технологию баз данных еще ближе к пользователям, так
как управляются локально. Распределённые базы данных (distributed databases) сочетают в себе
эти два типа, позволяя объединять между собой персональные, коллективные и организационные
базы данных в целостные, но распределенные системы. Как таковые, они теоретически
обеспечивают более гибкие варианты доступа к данным и их обработки, но в то же время ставят
проблемы, многие из которых не решены до сих пор.
Сущность распределенных баз данных заключается в том, что все данные организации
распылены между многими компьютерами — микрокомпьютерами, серверами локальных сетей и
большими ЭВМ, которые взаимодействуют между собой в процессе обработки базы данных. Цель
этих систем в том, чтобы у каждого пользователя возникало ощущение, что он - единственный
пользователь данных организации, и чтобы при этом обеспечивались такие же согласованность,
точность и быстродействие, какие были бы, если бы этой распределенной базой данных больше
никто не пользовался.
Среди наиболее актуальных проблем распределенных баз данных можно упомянуть
проблемы безопасности и контроля. Обеспечить доступ к базе данных для столь большого
количества пользователей (а конкурирующих пользователей могут быть сотни) и
проконтролировать, какие действия они выполняют с распределенной базой данных, - это
непростые задачи.
Координация и синхронизация обработки могут вызывать затруднения. Если одна группа
пользователей загружает и обновляет часть базы данных, а затем передает модифицированные
данные обратно на большую ЭВМ, то как может система в это же время предотвратить попытку
другого пользователя использовать старую версию данных, находящуюся в настоящий момент на
большой ЭВМ? Представьте себе, что в этот процесс вовлечено огромное количество файлов,
сотни пользователей и множество различного компьютерного оборудования.
Если переход от организационных баз данных к персональным и затем к коллективным
происходил достаточно легко, то трудности, стоящие перед проектировщиками и разработчиками
распределенных СУБД, монументальны. По правде говоря, даже при том, что работа над
101
распределенными системами баз данных ведется вот уже более 25 лет, значительные проблемы
все еще остаются. Корпорация Microsoft разработала архитектуру распределенной обработки
данных и набор поддерживающих ее продуктов под названием Microsoft Transaction Server (MTS)
и сейчас занимается ее построением. Хотя MTS является многообещающим проектом и среди всех
компаний именно у Microsoft имеются ресурсы для разработки и продвижения на рынок подобной
системы, до сих пор остается неясным, действительно ли распределенные базы данных смогут
удовлетворить каждодневные потребности организаций в сфере обработки данных.
11.10Объектно-ориентированные СУБД
В конце 1980-х годов началось использование нового стиля программирования под
названием объектно-ориентированное программирование (object-oriented programming), или ООП
(OOP), который имел существенно иную ориентацию, чем традиционное линейное
программирование. Если говорить вкратце, то структуры данных, которые обрабатываются в
ООП, являются значительно более сложными, чем те структуры, с которыми приходится иметь
дело в традиционных языках программирования. Кроме того, сложно обеспечить хранение этих
структур с помощью существующих коммерческих СУБД. Как следствие возникает новая
категория СУБД — объектно-ориентированные СУБД (object oriented DBMS), предназначенные
для хранения и обработки структур данных ООП.
По множеству причин ООП еще не получило широкого применения в деловых
информационных системах. Во-первых, оно является сложным в использовании, а разработка
приложений ООП стоит очень дорого. Во-вторых, у большинства организаций миллионы или
миллиарды байтов данных организованы в реляционные базы данных, и они не желают брать на
себя риск и расходы, связанные с преобразованием этих баз данных в формат объектноориентированных СУБД. В-третьих, большинство объектно-ориентированных СУБД были разработаны для поддержки инженерных приложений, и они просто не обладают возможностями и
функциями, подходящими или быстро адаптируемыми для нужд деловых приложений.
Следовательно, в обозримом будущем объектно-ориентированные СУБД, скорее всего, не
будут широко использоваться в приложениях коммерческих информационных систем. Мы
обсудим ООП, объектно-ориентированные базы данных и принадлежащий Oracle Corporation
гибрид под названием объектно-реляционные базы данных (object-relational databases), но в
основном направление этих лекций будет посвящено реляционной модели, поскольку она связана
с технологиями, которые наверняка будут использоваться в течение первых пяти лет вашей
карьеры.
11.11Резюме
Базы данных - один из наиболее важных курсов, связанных с информационными
системами. Навыки и знания, приобретаемые в ходе изучения этого курса, пользуются большим
спросом не только для традиционных приложений, но также для приложений, использующих
интернет-технологию в открытых и закрытых сетях.
Технология баз данных используется во множестве приложений. Некоторые из них
предназначены для единственного пользователя с единственным компьютером, другие
используются рабочими группами в количестве 20-30 человек через локальную сеть, третьи
служат сотням пользователей и содержат триллионы байтов данных. В последнее время
технология баз данных применяется в сочетании с интернет-технологией для поддержки
мультимедийных приложений в открытых и закрытых сетях.
Компонентами приложения базы данных являются сама база данных, система управления
базой данных (СУБД) и прикладные программы. Иногда прикладные программы действуют
полностью независимо от СУБД, а иногда значительная часть функциональности приложения
обеспечивается за счет возможностей и функций СУБД.
102
Системы обработки файлов хранят данные в отдельных файлах, каждый из которых
содержит свой тип данных. Эти системы имеют несколько ограничений. Данные, хранимые в
отдельных файлах, трудно комбинировать, поскольку они зачастую дублируются в разных файлах,
что приводит к нарушениям целостности данных. Прикладные программы зависят от форматов
файлов, что вызывает проблемы при обслуживании: когда форматы меняются, файлы становятся
несовместимыми, и требуется их преобразовывать. Трудно также представить данные в удобном
для пользователя виде.
Системы обработки баз данных были разработаны для того, чтобы преодолеть эти
ограничения. В базе данных СУБД служит интерфейсом между прикладными программами и
базой данных. Данные интегрированы, и они не дублируются столь часто. Изменение физических
форматов файлов затрагивает только СУБД. Если элементы данных изменяются, добавляются или
удаляются, лишь немногие из прикладных программ требуют модификации. Технология баз
данных упрощает представление данных в удобном для пользователя виде.
База данных — это самодокументированное собрание интегрированных записей. Она
является самодокументированной, так как содержит описание самой себя в словаре данных.
Словарь данных известен также как каталог данных, или метаданные. База данных является
собранием интегрированных записей, поскольку связи между записями также хранятся в базе
данных. Такая организация позволяет СУБД конструировать даже весьма сложные объекты,
комбинируя данные на основании хранимых связей. Связи часто хранятся как избыточные
данные. Таким образом, три составляющие базы данных — это данные приложений, словарь
данных и избыточные данные.
Технология баз данных развивалась в несколько стадий. Ранние базы данных
фокусировались на обработке транзакций с данными организации. Затем появление реляционной
модели и микрокомпьютеров привело к созданию персональных приложений баз данных. С
появлением локальных сетей началась разработка коллективных баз данных с клиент-серверной
архитектурой. Сегодня традиционные приложения баз данных доставляются пользователю с
помощью интернет-технологий. Важными направлениями в отрасли баз данных являются
распределенные и объектно-ориентированные базы данных. Сегодня, однако, ни одно из этих двух
направлений не стало коммерчески успешным и не получило широкого применения в деловых
приложениях.
12 Лекция № 12 Введение в разработку баз данных. СУБД. Создание базы
данных. Компоненты приложения. Процесс разработки базы данных
12.1 Введение в разработку баз данных.
В этой лекции в общих чертах рассматривается процесс разработки базы данных и ее
приложений. Мы начнем с описания элементов базы данных и обсуждения характерных
особенностей и функций СУБД. Далее мы проиллюстрируем процесс создания базы данных и
приложения для работы с ней. В заключение мы обсудим популярные стратегии разработки баз
данных. Цель этой лекции состоит в том, чтобы заложить основу для детального описания этой
технологии, которое последует в дальнейших лекциях.
12.2 База данных
На рис. 12.1 показаны основные компоненты системы базы данных. Базу данных
обрабатывает СУБД, которая используется разработчиками и пользователями, обращающимися к
СУБД напрямую или косвенно, через прикладные программы. Данный раздел посвящен базе
данных, а СУБД и прикладные программы обсуждаются в следующих разделах.
СУБД
103
Разработчик
Средства проектирования
Средство для создания таблиц
Я
Д Средство для создания формул
Р Средство для создания запросов
О
Средство для создания отчётов
Подсистема обработки
Процессор форм
С Процессор запросов
У Генератор отчётов
Б
Д Средства обработки, реализованные на
процедурных языках
База данных
Прикладные
программы
Пользователи
Прикладные
программы
Рис. 12.1
Как вам уже известно, из лекции № 11, база данных состоит из четырех основных элементов:
данных пользователя, метаданных, индексов и метаданных приложений.
12.3 Данные пользователя
Сегодня большинство баз данных представляют данные пользователя в виде отношений
(relations). Формальное определение термина отношение мы дадим ниже. На данный же момент
будем рассматривать отношение как таблицу данных. Столбцы таблицы содержат поля, или
атрибуты, а строки содержат записи о конкретных объектах делового мира.
Не все отношения являются одинаково желательными; некоторые отношения
структурированы лучше, чем другие. Процесс, с помощью которого получаются хорошо структурированные отношения, называется нормализацией (normalization). Чтобы получить
представление о разнице между плохо и хорошо структурированными отношениями, рассмотрим
отношение R1 (ИмяСтудента, Телефон Студента, ИмяРуководителя, ТелефонРуководителя), содержащее
имена и телефоны студентов и их руководителей:
ИмяСтудента ТлфСтудента
ИмяРуковод
Бейкер, Рекс
Бет, Мэри
Скотт, Гленн
Зилог, Фрита
Чарлз Джонсон,
Парке
Джонс
Парке
Джонс
Парке
232-8897
232-4487
232-4444
232-5588
232-0099
ТлфРуковод
236-0098
236-0110
236-0098
236-0110
236-0098
Недостаток этого отношения состоит в том, что оно содержит данные, принадлежащие
двум различным темам — студентам и руководителям. Такая структура отношения порождает
определенные проблемы при его обновлении. Например, если у руководителя по фамилии Парке
изменится номер телефона, необходимо будет изменить три строки данных. По этой причине было
бы лучше представить данные в виде двух отношений. Первое из них, R2 (ИмяСтудента,
ТелефонСтудента, ИмяРуководителя), будет содержать имя и телефон студента и фамилию его
руководителя:
ИмяСтудента ТлфСтудента
ИмяРуковод
Бейкер, Рекс
Бет, Мэри
Скотт, Гленн
Зилог, Фрита
Чарлз Джонсон,
Парке
Джонс
Парке
Джонс
Парке
232-8897
232-4487
232-4444
232-5588
232-0099
104
Второе отношение, R3 (ИмяРуководителя, ТелефонРуководителя), будет содержать фамилию и
телефон руководителя
ИмяРуковод
ТлфРуковод
Парке
Джонс
Парке
Джонс
Парке
236-0098
236-0110
236-0098
236-0110
236-0098
Теперь, если у руководителя изменится номер телефона, необходимо будет изменить
только одну строку в отношении R3. Разумеется, чтобы сформировать отчет, в котором были бы
представлены имена студентов вместе с именами их руководителей, нужно будет объединить
строки этих двух таблиц. Оказывается, однако, что гораздо лучше хранить отношения раздельно и
объединять их при составлении отчета, чем хранить их в виде одной комбинированной таблицы.
12.4 Метаданные
Как было указано в лекции 11, база данных является самодокументированной, то есть
одной из ее составляющих является описание собственной структуры. Это описание называется
метаданными (metadata). Так как СУБД предназначены для хранения таблиц и манипуляции ими,
большинство из них хранят метаданные в форме таблиц, иногда называемых системными
таблицами (system tables). В табл. 12.1 представлены два примера хранения метаданных в
системных таблицах. В таблице SysTables перечислены все таблицы, имеющиеся в базе данных, и
для каждой таблицы указаны количество столбцов и имена одного или нескольких столбцов,
служащих первичным ключом. Такой столбец или набор столбцов является уникальным
идентификатором строки. В таблице SysColumns перечислены столбцы, имеющиеся в каждой
таблице, а также тип данных и ширина каждого столбца. Эти две таблицы представляют собой
типичные образцы системных таблиц; в других подобных таблицах хранятся списки индексов,
ключей, хранимых процедур и т. п.
Таблица 12.1. Примеры метаданных
Таблица SysTables
Имя таблицы
Студент
Руководитель
Дисциплина
УчебныйПлан
Таблица
SysColumns
Имя столбца
НомерСтудента
Имя
Фамилия
Специальность
ИмяРуководителя
Телефон
Кафедра
НомерДисциплины
Название
КоличествоЧасов
Число столбцов
4
3
3
3
Имя таблицы
Первичный ключ
НомерСтудента
ИмяРуководителя
НомерДисциплины
{НомерСтудента, НомерДисциплины}
Тип данных
Длина (Длины приведены в
байтах или, что то же самое, в
символах (для текстовых
данных)
Студент
Студент
Студент
Студент
Руководитель
Руководитель
Руководитель
Дисциплина
Дисциплина
Дисциплина
Integer
Text
Text
Text
Text
Text
Text
Integer
Text
Decimal
105
4
20
30
10
25
12
15
4
10
4
НомерСтудента
Курс
НомерДисциплины
УчебныйПлан
УчебныйПлан
УчебныйПлан
Integer
Text
Integer
4
2
4
Хранение метаданных в таблицах не только эффективно для СУБД, но и удобно для
разработчиков, поскольку для запроса метаданных они могут использовать те же самые средства,
что и для запроса пользовательских данных. В лекции 14 мы обсудим язык под названием SQL,
который используется для запроса и обновления таблиц метаданных и пользовательских данных.
В качестве возможного примера использования SQL представьте, что вы разработали базу
данных с 15 таблицами и 200 столбцами. Вы помните, что некоторые столбцы имеют тип данных
currency, но не можете вспомнить, какие именно. С помощью SQL можно обратиться к таблице
SysColumns и по ней определить, какие столбцы имеют указанный тип данных.
12.5 Индексы
Третий тип данных, которые хранятся в базе данных, призван улучшить ее
производительность и доступность. Эти данные, называемые иногда избыточными данными
(overhead data), состоят главным образом из индексов (indexes), хотя в ряде случаев используются
и другие структуры данных, такие как связанные списки (индексы и связанные списки
обсуждаются ниже).
В табл. 2.2 приведены данные о студентах и два индекса к ней. Чтобы уяснить, какая может
быть польза от индексов, представьте себе, что данные в таблице СТУДЕНТ расположены в
порядке возрастания значения поля НомерСтудента, а пользователь хотел бы создать из этих
данных отчет, отсортированный по полю Фамилия. Для этого можно было бы извлечь все данные
из таблицы и отсортировать, но, если размеры таблицы не слишком малы, этот процесс может занять много времени. В качестве альтернативы можно создать индекс Фамилия, приведенный в
табл. 2.2. Записи в этом индексе отсортированы по полю Фамилия, поэтому достаточно считать
записи из индекса в порядке следования, чтобы затем получать данные из таблицы СТУДЕНТ,
отсортированные в нужном порядке.
Таблица 12.2. Примеры индексов
Таблица СТУДЕНТ
НомерСтудента Имя____________Фамилия_______Специальность____________________
100
Джеймс
Бейкер
Бухгалтерский учет
200
Мэри
Абернати
Информационные системы
300
Бет
Джексон
Бухгалтерский учет
400
Элдридж
Джонсон
Маркетинг
500
Крис
Тафт
Бухгалтерский учет
600
Джон
Сматерс
Информационные системы
700
Майкл
Джонсон
Бухгалтерский учет
Индекс Фамилия
Фамилия_____________________НомерСтудента______________________________________
Абернати
200
Бейкер
100
Джонсон
300
Джонсон
400, 700
Сматерс
600
Тафт_________________________500________________________________________________
Индекс Специальность
Специальность_______________НомерСтудента______________________________________
Бухгалтерский учет
100,300,500,700
Информационные системы
200, 600
Маркетинг____________________400_________________________________________________
Теперь представьте, что требуется получить данные о студентах, отсортированные по полю
Специальность. Опять-таки, можно извлечь эти данные из таблицы СТУДЕНТ и отсортировать, а
можно создать индекс Специальность и использовать его, как показано выше.
Индексы используются не только для сортировки, но и для быстрого доступа к данным.
Пусть, например, пользователю нужны сведения только о тех студентах, чьей специальностью
являются информационные системы. Без индекса пришлось бы проводить поиск по всей таблице.
106
Имея же индекс, можно найти в нем соответствующую запись и использовать ее для нахождения
нужных строк в таблице. На самом деле, если количество строк невелико, как в таблице
СТУДЕНТ, индексы де нужны, но представьте себе таблицу, которая содержит 10 000 или 120 000
строк. В этом случае сортировка или поиск по всей таблице работали бы слишком медленно.
Индексы удобны для сортировки и поиска, но за их использование приходится платить
свою цену. Каждый раз, когда обновляется строка в таблице СТУДЕНТ, индексы также
необходимо обновлять. Это не обязательно плохо - это означает только, что индексы не даются
даром и поэтому должны использоваться только в тех случаях, когда это действительно
оправдано.
12.6 Метаданные приложений
Четвертый и последний тип информации в базе данных - это метаданные приложений
(application metadata), которые описывают структуру и формат пользовательских форм, отчетов,
запросов и других компонентов приложений. Не все СУБД поддерживают компоненты
приложений, а из тех СУБД, где такая возможность предусмотрена, не все хранят структуру этих
компонентов в виде метаданных приложений в базе данных. Однако большинство современных
СУБД хранят эту информацию в базе данных. Вообще говоря, ни разработчики баз данных, ни
пользователи не обращаются к метаданным приложений напрямую, а пользуются
соответствующими средствами, которые предоставляет СУБД.
12.7 СУБД
СУБД значительно различаются по своим характеристикам и функциям. Первые продукты
такого рода были разработаны для больших ЭВМ в конце 1960-х годов и были весьма
примитивны. С тех пор СУБД постоянно совершенствовались, а функции их расширялись.
Усовершенствования касались не только обработки баз данных: СУБД также снабжались
функциями, упрощающими создание приложений баз данных.
В этой лекции для иллюстрации возможностей СУБД мы будем использовать Microsoft Access
2002. Это обусловлено тем, что Access 2002 обладает всеми типичными характеристиками и
функциями современной СУБД. Однако Access 2002 не является единственной СУБД такого рода,
и наш выбор ни в коей мере не предполагает какого-либо предпочтения перед другими подобными
продуктами, например MS SQL Server 2003.
Как видно из рис. 12.1, характеристики и функции СУБД можно разделить на три
подсистемы:
подсистему средств проектирования,
подсистему средств обработки,
ядро СУБД.
12.8 Подсистема средств проектирования
Подсистема средств проектирования (design tools subsystem) представляет собой набор
инструментов, упрощающих проектирование и реализацию баз данных и их приложений. Как
правило, этот набор включает в себя средства для создания таблиц, форм, запросов и отчетов. В
СУБД имеются также языки программирования и интерфейсы для них. Например, в Access есть
два языка: макроязык, не требующий глубокого знания программирования, и версия языка BASIC
под названием Visual Basic.
107
12.9 Подсистема обработки
Подсистема обработки (run-time subsystem)2 занимается обработкой компонентов
приложения, созданных с помощью средств проектирования. Например, в Access 2002 имеется
компонент, материализующий формы и связывающий элементы форм с данными таблиц.
Представьте себе форму с текстовым полем, где отображается значение столбца НомерСтудента
из таблицы СТУДЕНТ. В процессе работы приложения при открытии формы процессор форм
(form processor) извлекает значение поля НомерСтудента из текущей строки таблицы и отображает
его в форме. Все это делается автоматически - ни пользователю, ни разработчику не требуется
ничего делать, если имеется готовая форма. Другие процессоры подсистемы обработки
предназначены для выполнения запросов и вывода отчетов. Кроме того, в подсистеме обработки
имеется компонент, обрабатывающий запросы прикладных программ на чтение и запись данных в
базу.
Хотя это не показано на рис. 2.1, СУБД должны также предоставлять интерфейс для стандартных
языков программирования, таких как C++ и Java.
12.10Ядро СУБД
Третий компонент СУБД — это ее ядро (DBMS engine), которое выполняет функцию
посредника между подсистемой средств проектирования и обработки и данными. Ядро СУБД
получает запросы от двух других компонентов, выраженные в терминах таблиц, строк и столбцов,
и преобразует эти запросы в команды операционной системы, выполняющие запись и чтение
данных с физического носителя.
Кроме того, ядро СУБД участвует в управлении транзакциями, блокировке, резервном
копировании и восстановлении. Действия с базой данных должны выполняться как единое целое.
Например, при обработке заказа изменения в таблицах КЛИЕНТ, ЗАКАЗ и СКЛАД должны
производиться согласованно: либо выполняются все, либо не выполняется ни одно. Ядро СУБД
помогает координировать действия, с тем, чтобы либо выполнялись все действия в группе, либо не
выполнялись ни одного.
Microsoft предоставляет два различных ядра для Access 2002: Jet Engine и SQL Server. Ядро
Jet Engine используется для небольших персональных и коллективных баз данных. Ядро SQL
Server, представляющее собой независимый продукт Microsoft, предназначено для крупных баз
данных уровня отдела и небольших или среднего размера организационных баз данных. Когда вы
создаете базу данных с помощью встроенных в Access 2002 средств генерации таблиц (такие базы
данных хранятся вместе с suffix.mdb), вы используете Jet Engine. Создавая проект Access 2002 (с
suffix.adp), вы тем самым создаете прикладной интерфейс для ядра SQL Server.
12.11Создание базы данных
Схема базы данных (database scheme) определяет структуру базы данных, ее таблиц, связей
и доменов, а также деловой регламент. Схема базы данных — это проект, основа, на которой
строятся база данных и ее приложения.
2
В английском языке подсистема обработки обозначается термином run-time subsystem. He следует путать его с
похожим термином run-time product, который имеет несколько другое значение. Этим термином некоторые
производители обозначают урезанный вариант комплектации СУБД, куда входят подсистема обработки и ядро, но
не входит подсистема средств проектирования. Такой вариант позволяет лишь запускать готовое приложение.
Назначение таких продуктов в том, чтобы снизить стоимость приложения для конечного пользователя. Обычно
СУБД без подсистемы средств разработки стоит намного дешевле, чем полноценная СУБД, а иногда и вовсе
бесплатна. Следовательно, полную версию продукта покупает только разработчик, а конечные пользователи
покупают сокращенную версию
108
12.12Пример схемы базы данных
Чтобы уяснить себе, что такое схема базы данных и зачем она нужна, рассмотрим пример.
Колледж Highline — небольшой колледж свободных искусств на Среднем Западе США. Отдел
студенческого досуга колледжа финансирует локальные спортивные секции, но испытывает
проблемы с учетом спортивного инвентаря, выданного капитанам различных команд. Схема базы
данных для системы учета спортинвентаря будет содержать следующие компоненты.
12.13Таблицы
База данных имеет две таблицы3: CAPTAIN (CaptainName, Phone, Street City, State, ZIP), содержащую сведения о капитанах, и ITEM (Quantity, Description, Dateln, DateOut), содержащую
данные об инвентаре. Здесь перед скобками даны имена таблиц, а в скобках указываются имена
столбцов.
Ни CaptainName (имя капитана), ни Description (описание) не обязаны быть уникальными,
поскольку вполне может быть два капитана по имени Мэри Смит, и уж наверняка имеется много
инвентаря под названием «футбольные мячи». Чтобы обеспечить однозначную идентификацию
каждой строки (важность этого будет объяснена в последующих главах), мы добавим в каждую из
этих таблиц столбец с уникальным номером, как показано ниже:
CAPTAIN(CAPTAIN_ID, CaptainName, Phone, Street, City, State, ZIP) ITEM(ITEM_ID, Quantity,
Description, Dateln, DateOut)
12.14Связи
Две представленные здесь таблицы имеют следующие связи: одна строка таблицы
CAPTAIN связана с несколькими строками таблицы ITEM, но одна строка таблицы ITEM
связана с одной и только одной строкой таблицы CAPTAIN. Такая связь обозначается 1:N и
произносится «один к N» или «один ко многим». Обозначение 1:N следует понимать так, что одна
строка в первой таблице связана с несколькими строками во второй таблице.
По тем обозначениям таблиц, которые даны выше, невозможно сказать, какая строка
таблицы CAPTAIN связана с какими строками таблицы ITEM. Поэтому, чтобы обозначить их
связь, мы добавим в таблицу ITEM столбец CAPTAIN_ID. Полная структура двух таблиц
выглядит следующим образом:
CAPTAIN(CAPTAIN_ID, CaptainName, Phone, Street, City, State, ZIP)
ITEM(ITEM_ID, Quantity, Description, Dateln, DateOut, CAPTAIN_ID)
При такой структуре легко определить, какому капитану был выдан данный инвентарь.
Например, чтобы узнать, кому был выдан инвентарь за номером 1234, в соответствующей строке
таблицы ITEM мы найдем значение CAPTAIN_ID. По этому номеру мы сможем определить имя и
номер телефона данного капитана.
12.15Домены
Домен4 (domain) — это множество значений, которые может принимать столбец.
Рассмотрим домены для столбцов таблицы ITEM. Предположим, что ITEM_ID и Quantity
(количество) - целые числа, Description - текст с максимальной длиной 25 символов, Dateln и
DateOut (даты выдачи и возврата) имеют тип «дата», a CAPTAIN_ID также является целым
3
4
Наиболее важной и сложной задачей при разработке баз данных является проектирование структуры таблиц. Начав
этот пример с уже готовых таблиц, мы опустили большую часть проекта.
Это определение значительно упрощено, с тем, чтобы сконцентрироваться на компонентах системы базы данных.
Более полное обсуждение доменов происходит в лекции __.
109
числом. Кроме задания физического формата, нам также необходимо решить, будут ли какие-либо
из доменов уникальными для данной таблицы. В нашем примере мы хотим, чтобы столбец
ITEM_ID был уникальным, поэтому необходимо указать это в определении домена. Поскольку
капитану может быть выдано более одной единицы инвентаря, столбец CAPTAIN_ ID не является
уникальным для таблицы ITEM.
Необходимо также задать домены для столбцов таблицы CAPTAIN. CAPTAIN_ID является целым
числом, а все остальные столбцы — это текстовые поля различной длины. CAPTAIN_ID должен
быть уникальным для таблицы CAPTAIN.
12.16Деловой регламент
Последний элемент схемы базы данных — это деловой регламент (business rules),
представляющий собой ограничения на возможные действия пользователя, которые необходимо
отразить в базе данных и ее приложениях. Примером делового регламента для колледжа Highline
может служить следующий набор правил:
1. Чтобы капитан мог получить на руки какой-либо инвентарь, у него должен быть местный
телефон.
2. Ни за одним капитаном не должно числиться более семи футбольных мячей.
3. По окончании каждого семестра капитаны обязаны возвратить весь инвентарь »в течение
пяти дней.
4. Капитан не может получить на руки новый инвентарь, если у него имеется задолженность
по ранее взятому инвентарю.
Деловой регламент является важной частью схемы, поскольку он задает такие ограничения на
возможные значения данных, которые должны выполняться в любом случае, независимо от того,
каким образом изменения достигают ядра СУБД. Не важно, что является источником запроса на
изменение данных — пользователь формы, запрос на обновление/чтение или прикладная
программа: СУБД должна позаботиться о том, чтобы эти изменения не нарушили никаких правил.
К сожалению, реализация делового регламента осуществляется в различных СУБД поразному. В Access 2002 некоторые правила могут задаваться в схеме и выполняться
автоматически. В таких продуктах, как SQL Server и Oracle, деловой регламент реализуется с
помощью так называемых хранимых процедур (stored procedures). В некоторых случаях СУБД
оказывается неспособной реализовать выполнение требуемых правил, и их приходится
закладывать в прикладные программы.
12.17Создание таблиц
Следующим шагом после разработки схемы базы данных является создание таблиц. Для
этого используются специализированные средства, предоставляемые СУБД. Имя каждого столбца
создаваемой таблицы указывается в столбце Field Name (Имя поля), а тип данных задается в
столбце Data Type (Тип данных). В столбце Description (Описание), не обязательном к
заполнению, даются описания столбцов таблицы и комментарии. Дополнительные данные по
каждому столбцу - количество символов, формат, заголовок и прочее - указываются в полях ввода
группы Field Properties (Свойства поля), расположенной в нижней части окна. Обратите внимание,
что свойство Indexed (Индексируется) в нижней части окна установлено в значение Yes (No
Duplicates), что означает, что для столбца ITEM_ID должен быть создан индекс из уникальных
значений. Таблица CAPTAIN создается аналогичным образом.
12.18Определение связей
110
Связь между таблицами CAPTAIN и ITEM имеет вид 1:N, что изображается на схеме путем
помещения ключа таблицы CAPTAIN в таблицу ITEM. Столбец, играющий ту же роль, что и
столбец CAPTAIN_ID в таблице ITEM, называется иногда внешним ключом (foreign key),
поскольку он является ключом таблицы, внешней по отношению к той таблице, в которой он
находится. При создании форм, запросов и отчетов СУБД может оказать большую помощь
разработчику, если она знает, что столбец CAPTAIN_ID в таблице ITEM является внешним
ключом таблицы CAPTAIN. В различных СУБД статус внешнего ключа объявляется по-разному.
В Microsoft Access для этого рисуется связь между ключом и внешним ключом. Столбец
CAPTAIN_ID основной таблицы (CAPTAIN) соответствует столбцу CAPTAIN_ID в связанной с
ней таблице (ITEM).
Одним из преимуществ объявления связи для СУБД является то, что когда данные из
столбцов двух таблиц считываются в форму, запрос или отчет, СУБД знает, как связаны строки
этих таблиц. Хотя эту связь можно указать для каждой конкретной формы, запроса или отчета,
однократное объявление экономит время и снижает вероятность ошибок. На прочие элементы в
окне Edit Relationship (Редактировать связь) мы пока не будем обращать внимания: о них вы
узнаете в ходе дальнейшего изложения. Когда определены таблицы, столбцы и связи, следующим
шагом является построение компонентов приложения.
12.19Компоненты приложения
Приложение базы данных состоит из форм, запросов, отчетов, меню и прикладных программ. Как
показано на рис. 2.1, формы, запросы и отчеты можно создавать с помощью средств,
поставляемых в комплекте с СУБД. Прикладные программы должны быть написаны либо на
входном языке СУБД, либо на одном из стандартных языков и затем посредством СУБД
соединены с базой данных.
12.20Формы
Существуют три различных представления данных, содержащихся в таблицах CAPTAIN и
ITEM. Первый вид данных представлен в табличном формате. Щелкнув мышью на знаке «плюс»,
имеющемся в начале каждой строки, пользователь может увидеть записи из таблицы ITEM,
связанные с конкретной строкой таблицы CAPTAIN.
Второй вид представления - в виде формы для ввода данных (data entry form). В этой форме в
каждый момент времени отображаются данные для одного капитана. Неопытные пользователи,
скорее всего, найдут это представление более простым в использовании, чем табличный формат.
К странице регистрации капитанов можно обращаться через Интернет или интрасеть, используя
браузер Microsoft Internet Explorer. Для этого страница должна храниться на web-сервере, подобном Internet Information Server. На данный момент следует просто знать, что такие формы
можно создавать с помощью средств, входящих в состав Access 2002.
Табличное представление автоматически генерируется Access 2002 для каждой таблицы,
определенной в схеме базы данных. Формы для ввода данных, однако, должны создаваться с
помощью генераторов форм. В качестве источника данных для новой формы заявлена таблица
CAPTAIN. Access выводит окно, называемое списком полей (field list), в котором перечислены все
столбцы таблицы CAPTAIN. Пользователь перетащил (drag-n-drop) поле Captain Name из списка
полей в форму. В ответ на это Access создал метку с названием CaptainName и поле ввода, куда
будут вводиться значения CaptainName. Теперь поле ввода привязано (bound) к столбцу
CaptainName таблицы CAPTAIN. Другие столбцы таблицы привязываются аналогичным образом;
столбцы таблицы ITEM привязываются к форме с помощью средства, называемого субформой
(subform). В Access имеется также мастер форм, позволяющий создавать формы.
111
12.21Процесс разработки базы данных
Многие тома были посвящены разработке информационных систем вообще и приложений
баз данных в частности, поэтому здесь нам нет нужды сколько-нибудь глубоко обсуждать
процессы системной разработки. Мы лишь кратко рассмотрим процессы, используемые для
разработки баз данных и их приложений.
12.22Общие стратегии
База данных — это модель пользовательской модели деловой активности. Поэтому, для
того чтобы построить эффективную базу данных и ее приложения, команда разработчиков должна
ясно представить себе пользовательскую модель. Для этого команда строит модель данных,
идентифицирующую объекты, которые должны храниться в базе данных, и определяет их
структуру и связи между ними. Это понимание должно быть достигнуто на ранней стадии
процесса разработки путем опроса пользователей и составления технического задания (statement
of requirements). Большинство таких технических заданий включают использование прототипов
(prototypes) — шаблонных баз данных и приложений, представляющих различные аспекты
создаваемой системы.
Есть две общих стратегии разработки баз данных: сверху вниз и снизу вверх.
Разработка сверху вниз (top-down database development) идет от общего к частному. Она
начинается с изучения стратегических целей организации, способов, при помощи которых эти
цели могут быть достигнуты, требований к информации, которые должны быть удовлетворены
для достижения этих целей, и систем, необходимых для предоставления такой информации.
Результатом такого исследования является абстрактная модель данных.
Отталкиваясь от этой общей модели, команда разработчиков двигается «вниз», к всё более и более
подробным описаниям и моделям. Модели промежуточного уровня также постоянно
детализируются, пока не воплотятся в конкретные базы данных и их приложения. Одно или более
из этих приложений берется затем в разработку. В конце-концов вся высокоуровневая модель
данных трансформируется в низкоуровневые модели, после чего реализуются все указанные
системы, базы данных и приложения.
При разработке снизу вверх (bottom-up database development) уровень абстракции
меняется в обратном направлении: исходным пунктом является необходимость в конкретной
системе. Способ выбора первой системы варьируется от организации к организации. В одних
организациях приложение выбирается правлением, в других пользователи могут выбирать его
самостоятельно, в третьих побеждает мнение того, кто в администрации громче всех кричит.
Так или иначе, для разработки выбирается конкретная система. Команда разработчиков
затем составляет техническое задание, рассматривая выходы и входы существующих
компьютерных систем, анализируя формы и отчеты, используемые в существующих системах с
ручной записью, и опрашивая пользователей с целью определения их потребностей в новых
отчетах, формах и запросах, а также других требований. Исходя из этого всего, команда
программистов разрабатывает информационную систему. Если система включает в себя базу
данных, команда на основании технического задания строит модель данных, а имея модель
данных, она проектирует и реализует базу данных. Когда создание данной системы завершается,
запускаются другие проекты, целью которых является построение дополнительных
информационных систем.
Сторонники разработки сверху вниз утверждают, что этот подход имеет преимущество
перед разработкой снизу вверх, поскольку модели данных (и соответствующие им системы)
строятся с глобальной перспективой. Они считают, что такие системы гораздо лучше
взаимодействуют между собой, являются более согласованными и требуют намного меньше
переделок.
Сторонники разработки снизу вверх говорят, что такой подход работает быстрее и
сопряжен с меньшим риском. Они утверждают, что моделирование сверху вниз выливается в
большое количество трудновыполнимых исследований и что процесс планирования часто заходит
112
в тупик. Хотя моделирование снизу вверх не обязательно имеет своим результатом оптимальный
набор систем, тем не менее, с его помощью можно быстро создать работающую систему. Такие
системы начинают давать прибыль гораздо быстрее, чем системы, смоделированные сверху вниз,
и это более чем компенсирует любые переделки и модификации, которые придется сделать, чтобы
настроить систему на глобальную перспективу.
В этой лекции описываются средства и способы, которые можно использовать при любом
стиле системной разработки. Например, хотя и модель «сущность—связь», и семантическая
объектная модель работают при разработке как сверху вниз, так и снизу вверх, модель
«сущность—связь» более эффективна при разработке сверху вниз, а семантическая объектная модель — при разработке снизу вверх.
12.23Моделирование данных
Как уже говорилось, наиболее важная цель на стадии разработки технического задания это создание модели данных пользователя (user data model), или моделирование данных (data
modeling). Как бы это ни делалось - сверху вниз или снизу вверх, - это включает в себя опрос
пользователей, документирование требований и построение модели данных и прототипов на
основе этих требований. Такая модель показывает, какие объекты должны храниться в базе
данных, и определяет их структуру и связи между ними.
Рассмотрим, например, список заказов, выполненных продавцом за определенный период
времени. Чтобы приложение базы данных могло выдать такой отчет № 1, база данных должна
содержать информацию, представленную в этом отчете, поэтому разработчики базы данных
должны исследовать этот отчет и на его основании определить, какие данные должны храниться в
базе. В нашем случае должны быть данные о продавцах (имя и регион) и данные о заказах
(компания, дата заказа и количество товара).
Разработка баз данных осложняется тем, что требований может быть несколько и они обычно
перекрываются. Отчет № 2 также содержит данные о продавцах, но вместо заказов в нем
перечислены комиссионные. Глядя на этот отчет, мы можем предположить, что существуют
различные типы заказов и для каждого из них определен свой процент комиссионных.
Заказы, перечисленные в отчете № 2, каким-то образом связаны с заказами,
перечисленными в отчёте № 1, но каким именно, остается не слишком ясным. Команда
разработчиков должна определить эти связи, делая выводы из отчетов и форм, интервьюируя
пользователей, используя собственные знания по данному вопросу и другие источники.
12.24Моделирование данных как делание выводов
Когда пользователи говорят, что им нужны формы и отчеты с определенными данными и
структурами, это подразумевает, что у них в голове имеется некая модель, представляющая вещи в
их мире. Однако пользователи могут быть не в состоянии точно описать эту модель. Если бы
разработчик спросил типичного пользователя: «Как вы себе представляете структуру модели
данных, касающихся продавцов?», то мир пользователя выглядел бы по меньшей мере
загадочным, поскольку большинство пользователей не мыслят такими категориями.
Вместо того чтобы задавать подобные вопросы, разработчики должны из высказываний
пользователя о формах и отчетах делать выводы о структуре и связях объектов, которые должны
храниться в базе данных. Затем разработчики воплощают эти выводы в модели данных, которая
трансформируется в проект базы данных, который, в свою очередь, реализуется при помощи
СУБД. Затем конструируются приложения, генерирующие отчеты и формы для пользователей.
Таким образом, построение модели данных - это процесс делания предположений. Отчеты
и формы напоминают тени на стене. Пользователи могут описать тени, но не могут описать
формы тел, отбрасывающих эти тени. Поэтому разработчикам приходится делать предположения,
решать обратную задачу, и реконструировать из этих теней структуры и связи.
113
Этот процесс является, к сожалению, в большей степени искусством, чем наукой. Можно
изучить все средства и способы моделирования данных (фактически эти средства и способы
являются предметом разговора в следующих двух главах), но их использование представляет
собой искусство, которое требует опыта, направляемого интуицией.
Качество модели является важным аспектом. Если документированная модель данных
адекватно отображает модель данных, присутствующую в воображении пользователя, есть
отличный шанс, что разработанные на ее основании приложения будут отвечать потребностям
пользователей. Если же пользовательская модель данных отображена в документированной
модели неадекватно, то приложение вряд ли приблизится к тому, что действительно нужно пользователям.
12.25Моделирование в многопользовательских системах
Процесс моделирования данных еще больше усложняется в многопользовательских
коллективных и организационных базах данных, поскольку различные пользователи могут
представлять себе различные модели данных. Эти модели могут оказаться несогласованными,
хотя в большинстве случаев несоответствия между ними могут быть устранены. Например,
пользователи могут употреблять один и тот же термин для разных вещей или различные термины
для одной и той же вещи.
Но иногда имеющиеся различия не дают возможности согласованного решения. В таких
случаях разработчик базы данных должен документировать эти различия и помочь пользователям
разрешить их, а это, как правило, означает, что некоторым людям придется изменить свой взгляд
на мир.
12.26Недоразумения по поводу термина «модель»
Существуют два альтернативных средства для построения моделей данных: модель
«сущность—связь» и семантическая объектная модель. Обе модели представляют собой
структуры для описания и документирования требований пользователя к данным. Чтобы избежать
недоразумений, обратите внимание на различное использование термина модель. Команда разработчиков анализирует требования и строит пользовательскую модель данных, или модель
требований к данным (requirements data model). Эта модель является представлением требований
пользователя к структуре и связям объектов, которые должны храниться в базе данных. Для
создания пользовательской модели данных команда разработчиков использует средства, которые
называются моделью «сущность—связь» и семантической объектной моделью. Эти средства
состоят из языковых и изобразительных стандартов для представления пользовательской модели
данных. Их роль в разработке баз данных подобна той роли, которую выполняют алгоритмы и
псевдокод в программировании.
12.27Резюме
Компонентами системы базы данных являются база данных, СУБД и прикладные
программы, с которыми работают как пользователи, так и разработчики. База данных состоит из
данных, метаданных, индексов и метаданных приложения. Большинство современных баз данных
представляют данные в виде отношений, или таблиц, хотя не все отношения одинаково
желательны. Нежелательные отношения могут быть преобразованы в два или более желательных с
помощью процесса, называемого нормализацией. Метаданные часто хранятся в специальных
таблицах, которые называются системными таблицами.
Характеристики и функции СУБД можно сгруппировать в три подсистемы. С помощью
подсистемы средств проектирования определяется структура базы данных, приложений и их
114
компонентов. Функцией подсистемы обработки является материализация форм, отчетов и
запросов путем чтения или записи данных в базу. Ядро СУБД является посредником между двумя
другими подсистемами и операционной системой. Она принимает запросы, выраженные в терминах таблиц, строк и столбцов, и преобразует их в запросы на физическое чтение и запись.
Схема - это описание структуры базы данных. Она включает в себя описание таблиц, связей
и доменов, а также деловой регламент. Строки одной таблицы могут быть связаны со строками
других таблиц. В этой главе проиллюстрирована связь вида 1:N между двумя таблицами; как вы
увидите из следующей главы, есть и другие типы связей.
Домен - это множество значений, которые может иметь столбец. Мы должны указывать
домен для каждого столбца каждой таблицы.
Наконец, деловой регламент — это ограничения на виды деловой активности, которые
должны быть отражены в базе данных и ее приложениях.
Для создания табличных структур, определения связей и создания форм, запросов, отчетов
и меню используются средства, предоставляемые СУБД. СУБД также включают в себя средства
для взаимодействия с прикладными программами, написанными либо на входном языке СУБД,
либо на стандартных языках, таких как Java.
Поскольку база данных является моделью пользовательской модели деловой активности,
разработка базы данных начинается с изучения и записи этой модели. Иногда она выражается в
форме прототипов будущего приложения или компонентов приложения.
Два общих стиля разработки таковы: разработка сверху вниз, которая идет от общего к
частному, и разработка снизу вверх, которая идет от частного к общему. В первом случае
приложения разрабатываются с глобальной перспективой, зато во втором случае разработка идет
быстрее. Иногда используется комбинация этих двух подходов.
Модели данных конструируются путем делания выводов из высказываний пользователя.
Собираются формы, отчеты и запросы, и на их основании разработчики делают вывод о
структурах, существующих в воображении пользователей. Это необходимо, поскольку
большинство пользователей не способны непосредственно описать свои модели данных.
Моделирование данных может быть особенно затруднительным в многопользовательских
приложениях, где представления различных пользователей могут противоречить друг другу, и ни
один пользователь не может представить себе всю картину деловой активности.
Термин модель данных используется двояко: он может означать как модель
пользовательских представлений о данных, так и средства, используемые для описания этих
представлений.
13 Лекция № 13 Реляционная модель и нормализация. Функциональные
зависимости.
Реляционная модель важна по двум причинам. Во-первых, поскольку конструкции
реляционной модели имеют широкий и общий характер, она позволяет описывать структуры баз
данных независимым от СУБД образом Во-вторых, реляционная модель является основой почти
всех СУБД Таким образом, понимание принципов этой модели существенно
В этой лекции даются основы реляционной модели (relational model) и объясняются
фундаментальные принципы нормализации (normalization) Мы начнем с того факта, что не все
отношения одинаковы некоторые из них более предпочтительны, чем другие Нормализация - это
процесс преобразования отношения, имеющего некоторые недостатки, в отношение, которое этих
недостатков не имеет Что еще более важно, нормализацию можно использовать как критерий для
определения желательности и правильности отношений. Вопрос о том, что такое хорошо
структурированное отношение, был предметом многочисленных теоретических исследований
Термин нормализация обязан своим появлением одному из пионеров технологии баз данных, Э.
Ф Кодду (Е F Codd), который определил различные нормальные формы (normal forms) отношений.
115
В этой лекции мы обсудим нормализацию. Формальное, более тщательное исследование данного
вопроса можно найти в работе Дейта и Ульмана (С J. Date и J D Ullman)5
13.1 Реляционная модель
Отношение (relation) — это двумерная таблица. Каждая строка в таблице содержит
данные, относящиеся к некоторой вещи или какой-то ее части. Каждый столбец таблицы
описывает какой-либо атрибут этой вещи. Иногда строки называются кортежами (tuples), а
столбцы — атрибутами (attributes).
Термины отношение, кортеж и атрибут пришли из реляционной математики, которая
является теоретическим источником этой модели. Профессионалы MIS предпочитают употреблять
аналогичные термины файл (file), запись (record) и поле (field), а большинство пользователей
находят более удобными термины таблица (table), строка (row) и столбец (column). Все эти
термины сведены в таблицу 13.1.
Таблица 13.1. Эквивалентная терминология реляционной модели
Реляционная
модель
Отношение
Программист
Пользователь
Файл
Таблица
Кортеж (строка)
Атрибут
Запись
Поле
Строка
Столбец
Чтобы таблица была отношением, она должна удовлетворять определенным
ограничениям6. Во-первых, значения в ячейках таблицы должны быть одиночными - ни
повторяющиеся группы, ни массивы не допускаются7. Все записи в столбце должны быть одного
типа. Например, если третий столбец первой строки таблицы содержит номер сотрудника, то и во
всех остальных строках таблицы третий столбец также должен содержать номер сотрудника.
Каждый столбец имеет уникальное имя; порядок столбцов в таблице несуществен. Наконец, в
отношении не может быть двух одинаковых строк, и порядок строк не имеет значения.
В таблице 13.2 представлен пример отношения. Отношение имеет семь строк, в каждой из
которых четыре столбца. Если бы мы расположили столбцы в ином порядке (скажем, поместив
ТабельныйНомер в крайний левый столбец) или переставили бы строки (например, по
возрастанию значения столбца Возраст), мы получили бы эквивалентное отношение.
Таблица 13.2. Отношение СОТРУДНИК
Кортеж 1
Кортеж 2
Кортеж 7
Атрибут1
Имя
Андерсон
Деккер
Джексон
Гловер
Мур
Наката
Смит
Атрибут 2
Возраст
21
Атрибут 3
Пол
Ж
Атрибут 4
ТабельныйНомер
010110
22
22
21
19
20
19
М
М
Ж
М
Ж
М
010100
101000
201100
111100
111101
111111
Таблица 13.2 представляет отдельный экземпляр отношения. Обобщенный формат отношения СОТРУДНИК (Имя, Возраст, Пол, ТабельныйНомер) - называется структурой отношения, и
именно это большинство людей имеет в виду, используя термин отношение.
5
С J Date, An Introduction to Database Systems, Sixth Edition (Reading, MA Addison-Wesley, 1994), и J D Ullman and
Jennifer Widom, A First Course in Database Systems (Upper Saddle River, NJ Prentice Hall, 1997)
6 E. F. Codd, «A relational Model of Data for Large Shared Databanks», Communications of the ACM, июнь , ШО, с 377-387
7 Это не означает, что значения должны быть фиксированной длины. Текстовое поле с записью переменной длины,
например, является вполне допустимым значением. Однако ячейка может содержать лишь одно такое значение.
116
Чтобы понять, что такое нормализация, мы должны определить два важных термина:
функциональная зависимость и ключ.
13.2 Функциональные зависимости
Функциональная зависимость (functional dependency) — это связь между атрибутами.
Предположим, что если мы знаем значение одного атрибута, то можем вычислить (или найти)
значение другого атрибута. Например, если нам известен номер счета клиента, то мы можем
определить состояние его счета. В таком случае мы можем сказать, что атрибут
СостояниеСчетаКлиента функционально зависит от атрибута НомерСчетаКлиента.
Говоря более общим языком, атрибут Y функционально зависит от атрибута X, если
значение X определяет значение Y. Другими словами, если нам известно значение X, мы можем
определить значение Y.
Уравнения выражают функциональные зависимости. Например, если мы знаем цену и
количество приобретенного товара, мы можем определить стоимость покупки по следующей
формуле:
Стоимость = Цена * Количество
В этом случае мы могли бы сказать, что атрибут Стоимость функционально зависит от
атрибутов Цена и Количество.
Функциональные зависимости между атрибутами в отношении обычно не выражаются
уравнениями. Пусть, например, каждому студенту присвоен уникальный идентификационный
номер, и у каждого студента есть одна и только одна специальность. Имея номер студента, мы
можем узнать его специальность, поэтому атрибут Специальность функционально зависит от
атрибута НомерСтудента. Или рассмотрим компьютеры в вычислительной лаборатории. Каждый
компьютер имеет конкретный размер основной памяти, поэтому атрибут Объем Памяти
функционально зависит от атрибута СерийныйНомерКомпьютера.
В отличие от случая с уравнением, такие функциональные зависимости нельзя разрешить
при помощи арифметики; вместо этого они хранятся в базе данных. Фактически, можно
утверждать, что базу данных стоит иметь только ради хранения и выдачи функциональных
зависимостей.
Функциональные зависимости обозначаются следующим образом:
НомерСтудента > Специальность
СерийныйНомерКомпьютера > ОбъемПамяти
Первое выражение читается так: «атрибут НомерСтудента функционально определяет атрибут
Специальность», «атрибут НомерСтудента определяет атрибут Специальность» или «атрибут
Специальность зависит от атрибута НомерСтудента». Атрибуты по левую сторону от стрелки
называются детерминантами (determinants).
Как уже говорилось, если номер студента определяет специальность, то каждому номеру студента
соответствует только одна специальность. Между тем, одной и той же специальности может
соответствовать более одного номера студента. Пусть студент под номером 123 специализируется
на бухгалтерском учете. Тогда для любого отношения, где присутствуют столбцы НомерСтудента
и Специальность, выполнится условие: если НомерСтудента = 123, то Специальность - БухгалтерскийУчет. Обратное, однако, неверно: если Специальность = БухгалтерскийУчет, то
атрибут НомерСтудента может принимать различные значения, так как на бухгалтерском учете
может специализироваться много студентов. Следовательно, мы можем сказать, что связь
атрибутов НомерСтудента и Специальность имеет вид N:l. В общем случае можно утверждать, что
если А определяет В, связь между значениями А и В имеет вид N:l.
В функциональные зависимости могут быть вовлечены группы атрибутов. Рассмотрим
отношение ОЦЕНКИ (НомерСтудента, Дисциплина, Оценка). Комбинация номера студента и
дисциплины определяет оценку. Такая функциональная зависимость записывается следующим
образом:
117
(НомерСтудента, Дисциплина) > Оценка
Заметьте, что для определения оценки требуется как номер студента, так и дисциплина. Мы
не можем разделить эту функциональную зависимость, поскольку ни номер студента, ни
дисциплина не определяют оценку сами по себе.
Обратите внимание на следующее различие. Если X > (Y, Z), то X > Y и X > Z. Например,
если НомерСтудента > (ИмяСтудента, Специальность), то НомерСтудента > ИмяСтудента и
НомерСтудента > Специальность. Но если (X, Y) > Z, то в общем случае неверно, что X > Y или X
> Z. Следовательно, если (НомерСтудента, Дисциплина) > Оценка, то ни номер студента, ни
дисциплина как таковые оценку не определяют.
13.3 Ключи
Ключ (key) — это группа из одного или более атрибутов, которая уникальным образом
идентифицирует строку. Рассмотрим отношение СЕКЦИЯ (рис. 5.3), имеющее атрибуты
НомерСтудента, Секция и Плата. Строка этого отношения содержит информацию о том, что
студент посещает определенную секцию за определенную плату. Предположим, что студент
одновременно не может посещать более одной секции. В этом случае значение атрибута
НомерСтудента идентифицирует единственную строку, поэтому данный атрибут является
ключом.
СЕКЦИЯ (НомерСтудента, Секция, Плата)
Ключ: НомерСтудента Sample Data
НомерСтудента Секция
Плата
100
Лыжи
200
150
Плавание
50
175
Теннис
50
200
Плавание
50
Рис. 5.3. Отношение СЕКЦИЯ
Ключи могут также составляться из нескольких атрибутов. Например, если студентам
разрешено одновременно посещать более одной секции, то один и тот же номер студента может
появиться в разных строках таблицы, поэтому атрибут НомерСтудента не будет уникальным
образом определять строку. Для этого потребуется какое-то сочетание атрибутов; возможно, это
будет комбинация (НомерСтудента, Секция).
Попутно отметим, что в предыдущем абзаце затронут тонкий, но весьма важный аспект,
Являются ли атрибуты ключами и являются ли они функционально зависимыми - это
определяется не абстрактным набором правил, а моделями, присутствующими в воображении
пользователей, а также деловым регламентом организации, использующей базу данных. Что в
приведенном выше примере является ключом - НомерСтудента, комбинация (НомерСтудента,
Секция) или какое-то еще сочетание атрибутов, - целиком и полностью определяется тем, как
представляют себе ситуацию люди, работающие в организации, которая использует базу данных.
Ответы на эти вопросы мы должны получить от пользователей По ходу дальнейшего изложения
имейте в виду, что все наши предположения о функциональных зависимостях, ключах,
ограничениях и тому подобных вещах определяются моделями в воображении пользователей.
Допустим, в ходе опроса пользователей мы выяснили, что студентам разрешено
одновременно быть записанными в несколько спортивных секций. Эта ситуация отражена в
отношении СЕКЦИИ (рис. 5.4). Как мы отметили, НомерСтудента не является ключом этого
отношения. В самом деле, студент с номером 100 посещает секцию гольфа и секцию лыж, и
атрибут НомерСтудента со значением 100 появляется в двух различных строках. Фактически, для
этого отношения ни один атрибут сам по себе не является ключом, то есть ключ должен состоять
из двух или более атрибутов.
НомерСтудента Секция
Плата
118
100
Лыжи
200
100
Гольф
65
150
Плавание
50
175
Сквош
50
175
Плавание
50
200
Плавание
50
200
Гольф
65
Рис. 5.4. Отношение СЕКЦИИ
Рассмотрим, какие комбинации из двух атрибутов возможны для данной таблицы. Таких
комбинаций имеется три: (НомерСтудента, Секция), (НомерСтудента, Плата) и (Секция, Плата).
Является ли какая-либо из этих комбинаций ключом? Чтобы быть ключом, группа атрибутов
должна уникальным образом идентифицировать строку. Опять-таки, ответы на подобные вопросы
мы должны получить от пользователей. Наше решение не должно основываться на выборочных
данных, подобных тем, которые приведены на рис. 5.4, или на наших собственных
предположениях.
Допустим, поговорив с пользователями, мы пришли к выводу, что плата за абонемент в
различных секциях может совпадать. Поскольку это так, комбинация (НомерСтудента, Плата) не
может уникальным образом определить строку. Например, студент с номером 100 может посещать
две различных секции, каждая из которых стоит $200. Это означает, что комбинация (100, $200)
возникла бы в таблице дважды, поэтому такая комбинация не может быть ключом.
Может ли быть ключом сочетание (Секция, Плата)? Может ли комбинация (Лыжи, $200)
уникальным образом определить строку? Нет, не может, поскольку секцию лыж может посещать
много студентов. А как насчет сочетания (Номер-Студента, Секция)? Имея те сведения, которые
мы получили от пользователей, можно ли сказать, что комбинация значения атрибутов
НомерСтудента и Секция уникальным образом определяет строку таблицы? Да, можно, пока от
нас не требуется вести записи об истории посещения секций студентом. Иными словами, должна
ли эта таблица содержать сведения только о тех секциях, которые студент посещает на данный
момент, или же в ней должны быть записи о секциях, которые студент посещал ранее?
И снова, чтобы ответить на этот вопрос, мы должны обратиться к пользователям.
Предположим, мы выяснили, что необходимо хранить сведения только о посещаемых в
настоящий момент секциях. Тогда комбинация (НомерСтудента, Секция) может уникальным
образом определить строку отношения и, следовательно, эта комбинация является ключом
данного отношения. Если бы пользователи указали, что должны также храниться записи о
секциях, которые посещались в прошлом, то отношение на рис. 5.3 имело бы дублирующиеся
строки. Поскольку это недопустимо по определению отношения, нам пришлось бы добавить
другие атрибуты, например атрибут Дата.
Это приводит нас к важному заключению. Каждое отношение имеет минимум один ключ.
Это утверждение должно быть верным, поскольку ни одно отношение не может иметь одинаковых
строк, и, следовательно, в крайнем случае ключ будет состоять из всех атрибутов отношения.
13.4 Резюме
Реляционная модель важна по двум причинам: во-первых, с ее помощью можно описывать
структуры баз данных независимым от СУБД образом, а во-вторых, эта модель лежит в основе
значительной части современных СУБД. Критерием правильности и желательности отношений
может служить нормализация.
Отношение — это двумерная таблица, в ячейках которой записаны одиночные значения.
Все значения в одном столбце принадлежат к одному и тому же типу; каждый столбец имеет
уникальное имя; порядок следования столбцов несуществен. Столбцы называются также
атрибутами. В отношении не может быть двух одинаковых строк, а порядок следования строк
несуществен. Строки называются также кортежами. Термины таблица, файл и отношение
являются синонимами; то же самое можно сказать о терминах столбец, поле и атрибут; термины
строка, запись и кортеж также синонимичны.
119
Функциональная зависимость — это связь между атрибутами. Y функционально зависит от
X, если значение X определяет значение Y. Детерминантом называется группа из одного или
нескольких атрибутов, находящаяся с левой стороны функциональной зависимости. Например,
если X определяет Y, то X является детерминантом. Ключ — это группа из одного или нескольких
атрибутов, которая однозначно определяет кортеж.
Каждое отношение имеет минимум один
ключ; поскольку каждая строка уникальна, в самом крайнем случае ключом является
совокупность всех атрибутов отношения. Хотя ключ всегда уникален, детерминант
функциональной зависимости может таковым и не быть. Являются ли атрибуты ключами и
являются ли они функционально зависимыми — это определяется не абстрактным набором
правил, а тем смыслом, который вкладывают пользователи в эти атрибуты.
В некоторых отношениях в результате обновления данных возникают нежелательные
последствия, называемые аномалиями модификации. Аномалия удаления — это ситуация, когда
удаление одной строки из отношения вызывает потерю информации о двух или более фактах.
Аномалией вставки называется ситуация, когда реляционная структура вынуждает добавлять
информацию одновременно о двух фактах. Аномалии могут быть устранены путем разбиения
исходного отношения на два.
Существует много типов аномалий модификации. Отношения можно классифицировать по типам
аномалий, которые ими ликвидируются. Типы, на которые подразделяются отношения в рамках
этой классификации, называются нормальными формами.
По определению каждое отношение находится в первой нормальной форме. Отношение
находится во второй нормальной форме, если каждый из его неключевых атрибутов зависит от
всего ключа. Отношение находится в третьей нормальной форме, если оно находится во второй
нормальной форме и не имеет транзитивных зависимостей. Отношение находится в нормальной
форме Бойса-Кодда, если каждый его детерминант является ключом-кандидатом. Отношение
находится в четвертой нормальной форме, если оно находится в нормальной форме Бойса-Кодда и
не имеет многозначных зависимостей. Определение пятой нормальной формы не имеет
интуитивной интерпретации, и поэтому мы его не приводили.
Отношение находится в доменно-ключевой нормальной форме, если каждое ограничение,
накладываемое на отношение, является логическим следствием определения доменов и ключей.
Под ограничением здесь понимается любое условие, определяющее возможные статические
значения атрибутов, истинность которого может быть проверена. Домены, как они определены
нами, имеют физическую и семантическую составляющие. В контексте ДКНФ, однако, под
доменом подразумевается только физическое описание.
Неформальная интерпретация ДКНФ заключается в том, что каждое отношение должно иметь
только одну тему. Например, в отношении может содержаться информация о профессорах или о
студентах, но не о тех и других одновременно.
Нормализация - это процесс анализа отношений. Отношения можно также строить
синтетическим путем, рассматривая связи между атрибутами. Если два атрибута функционально
определяют друг друга, между ними имеется связь вида «один к одному». Если один из двух
атрибутов функционально определяет второй, между этими атрибутами имеется связь «многие к
одному». Если ни один из двух атрибутов не определяет другой, между этими атрибутами имеется
связь «многие ко многим».
В некоторых случаях нормализация нежелательна. Всякий раз, когда исходная таблица
разбивается на две или более новых, возникают ограничения ссылочной целостности. Если
расходы на дополнительную обработку двух таблиц И обеспечение ссылочной целостности
превышают выгоду от устранения аномалий модификации, нормализация не рекомендуется.
Вдобавок в некоторых случаях создание повторяющихся столбцов предпочтительнее обычных
способов нормализации, а в других случаях для повышения производительности вводится
преднамеренная избыточность
14 Лекция № 14 Язык SQL. Основные операторы языка SQL
120
14.1 Язык SQL
SQL, или язык структурированных запросов, - на сегодняшний день наиболее важный из
языков манипулирования реляционными данными. Он рекомендован Американским
национальным институтом стандартов (ANSI) в качестве стандартного языка манипулирования
реляционными базами данных и используется как язык доступа к данным многими
коммерческими СУБД, включая DB2, SQL/DS, Oracle, INGRES, SYBASE, SQL Server, dBase for
Windows, Paradox, Microsoft Access и многие другие. Благодаря своей популярности SQL стал
стандартным языком для обмена информацией между компьютерами. Поскольку существует
версия SQL, которая может работать почти на любом компьютере и операционной системе,
компьютерные системы способны обмениваться данными, передавая друг другу запросы и ответы
на языке SQL.
Разработка SQL начиналась в середине 70-х годов прошлого века в исследовательском центре IBM в Сан-Хосе, и изначально язык носил название SEQUEL (сиквел). Было выпущено
несколько версий SEQUEL, и в 1980 году продукт был переименован в SQL. С тех пор, помимо
IBM, многие производители присоединились к разработке программных продуктов для SQL.
Институт ANSI взял на себя работу по поддержке SQL и периодически публикует обновленные
версии стандарта SQL. В этой главе обсуждается ядро SQL в том виде, как оно описано в
стандарте ANSI 1992 г., который часто обозначают как SQL928. Последняя версия стандарта,
SQL3, содержит расширения языка для объектно-ориентированного программирования.
Конструкции и выражения в конкретной реализации SQL (например, в Oracle или SQL
Server) могут немного отличаться от ANSI-стандарта. Частично это обусловлено тем, что многие
коммерческие СУБД были разработаны до того, как появилось соглашение о стандарте, а также
тем, что производители закладывали в свои продукты дополнительные возможности с целью
получить преимущество в конкурентной борьбе. Исходя из рыночной перспективы, одной лишь
поддержки стандарта ANSI порою считалось недостаточно для обеспечения привлекательности
продукта.
Команды языка SQL могут использоваться интерактивно как язык запросов, а также могут
быть встроены в прикладные программы. Таким образом, SQL не является языком
программирования (как, например, COBOL); он скорее представляет собой подъязык данных (data
sublanguage) или язык доступа к данным (data access language), встраиваемый в другие языки.
В этой лекции представлены интерактивные операторы SQL, которые, будучи встроенными
в прикладные программы, требуют настройки и модификации. Здесь рассматриваются операторы
манипулирования данными и операторы определения данных.
SQL - это язык, ориентированный на преобразования, который принимает на входе одно
или несколько отношений и выдает на выходе одно отношение Результат каждого SQL-запроса
представляет собой отношение; даже если результатом является отдельное число, это число
считается отношением, у которого одна строка и один столбец. Таким образом, подобно
реляционной алгебре, язык SQL является замкнутым.
14.2 Основные операторы языка SQL
Операторы языка SQL используются во всех интерактивных интерпретаторах языка SQL
(Informix-SQL, SQL-Plus, SQL-Query и др.). Для каждого инструмента характерны определенные
особенности использования SQL, которые описаны в соответствующей документации.
14.3 Основные соглашения по языку SQL
8
International Standards Organization Publication ISO/IEC 9075 1992, Database Language SQL
121
Формат записи операторов SQL свободный. Можно писать все подряд на одной строке,
один оператор на нескольких строках, ключевые слова в операторах можно разделять
произвольным количеством пробелов и комментариев. Никакими значками (типа ;) операторы
разделять не нужно. Окончание операторов определяется по контексту.
Примечание. Если вы записываете утверждения SQL не в программе, а в среде интерпретатора,
то разделять операторы точкой с запятой (;) необходимо.
Весь набор ключевых слов языка SQL зарезервирован, их нельзя занимать для других
целей.
Интерпретатору языка безразлично, прописными или строчными буквами пишутся
операторы. Он их не различает.
Комментарии обозначаются знаками { комментарий } или знаком -- (два знака минус) до
конца строки.
14.4 Группы операторов языка SQL
SQL содержит 4 группы операторов:
операторы описания данных: CREATE, DROP, ALTER и др.
операторы задания прав доступа в БД: GRANT / REVOKE , LOCK/UNLOCK, SET LOCK
MODE
операторы защиты, восстановления данных и прочие операторы.
операторы манипуляции данными: INSERT, DELETE-, SELECT, UPDATE и др.
Их обзор предлагается ниже.
14.5 Операторы описания данных
Операторы описания данных предназначены для описания (создания), изменения описания
и уничтожения объектов БД.
В SQL различаются следующие виды объектов:
• база данных (database);
• таблица (table);
• столбец (column);
• индекс (index);
• вид (view);
• синоним (synonym).
Каждый объект имеет собственное имя - идентификатор. Каждый объект имеет владельца,
т. е. того пользователя, который его создал. Имя объекта можно уточнять с помощью имени его
владельца (owner-name) в такой форме: Irina.tablel
Ниже приводятся примеры использования всех операторов описания данных. Полный же
их синтаксис можно найти в "Кратком справочнике по SQL".
14.6 Создание базы данных
CREATE DATABASE primer
В любой момент времени вы можете иметь доступ к объектам только одной, ТЕКУЩЕЙ
(CURRENT) базы данных. Оператор DATABASE делает новую БД текущей, закрывая при этом
доступ к объектам предыдущей текущей БД. Оператор CLOSE DATABASE просто закрывает
текущую БД.
122
Создаются таблицы kadr и fn, содержащие столбцы разных типов:
CREATE TABLE kadr (
Num
INT,
tabnom SERIAL,
fio CHAR(20) UNIQUE,
zp MONEY(16,2),
birth
DATE,
datf
DATETIME year TO minute)
CREATE TABLE fn ( num int, namec char(20))
В уже существующей таблице мы можем поменять тип столбца, добавить новый, уничтожить
старый:
ALTER TABLE kadr ADD (place CHAR(20) BEFORE zp), DROP(birth) ALTER TABLE items
MODIFY (manu_code char(4))
Изменение структуры таблицы приводит к физическому преобразованию данных в ней.
Если изменен тип столбца, то данные в нем преобразуются в новый тип, и если это невозможно
осуществить, то оператор ALTER завершается с кодом ошибки, а таблица остается неизменной.
View-виртуальная таблица базируется на существующих таблицах:
CREATE VIEW vtable AS SELECT tabnom, fio, birth FROM kadr WHERE zp< 1000
# создано view-псевдотаблица из трех столбцов, содержащая строки из таблицы kadr, в которых
зарплата (zp) меньше 1000 рублей.
Виртуальная таблица ведет себя точно так же, как настоящая таблица, только место на
диске под нее не отводится, поскольку данные, лежащие в ней, на самом деле хранятся в таблице,
на которую этот view указывает.
Индекс - дополнительная структура к столбцам таблицы, необходимость в котором
продиктована возможностью ускорения поиска значений в столбце:
CREATE UNIQUE INDEX indx ON kadr (tabnom)
# создан индекс для столбца tabnom из таблицы kadr. Индекс уникальный, значит, в столбце не
могут появиться одинаковые значения.
Мы можем физически упорядочить таблицу в соответствии
кластеризованной таблице SELECT работает значительно быстрее:
ALTER INDEX indx TO CLUSTER
с
индексом.
В
Имена столбцов в разных таблицах могут совпадать. Если в каком-либо операторе SQL
упоминаются два столбца с одинаковыми названиями, то их нужно уточнять именами таблиц, их
содержащих. Перед именем любого объекта можно (а иногда и необходимо) указать имя его
владельца - входное имя пользователя, который создал этот объект:
kadr.num
# столбец num из таблицы kadr
fn.num
# столбец num из таблицы fn
ivanov.tablei .n1
# столбец п1 из таблицы tablei, владельцем которой является ivanow
irina.table1.n1
# столбец п1 из другой (!) таблицы - таблицы table 1, владельцем
которой является irina
Синоним для имени таблицы используется для сокращения записи.
CREATE SYNONYM q1 FOR ivanov.tablei .n1
123
Теперь повсюду можно (хотя и не обязательно) вместо имени ivanov.table1.n1 использовать имя
q1.
Естественно, что любой созданный в БД объект можно уничтожить. Надо только помнить,
что операторы описания данных не откатываются назад, а потому если вы уничтожили таблицу,
или базу данных то это уже необратимо.
DROP VIEW vtable
# Уничтожается только view. С данными - в таблицах, на
которых он базировался ничего не происходит.
DROP TABLE kadr
# уничтожает таблицу вместе с данными.
DROP INDEX indx
DROP SYNONYM q1
DROP DATABASE primer # уничтожает базу вместе со всеми данными и системным
журналом
14.7 Операторы прав доступа
Выдавать и отнимать права доступа к таблице может владелец таблицы, Администратор
Базы Данных (имеющий DBA-права), а также пользователь, которому было выдано право
определять права (Оператором GRANT WITH GRANT OPTIONS):
REVOKE ALL ON customer FROM PUBLIC GRANT ALL ON customer TO ivanov, petrov WITH
GRANT OPTION
GRANT UPDATE(fname,lname,company, sity),SELECT ON customer TO PUBLIC
REVOKE CONNECT FROM sidorov, root REVOKE DBA FROM ivanov
Отобрать у вас права DBA (если вы, конечно, им являетесь) может только другой DBA.
На время транзакции (т. е. проводки) все измененные строки автоматически блокируются
системой от изменения (но не от просмотра). Вы можете явно закрыть на замок (lock) всю таблицу
целиком, тогда система не будет блокировать строки по отдельности. Вы можете блокировать
таблицу целиком не только от изменения, но и от просмотра:
BEGIN WORK LOCK TABLE kadr
UNLOCK TABLE kadr
LOCK TABLE kadr EXCLUSIVE
Если ваш оператор пытается сделать запись в блокированную другим пользователем
строку, то оператор завершается по ошибке. Вы можете установить для своей программы режим
"Ждать разблокирования строк":
SET LOCK MODE TO WAIT
14.8 Операторы выполнения и "отката" транзакций
В БД, не имеющей системного журнала, невозможно выполнение транзакций и
восстановление до текущей контрольной точки.
Тем не менее, наличие системного журнала у БД вызывает заметный рост накладных расходов и
замедление работы запросов. К тому же при активной работе с базой системный журнал быстро
"разбухает". За ним нужно следить и периодически очищать его:
14.9 Транзакция
BEGIN WORK
# начать транзакцию
# операторы
124
IF все нормально THEN COMMIT WORK
ELSE ROLLBACK WORK END IF
Если во время транзакции программа аварийно завершилась, то сервер БД автоматически сделает
откат назад, к состоянию БД до начала выполнения транзакции; по сути то же, что всегда делает
оператор ROLLBACK.
14.10Операторы манипуляции данными
Следующая группа операторов предназначена для манипулирования данными в таблицах. В нее
входят операторы выбора (SELECT) строк из таблицы (или таблиц), уничтожения (DELETE) строк
в таблице, вставки (INSERT) строк и изменения (UPDATE) значений в существующих в таблице
строках.
Оператор DELETE
Уничтожить в таблице kadr все строки, в которых номер подразделения равен 3, а фамилия
кончается на буквы "ин":
DELETE FROM kadr WHERE num=3 AND fio MATCHES "*ин"
В результате из списков будут вычеркнуты работники 3-го отдела "Галкин", "Малкин", "Малинин"
и т. п.
А этот оператор уничтожит ВСЕ строки в таблице kadr, владельцем которой является irina, но не
саму таблицу:
DELETE FROM irina.kadr.
Оператор SELECT
Первый пример находит в таблице kadr строку, в которой столбец tabnum=34. Из этой строки
берутся только 3 указанных столбца.
Второй пример выбирает ВСЕ строки из таблицы fn и все столбцы:
Третий пример выбирает фамилии работников из таблицы "кадры", а названия подразделений, в
которых они работают, из таблицы fn.
SELECT fio, place, zp FROM kadr WHERE tabnom=34
SELECT * FROM fn
SELECT kadr.fio, fn.namec WHERE kadr.num=fn.num
Оператор INSERT может вставить в таблицу одну строку, если используется в форме INSERT
INTO VALUES, а может вставить в таблицу целый набор строк, выбранных подзапросом SELECT
из другой таблицы:
INSERT INTO kadr VALUES (4,0,Тромыко",1000,"10/25/1976",NULL)
INSERT INTO customer VALUES (ps_customer.*)
# ps_customer -переменная типа RECORD - аналог структуры в
# языке С. Этот оператор вставляет значения элементов записи
# ps_customer в соответствующие поля таблицы customer
INSERT INTO kadr (tabnom, fio, num, place)
SELECT 0 , fio, 4, place FROM kadrold
WHERE num=3 AND fio IS NOT NULL
# последний оператор вставляет сразу несколько строк
Если мы хотим, чтобы при вставлении строки в столбец типа SERIAL автоматически
заносилось очередное значение счетчика, нужно вставлять в этот столбец константу 0.
125
Если не во все столбцы вставляемой строки вносится значение (как это сделано в третьем
операторе), то незаполненные столбцы заполняются значением NULL.
В операторах DELETE, UPDATE, SELECT может присутствовать WHERE-предложение, в
котором можно задать условия на строки, требующие обработки (соответственно уничтожить,
изменить или выбрать).
Оператор UPDATE
Меняет значения столбцов в строках, удовлетворяющих WHERE-условию:
UPDATE kadr SET fio="lvanov" WHERE тю="Иванов"
UPDATE fn1 SET nam_otd[1,4]=namec[5,8] WHERE
num BETWEEN 3 AND 5 OR namec IN ("ректорат","бухгалтерия")
В таблице fnl в подразделениях номер 3, 4, 5, а также в ректорате и бухгалтерии первые 4 символа
в имени подразделения будут заменены на подстроку поля namec из той же строки.
Предложение WHERE
Предложение WHERE может присутствовать в любом из операторов DELETE, UPDATE,
SELECT, когда нужно задать условия на строки, которые требуется обработать (соответственно
уничтожить, изменить или выбрать). Рассмотрим структуру и примеры использования
предложения WHERE.
В предложении WHERE пишется логическое условие, которое получается соединением с
помощью логических операторов AND, OR и NOT элементарных сравнений типа:
выражение1 < выражение2,
выражение1 >= выражение2 и т. п.,
а также элементарных сравнений специального вида:
column-name IS [NOT] NULL
выраж [NOT] BETWEEN выраж1 AND выраж2 выраж [NOT] IN (выраж1 ,... [,...])
Можно выяснить, подходит ли символьная строка под определенный шаблон или нет. Для
этого используются 2 операции сравнения по шаблону - LIKE и MATCHES:
симв-выражение MATCHES "шаблон"
симв-выражение LIKE "шаблон"
LIKE имеет более простой шаблон. В нем используются только 2 спецсимвола: "%"
замещает произвольное количество символов, "_" замещает ровно 1 символ. Все остальные
символы в шаблоне обозначают сами себя. Если мы хотим включить в шаблон "%" или "_",
отменив их специальный смысл, то перед ними надо поставить ESC-символ (по умолчанию это
"\"). Допустим, нам нужно выбрать из таблицы table7 все строки, в которых символьный столбец
stringl содержит символ "+", а предпоследняя буква в нем - S. Оператор выборки будет выглядеть
так: SELECT * FROM table7 WHERE stringl LIKE "%+%S_"
MATCHES использует такие спецсимволы шаблона, как: *, ?, [, ], ^, -.
* - заменяет любое количество символов;
? - заменяет один любой символ;
[...] - заменяет 1 символ из перечисленных в скобках, возможны указания "от и до" (-) и "не" (Л);
[аbН] - любой из символов a, b, H;
[^d-z] - любой символ, исключая d, e, f, g,..., у, z;
\ - отменяет спецсмысл спецсимволов *,?,[,].
126
Если вы хотите воспользоваться спецсимволами как обычными, примените escape-char.
Если escape-char="\", то \? обозначает просто символ ?, \* обозначает просто символ *, \\
обозначает просто символ \ . Зато знак кавычки (") внутри шаблона нужно обозначать двумя
кавычками ("").
Выбрать все данные о заказчиках, в названиях компаний которых вторая буква не лежит в
интервале от G до L, а третья буква с:
SELECT * FROM customer WHERE company МАТСЕS”?[^G-L]c*"
Если вы хотите:
сравнить выражение с результатом другого SELECT-оператора:
выраж_сравн {ALL | [ANY | SOME]} (SELECT-statement)
определить, принадлежит ли выражение результатам другого SELECT-оператора:
выраж JNOT] IN (SELECT-statement)
выяснить, выбрал ли хоть что-нибудь другой SELECT-оператор:
_[NOT] EXISTS (SELECT-statement) то применяйте условия с подзапросом.
Условия с подзапросом
SELECT fio FROM kadr WHERE zp=(SELECT MAX(zp) FROM kadr)
Здесь подзапрос возвращает единственное значение - максимальное значение зарплаты. А
внешний SELECT-оператор находит фамилии обладателей такой зарплаты:
SELECT fio, kod, org FROM zar WHERE den is not NULL and
city in (SELECT city FROM regiony WHERE region="West")
Здесь запрос выводит данные о руководителях, получивших финансирование и работающих в
регионе с условным названием West:
SELECT order_num,stock_rHjm,manu_code, totaLprice FROM items x WHERE totaLprice > (SELECT
2*M IN (totaLprice)
FROM items WHERE order_num=x.order_num)
Этот запрос (используя связанный подзапрос) выводит список всех изделий, чья общая
цена не менее чем в 2 раза превосходит минимальную цену изделий, перечисленных в этом же
заказе.
Вы можете соединять любое количество вышеперечисленных условий вместе, используя
логические операторы NOT, AND, OR.
Расширенные функции оператора SELECT
Предложения INTO, INTO TEMP, FROM. Выбрать все строки (нет предложения WHERE)
из таблицы kadr, взять в них все столбцы (вместо переселения столбцов стоит *), оставить только
различные строки (ключевое слово UNIQUE) и поместить результат во временную таблицу (INTO
TEMP) x, которая будет при этом создана с такими же столбцами, что и у kadr:
SELECT UNIQUE * FROM kadry INTO TEMP x
127
Выбирать можно из нескольких таблиц. При этом берутся все возможные комбинации
строк из первой таблицы со второй. Предположим, что в таблице tab1 6 строк, а в tab2 - 7 строк.
Результат нижеприведенного примера - таблица, содержащая 3 столбца и 7*6=42 строки:
SELECT tabl .a-tab2.b, tabl .a, tab2.b FROM tabl, tab2
Результирующую таблицу можно использовать по-разному: ее можно «закачать» (INTO
TEMP) во временную таблицу, ее можно отдать на обработку другому оператору (если выборку
осуществлял подзапрос), для нее можно создать курсор ("буфер" с указателем на текущую строку),
а можно положить её (INTO) в простую программную переменную (если выбрано не более одной
строки).
Выбранные строки можно упорядочить по возрастанию (убыванию) значения в столбце
(столбцах):
SELECT a,b,c,d+e FROM tabl ORDER BY b,c
SELECT a,b,c,d+e FROM tabl ORDER BY 2,3
В предложении ORDER BY вместо имени столбца можно указывать его порядковый номер
в списке выборки (select-list). Вышеприведенные операторы эквивалентны.
Поместить значения из столбцов в переменные (поскольку lname используется и как имя
переменной, и как имя столбца, то имя столбца предваряется знаком @:
SELECT customer_num, @lname,city INTO cnum,lname,town FROM customer
Агрегатные функции
К выбранным строкам можно применять агрегатные функции COUNT(*) - количество,
MAX(column) и MIN(column) - максимальное и минимальное значение в столбце,
SUM(column) - сумма всех значений в столбце, AVG(column) - среднее значение в столбце.
Поместить в переменную num количество строк в таблице orders, в которых столбец
customernum равен 101:
SELECT COUNTO INTO num FROM orders WHERE customer_num=101
Пример с использованием соединения таблиц. Находится среднее значение зарплаты,
превосходящей 3000 (столбец zp принадлежит одной из таблиц), при условии совпадения
столбцов place в двух таблицах:
SELECT AVG (zp) FROM table"! ,table2 WHERE tablei .place=table2.place and zp>3000
Группировка GROUP BY
Группировка используется для сброса группы (строк) в одну.
Результат запроса содержит одну строку для каждого множества строк, удовлетворяющих
WHERE-предложению и содержащих одно и то же значение в указанном столбце:
SELECT place, COUNTf), AVG(zp) FROM kadr GROUP BY place
Получить количество работающих и их среднюю зарплату по каждому месту:
SELECT place, COUNT(*), AVG(zp) FROM kadr GROUP BY 1
Эквивалентная запись
Предложение HAVING накладывает дополнительные условия на группу:
SELECT order_num, AVG(totaLpriece) FROM items
GROUP BY order_num HAVING COUNTf) > 2I
Этот запрос возвращает номера заказов и среднее значение total_price
в заявках для всех заказов, имеющих не менее двух заявок.
Внешнее соединение таблиц
128
Строки из таблицы, присоединенной внешним образом (на внешнее соединение указывает
ключевое слово OUTER), будут выбираться, несмотря! на то, удовлетворяют ли они условиям
WHERE предложения или нет. В некоторых случаях это полезно, когда у вас есть главная и
вспомогательная таблица и данные из главной таблицы вам нужно получить в любом случае.
Пример внешнего соединения:
SELECT company, order_num FROM customer с, OUTER orders о
WHERE c.customer_num=o customer_num
Запрос находит названия компаний и номера заказов, которые они послали. Если же
компания заказов не присылала, то ее название все равно будет выбрано, а номер заказа в этой
строке будет равен NULL. (А если бы мы запустили запрос без параметра OUTER, то названия
этих компаний вообще не попали бы в выборку - SQL для Informix.)
Сложные примеры манипуляции данными
Операторы манипуляции данными - самая мощная составляющая SQL.
В следующем примере ликвидируются одинаковые строки в таблице kadr.
select unique * from kadr into temp kd delete from kadr where 1=1 Insert into kadr select * from kd ^rop
table kd
В следующем примере информация в строках изменяется по значению ключа.
• Таблица b содержит (kl int, pole char(20)), причем все kl различны.
• В таблице kadr заменить kadr.place на b.pole в строках, где kadr.tabnom=b .kl:
SELECT b.kl, b.pole, num, place, zp, birth
FROM kadr, b WHERE kadr.tabnom=b.kl into temp kd
DELETE FROM kadr WHERE tabnom in (SELECT kl FROM b)
INSERT INTO kadr SELECT * FROM kd
DROP TABLE kd
Ту же самую операцию можно проделать с помощью одного оператора UPDATE,
использующего подзапрос:
UPDATE kadr SET
place=(select pole from b where kadr.tabnom=b.kl) WHERE tabnom IN (select kl from b)
В следующем примере информация в строках изменяется по значению ключа при
выполнении условий, наложенных на меняемые строки:
Таблица newtable______
fio
har_________cen
John способный $300
Piter коммунист______
Bob хороший____$25
Bob плохой
$15
Таблица oldtable
fio
... har_______ ... cen
John
бездарный
$600
…
__________
______
Piter
демократ
$45
Ronny
плохой_____
______
В таблице oldtable хранятся сведения о сотрудниках. На основе последних исследований
была составлена таблица newtable, с поправками к содержанию oldtable.
Строчка будет подменяться, если за новую информацию о сотруднике в таблице newtable
заплачено больше, чем за хранящуюся в oldtable:
UPDATE oldtable SET
(har,cen)=( (SELECT har.cen FROM newtable WHERE oldtable.fio=newtable.fio)) * WHERE fio IN
(SELECT fio FROM newtable) AND
129
cen < (SELECT cen FROM newtable WHERE oldtable.fio=newtable.fio);
14.11Расширения языка SQL
Поскольку чистый SQL не является алгоритмическим языком, т. е. не содержит в себе
операторов IF-THEN-ELSE, DO WHILE, FOR, CASE и т. д., его с самого начала возникновения
пытались расширить, чтобы полу- I чить возможность писать на нем простейшие программы.
В настоящее время имеются 3 наиболее распространенные версии процедурных
расширений языка SQL:
версия фирмы Oracle под названием PL/SQL, которая входит во все без исключения
версии Oracle и является основным инструментом создания приложений под Oracle;
версия Informix и ряда других фирм, получившая название языка 4-го поколения
4GL;
последняя по времени появления версия, ориентированная на Java, или ужe скорее
симбиоз Java+SQL, получившая условное название JavaSQL.
14.12Выводы
Язык SQL, созданный более четверти века тому назад, превратился в общепризнанный
универсальный инструмент для управления данными. Во многих отношениях появление Java
стало практичным и вездесущим средством обогащения этой инфраструктуры семантикой
произвольного уровня сложности, которым может быть только универсальный объектно-ориентированный язык программирования. Подобная логика по самой своей природе является
распределенной, ее легко развернуть на любом уровне архитектуры сетевых вычислений.
Сочетание получивших широкое распространение серверов СУБД SQL-типа и Java-логики
позволит превратить реляционные системы в серверы обработки информации универсального
типа, без которых трудно себе представить информационную архитектуру будущего.
15 Лекция №15: Открытый интерфейс доступа к базам данных – ODBC
15.1 Функциональная модель ODBC
15.2 Основа ODBC
Интерфейс ODBC (Open Database Connectivity) был разработан фирмой Microsoft как
открытый интерфейс доступа к базам данных. Он предоставляет унифицированные средства
взаимодействия прикладной программы, называемой клиентом (или приложением-клиентом), с
сервером - базой данных.
В основу интерфейса ODBC были положены спецификация CLI-интерфейса (Call-Level
Interface), разработанная X/Open, и ISO/IEC для API баз данных, а также язык SQL (Structured
Query Language) как стандарт языка доступа к базам данных.
Интерфейс ODBC проектировался для поддержки максимальной интероперабельности
приложений, которая обеспечивает унифицированный доступ любого приложения,
использующего ODBC, к различным источникам данных. Так, если приложение, соответствующее
стандарту ODBC и SQL, первоначально разрабатывалось для работы с базой данных Microsoft
Access, а затем таблицы этой базы были перенесены в базу данных Microsoft SQL Server или базу
данных Oracle, то приложение сможет и дальше обрабатывать эти данные без внесения
дополнительных изменений.
130
Для взаимодействия с базой данных приложение-клиент вызывает функции интерфейса
ODBC, которые реализованы в специальных модулях, называемых ODBC-драйверами. Как
правило, ODBC-драйверы - это DLL-библиотеки, при этом одна DLL-библиотека может
поддерживать несколько ODBC-драйверов. При установке на компьютер любого SQL-сервера
(базы данных, поддерживающей один из стандартов языка SQL, например, SQL-92) автоматически
выполняется регистрация в реестре Windows и соответствующего ODBC-драйвера.
15.3 Архитектура ODBC
Архитектура ODBC представлена четырьмя компонентами (рис. 1.1):
Приложение-клиент, выполняющее вызов функций ODBC.
Менеджер драйверов, загружающий и освобождающий ODBC-драйверы, которые
требуются для приложений-клиентов. Менеджер драйверов обрабатывает вызовы ODBCфункций или передает их драйверу.
ODBC-драйвер, обрабатывающий вызовы SQL-функций, передавая SQL-серверу
выполняемый SQL-оператор, а приложению-клиенту - результат выполнения вызванной
функции.
Источник данных, определяемый как конкретная локальная или удаленная база данных.
Рис. 1.1. Архитектура ODBC
Основное назначение менеджера драйверов - загрузка драйвера, соответствующего
подключаемому источнику данных, и инкапсуляция взаимодействия с различными типами
источников данных посредством применения различных ODBC-драйверов.
ODBC-драйверы, принимая вызовы функций, взаимодействуют с приложением-клиентом,
выполняя следующие задачи:
управление коммуникационными протоколами между приложением-клиентом и
источником данных;
управление запросами к СУБД;
выполнение передачи данных от приложения-клиента в СУБД и из базы данных в
приложение-клиент;
131
возвращение приложению-клиенту стандартной информации о выполненном вызове
ODBC-функции в виде кода возврата;
поддерживает работу с курсорами и управляет транзакциями.
Приложение-клиент одновременно может устанавливать соединения с несколькими
различными источниками данных, используя разные ODBC-драйверы, а также несколько
соединений с одним и тем же источником данных, используя один и тот же ODBC-драйвер.
15.4 Функции ODBC API
Все функции ODBC API условно можно разделить на четыре группы:
основные функции ODBC, обеспечивающие взаимодействие с источником данных;
функции установки (setup DLL);
функции инсталляции (installer DLL) ODBC и источников данных;
функции преобразования данных (translation DLL).
Объявления всех функций и используемых ими типов данных содержатся в заголовочных
файлах. Группа основных функций ODBC API разбита на три уровня:
функции ядра ODBC;
функции 1 уровня;
функции 2 уровня.
Каждый ODBC-драйвер специфицируется как драйвер, поддерживающий определенный
уровень функций ODBC API.
Прототипы функций ядра ODBC API находятся в файле Sql.h (C/C++, Visual Studio), а
прототипы функций 1 и 2 уровней - в файле Sqlext.h.
Применение #define ODBCVER позволяет указать используемую версию (например,
#define ODBCVER 0x0351).
Прототипы функций установки и инсталляции находятся в файле odbcinst.h.
15.5 Соотношение стандарта ODBC и стандарта интерфейса уровня
вызовов (CLI)
Как уже отмечалось выше, открытый интерфейс доступа к базам данных фирмы Microsoft
основан на следующих стандартах:
спецификация X/Open CAE1) (Specification "Data Management: SQL Call-Level Interface
(CLI)");
спецификация ISO2) /IEC 9075-3:1995 (E) (Call-Level Interface (SQL/CLI)).
В настоящее время фирма Microsoft поддерживает версию 3.x ODBC API. Приложения,
написанные на основе спецификации X/Open и ISO CLI, будут правильно работать с ODBCдрайверами версии 3.x или драйверами "согласованного стандарта" в том случае, если они
компилируются с заголовочными файлами ODBC версии 3.x и линкуются с ODBC 3.x
библиотеками, а доступ к ODBC-драйверу получают через менеджер драйверов ODBC 3.x.
Аналогично, что и сами драйверы 3.x, написанные на основе спецификации X/Open и ISO CLI,
будут правильно работать с приложениями при соблюдении этих же условий.
Драйвер ODBC 3.x всегда поддерживает все возможности, используемые приложением
"согласованного стандарта", а приложение ODBC 3, которое использует только возможности,
132
предоставляемые ISO CLI, и обязательные средства, описываемые X/Open CLI, всегда будет
работать с драйвером "согласованного стандарта".
В дополнение к интерфейсу, специфицированному в стандартах ISO/IEC и X/Open CLI,
ODBC реализует следующие возможности:
извлечение нескольких строк (блочная выборка) за один вызов функции;
связывание с массивом параметров;
поддержка закладок, включая выборку посредством закладки, закладки переменной
длины, блочное обновление и удаление посредством отмеченных операций над
непоследовательными строками;
построчное связывание (row-wise binding);
связывание со смещением (binding offsets);
поддержка пакетов SQL-операторов как в хранимых процедурах, так и в виде
последовательности отдельных SQL-операторов, выполняемых при вызове функций
SQLExecute и SQLExecDirect;
определение точного или приблизительного числа строк курсора;
применение операции позиционированного обновления и удаления и пакетных удалений
и обновлений с использованием функции SQLSetPos;
поддержка функций каталога, позволяющих получать информацию из схемы базы
данных (системных таблиц);
библиотеки преобразования для кодовых страниц;
асинхронное выполнение;
поддержка хранимых процедур, включая escape-последовательности, механизм
связывания выходных параметров, функции каталога;
более продвинутые возможности соединения, включающие поддержку атрибутов
соединения и просмотра атрибутов.
Для согласованности со стандартом ISO CLI и X/Open CLI в заголовочных файлах
содержатся псевдонимы значений, используемых в ODBC API. Так, в псевдонимах "MAX"
расширено до "MAXIMUM", "LEN" до "LENGTH", "MULT" до "MULTIPLE", "OJ" до
"OUTER_JOIN", а "TXN" до "TRANSACTION". Например:
Индентификатор ODBC
SQL_MAX_CATALOG_NAME_LEN
Псевдоним в заголовочном файле
SQL_MAXIMUM_CATALOG_NAME_LENGTH
SQL_MAX_COLUMN_NAME_LEN
SQL_MAXIMUM_COLUMN_NAME_LENGTH
SQL_MAX_COLUMNS_IN_GROUP_BY
SQL_MAXIMUM_COLUMNS_IN_GROUP_BY
SQL_MAX_COLUMNS_IN_ORDER_BY
SQL_MAXIMUM_COLUMNS_IN_ORDER_BY
SQL_MAX_COLUMNS_IN_SELECT
SQL_MAXIMUM_COLUMNS_IN_SELECT
SQL_MAX_COLUMNS_IN_TABLE
SQL_MAXIMUM_COLUMNS_IN_TABLE
SQL_MAX_CONCURRENT_ACTIVITIES SQL_MAXIMUM_CONCURRENT_ACTIVITIES
SQL_MAX_CURSOR_NAME_LEN
SQL_MAXIMUM_CURSOR_NAME_LENGTH
SQL_MAX_DRIVER_CONNECTIONS
SQL_MAXIMUM_DRIVER_CONNECTIONS
SQL_MAX_IDENTIFIER_LEN
SQL_MAXIMUM_IDENTIFIER_LENGTH
SQL_MAX_SCHEMA_NAME_LEN
SQL_MAXIMUM_SCHEMA_NAME_LENGTH
SQL_MAX_STATEMENT_LEN
SQL_MAXIMUM_STATEMENT_LENGTH
SQL_MAX_TABLE_NAME_LEN
SQL_MAXIMUM_TABLE_NAME_LENGTH
SQL_MAX_TABLES_IN_SELECT
SQL_MAXIMUM_TABLES_IN_SELECT
SQL_MAX_USER_NAME_LEN
SQL_MAXIMUM_USER_NAME_LENGTH
SQL_MULT_RESULT_SETS
SQL_MULTIPLE_RESULT_SETS
SQL_OJ_CAPABILITIES
SQL_OUTER_JOIN_CAPABILITIES
SQL_TXN_CAPABLE
SQL_TRANSACTION_CAPABLE
SQL_TXN_ISOLATION_OPTION
SQL_TRANSACTION_ISOLATION_OPTION
133
15.6 Создание источника данных
Источник данных DSN, используемый функциями ODBC API, первоначально должен быть
создан. Это можно выполнить как программно - вызвав функцию ODBC API, так и интерактивно используя утилиту ODBC (в зависимости от версии Windows, расположенную на панели
управления или администрирования).
15.7 Утилита ODBC
При использовании утилиты ODBC (рис. 1.2) на вкладке Пользовательский DSN
отображается список всех зарегистрированных источников данных.
Рис. 1.2. Диалог утилиты ODBC
При добавлении нового источника данных отображается
зарегистрированными в реестре Windows ODBC-драйверами (рис. 1.3).
134
диалог
со
всеми
Рис. 1.3. Список зарегистрированных драйверов
В зависимости от выбранного ODBC-драйвера последовательно отображаются один или
несколько диалогов для ввода параметров создаваемого DSN. Так, для создания источника
данных, позволяющего работать с базой данных Microsoft SQL Server, следует определить имя
создаваемого DSN, имя зарегистрированного SQL-сервера (рис. 1.4) и имя базы данных (на этом
сервере), а также ряд дополнительных параметров.
Рис. 1.4. Создание DSN для базы данных Microsoft SQL Server
15.8 Создание источника данных с использованием ODBC API
DLL-библиотека ODBCCP32.DLL предоставляет функции ODBC API ConfigDSN и
SQLConfigDataSource, позволяющие выполнять регистрацию новых источников данных или
удалять информацию об источниках данных из реестра Windows (и из файла ODBC.ini).
135
Функция ConfigDSN позволяет добавлять, изменять или удалять источники данных и имеет
следующее формальное описание:
BOOL ConfigDSN(
HWND
hwndParent,
WORD
fRequest,
LPCSTR
lpszDriver,
LPCSTR
lpszAttributes);
Для использования в среде Visual Studio функций ConfigDSN и SQLConfigDataSource
следует подключить заголовочный файл odbcinst.h.
Параметр hwndParent определяет дескриптор окна или NULL. Если дескриптор не указан,
то при выполнении данной функции окно с предложением уточнить параметры не отображается.
Параметр fRequest указывает тип запроса, который задается одной из следующих констант:
ODBC_ADD_DSN - добавление нового источника данных;
ODBC_CONFIG_DSN - изменение существующего источника данных;
ODBC_REMOVE_DSN - удаление существующего источника данных.
Параметр lpszDriver содержит описание драйвера, а параметр lpszAttributes список
атрибутов
в
форме
"ключевое
слово=значение"
(например:
DSN=MyDB\0UID=U1\0PWD=P1\0DATABASE=DB1\0\0). Список атрибутов завершается двумя
null-байтами.
При успешном завершении функция возвращает значение TRUE, в противном случае
вызовом функции SQLInstallerError можно получить один из следующих кодов ошибки:
ODBC_ERROR_INVALID_HWND - ошибка в указании дескриптора окна;
ODBC_ERROR_INVALID_KEYWORD_VALUE - параметр lpszAttributes содержит ошибки;
ODBC_ERROR_INVALID_NAME - параметр lpszDriver не найден в системе;
ODBC_ERROR_INVALID_REQUEST_TYPE - параметр fRequest содержит недопустимое
значение;
ODBC_ERROR_REQUEST_FAILED - нельзя выполнить действие, указанное параметром
fRequest;
ODBC_ERROR_DRIVER_SPECIFIC - ошибка конкретного драйвера.
Для записи информации об источнике данных в секцию [ODBC Data Sources] секции
ODBC.INI реестра Windows функция ConfigDSN вызывает функцию SQLWriteDSNToIni, а для
удаления - функцию SQLRemoveDSNFromIni.
Функция SQLConfigDataSource имеет следующее формальное описание:
BOOL SQLConfigDataSource(
HWND
hwndParent,
WORD
fRequest,
LPCSTR
lpszDriver,
LPCSTR
lpszAttributes);
Параметры функции SQLConfigDataSource аналогичны параметрам функции ConfigDSN,
при этом параметр fRequest может принимать следующие значения:
ODBC_ADD_DSN - добавление нового пользовательского DSN;
ODBC_CONFIG_DSN - изменение существующего пользовательского DSN;
ODBC_REMOVE_DSN - удаление существующего пользовательского DSN;
ODBC_ADD_SYS_DSN - добавление нового системного DSN;
ODBC_CONFIG_SYS_DSN - изменение существующего системного DSN;
136
ODBC_REMOVE_SYS_DSN - удаление существующего системного DSN.
Функция ConfigDSN относится к группе функций установки DLL (setup DLL), а функция
SQLConfigDataSource - к группе функций инсталляции DLL (Installer DLL).
При выполнении функция SQLConfigDataSource использует значение параметра
lpszDriver для получения из системной информации полного пути к Setup DLL конкретного
драйвера, загружает эту DLL и вызывает функцию ConfigDSN, передавая ей свой список
параметров (значение параметра fRequest преобразуется к значению, принимаемому функцией
ConfigDSN). Перед вызовом ConfigDSN, в зависимости от типа обрабатываемого DSN,
устанавливается режим USERDSN_ONLY (пользовательский DSN) или SYSTEMDSN_ONLY
(системный DSN), а перед завершением выполнения функция SQLConfigDataSource возвращает
режим BOTHDSN.
15.9 Коды возврата
Все функции ODBC API возвращают значения, называемые кодами возврата. Код возврата
определяет, была ли функция выполнена успешно, или характеризует тип произошедшей ошибки.
В заголовочном файле sql.h определены следующие коды возврата:
#define SQL_SUCCESS
0
Функция выполнена успешно
#define
SQL_SUCCESS_WITH_INFO
1
Функция выполнена успешно, но с уведомительным сообщением
#if (ODBCVER >= 0x0300)
#define SQL_NO_DATA
100
#endif
Больше нет строк для извлечения их из результирующего набора.
В предыдущей версии ODBC API этот код возврата обозначался как
SQL_NO_DATA_FOUND. В версии 3.x код возврата SQL_NO_DATA_FOUND
содержатся в заголовочном файле sqlext.h
#define SQL_ERROR
(-1)
При выполнении функции произошла ошибка
#define
SQL_INVALID_HANDLE
2)
(-
Указан неверный дескриптор
#define
SQL_STILL_EXECUTING
2
Функция, выполняемая асинхронно, пока не завершена
#define SQL_NEED_DATA
99
Для успешного выполнения данной функции следует
предварительно определить необходимые данные
Первые два кода возврата определяют, что функция была выполнена, а остальные
информируют о типе произошедшей ошибки.
Для определения типа кода возврата в заголовочном файле sqltypes.h введено следующее
объявление:
typedef signed short
RETCODE;
137
16 Лекция 18. Документирование в процессах жизненного цикла ПО.
Стандарты управления жизненным циклом автоматизированной системы
16.1 Документация и ее роль в обеспечении качества
Документирование ПО определяется стандартами ГОСТ серии 19, 34, ГОСТ Р ИСО/МЭК 8631,
ГОСТ Р ИСО 9127, ГОСТ Р ИСО/МЭК ТО 9294. Полный перечень нормативных документов на
программную документацию приведен в документе Методика экспертизы программной
документации, находящегося на стадии утверждения.
ГОСТ Р ИСО/МЭК ТО 9294-93 ИТ. Руководство по управлению документированием ПО является
одним из основных стандартов в данной области и представляет собой руководство по
документированию ПО для тех руководителей, которые отвечают за разработку программного
обеспечения. Данное руководство предназначено для помощи руководителям в обеспечении
эффективного проведения документирования в организациях. Данный стандарт направлен на
определение стратегий, стандартов, процедур, ресурсов и планов, которыми должны заниматься
сами руководители для того, чтобы эффективно управлять документированием ПО.
Руководство по управлению документированием ПО предназначено для применения ко всем
типам программного обеспечения - от простейших программ до наиболее сложных систем
программного обеспечения, охватывающих все типы программной документации, относящейся ко
всем стадиям жизненного цикла ПО.
Принципы управления документированием программного обеспечения одинаковы для любого
объема проекта. Для небольших проектов значительную часть положений, приведенных в данном
стандарте, можно не применять, но принципы остаются теми же. Руководители могут
адаптировать данные рекомендации для своих конкретных потребностей.
Эффективность выполнения руководящей роли можно рассматривать как основанную на
следующих трех элементах.
1. Руководящая обязанность по документированию требует признания того, что программная
документация важна и что ее следует планировать, описывать, проверять, утверждать, выпускать,
распространять и сопровождать.
2. Руководящая поддержка обязанностей персонала по документированию требует руководство и
стимулирование персонала при проведение требуемого документирования и обеспечение его
ресурсами для содействия в данной работе.
3. Признаки руководящих обязанностей и поддержки - требует обеспечить:
а) опубликованные официальные отчеты о стратегии документирования;
б) стандарты и руководства, определяющие все аспекты документирования ПО;
в) опубликованные процедуры документирования;
г) выделение соответствующих ресурсов для документирования;
д) планирование документирования, осуществляемое как неотъемлемая часть процесса разработки
ПО;
е) постоянную проверку, осуществляемую для обеспечения соответствия со стратегией,
стандартами, процедурами и планами по документированию.
В ГОСТ Р ИСО/МЭК ТО 9294-93 программная документация рассматривается как имеющая
следующие шесть основных функций.
1. Информация для управления. Во время разработки ПО администрации необходимо оценивать
ход работы, возникающие проблемы и вероятности развития процесса разработки ПО.
Периодические отчеты, согласно которым проверяют ход работ по графику и представляют планы
на следующий период, обеспечивают контрольные механизмы и обзор проекта.
2. Связь между задачами. Большинство проектов разработки ПО разделяется на задачи,
выполняемые различными группами: специалисты в предметной области, аналитики,
проектировщики, специалисты по обеспечению качества и др. Этим группам, а также персоналу в
пределах группы, необходимы средства общения друг с другом, обеспечивающие информацию,
138
которую можно воспроизводить, распространять и на которую можно ссылаться. Большинство
методологий разработки ПО устанавливают официальные документы для связи между задачами.
Например, аналитики представляют официальные спецификации требований проектировщикам, а
они, в свою очередь, официальные проектные спецификации программистам.
3. Обеспечение качества. Требуется документация разработки и документация продукции для
выполнения задач, связанных с обязанностями по обеспечению качества ПО.
4. Инструкции и справки. Документация, требующаяся операторам, пользователям,
руководителям и другим заинтересованным лицам для того, чтобы понимать и использовать ПО.
5. Сопровождение ПО. Специалистам, сопровождающим ПО, требуется детальное описание ПО,
такое, чтобы они могли локализовать и корректировать ошибки и модернизировать или изменять
ПО соответствующим образом.
6. Исторические справки. Документация, требуемая в качестве исторической справки по проекту.
Данная документация может помочь в переносе и переводе ПО в новое окружение.
Рассмотрим стратегии документирования. Стратегии документирования, подготовленные и
контролируемые руководителем организации, обеспечивают руководящими положениями
ответственных лиц, принимающих решения на всех нижних уровнях. Стратегия обеспечивает
главное направление, но не дает рекомендаций, что делать и как это делать. Из-за существенной
роли, которую играет документация на всех стадиях ЖЦ ПО, стратегия должна быть официально
утверждена, доведена до каждого исполнителя проекта. Официальная стратегия устанавливает
дисциплину, требуемую для эффективного документирования ПО.
Стратегия должна поддерживать основные элементы эффективного документирования:
1. требования документации охватывают весь жизненный цикл ПО;
2. документирование должно быть управляемым;
3. документация должна соответствовать ее читательской аудитории;
4. работы по документированию должны быть объединены в общий процесс
разработки ПО;
5. должны быть определены и использованы стандарты по документированию;
6. должны быть определены средства поддержки.
Внутри организации, помимо стратегии, должны быть приняты стандарты и руководства для:
1. модели жизненного цикла ПО;
2. типов и взаимосвязей документов;
3. содержания документа;
4. качества документа;
5. форматов документа;
6. обозначение документа.
Данные стандарты и руководства будут определять, как следует выполнять задачи
документирования, и будут обеспечивать критерии для оценки полноты, полезности и
соответствия программной документации, создаваемой в организации.
Большинство стандартов и руководств выдают рекомендации, которые применимы на общем
уровне. Зачастую будут требоваться управленческие решения для адаптации общих рекомендаций
к конкретным проектам. Применение стандартов, распространяющихся на организацию
документирования, облегчит руководителям проекта определение следующих вопросов:
- какие типы документов требуются?
- каков объем представляемой документации?
- что документы содержат?
-какой уровень качества будет достигнут?
- где документы будут созданы?
- как документы будут хранить, сопровождать и обращать?
В организации должны быть установлены процедуры для применяемых стратегий
документирования. Процедуры для применяемых стратегий определяют последовательность
документирования: планирование, подготовка, конфигурационное управление, проверка,
139
утверждение, производство, хранение, дублирование, распространение, модернизация и продажа.
Кроме того, процедуры должны определять контрольные пункты и методы обеспечения качества.
Основными ресурсами, требуемыми для документирования, являются следующие: персонал,
средства, финансирование.
Персонал. Для процесса разработки ПО необходимы люди со знанием программирования, сути
предмета, документирования, проектировщики, специалисты в предметной области и другие.
Важно, чтобы все специалисты, участвующие в разработке проекта были обучены методам
документирования и полностью понимали и выполняли свою роль в документировании.
Средства. Важно предусмотреть обеспечение задач документирования соответствующими и
подходящими средствами. Инструментальные средства полезны для подготовки и контроля
документации. Они могут быть применены для повышения эффективности многих процессов
документирования и использования стандартов данной организации, распространяющихся на
документирование.
Финансирование. Важно, чтобы стоимость документирования определяли как отдельные статьи
бюджета, так как она нередко составляет значительную часть стоимости разработки ПО.
Процесс документирования, как уже отмечалось выше, должен планироваться. План
документирования определяет, что должно быть сделано, как это должно быть сделано, когда это
должно быть сделано и кто это должен делать.
План документирования может быть как частью общего плана проекта, так и как отдельным
документом. Он должен быть доведен до всех участников проекта. План документирования
включает в себя изложение общей структуры документации, типов, содержания, качества,
форматов, обозначения, комплектности и хранения документов, их обращения и графика
документирования.
График документирования должен распределять время для:
планирования документов;
проверки плана и принципов документирования;
подготовки проектов и проверки их на техническую точность, полноту и соответствие;
редактирование при внесение комментариев, появившихся при проверке;
проведения согласования;
перевода;
распространения.
Планирование документирования следует начинать заранее, и план необходимо проверять на всем
протяжении проекта. Подобно любому плану, план документирования отражает намечаемые
действия и является объектом для необходимых изменений. В проекте должны быть
предусмотрены регулярные проверки результативности изменений в плане.
Более подробно рассмотрим стандарты и руководства, принимаемые в организации.
1. Выбор модели жизненного цикла ПО.
Как уже отмечалось выше, существует ряд моделей жизненного цикла ПО с отличающейся
терминологией для различных стадий. С точки зрения программной документации, не имеет
значения, какая модель выбрана, до тех пор, пока стадии и соответствующая им документация
четко определены, спланированы и выполнимы для любого конкретного программного проекта.
Руководители должны выбрать соответствующую модель ЖЦ и гарантировать, чтобы ее
применяли в данной организации. При этом руководители должны убедиться, что выбранные
стадии и соответствующие задачи помогут им в контроле за ходом разработки ПО.
Проведем краткий анализ жизненных циклов программного обеспечения, описанных нами выше.
В рамках ИСО/МЭК 12207 документирования решаются при вызове каким-либо процессом ЖЦ
процесса документирования.
Процесс документирования - это процесс записи информации, получаемой в процессе жизненного
цикла или деятельности. Процесс состоит из набора действий, таких как планирование,
проектирование, производство, редактирование, распространение и сопровождение документов,
140
необходимых всем заинтересованным лицам проекта: менеджерам, инженерам и пользователям
системы или ПО.
Процесс документирования состоит из следующих действий: реализации, проектирование и
разработка, производство и сопровождение.
Реализация. Это действие состоит из следующих задач.
Планирование, определяющее, какие документы должны быть выпущены во время жизненного
цикла ПО, что должно быть разработано, задокументировано и реализовано. Для каждого
установленного документа должно быть указано следующее:
а) название или имя;
б) цель;
в) назначение;
г) процедуры и ответственность по вводу, разработке, осмотру, модификации, утверждению,
производству, хранению, распространению, сопровождению и конфигурированию;
д) расписание промежуточной и конечной версий.
Проектирование и разработка. Это действие состоит из следующих задач.
1. Каждый документ должен быть спроектирован в соответствии с применяемыми стандартами по
формату, содержанию, нумерации страниц, размещению рисунков/таблиц, отметке о
приоритете/секретности, упаковке и другим пунктам.
2. Источник и соответствие входных данных для документов должны быть гарантированы.
Должны быть использованы автоматические средства документирования.
3. Подготовленные документы должны быть просмотрены и отредактированы с точки зрения
формата, технического содержания и стиля представления в соответствии со стандартами по
документации. Они должны быть утверждены ответственным за их выпуск.
Производство. Это действие состоит из следующих задач.
1. Документы должны быть произведены и упакованы. В соответствии с планом, ими должны
быть обеспечены все заинтересованные стороны. Производство и распространение документов
может быть выполнено в бумажном, электронном виде. Исходные материалы должны храниться в
соответствии с условиями записи, секретности, сопровождения и резервных копий проекта.
2. Контроль должен быть представлен в соответствии с процессом управления
конфигурированием.
Сопровождение. Это действие состоит из следующих задач.
1. Задачи, необходимые для выполнения при модификации существующего ПО, должны быть
исполнены.
Стадия Рабочая документация ГОСТ 34.601 частично соответствует привлечению процесса
документирования процессов разработки по ИСО/МЭК 12207. Название данной стадии не точно
отражает ее содержание, так как она содержит этап 6.2 - Разработка или адаптация программ.
Кроме того, процесс документирования выполняется на стадиях эскизного и технического
проекта. По ГОСТ 19.102 этап разработки программной документации появляется только на
стадии Рабочий проект. Такое позднее начало документирования процессов ЖЦ не в состоянии
обеспечить ни требуемого качества документации, ни требуемого качества ПО.
Таким образом, терминология и концепция в области документирования ИСО/МЭК 12207
представляются более удачными. Можно рекомендовать при использование ГОСТ 34.601 для
этапов 4.2, 5.2, 5.3, 6.1 учитывать в содержании работ задачи, определенные в ИСО/МЭК 12207
для процесса документирования
2. Определение типов и содержания документов.
Программные документы можно представить разделенными на три категории:
документация разработки;
документация продукции;
документация управления проектом.
Данная схема не является исчерпывающей и окончательной, но служит контрольной
таблицей основных типов программных документов, которые руководители должны
предусмотреть, когда определяют стандартные типы своих документов.
141
1. Документация разработки. Документы, описывающие процесс разработки ПО, определяют
требования, которым должно удовлетворять ПО, определяют проект программного обеспечения,
определяют, как его контролируют и как обеспечивают его качество. Документация разработки
также включает в себя подробное описание ПО (программную логику, программные взаимосвязи,
форматы и хранения данных и т.д.).
Разработка документов преследует пять целей:
а) они являются средством связи между всеми участниками проекта и описывают подробности
решений, принятых относительно требований к ПО, проекту, программированию и тестированию;
б) они описывают обязанности группы разработки и определяют, кто, что и когда делает,
учитывая роль программного обеспечения, предмета работ, документации, персонала,
обеспечивающего качество, и каждого вовлеченного в процесс разработки;
в) они выступают, как контрольные пункты, которые позволяют руководителям оценивать ход
разработки (если документы разработки отсутствуют, неполны или устарели, то руководители
проекта теряют важное средство для отслеживания и контроля проекта);
г) они образуют основу документации сопровождения ПО, требуемой лицам, сопровождающим
ПО, как часть документации продукции;
д) они описывают историю разработки ПО.
Типовыми документами разработки являются:
анализы осуществимости и исходные заявки;
спецификации требований и функций;
проектные спецификации, включая спецификации программ и данных;
планы разработки, сборки и тестирования ПО;
планы обеспечения качества, стандарты и графики;
защитная и текстовая информация.
2. Документация продукции. Документация продукции обеспечивает информацию, необходимую
для эксплуатации, сопровождения, модернизации, преобразования и передачи программной
продукции.
Документация продукции преследует три цели:
обеспечение учебной и справочной информацией для любого, использующего или
эксплуатирующего ПО;
облегчение сопровождения и модернизации ПО программистам, не разрабатывавших ПО;
помощь при продаже или приемке ПО.
Документация продукции должна включать в себя материалы для следующих типов читателей:
пользователей, операторов, сопровождающих программистов. Кроме того, данная документация
может включать в себя руководства и материалы для руководителей, вспомогательные материалы,
общую информацию.
Типовые документы продукции включают в себя:
учебные руководства;
справочные руководства и руководства пользователя;
руководства по сопровождению ПО;
брошюры и информационные листки, посвященные продукции.
ГОСТ Р ИСО 9127-94 Системы обработки информации. Документация пользователя и
информация на упаковке для потребительских пакетов вводит определение документации
пользователя, как документации, которая обеспечивает пользователей информацией, необходимой
для установки и прогона ПО и является обязательной в поставке (документация пользователя
142
выполняется в виде одного или нескольких руководств и вкладывается вместе с программным
продуктом внутрь упаковки).
Данный стандарт определяет три категории информации:
- обязательная информация, поставляемая с каждым пакетом;
- условная информация, поставляемая с каждым пакетом, для которого она необходима;
- факультативная информация, поставляемая с каждым пакетом, по усмотрению изготовителя или
торгующей организации.
Назначением документации пользователя является
достаточной информацией для ясного понимания:
цели, функций и характеристик ПО;
того, как ввести в действие и использовать ПО;
договорных прав и обязанностей.
обеспечение
конечного
пользователя
Документация пользователя должна включать в себя справочную документацию для
повседневного использования программы. Дополнительно может быть выполнена учебная
документация. В качестве справочной документации выступают обозначение пакета, компоненты
пакета, функциональное описание ПО, ввод в действие ПО, использование ПО, техническая
информация о ПО, тестирование, договорная информация, словарь, указатель, замечания
конечных пользователей.
Таким образом, ГОСТ Р ИСО 9127, не имея формальных ссылок на ГОСТ Р ИСО/МЭК ТО 9294,
фактически дополняет введенное в нем понятие документации продукции.
3. Документация управления проектом. Документы создаются на основе информации управления
проектом, такой как:
графики для каждой стадии процесса разработки и отчеты об изменениях графиков;
отчеты о согласованных изменениях ПО;
отчеты о решениях, связанных с разработкой;
распределение обязанностей.
Данная документация обеспечивает информацию, относящуюся, с точки зрения руководства, к
долговечности продукции.
3. Определение качества документов.
Руководители должны выбирать стандарты, распространяющиеся на уровень качества,
соответственно различным типам документов и различным типам проектов и должны определять,
как это качество будет достигнуто и поддержано.
Понятия качества, применимые к содержанию, структуре и представлению документации:
качество содержания можно измерять в элементах точности, полноты и ясности;
качество структуры, можно измерять легкостью, с которой читатель имеет возможность
определить местоположение информации;
качество представления должно соответствовать типу проекта.
4. Определение форматов документов.
Стандартизованные форматы документов важны для контроля качества документов, для
читаемости документов и для облегчения их сопровождения.
Информация может быть представлена в различных форматах, причем форматы могут меняться от
проекта к проекту. Форматы зависят от таких факторов, как объем проекта, аудитория, для
которой предназначены документы, количество стадий разработки и бюджет документирования.
Кроме того, должно быть учтено соображение о том, будут ли документы переводить для
международного распространения.
Стандарты и руководства организации, распространяющие на форматы документов, должны быть
установлены таким образом, чтобы допускать гибкость для руководителей в выборе форматов,
подходящих для их проектов.
143
5. Определение системы обозначения документов.
Стандартные обозначения документов необходимы для эффективного контроля документации.
Обозначающая информация может включать в себя: заглавие документа; ссылочный номер
документа; номер версии документа; дату выпуска и пересмотра; реквизиты автора; реквизиты
утвердившего лица; обозначение защищенности (авторских прав); обозначение организации.
Если документы выпускаются в виде разрозненных листов, каждая страница должна иметь
индивидуальное обозначение (например, со ссылочным номером документа, номером страницы и
номером издания).
В части требований 2 - 5 отечественные стандарты 19-ой, 34-ой серии, ГОСТ 28195-89
обеспечивают решение задачи формирования комплекта документации, что будет нами
рассмотрено ниже.
16.1.1 Стандарты управления жизненным циклом автоматизированной системы
ГОСТ 19.102-77 Единая система программной документации. Стадии разработки
ГОСТ 19.201-78* Единая система программной документации. Техническое задание.
Требования к содержанию и оформлению
ГОСТ 2.503-90 ЕСКД. Правила внесения изменений
ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные
системы. Автоматизированные системы. Стадии создания
ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные
системы. Техническое задание на создание автоматизированной системы
ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла
программных средств
РД 50-34.698-90 Методические указания. Информационная технология. Комплекс
стандартов и руководящих документов на автоматизированные системы.
Автоматизированные системы. Требования к содержанию документов
16.2 3.3. Требования стандартов к программной документации
Как уже было отмечено, качество программного обеспечения, наряду с другими факторами,
определяется полнотой и качеством пакета документов, сопровождающих ПО. К программным
документам относятся документы, содержащие сведения, необходимые для разработки,
изготовления, сопровождения программ и эксплуатации.
19-я система стандартов (Единая система программной документации - ЕСПД) устанавливает
следующие виды программной документации.
1. Спецификация. Состав программы и документация на нее.
2. Ведомость держателей подлинников. Перечень предприятий, на которых хранят подлинники
программных документов.
3. Текст программы. Запись программы с необходимыми комментариями.
4. Описание программы. Сведения о логической структуре и функционировании программ.
5. Программа и методика испытаний. Требования, подлежащие проверке при испытании
программы, а также порядок и методы контроля.
6. Техническое задание. Назначение и область применения программы, технические, техникоэкономические и специальные требования, предъявляемые к программе, необходимые стадии и
сроки разработки, виды испытаний.
7. Пояснительная записка. Схема алгоритма, общее описание алгоритма и функционирования
программы, а также обоснование принятых технических и технико-экономических решений.
144
8. Эксплуатационные документы. Сведения для обеспечения функционирования и эксплуатации
программы. Перечень эксплуатационных документов представлен в таблице 3.1.
Таблица 3.1
Вид
эксплуатационного
документа
Содержание
эксплуатационного документа
Регламентирующие стандарты
Ведомость
эксплуатационных
документов
Перечень
эксплуатационных
документов на программу.
ГОСТ 19.507-79.
Формуляр
Основные
программы,
сведения
программы.
характеристики
комплектность
и
об
эксплуатации
ГОСТ 19.501-78.
Описание применения
Сведения о назначении программы,
области
применения,
классе
решаемых задач, применяемых
методах,
ограничениях
для
применения,
минимальной
конфигурации технических средств.
ГОСТ 19.502-78.
Руководство
системного
программиста
Сведения
для
проверки,
обеспечения функционирования и
настройки программы на условия
конкретного применения.
ГОСТ 19.503-79.
Руководство
программиста
Сведения
программы.
эксплуатации
ГОСТ 19.504-79.
Руководство оператора
Сведения,
необходимые
для
осуществления действий, связанных
с
выполнением
программы
вычислительной системой.
ГОСТ 19.505-79.
Описание языка
Описание синтаксиса и семантики
языка.
ГОСТ 19.506-79.
Сведения
для
применения
текстовых
и
диагностических
программ
при
обслуживание
технических средств.
ГОСТ 19.508-79.
Руководство
техническому
обслуживанию
по
для
Полный пакет документов, разрабатываемых при создании автоматизированной системы и, в
частности, программного обеспечения, установленный в отечественных стандартах, включает:
ГОСТ 34.602-89 - техническое задание на создание АС;
ГОСТ 34.201-90 - виды и комплектность документов;
РД 50-34.698-90 - пояснительная записка, схема функциональной структуры, общее описание
системы, описание постановки задачи, описание информационного обеспечения системы,
описание организации информационной базы, перечень входных сигналов и данных, перечень
выходных сигналов/документов, описание программного обеспечения;
ГОСТ 19.201-78 - техническое задание;
ГОСТ 19.402-78 - описание программы;
145
ГОСТ 19.404-79 - пояснительная записка;
ГОСТ 19.301-79 - программа и методика испытаний.
Техническое задание. Содержание технического задания на разработку программных продуктов
должно соответствовать ГОСТ 19.201-78 Техническое задание. Требования к содержанию и
оформлению. Помимо разработки технического задания на все ПО могут разрабатываться
технические задания на этапы, например, техническое задание на выполнение НИР.
Согласно ГОСТ 19.201-78 техническое задание на разработку ПО должно включать следующие
разделы:
введение;
основания для разработки;
назначение разработки;
требования к программе;
требования к программной документации;
технико-экономические показатели;
стадии и этапы разработки;
порядок контроля и приемки;
приложения.
В зависимости от особенностей разрабатываемого ПО стандарт допускает уточнение
содержания разделов, введение новых разделов или их объединение.
В разделе Введение указывается наименование, краткая характеристика области применения ПО.
В разделе Основания для разработки указывается:
документ (документы), на основание которых ведется разработка; организация, утвердившая
документ, и дата утверждения; наименование (условное обозначение) темы разработки.
В разделе Назначение разработки должно быть указано функциональное и эксплуатационное
назначение ПО.
В раздел Требования к программе включаются следующие подразделы.
1. Требования к функциональным характеристикам, в котором указываются требования к составу
выполняемых функций, организации входных и выходных данных, временным характеристикам и
т.д. В данном подразделе описывается поведение ПО с точки зрения соотношения входа и выхода,
без конкретизации его внутренней структуры. Описание выполняемых функций делается либо в
текстовом виде, либо на специальном графическом языке. Описание входа заключается в
фиксации синтаксиса и семантики всех входных данных. Описание выхода должно содержать
точное описание всех возможных выходных данных в тесной взаимосвязи с входными.
2. Требования к надежности, где указываются требования к обеспечению надежного
функционирования ПО, его защите (контроль входной и выходной информации, описание
последствий отказов ПО и т.д.).
3. Условия эксплуатации, в котором должны быть указаны характеристики операционной среды,
вид обслуживания, необходимое количество и квалификация персонала и др., а также допустимые
параметры окружающей среды (относительная влажность, температура и др.).
4. Требования к составу и параметрам технических средств - необходимый состав технических
средств (конфигурация) с указанием их основных технических характеристик.
5. Требования к информационной и программной совместимости, в котором указываются
требования к информационным структурам на входе и выходе и методам решения, исходным
кодам, языкам программирования и программным средствам, используемым ПО. Кроме того,
могут указываться протоколы межмашинного сетевого обмена данными, стандарты протоколов
формализации данных и управления терминалами, стандарты и форматы сообщений, протоколы
транзакций, протоколы запросов данных, стандарты представления данных, требования к СУБД и
операционным системам.
6. Требования к маркировке и упаковке.
7. Требования к транспортированию и хранению.
В разделе Требования к программной документации должен быть указан предварительный состав
программной документации и, при необходимости, специальные требования к ней.
146
В разделе Технико-экономические показатели указывается: ориентировочная экономическая
эффективность, предполагаемая годовая потребность, экономические преимущества разработки
по сравнению с лучшими отечественными и зарубежными образцами или аналогами.
В разделе Стадии и этапы разработки устанавливают необходимые стадии разработки, этапы и
содержание работ (перечень документов, которые должны быть разработаны, согласованы и
утверждены), а также сроки разработки и исполнителей.
В разделе Порядок контроля и приемки должны быть указаны виды испытаний и общие
требования к приемке ПО. Здесь фиксируют важнейшие характеристики ПО в некоторой
количественной или иной достаточно простой форме, с тем, чтобы можно было установить
степень соответствия готового ПО принятым техническим условиям.
В приложениях к техническому заданию при необходимости приводят:
перечень научно-исследовательских и других работ, обосновывающих разработку;
схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут
быть использованы при разработке;
другие источники разработки.
Техническое задание на создание АС разрабатывается в соответствии с ГОСТ 34.602-89. Данный
стандарт устанавливает следующие разделы, включаемые в техническое задание.
1. Общие сведения, включающие полное наименование системы, условное обозначение системы,
шифр темы (шифр (номер) договора), наименование предприятий разработчика и заказчика
системы и их реквизиты, перечень документов, на основании которых создается система,
плановые сроки начала и окончания работ по созданию АС, сведения об источниках и порядке
финансирования работ.
2. Назначение и цели создания АС, в котором указывают назначение системы и цели ее создания.
3. Характеристика объекта автоматизации.
4. Требования к системе. Данный раздел состоит из следующих подразделов.
а) Требования к системе в целом. Здесь указывают перечень подсистем, их назначение и основные
характеристики, требования к числу уровней иерархии и степени централизации системы,
требования к способам и средствам связи для информационного обмена между компонентами
системы, требования к характеристикам взаимосвязей АС со смежными системами, требования к
ее совместимости, способы обмена информации. Кроме того, требования к численности и
квалификации персонала и режиму его работы, к надежности, безопасности и т.д.
б) Требования к функциям.
в) Требования к видам обеспечения (математическому, информационному, лингвистическому
программному , техническому организационному и т.д.).
5. Состав и содержание работ по созданию (развитию) АС.
6. Порядок контроля и приемки системы.
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу в
действие.
8. Требования к документированию.
9. Источники разработки.
Основное внимание уделим руководящему документу РД 50-34.698-90, устанавливающий
требования к содержанию документов на автоматизированные системы. Структура РД 50-34.69890 приведена в таблице 3.2.
Содержание документов, разрабатываемых на предпроектных стадиях (Формирование требований
к АС и Разработка концепции АС), приведено в рекомендуемом приложении к РД 50-34.698-90.
На первой стадии разрабатывается отчет (согласно ГОСТ 7.32) и заявка на разработку АС. На
второй - отчет согласно ГОСТ 7.32.
Содержание организационно-распорядительных документов установлено также в рекомендуемом
приложении. К организационно-распорядительным документам относятся:
акт завершения работы;
акты приемки в опытную и промышленную эксплуатацию;
план-график работ;
приказы о проведении работ и составе приемочной комиссии;
147
протоколы испытаний и согласования.
Документ Описание программного обеспечения содержит вводную часть и разделы: структура
ПО, функции частей ПО, методы и средства разработки ПО, операционная система, средства,
расширяющие возможности операционной системы.
Во вводной части приводят основные сведения о техническом, информационном и других видах
обеспечения АС, необходимые для разработки ПО или ссылку на соответствующие документы
проекта АС.
В разделе Структура ПО приводят перечень частей ПО с указанием их взаимосвязей и
обоснованием выделения каждой из них. В разделе Функции частей ПО приводят назначение и
описание основных функций для каждой части ПО.
В разделе Методы и средства разработки ПО приводят перечень методов программирования и
средства разработки ПО АС с указанием частей ПО, при разработке которых следует использовать
соответствующие средства и методы.
В разделе Операционная система указывают следующее.
1. Наименование, обозначение и краткую характеристику выбранной операционной системы и ее
версии, в рамках которой будут выполнять разрабатываемые программы, с обоснованием выбора
и указанием источников, где дано подробное описание выбранной версии.
2. Наименование руководства, в соответствие с которым должна осуществляться генерация
выбранного варианта операционной системы.
3. Требования к варианту генерации выбранной версии операционной системы.
Раздел Средства, расширяющие возможности операционной системы содержит подразделы, в
которых для каждого используемого средства, расширяющего возможности операционной
системы, указывают:
наименование, обозначение и краткую характеристику средства, с обоснованием необходимости
его применения и указанием источников, где дано подробное описание выбранного средства;
наименование руководства, в соответствие с которым следует настраивать используемое средство
на конкретное применение;
требования к настройке используемого средства.
148
Таблица 3.2.
Область
Документы по
общесистемным
решениям
Документы с
решениями по
организационному
обеспечению
Документы с
решениями по
техническому
обеспечению
(основные)
Документы с
решениями по
информационному
обеспечению
(основные)
Документы с
решениями по
техническому
обеспечению
Документы с
решениями по
математическому
обеспечению
Документы
Содержание
1. Ведомость эскизного (технического) проекта
2. Пояснительные записки к эскизному,
техническому проектам
3. Схема функциональной структуры
4. Ведомость покупных изделий
5. Описание автоматизируемых функций
6. Описание постановки задачи
7. Паспорт
8. Проектная оценка надежности системы
9. Общее описание системы
10. Программа и методика испытаний
11. Схема орг. структуры
1. Описание организационной структуры
2. Методика автоматизированного проектирования
Выполняется по ГОСТ 2.106
Согласно РД 50-34.698-90
3. Технологическая инструкция
4. Руководство пользователя
5. Описание технологического процесса обработки
данных
1. Схема автоматизации
2. Описание комплекса технических средств
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
3. ТЗ на разработку специализированных
технических средств
4. Схема структурная комплекса технических
средств (КТС)
1. Перечень входных сигналов и данных
2. Перечень выходных сигналов
Согласно ГОСТ 15.001
Согласно РД 50-34.698-90
3. Описание ИО системы
5. Описание организации информационной базы
6. Описание системы классификации и кодирования
7. Описание массива информации
8. Массив входных данных
9. Каталог БД
10. Состав выходных данных
11. Инструкция по формированию и ведению БД
1. Описание программного обеспечения
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
1. Описание алгоритма (проектной процедуры)
Согласно РД 50-34.698-90
149
Согласно РД 50-34.698-90
Выполняется по ГОСТ 2.106
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Согласно РД 50-34.698-90
Пояснительная записка к эскизному (техническому) проекту содержит следующие разделы
(согласно РД 50-34.698-90): общие положения; описание процесса деятельности; основные
технические решения; мероприятия по подготовке объекта автоматизации к вводу системы в
действие.
В разделе Общие положения приводят:
наименование проектируемой АС и наименование документов, их номера и дату утверждения, на
основании которых ведут проектирование АС;
перечень организаций, участвующих в разработке системы, сроки выполнения стадий;
цели, назначение и область использования АС;
подтверждение соответствия проектных решений действующим нормам и правилам техники
безопасности и т.п.;
сведения об использованных при проектирование нормативно-технических документах;
сведения о НИР, передовом опыте, изобретениях, использованных при разработке проекта.
В разделе Описание процесса деятельности отражают состав процедур (операций) с учетом
обеспечения
взаимосвязи
и
совместимости
процессов
автоматизированной
и
неавтоматизированной деятельности, формируют требования к организации работ в условиях
функционирования АС.
В разделе Основные технические решения приводят:
решения по структуре системы, подсистем, средствам и способам связи для информационного
обмена между компонентами системы, подсистем;
решения по взаимосвязям АС со смежными системами, обеспечению их совместимости;
решения по режимам функционирования, диагностированию работы АС;
решения по численности, квалификации и функциям персонала АС, режимам его работы, порядку
взаимодействия;
сведения об обеспечении заданных в техническом задании потребительских характеристик
системы (подсистем), определяющих ее качество;
состав функций, комплексов задач, реализуемых системой (подсистемой);
решения по комплексу технических средств, его размещению на объекте;
решения по составу информации, объему, способам ее организации, видам машинных носителей,
входным и выходным документам и сообщениям, последовательности обработки информации и
другим компонентам;
решения по составу программных средств, языкам деятельности, алгоритмам процедур и операций
и методам их реализации.
В разделе приводят в виде иллюстраций другие документы, которые допускается включать по
ГОСТ 34.201.
В разделе Мероприятия по подготовке объекта автоматизации к вводу системы в действие
приводят:
мероприятия по приведению информации к виду, пригодному для обработки на ЭВМ;
мероприятия по обучению и проверке квалификации персонала;
мероприятия по созданию необходимых подразделений и рабочих мест;
мероприятия по изменению объекта автоматизации;
другие мероприятия, исходящие из специфических особенностей создаваемых АС.
Рассмотрим содержание ряда документов, определенных в стандарте DO - 178B. Некоторые
документы, именуемые в данном стандарте как данные жизненного цикла ПО, уже
рассматривались нами в разделе 2.
В DO - 178B определено, что данные жизненного цикла могут принадлежать к одной из двух
категорий: Категории Управления 1 и Категории Управления 2. Эти категории связаны с
элементами управления конфигурацией. Данное разделение позволяет иметь средства управления
затратами на разработку там, где может применяться менее строгий контроль без снижения
степени защищенности данных. В приложении А к документу DO - 178B приведены минимальные
категории управления, назначенному каждому виду данных и их вариации в зависимости от
150
уровня ПО (А, В, С, D, Е). Ниже, в таблице 3.3, представлены некоторые фрагменты целей этапов
жизненного цикла и их выходы - данные жизненного цикла.
Документ DO - 178B устанавливает, что приложение А не предназначено для представления всех
данных, необходимых для создания ПО, и не предусматривает какого-либо определенного способа
хранения этих данных или их организации внутри структур хранения. В дополнении к указанным
документам могут вырабатываться другие, необходимые для сертификации ПО.
Характеристики данных жизненного цикла ПО следующие:
непротиворечивость: информация непротиворечива, если она записана в терминах, допускающих
единственное толкование и дополненная, по необходимости, определениями;
полнота: информация полна, если она включает все необходимые требования и/или описательные
материалы; все используемые диаграммы имеют комментарии, единицы измерения и термины
полностью определены;
проверяемость: информация проверяема, если она может быть проконтролирована на предмет
корректности;
состоятельность; информация состоятельна, если внутри нее нет конфликтов;
модифицируемость: информация модифицируема, если она структурирована и стилизована таким
образом, что вносимые изменения полноценны, непротиворечивы и
корректны;
151
Таблица 3.3
№
Цели
п/п
Применяемость, в
зависимости от уровня ПО
Описание
А
В
С
Выходы
Категория управления,
обуславливаемая уровнем ПО
А
В
План
программных аспектов
сертификации
1
1
1
1
План
разработки ПО
1
1
2
2
1
1
2
2
1
1
2
2
План
определения качества
ПО
1
1
2
Стандарты
требований к ПО
1
1
2
1
1
2
1
1
2
D
С
D
Этап планирования ПО
.
.
1
Определение
действий на этапе
разработки
и
интегрированном
этапе
*
* *
2
Определение
критериев перехода,
взаимосвязей
и
согласованности
между этапами
*
* *
*
План
верификации ПО
План
управления
конфигурацией ПО
.
.
3
Определе
ние среды ЖЦ ПО
*
*
*
5
Определе
ние
стандартов
разработки ПО
*
*
*
*
Стандарты
проектирования ПО
2
Стандарты
кодирования ПО
Этап разработки ПО
1
Разработк
а ВУ требований
*
*
*
*
Данные
требований к ПО
1
1
1
1
2
Определе
ние установленных
ВУ требований
*
*
*
*
Данные
требований к ПО
1
1
1
1
3
Разработк
а архитектуры ПО
*
*
*
*
Описание
проектирования
1
1
2
2
.
6
Разработк
а исходного кода
*
*
*
*
Исходный
1
1
1
.
.
.
1
код
Верификация выходов подэтапа определения требований к ПО
.
.
.
1
ВУ
требований к ПО
подчиняются
требованиям
к
системе
-
-
*
*
Результаты
верификации ПО
2
2
2
2
2
ВУ
требований точны
и согласованы
-
-
*
*
Результаты
верификации ПО
2
2
2
2
7
Алгоритм
ы точны
-
-
*
Результаты
верификации ПО
2
2
2
1
1
2
2
2
2
2
2
1
1
2
Тестирование выходов подэтапа интеграции
.
1
Исполняе
мый
объектный
код подчиняются
ВУ требованиям
*
*
*
*
Варианты
процедуры
верификации ПО
и
Результаты
верификации ПО
.
4
мый
Исполняе
объектный
-
*
*
Варианты
процедуры
152
и
код
точно
соответствует НУ
требованиям
верификации ПО
2
2
2
Результаты
верификации ПО
- - цели должны быть удовлетворены независимо; * - цели должны быть удовлетворены; 1 - данные удовлетворяют
Категории Управления 1; 2 - данные удовлетворяют Категории Управления 2.
Трассируемость: информация трассируема, если могут быть определены источники ее
компонентов;
Форма: форма должна обеспечить возможность эффективно получать доступ к данным
жизненного цикла.
По в течение всего срока службы системы; управление; если предназначены для использования с
этой целью, то данные должны быть определены в плане ПО, который регламентирует этап, для
которого вырабатываются эти данные.
Дадим краткую характеристику основных данных жизненного цикла ПО.
План программных аспектов сертификации - первичное средство из используемых службами
сертификации для определения, предлагает ли разработчик такой жизненный цикл ПО, который
удовлетворяет уровню разрабатываемого ПО. Данный план должен включать следующие разделы.
1. Обзор системы. Этот раздел содержит обзор системы, включая описание ее функций и их
распределение между аппаратной и программной частями, архитектуры, программно-аппаратных
интерфейсов, возможностей по обеспечению безопасности и т.д.
2. Обзор ПО. Здесь коротко описывают функции ПО с акцентом на предлагаемый уровень
концепции безопасности.
3. Аспекты сертификации. Этот раздел содержит сводку базиса сертификации, включая средства
обеспечения соответствия по отношению к программным аспектам сертификации. Здесь также
устанавливается предлагаемый уровень ПО и приводятся выводы этапа оценки безопасности
системы, включая потенциальную возможность работы ПО в неблагоприятных условиях.
4. Жизненный цикл ПО. В данном разделе описан используемый жизненный цикл и приводятся
резюме по каждому его этапу и подэтапу, для которых детальная информация определяется в
соответствующих планах на разработку ПО. Резюме определяет, какие цели каждого этапа и
подэтапа ЖЦ ПО должны быть достигнуты, вовлекаемые структуры для их достижения и т.д.
5. Данные жизненного цикла ПО. Этот раздел определяет данные, которые будут выработаны и
управляемы подэтапами ЖЦ ПО. Здесь также описывается отношение данных друг к другу и
другим данным, определяющим систему, данные, требуемые для сертификации, форма данных и
т.д.
6. Планировка. Этот раздел описывает средства, которые будут использованы разработчиком для
предоставления отчетности по деятельности в течение жизненного цикла ПО при сертификации.
7. Дополнительные аспекты. Здесь приводятся специфические возможности, которые могут
повлиять на этап сертификации: например, альтернативные методы обеспечения соответствия,
оценка качества инструментальных средств, ранее разработанное ПО и т.д.
План оценки качества ПО. Устанавливает используемые методы для достижения целей этапа
оценки качества ПО (ОКПО). План ОКПО может включать описание методов улучшения и
прогрессивного управления этапом и может состоять из следующих разделов.
1. Среда. Описание среды оценки качества ПО, включая структуру, организационные
ответственности и интерфейсы, стандарты, процедуры, средства, методы и метрики.
2. Полномочия. Характеристика полномочий, ответственности и независимости оценки качества
ПО.
3. Методы. Методы оценки качества ПО, которые должны использоваться для каждого подэтапа
жизненного цикла ПО на всем его протяжении, включая:
методы ОКПО, такие, как обзоры, ведение протоколов, отчеты, проверки и наблюдение за
этапами ЖЦ ПО;
методы, относящиеся к оповещению о проблемах и их исправлению;
методы описания проверки ПО.
153
4. Промежуточный критерий. Устанавливает промежуточный критерий для перехода к этапу
оценки качества ПО.
5. Временные требования. Временные требования методик этапа ОКПО по отношению к
методикам подэтапов ЖЦ ПО.
6. Результаты оценки качества ПО. Описание результатов, выработанных этапом оценки
качества ПО.
7. Управление поставщиками. Описание средств оценки соответствия действий поставщиков
нижнего уровня плану оценки качества ПО.
Документ Требования к ПО определяет требования высокого уровня, включая и производные
требования, если это необходимо. Этот документ должен включать следующее (но не
ограничиваться этим).
1. Описание приведения системных требований к программным, с особым акцентом на требования
безопасности и потенциальные условия возникновения сбойных ситуаций.
2. Функциональные и операционные требования для каждого режима работы.
3. Критерии функционирования, например, точность.
4. Временные требования и ограничения.
5. Ограничения по размеру памяти.
6. Программные и аппаратные интерфейсы, например, протоколы обмена, форматы данных,
частота входных и выходных сигналов.
7. Требования на обнаружение сбоев и мониторинг за безопасностью функционирования.
8. Требования к расчленению ПО на отдельные компоненты и на их взаимодействие друг с другом
(например, при реализации в виде распределенной системы).
Таким образом, хотя стандарт DO - 178B и не устанавливает явно процессы документирования в
своем жизненном цикле, ясно видно, что документации в нем уделено большое внимание.
В заключение данного раздела кратко остановимся на документах, разрабатываемых в ходе
процесса создания ПО согласно [2]. В процессе разработки ПО появляются следующие
документы, перечисленные ниже в хронологическом порядке:
Соглашение о требованиях; Внешняя спецификация; Внутренняя спецификация. Документ
Соглашение о требованиях должен содержать первое письменное соглашение между заказчиком и
разработчиком о том, что будет сделано, и что не будет делаться при разработке и выпуске
программного обеспечения. В отличие от него спецификация предполагает наличие более точных
и исчерпывающих формулировок и определений. При этом, первые два документа содержат
информацию о том, что представляет собой ПО; а третий должен объяснять, как ПО устроено и
как достигаются установленные для него цели и требования. Все документы имеют схожую
структуру для облегчения контроля над проектом, а также для обеспечения прослеживаемости
всех технических решений от требований до их реализации. По мере продвижения проекта
разделы документа либо просто копируются в соответствующие разделы следующего
создаваемого документа, либо расширяются описаниями технических решений текущего этапа.
Ниже приведена общая структура документа Внешняя спецификация, с развернутыми
комментариями в тех пунктах, которые касаются технической стороны дела (документ также
включает экономические, управленческие и другие аспекты, которые не рассматриваются здесь):
1. ОПИСАНИЕ ПРОГРАММНОГО ИЗДЕЛИЯ
1.1. Наименование и шифры ПО (полное наименование, сокращенные наименования, шифры ПО и
проекта).
1.2. Краткое описание ПО (включая сведения об авторском праве, иерархию документов, с
указанием документов вышестоящих уровней).
1.3. Результирующие компоненты ПО (оформляется в виде таблицы или другой формы и включает
в себя, перечень спецификаций, другой документации и компонентов программного обеспечения).
2. ЦЕЛИ
Этот раздел содержит причины выпуска ПО с указанием различного типа заявок, планов и т.п. и
носит полностью управленческий характер.
3. СТРАТЕГИЯ
3.1. Соглашения относительно представления материала.
154
3.1.1. Обозначения (определяются все обозначения, используемые в требованиях: например, если
применяются индексы, то дается пример их использования и определяется принцип индексации).
3.1.2. Терминология (особенно специфическая для данного изделия).
3.1.3. Синтаксис (приводятся, если необходимо, синтаксические правила для дальнейшего
описания требований).
3.2. Генерируемое программное обеспечение (классифицируется как вспомогательное и
порождаемое описываемым изделием).
3.3. Системное программное обеспечение (все остальное ПО, включая ОС, утилиты, пакеты
прикладных программ, которое классифицируется как основное, поскольку оно генерирует ПО
предыдущего пункта).
Примечание. Причина такой расстановки пунктов состоит в том, что при правильном
проектировании сверху вниз генерируемое программное обеспечение является основной целью
проектирования и должно быть описано раньше, чем его генератор. Другими словами, структура
генерируемых программ должна определять структуру генератора, а не наоборот. Если все ПО
является основным, то в п.3.2. делается пометка не используется и опускаются все его подпункты.
Структура подпунктов п.п. 3.2 и 3.3 полностью дублируется и далее для простоты используется
нумерация только п.п. 3.3.
3.3.n. Общие характеристики функции n. Если технически затруднительно и неестественно
рассматривать ПО как один большой функциональный модуль, то следует привести его
функциональную декомпозицию, показав связи между функциями (функциональными модулями)
и присвоив каждой функции некоторое уникальное имя n. Затем для каждой функции отводится
подраздел раздела 3.3 (т.е. 3.3.1, 3.3.2 и т.д.), в заглавии которого используется слово функция с
последующим именем функционального модуля. Отметим, что такая функциональная
декомпозиция не указывает, как именно ПО будет фактически разбито на программные модули
(это составляет содержание документа Внутренняя спецификация). Для удобства работы, конечно,
полезно иметь некоторое соответствие функционального и фактического разбиения, но это не
является требованием и не должно уводить с правильного пути проектирования изделия.
3.3.n.1. Внешние ограничения.
3.3.n.1.1. Стандарты (список используемых промышленных стандартов и собственных стандартов
предприятия).
3.3.n.1.2. Ограничения на совместимость. Необходимо рассматривать несколько аспектов
совместимости:
исходный язык, машинный язык, форматы данных и сообщений, форматы отчетов, форматы
листингов и т.п. Специально должна оговариваться совместимость со следующими программными
изделиями:
изделиями-предшественниками (т.е. такими, которые пользователь может заменить новым
изделием; если число функций при такой замене уменьшается, то следует привести обоснование
этому);
изделиями-компаньонами (т.е. относящимися к той же группе средств и являющимися
альтернативой);
подобными изделиями (т.е. выполняющих похожие функции в других программных изделиях);
конкурирующими изделиями (других организаций).
3.3.n.1.3. Программные ограничения. Описываются программное окружение разрабатываемого
ПО, включая указание средств для его загрузки и запуска. Также отмечаются все действующие
программные ограничения, например использование вычислений с удвоенной точностью для
некоторых функций.
3.3.n.1.4. Аппаратные ограничения. Приводится перечень устройств, необходимых для работы ПО
(с указанием минимальной, оптимальной и максимальной конфигурации). Указываются все
действующие ограничения на оборудование, например, физические характеристики терминала
или требование запрещения использования звукового сигнального устройства.
3.3.n.2. Внешние характеристики.
Примечание. Если разрабатываемое ПО является расширением уже существующего, то
описываются, главным образом, его дополнительные характеристики. В любом случае
наибольшее внимание должно уделяться самым важным для конечного пользователя вопросам.
155
Эти разделы являются основой документа и содержат полное и окончательное описание всех
свойств программного изделия.
3.3.n.2.1. Результаты. Описываются все выходные данные ПО с точки зрения их функционального
содержания и назначения (например, файлы, сообщения, программно устанавливаемые сигналы и
прерывания). При этом должны быть рассмотрены все возможные в системе носители и средства
отображения информации. Указываются тип, структура, формат, объем, расположение и диапазон
изменения. Для всех выходных данных, читаемых людьми (сообщения и отчеты) должны быть
приведены образцы.
3.3.n.2.2. Процессы обработки. Описываются операции, выполняемые ПО в целом или
функциональными модулями, рассматриваемыми как черный ящик. Если обсуждение идет на
уровне модулей или этапов разработки, указываются также модули или этапы, требуемые для
получения определенной выходной информации. Точно определяются все возможные ошибки,
потенциальные условия их возникновения и способы рестарта и восстановления. Подраздел
должен описывать инициацию, преобразование данных, все варианты завершения работы
(нормального и аварийного).
3.3.n.2.3. Входы. Описание подобно п. 3.3.2.1
3.3.n.3. Эргономические характеристики.
Примечание. Этот раздел описывает свойства, обеспечивающие надежность, комфорт и
продуктивность работы пользователей и операторов, а также вопросы безопасности, секретности,
восстанавливаемости после сбоев, мобильности ПО. Остановимся более подробно на двух
подразделах: Надежность и Рабочие характеристики.
В разделе Надежность (это свойство программы понимается здесь как способность к
восстановлению нормальной работы при ошибках и сбоях в работе оборудования)
рассматриваются следующие вопросы:
защита данных пользователя;
степень защиты программ от ошибок, возникающих в других частях системы (например,
работающих одновременно с данной программой в другой области памяти). Следует рассмотреть,
как могут повлиять на работу предлагаемых программных средств такие ошибки, учитывая
следующие моменты: распределение ресурсов памяти (указать, если предусмотрено обеспечение
изоляции отводимых областей памяти); связь программ через общие аппаратные ресурсы.
Раздел Рабочие характеристики описывает основные параметры или принципы, по которым
должна оцениваться эффективность работы программы, по возможности в количественном виде с
указанием возможных допусков. Все параметры должны быть измеряемыми, к их числу могут
относиться быстродействие, пропускная способность, скорость передачи данных, расход
машинных ресурсов, время реакции (или задержки) и т.д.
3.3.n.4. Внутренние характеристики (этот раздел полностью расширяется в документе Внутренняя
Спецификация, однако частично может быть заполнен с целью полного описания
соответствующих внешних свойств).
3.4. Внутренние ограничения (здесь речь идет о тех свойствах, которые пользователю логично
ожидать, но которые по тем или иным причинам будут исключены из программного изделия или
потенциально оставлены на усмотрение разработчика: например, неполная взаимозаменяемость
носителей, отсутствие поддержки каких-либо возможностей оборудования, и т.п.).
4. ИСПОЛЬЗУЕМЫЕ МАТЕРИАЛЫ (в т.ч. справочные)
5. ПЕРЕДАЧА ЗАКАЗЧИКУ И ВВОД В ДЕЙСТВИЕ.
156
