Курсовая по предмету Управление данными. Курсовая Управление данными. Эксплуатация баз данных
 Скачать 52.27 Kb.
|
1 2 ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ Государственное образовательное учреждение высшего профессионального образования Тверской государственный технический университет (ГОУВПО ТГТУ) КУРСОВАЯ РАБОТА по управлению данными Тема: Эксплуатация баз данных  Выполнил: студент 3 курса группы Проверил: Тверь 2021 План курсовой работы (Тема: «Эксплуатация баз данных») стр.
Введение Современные базы данных – это сложные многофункциональные программные системы, работающие в открытой распределенной среде. Они уже сегодня доступны для использования в деловой сфере и выступают не просто в качестве технических и научных решений, но как завершенные продукты, предоставляющие разработчикам мощные средства управления данными и богатый инструментарий для создания прикладных программ и систем. Эксплуатация баз данных предусматривает выполнение функций, направленных на обеспечение надежного и эффективного функционирования системы баз данных, адекватности содержания базы данных информационным потребностям пользователей, отображения в базе данных актуального состояния предметной области. Необходимость персонала, обеспечивающего администрирование данными в системе БД в процессе функционирования, является следствием централизованного характера управления данными в таких системах, постоянно требующего поиска компромисса между противоречивыми требованиями к системе в социальной пользовательской среде. Хотя такая необходимость и признавалась на ранних стадиях развития технологии баз данных, четкое понимание и структуризация функций персонала, занятого администрированием, сложилось только вместе с признанием многоуровневой архитектуры СУБД. Проблема исследования «Эксплуатация баз данных» заключается в возможности дать исчерпывающие ответы на поставленные вопросы: что представляет собой эксплуатация баз данных, в чем заключаются его основные функции и задачи, его значение для стабильной и эффективной работы базы данных. Актуальность исследования «Эксплуатация баз данных» несомненна. Можно провести аналогию между администратором баз данных и ревизором предприятия. Ревизор защищает ресурсы предприятия, которые называются деньгами, а администратор – ресурсы, которые называются данными. Нельзя рассматривать администратора баз данных только как квалифицированного технического специалиста, так как это не соответствует целям администрирования. Уровень администратора баз данных в иерархии организации достаточно высок: чтобы определять структуру данных и право доступа к ним, администратор должен знать, как работает предприятие, и как используются соответствующие данные. Проблеме администрирования баз данных внимание уделяется сравнительно недавно – с появлением и развитием современных баз данных. Однако в связи с тем, что совершенствование баз данных и систем управления данных – явление постоянное и непрерывное, проблема остается достаточно актуальной, следовательно, требует дополнительных исследований в данной области компьютерных технологий. Цель исследования заключается в изучении эксплуатации баз данных Задачи исследования формируются, исходя из его цели, и заключаются в следующем: 1. Рассмотреть понятие, классификацию и функции администратора базы данных. 2. Рассмотреть обязанности, связи и средства администратора современных систем управления базами данных. 3. Изучить основные направления и принципы эксплуатации баз данных. Данное исследование проведено с использованием теоретических положений, раскрывающих основные характеристики и элементы исследуемого явления. Практическая значимость исследования заключается в его возможном использовании при изучении информационных технологий в высших учебных заведениях. Основные средства СУБД Современная СУБД содержит в своем составе программные средства создания баз данных, средства работы с данными и дополнительные, сервисные средства. С помощью средств создания БД проектировщик, используя язык описания данных (ЯОД), переводит логическую модель БД в физическую структуру, а на языке манипуляции данными (ЯМД) разрабатывает программы, реализующие основные операции с данными (в реляционных БД - это реляционные операции). При проектировании привлекаются визуальные средства, т.е. объекты, и программа-отладчик, с помощью которой соединяются и тестируются отдельные блоки разработанной программы управления конкретной БД. Средства работы с данными предназначены для пользователя БД. Они позволяют установить удобный (как правило, графический многооконный) интерфейс с пользователем, создать необходимую функциональную конфигурацию экранного представления выводимой и вводимой информации (цвет, размер и количество окон, пиктограммы пользователя) и т.д. и производить операции с данными БД, манипулируя текстовыми и графическими экранными объектами. Дополнительные (сервисные) средства позволяют при проектировании и использовании БД привлечь к работе с БД другие системы. Например, воспользоваться текстом из системы редактирования Word или таблицей из табличной системы Excel или обратиться к сетевому серверу. Система управления базами данных (СУБД) является универсальным программным средством, предназначенным для создания и ведения (обслуживания) баз данных (БД) на внешних запоминающих устройствах, а также доступа к данным и их обработки. СУБД поддерживают один из возможных типов моделей данных — сетевую, иерархическую пли реляционную, которые являются одним из важнейших признаков классификации СУБД. СУБД обеспечивают многоцелевой характер использования базы данных, защиту и восстановление данных. Наличие развитых диалоговых средств и языка запросов высокого уровня делает СУБД удобным средством для конечного пользователя. Основными средствами СУБД являются: средства задания (описания) структуры базы данных; средства конструирования экранных форм, предназначенных для ввода данных, просмотра и их обработки в диалоговом режиме; средства создания запросов для выборки данных при заданных условиях, а также выполнения операций по их обработке; средства создания отчетов из базы данных для вывода на печать результатов обработки в удобном для пользователя виде; языковые средства — макросы, встроенный алгоритмический язык (Dbase, Visual Basic или другой), язык запросов (QBE — Query By Example, SQL) и т.п., которые используются для реализации нестандартных алгоритмов обработки данных, а также процедур обработки событий в задачах пользователя; средства создания приложений пользователя (генераторы приложений, средства создания меню и панелей управления приложениями), позволяющие объединить различные операции работы с базой данных в единый технологический процесс. База данных — это совокупность данных, организованных на машинном носителе средствами СУБД. В базе данных обеспечивается интеграция логически связанных данных при минимальном дублировании хранимых данных. БД включает данные, отражающие некоторую логическую модель взаимосвязанных информационных объектов, представляющих конкретную предметную область. База данных организуется в соответствии с моделью и структурами данных, которые поддерживаются в СУБД. СУБД в многопользовательских системах. База данных, как правило, содержит данные, необходимые многим пользователям. Получение одновременного доступа нескольких пользователей к общей базе данных возможно при установке СУБД в локальной сети персональных компьютеров и создании многопользовательской базы данных. В сети СУБД следит за разграничением доступа разных пользователей к общей базе данных и обеспечивает защиту данных при одновременной работе пользователей с общими данными. Автоматически обеспечивается защита данных от одновременной их корректировки несколькими пользователями-клиентами. В сети с файловым сервером база данных может размещаться на сервере. При этом СУБД загружается и осуществляет обработку данных базы на рабочих станциях пользователей. Концепция файлового сервера в локальной сети обеспечивается рядом сетевых операционных систем. В сети, поддерживающей концепцию «клиент-сервер», используется сервер баз данных, который располагается на мощной машине, выполняет обработку данных, размещенных на сервере, и отвечает за их целостность и сохранность. Для управления базой данных на сервере используется язык структурированных запросов SQL (Structured Queries Language). На рабочих станциях-клиентах работает СУБД-клиент. Пользователи могут взаимодействовать не только со своими локальными базами, но и с данными, расположенными на сервере. СУБД-клиент, в которой поддерживается SQL, в полном объеме может посылать на сервер запросы SQL, получать необходимые данные, а также посылать обновленные данные. При этом с общей базой данных могут работать СУБД разного типа, установленные на рабочих станциях, если в них поддерживается SQL. Подключение из СУБД к серверам баз данных SQL может быть осуществлено с помощью драйверов ODBC. ODBC (Open Database Connectivity, открытый стандарт доступа к базам данных), поддерживает стандартный протокол для серверов баз данных SQL. Непосредственное управление данными во внешней памяти. Эта функция включает обеспечение необходимых структур внешней памяти как для хранения непосредственных данных, входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным в некоторых случаях (обычно для этого используются индексы). В некоторых реализациях СУБД активно используются возможности существующих файловых систем, в других работа производится вплоть до уровня устройств внешней памяти. Но подчеркнем, что в развитых СУБД пользователи в любом случае не обязаны знать, использует ли СУБД файловую систему, а если использует, то как организованы в ней файлы. В частности, СУБД поддерживает собственную систему именования объектов БД (это очень важно, поскольку имена объектов базы данных соответствуют именам объектов предметной области). Существует множество различных способов организации внешней памяти баз данных. Как и все решения, принимаемые при организации баз данных, конкретные методы организации внешней памяти необходимо выбирать в тесной связи со всеми остальными решениями. Управление буферами оперативной памяти. СУБД обычно работают с БД значительного размера; по крайней мере, этот размер обычно существенно превышает доступный объем оперативной памяти. Понятно, если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Единственным же способом реального увеличения этой скорости является буферизация данных в оперативной памяти. И даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов. При управлении буферами основной памяти приходится разрабатывать и применять согласованные алгоритмы буферизации, журнализации и синхронизации. Заметим, что существует отдельное направление СУБД, которые ориентированы на постоянное присутствие в оперативной памяти всей БД. Это направление основывается на предположении, что в предвидимом будущем объем оперативной памяти компьютеров сможет быть настолько велик, что позволит не беспокоиться о буферизации. Пока эти работы находятся в стадии исследований. Управление транзакциями. Транзакция – это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные ею, во внешней памяти, либо ни одно из этих изменений никак не отражается в состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Таким образом, поддержание механизма транзакций – обязательное условие даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо существеннее во многопользовательских СУБД. То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения, делает очень удобным использование понятия транзакции как единицы активности пользователя по отношению к БД. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый пользователь может в принципе ощущать себя единственным пользователем СУБД (на самом деле, это несколько идеализированное представление, поскольку пользователи многопользовательских СУБД порой могут ощутить присутствие своих коллег). С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций. Под сериализаций параллельно выполняющихся транзакций понимается такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивлентен эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций – это такой способ их совместного выполнения, который приводит к сериализации транзакций. Понятно, что если удается добиться действительно сериального выполнения смеси транзакций, то для каждого пользователя, по инициативе которого образована транзакция, присутствие других транзакций будет незаметно (если не считать некоторого замедления работы для каждого пользователя по сравнению с однопользовательским режимом). Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов БД. При использовании любого алгоритма сериализации возможны ситуации конфликтов между двумя или более транзакциями по доступу к объектам БД. В этом случае для поддержания сериализации необходимо выполнить откат (ликвидировать все изменения, произведенные в БД) одной или более транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе транзакций других пользователей. Журнализация. Одно из основных требований к СУБД – надежное хранение данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть аварийное завершение работы СУБД (из-за ошибки в программе или некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции. Но в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежного хранения данных в БД требует избыточности хранения данных, причем та их часть, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенный метод поддержания такой избыточной информации – ведение журнала изменений БД. Журнал – это особая часть БД, недоступная пользователям СУБД и поддерживаемая особо тщательно (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), а порой запись соответствует минимальной внутренней операции модификации страницы внешней памяти. В некоторых системах одновременно используются оба подхода. Во всех случаях придерживаются стратегии «упреждающей» записи в журнал (так называемого протокола Write Ahead Log – WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя. Самая простая ситуация восстановления – индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции выполнением обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу). При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом. Более подробно мы рассмотрим это в соответствующей лекции. Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия – это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии по журналу, воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после конца восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным. Протоколирование и аудит. Аудит – проверка того, все ли предусмотренные средства управления задействованы и соответствуют уровню защищенности установленным требованиям. Такая мера как протоколирование и аудит состоит в следующем: обнаружение необычных и подозрительных действий пользователей и идентификация лиц, совершивших эти действия; оценка возможных последствий состоявшегося нарушения; оказание помощи; организация пассивной защиты информации от нелегальных действий пользователя: поддержка точности вводимых данных; поддержка документации в активном виде; корректное тестирование пользователей. Рекомендуется при выполнении организации протоколирования фиксировать факты передачи привилегий и подключения к той или иной базе данных. Средства поддержки доступности. Следующим вопросом в рассмотрении проблемы обеспечения информационной безопасности является анализ средств поддержания высокой готовности. Если речь идет о СУБД, то необходимо в архитектуре аппаратно-программного комплекса иметь средства, обеспечивающие нейтрализацию аппаратных отказов и восстановление после ошибок обслуживающего персонала или прикладных программ. Сохранение информации базы данных на диски, помещаемые затем в безопасное место, уже длительное время активно применяется для информационных систем. При архивировании сохраняются пространства базы данных и многочисленная сопутствующая информация, необходимая для последующего восстановления. Резервное копирование – периодически выполняемая процедура получения копии базы данных и ее журнала изменений на носителе, сохраняемом отдельно от системы. Надо помнить, что архив отражает состояние базы данных на время начала архивирования. Резервные копирования логических журналов транзакций сохраняет файлы журналов; интерпретация последних позволяет восстановить базу данных до состояния, более позднего, чем момент последнего архивирования. На основании полученной информации из архива и/или резервной копии может быть осуществлено восстановление как архивной информации (физическое восстановление), так и более свежие состояние базы данных (логическое восстановление). Можно перечислить возможности службы восстановления на примере СУБД Informix: архивировании в горячем режиме, т.е. без прерывания работы сервера; резервное копирование журналов транзакций; сохранение на удаленных устройствах; сохранение по заранее определенному расписанию без участия оператора; сжатие и шифрование информации. Контрольные точки – момент синхронизации между состоянием базы данных и журнала транзакция. В это время принудительно выгружаются содержимое буфера оперативной памяти на устройства вторичной памяти. Рассмотренные выше средства сохранения могут обеспечить восстановление с минимальными потерями пользовательской информации, однако работа сервера базы данных будет на некоторое время прервана. Следующий механизм, обеспечивающий высокий уровень отказоустойчивости – технология тиражирования данных. Тиражирование данных – это асинхронный перенос изменений объектов исходной базы данных в базы, принадлежащие различным узлам распределенной системы. В конфигурации серверов базы данных выделяют один основной и ряд вторичных. В обычном режиме работы основной сервер выполняет чтение и обновление данных, обеспечивает перенос зафиксированных изменений на вторичные серверы. В случае отказа основного сервера его функции автоматически (вручную) переводятся на вторичный сервер в режим работы “чтение + запись”. После восстановления функций основного сервера ему может быть присвоен статус вторичного, а вторичному делегированы все полномочия основного (при этом обеспечивается непрерывная доступность данных). Процедура тиражирования осуществляется либо в синхронном, либо в асинхронном режиме. Благодаря первому осуществляется гарантированность полной согласованности данных, т.е. на вторичном сервере будут зафиксированы все транзакции, выполненные на основном. Асинхронный режим улучшает рабочие характеристики системы, не всегда обеспечивая полную согласованность (стоит заметить, что далеко не во всех задачах требуется синхронизация фиксации; достаточно поддерживать тождественность данных лишь в критические моменты времени). Защита коммуникаций между клиентом и сервером. Проблема защиты коммуникаций между клиентом и сервером в информационных системах не является специфичной для СУБД. Для обеспечения защиты информации выделяется сервис безопасности, в функции которого входит аутентификация, шифрование и авторизация. Эти вопросы были рассмотрены выше. Отражение угроз, специфичных для СУБД. Однако главный источник угроз для СУБД лежит в самой природе баз данных. Наличие специфического непроцедурного языка SQL, процедур и механизм правил – все это обеспечивает потенциальному злоумышленнику средства для получения информации, на которую он не имеет полномочий. Нередко нужную, но недоступную по статусу информацию можно получить путем логического вывода. Например, используя операцию вставки, а не выбора (на которую прав нет), анализировать коды завершения SQL-операторов, и получать информацию о наборе первичных ключей. Для борьбы с подобными угрозами используется механизм размножения строк для СУБД, поддерживающий метки безопасности. Суть этого метода состоит в том, чтобы в состав первичного ключа добавлять метку безопасности, что обеспечивает одновременное хранение в базовой таблице несколько экземпляров строк с одинаковыми значениями важных ключей. Агрегирование – метод получения новой информации путем комбинирования данных, добытых легальным путем из различных таблиц базы данных. Бороться с агрегированием можно за счет тщательного проектирования модели данных и максимального ограничения доступа пользователя к информации. Таким образом, можно определить некоторые стратегии в области безопасности: минимум привилегий; разделение обязанностей; эшелонированная оборона (сервер базы данных, средства защиты СУБД и операционной системы); разнообразие средств защиты; невозможность перехода в небезопасное состояние; всеобщая поддержка мер безопасности. 1 2 |