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

Допустим, что необходимо одновременно изменить несколько взаимосвязанных записей. Часто, для описания такой ситуации используется пример с банкоматом. Пользователь банковского терминала запускает транзакцию: вставляет в машину кредитную карту, вводит идентификационный код и выбирает тип транзакции. В результате этого клиентская запись считывается из базы данных центрального компьютера, который может располагаться на другом конце города или земного шара. Если клиент запрашивает выдачу наличности, то по содержимому записи проверяется, достаточен ли остаток денег на счете. Затем остаток уменьшается на затребованную величину и банкомату посылается команда на выдачу денег. Что если случилась поломка, и банкомат не может выдать наличность? Прежде чем эта неудавшаяся транзакция завершится, следует отменить изменение остатка на счете клиента. Средство, используемое для этого в AS/400, — управление транзакциями (commitment control).

Так как все изменения невозможно выполнить одновременно, система обязана защитить группу взаимосвязанных записей и не освобождать ее до тех пор, пока все изменения не будут внесены. Команда «Commit» позволяет изменить группу записей так, чтобы она выглядела как одна операция. Если нельзя выполнить какое-либо изменение, то вся группа изменений может быть отменена по команде «Rollback». Для этих операций управление транзакциями использует журналирование.

Триггеры

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

При добавлении к физическому файлу триггера необходимо определить три атрибута. Первый — событие, приводящее к запуску триггера: вставка, обновление или удаление записи из файла. Второй атрибут задает, когда следует запустить триггер — до или после события. Наконец, третий атрибут задает программу запуска триггера. Обычно это пользовательская программа, написанная на любом ЯВУ, поддерживаемом AS/400.

Таким образом, для каждого физического файла можно назначить до шести триггеров: по два триггера для обновления, вставки и удаления записей, так чтобы один триггер запускался до события, второй — после. Триггеры добавляют командой «ADDPFTRG» (Add Physical File Trigger), а удаляют командой «RMVPFTRG» (Remove Physical File Trigger).

Ссылочная целостность

На практике данные одного физического файла часто зависят от данных другого. Если программа обновляет один файл независимо от другого, то целостность данных может быть нарушена. Часто ответственность за поддержку таких зависимостей ложится на прикладную программу. Ссылочная целостность — это средство, встроенное в базу данных AS/400 и позволяющее снять эту ответственность с прикладных программ.

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

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