Глава 1 - Логическая структура базы данных |
|
Содержание:
1.1 Деловая и программная среда 1.1 Деловая и программная среда Тестирование ТРС включает в себя набор базовых операций, разработанных для испытания системной функциональности путем отображения среды комплексных OLTP-приложений. Эти базовые операции были использованы в приближенном к реальности контексте и, чтобы помочь пользователям интуитивно работать с компонентами теста, они отображают активность оптового поставщика. Основная работа сосредоточена на обработке запросов и формирует логическую структуру базы данных, которая может быть распределена без структурных изменений в транзакциях. ТРС-С не дает представления об определенном сегменте рынка, скорее, в целом об индустрии, которая управляет, продает или реализует программу или услугу (например, прокат автомобилей, доставка еды, поставка запчастей, и т.п.) ТРС-С не пытается быть моделью того, как построить реальное приложение. Целью испытания является уменьшение количества операций, обнаруживаемых в производственных приложениях при сохранении основных качественных характеристик приложения, а именно: уровень загрузки системы и сложность операций. Для управления системой ввода заказов требуется выполнять большое количество функций. Многие из этих функций не важны при анализе быстродействия, т. к. они незначительны в терминах загрузки системы или в терминах частоты обращения. Несмотря на то, что эти функции необходимы для производственной системы, они создают огромное многообразие в контексте стандартного тестирования и опускаются в ТРС-С. Компания, отображаемая в тестировании, является оптовым поставщиком с огромным количеством географически удаленных складов и точек продаж. По мере роста компании создаются новые точки продаж и связанные с ними склады. Каждый региональный склад обеспечивает 10 точек продаж. Последние, в свою очередь, обслуживают до 3000 клиентов каждая. Все склады поддерживают запас в 100 000 единиц товара, предлагаемого компанией. Следующая диаграмма показывает иерархию складов, точек продаж и клиентов в ТРС-С окружении.
Клиенты звонят в компанию для размещения нового заказа или для выяснения статуса уже существующего. Заказ состоит в среднем из 10 позиций. Один процент от всех позиций составляют товары, отсутствующие на региональном складе, их нужно поставлять с другого склада. Система компании также используется для ввода платежей клиентов, обработки заказов на доставку и определения потенциально дефицитных товаров.
1.2 Элементы базы данных, связи и характеристики
Компоненты базы данных ТРС-С по определению состоят из 9 отдельных и индивидуальных таблиц. Взаимосвязь между этими таблицами определена в диаграмме межобъектного взаимодействия, приведенной ниже, и следует из правил указанных в Главе 1.4.
Все указанные цифры показывают частоту запросов базы данных (см. Главу 4.3). Числа в блоках показывают количество элементов в таблицах (число строк). Чтобы показать масштабность базы данных, эти значения делятся на число заказов W (см. Главу 4). Числа возле стрелок показывают количество взаимосвязей (среднее число дочерних объектов на каждый родительский). Символ «+», используемый после количества взаимосвязей, показывает, что это число подвержено небольшим изменениям по сравнению с исходным наполнением базы данных в течение всего измерения (см Главу 5.5), т. к. позиции добавляются или удаляются.
Следующий список определяет минимальную структуру (список свойств) каждой таблицы, в которой: NuniqueIDs означает, что свойство должно содержать любой ID среди множества Nне беря во внимание физическое представление свойства (например, двойной, упакованный десятичный, алфавитный и т.д.). variable text, size N (переменный текст, размер N) – свойство должно содержать строку символов переменной длины с N максимальным числом символов. Если же строка имеет фиксированную длину и эта длина меньше N, то она должна быть заполнена пробелами. fixed text, size N (фиксированный текст, размер N) – свойство должно содержать строку символов фиксированной длины, равной N. Data and Time (Дата и время) – представляет собой типы данных, используемых для даты, включая компоненту времени. Дата должна быть в пределах от 1 января 1900 года до 31 декабря 2100 года. Время же должно быть в пределах от 00ч 00мин 00сек до 23ч 59мин 59сек с разрешением как минимум 1 секунда. Дата и время должны быть заполнены данными, тип которых задается СУБД. numeric(m [,n]) (Числовое значение (m [, n])) – это числовое значение без знака с m минимальным числом знаков, причем n – число знаков после запятой. Свойство должно содержать любое допустимое число, которое можно описать, как числовое значение (m, n). Пренебрежение значением n, как, например, в NUM(m), эквивалентно NUM(m, 0). Числовые поля, содержащие денежные величины (W_YTD, D_YTD, C_CREDIT_LIM, C_BALANCE, C_YTD_PAYMENT, H_AMOUNT, OL_AMOUNT, I_PRICE), должны содержать данные, тип которых задается СУБД как точный числовой тип данных, или удовлетворять ANSI SQL стандарту, будучи точным числовым представлением. signed numeric(m [,n]) (Числовое значение (m [, n])) со знаком – идентично numeric(m [,n]) за тем лишь исключением, что может быть представлено как положительным, так и отрицательным значениями. Null – означает выход за пределы значений, допустимых для данного свойства.
Комментарий 1. Для каждой таблицы свойства могут быть представлены в любом порядке путем любого физического представления, доступного в тестируемой системе. Комментарий 2. Таблица и имена свойств используются только по назначению; программой могут быть использованы различные имена. 1.4.1. Допускается физическая кластеризация записей базы данных. 1.4.2. Для предупреждения логического чтения/записи, исключен режим просмотра, который отображает ряды. Комментарий: цель данной главы – удостовериться, что приложение выполняет ряд логических операций, заданных транзакционным профилем, и при этом, используя просмотр, не объединяет их в одно действие. 1.4.3. Все таблицы должны иметь определенное число рядов, как этого требуют правила заполнения базы данных (см. пункт 4.3) 1.4.4. Допускается горизонтальное разбиение таблиц. Группы рядов могут относиться к различным файлам, дискам или областям. В случае подобного деления все детали этой операции должны быть подробно изложены. 1.4.5. Допускается вертикальное разбиение таблиц. Группы свойств (столбцы) одной таблицы могут относиться к разным файлам, дискам, или областям. В случае подобного деления все детали этой операции должны быть подробно изложены (ограничения описаны в пункте 1.4.9). Комментарий: В двух предыдущих пунктах (1.4.4 и 1.4.5) закрепление данных за различными файлами, дисками или областями не учитывает информацию о логической структуре данных (т.е., информацию о границах рядов или столбцов). Например, распределение или чередование блоков данных файла, по устройствам дискового массива, содержащего одну или несколько логических таблиц на разных дисках, не берется во внимание при его разделении на части. Это связано с тем, что подобное разделение выполняется аппаратными средствами или операционной системой, без наличия информации о структуре этого файла. 1.4.6. Для всех таблиц допускается дублирование. Все копии таблиц должны соответствовать требованиям ACID (атомарность, непротиворечивость, изолированность, долговечность), как указано в Главе 3. В таком случае все детали этого копирования должны быть подробно изложены. Комментарий: Только одна копия таблицы должна соответствовать требованию о долговечности, описанному в Главе 3. 1.4.7. Свойства можно добавлять и/или копировать из одной таблицы в другую, но при этом производительность системы не должна возрастать. 1.4.8. Как описано в пункте 1.3.1, каждое свойство должно быть логически дискретным. При этом оно должно быть доступно системе управления базой данных (СУБД). Например, W_STREET_1 и W_STREET_2 не являются частями одного и того же свойства W_STREET. 1.4.9. Как указано в пункте 1.3.1, каждое свойство должно быть доступно системе управления базой данных (СУБД), как единственное. Например, S_DATA не может быть представлено как два дискретных свойства S_DATA_1 и S_DATA_2. 1.4.10. Первичный ключ каждой таблицы не должен прямо указывать местонахождение рядов на физическом диске. Программа может и не ссылаться на ряды посредством косвенной адресации, так как они являются всего лишь выносом с первоначального места хранения. Это не исключает схем хеширования или другой организации файлов, которая бы позволила добавлять, удалять или вносить изменения в записи. Исключением является таблица ИСТОРИЯ, в которой может использоваться косвенная адресация, но все остальные требования к этой таблице обязательно должны быть учтены. Комментарий 1: Цель данного параграфа состоит в том, чтобы при выполнении транзакции или утверждении транзакционного запроса прикладная программа (см. пункт 2.1.7) для всех доступов использовала не физические, а логические идентификаторы. Она не должна содержать пользовательского кода, способного привести или переводящего логический ключ к виду, который указывает расположения соответствующих рядов и столбцов таблицы. Комментарий 2: Внутренние записи или идентификаторы рядов, как, например, энное число ID идентификаторов или курсоров, могут использоваться при соблюдении следующих условий: 1.4.11. Во время тестирования, пока в таблицах не выполнены все добавления или удаления записей, систему нельзя конфигурировать. Хотя заполнение таблицы по определению ограничивается доступным свободным местом, должна быть предусмотрена возможность вставлять в таблицу дополнительные ряды в количестве до 5% от общего числа, а значение ключа должно превышать значения, представленные в таблице минимум в 2 раза. Комментарий: Перед началом тестирования требуется провести оценку свободного пространства, при необходимости выделить дополнительное место, объемом в 5% от размера таблицы. Для подобных систем, свободное место должны рассматриваться как выделенное, а при расчетах учитываться как постоянное. 1.4.12. Минимальная десятичная точность каждого из вычислений, являющихся частью прикладной программы, должна быть равна максимальной точности каждой отдельной операции в данном вычислении. 1.4.13. При выполнении теста все остальные правила, описанные в данном документе (например, Правило Непротиворечивости, приведенное в пункте 3.3), также должны быть учтены. 1.4.14. Такие свойства таблицы, как текст переменной длины, текст фиксированной длины, дата и время, а также числа должны иметь тип, определяемый в СУБД (т.е., не прикладной программой), которая предназначена для хранения данных с заранее определенными типами этих свойств. Например, дата и время должны быть реализованы тем типом, который предназначен для хранения информации о дате и времени. 1.5.1. В рамках каждой таблицы в передаваемой структуре данных, значения первичного ключа должны быть уникальными. Например, в случае горизонтального разбиения таблицы, уникальными должны быть значения первичного ключа рядов для всех ее частей. 1.5.2. В любой передаваемой структуре данных не допускается присутствие неправильно оформленных рядов. Ряд считается неправильным, если какое-либо из его свойств не может быть определено. Например, при вертикальном разбиении таблицы ряд должен присутствовать в каждой части таблицы. 1.6 Требования четкости доступа к данным Четкость доступа к данным – это свойство системы, которое удаляет из программы любую информацию о размещении и механизмах доступа к данным, разделенным на части. Программа, которая использует вертикальное и/или горизонтальное разбиение, должна учитывать требования четкости доступа к данным, описанным в данном параграфе. Ни одна ограниченная серия тестов не может доказать, что система поддерживает полную четкость доступа к данным. Приведенные ниже требования определяют, имеет ли система четкий доступ к данным. Комментарий: Цель данного параграфа – убедиться, что службы таких прикладных программ, как СУБД, операционная система, аппаратные средства или любое их сочетание, предоставляют прямой и ясный доступ к данным, физически и/или логически разбитым на части. 1.6.1. Каждая из 9ти таблиц, описанных в параграфе 1.3, должна распознаваться по имени, которое никак не связано с разделением таблиц. В прикладной программе все операции по обработке данных должны использовать только эти имена. 1.6.2. Система не должна выполнять операции с данными, использующими упомянутые выше названия, которые могут привести к нарушению правила непрерывности (см. параграф 1.5). Например, система должна предотвращать вставку рядов в вертикально разбитую таблицу при помощи программы, разработанной не ТРС-С, если все части этих рядов еще не вставлены. 1.6.3. Используя названия, удовлетворяющие условиям пункта 1.6.1, программа должна быть способна управлять любым количеством рядов или столбцов, которые: Например, семантика и синтаксис, которые используются при обновлении случайного набора рядов в любой из таблиц, должны так же применяться и при обновлении случайного набора рядов в других таблицах. Комментарий: Задача состоит в том, чтобы для управления записями в базе данных ТРС-С программа использовала основные целевые методы.
|
