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

Здесь есть возможность читать онлайн «Олег Мостовлянский - Вечный двигатель третьего рода. Неканонические размышления о бизнес-системах, или О чём стоит сначала подумать. Модели данных и бизнес-логика» — ознакомительный отрывок электронной книги совершенно бесплатно, а после прочтения отрывка купить полную версию. В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. ISBN: , Жанр: popular_business, Прочая околокомпьтерная литература, на русском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

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

Предлагаем к чтению аннотацию, описание, краткое содержание или предисловие (зависит от того, что написал сам автор книги «Вечный двигатель третьего рода. Неканонические размышления о бизнес-системах, или О чём стоит сначала подумать. Модели данных и бизнес-логика»). Если вы не нашли необходимую информацию о книге — напишите в комментариях, мы постараемся отыскать её.

Автор на основе своего опыта работы предлагает перечень тем и ситуаций, над которыми желательно предварительно хорошенько подумать.

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

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

Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

В самом конкретном – в комнатах стоят шкафы или стеллажи, на полках – книги, которые содержат произведения (одно или много; или же – часть) каких-либо авторов… Это – случай классической библиотеки. Более современный случай – в фонде имеется информация, хранимая в электронном (оцифрованном) виде, в виде файлов. Файлы могут находиться как на носителях типа дискет (а что? вдруг ещё остались где-нибудь), магнитных лент (это вообще раритеты), компакт-дисков (CD, DVD, BD и т. п.), а также на накопителях (т. н. жёстких дисках) серверов. Носители будут храниться как и книги, на полках (либо в ящиках) шкафов, сервера будут расположены в комнатах – так что принципиальных отличий здесь не видно.

Сделаем первый шаг.

Назовём основные сущности:

– хранимая единица информации – Unity

– местоположение хранения этой единицы – Placeholder

– содержание хранимой единицы информации – Content

Связаны они следующим образом:

Что видно из этой диаграммы В месте хранения Placeholder может находиться - фото 1

Что видно из этой диаграммы?

– В месте хранения Placeholder может находиться несколько хранимых единиц Unity , но может не быть и ни одной. Это показано связью ( relation ) is_place_for .

– Каждая хранимая единица Unity обязательно находится в одном (и не более! это вроде само собой понятно) месте хранения Placeholder (показано связью placed_on ).

– Каждая хранимая единица Unity обязательно – поскольку речь идёт об информации – имеет вполне определённое содержание Content . Причём – только одно. Связь contains .

– Напротив, содержание Content вполне может относиться к нескольким (одной и более) хранимым единицам Unity (связь contained_in ). Пример – несколько экземпляров одной книги.

Это – самое общее представление. Будем рассматривать эти сущности более детально, и в том же порядке, в котором они были декларированы: Unity , затем Placeholder , ну и напоследок Content . Возможно (то есть, практически наверняка), что-то ещё добавится по пути, в процессе.

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

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

И – о, Гринпис, где твой ледокол! – при рисовании схем и написании текста ни одно животное не пострадало.

Хранимая единица информации (Unity)

Итак, для начала – хранимая единица информации Unity . Очевидно, она должна описывать предметы, которые хранятся в фонде, учитываются как отдельные единицы и могут выдаваться абонентам. Что может храниться в библиотеке?

– Книги,

– журналы,

– газеты,

– рукописи,

– ксерокопии,

– микрофильмы,

– микрофиши,

– магнитные, оптические и прочие современные нам носители,

– и т. д., и т. п. – в общем, всё, что только может содержать информацию.

Здесь надо немного остановиться. Вопрос касается файлов.

С одной стороны, файл – отдельная законченная единица информации. С другой стороны, в одном файле может содержаться несколько независимых единиц информации – например, оцифрованных книг, репродукций и т. п. И с третьей стороны – один хранимый экземпляр носителя информации (например, компакт-диск) может содержать несколько файлов. Кстати, этот компакт-диск может быть не самостоятельным – а приложением к какой-либо книге…

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

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

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «ЛитРес».

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

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

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


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

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

x