22.4.2 Проблема промежуточных данных
Так же как и проблему пропавшего обновления проиллюстрируем данную проблему на примере. На рисунке 26 изображена схема работы той же программы для обработки заказов, что и на предыдущем рисунке.
Рисунок 26 Проблема промежуточных данных
На этот раз Пользователь 1 снова начинает принимать от клиента заказ на 100 изделий Samsung C110. На этот раз его копия программы запрашивает таблицу PRODUCTS, выясняет, что в наличии имеется 139 изделий, и обновляет ее, показывая, что после принятия заказа в наличии осталось 39 изделий. Тем временем клиент Пользователя 2 пытается заказать 125 вышеупомянутых изделий. Его копия программы запрашивает таблицу PRODUCTS, выясняет, что в наличии имеется только 39 изделий, и отказывается принять заказ. А клиент Пользователя 1 решает отказаться от заказа, и программа выполняет инструкцию ROLLBACK для отмены транзакции, после выполнения, которой СУБД восстанавливает в таблице число 139, хотя 39 изделий из них уже предназначены заказчика Пользователя 2. Такое противоречие в базе данных возникло из–за того, что информацию, которую извлекла программа Пользователя 2, являлись промежуточными, так как еще не были подтверждены программой Пользователя 1.
22.4.3 Проблема несогласованных данных
На нижеследующем рисунке изображена еще одна схема работы программы для обработки заказов.
Рисунок 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”, или проблема “нестабильных результатов выборки”.