Лекции и практики (1). Курс лекций и материалы для практических занятий

• Название: Курс лекций и материалы для практических занятий
• Дата: 17.03.2023
• Размер: 1.01 Mb.
• Имя файла: Лекции и практики (1).docx
• Тип: Курс лекций; #996812
• страница: 34 из 75

Обеспечение целостности данных

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

Рассмотрим различные типы ограничений целостности в языке SQL:

1. 
   Уникальность значения первичного ключа (PRIMARY KEY).
   
2. 
   Уникальность ключевого поля или комбинации значений ключевых полей:
   

UNIQUE(A),

где A – один или несколько атрибутов, указанных через запятую. (1,2 – явные структурные ограничения целостности.)

3. 
   Обязательность/необязательность значения (NOT NULL/NULL).
   
4. 
   Задание диапазона значений атрибута Field: CHECK(field BETWEEN min_value AND max_value)
   
5. 
   Задание взаимоотношений между значениями атрибутов Field1 и Field2:
   

CHECK (field1 @ field2),

где @ – оператор отношения (например, знак ">").

6. 
   Задание списка возможных значений (констант) для атрибута Field: CHECK (field IN (value1, value2,…, valueN)).
   
7. 
   Определение формата атрибута Field (даты, числа и др.). Например:
   

CHECK (field LIKE '_ _ _- ') -- формат телефонного номера

8. 
   Определение домена атрибута на основе значений другого атрибута: множе- ство значений некоторого атрибута отношения является подмножеством значений другого атрибута этого или другого отношения (внешний ключ, FOREIGN KEY).
   

(3.-8. – явные ограничения целостности на значения данных.)

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

Реализация ограничений целостности возлагается на СУБД или выполня- ется с помощью специальных программных модулей.

СУБД проводит проверку выполнения ограничений целостности для ко- манд DDL до выполнения команды, а для команд DML либо сразу после вы- полнения команды, либо после выполнения всей транзакции. (По стандарту ISO этим можно управлять; по умолчанию проверка проводится после каждой опе- рации DML).

2. Обеспечение безопасности данных

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

1. 
   Виды сбоев
   

В СУБД предусмотрены специальные механизмы, призванные нивелиро- вать последствия сбоев в работе базы данных. Рассмотрим наиболее типичные сбои и способы защиты от них:

1. 
   Сбой предложения.
   

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

2. 
   Сбой пользовательского процесса.
   

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

3. 
   Сбой процесса сервера.
   

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

4. 
   Сбой носителя (диска).
   

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

5. 
   Ошибка пользователя.
   

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

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

Лекция 10.Средства физической защиты данных

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

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

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

Создание частичной и инкрементной РК выполняется средствами СУБД, а создание полной РК – средствами СУБД или ОС (например, с помощью ко- манды copy). В резервную копию, созданную средствами СУБД, обычно вклю- чаются только те блоки памяти, которые реально содержат данные (т.е. пустые блоки, выделенные под объекты БД, в резервную копию не входят).

Периодичность резервного копирования определяется администратором системы и зависит от многих факторов: объём БД, интенсивность запросов к БД, интенсивность обновления данных и др. Как правило, технология проведе- ния резервного копирования такова:

• 
  раз в неделю (день, месяц) осуществляется полное копирование;
  
• 
  раз в день (час, неделю) – частичное или инкрементное копирование.
  

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

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

2. 
   Восстановление базы данных
   

В том случае, если нельзя восстановить БД после сбоя автоматически, восстановление БД выполняется в два этапа:

1. 
   перенос на рабочий диск резервной копии базы данных (или той её части, которая была повреждена);
   
2. 
   перезапуск сервера БД с повторным проведением всех транзакций, зафикси- рованных после создания резервной копии и до момента возникновения сбоя.
   

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

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

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

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

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

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

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

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

После выполнения этих этапов восстановления БД находится в согласованном состоянии и с ней можно работать.