gos_янв_2009 / 2.2. БД

1. Восстановление состояния базы данных. Типы сбоев и их последствия. Роль системного журнала в процедурах восстановления. Протокол WAL.

Восстановление базы данных может производиться в следующих случаях:

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

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

Жесткий сбой системы (аварийный отказ аппаратуры). Жесткий сбой характеризуется повреждением внешних носителей памяти. Жесткий сбой может произойти, например, в результате поломки головок дисковых накопителей.

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

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

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

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

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

2. Понятие функциональной зависимости атрибутов. Нормальные формы отношений. Процедура нормализации.

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

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

Е.Коддом выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме.

Первая нормальная форма Отношение называется нормализованным или приведенным к первой нормальной форме, если все его атрибуты простые (далее неделимы). Преобразование отношения к первой нормальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа. Например, отношение Студент = (Номер, Фамилия, Имя, Отчество, Дата, Группа) находится в первой нормальной форме.

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

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

Пример Отношение Студент = (Номер, Фамилия, Имя, Отчество, Дата, Группа) находится в первой и во второй нормальной форме одновременно, так как описательные реквизиты однозначно определены и функционально зависят от ключа Номер. Отношение Успеваемость = (Номер, Фамилия, Имя, Отчество, Дисциплина, оценка) находится в первой нормальной форме и имеет составной ключ Номер+Дисциплина. Это отношение не находится во второй нормальной форме, так как атрибуты Фамилия, Имя, Отчество не находятся в полной функциональной зависимости с составным ключом отношения.

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

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

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

3. Модель транзакции в SQL. Механизм представлений в SQL.

В SQL поддерживается классическое понимание транзакции, характеризуемое аббревиатурой ACID (от Atomicy, Consistency, Isolation и Durability). В соответствии с этим понятием под транзакцией разумеется последовательность операций (например, над базой данных), обладающая следующими свойствами.

Атомарность (Atomicy). Это свойство означает, что результаты всех операций, успешно выполненных в пределах транзакции, должны быть отражены в состоянии базы данных, либо в состоянии базы данных не должно быть отражено действие ни одной операции (конечно, здесь речь идет об операциях, изменяющих состояние базы данных). Свойство атомарности, которое часто называют свойством "все или ничего", позволяет относиться к транзакции, как к динамически образуемой составной операции над базой данных1).

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

Изоляция (Isolation). Требуется, чтобы две одновременно выполняемые транзакции3) никоим образом не действовали одна на другую. Другими словами, результаты выполнения операций транзакции T1 не должны быть видны никакой другой транзакции T2 до тех пор, пока транзакция T1 не завершится успешным образом.

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

Установка характеристик транзакции

У каждой выполняемой транзакции имеются три характеристики, значения которых существенно влияют на действия системы при управлении транзакцией, - уровень изоляции (isolation level), режим доступа (access mode) и размер области диагностики. При неявном образовании транзакции эти характеристики устанавливаются по умолчанию: транзакция получает максимальный уровень изоляции от одновременно выполняемых транзакций; режим доступа, позволяющий выполнять и операции выборки, и операции обновления базы данных; и назначаемый по умолчанию размер области диагностики.

Если значения характеристик транзакции, устанавливаемых по умолчанию, в некотором случае не являются пригодными, то до выполнения оператора, неявно инициирующего транзакцию, можно явно установить характеристики данной транзакции с использованием оператора SET TRANSACTION. Этот оператор определяется следующими синтаксическими правилами:

SET TRANSACTION mode_commalist

mode ::= isolation_level

| access_mode

| diagnostics_size

isolation_level ::= READ UNCOMMITED

| READ COMITTED

| REPEATABLE READ

| SERIALIZABLE

access_mode ::= READ ONLY

| READ WRITE

diagnostics_size ::= DIAGNOSTIC SIZE value_specification

Операцию установки характеристик транзакции нельзя выполнять в контексте какой-либо активной транзакции. Выполнение операции допустимо только до образования первой транзакции SQL-сессии или между последовательно выполняемыми транзакциями этой сессии. В одном операторе SET TRANSACTION можно задать только по одному значению каждой из трех характеристик, но допускается последовательное выполнение нескольких таких операций с разными операндами.

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

4. Подходы к ограничению доступа к данным в СБД.

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

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

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

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

Права можно разделить на три категории: права на доступ к объектам; права на выполнение команд (возможность создания объектов в базе данных, самой базы данных и выполнения процедуры резервного копирования); неявные права.

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

Каждая СУБД должна поддерживать механизм, гарантирующий, что доступ к базе данных смогут получить только те пользователи, которые имеют соответствующее разрешение. Язык SQL включает операторы GRANT и REVOKE, предназначенные для организации защиты таблиц в базе данных. Механизм защиты построен на использовании идентификаторов пользователей, предоставляемых им прав владения и привилегий.

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

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

Привилегиями, или правами, называются действия, которые пользователь имеет право выполнять в отношении данной таблицы базы данных или представления. В стандарте SQL определяется следующий набор привилегий:

SELECT – право выбирать данные из таблицы;

INSERT – право вставлять в таблицу новые строки;

UPDATE – право изменять данные в таблице;

DELETE – право удалять строки из таблицы;

REFERENCES – право ссылаться на столбцы указанной таблицы в описаниях требований поддержки целостности данных;

USAGE – право использовать домены, проверки и наборы символов.

8. Реляционные исчисления (РИ). Правильно построенные формулы РИ с переменными-кортежами.

Реляционное исчисление (РИ) абстрактный язык манипулирования реляционными данными. РИ есть просто система обозначений для определения производного отношения в терминах других отношений. Для формул РИ процедурной интерпретации нет. Они декларативны. Формула просто определяет условия, которым должны удовлетворять кортежи результирующего отношения, – требуемые данные. Однако можно и не указывать, какие соединения, проекции и селекции строить. Можно сформулировать на некотором формальном языке фразу следующего содержания: «Получить значения атрибута Sn для таких поставщиков, для которых в SPJ существуют кортежи с тем же значением атрибута S# и со значением атрибута P# = ‘P2’.»

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

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

РИ с переменными-кортежами. Пусть R – некоторое отношение. Величина t, значениями которой являются кортежи отношения R, называется переменной-кортежем, определенной на R. На интуитивном уровне переменная-кортеж это перемещающееся по строкам таблицы окно, в котором всегда видна одна строка – текущее значение переменной.

Правильно построенные формулы (ППФ) – это предикат первого порядка. ППФ может содержать кванторы EXISTS (существует) и FORALL (для всякого). Выражение EXISTS SX (SX.Ci = ‘Яя’) может быть прочитано так: «Существует в области определения переменной SX кортеж со значением атрибута Ci равным ‘Яя’». Предикат принимает значение .T., если в текущем значении отношения S есть хотя бы один кортеж со значением Ci = ‘Яя’. если R – некоторое отношение, t – переменная, определенная на R, t₁, t₂, …, t_n – значения t (кортежи R), a f(t) – ППФ, то формула EXISTS t (f(t)) равносильна бескванторной формуле .F. OR f(t₁) OR f(t₂) OR … OR f(t_n). Выражение FORALL SX (SX. Ci = ‘Яя’) может быть прочитано так: «В каждом кортеже отношения S значение атрибута Ci равно ‘Яя’». В предыдущих обозначениях формула FORALL t (f(t)) равносильна бескванторной формуле .Т. AND f(t₁) AND f(t₂) AND … AND f(t_n). Очевидно, FORALL t (f(t)) равносильно NOT EXISTS t (NOT (f(t)). Переменная t, входящая в ППФ, называется связанной или свободной в зависимости от того, действует ли на формулу квантор по t.

Примеры: f(t) – переменная t свободная; f(t, q) – переменные t и q свободные; EXISTS t (f(t, q)) – переменная t связанная, q – свободная; FORALL t (f(t)) AND g(t) - первое вхождение t – связанное, второе – свободное.

В последней формуле одним и тем же символом t обозначены разные переменные, возможно, определенные на одной и той же области. В первой подформуле можно изменить имя переменной, не меняя смысла высказывания и значения предиката. Переменная служит здесь лишь для связи внутренних параметров предиката f( ) с внешним квантором. Второе вхождение переменной t имеет совершенно иной смысл. Здесь g(t) принимает то или иное значение в зависимости от значения переменной t. Заменить t на x, например, здесь нельзя, поскольку х и t могут принимать различные значения. Связанная переменная подобна локальной переменной в языках программирования. Формула, в которой все переменные связаны, называется закрытой. Например, FORALL x (EXISTS y (f(x, y))) – закрытая формула. Формула, содержащая по крайней мере одну свободную переменную, называется открытой.

6. Понятие транзакции. Свойства АСИД.

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

Транзакция обладает четырьмя важными свойствами, известными как свойства АСИД:

(А) Атомарность. Транзакция выполняется как атомарная операция - либо выполняется вся транзакция целиком, либо она целиком не выполняется.

(С) Согласованность. Транзакция переводит базу данных из одного согласованного (целостного) состояния в другое согласованное (целостное) состояние. Внутри транзакции согласованность базы данных может нарушаться.

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

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

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

Команда COMMIT WORK завершает текущую транзакцию и автоматически начинает новую транзакцию. При этом гарантируется, что результаты работы завершенной транзакции фиксируются, т.е. сохраняются в базе данных. Некоторые системы (например, Visual FoxPro), требуют подать явную команду BEGIN TRANSACTION для того, чтобы начать новую транзакцию.

Команда ROLLBACK WORK приводит к тому, что все изменения, сделанные текущей транзакцией откатываются, т.е. отменяются так, как будто их вообще не было. При этом автоматически начинается новая транзакция.

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

Свойство Д (долговечность) также не является абсолютными свойством, т.к. некоторые системы допускают вложенные транзакции. Если транзакция Б запущена внутри транзакции А, и для транзакции Б подана команда COMMIT WORK, то фиксация данных транзакции Б является условной, т.к. внешняя транзакция А может откатиться. Результаты работы внутренней транзакции Б будут окончательно зафиксированы только если будет зафиксирована внешняя транзакция А.

7. Проблема синхронизации транзакций. Двухфазный протокол синхронизационных блокировок.

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

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

Различают три основные проблемы параллелизма: проблема потери результатов обновления; проблема незафиксированной зависимости (чтение "грязных" данных, неаккуратное считывание); если не предпринимать специальных мер, то при работе в смеси нарушается свойство (И) транзакций - изолированность. Транзакции реально мешают друг другу получать правильные результаты.

Транзакции называются конкурирующими, если они пересекаются по времени и обращаются к одним и тем же данным. В результате конкуренции за данными между транзакциями возникают конфликты доступа к данным. Различают следующие виды конфликтов: W-W (Запись - Запись). Первая транзакция изменила объект и не закончилась. Вторая транзакция пытается изменить этот объект. Результат - потеря обновления. R-W (Чтение - Запись). Первая транзакция прочитала объект и не закончилась. Вторая транзакция пытается изменить этот объект. Результат - несовместимый анализ (неповторяемое считывание). W-R (Запись - Чтение). Первая транзакция изменила объект и не закончилась. Вторая транзакция пытается прочитать этот объект. Результат - чтение "грязных" данных. Конфликты типа R-R (Чтение - Чтение) отсутствуют, т.к. данные при чтении не изменяются.

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

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

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

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

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

Протокол предусматривает две фазы выполнения транзакции: фазу наложения блокировки и фазу снятия блокировки. В первой происходит накопление захватов, во второй – освобождение всех захваченных объектов. Если все транзакции соблюдают двухфазный протокол блокировки, то коллизии потерянных изменений, «грязных» и неповторяющихся чтений невозможны. Однако коллизия фантомов может возникать или не возникать в зависимости от того, какое подмножество данных рассматривается системой как объект захвата. Предположим, что объектом захвата является кортеж отношения. Тогда транзакцией Т1 для выполнения операции чтения будут заблокированы в разделяемом режиме все существующие кортежи отношения R, удовлетворяющие условию выборки S. Но транзакции Т2 для выполнения операции вставки кортежа не нужно блокировать эти кортежи. Она должна «заблокировать» новый. Таким образом, не нарушая двухфазного протокола блокировки, транзакция Т2 может добавить кортеж в отношение R. Если же объектом блокировки является отношение, то коллизия фантомов возникнуть не может и двухфазный протокол блокировки обеспечивает абсолютную изолированность транзакций.

5. Модель "сущность - связь". Назначение модели. Понятия сущности, связи, атрибута. Типы связей.

Модель типа “сущность-связь” – это неформальная модель предметной области, которая используется при проектировании БД. Эта модель позволяет моделировать объекты ПО и взаимоотношения объектов. Относительная простота, применение естественного языка и легкость понимания позволяет использовать модель как инструмент для общения с будущими пользователями для сбора информации о предметной области для проектирования БД. Основное назначение неформальной модели “сущность - связь” – смысловое описание предметной области и представление информации для обоснования выбора видов моделей и структур данных, которые в дальнейшем будут использованы в системе.

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

Атрибут – это поименованная характеристика сущности, которая принимает значения из некоторого множества значений. В модели атрибут выступает в качестве средства, с помощью которого моделируются свойства сущностей. Например, для описания сущности книга, можно использовать атрибуты: Название, Фамилия автора, Год издания. Чтобы задать атрибут в модели, необходимо присвоить ему наименование, привести смысловые описания, определить множество его допустимых значений и указать для чего он используется. Основное назначение атрибута – описание свойства сущности, а также идентификации экземпляров сущностей. Например, атрибут шифр - детали, которому соответствует множество уникальных значений шифров деталей, позволяет однозначно идентифицировать конкретные экземпляры сущности деталь в соответствующем наборе. Атрибут можно использовать и для представления связей между сущностями, поскольку связь (отношение) характеризует именно те объекты, между которыми она существует (например, Отец – характер родства) и потому может выступать в роли свойства, признака сущности.

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

Отображение 1:1 (связь один к одному). С помощью отображения 1:1 определяют такой тип связи между типами сущностей А и В когда каждому экземпляру сущности А соответств. один и тот же экземпляр сущности В и наоборот, каждому экземпляру сущности В соответствует один и только один экземпляр сущности А. Идентификация экземпляров сущностей уникальна в обоих направлениях для отображения 1:1.

Отображение 1:М (связь один по многим). С помощью отображения 1:М определяется тип связи между типами сущностей А и В, когда одному экземпляру сущности А может соответств. 0,1 или несколько экземпляров сущности В, однако каждому экземпляру сущности В соответствует только один экземпляр сущности А. Идентификация экземпляров при отображении 1:М уникальна только в направлении от В к А.

Отображение М:1 (связь многие к одному). Отображение является обратным отображению 1:М.

Отображение М:N(связь многих-ко-многим). С помощью отображения М:N определяется тип связи между типами сущностей А и В, при котором каждому экземпляру сущности А может соответствовать 0,1 или несколько экземпляров сущности В и наоборот. Идентификация экземпляров сущностей неуникальна в обоих направлениях.

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

9. Назначение и составные части реляционной модели данных. Понятия домена, атрибута, схемы отношения, кортежа, отношения. Свойства отношений.

Базы данных всегда создаются для хранения сведений об определенном виде деятельности. Часть реального мира, сведения о которой хранятся в БД, называется предметной областью базы данных. Единицей хранящейся в БД информации является таблица. Каждая таблица представляет собой совокупность строк и столбцов, где строки соответствуют экземпляру объекта, конкретному событию или явлению, а столбцы - атрибутам (признакам, ха­рактеристикам, параметрам) объекта, события, явления. В терминах БД столбцы таблицы называются полями, а ее строки - записями.

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

Основой современной технологии БД, без сомнения, является реляционная модель, именно эта основа делает область технологии БД наукой. В реляционной модели рассматривается три аспекта данных – структура данных (объекты данных), целостность данных и обработка данных (операторы). Рассмотрим подробней эти части.

• Отношение соответствует тому, что мы называем таблицей.

• Кортеж соответствует строке этой таблицы, а атрибут – столбцу. Количество кортежей называются кардинальным числом, а количество атрибутов – степенью.

• Первичный ключ – это уникальный индикатор для таблицы, т.е. столбец или такая комбинация столбцов, что в любой момент времени не существует 2-х строк, содержащих одинаковое значение в том столбце или комбинации столбцов.

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

- Именованное отношение – это отношение, имя и определение схемы которого сохранены в системном каталоге. Именованное отношение может быть базовым или производным.

- Производное отношение есть отношение, определенное посредством реляционного выражения через именованные отношения. Производное отношение может быть именованным или неименованным.

- Базовое отношение – именованное отношение, не являющееся производным.

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

10. Организация данных SQL-системы. Объекты, схема, каталог, кластер.

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

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

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

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

Таблица является фундаментальной информационной структурой SQL-системы. Результаты всех операций над данными выражаются в табличной форме. Само описание базы данных – системный каталог – представляет собой набор таблиц, содержащих информацию об объектах БД. Кроме базовых таблиц, физически сохраняемых во внешней памяти, в схеме могут быть определены виртуальные таблицы – представления. Представление (VIEW) есть объект, содержащий именованный запрос, на который можно ссылаться в операторах манипулирования данными. Механизм представлений обеспечивает возможность предъявления хранимых данных в удобной и привычной для конечного пользователя форме.

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

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

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

11. Операции реляционной алгебры. Синтаксис выражений.

Реляционная алгебра (РА) – один из имеющихся в реляц. модели данных механизмов манипулирования данными на уровне множеств кортежей. Первый вариант набора операций РА был предложен Э.Коддом в 1970 г. Он содержал 8 операций. Позднее различными авторами были предложены различные дополнения этого набора. Операндами операций РА являются отношения. Всякая операция РА производит отношение, формируя по определенным правилам схему и тело производного отношения из атрибутов и кортежей операндов. Реляционная алгебра замкнута относительно множества отношений. Из имен отношений, знаков операций РА и скобок можно строить выражения произвольной степени сложности. Очень сложные запросы к реляционной БД можно сформулировать в виде одного выражения РА. Поэтому реляционная алгебра обладает большой выразительной мощностью. Поскольку отношения – это множества, то операции РА основаны на теоретико-множественных операциях. Однако отношения – множества с особыми свойствами, поэтому в РА входят также специфические операции, которые могут быть определены только на множествах отношений. Выделяют две группы операций РА. Теоретико-множественные операции: объединение; разность; пересечение; расширенное прямое произведение. Специальные реляционные операции: переименование; селекция (ограничение, выборка); проекция; соединение по условию; естественное соединение; взятие реляционного частного (реляционное деление). Этот набор операций избыточен, так как некоторые из них выражаются через другие. Тем не менее, все они включаются в состав алгебры как элементарные, исходя из интуитивных потребностей пользователей БД. Поскольку результатом любой реляционной операции (кроме операции присваивания) является некоторое отношение, можно образовывать реляционные выражения, в которых вместо отношения-операнда некоторой реляционной операции находится вложенное реляционное выражение. Для алгебры, у которой операции замкнуты относительно понятия отношения, каждая операция должна производить отношение с двумя составляющими: телом и заголовком. Только в этом случае будет действительно возможно строить вложенные выражения. Операции объединения, пересечения взятия разности (вычитания) требуют от отношений-операндов совместимых по типу. Два отношения называются совместимыми по типу, если каждое из них имеет одинаковое множество имен атрибутов и если соответствующие атрибуты определены на одном и том же домене. Если необходимо выполнить операцию объединения, пересечения или вычитания двух отношений, которые почти совместимы по типу, за исключением некоторых различий в именах атрибутов, можно использовать оператор переименования, чтобы сделать эти отношения полностью совместимыми по типу, прежде чем выполнить необходимую операцию. Синтаксис реляционных выражений. Определим теперь синтаксис для операций РА. Основной синтаксической единицей является выражение РА, производящее отношение. Любое выражение является безымянным производным отношением. Здесь атрибут – идентификатор, список – список разделенных запятыми атрибутов, константа – литеральное значение.

12. Операторы обновления данных в SQL.

Оператор SELECT, может использовать в качестве источника данных любую совокупность именованных таблиц. Существует единственное ограничение: ID, издавший оператор, должен иметь привилегии на просмотр всех таблиц источника. В отличие от этого операторы обновления данных всегда используют в качестве приемника данных одну именованную таблицу – базовую или представление. Если приемником является представление, то оно должно быть обновляемым. В любом случае реально обновляются только базовые таблицы. Порядок исполнения операторов обновления следующий. Приняв оператор, система считывает из Физич. БД в свой рабочий буфер обновляемую базовую таблицу. Все изменения данных выполняются в этой копии. Обновленная таблица переносится из рабочего буфера в ФБД, только если транзакция, содержащая оператор обновления, завершилась успешно. В противном случае рабочий буфер очищается, и никаких изменений в ФБД не происходит. Действие операторов ограничено не только привилегиями пользователя, но и правилами целостности данных, объявленными в определениях объектов схемы. Исполняющая система автоматически проверяет все ограничения, которые могут быть нарушены вследствие предложенных изменений данных. Если хотя бы одно из них нарушается, операция обновления будет отвергнута. Если правилами целостности в связи с предложенными изменениями предусмотрены каскадные обновления других объектов, они выполняются автоматически. Порядок выполнения этих не заданных явно обновлений такой же. Рассмотрим теперь синтаксис операторов обновления.

Оператор INSERT в общем случае добавляет в указанную таблицу группу строк. Группа может быть либо результатом запроса, либо явно заданным списком строк – конструктором значений таблицы. Результат запроса или строки конструктора могут содержать значения части столбцов обновляемой таблицы. В этом случае имена этих столбцов должны быть указаны списком имен столбцов. Вот синтаксическая диаграмма оператора, соответствующая определению SQL2:

INSERT INTO имя_таблицы [ (имя_столбца.,..) ]

запрос

конструктор_значений_таблицы

| { DEFAULT VALUES };

Здесь имя_столбца – имя столбца обновляемой таблицы. Список имен можно не указывать, если добавляемые строки содержат значения для всех столбцов таблицы. Столбцам, не вошедшим в список, в новых строках будут присвоены значения по умолчанию, если они определены, либо NULL-значения. Если для какого-либо столбца это невозможно (например, столбец определен как NOT NULL, а значение по умолчанию не задано), операция будет прервана.

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

13. Назначение модели данных IDEF1X. Компоненты модели. Нотации графического языка IDEF1X. Уровни модели. Этапы моделирования.

Сущность в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друг от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира. Примером сущности IDEF1X может быть сущность "СОТРУДНИК", которая представляет собой всех сотрудников предприятия, а один из них, скажем, Иванов Петр Сергеевич, является конкретной реализацией этой сущности. В примере, каждый экземпляр сущности СОТРУДНИК содержит следующую информацию: ID сотрудника, имя сотрудника, адрес сотрудника и т.п. В IDEF1X модели эти свойства называются атрибутами сущности. Каждый атрибут содержит только часть информации о сущности.

Связи в IDEF1X представляют собой ссылки, соединения и ассоциации между сущностями. Связи это суть глаголы, которые показывают, как соотносятся сущности между собой. При создании сущности в IDEF1X модели, одним из главных вопросов, на который нужно ответить, является: "Как можно идентифицировать уникальную запись?". Для этого требуется уникальная идентификация каждой записи в сущности для того, чтобы правильно создать логическую модель данных. Правила устанавливают, что атрибуты и группы атрибутов должны:

-Уникальным образом идентифицировать экземпляр сущности.

-Не использовать NULL значений.

-Не изменяться со временем. Экземпляр идентифицируется при помощи ключа. При изменении ключа, соответственно меняется экземпляр.

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

Если сущности в IDEF1X диаграмме связаны, связь передает ключ (или набор ключевых атрибутов) дочерней сущности. Эти атрибуты называются внешними ключами. Внешние ключи определяются как атрибуты первичных ключей родительского объекта, переданные дочернему объекту через их связь. Передаваемые атрибуты называются мигрирующими.

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

Зависимые сущности классифицируются на сущности, которые не могут существовать без родительской сущности и сущности, которые не могут быть идентифицированы без использования ключа родителя (сущности, зависящие от идентификации). Сущность СОТРУДНИК принадлежит ко второму типу зависимых сущностей, так как сотрудники могут существовать и без отдела. Сущности, независящие при идентификации от других объектов в модели, называются независимыми сущностями. В IDEF1X независимые сущности представлены в виде прямоугольников.

Стандарт IDEF1X дает следующее определение модели данных:

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

графический – средства создания диаграмм, показывающих структуру и взаимосвязи данных; текстовый – правила создания и ведения текстовых документов, уточняющих и поясняющих графическую модель, – глоссариев, спецификаций, отчетов, заметок и т.п. В IDEF1Х различают три уровня графического представления информации, или три уровня диаграмм. Уровень «сущность-связь» (ER level). Это уровень наименее детального представления информации. Он используется на начальной стадии моделирования, когда еще не выяснены или не поняты до конца свойства сущностей и связей. На диаграммах ER-уровня сущности и связи представлены только их именами. Уровень ключей (Key-Based Level, KB). На этом уровне в диаграммах отражаются имена первичных и внешних ключей сущностей и спецификации связей. Диаграмма KB-уровня объявляет уникальные идентификаторы экземпляров сущностей и ограничения ссылочной целостности.

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

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

14. Функции СУБД (8 сервисов Кодда).

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

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

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

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

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

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

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

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

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

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

15. Назначение и составные части реляционной модели данных (РМД). Внутренние ограничения целостности РМД. Механизмы поддержания целостности реляционной базы данных.

Основы реляционной модели данных были впервые изложены в статье Е.Кодда в 1970 г. Эта работа послужила стимулом для большого количества статей и книг, в которых реляционная модель получила дальнейшее развитие. Наиболее распространенная трактовка реляционной модели данных принадлежит К.Дейту. Согласно Дейту, реляционная модель состоит из трех частей: - Структурной части. - Целостной части. - Манипуляционной части.

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

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

Выделяют три разновидности внутренних ограничений целостности: целостность домена, целостность сущности, ссылочная целостность.

Целостность домена. Домены являются одной из важнейших составляющих РМД. Механизм доменов обеспечивает: - принципиальную возможность ограничения сравнений и блокирования бессмысленных операций в БД; - принципиальную возможность формального контроля ввода данных. Правило целостности домена: всякий атрибут может принимать значения только из своего домена. Это означает, что в любой РБД для каждого атрибута должно существовать правило, определяющее допустимость значений. Правило целостности домена – это метаправило, правило о правилах.

Целостность сущности. Правило целостности сущности - в БД не должна храниться информация о чем-то таком, что мы не можем идентифицировать. Это требование связано с проблемой представления незнания в БД. Во всех случаях, прежде чем заносить информацию в БД, необходимо идентифицировать эту информацию, т.е. задать определенное значение первичного ключа. Если допустить возможность неопределенных значений первичного ключа, то будет разрушен механизм адресации РМД. Правило целостности сущности: ни один компонент первичного ключа отношения не может принимать неопределенное значение. Это, как и требование целостности домена, метаправило. Оно означает, что в схеме конкретной РБД должны быть определены первичные ключи всех отношений. Тогда РСУБД не допустит появления кортежей с Null-значениями соответствующих атрибутов.

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

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

- Операции обновления и целостность данных В любой реляционной БД имеется три типа операций обновления базовых отношений: INSERT – вставить кортеж в отношение; DELETE – удалить кортеж из отношения; UPDATE – обновить значение атрибута(ов) в кортеже. Таким образом, выполнение операций INSERT и UPDATE должно сопровождаться (в общем случае) проверками всех трех типов правил целостности. При выполнении операции DELETE необходимо проверять только ссылочную целостность.

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

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

- Контроль ссылочной целостности. Требование ссылочной целостности накладывает ограничения на все три операции обновления БД. Операция INSERT. Эта операция затрагивает только одно отношение. Если вставляется кортеж в отношение, не являющееся потомком ни в какой связи, то ссылочная целостность не может быть нарушена. Просто в БД появится новый кортеж, на который нет ссылок. Операции DELETE и UPDATE. Удаление кортежа отношения, не являющегося ссылочным ни для какого другого, не может привести к нарушению ссылочной целостности. Таким образом, операции удаления/обновления родительского ключа затрагивают, по крайней мере, два отношения – ссылочное и ссылающееся. Для того чтобы система могла поддерживать ссылочную целостность при выполнении этих операций, нужно сообщить ей, что она должна делать с кортежами-потомками удаляемого кортежа-родителя, т.е. определить правило внешнего ключа. Правила внешних ключей устанавливаются для каждого из отношений(ссылочного и ссылающегося) индивидуально. Операции удаления/обновления всегда атомарны. Либо выполняются все определенные правилами изменения в группе отношений, затронутых операцией, либо не выполняется ни одно, и состояние БД остается неизменным.

16. Организация процессов обработки данных в системах оперативной обработки транзакций.

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

• фиксацией внесенных изменений;

• отменой проделанных изменений (откатом);

• успешным завершением прикладной программы с фиксацией изменений, внесенных последней исполнявшейся транзакцией;

• аварийным завершением прикладной программы с откатом последней исполнявшейся транзакции.

В двух последних случаях новая транзакция не начинается, поскольку прикладная программа завершилась.

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

Таблица Уровни изолированности транзакции

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

Уровень REPEATABLE READ допускает появление строк-фантомов. Его следует устанавливать в том случае, если транзакции не требуется повторно выполнять один и тот же многострочный запрос.

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

В режимах REPEATABLE READ и READ COMMITED на транзакцию могут повлиять только окончательные (зафиксированные) результаты параллельно исполняющихся транзакций. В режиме READ UNCOMMITED ей доступны и промежуточные результаты. Этот режим можно использовать лишь в том случае, когда допустимы «грязные» данные в результатах запросов.

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

17. Понятие базы данных. Структурные единицы БД. Метаданные и индексы.

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

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

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

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

Введем некоторые замечания:

1. Компьютерные файлы часто называют таблицами, а не файлами.

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

3. Отношение соответствует тому, что мы до сих пор называли таблицей.

4. Кортеж соответствует строке этой таблицы, а атрибут – столбцу. Количество кортежей называются кардинальным числом, а количество атрибутов – степенью.

5. Первичный ключ – это уникальный индикатор для таблицы, т.е. столбец или такая комбинация столбцов, что в любой момент времени не существует 2-х строк, содержащих одинаковое значение в том столбце или комбинации столбцов.

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

Словарь данных представляет собой подсистему банка данных, предназначенную для централизованного хранения информации о структурах данных, взаимосвязях файлов баз данных друг с другом, типах данных и форматах их представления, принадлежности данных пользователям, кодах защиты и разграничения доступа и т.п. Функционально словарь данных присутствует во всех банках данных, но не всегда выполняющий эти функции. Сам словарь данных вполне можно считать самостоятельной базой данных (но не пользовательской, а системной). Словарь содержит «данные о данных» (иногда называемые метаданными или дескрипторами), т.е. определения других объектов системы, а не просто обычные данные. Иначе говоря, метаданные – это детальная информация, касающаяся различных объектов, которые имеют значение для самой системы. Примерами таких объектов могут служить переменные-отношения, индексы, ограничения поддержки целостности, ограничения защиты и т.д. Метаданные необходимы для обеспечения правильной работы системы. Например, оптимизатор использует информацию каталога об индексах и других физических структурах хранения данных, а также иную информацию, необходимую ему для принятия решения о том, каким образом выполнить тот или иной запрос пользователя. Аналогично подсистема защиты использует информацию каталога о пользователях и установленных ограничениях защиты, чтобы разрешить или отклонить выполнение поступившего запроса.

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

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

18. Жизненный цикл системы с базами данных. Фазы проектирования БД.

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

ЖЦБД состоит из следующих этапов:

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

2. Проверка осуществимости. Здесь определяется технологическая, операционная и экономическая осуществимость плана создания БД, т. е.: · технологическая осуществимость – есть ли технология для реализации запланированной БД?

· операционная осуществимость – есть ли средства и эксперты, необходимые для успешного осуществления плана создания БД? · экономическая целесообразность – можно ли определить выводы? Окупится ли запланированная система? Можно ли оценить издержки и выгоду?

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

4. Концептуальное проектирование – создание концептуальной схемы БД. Спецификации разрабатываются в той степени, которая необходима для перехода к реализации. Основным выходным документом является единая инфологическая модель (или схема БД на концептуальном уровне). При разработке данной модели используются информация и функции, которые должна выполнить система, определённые на этапе сбора и определения требований к системе. На данном этапе желательно также определить: 1) правила для данных; 2) правила для процессов; 3) правила для интерфейса.

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

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

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

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

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

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

19. Трёхуровневая архитектура СУБД.

Различие между логическим и физическим представлением данных официально признано в 1978 году, когда комитет ANSI/SPARC предложил обобщенную структуру систем баз данных. Эта структура получила название трехуровневой архитектуры. Три уровня архитектуры следующие: внутренний, концептуальный и внешний.

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

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

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

Пример. Пусть в нашей ПО имеется объект СЛУЖАЩИЙ, характеризующийся свойствами

и есть два конечных пользователя БД – КП1 и КП2. Для КП1 представляют интерес только табельный номер и номер отдела, для КП2 – табельный номер и зарплата. Объект имеет три уровня представления или описания.

На внешнем уровне показаны два представления объекта СЛУЖАЩИЙ для различных конечных пользователей. Каждому из них обслуживающая его ПП предоставляет ту информацию о СЛУЖАЩем, в которой он заинтересован, скрывая другие характеристики.

Внешний уровень 1 (COBOL) Внешний уровень 2 (PL/1)

01 EMP# DCL 1 EMP

02 ЕМPNO PIC X (6) 2 EMP CHAR (6)

02 DEPNO PIC X (4) 3 SAL FIXED BIN (31);

Первые строчки этих текстов объявляют имена объекта. Вторые и третьи строчки указывают имена и типы характеристик объекта. Для КП1 – это табельный номер и номер отдела, а для КП2 – табельный номер и зарплата. Отметим, что в разных представлениях имена объекта и его характеристик могут быть различными.

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

Концептуальный уровень

СЛУЖАЩИЙ

Номер служащего CHAR (6)

Номер отдела CHAR (4)

Зарплата NUMERIC (5)

Из приведенного описания совершенно не видно, как эта информация организована в памяти ЭВМ. Пользователю не нужно это знать. На внутреннем уровне объект СЛУЖАЩИЙ представлен типом внутренней записи STORED_EMP.

Внутренний уровень

Указана длина записи – 20 байт. Запись состоит из четырех хранимых полей – PREFIX, EMP#, DEPT# и PAY. Поле PREFIX содержит необходимую служебную информацию. Три поля данных соответствуют свойствам СЛУЖАЩего. Поле EMP# связано с индексом ЕМРХ, обеспечивающим быстрый поиск по значениям ЕМР#. Этот индекс определен на внутреннем уровне, но не виден уже на концептуальном.

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

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

Рис. Доступ к данным в СБД

Шаг 1. ПП обращается к СУБД с запросом на чтение записи внешней модели.

Шаг 2. СУБД, используя схемы ВМД и КМД и описание отображения внешний  концептуальный, определяет, какие записи КМД необходимы для формирования требуемой записи ВМД.

Шаг 3. СУБД, используя схемы КМД и В_НМД и описание отображения концептуальный  внутренний, определяет, какие записи внутренней модели необходимы для формирования затребованных записей КМД и совокупность физических записей, которые должны быть для этого считаны с физического носителя.

Шаг 4. СУБД выдает ОС запрос на считывание в свои буферы необходимых записей физической базы данных (ФБД).

Шаг 5. ОС считывает затребованные записи и помещает их в системные буферы СУБД.

Шаг 6. На основании имеющихся схем моделей и описаний отображений СУБД формирует в своем буфере затребованную внешнюю запись.

Шаг 7. СУБД пересылает сформированную внешнюю запись в рабочую область (РО) ПП.

Шаг 8. СУБД передает в ПП сообщение о результатах выполнения запроса.

Процедура записи данных из ПП в ФБД выполняется аналогично.