5. Спецификация Базы данных
В дополнение к сказанному каждое Приложение должно иметь по крайней мере одну Базу данных, в которой отыскиваются Правила. Важно отметить, что данная База может использоваться и другими Приложениями. В таких случаях каждое правило должно использовать некую комбинацию своих служб (Service) и/или выражений для замены, соответствующую только той строке Application Unique Strings, для которой правило корректно.
Спецификация базы данных должна включать перечисленные ниже компоненты.
- General Specification — общая спецификация
- База данных должна иметь общую спецификацию, в качестве которой может использоваться ссылка на другой стандарт (SQL, DNS и т.п.) или полностью определенная новая спецификация. Спецификация Базы данных должна четко указывать допустимый набор символов, чтобы знать, какие наборы символов используются для представления Ключей и Правил.
- Lookup Procedure — процедура поиска
- Этот параметр задает способ формулировки и подачи запросов. В случае использования базы данных для других целей (например, DNS) спецификация должна ясно показывать, как формулируются запросы применительно к случаю DDDS. Например, База данных на основе DNS должна указывать используемые типы записей RR и запросов (Query).
- Key Format — формат ключа
- Если требуются какие-либо операции для преобразования Ключа во что-либо корректное для базы данных, такие преобразования должны быть четко определены. Например, в случае базы данных DNS Ключи должны создаваться как корректные доменные имена.
- Rule Format — формат правила
- Спецификация выходного формата для правила.
- Rule Insertion Procedure процедура вставки правила
- Спецификация вставки Правил в базу данных. Эта спецификация может включать политику, в соответствии с которой Правила могут или не могут добавляться в базу данных.
- Rule Collision Avoidance — предотвращение конфликтов между правилами
- Поскольку База данных может использоваться множеством Приложений (например, ENUM и URI Resolution), спецификация должна четко описывать способы предотвращения конфликтов между правилами. Обычно для решения этой задачи используются два метода: 1) запрет для одного ключа возможности быть корректным в двух разных Приложениях; 2) если вариант 1 невозможен, создается такое выражение для замены, чтобы регулярное выражение включало достаточную часть Application Unique String для идентификации различия между двумя Приложениями.