Проблема несогласованных данных

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

Рисунок 27 Проблема несогласованных данных

Пользователь 1 снова начинает принимать от своего клиента заказ на 100 изделий Samsung C110. Вскоре после этого программа Пользователя 2 выясняет количество этих же изделий на складе. Затем программа Пользователя 2 выполняет запрос о наличии изделий Samsung C100. Тем временем Пользователь 1 принимает заказ на изделия Samsung C110, его программа обновляет соответствующую строку и выполняет инструкцию COMMIT, завершая транзакцию по приему заказа. После некоторых размышлений клиент Пользователя 2 решает заказать изделия Samsung C110, которые ему предлагались вначале. Его программа вновь запрашивает информацию об этих изделиях. Но новый запрос показывает, что в наличии имеется только 39 изделий вместо 139, показанных предыдущим запросом несколько секунд тому назад.

В данном примере, в отличие от двух предыдущих, состояние базы данных правильно отражает реальную ситуацию. В наличии осталось только 39 изделий, поскольку у Пользователя 1 их было заказано 100 штук. Из-за того, что Пользователь 2 увидел данные программы Пользователя 1, ничего особенного не произошло – заказ от Пользователя 1 был успешно принят. Однако с точки зрения Пользователя 2, база данных не была целостной в течение выполняемой им транзакции. В начале транзакции некоторая строка содержала одни данные, а позднее в той же самой транзакции она содержала другие данные, поскольку “внешние события” нарушили целостное восприятие базы данных. Такая несогласованность может привести к различным проблемам даже в том случае, если программа Пользователя 2 не будет обновлять базу данных, опираясь на результаты первого запроса. Например, если его программа накапливает итоговые суммы или собирает статистические данные, то нет гарантии, что она отражает информацию правильно. В стандарте SQL2 эта проблема обозначена как “Р2”, или проблема “нестабильных результатов выборки”.

22.4.4 Проблема строк – призраков

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

Рисунок 28 Проблема строк – призраков

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

Здесь, как и в предыдущем примере, проблема заключается в несогласованности данных. Состояние базы данных соответствует реальной ситуации, и целостность данных не нарушена, но один и тот же запрос, выполненный дважды в течение одной транзакции, возвращает два различных результата. В предыдущем примере запрос извлекал одну строку, и противоречивость данных была вызвана выполнением инструкции UPDATE. Выполнение инструкции DELETE могло бы вызвать ту же проблему. В примере, представленном на нижеследующем рисунке, проблема возникла в результате выполнения инструкции INSERT. В первом запросе дополнительной строки не было, и после выполнения второго запроса сложилось такое впечатление, что она появилась “из ниоткуда”. Проблема строк-призраков, как и проблема несогласованных данных, может привести к противоречивым и неправильным расчетам. В стандарте SQL2 эта проблема обозначена как “РЗ”.