Вечный двигатель третьего рода. Неканонические размышления о бизнес-системах, или О чём стоит сначала подумать. Модели данных и бизнес-логика. Олег Анатольевич Мостовлянский
Читать онлайн книгу.теперь «второе лицо» сущности Unity – способность представлять собой объект Collection. Сделать это можно разными способами – в зависимости от конкретной концепции организации коллекций.
Для простоты и наглядности просто представим ситуацию в виде графа:
То есть, каждая единица может быть (либо не быть) коллекцией ненулевого числа отдельных хранимых единиц (связь collection_of), а каждая хранимая единица заведомо существует и может входить (либо не входить) в различное число коллекций (показано связью collected_in).
Например, роман «Война и мир» Льва Николаевича Толстого (бумажная книга без приложений в виде компакт-диска с аудио-версией или ролевой игрой по сюжету) коллекцией сам не является, но в принципе может являться частью коллекции «Сочинения Л. Н. Толстого» (если какое-либо издательство выпустило такую серию). Но: если коллекцией является некое «Собрание сочинений Л.Н.Толстого в… томах», то элементом такой коллекции будет не конкретное произведение, а «Том номер такой-то». А какие произведения будут в этом томе – уже дело содержания. В общем, хозяин – барин, но принцип понятен.
Оговорка насчёт «бумажной книги без приложений» весьма существенна: книга по какой-либо проблеме программирования, к которой прилагается диск с примерами, в данной схеме – уже коллекция.
Каких-то дополнительных специфических атрибутов – по сравнению с «базовой» Unity – Collection не предполагает. Однако появляется некоторая поведенческая специфика:
– экземпляр Unity не может быть Collection для самого себя;
– удалён может быть только тот экземпляр Unity, который ни для кого более не является Collection.
То есть:
– связь collected_in объекта Unity не может указывать на самого себя;
– у удаляемого экземпляра Unity не должно быть связей collection_of.
Коллекции являются не некоей исключительной прерогативой хранимых единиц библиотечного фонда, а общим концептуальным конструктивным элементом структур данных, позволяющим организовывать иерархию объектов, и будут встречаться и в дальнейшем. Поэтому рассуждения о них и были выделены в отдельный пункт.
Имплементационно-специфичным моментом здесь является реализация связей (в случае Unity – collected_in и collection_of; далее встретятся и другие). В частности, в реляционных базах данных для этого могут быть использованы таблицы перекрёстных ссылок, позволяющие организовывать связи типа «многие ко многим» (many-to-many). Надо только не забывать регулировать взаимоотношения связанных объектов в базе при действиях над ними (On Update, On Delete) правилами – CASCADE, RESTRICT… – и всё получится.
Местоположение хранения (Placeholder)
Смешно, но понимание необходимости регистрации местоположения хранимой единицы – а этот атрибут уж никак не специфичен для библиотечного фонда, он обязателен для любого каталога – никак не найдёт своей дороги в массы. Пример: аптека в Минске (столица «незалежнай Беларусі»). Проверив по компьютерной базе (!) наличие запрошенного