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

Автор: Олег Анатольевич Мостовлянский
Издательство: Издательские решения
Серия:
Жанр произведения: Компьютеры: прочее
Год издания: 0
isbn: 9785449066596
Скачать книгу
теперь «второе лицо» сущности 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)

      Смешно, но понимание необходимости регистрации местоположения хранимой единицы – а этот атрибут уж никак не специфичен для библиотечного фонда, он обязателен для любого каталога – никак не найдёт своей дороги в массы. Пример: аптека в Минске (столица «незалежнай Беларусі»). Проверив по компьютерной базе (!) наличие запрошенного