Файл: Тема концепция управления данными в современных информационных системах Цель лекции.docx

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

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

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

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

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

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

---

Основные возможности SQL:

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

2. На рис. 2.1 показаны основные компоненты СУБД.

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

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

Рис. 2.1. Основные компоненты СУБД.
Индексы - часть хранимых данных, а описание, указывающее какие атрибуты имеют индексы, часть метаданных.

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

---

В простых системах БД менеджером памяти может быть просто система файлов базовой ОС. Менеджер памяти состоит из двух компонентов:

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

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

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

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

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

Часто БД допускает параллельную поддержку множества транзакций («что-то» происходит на нескольких банкоматах одновременно). Гарантировать правильное выполнение всех таких транзакций – задача компонента СУБД, называемого менеджером транзакций. Основные требования, предъявляемые к выполнению транзакций (их называют ACID – свойства):

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

---

В верхней части рис.2.1 находятся три типа обращений СУБД:

1.Запросы – вопросы по поводу данных, которые генерируются двумя способами:

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

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

2.Модификации – это операции по изменению данных.

3.Модификации схемы – это команды, которые обычно даются персоналом, администраторами БД, имеющими право изменять схемы БД или создавать новую БД.

СУБД принято классифицировать по следующим аспектам:

1. 
   По языкам:
   
   1. 
      Открытые (используют универсальные языки программирования);
      
   2. 
      Замкнутые (собственные языки взаимодействия с пользователем);
      
   3. 
      Смешанные;
      
2. 
   По числу уровней в архитектуре:
   
   1. 
      Одноуровневые (физическая модель);
      
   2. 
      Двухуровневые (физическая, концептуальная модели);
      
   3. 
      Трехуровневые (физическая, концептуальная, внешняя модели);
      
3. 
   По функциям:
   
   1. 
      Информационные (допускают хранение и доступ к информации);
      
   2. 
      Операционные (хранение, доступ и обработка информации);
      
4. 
   По сфере применения:
   
   1. 
      Универсальные;
      
   2. 
      Специализированные;
      
5. 
   По типам данных:
   
   1. 
      С фиксированным набором типов данных;
      
   2. 
      Расширяемые (можно определять новые типы данных и операции над ними).
      

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

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

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

---

Сформулируем различия между соответствующими уровнями архитектуры базы данных.

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

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

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

Под схемой БД понимается общее описание БД. В соответствии с трехуровневой архитектурой различают три различных типа схем БД:

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

---