Вечный двигатель третьего рода. Неканонические размышления о бизнес-системах, или О чём стоит сначала подумать. Модели данных и бизнес-логика - страница 4

Остановка получается недолгая, ибо решение очевидно и просто: каждая единица информации (Unity) может быть в то же время и собранием (Collection) подобных единиц.

Вернёмся к теме – Unity.

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

– значение атрибута абсолютно произвольно (так называемый «мануальный ввод»), либо

– значение атрибута должно быть задано из определённого списка значений (выбор из справочника).

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

Отметим, что и уникальные атрибуты могут выбираться из справочников – например, при наличии неких доменных ограничений. В этом случае необходим дополнительный контроль единственности выбора… но, как говорится – любой каприз за ваши ресурсы.

Итак:

Разберём по позициям. На первый раз – подробно.

Уникальный идентификатор, который будет использоваться для организации связей с другими структурами данных библиотеки. Требования к нему:

– лёгкость автоматического генерирования уникальных значений,

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

– минимальный физический размер поля.

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