НОУ ИНТУИТ | Лекция | Защитные механизмы операционных систем

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

Транзакции

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

Пример транзакции: выбор сведений из БД о заданном физическом лице; изменение паспортных данных; подтверждение изменений (сохранение).

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

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

2 Непротиворечивость, постоянство (consistency). После завершения транзакции система должна находиться в известном состоянии, т.е. транзакция не должна оставлять после себя следов. С точки зрения стороннего наблюдателя, система находится в непротиворечивом состоянии и до начала, и после завершения транзакции.

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

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

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

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

В стандарте SQL указывается, что транзакция запускается любым SQL оператором, выполняемым пользователем или программой (Select, Insert, Update), это, так называемый, неявный запуск транзакции. Вся выполняемая программа может рассматриваться СУБД как единая транзакция.

Завершение транзакции может быть выполнено одним из 4—х способов.

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

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

3 При внедрении SQL команды в текст программы успешное окончание работы программы автоматически вызовет завершение последней запущенной транзакции, даже если оператор Commit не был явно введен.

4 При внедрении SQL команды в текст программы аварийное завершение этой программы автоматически вызовет откат последней запущенной этой программой транзакции.

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

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

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

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

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

Рисунок 34 – Проблема утраченного обновления

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

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

Рисунок 35 – Проблема зависимости от незафиксированного обновления

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

3 Проблема несовместимого анализа. Параллельно выполняются два процесса обработки одних и тех же данных Д. Один пользователь создает отчет, который содержит как детальные, так и итоговые строки. Второй в это время изменяет данные, влияющие на формирование итоговых строк. Могут наблюдаться противоречия в отчете: сумма детальных строк может быть не равна итоговой цифре — целостность БД не нарушается, но документ неприемлем. Такая ситуация называется “проблемой несовместимого анализа”.

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

Блокировка данных

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

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

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

Влияние размеров блокируемых элементов на показатели производительности БД представлены в таблице 29.

Таблица 29 – Влияние размеров блокируемых элементов

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

1 Простая модель. Не вводится различие блокировок для операторов чтения и записи элемента данных Д. Используются две команды: установить блокировку элемента Д; снять блокировку элемента Д. При установке блокировки элемента Д предотвращается к нему доступ от других транзакций, как для выполнения операции чтения, так и для выполнения операции записи до тех пор, пока элемент Д не будет разблокирован. Это эксклюзивная или монопольная блокировка, она, как правило, автоматически устанавливается СУБД при выполнении команд Insert, Update.

2 Модель с блокировками для чтения и записи. В данной модели определено различие между видами доступа к элементу Д: доступ только для чтения; доступ только для записи. В связи с эти различают 2 типа команд блокировки:

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

б) команда блокировки элемента Д по чтению и записи. Эта команда соответствует команде блокировки простой модели, т.е. предотвращает доступ к элементу Д всем другим транзакциям.

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

Все блокировки снимаются командой «снять блокировку».

Любая блокировка осуществляются по следующим правилам.

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

2 Если элемент ещё не заблокирован какой—либо транзакцией, то блокировка будет выполнена успешно.

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

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

Для обеспечения нормальной работы системы необходимо помнить и выполнять некоторые правила.

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

2 Открывать БД в режиме разделения, если изменению данных предшествует иное их использование, а захват БД осуществлять позднее.

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

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

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

6 Отменить блокирование может только владелец. Отмена может быть неявной — новое блокирование отменяет предыдущее.

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

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

Пример ситуации бесконечного ожидания приведен на рисунке 36.

Рисунок 36 – Пример ситуации бесконечного ожидания

Предположим, что транзакции T1, T2, Т3, Т4 исполнения программы, содержащей следующие действия: блокирование Д; чтение Д; изменение Д; подтверждение сохранения Д; разблокирование Д. Не исключена возможность того, что транзакция Т2 будет бесконечно находиться в состоянии ожидания, тогда как некоторые другие транзакции постоянно осуществляют блокировку Д, хотя и существует неограниченное число моментов, когда Т2 имеет шансы заблокировать Д. Состояние такого рода называется бесконечным ожиданием. Подобная проблема потенциально может возникнуть в любой обстановке, предусматривающей параллельное исполнение процессов (задача продажи билетов).

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

Пример ситуации тупика приведен на рисунке 37. Есть две транзакции: транзакция Т1, содержащая команды, работающие с элементами данных А и В: LOCK(A); LOCK (B); …; UNLOCK (A); UNLOCK (B) и транзакция Т2: LOCK(B); LOCK (A); …; UNLOCK (B); UNLOCK (A). При этом не имеет значения, для каких процессов требуются элементы данных А и В в транзакциях Т1 и Т2 (команда LOCK – заблокировать элемент данных, команда UNLOCK – разблокировать элемент данных).

Рисунок 37 – Пример ситуации тупика

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

Способы предотвращения тупиков являются объектом исследования в области теории БД. Предлагаются различные методы разрешения тупиков.

1 Выполняется линейное упорядочивание элементов по какому—либо признаку (например, последовательно перечисляются все элементы, подлежащие блокированию) и вводится системное требование на составление запросов (программ): все запросы должны выполнять блокировки в этом порядке.

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

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

Блокировки предотвращают потерю изменений при параллельной обработке данных. Но существует ряд проблем, которые нельзя решить с помощью блокировок: «грязное чтение», «невоспроизводимое (неповторяемое) чтение», «фантомное чтение».

1 «Грязное чтение» (dirty reads). Одна транзакция изменяет некоторые данные, но еще не завершается. Другая транзакция читает эти же данные (с изменениями, внесенными первой транзакцией) и принимает на их основе какие—то решения. Первая транзакция выполняет откат. В результате решение, принятое второй транзакцией будет основано на неверных данных.

2 «Невоспроизводимое (неповторяемое) чтение» (nonrepeatable reads). Одна транзакция в ходе своего выполнения несколько раз читает одни и те же данные Д. Другая транзакция в интервалах между этими чтениями изменяет данные Д и успешно заканчивается. В результате получится, что чтения, осуществляемые первой транзакцией,дают разные результаты.

3 «Фантомное чтение» (phantoms reads). Одна транзакция в ходе своего выполнения несколько раз выбирает множество строк по одним и тем же критериям. Другая транзакция в интервалах между этими выборками добавляет или удаляет строки или изменяет столбцы некоторых строк, используемых в критериях выборки первой транзакции, и успешно заканчивается. В результате получится, что одни и те же выборки в первой транзакции дают разные множества строк.

Для определения допустимости тех или иных проблем можно определить уровни изоляции транзакций. Такие настройки можно сделать как в среде многопользовательской СУБД, так и в среде разработки приложений. Например, в среде Delphi установка уровней изоляции транзакций определяется свойством компонента Tdatabase property TransIsolation: TtransIsolation. Разработчик может указать желаемый уровень, а СУБД будет управлять транзакциями в соответствии с этими указаниями.

Уровни изоляции транзакций определяют:

— могут ли другие (конкурирующие транзакции) вносить изменения в данные, изменяемые текущей транзакцией;

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

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

1 Уровень изоляции Read Uncommetted (RU) — незавершенное, грязное чтение. На этом уровне запрещается изменение данных со стороны других транзакций, если эти данные модифицируются еще не окончившейся транзакцией. Иначе говоря, другие транзакции блокируются по записи для этих данных до тех пор, пока не окончится текущая транзакция. Однако другим транзакциям разрешается считывать еще не подтвержденные данные, что классифицируется как «грязное чтение».

2 Уровень Read Commetted (RC) — чтение данных. На этом уровне запрещается грязное чтение.

3 Repeatable Reads (RR) — воспроизводимое чтение. На этом уровне запрещается «грязное чтение» и «невоспроизводимое (неповторяемое) чтение».

4 Serializable (S) — сериализуемость. На этом уровне запрещается «фантомное чтение».

В таблице 30 приведены уровни изоляции транзакций и проблемы, которые они решают.

Таблица 30 – Уровни изоляции

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

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

Экспорт представляет собой логическое копирование БД, два остальных способа – физическое копирование файлов.

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

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

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

Одна из основных функций администратора БД – быть готовым к возможному отказу системы. В случае возникновения отказа база данных должна быть восстановлена быстро и с минимально возможными потерями. Процесс восстановления БД требует от АБД:

— определения, какие структуры базы данных затронуты и требуют восстановления;

— выполнения соответствующих шагов по восстановлению;

— рестарта экземпляра БД для восстановления его нормальной работоспособности;

— проверки, что в базе данных не остались некорректные данные, и действия пользователей не пропали.

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

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

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

Наиболее простой стратегией является возможность восстановления базы данных из её копии, которая периодически делается администратором БД. Затем при возникновении сбоя база данных восстанавливается, и заново производятся все утерянные транзакции, например, осуществляется повторный ввод данных, не отраженных в ранее сделанной копии. Такая стратегия для баз данных с большим числом пользователей может и не позволить вернуть систему в то состояние, в котором она находилась до сбоя из—за того, что при параллельной работе трудно восстановить и синхронизовать все действия пользователей. Какой—то объем данных будет утрачен.

Существует ещё один подход к восстановлению БД. Он заключается в том, чтобы периодически делать копии базы данных и вести журнал всех изменений, произведенных в базе данных транзакциями со времени последнего копирования. Восстановление в случае сбоя может быть произведено одним из двух методов. Первый – база данных восстанавливается до известного (отраженного в копии) состояния, после чего выполняются все правильные транзакции согласно записям в журнале. Метод называют «откат вперед» (rolling forward). Второй метод – в случае сбоя отменяются все ошибочные транзакции, затем запускаются правильные транзакции, которые выполнялись в момент сбоя – «откат назад», (rolling back). Для восстановления данных любым из этих методом требуется ведение журнала результатов транзакций. Современные СУБД имеют такие средства. Журнал транзакций позволяет сохранять действия, произведенных с данными в хронологическом порядке — прежде чем транзакция будет выполнена, она будет записана в журнал. В случае сбоя журнал используется как для отмены, так и для выполнения заданных транзакций. Журнал транзакций рекомендуется размещать на отдельном устройстве, что дает возможность повысить производительность и надежность системы баз данных:

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

— повышается скорость записи в журнал транзакций, так как операции ввода/вывода, разделенные между двумя устройствами, выполняются быстрее;

— рост объема журнала транзакций не понизит общую производительность системы;

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

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

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

Управление СУБД

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

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

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

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

Вопросы проектирования приложений БД

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

Основная функция приложения БД – обработка данных. Для баз данных определены четыре основные функции обработки: добавление и обновление данных, чтение и удаление.

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

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

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

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

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

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

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

Важным для автоматизированной информационной системы является адекватное, с точки зрения конечного пользователя, представление данных на интерфейсных формах ввода/ вывода, в различных документах и отчетах, формируемых прикладной программой. Данные, взятые из БД, могут иметь много различных форматов – каждый конечный пользователь определяет свой формат. Востребованным являются форматы MS Word, Excel, форматы интернет—страниц.

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

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