В ежеквартальном сообщении за 1999 год описание каждой объявленной части
появляется только однажды. Мы могли бы усилить это ограничение, используя unique.
Однако мы также хотим гарантировать,
чтобы каждый отдельный элемент, перечисленный под почтовым индексом, имел
описание соответствующей части. Мы усиливаем ограничение, используя элементы key
и keyref
. Схема отчета, report.xsd
, показывает, что конструкции key
и keyref
применяются почти с тем же самым синтаксисом, что и unique
. Элемент
key
применяется к
значению атрибута number
элементов part
, которые являются дочерними элемента parts
. Такое объявление number
как ключевого означает, что его значение
должно быть уникально и не может быть установлено в ноль (то есть всегда не
нулевое), а имя, которое связано с ключом, pNumKey, позволяет ссылаться на ключ из любого места.
Чтобы
гарантировать, что отдельные элементы имеют соответствующие им части
описания, мы говорим, что атрибут number
(<
field>@
number</
field>
) этих элементов (<
selector>
zip/
part</
selector>
) должен ссылаться посредством ключа pNumKey. Такое объявление number
как keyref не означает, что его значение должно быть уникально, но это
означает, должен существовать pNumKey с тем
же самым значением.
Как вы могли заметить, по
аналогии с unique
можно определить комбинации значений key
и keyref
. Используя тот же механизм, мы можем
выйти за пределы простого требования равенства номеров изделий и определить
комбинации значений, которые должны быть равны. Такие значения могут задавать
комбинации нескольких типов значений (string
, integer
, date
и т.д.), для которых задание порядка и
типа ссылок элементов field
является одинаковым как в определении key
, так и
keyref
.