Шпаргалка по "Информатике"

Журнализация

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

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

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

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

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

Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Архивная копия - это полная копия БД к моменту начала заполнения журнала.

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

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

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

Язык SQL включает язык определения данных, язык манипулирования данными, язык запросов, язык управления данными.

 

2) СУБД определение,  функции

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

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

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

Типовая организация СУБД

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

- компилятор  языка SQL

- подсистема  поддержки времени исполнения, которая интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД

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

Функции СУБД

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

2. управление буферами оперативной памяти – обычно СУБД работает с БД значительного размера, по крайней мере этот размер обычно существенно больше доступного объема оперативной памяти. Если при обращении к элементу будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройств внешней памяти, поэтому единственный способ увеличить скорость является буферизация данных оперативной памяти, выполняемая самой СУБД, а не ОС.

3. управление транзакциями. Транзакция – последовательность операций над БД, рассматриваемых как единое целое.

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

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

С управлением  транзакциями в многопользовательской  СУБД связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций

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

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

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

5. поддержка языков БД

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

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

Язык SQL включает язык определения данных, язык манипулирования данными, язык запросов, язык управления данными.

 

 

3) СУБД определение,  классификация

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

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

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

Типовая организация СУБД

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

- компилятор  языка SQL

- подсистема  поддержки времени исполнения, которая  интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД

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

Классификация СУБД

1. По модели данных

- иерархические

- сетевые

- реляционные

- объектно-ориентированные

- объектно-реляционные

- пост-реляционные

2. По степени распределенности

- локальные  СУБД

- распределенные  СУБД

3. По способу доступа к БД

- файл-серверные

- клиент-серверные

- встраеваемые

 

Иерархическая БД

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

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

Сетевая БД

К основным понятиям сетевой модели базы данных относятся: уровень, элемент (узел), связь.

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

Характерной особенностью РБД является структура, выполненная  в виде таблиц. Строки таких таблиц соответствуют записям, столбцы - атрибутам (признакам хранимых данных).

Объектно-ориентированные  базы данных (ООБД) появились совсем недавно как естественное развитие объектно-ориентированных языков программирования.

Данные представлены в виде объектов различных классов.

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

Для доступа  к объектам, в каждой ООБД обычно предусматривается свой собственный язык, либо расширение другого языка. Пока еще ООБД недостаточно развиты и не представляют серьезной конкуренции SQL-серверам. Примеры, Cache, FastObjects,GemStone/S, Jasmine, ObjectStore и др

Объектно-реляционные БД

Разработчики  многих реляционных БД включают в свои базы средства работы с объектными типами данных.

 Такие базы  данных получили название объектно-реляционных. 

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

Пост-реляционными, часто называют многомерные базы данных.

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