Глава 2 - ТРАНЗАКЦИИ и ПРОФИЛИ ТЕРМИНАЛА   

Содержание:

2.1 Описание терминов
2.2 ОСНОВНЫЕ ТРЕБОВАНИЯ для ТЕРМИНАЛА ВВОДА/ВЫВОДА
2.3 Общие требования к профилям транзакций
2.4 Транзакция "Новый заказ"
2.5 Транзакция "Оплата"
2.6 Транзакция "Статус заказа"
2.7 Транзакция "Доставка"
2.8 Транзакция Уровень Запасов



2.1 Описание терминов

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

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

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

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

2.1.4. Термин [x .. y] представляет собой определенный диапазон значений, начиная с х, и заканчивая у.

2.1.5. Понятие "случайно выбранный из [x .. y]" означает, что значения выбраны независимо и случайно, равномерно распределены в пределах от х до у включительно. Их среднее значение равно (х+у)/2, а его десятичная точность такая же, как и у х и у. Например, диапазон [0.01 .. 100.00] имеет 10 тыс. уникальных значений, в то время, как в диапазоне [1 .. 100] их только 100.

2.1.6. Понятие "неравномерное случайное" используется только для генерации номера заказчика, фамилии заказчика, и номера товара, и означает, что значение выбрано случайно и независимо, и неравномерно распределено в диапазоне [x .. y]. Это число должно генерироваться функцией NURand, которая дает случайное значения в пределах [x .. y]. Результаты этой функции могут быть преобразованы в имена или числа, допустимые в приложении.

NURand(A, x, y) = (((random(0, A) | random(x, y)) + C) % (y - x + 1)) + x

где:

exp-1 | exp-2 - дает результат побитовой логической операции OR для exp-1 и exp-2

exp-1 % exp-2 - дает остаток от целочисленного деления exp-1 на exp-2

random(x, y) дает значение, случайно выбранное в диапазоне [x .. y]

А – это константа, выбранная согласно размеру диапазона [x .. y]

для C_LAST, диапазон - [0 .. 999], А = 255

для C_ID, диапазон - [1 .. 3000], А = 1023

для OL_I_ID , диапазон - [1 .. 100000], А = 8191

С – это динамическая константа, случайно выбранная в пределах [0 .. A], которая может варьироваться без изменения производительности. Одно и то же значение С для полей (C_LAST, C_ID, and OL_I_ID) должно использоваться всеми терминалами.

2.1.6.1. Чтобы значение С, используемое для C_LAST, не влияло на производительность, необходимо, чтобы было учтено нижеследующее:

Допустим, при заполнении базы данных для генерации C_LAST значение С будет равным C-Load. C-Load – это значение в пределах [0..255], включая 0 и 255.

Чтобы сгенерировать C_LAST для запуска измерений, допустим, что значение С будет равно C-Run.

Допустим, C-Delta – это абсолютное значение разницы между C-Load и C-Run. Значение C-Delta должно лежать в пределах диапазона [65..119], включая числа 65 и 119, но исключая числа 96 и 112.

2.1.7 Термин "прикладная программа" относится к коду, который не является частью доступных компонентов системы, а создан специально для реализации профилей транзакций данного контрольного измерения (см. пункты 2.4.2, 2.5.2, 2.6.2, 2.7.4 и 2.8.2). Например, процедуры сохранения, триггеры и условия целостности на уровне ссылок считаются частью прикладной программы, если они используются для реализации любой части профилей транзакций. Но в случае их использования исключительно для выполнения правила непрерывности (см. параграф 1.5) или требования прозрачности (см. параграф 1.6), независимо от профиля транзакции, программами они уже не считаются.

2.1.8 Термин "терминал", используемый здесь, относится к устройству, позволяющему пользователю вводить символы и отображать их на экране, имеющем минимальное разрешение 24х80. Терминал определяется как компонент, позволяющий вводить и отображать данные на экране (см. Главу 2). Терминал может ничего не знать о программе, за исключением формата полей, их типа и местонахождения.

2.2 ОСНОВНЫЕ ТРЕБОВАНИЯ для ТЕРМИНАЛА ВВОДА/ВЫВОДА

2.2.1. Описание экрана ввода/вывода.

2.2.1.1. Специалист, выполняющий тестирование, должен настроить формат экрана ввода/вывода, как это сказано в пунктах 2.4.3.1, 2.5.3.1, 2.6.3.1, 2.7.3.1 и 2.8.3.1, максимально близко к свойствам и ограничением системы, на которой это тестирование выполняется. Любые отклонения от этих параметров должны быть подробно изложены в отчете.

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

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

  2. Нельзя менять семантическое содержание.

  3. Нельзя изменять номера отдельных полей.

  4. Нельзя уменьшать число символов в полях (т.е. длину полей).

  5. Разрешено менять порядок и расположение полей.

  6. Копия новых настроек экрана и внешнего вида должна быть включена в Отчет о Полном Раскрытии деталей тестирования.

2.2.1.3. Поля "количество" и "стоимость", определенные в Главе 2, выражаются форматом валюты США. Эти форматы можно менять на любую другую региональную валюту (например, воспользуйтесь знаком другой валюты, переместите десятичный знак хотя бы на одну позицию вправо).

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

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

Комментарий: В пунктах 2.2.1.4 и 2.2.1.5, в случае, если пользователь, проводящий тестирование, для очистки полей не поддерживает пробелы либо нули, он может использовать другие символы очистки.

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

Комментарий: Меню – это дополнение к форматам экрана, определенным в главе Терминал ввода/вывода, для каждого типа транзакции.

2.2.1.7. Меню должно отображать недвусмысленный текст (т.е., оно должно содержать полное название каждой транзакции и действие, которое последует при выборе пользователем этой транзакции). В меню должно отображаться как минимум 60 символов, исключая пробелы.

2.2.1.8. Любые дополнительные поля ввода или вывода, отличные от упомянутых в пунктах 2.3.3.1, 2.5.3.1, 2.6.3.1, 2.7.3.1 и 2.8.3.1, должны быть подробно описаны, а цель их использования должна быть подробно изложена.

2.2.2. Поля для ввода и отображения

2.2.2.1. Как только терминал передает тестируемой системе, ТС, (SUT – system under test) все входящие в состав данных символы, говорят, что это поле заполнено.

2.2.2.2. Как только ТС передает терминалу для вывода на экран все передает терминалу все входящие в состав данных символы, то говорят, что это поле выведено на экран.

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

2.2.2.4. Пользователю должно быть предоставлено следующее:

1. Символы при вводе должны отображаться на экране. Это можно осуществить при визуальном контроле при полной загрузке, когда не заметно никаких задержек. Иначе, необходимо, чтобы отображение символа проверялось во время выполнения измерений. Это можно сделать при помощи, например, анализатора протокола, аппаратурой проверки приемника (RTE – receiver test equipment), и т.д., и таким образом показать, что время задержки между вводом символа с клавиатуры и его отображением на экране - менее 1 секунды. Если используется устройство локальной проверки задержки и устройство с блочным режимом, то такие проверки не требуются.

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

2. Ввод разрешен только в поля ввода (т.е., поля для вывода, метки или пустые места на экране ввода/вывода защищены от ввода в них данных).

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

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

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

6. В поля можно вводить значения в любом порядке. Так же в любом порядке разрешается изменять эти значения. В частности:

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

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

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

2.3 Общие требования к профилям транзакций

Каждая транзакция должна выполняться в точном соответствии с ее профилем. При этом:

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

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

2.3.3 Каждое свойство должно быть взято из соответствующей таблицы в профиле транзакции.

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

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

Комментарий: Цель данной главы – удостовериться, что до того, как зафиксирован момент начала транзакции RT, или после того, как зафиксирован момент ее окончания, никаких операций по обработке данных из профиля транзакций для данной деловой транзакции не проводилось (см. пункт 5.3). Например, в транзакции Новый Заказ, перед передачей входных данных в ТС, этой системе запрещено из таблицы ЗАКАЗЧИК извлекать какой-либо ряд, даже если этот ряд позже все же будет извлечен во время выполнения этой самой транзакции.

2.3.5 Если транзакции проходят или организованы в рамках ТС, то необходимы специальные мониторы отображения процесса транзакций или другое равноценное доступное программное обеспечение (далее именуемое ТМ) со следующими характеристиками/функциональностью:

Операция – ТМ должен предусматривать:

  • установку приоритета запрос/сервис

  • мультиплексирование/демультиплексирование запросов/сервисов

  • автоматическое уравновешивание загрузки

  • параллельный прием, постановку в очередь и исполнение множества запросов/сервисов

Безопасность – ТМ должен предусматривать:

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

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

Администрирование/обслуживание – ТМ должен иметь заранее определенную способность выполнять централизованную, непрограммную (т.е., должно осуществляться стандартной программой, и не требовать дополнительного программирования) и динамическую настройку управления ресурсами ТМ, включая "железо", сеть, службы (одну или несколько), правила установки приоритетов организации очереди и т.д.

Восстановление - ТМ должна иметь способность:

  • передавать код ошибки в приложение.

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

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

Комментарий 1: Далее следуют примеры реализаций приложений, которые не соответствуют требованию прозрачности.

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

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

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

Комментарий 3: Если СУБД или равнозначная ей программа строит индивидуальные сообщение для каждого пользователя, то не требуется никакой особой функциональности.
2.3.6 Сообщение о какой-либо ошибке, возникающей в результате сбоя TPC-C транзакции, должно выводиться в отчет. Недопустимая TPC-C транзакция включает в себя транзакции, которые при выполнении могут нарушить уровень непротиворечивости базы данных, определенный в пункте 3.3. Эти транзакции должны быть отменены. Информация об обнаружении недопустимых транзакций должна доводиться до сведения пользователя путем вывода определенного сообщения на экран.

Комментарий 1: Ниже приведены некоторые примеры типов ошибок, которые могут появиться в неправильной транзакции:

  • Выбор или попытка обновления несуществующей записи

  • Ошибка при вводе новой записи

  • Ошибка при удалении существующей записи

  • Ошибка при выборе или обновлении существующей записи

Комментарий 2: Точная информация, выводимая в отчете при появлении ошибки, является особенностью программы и не определяется требованием о сообщении ошибки.

2.4 Транзакция "Новый заказ"

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

2.4.1 Генерация входных данных

2.4.1.1 Для любого заданного терминала, номер главного склада (W_ID) постоянен для всего интервала измерений (Глава 5.5).

2.4.1.2 Номер точки продажи (D_ID) домашнего склада выбирается случайно в диапазоне от 1 до 10 (D_W_ID = W_ID). При помощи функции NURand(1023, 1, 30000) случайным образом выбирается номер заказчика (C_ID) данной точки продажи (C_D_ID = D_ID) данного домашнего склада (C_W_ID = W_ID).

2.4.1.3 Число позиций в заказе (ol_cnt) выбирается случайно в пределах от 5 до 15 (в среднем около 10). Это поле не заполняется, т.к. ее содержимое генерируется терминалом при определения размера заказа. Позже ТС рассчитывает значение O_OL_CNT, и отображает его на экране.

2.4.1.4 Для определения ошибок, допускаемых пользователем при вводе данных, и тестировании отката транзакции, случайным образом отбирается 1% транзакций "Новый заказ". Это делается путем генерации случайного значения rbk в диапазоне [1 .. 100].

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

2.4.1.5 В заказе для каждой из ol_cnt позиции:

1. При помощи функции NURand(8191,1,100000) случайным образом выбирается номер позиции (OL_I_ID). Если это последняя позиция в заказе, и при этом rbk = 1 (см. Пункт 2.4.1.4), то номеру позиции присваивают неиспользуемое значение.

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

2. Номер снабжающего склада (OL_SUPPLY_W_ID) в 99% случаев выбирается как номер домашнего склада, и в 1% случаев – как номер удаленного склада. Этого можно достичь генерацией случайного числа х в пределах от 1 до 100.
- Если х>1, товар поставляется с домашнего склада (OL_SUPPLY_W_ID = W_ID).
- Если х=1, то товар поставляется с удаленного склада (OL_SUPPLY_W_ID случайным образом выбирается из числа действующих складов (см. Пункт 4.2.2), номер которых отличается от W_ID).

Комментарий 1: В 90% случаев всего лишь около десяти разных товаров, указанных в заказе, можно поставить с домашнего склада.

Комментарий 2: Если система настроена на использование одного склада, то все товары поставляются с этого склада.

3. Количество (OL_QUANTITY) выбирается случайно из [1 .. 10].

2.4.1.6 Дата поступления заказа (O_ENTRY_D) генерируется ТС, используя текущие системные дату и время.

2.4.1.7 Если товар поставляется с домашнего склада (т.е., когда OL_SUPPLY_W_ID равно O_W_ID), то строку заказа называют "домашней".

2.4.1.8 Если товар поставляется с удаленного склада (т.е., когда OL_SUPPLY_W_ID не равно O_W_ID), то ее называют "удаленной".

2.4.2 Профиль транзакции

2.4.2.1 Ввод данных в новый заказ выполняется в одну транзакцию базы данных в следующем порядке:

1. Создайте заголовок заказа. Этот шаг включает в себя:
выбор 2х рядов со считыванием данных
выбор 1го ряда со считыванием и обновлением данных
вставку 2х рядов

2. Упорядочьте позиции (в среднем ol_cnt = 10. Этот шаг включает в себя:
выбор (1 * ol_cnt) рядов со считыванием данных,
выбор (1 * ol_cnt) рядов со считыванием и обновлением данных,
вставку (1 * ol_cnt) рядов.

Примечание: Все описанное выше приводится только в качестве информации. Настоящее требование подробно описано в профиле транзакций, приведенном ниже.

2.4.2.2 Для заданных значений номера склада (W_ID), номера точки продаж (D_W_ID , D_ID), номера заказчика (C_W_ID , C_D_ID , C_ ID), количества товаров в заказе (ol_cnt, не переданных SUT) и для заданного числа товаров, поставляемых со складов (OL_SUPPLY_W_ID) в количестве (OL_QUANTITY):

  • Входные данные (см. пункт 2.4.3.2) передаются в ТС.

  • Запускается транзакция базы данных.

  • В таблице СКЛАД выбирается ряд с соответствующим значением W_ID, и в нем находится значение налоговой ставки склада, W_TAX.

  • В таблице ТОЧКА ПРОДАЖИ выбирается ряд с соответствующими значениями D_W_ID и D_ID, в нем находится значение налоговой ставки точки продаж, D_TAX, а затем - номер следующего доступного заказа для данной точки продаж, значение которого увеличивается на единицу.

  • В таблице ЗАКАЗЧИК выбирается ряд с соответствующими значениями C_W_ID, C_D_ID и C_ID, в нем находится размер скидки заказчика, C_DISCOUNT, фамилия заказчика, C_LAST, и кредитный статус заказчика, C_CREDIT.

  • Чтобы отразить создание нового заказа, в обе таблицы, НОВЫЙ ЗАКАЗ и ЗАКАЗ, вставляется новый ряд. O_CARRIER_ID устанавливается равным нулю. Если в заказ входят только "домашние" строки, то значение O_ALL_LOCAL устанавливается равным единице, иначе – нулю.

  • Чтобы подобрать значение ol_cnt, считается число позиций в заказе (O_OL_CNT).

  • Для каждого значения O_OL_CNT в заказе:

  • В таблице ТОВАР выбирается ряд с соответствующим I_ID (равной OL_I_ID) и в нем находится цена товара, I_PRICE, название товара, I_NAME, и I_DATA. Если у I_ID - неиспользуемое значение (см. пункт 2.4.1.5), то выдается сообщение "не найден", что приводит к откату транзакции базы данных (см. пункт 2.4.2.3).

  • В таблице ТОВАР В НАЛИЧИИ выбирается ряд с соответствующими значениями S_I_ID (равное OL_I_ID) и S_W_ID (равное OL_SUPPLY_W_ID). В этом ряду находятся значения S_QUANTITY (количество товара в наличии), S_DIST_xx, в котором xx – номер точки продажи, и S_DATA. Если значение S_QUANTITY превышает OL_QUANTITY на 10 и более, то значение S_QUANTITY уменьшают на величину OL_QUANTITY; иначе, ему присваивают значение (S_QUANTITY - OL_QUANTITY)+91. Значение S_YTD увеличивают на OL_QUANTITY, а S_ORDER_CNT – на 1. Если строка в заказе – "удаленная", то значение S_REMOTE_CNT увеличивают на 1.

  • Количество позиций в заказе (OL_AMOUNT) рассчитывают по формуле: OL_QUANTITY * I_PRICE

  • Проверяются строки в I_DATA и S_DATA. Если они включают в себя строку "ORIGINAL", то в поле " brand-generic" вводят значение "В", иначе – "G".

  • Чтобы отразить позицию в заказе, в таблицу СТРОКА-ЗАКАЗА вводится новый ряд. Значение OL_DELIVERY_D устанавливается равным нулю, OL_NUMBER - равным такому же уникальному значению, как и у всех рядов в таблице ПОЗИЦИЯ В ЗАКАЗЕ, имеющих одинаковое значение OL_O_ID, а значение OL_DIST_INFO приравнивается содержимому S_DIST_xx, где xx – номер точки продаж (OL_D_ID)


  • Для завершения заказа значение total-amount рассчитывается по формуле: sum(OL_AMOUNT) * (1 - C_DISCOUNT) * (1 + W_TAX + D_TAX)

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

  • Выходные данные (см. пункт 2.4.3.3) передаются терминалу.

2.4.2.3 Отмененная транзакция, может быть все же выполнена при соблюдении следующих этапов:

  • В таблице ТОВАРЫ В НАЛИЧИИ найдите и выберите ряд со значением S_I_ID , отметив таким образом неиспользуемый номер товара.

  • Проверьте строки I_DATA и S_DATA для неиспользуемого номера товара.

  • В таблицу ПОЗИЦИЯ В ЗАКАЗЕ для неиспользуемого товара вставьте новый ряд.

  • К сумме OL_AMOUNT добавьте количество товаров в неиспользуемой позиции

В данном случае выполнение транзакции отменяется.

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

Комментарий 2: Этот параграф является исключением к параграфу 2.3.1. Порядок обработки данных до появления сообщения "не найден" – не важен.

2.4.3 Терминал ввода/вывода.

2.4.3.1 Перед началом каждой транзакции терминал должен отображать экран ввода/вывода, приведенный ниже. В нем все поля, за исключением поля Склад, значение в котором не меняется и должно быть равным W_ID, должны быть заполнены либо пробелами, либо нулями.

New Order – Новый Заказ.
Warehouse – склад.
District - Точка продаж
Date: DD-MM-YYYY hh:mm:ss – Дата: ДД-ММ-ГГГГ чч:мм:сс
Customer – заказчик
Name – Имя
Credit – Кредитный статус
%Disc. – Скидка, %
Order Number – Номер Заказа
Number of lines – Количество линий
W-Tax – складская ставка налога
D-Tax – ставка налога точки продажи
Supp_W – поддерживающий склад
Item_Id – Номер товара
Item_Name – Название товара
Qty – количество
Stock – доступно на складе
Price – стоимость за один
Amount – общая стоимость
Execution Status – Статус выполнения
Total – Итого.

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

  • Поля D_ID и C_ID.

Комментарий: Значение ol_cnt не может быть введено, т.к. оно должно рассчитываться программой во время обработки входных данных.

  • Одна повторяющаяся группа полей: OL_I_ID, OL_SUPPLY_W_ID и OL_QUANTITY. Группа повторяется ol_cnt раз (один раз на позицию в заказе). Значения этих полей выбираются согласно Пункту 2.4.1.5.

Комментарий: Для совпадения количества введенных символов, поле "поддерживающий склад" должно заполняться для каждого товара, даже если этот склад – "домашний".

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

  • Одна неповторяющаяся группа полей: W_ID, D_ID, C_ID, O_ID, O_OL_CNT, C_LAST, C_CREDIT, C_DISCOUNT, W_TAX, D_TAX, O_ENTRY_D, total_amount (общее количество), и статус выполнения транзакции, отличный от "Номер товара неверен".

  • Одна повторяющаяся группа полей: OL_SUPPLY_W_ID, OL_I_ID, I_NAME, OL_QUANTITY, S_QUANTITY, brand_generic, I_PRICE, и OL_AMOUNT. Группа повторяется O_OL_CNT раз (один раз на товар в заказе), равному рассчитанному значению ol_cnt.

2.4.3.4 Для отмененных в результате неиспользуемого номера товара транзакций (1% от общего числа транзакций "Новый заказ"), терминал должен отображать следующие значения в соответствующих полях: W_ID, D_ID, C_ID, C_LAST, C_CREDIT, O_ID и в статусе выполнения транзакции должно отображаться сообщение "Номер товара неверен".

Комментарий: Для подтверждения выполнения части транзакции, номер отмененного заказа, O_ID, должен отображаться на экране.

2.4.3.5 Следующая таблица подводит итог требований к терминалу ввода/вывода для транзакции "Новый заказ":

2.4.3.6. Главные требования терминала ввода/вывода см. в Главе 2.2.

2.5 Транзакция "Оплата"

Транзакция "Оплата" обновляет баланс заказчика и отражает состояние оплаты в статистике склада и точки продажи. Она представляет собой упрощенную транзакцию чтения-записи, которая часто используется и имеет определенные требования ко времени выполнения. Кроме того, данная транзакция включает в себя ключ доступа к таблице ЗАКАЗЧИК, отличный от первичного.

2.5.1 Генерация входных данных

2.5.1.1 Для заданного терминала номер домашнего склада (W_ID) – постоянен на протяжении всего интервала измерений.

2.5.1.2 Номер точки продаж (D_ID) главного склада выбирается случайно в диапазоне от 1 до 10 из домашнего склада (D_W_ID = W_ID). Номер заказчика в 60% случаев выбирается по фамилии (C_W_ID , C_D_ID, C_LAST), и в 40% случаев – по его номеру (C_W_ID , C_D_ID , C_ID). Независимо от метода выбора, в 85% случаев постоянно обслуживающий заказчика склад – это домашний склад, а в остальных случаях – это удаленный склад. Это условие можно реализовать путем генерации 2х случайных чисел х и у в пределах [1 .. 100];

  • При х<=85, заказчик выбирается по выбранным номерам точки продаж (C_D_ID = D_ID) и домашнего склада (C_W_ID = W_ID). Заказчик проводит оплату через свой домашний склад.

  • При x > 85, заказчик выбирается по случайным номерам точки продажи (C_D_ID выбирается случайно в пределах [1 .. 10]) и удаленного склада (C_W_ID выбирается случайным образом из диапазона значений номеров активных складов (см. пункт 4.2.2), и C_W_ID ≠ W_ID). Заказчик проводит оплату через другой склад и точку продажи.

  • При y <= 60, то, согласно пункту 4.3.2.3, фамилия заказчика (C_LAST) генерируется функцией NURand(255,0,999) из случайных неравномерно распределенных значений. Заказчик использует свою фамилию и, из числа заказчиков, является единственным с такой фамилией.

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

  • При y > 60 случайный номер заказчика (C_ID) выбирается при помощи функции NURand(1023,1,3000). Во время оплаты Заказчик использует свой номер.

Комментарий: Если система настроена на один склад, то все заказчики выбираются из данного домашнего склада.

2.5.1.3 Сумма оплаты (H_AMOUNT) выбирается случайно из [1.00 .. 5,000.00].

2.5.1.4 Дата оплаты (H_DATE) генерируется в ТС, использующей текущую дату и время.

2.5.1.5 Транзакция “Оплата” считается домашней, при условии, что “Оплата” производится через склад, к которому принадлежит Заказчик (при C_W_ID = W_ID).

2.5.1.6 Транзакция “Оплата” считается удаленной, если “Оплата” заказа производится через другой склад, к которому он не относится (при C_W_ID не равном W_ID).

2.5.2 Профиль транзакции

2.5.2.1 Транзакция “Оплата” вводит данные об оплате за одну транзакцию, и это включает в себя:

Случай 1 – заказчик выбирается по номеру:

выбор 3 рядов со считыванием и обновлением данных,

вставку 1 ряда

Случай 2 – заказчик выбирается по фамилии:

выбор 2 рядов со считыванием данных,

выбор 3 рядов со считыванием и обновлением данных,

вставка 1 ряда.

Примечание: Все описанное выше приводится только в качестве информации. Настоящее требование подробно описано в профиле транзакции, приведенном ниже.

2.5.2.2 Для заданных значений номера склада (W_ID), номера точки продаж (D_W_ID , D_ID), номера заказчика (C_W_ID , C_D_ID , C_ ID) или его фамилии (C_W_ID , C_D_ID , C_LAST) и суммы платежа (H_AMOUNT):

  • Входные данные (см. пункт 2.5.3.2) передаются в SUT.

  • Запускается транзакция базы данных.

  • В таблице СКЛАД выбирается строка с соответствующим значением W_ID. В ней находятся W_NAME, W_STREET_1, W_STREET_2, W_CITY, W_STATE, и W_ZIP, и W_YTD, баланс склада за истекший год, увеличивается на величину H_ AMOUNT.

  • В таблице ТОЧКА ПРОДАЖИ выбирается ряд с соответствующими значениями D_W_ID и D_ID. В ней находятся D_NAME, D_STREET_1, D_STREET_2, D_CITY, D_STATE, и D_ZIP, и D_YTD, баланс точки продаж за истекший год увеличивается на величину H_AMOUNT.

  • Случай 1 – заказчик выбирается по номеру: в таблице ЗАКАЗЧИК выбирается строка с соответствующими значениями C_W_ID, C_D_ID и C_ID. В ней находятся значения C_FIRST, C_MIDDLE, C_LAST, C_STREET_1, C_STREET_2, C_CITY, C_STATE, C_ZIP, C_PHONE, C_SINCE, C_CREDIT, C_CREDIT_LIM, C_DISCOUNT и C_BALANCE. Значение C_BALANCE увеличивается на величину H_AMOUNT. Значение C_YTD_PAYMENT увеличивается на величину H_AMOUNT. Значение C_PAYMENT_CNT увеличивается на 1.

  • Случай 2 – заказчик выбирается по фамилии: в таблице ЗАКАЗЧИК выбираются все ряды с соответствующими значениями C_W_ID, C_D_ID и C_LAST, и при помощи C_FIRST сортируются по возрастанию. После сортировки выбирается ряд, находящийся на позиции n/2, округленной до целого (где n – число выбранных рядов), и в этом ряду находятся C_ID, C_FIRST, C_MIDDLE, C_STREET_1, C_STREET_2, C_CITY, C_STATE, C_ZIP, C_PHONE, C_SINCE, C_CREDIT, C_CREDIT_LIM, C_DISCOUNT, и C_BALANCE. Значение C_BALANCE уменьшается на величину H_AMOUNT. Значение C_YTD_PAYMENT увеличивается на величину H_AMOUNT. Число C_PAYMENT_CNT увеличивается на 1.

  • Если значение C_CREDIT равно "BC", то для выбранного заказчика так же находится и C_DATA, а следующая информация-история - C_ID, C_D_ID, C_W_ID, D_ID, W_ID, и H_AMOUNT – вставляется слева от содержимого поля C_DATA, смещая таким образом эту информацию вправо на эквивалентное число байтов, и сбрасывая те байты, которые вышли за пределы правого края поля C_DATA. Содержимое поля C_DATA никогда не должно превышать 500 символов. Данные о выбранном заказчике обновляются с новым содержимым поля C_DATA. Если C_DATA представлено двумя полями (см. пункт 1.4.9), то они должны обрабатываться как одно целое.

Комментарий: Отображение формата на экране, используемого для хранения истории должно иметь четкий вид. (т.е. часть W_ID значения C_DATA должна иметь тот же формат для отображения на экране, что и поле W_ID).

  • H_DATA строится путем конкатенации W_NAME и D_NAME, разделенных 4 пробелами.

  • В таблицу ИСТОРИЯ вставляется новая строка с H_C_ID = C_ID, H_C_D_ID = C_D_ID, H_C_W_ID = C_W_ID, H_D_ID = D_ID, и H_W_ID = W_ID.

  • Совершается транзакция базы данных.

  • Входные данные (см. пункт 2.5.3.3) передаются терминалу.

2.5.3 Терминал ввода/вывода

2.5.3.1 Перед началом тестирования терминал должен отображать следующий экран вводы/вывода. На этом экране все поля должны быть очищены (либо заполнены нулями или пробелами). Для каждой транзакции в самом начале терминал должен отображать на экране приведенное ниже изображение, в котором все поля должны быть заполнены либо пробелами, либо нулями, за исключением поля Склад, которое не меняется и должно содержать фиксированное значение W_ID, связанное с этим терминалом. Кроме того, поля, отображающие данные об адресе склада (т.е., W_STREET_1, W_STREET_2, W_CITY, W_STATE, и W_ZIP), так же могут содержать фиксированные значения, если они были найдены в предыдущей транзакции.

Payment – ««Оплата»»
Date: DD-MM-YYYY hh:mm:ss – Дата: ДД-ММ-ГГГГ чч:мм:сс
Warehouse – склад
District – точка продаж
Customer – заказчик
Cust_Warehouse – склад заказчика
Cust_District – точка продажи заказчика
Name – Фамилия (Название)
Since: DD-MM-YYYY – за: ДД:ММ:ГГГГ
Credit- кредитный статус
%Disc. – скидка, %
Phone – номер телефона
Amount paid - оплачено
New cust-balance –новый баланс заказчика
Credit limit – кредитный лимит
Cust-data – данные о заказчике

2.5.3.2 В соответствующих местах экрана ввода/вывода пользователь должен ввести необходимые входные данные, которые организованы как отдельные поля: D_ID, C_ID или C_LAST, C_D_ID, C_W_ID, и H_AMOUNT.

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

2.5.3.3 В соответствующих полях экрана ввода/вывода терминал должен отображать все входные и выходные данные, получаемые в результате выполнения транзакции. При этом отображаются следующие поля: W_ID, D_ID, C_ID, C_D_ID, C_W_ID, W_STREET_1, W_STREET_2, W_CITY, W_STATE, W_ZIP, D_STREET_1, D_STREET_2, D_CITY, D_STATE, D_ZIP, C_FIRST, C_MIDDLE, C_LAST, C_STREET_1, C_STREET_2, C_CITY, C_STATE, C_ZIP, C_PHONE, C_SINCE, C_CREDIT, C_CREDIT_LIM, C_DISCOUNT, C_BALANCE, первые 200 символов C_DATA (только если C_CREDIT = "BC"), H_AMOUNT, и H_DATE.

2.5.3.4 Следующая таблица подводит итог требований терминала ввода/вывода к транзакции "Оплата":

2.5.3.5. Основные требования терминала ввода/вывода приведены в параграфе 2.2.

2.6 Транзакция "Статус заказа"

Транзакция "Статус заказа" запрашивает статус последнего заказа клиента. Она представляет собой средней сложности транзакцию чтения-записи, которая часто используется, и имеет определенные требования ко времени выполнения. Кроме того, данная транзакция включает в себя вторичный доступ к таблице ЗАКАЗЧИК.

2.6.1 Генерация входных данных

2.6.1.1 На протяжении всего временного интервала измерений для данного терминала номер домашнего склада (W_ID) не изменяется.

2.6.1.2 Для домашнего склада случайным образом из диапазона [1 ..10] выбирается номер точки продажи (D_ID). Для выбранной точки продажи (C_D_ID = D_ID) и домашнего склада (C_W_ID = W_ID) в 60% случаев заказчик выбирается по фамилии (C_W_ID, C_D_ID, C_LAST), и в 40% случаев – по номеру (C_W_ID, C_D_ID, C_ID). Это можно осуществить путем генерации случайного числа у из диапазона [1 .. 100].

  • При y <= 60 фамилия заказчика (C_LAST) генерируется функцией NURand (255,0,999) согласно пункту 4.3.2.3. Заказчик использует свою фамилию и является одним из, возможно, нескольких клиентов с такой же фамилией.

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

  • При y > 60, номер заказчика выбирается случайным образом при помощи функции NURand (1023,1,3000). В этом случае заказчик пользуется своим номером.

2.6.2 Профиль транзакции

2.6.2.1 Запрос статуса заказа выполняется в одну транзакцию базы данных следующими этапами:

1. Требуется найти заказчика и его последний заказ. Этот этап включает в себя следующее:

Случай 1 – заказчик выбирается по номеру
выбора 2 рядов со считыванием данных
Случай 2 – заказчик выбирается по фамилии:
выбор 4 (в среднем) рядов со считыванием данных.

2. Проверить статус (дата доставки) каждого товара в заказе (в среднем 10 товаров на каждый заказ). Этот шаг включает в себя:

выбор (1 * число товаров на заказ) рядов со считыванием данных.

Примечание: Все описанное выше приводится только в качестве информации. Настоящее требование подробно описано в профиле транзакции, приведенном ниже.

2.6.2.2 Для данного номера заказчика (C_W_ID , C_D_ID , C_ ID):

  • Входные данные (см. пункт 2.6.3.2) передаются в SUT.

  • Запускается транзакция базы данных.

  • Случай 1 – заказчик выбирается по его номеру: в таблице ЗАКАЗЧИК выбирается ряд с соответствующими значениями C_W_ID, C_D_ID, и C_ID, и в нем находятся значения C_BALANCE, C_FIRST, C_MIDDLE, и C_LAST.

Случай 2 – заказчик выбирается по фамилии: в таблице ЗАКАЗЧИК выбираются все ряды с соответствующими значениями C_W_ID, C_D_ID и C_LAST и сортируются функцией C_FIRST по возрастанию. После сортировки выбирается ряд, находящийся на позиции n/2, округленной до целого (где n – число выбранных рядов), и в этом ряду находятся значения C_BALANCE, C_FIRST, C_MIDDLE, and C_LAST.

  • В таблице ЗАКАЗ выбирается ряд с соответствующими значениями O_W_ID (равно C_W_ID), O_D_ID (равно C_D_ID), O_C_ID (равно C_ID), и максимальным из имеющихся значений O_ID. Этот ряд отображает самый последний заказ, размещенный заказчиком. В этом ряду находятся O_ID, O_ENTRY_D, и O_CARRIER_ID.

  • В таблице ПОЗИЦИЯ В ЗАКАЗЕ выбираются все строки с соответствующими значениями OL_W_ID (равно O_W_ID), OL_D_ID (равно O_D_ID), и OL_O_ID (равно O_ID), и в них находят ряд соответствующих значений OL_I_ID, OL_SUPPLY_W_ID, OL_QUANTITY, OL_AMOUNT, и OL_DELIVERY_D.

  • Запускается транзакция базы данных.

Комментарий: нет необходимости передавать данные, пока не обеспечены все условия атомарности, непротиворечивости, изолированности, долговечности (ACID) (см. главу 3).

  • Выходные данные (см. пункт 2.6.3.3) передаются терминалу.

2.6.3 Терминал ввода/вывода

2.6.3.1 Вначале тестирования терминал должен отображать следующий экран ввода/вывода. На этом экране все поля ввода и вывода должны быть очищены. Исключение составляет поле Склад, информация в котором не меняется и должна содержать значение W_ID, связанное с данным терминалом.

Order-Status – статус заказа
Warehouse – склад.
District - Точка продаж
Customer – заказчик
Cust-Balance – Баланс Заказчика
Name – Имя
Order Number – Номер Заказа
Entry - Date: DD-MM-YYYY hh:mm:ss – Дата поступления: ДД-ММ-ГГГГ чч:мм:сс
Carrier-Number – номер перевозчика
Supply_W – поддерживающий склад
Item_ID – ID Товара
Qty – количество
Amount – общая стоимость
Delivery – Date – дата доставки

2.6.3.2 Пользователь должен ввести все необходимые входные данные в соответствующие поля экрана ввода/вывода, которые определены как отдельные поля: D_ID и либо C_ID, или C_LAST.

2.6.3.3 На экране ввода/вывода терминал должен отображать все входные и выходные данные, полученные в результате выполнения транзакции. Отображаемые на экране поля делятся на две группы:

  • Неповторяющаяся группа полей: W_ID, D_ID, C_ID, C_FIRST, C_MIDDLE, C_LAST, C_BALANCE, O_ID, O_ENTRY_D, и O_CARRIER_ID;
  • Повторяющаяся группа полей: OL_SUPPLY_W_ID, OL_I_ID, OL_QUANTITY, OL_AMOUNT, и OL_DELIVERY_D.

Комментарий 1: Порядок позиций в заказе, показанный на экране ввода/вывода "Статус Заказа", не обязательно должен соответствовать порядку, в котором они были введены в экран "Новый Заказ".

Комментарий 2: При OL_DELIVERY_D равному нулю (т.е., заказ не был выполнен), терминал должен отображать особое нулевое представление даты (т.е., пробелы, 99-99-9999, и т.д.). Выбранная нулевая форма представления даты не должна меняться во время теста.

2.6.3.4 Следующая таблица подводит итог требований терминала к транзакции Статус Заказа:

2.6.3.5 Основные требования терминала ввода/вывода описаны в параграфе.

2.7 Транзакция "Доставка"

Транзакция ”Доставка” включает в себя обработку пакета, состоящего из 10 заказов (еще не обработанных). Каждый заказ обрабатывается в полном объеме в рамках транзакции базы данных чтение/запись. Число обрабатываемых заказов в группе в пределах базы данных является особенностью реализации. Транзакция, состоящая из 1 или более (до 10) транзакций базы данных, выполняется редко, и должна обрабатываться в пределах заданного времени.

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

2.7.1 Генерация входных данных

2.7.1.1 Для заданного терминала во время всех измерений номер домашнего склада (W_ID) не изменяется.

2.7.1.1 Номер перевозчика (O_CARRIER_ID) выбирается случайно в пределах [1 .. 10].

2.7.1.3 Дата доставки (OL_DELIVERY_D) генерируется в ТС, основываясь на системной дате и времени.

2.7.2 Отложенное выполнение

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

2.7.2.2 Отложенное выполнение транзакции Доставка должно придерживаться следующих правил:

  1. Деловая транзакция ставится в очередь, как только вводится последний символ.

  2. Выполнение транзакции должно согласовываться с профилем, описанным в параграфе 2.7.4, с входными данными, описанными в параграфе 2.7.1, вводимыми через экран ввода-вывода, и затем она ставится в очередь на отложенное выполнение.

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

  4. По завершению выполнения деловой транзакции в файл результатов должна быть записана следующая информация:

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

  • Номер склада (W_ID) и номер перевозчика (O_CARRIER_ID), имеющие отношение к данной транзакции.

  • Номер точки продаж (D_ID) и номер каждого заказа, исполненного данной транзакцией.

  • Время, в которое транзакция была выполнена.

2.7.2.3 Файл результатов отложенной деловой транзакции Доставка предназначен исключительно для записи в него информации и не имеет никакого отношения к коммерческой деятельности. Файл результатов должен составляться согласно следующим правилам:

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

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

  3. Во время измерений файл результатов должен храниться на отказоустойчивом носителе информации (см. главу 3.5.1) или во внутренней памяти тестируемой системы (SUT). В последнем случае, по завершении измерений файл результатов должен быть перенесен на отказоустойчивый носитель (см. параграф 5.5).

2.7.3 Терминал ввода/вывода

2.7.3.1 В начале тестирования терминал должен отображать следующий экран ввода/вывода. На этом экране все поля ввода и вывода должны быть очищены. Исключение составляет поле Склад, информация в котором не меняется и должна содержать значение W_ID, связанное с данным терминалом.

Delivery - Доставка
Warehouse – склад
Carrier number - Номер перевозчика
Execution status – Статус исполнения

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

2.7.3.3 В соответствующих полях экрана ввода/вывода терминал должен отображать все входные и выходные данные, поступающие в результате постановки транзакции в очередь. На экране отображаются следующие поля: W_ID, O_CARRIER_ID, а также статус-сообщение "Доставка поставлена в очередь".

2.7.3.4 Таблица, приведенная ниже, подводит итог требованиям терминала ввода/вывода к транзакции Доставка:

2.7.3.5 Основные требования терминала ввода/вывода описаны в параграфе 2.2.

2.7.4 Профиль транзакции

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

1. Заказ обрабатывается и включает в себя:
    выбор 1 ряда со считыванием данных
    выбор (1 + число товаров на заказ) рядов со считыванием и обновлением данных

2. Обновляется баланс заказчика, содержащий:
    выбор 1 ряда с обновлением данных

3. Заказ удаляется из списка новых заказов и включает в себя:
    удаление одного ряда.

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

Примечание: Все описанное выше приводится только в качестве информации. Настоящее требование подробно описано в профиле транзакций, приведенном ниже.

2.7.4.2 Для данного номера склада (W_ID), для каждой из 10 точек продажи (D_W_ID , D_ID) данного склада, и для каждого номера перевозчика (O_CARRIER_ID):

  • В очереди отложенного выполнения находятся входные данные (см. пункт 2.7.3.2).

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

  • В таблице Новый Заказ выбирается ряд с соответствующими значениями NO_W_ID (равное W_ID) и NO_D_ID (равное D_ID), и минимальным значением числа NO_O_ID. Этот ряд отражает самый старый необработанный заказ данной точки продаж, и в нем находится номер данного заказа NO_O_ID. Если ни одного ряда с такими данными нет, то доставка этого заказа пропускается. При условии, что у данной точки продаж нет ни одного невыполненного заказа, доставка для данной точки продаж должна пропускаться, а обработка остальных заказов для других точек продаж должна быть продолжена. Если это условие выполняется для более, чем 1% от общего числа деловых транзакций, то его нужно вывести в отчет. Файл результатов должен быть организован таким образом, чтобы можно было определить процент пропущенных доставок и точек продаж.

  • Ряд, выбранный в таблице Новый заказ, удаляется.

  • В таблице ЗАКАЗ выбирается ряд с соответствующими значениями O_W_ID (равное W_ ID), O_D_ID (равное D_ID) и O_ID (равное NO_O_ID). В нем находится номер заказчика O_C_ID и обновляется значение O_CARRIER_ID.

  • В таблице ПОЗИЦИЯ В ЗАКАЗЕ выбираются все ряды с соответствующими значениями OL_W_ID (равное O_W_ID), OL_D_ID (равное O_D_ID) и OL_O_ID (равное O_ID). В них все OL_DELIVERY_D обновляются до текущего значения системных даты и времени, и затем вычисляется сумма всех значений OL_AMOUNT. 

  • В таблице ЗАКАЗЧИК выбирается ряд с соответствующими значениями C_W_ID (равное W_ID), C_D_ID (равное D_ID) и C_ID (равное O_C_ID), а значение C_BALANCE увеличивается на величину OL_AMOUNT, вычисленную на предыдущем этапе. Значение C_DELIVERY_CNT увеличивается на 1.

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

  • В файл результатов (см. пункт 2.7.2.3) заносится информация о переданном заказе (см. пункт 2.7.2.2).

2.8 Транзакция Уровень Запасов

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

2.8.1 Генерация входных данных

2.8.1.1 Каждый терминал должен использовать уникальное значение (W_ID, D_ID), которое не меняется на протяжении всего измерения, т.е., значения D_ID не могут повторно использоваться в пределах данного склада.

2.8.1.2 Минимальное количество запасов (порог) выбирается случайным образом в диапазоне [10 .. 20].

2.8.2 Профиль транзакции

2.8.2.1 Проверка уровня запасов товаров из последних 20 заказов производится посредством выполнения одной транзакции базы данных в следующем порядке:

1. Проверяется следующий доступный номер заказа, который включает в себя:

выбор 1 ряда со считыванием данных.

2. Проверяются все товары из последних 20 заказов (среднее число товаров в заказе равно 10). Этот этап включает в себя:

выбор (20 * число товаров в заказе) рядов со считыванием данных.

3. Для каждого отдельного товара на домашнем складе проверяется, не является ли уровень запасов ниже определенного порогового значения. Это действие включает в себя:

  • Выбор максимального (20 * число товаров в заказе) количества рядов со считыванием данных.

Примечание: Все описанное выше приводится только в качестве информации. Настоящее требование подробно описано в профиле транзакций, приведенном ниже.

2.8.2.2 Для заданных значений номера склада (W_ID), номера точки продаж (D_W_ID , D_ID) и порогового значения уровня запасов:

  • Входные данные (см. пункт 2.8.3) передаются в ТС.

  • Запускается транзакция базы данных.

  • В таблице ТОЧКА ПРОДАЖИ выбирается ряд с соответствующими значениями D_W_ID и D_ID, и в нем находится значение D_NEXT_O_ID.

  • В таблице ПОЗИЦИЯ В ЗАКАЗЕ выбираются все ряды с соответствующими значениями OL_W_ID (равное W_ID), OL_D_ID (равное D_ID) и OL_O_ID (меньше, чем D_NEXT_O_ID, больше либо равно D_NEXT_O_ID - 20). Это и есть товары из последних 20 заказов данной точки продаж.

  • В таблице ЗАПАСЫ по списку номеров отдельных товаров пересчитываются все ряды с соответствующими значениями S_I_ID (равное OL_I_ID) и S_W_ID (равное W_ID), значением S_QUANTITY, величина которого меньше порога (таким образом, вычисляется значение low_stock).

Комментарий: Запасы должны рассчитываться только для отдельных товаров. Таким образом, товары, встречающиеся более одного раза в 20 избранных заказах, должны быть собраны в одно итоговое значение для данного товара.

  • Выполняется текущая транзакция базы данных.

Комментарий: Не нужно выполнять транзакцию, пока не удовлетворены все требуемые ACID свойства (см. пункт 2.8.2.3).

  • Выходные данные (см. пункт 2.8.3.3) передаются терминалу.

2.8.2.3 Для деловой транзакции Уровень Запасов не требуется проводить полного упорядочивания и многократного считывания данных. Еще до запуска транзакции все считывания должны быть выполнены не позже, чем самые последние данные были обработаны. Все остальные ACID свойства должны быть учтены.

Комментарий: Данный параграф позволяет разбивать транзакцию на несколько частей.

2.8.3 Терминал ввода/вывода

2.8.3.1 В начале тестирования терминал должен отображать следующий экран ввода/вывода. На этом экране все поля ввода и вывода должны быть очищены. Исключение составляют поля Склад и Точка Продаж, информация в которых не меняется и должна содержать значения W_ID и D_ID, связанные с данным терминалом.

Stock-Level – Уровень Запасов
Warehouse – склад
District – точка продажи
Stock Level Threshold – пороговое значение уровня запасов
Low stock – низкий уровень запасов

2.8.3.2 Пользователь должен ввести необходимую информацию в соответствующее поле (threshold) экрана ввода/вывода.

2.8.3.3 Терминал должен отобразить в соответствующем поле экрана ввода/вывода всю входную и выходную информацию, полученную в результате выполнения транзакции. Должны отображаться следующие поля: W_ID, D_ID, threshold и low_stock.

2.8.3.4 Следующая таблица подводит итог требований терминала ввода/вывода к транзакции Уровень Запасов.

2.8.3.5 Основные требования терминала ввода/вывода описаны в параграфе.