Тема: Управление безопасностью сети

 

Раньше маршрутизируемые сети соединяли небольшое количество локальных сетей (LANs) и узлов. По мере роста соединений между внутренними и внешними сетями, и роста использования сети Internet, контроль доступа к сети стал представлять собой отдельную проблему. Сетевым администраторам приходится решать задачу запрета нежелательного трафика и разрешения необходимого доступа к сети. Такие средства, как пароли, использование оборудования для обратных соединений (callback) и контроль физического доступа, эффективны, но им не хватает гибкости и специфических возможностей контроля, которые предпочитает большинство администраторов.

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

 

Применение АСLs.

 

Фильтрация пакетов позволяет контролировать движение пакетов по сети. АСLs фильтруют трафик, который проходит через маршрутизатор, но не фильтруют трафик, который порождает сам маршрутизатор.

Сisсо позволяет с помощью АСLs разрешить или запретить прохождение пакетов на вход или выход интерфейсов маршрутизатора. АСLs также можно применять к виртуальным портам (vty) маршрутизатора для разрешения или запрещения трафика Telnet на маршрутизатор или с него.

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

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

Стандартные и расширенные списки контроля доступа Сisсо позволяют реализовать безопасность и шифрование.

Классификация и разделение трафика также полезна для поддержки разного качества обслуживания (QoS) для разного трафика:

 

- технологии очередей в IОS по приоритету и по настройке (software-priority queuing and custom queuing;.

- технологии “соединение по требованию” (dial-оn-demand routing, DDR);

- фильтрации обновлений протокола маршрутизации с маршрутизатора или на него.

 

 

Типы АСLs

Идентификация списков контроля доступа

Номер АСLs является первым аргументом в команде конфигурирования АСLs который определяет его тип. Маршрутизатор на основании этого номера подставляет нужные аргументы для выбранного типа АСLs. Строки АСLs. содержат условия для проверки пакетов в соответствии с используемым стеком протоколов. Параметры проверки трафика различаются в зависимости от протокола.

 

Для каждого протокола можно создать множество списков контроля доступа. Для каждого нового АСLs устанавливается новый номер. Однако можно использовать только один АСLs для одного протокола (стека) на одном направлении (вход или выход) одного интерфейса.

АСLs с номерами от 1 до 99 или от 1300 до 1999 - стандартный IР АСLs.

АСLs с номерами от 100 до 199 или от 2000 до 2699 - расширенный IР АСLs.

АСLs с именем может быть стандартным или расширенным. Именованные IР АСLs позволяют удалять, но не вставлять, отдельные строки.

Стандартные АСLs: Стандартные IРАСLs проверяют адрес источника пакета.

 

Стандартные АСLs (номера от 1 до 99 и от 1300 до 1999) отфильтровывают пакеты, основываясь на адресе источника и маске. В результате разрешается или запрещается весь стек протоколов ТСР/IР от определенной сети, подсети или узла на основании IР адреса источника пакета. Такая фильтрация ограничивает возможности контроля.

 

Расширенные АСLs: Расширенные IР АСLs (номера от 100 до 199 и от 2000 до 2699) проверяют и адрес источника, и адрес назначения пакета. Они также могут проверять специфические протоколы, номера портов и другие параметры, которые можно указать в конце строки. Это предоставляет администраторам большую гибкость и возможности контроля.

 

Некоторые из часто встречающихся номеров портов показаны в таблице:

 

Номера портов (в десятичном виде)	Протокол IР
20 (ТCР)	данные FТР
21 (ТCР)	управление FТР
23 (ТCР)	Telnet
25 (ТCР)	SMTP
53(ТCР/ UDP)	DNS
69 (UDР)	TFTP
80 (ТCР)	НТТР

Работа АСL.

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

Когда пакеты отбрасываются, некоторые протоколы возвращают специальный пакет для уведомления отправителя, что адрес назначения недоступен. Для протокола IР отброшенный согласно АСL трафик рождает ответ “Адрес назначения недоступен” (“Destination unreachable, U.U.U.”), в случае если был отправлен рing, и ответ “Запрещено административно” (“Administratively prohibited,!А *!А”), если это был traceroute.

 

Существует два направления работы АСLs.

 

Входящие АСLs.

Исходящие АСLs.

Входящие АСLs: Входящие пакеты обрабатываются до того, как они маршрутизируются на исходящий интерфейс. Эффективность входящего АСLs в том, что он предотвращает лишний просмотр таблицы маршрутизации в случае если пакет должен быть отброшен. Разрешенный пакет обрабатывается. Для входящих списков контроля доступа “разрешить” означает продолжить обработку пакета после получения его на входящем интерфейсе, а “запретить” означает отбросить пакет.

Когда пакет приходит на маршрутизатор через интерфейс на котором установлен входящий АCL, то пакет не отправляется о тех пор, пока не пройдет проверку на соответствии со строками этого АСL. В зависимости от результатов проверки пакет будет разрешен или запрещен.

Если пакет запрещен, то он отбрасывается.

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

 

Исходящие АСLs: Входящие пакеты сначала маршрутизируются на исходящий интерфейс, а затем пропускаются через исходящий список контроля доступа. Для исходящих списков контроля доступа “разрешить” означает отправить пакет в исходящий буфер интерфейса, а “запретить” означает отбросить пакет.

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

Затем маршрутизатор проверяет, используется ли АСL на исходящем интерфейсе. Если нет, то пакет отправляется в исходящий буфер.

Если на исходящем интерфейсе есть исходящий АСL, пакет не отправляется о тех пор, пока не пройдет проверку на соответствии со строками этого АСL. В зависимости от результатов проверки пакет будет разрешен или запрещен.

Алгоритм работы АСL

 

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

 

Если заголовок пакета и условие проверки в строке АСL совпадают, то оставшиеся строки списка контроля доступа игнорируются, и к пакету применяется правило “разрешить” или “запретить” в соответствии с той строкой, с которой произошло совпадение.

 

Если заголовок пакета не совпал с условием проверки в строке АСL, то пакет проверяется на предмет совпадения со следующими строками списка. Процесс поиска соответствия продолжается до последней строки списка контроля доступа.

 

Последняя, невидимая строка применяется ко всем пакетам, к которым не подошло ни одно условие проверки. Условие в этой последней строке совпадает со всеми пакетами, и к ним применяется правило - запретить. Все оставшиеся пакеты отбрасываются. Последняя строка часто называется “невидимое условие запрета” (“implicit deny any statement”). Из-за этого условия список контроля доступа должен иметь хотя бы одну строку, имеющую правило “разрешить”. В противном случае АСL отбросит весь трафик.

 

ACL работает по принципу – запрещено все, что не разрешено.

 

Один АСL можно использовать на разных интерфейсах. Однако можно использовать только один АСL для одного протокола (стека) на одном направлении (вход или выход) одного интерфейса.

 

Тема: Управление производительностью сети

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

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

 

Для расчета максимального количества кадров минимальной длины, проходящих по сегменту Ethernet, заметим, что размер кадра минимальной длины вместе с преамбулой составляет 72 байт или 576 бит, поэтому на его передачу затрачивается 57,5 мкс. Прибавив межкадровый интервал в 9,6 мкс, получаем, что период следования кадров минимальной длины составляет 67,1 мкс. Отсюда максимально возможная пропускная способность сегмента Ethernet составляет 14 880 кадр/с. (14903)

Кадры максимальной длины технологии Ethernet имеют поле длины 1500 байт, что вместе со служебной информацией дает 1518 байт, а с преамбулой составляет 1526 байт или 12 208 бит. Максимально возможная пропускная способность сегмента Ethernet для кадров максимальной длины составляет 813 кадр/с (818).

Теперь рассчитаем, какой максимальной полезной пропускной способностью в бит в секунду обладают сегменты Ethernet при использовании кадров разного размера.

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

· служебной информации кадра;

· межкадровых интервалов (IPG);

· ожидания доступа к среде.

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

С_П =14880 * 46 *8 = 5,48 Мбит/с.

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

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

С_П = 813 *1500 * 8 =9,76 Мбит/с,

что весьма близко к номинальной скорости протокола.

При использовании кадров среднего размера с полем данных в 512 байт пропускная способность сети составит 9,29 Мбит/с, что тоже достаточно близко к предельной пропускной способности в 10 Мбит/с.

Отношение текущей пропускной способности сети к ее максимальной пропускной способности называется коэффициентом использования сети (network utilization). При этом при определении текущей пропускной способности принимается во внимание передача по сети любой информации, как пользовательской, так и служебной.

При отсутствии коллизий и ожидания доступа коэффициент использования сети зависит от размера поля данных кадра и имеет максимальное значение 0,976 при передаче кадров максимальной длины.

 

Раздел 4. Схемы послеаварийного восстановления работоспособности компьютерной сети.

 

Тема: Резервное копирование данных

 

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

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

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

Установление жизненного цикла и календаря операций

 

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

Ежедневные задачи являются основой, с которой хорошо знакомы системные администраторы. К ним относятся:

мониторинг заданий;

отчеты о сбоях и успешном выполнении;

анализ и разрешение проблем;

манипуляции с лентами и управление библиотекой;

расписание выполнения заданий.

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

анализ производительности;

тенденции изменения объемов и планирование этих изменений;

рассмотрение и анализ методики резервного копирования;

проверку возможности восстановления;

планирование развития архитектуры. Определяем ежедневные, еженедельные и ежемесячные задания.

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

Ежедневный обзор логов процесса резервного копирования

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

Защита базы данных резервного копирования или каталога

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

Ежедневное определение временного окна резервного копирования

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

Локализация и сохранение "внешних" систем и томов

ПО резервного копирования предоставляет некоторые отчеты о ежедневных сессиях резервного копирования. Рассматривать только их и полагаться только на них рискованно. ПО резервного копирования генерирует отчеты только об известных ему серверах. Сложные среды часто имеют "внешние" системы, системы, которые участвуют в работе, но не включены в схему резервного копирования. Это происходит по разным причинам. Купленная неким подразделением система и оказавшаяся вне поля зрения IT-подразделения некоторое время может работать с собственным резервным копированием. Но рано или поздно возможен сбой, приводящий к потере данных. Тогда специалисты IT-подразделения получают запрос восстановления данных на системе, о которой им ничего не известно. Как правило, такие системы попадают в поле зрения службы IT, слишком поздно. Решение этой проблемы может оказаться трудоемким и займет массу времени. Потребуется регулярный просмотр и мапирование новых сетевых адресов в узлы (ноды), фильтрация не связанных с задачей адресов (дополнительные сетевые карты, сетевые устройства, принтеры и т.д.), идентификация местоположения и владельцев таких узлов и внесение соответствующих изменений в политику резервного копирования (в этом случае объемы данных, подлежащих сохранению, увеличатся). Также важно регулярное предоставление отчетов владельцам системы и приложений о том, что на самом деле сохраняется, а что - нет.

 

Максимально возможная централизация и автоматизация резервного копирования

Ключом к успешной защите данных является их целостность. Но это не значит, что со всеми данными требуется обходиться одинаково. Наоборот - одинаково надо обращаться с данными, сходными по объему и важности для компании. Проблема "внешних" систем, о которой шла речь чуть выше, как раз является примером нарушения целостности данных, возникающего из-за нецентрализованного управления резервным копированием. Нередко операции резервного копирования для Windows - и Unix-серверов происходят независимо. Такая организация могла предшествовать сетевому хранению. Помимо того что это неэффективно, подобная организация предполагает разные наборы процедур и разные стратегии резервного копирования для разных платформ. Определять ценность данных таким образом неправильно.

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

Возьмем, к примеру, трудоемкую задачу ежедневного изучения журналов (логов) выполнения операций. Автоматизация позволит генерировать сигналы тревоги при появлении в логах заранее определенных ошибок. Верно и обратное: автоматизация поможет накапливать повторяющиеся в логах ошибки. Если в логах увидеть одну ошибку SCSI, это то же самое, что увидеть их тысячу.

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

 

Создание и поддержка открытых отчетов, отчетов об открытых проблемах

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

 

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

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

 

 

Тема: Хранилище данных. Принципы работы хранилищ данных.

 

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

ориентированность на предметную область или ряд предметных областей,

интегрированность,

зависимость от времени (поддержка хронологии),

постоянство.

Ориентированность на предметную область

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

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

Интегрированность

Наиболее важный аспект хранилища данных состоит в том, что данные, находящиеся в хранилище, интегрированы.

Интегрированность проявляется во многих аспектах:

в согласованности имен,

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

в согласованности структур данных,

в согласованности физических атрибутов данных и др.

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

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

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

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

Зависимость от времени

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

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

Другое проявление зависимости хранилища данных от времени заключается в его структуре. Каждая структура хранилища включает – явно или неявно – элемент времени.

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

 

Постоянство

Четвертая определяющая характеристика хранилища данных – это постоянство. В оперативной среде операции обновления, добавления, удаления и изменения производятся над записями регулярно. Базовые манипуляции с данными хранилища ограничены начальной загрузкой данных и доступом к ним. В хранилище данных обновление данных не производится. Исходные (исторические) данные, после того как они были согласованны, верифицированы и внесены в хранилище данных, остаются неизменными и используются исключительно в режиме чтения.

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

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

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

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

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

Хранилище данных содержит агрегированные (итоговые) данные, которые никогда не включаются в оперативную среду.

Передача данных из оперативной среды в хранилище данных сопровождается фундаментальными преобразованиями. Большинство данных при поступлении в хранилище видоизменяется.

 

В общем случае модель данных современных Систем Поддержки Принятия Решений (СППР) строится на основе пяти классов данных:

• источники данных,
• хранилища данных (в узком смысле),
• оперативный склад данных,
• витрины данных,
• метаданные.

Источники данных

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

Хранилище данных (в узком смысле)

Хранилище данных (в узком смысле) представляет собой предметно-ориентированную базу или совокупность БД, извлекаемых из источников, которые организованы по сегментам, отражающим конкретную предметную область бизнеса: производство, правило, детальные слабо агрегированные данные.

Оперативный склад данных (Operational Data Store - ODS)

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

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

имеет изменяемое содержимое,

содержит только детальные данные,

содержит текущие значения данных.

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

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

Витрины данных (Data mart)

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

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

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

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

 

Метаданные

Метаданные — это любые данные о данных. Метаданные играют важную роль в построении Систем Поддержки Принятия Решений (СППР). Одновременно это один из наиболее сложных и недостаточно практически проработанных объектов. В общем случае можно выделить по крайней мере три аспекта метаданных, которые должны присутствовать в системе.

С точки зрения пользователей:

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

С точки зрения функциональности системы:

• метаданные о процессах трансформации,
• метаданные по администрированию системы,
• метаданные о приложениях, метаданные о представлении данных

пользователям.

 

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

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

 

 

Тема: Принципы построения. Основные компоненты хранилища данных.

 

Хранилище на самом верхнем уровне состоит, как правило, из трех подсистем:

подсистемы загрузки данных,

подсистемы обработки запросов и представления данных,

подсистемы администрирования хранилища.

 

Подсистема загрузки данных

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

Начальной загрузки ретроспективных данных,

Регламентного пополнения хранилища данными из источников.

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

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

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

Программное обеспечение регламентированной отчетности, которое характеризуется заранее предопределенными запросами данных и их представлениями бизнес-пользователям. От данного ПО не требуется быстрого времени реакции. Из соображений стоимости эффективности для его реализации в наибольшей степени подходит технология ROLAP (см. далее).

Программное обеспечение нерегламентированных запросов пользователей. Это ПО – основной способ общения бизнес-аналитиков с хранилищем, при котором каждый последующий запрос к данным и вид их представления определяются, как правило, результатами предыдущего запроса. Для приложений данного типа требуется высокая скорость обработки запросов (единицы секунд). Данное ПО реализуется технологией MOLAP (см. далее) и специальными инструментами построения сложных нерегламентированных запросов с интуитивно понятным для бизнес-аналитиков графическим интерфейсом.

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

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

 

Подсистема администрирования хранилища

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

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

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

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

 

 

Тема: Технологии управления информацией OLАP ‑ технология

 

В соответствии с этим основными функциями информационно-аналитической системы являются:

Извлечение данных из различных источников, их преобразование и загрузка в хранилище

Хранение данных

Анализ данных, включая регламентированные отчеты, произвольные запросы, многомерный анализ (OLAP) и извлечение знаний (data mining).

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

Корпорация Oracle предлагает новый подход к созданию аналитических систем – единую и функционально полную платформу для решения всех перечисленных задач.

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

Компонент Data Warehousesобъединяет те возможности сервера Oracle, которые предназначены для построения и эффективного использования хранилищ данных. Режимы функционирования базы данных для аналитических задач требуют специальных настроек параметров, методов индексирования и обработки запросов. Начиная с Oracle7, в СУБД Oracle стали появляться новые средства, с помощью которых совершенствовалась работы базы в режиме хранилищ и витрин данных. К их числу относятся параллельная обработка запросов, позволяющая наиболее полно использовать возможности многопроцессорных аппаратных платформ, эффективные битовые (bitmap) индексы и специализированные алгоритмы выполнения запросов, такие как хэш-соединения (hash joins), которые многократно повысили производительность обработки аналитических запросов. В СУБД Oracle имеется мощная возможность секционирования данных (partitioning), облегчающая управление и значительно ускоряющая обработку очень больших таблиц и индексов. Кроме того, появились новые схемы оптимизации, преобразующие запросы к типу «звезда», что позволяет избежать ресурсоемкого полного соединения справочных таблиц. Одним из важнейших усовершенствований в этом же направлении является технология управления суммарными данными на основе материализованных представлений (materialized views). Анализируя статистику работы системы, СУБД рекомендует администратору необходимые агрегаты, автоматически их создает и периодически обновляет. Затем при выполнении запросов с агрегированием система автоматически переписывает их таким образом, чтобы они обращались к суммарным данным, хранящимся в материализованных представлениях. Такой подход резко, иногда на несколько порядков, повышает производительность хранилища данных для конечных пользователей. Среди других технологий, связанных с быстродействием в аналитических задачах, — функциональные индексы, специальные операции для вычисления итогов и подитогов в отчетах, широкий спектр встроенных аналитических функций и ряд других.

ETL компонент — это расширение стандартных средств СУБД Oracle дополнительными командами и средствами, полезными для задач сбора и преобразования данных. К таким средствам относятся внешние таблицы, автоматическая фиксация изменения данных (change data capture), табличные функции, одновременный ввод и корректировка данных, ввод данных в несколько таблиц и др. [5].

Опция OLAP Services позволяет хранить и обрабатывать многомерную информацию на том же сервере баз данных, где находится реляционное хранилище. По функциональным возможностям OLAP Services сравнимы с многомерной СУБД OracleExpress и по существу завершают процесс интеграции технологии OracleExpress с реляционным сервером OracleDatabase. Средства OLAP Services поддерживают в полном объеме основной язык сервера Express, а для существующих баз данных Express обеспечивается их миграция в СУБД Oracle [6].

Средствами опции Oracle9i DataMining реализуется технология data mining, с помощью которой в больших объемах информации можно автоматически выявить ЭШелямерность и взаимосвязи, полезные для принятия управленческих решений.

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

 

Для разработки и развертывания хранилищ и витрин данных предназначен продукт Oracle Warehouse Builder, который представляет собой интегрированную CASE-среду, ориентированную на создание информационно-аналитических систем. Средствами этого продукта можно проектировать, создавать и администрировать хранилища и витрины данных, разрабатывать и генерировать процедуры извлечения, преобразования и загрузки данных из различных источников, эффективно управлять метаданными. Стандарты Common Warehouse Model, лежащие в основе репозитария Oracle Warehouse Builder, обеспечивают его интеграцию с различными аналитическими инструментальными средствами как Oracle, так и других фирм. Для организации доступа с рабочих мест аналитиков к данным хранилища и витрин используются специализированные рабочие места, поддерживающие необходимые технологии как оперативного, так и долговременного анализа. Аналитическая деятельность в рамках корпорации достаточно разнообразна и определяется характером решаемых задач, организационными особенностями компании, уровнем и степенью подготовленности аналитиков. В связи с этим современный подход к инструментальным средствам анализа не ограничивается использованием какой-то одной технологи. В настоящее время принято различать четыре основных вида аналитической деятельности:

стандартная отчетность,

нерегламентированные запросы,

многомерный анализ (OLAP) и

извлечение знаний (data mining).

Каждая из этих технологий поддерживается продуктами Oracle: для стандартной отчетности используется OracleReports, для формирования нерегламентированных отчетов и запросов — OracleDiscoverer, для сложного многомерного анализа – опция сервера Oracle9i OLAP Services вместе с Jdeveloper и BI JavaBeans или линия продуктов OracleExpress, а для задач «извлечения знаний опция OracleDataMining.

Важнейшей чертой аналитических инструментальных средств и приложений Oracle является их готовность к работе в среде Web. Менеджеры и аналитики, где бы они ни находились, могут получать информацию из Хранилищ и Витрин Данных в защищенной Интранет-архитектуре с помощью сервера приложений Oracle9i ApplicationServer.

Кроме собственно продуктов, обеспечивающих полное решение для корпоративной информационно-аналитической системы, корпорация Oracle предлагает оригинальную методологию выполнения проекта по созданию и сопровождению таких систем. Эта методология называется Data Warehouse Method (DWM) и является частью общего подхода Oracle к проектированию и реализации различных проектов.

 

 

Тема: Понятие баз данных. Основные понятия, принцип работы. СУБД

 

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

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

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

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

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

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

Отношения обладают следующими свойствами:

- каждый элемент – один элемент данных;

- повторяющиеся группы отсутствуют;

- элементы столбца имеют одинаковую природу;

- в таблице не повторяются строки;

- строки и столбцы можно просматривать в любом порядке.

Преимущество данной модели:

- простота логической модели;

- гибкость системы;

- независимость данных;

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

Если прикладная информационная система опирается на некоторую систему управления данными, обладающую свойствами: поддержание логически согласованного набора файлов; обеспечение языка манипулирования данными; восстановление информации после разного рода сбоев; реально параллельная работа нескольких пользователей, то эта система управления данными является системой управления базами данных (СУБД).

Основные функции СУБД:

1. Непосредственное управление данными во внешней памяти

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

2. Управление буферами оперативной памяти

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

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

3. Управление транзакциями

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

4. Журнализация

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

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

Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. Можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.

5. Поддержка языков БД

Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL) и язык манипулирования данными (DML). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные.

В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language), который сочетает средства SDL и DML, т.е. позволяет определять схему реляционной БД и манипулировать данными. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов.

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

Организация типичной СУБД и состав ее компонентов соответствует рассмотренному набору функций.

Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть - ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД.

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

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

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

 

Тема: Принципы планирования восстановления работоспособности сети при аварийной ситуации

Реализуемость Плана основана на двух предположениях:

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

Тема: Допущения при разработке схемы послеаварийного восстановления. Основные требования к политике организации схемы послеаварийного восстановления

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

• система неработоспособна, с учетом специфики реализации и технологии работы системы, технические средства могут быть восстановлены по прежнему месту размещения не ранее чем через 12 часов;
• заранее определен ключевой персонал, который осведомлен о действиях в чрезвычайных обстоятельствах и своих обязанностях в процессе восстановления работоспособности системы;
• системы контроля, аварийного оповещения и ликвидации последствий (противопожарные системы, контроль загазованности, контроль протечек водопровода и отопления и др.) исправны и находятся в работоспособном состоянии.
• все элементы системы (как в месте постоянного размещения, так и в резервном помещении) обеспечены непрерывным энергопитанием не менее чем на 30 минут с момента выхода из строя основной энергосистемы. В последующем все элементы системы подключаются к дизель-генератору, обеспеченному трехсуточным запасом топлива;
• аппаратно-программные средства, размещенные в центральном офисе, не доступны в результате чрезвычайных обстоятельств более 12 часов;
• актуальные резервные копии прикладного программного обеспечения и данных не повреждены и доступны в резервном офисе;
• необходимое для восстановления системы оборудование доступно в резервном офисе;
• договоры на техническое обслуживание аппаратных средств, обновление программного обеспечения и услуги провайдеров связи включают положения, необходимые для реализации Плана восстановления функционирования системы.

Целью хакерской атаки обычно является хищение коммерческой информации и финансовое мошенничество, однако в Москве, по опросам специалистов, эти позиции составляют лишь 3% и 6% от общего числа хакерских атак. Эксперты Ernst & Young полагают, что масштабы проблемы намного существеннее, а низкий процент объясняется тем, что современные хакеры искусно скрывают следы. Только в Москве ущерб от электронных мошенников оценивается столичными правоохранительными органами в 12 - 15 млн долларов в месяц.

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

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