1 / 89

Системы управления базами данных ( I часть)

Системы управления базами данных ( I часть). Защита данных. Администрирование БД. Лекции доступны на сайте www.ucit.ru В разделе сайта: Профессиональная переподготовка Рабочие программы. Защита данных.

Download Presentation

Системы управления базами данных ( I часть)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Системы управления базами данных (I часть) Защита данных. Администрирование БД.

  2. Лекции доступны на сайте www.ucit.ru В разделе сайта: Профессиональная переподготовка Рабочие программы

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

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

  5. Защита целостности и непротиворечивости • Минимальная избыточность данных. • Ограничение доступа • Ограничение обработки • Ведение системного журнала • Регистрация пользователей • Регистрация действий • Использование транзакций (Принцип Статус-кво) • Контрольные точки • Копирование данных • Управление параллельным доступом

  6. Минимальная избыточность данных означает отсутствие или минимальное присутствие дублирования данных. Ограничение доступа: На уровне пользователей На уровне данных

  7. Ограничение доступа на уровне пользователей Система имен пользователей, паролей и регистрация в системе обеспечивает права пользователя на доступ к системе. Каждый пользователь системы должен быть детерминирован. При входе выделяют две процедуры: • Процедура идентификации - проверка имени пользователя. • Процедура верификации - проверка пароля, т.е. правильности ввода имени. Возможны и такие современные методы как идентификация по отпечаткам пальцев, радужке глаза, видео, аудио- распознавание и т.д. 2НФ

  8. Пользователи БД Пользователи классифицируются по категориям, и каждая категория получает право работы с определенной областью доступа В системе обычно имеется 4 группы пользователей: 1. Администраторы (системные) - полные права доступа к данным 2. Общая (пользователи) - минимальный доступ 3. Владелец (собственник данных) - полное право доступа к данным 4. Группа - т.е. часть пользователей, которым владелец передал часть прав.

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

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

  11. Ведение системного журнала Ведение системного журнала предполагает: 1. Регистрацию каждого входа пользователя 2. Регистрация всех действий, которые совершил пользователь

  12. Использование транзакций ТРАНЗАКЦИЯ - неделимая с точки зрения воздействия на БД последовательность операторов манипулирования данными (чтения, удаления, вставки, модификации) такая что, либо результаты всех операторов, входящих в транзакцию, отображаются в БД, либо воздействие всех этих операторов полностью отсутствует. Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Транзакция или логическая единица работы, - это, в общем случае, последовательность ряда таких операций, которые преобразуют некоторое непротиворечивое состояние базы данных в другое непротиворечивое состояние, но не гарантируют сохранения непротиворечивости во все промежуточные моменты времени.

  13. Механизм транзакций 320 кортежей

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

  15. Транзакции В общем случае, транзакция – это совокупность изменений в БД, которые должны быть зафиксированы ВСЕ в БД, либо НИ ОДНОГО. Для работы с транзакциями используются два предложения: COMMIT (фиксировать), превращающее все предварительные обновления в окончательные ("зафиксированные"); ROLLBACK (откат), аннулирующее все предварительные обновления.

  16. Организация параллельной обработки данных Управление параллельным доступом- совокупность мероприятий по обеспечению целостности и непрерывности в системах коллективного пользования (в системах в которых возможен доступ одних и тех же пользователей к одним и тем же данным).

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

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

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

  20. Пример необходимости использования параллельного доступа Могут быть выписаны 2 билета на одно место Покупка авиабилетов с 2-х разных терминалов на один рейс

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

  22. Блокировка данных Блокировки задерживают определенные операции с БД, пока другие операции или транзакции не завершены.

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

  24. Борьба с тупиками и бесконечными ожиданиями Блокировка всех элементов данных. Упорядочение элементов данных и запрос блокировок в этом порядке. Использование планировщика транзакций Использование контрольных точек. Контрольная точка- это фиксация состояния системы в некоторый момент времени. В случае обнаружения ошибок откат программы происходит к ближайшей контрольной точке. Но это требует дополнительного расхода памяти и времени. (SAVEPOINT)

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

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

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

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

  29. Схема выполнения транзакций Если Программа 1 выполняетобновление записи, то это изменение фиксируется на диске в сегменте отката. Пока не достигнута точка COMMIT, любой другой пользователь видит неизмененную запись. После команды COMMIT транзакция переписывается в журнал транзакций. Через буфер сервера СУБД обновленная запись БД запоминается в таблицах БД, т.е. изменения показываются другим пользвателям.

  30. Восстановление БД после сбоя во время транзакции После восстановления и перезагрузки после зависания в момент переписывания транзакции из сегмента отката в журнал транзакций СУБД автоматически пытается восстановить потерянные данные и целостность БД. СУБД находит в журнале транзакций последнюю с конца файла отметку о перезаписи файла на диск и выполняет ДОКАТ базы данных (начиная с этой отметки и до конца файла) СУБД выполняет ОТКАТ базы данных, чтобы устранить изменения, сделанные неполной транзакцией (читает с конца и до начала сегмента отката записи «до обновления» и записывает их в БД) Сегмент отката Начало сегмента Откат

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

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

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

  34. Журнализация БД Во всех трех случаях основой восстановления является избыточное хранение данных. Эти избыточные данные хранятся в журнале, содержащем последовательность записей об изменении базы данных.

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

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

  37. Обеспечение секретности и безопасности 2 2 2 2 КС - канал связи 5 6 7 5 6 8 К РС К РС К РС Узлы коммутации ЭВМ 1 4 1 4 1 3 1 1.Подключение к каналам связи. 2.Сбор электромагнитного излучения. 3.Ошибки коммутации. 4.Перекрестные помехи. 5.Отключение системы защиты. 6.Сбор "мусора". 7.Подглядывание, подслушивание. 8.Внесение ошибок в программные средства защиты и обработки данных. РС – рабочая станция

  38. Возможные нарушители • Категории лиц, могущие стать нарушителями системной защиты: • Пользователи. • Обслуживающий персонал: • Программисты. • Электронщики. • Вспомогательные подразделения. • Сторонние лица.

  39. Принципы построения системы защиты Простота. Открытость механизма защиты. Разделение полномочий. Минимальность полномочий. Максимальная обособленность механизма защиты. Психологическая привлекательность.

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

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

  42. Задачи и функции администратора БД Проектирует концептуальные модели Принимает участие в тестировании Организует обучение пользователей Разрабатывает стандарты на обозначение элементов данных и на процедуры обработки. Защита данных. Регистрация пользователей. Установка периодичности копирования БД Реорганизация базы данных

  43. Задачи системного администрирования • создание резервных копий файлов (для баз данных и проектов Access); • периодическое сжатие файлов (для баз данных); • защита файлов средствами шифрования (для баз данных); • изменение пароля для открытия файла (для баз данных); • управление учетными записями и правами доступа для приложений, защищённых на уровне пользователей (для баз данных и проектов) Установка и управление параметрами системы защиты на уровне пользователей для баз данных выполняются средствами Access, а для проектов — средствами SQL Server.; • установка приложения, разделенного на файл объектов данных и файл объектов приложения, на новую рабочую станцию и обновление ссылок на связанные таблицы (для баз данных); • установка клиентского приложения на новую рабочую станцию и корректное подключение ее к базе данных, установленной на сервере (для проектов).

  44. Безопасность и санкционирование доступа В контексте баз данных термин БЕЗОПАСНОСТЬ означает защиту данных от несанкционированного раскрытия, изменения или уничтожения. SQL позволяет индивидуально защищать как целые таблицы, так и отдельные их поля. Для этого имеются две более или менее независимые возможности: механизм представлений, используемый для скрытия засекреченных данных от пользователей, не обладающих правом доступа; подсистема санкционирования доступа, позволяющая предоставить указанным пользователям определенные привилегии на доступ к данным и дать им возможность избирательно и динамически передавать часть выделенных привилегий другим пользователям, отменяя впоследствии эти привилегии, если потребуется.

  45. Обычно при установке СУБД в нее вводится какой-то ИДЕНТИФИКАТОР, который должен далее рассматриваться как идентификатор наиболее привилегированного пользователя - системного администратора. Каждый, кто может войти в систему с этим идентификатором (и может выдержать тесты на достоверность), будет считаться системным администратором до выхода из системы. Системный администратор может создавать базы данных и имеет все привилегии на их использование. Эти привилегии или их часть могут предоставляться другим пользователям (пользователям с другими идентификаторами). В свою очередь, пользователи, получившие привилегии от системного администратора, могут передать их (или их часть) другим пользователям, которые могут их передать следующим и т.д.

  46. Предоставление привилегий Привилегии предоставляются с помощью предложения GRANT (предоставить) Общий формат: GRANT привилегии ON объект TO пользователи; "привилегии" – это список, состоящий из одной или нескольких привилегий, разделенных запятыми, либо фраза ALL PRIVILEGES (все привилегии); "объект" - имя и, если надо, тип объекта (база данных, таблица, представление, индекс и т.п.); "пользователи" - список, включающий один или более идентификаторов санкционирования, разделенных запятыми, либо специальное ключевое слово PUBLIC (общедоступный).

  47. Привилегии таблиц К таблицам (представлениям) относятся привилегии SELECT, DELETE, INSERT и UPDATE [(столбцы)], позволяющие соответственно считывать (выполнять любые операции, в которых используется SELECT), удалять, добавлять или изменять строки указанной таблицы (изменение можно ограничить конкретными столбцами). Например, предложение GRANT SELECT, UPDATE (Наим_дет) ON Детали TO vvu; позволяет пользователю, который представился системе идентификатором vvu, использовать информацию из таблицы Детали, но изменять в ней он может только значения столбца Наим_дет.

  48. Отмена привилегий Если пользователь USER_1 предоставил какие-либо привилегии другому пользователю USER_2, то он может впоследствии отменить все или некоторые из этих привилегий. Отмена осуществляется с помощью предложения REVOKE (отменить), общий формат которого очень похож на формат предложения GRANT: REVOKE привилегии ON объект FROM пользователи; Например, можно отобрать у пользователя user1 право изменения значений столбца Наим_дет: REVOKE UPDATE (Наим_дет) ON Детали FROM user1;

  49. Реорганизация базы данных • Любое изменение в структуре данных называется РЕОРГАНИЗАЦИЕЙ БД. • Различают реорганизацию на 3-х уровнях: • - концептуальный; • - логический; • - физический. • Как правило, реорганизация на каком-то уровне влечет реорганизацию на ниже лежащих уровнях: • Реорганизация на концептуальном уровне влечет расширение предметной области. • Реорганизация на логическом уровне влечет смену старой системы, уточнение логической модели. • Реорганизация на физическом уровне влечет увеличение скорости доступа, изменение структуры хранения (смена носителя, переполнение пространства).

More Related