может быть реализован, например, как
TEXT,
CHAR (n) либо
VARCHAR (n), где
n – длина поля.
Индексация по этому полю желательна как для возможности сортировки по алфавиту, так и для структурного поиска (по вхождению слов). Частный пример реализации второго случая – использование DB2 Text Extender.
Местоположение хранимой единицы. Как и в случае библиотечного кода, формат данного поля представлен чисто условно. В реальной системе это должен быть либо конкретный адрес, где находится книга (либо другой хранимый объект) – комната, шкаф/стеллаж, полка/ячейка, – и тогда рациональней использовать набор из нескольких полей (атрибутов), либо путь к файлу – тогда, как и для поля name, будут действовать зависящие от платформы реализации ограничения на длину. Но и в этом случае – поскольку полный путь включает сетевое имя сервера (или сетевого диска; или локального диска – если сервер один) и иерархию каталогов – удобнее всё же будет использовать набор полей.
Естественно, требование уникальности неприменимо к местоположению/пути в любом случае: как на одной полке может стоять много книг, так и в одном каталоге может находиться множество файлов.
Если сущность определяется как Collection – то единого пути может не быть (подшивка Chemical Abstracts за несколько десятков лет ну никак не вместится на одну полку), и атрибут (или набор атрибутов) будет не заполнен. Но это – только для Collection, все единичные Unity – в том числе и входящие в различные Collection – должны где-то находиться, и path у них должен быть заполнен (см., впрочем, >*)).
Совершенно закономерен здесь вопрос (если следить за процессом рассуждений внимательно – а не по принципу «в одно ухо вошло – из другого… м-м-м…») о правомерности существования этого самого атрибута: зачем он здесь, если местоположение хранимой единицы достаточным образом описывается связью placed_on к объекту Placeholder?
Атрибут Unity::path является производным (образно говоря, суммой по некоторым – конкретным для каждой имплементации – правилам) от полной иерархии связанных по placed_on объектов Placeholder, а именно атрибутов Placeholder::path. Содержимое его, соответственно, меняется синхронно изменениям в иерархии связанных объектов Placeholder (как это будет реализовано – на уровне базы данных, или же на уровне приложения – целиком на совести имплементатора).