3. Обслуживание базы данных

В рамках обслуживания БД в Traffic Inspector реализованы следующие операции:

отслеживание наличия свободного места на дисках сервера;

резервное копирование базы данных;

очистка встроенной базы данных.

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

Для настройки операций обслуживания выполните следующие действия.

Откройте окно настройки операций обслуживания. Сделать это можно из блока Обслуживание БД в разделе Настройки или в разделе Настройки -> Обслуживание БД консоли администратора.

На вкладке Задачи обслуживания выберите задачи, которые будут настраиваться в рамках данного мастера.

Если на вкладке Задачи обслуживания была выбрана задача Файлы и диски, то на одноименной вкладке настройте следующие параметры этой операции.

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

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

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

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

Если на вкладке Задачи обслуживания была выбрана задача Резервное копирование, то на одноименной вкладке настройте параметры выполнения этой операции (настройка полностью аналогична настройке резервного копирования в отдельном окне, подробнее см. в п. Резервное копирование).

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

На этой же вкладке включите или выключите сжатие очищенного файла базы данных.

Сохраните внесенные изменения.

Экзаменационный билет № 3

1.Процедуры физического проектирования

Цель этапа физического проектирования - описание конкретной реализа­ции базы данных, размещаемой во внешней памяти компьютера. Это описание структуры хранения данных и эффективных методов доступа к данным базы. При логическом проектировании отвечают на вопрос - что надо сделать, а при физическом - выбирается способ, как это сделать. Процедуры физического проектирования следующие.  Проектирование таблиц базы данных средствами выбранной СУБД. Осуществляется выбор реляционной СУБД, которая будет использоваться для создания базы данных, размещаемой на машинных носителях. Глубоко изуча­ются ее функциональные возможности по проектированию таблиц. Затем вы­полняется проектирование таблиц и схемы их связи в среде СУБД. Подготов­ленный проект базы данных описывается в сопровождаемой документации.  Реализация бизнес-правил в среде выбранной СУБД. Обновление ин­формации в таблицах может быть ограничено бизнес-правилами. Способ их реализации зависит от выбранной СУБД. Одни системы для реализации требо­ваний предметной области предлагают больше возможностей, другие - меньше. В некоторых системах вообще отсутствует поддержка реализации бизнес-правил. В таком случае разрабатываются приложения для реализации их огра­ничений.  Все решения, принятые в связи с реализацией бизнес-правил предметной области, подробно описываются в сопроводительной документации. 3. Проектирование физической организации базы данных. На этом шаге выбирается наилучшая файловая организация для таблиц. Выявляются транзакции, которые будут выполняться в проектируемой базе данных, и выделяются наиболее важные из них. Анализируется пропускная способность транзакций - количество транзакций, которые могут быть обработаны за заданный интервал времени, и время ответа - промежуток времени, необходимый для выполнения одной транзакции. Стремятся к повышению пропускной способности транзакций и уменьшению времени ответа. На основании указанных показателей принимаются решения об оптимизации производительности базы данных путем определения индексов в таблицах, ускоряющих выборку данных из базы, или снижения требований к уровню нормализации таблиц. Проводится оценка дискового объема памяти, необходимого для размещения создаваемой базы данных. Стремятся к его минимизации. Принятые решения по изложенным вопросам документируются. 4. Разработка стратегии защиты базы данных. База данных представляет собой ценный корпоративный ресурс, и организации ее защиты уделяется большое внимание. Для этого проектировщики должны иметь полное и ясное представление обо всех средствах защиты, предоставляемых выбранной СУБД. 5. Организация мониторинга функционирования базы данных и ее на­стройка. После создания физического проекта базы данных организуется не­прерывное слежение за ее функционированием. Полученные сведения об уровне производительности базы данных используются для ее настройки. Для этого привлекаются и средства выбранной СУБД. Решения о внесении любых изменений в функционирующую базу данных должны быть обдуманными и всесторонне взвешенными.

2. Проектирование БД. Проблемы проектирования БД

Проектирование ИМ, включающих в себя БД, осуществляется на физическом, концептуальном и логическом уровнях.

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

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

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

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

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

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

Структурирование информации для использования в ИС в процессе проведения системного анализа на основе совокупности правил и рекомендаций.

Основная цель проектирования БД - сокращение избыточности хранимых данных и, следовательно, экономия объёма используемой памяти, уменьшение затрат на многократные операции, обновлении избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте.

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

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

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

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

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

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