Сказка о рыбаке и рыбке - строим модель данных

В рамках повышения технологической грамотности наших заказчиков - подготовили материал с пошаговым описанием создания модели данных по произведению А.С. Пушкина "Сказка о рыбаке и рыбке" (Золотая рыбка). Вдруг кому :)

Модель данных - ядро информационной системы

Давайте спроектируем модель данных на примере сказки (кейса) "О рыбаке и рыбке" Александра Сергеевича Пушкина

Модель данных - это система, отражающая ключевые сущности (объекты управления), их атрибуты и связи

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

Давайте разберем - какие ключевые сущности (объекты) мы видим?

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

oldWoman - Старуха
oldMan - Старик

Движемся дальше. Тезис, что "Старуха своя" - толкуем таки, что Старик и Старуха сформировали ячейку общества - Family

Уже возникают интересные нюансы в проектировании и построении учетной информационной системы

Связь oldWoman - oldMan можно реализовать и без таблицы Family добавив Старику и Старухе по атрибуту (строке), содержащему ссылку на супруга spouseId и
указав взаимные связи между объектами

Такой подход с одной стороны - облегчит проектируемую систему (минус одна таблица), но с другой стороны и уменьшатся учетные возможности нашей информационной системы. Если Старик разведется со Старухой (удалится связь; сорри за спойлер), то мы потеряем данные, что они были женаты

Использование же таблицы Family (для учета семей), позволяет нам хранить в базе данных всю актуальную и архивную информацию о таком важно объекте управления, как - семья

Движемся дальше - фиксируем новые сущности (объекты)

See - море (которое "самое синие")
Land - суша, на которой живут Старик со Старухой

По сути - это два фундаментальных объекта управления в кейсе про "Золотую рыбку". Так что игнорирование данных объектов значительно снизит качество нашей будущей информационной системы

p.s. По уму See и Land это просто два разных представителя (конкретизация) такой сущности как Пространство (как Старик и Старуха - Человек), однако для простоты восприятия мы их различим

Они жили в ветхой землянке

Ровно тридцать лет и три года.

Старик ловил неводом рыбу,

Старуха пряла свою пряжу

 

Видим, что живут они не в чистом поле (Land), а в ветхой землянке - Building (называем так, потом что Building будет претерпевать значимые физические и информационные изменения; сорри за спойлер)

Стаж проживания в тридцать лет и три года можно отнести как к свойству Family, так и к связи Family - Building (Тонкое отличие: семье может быть 33 года, но проживали они в разных локациях). Однако не будем перегружать нашу модель в виду несущественности данной информации в нашем кейсе. Равно как и проигнорим пряжу, но не - невод

FishingTool - невод

Обратите внимание на связи:
Family связана (проживают) с Building, а Building в свою очередь находится (связано) на Land.
Ну а инвентарный номер fishingToolId логически закреплен за oldMan

Далее. От статической картинки дошли до процессов - "старик ловил"
Обратите внимание - бизнес-процесс "ловля неводом рыбы" (и его результат) пока никак не могут быть отражены в нашей модели данных. Пока у нас имеется только oldMan, fishingTool и связь между ними

 

Раз он в море закинул невод, —

Пришел невод с одною тиной.

Он в другой раз закинул невод,

Пришел невод с травой морскою

 

Заброс невода в море - транзакция

Дошли до более тонкой темы - как организовать учет процесса и его результата

FishingAct - один заброс невода в море

Обратите внимание на параметры (атрибуты) FishingAct:
id - уникальный идентификационный номер (уже случилось два FishingAct)
fisher_id - идентификационный номер рыбака (у нас рыбак один - oldMan, но в теории их может же быть много )
fishingTool_id - идентификационный номер FishingTool (у нас это - невод, но может быть и удочка и запрещенка же всякая с разными инвентарными номерами)
sea_id - идентификационный номер Sea, в котором рыбачим (предусмотрим возможность рыбалки в различных водоемах)
startTime - дата и время заброса FishingTool в Sea
endTime - дата и время извлечения FishingTool в Sea (по разнице endTime - startTime - можно вычислить продолжительность операции)
result - описание того бесполезного, что оказалось в FishingTool по результатам fishingAct (типа, трава морская и прочее)
isGoldFish - оказалась ли в FishingTool gGoldFish? (boolean)

Пока ход бизнес-процесса "ловля рыбы" и его результаты отражаются следующими данными в нашей информационной системе:

В третий раз закинул он невод, —

Пришел невод с одною рыбкой,

С непростою рыбкой, — золотою.

Как взмолится золотая рыбка!

Голосом молвит человечьим:

«Отпусти ты, старче, меня в море,

Дорогой за себя дам откуп:

Откуплюсь чем только пожелаешь.»

Удивился старик, испугался:

Он рыбачил тридцать лет и три года

И не слыхивал, чтоб рыба говорила.

Отпустил он рыбку золотую

И сказал ей ласковое слово:

«Бог с тобою, золотая рыбка!

Твоего мне откупа не надо;

Ступай себе в синее море,

Гуляй там себе на просторе».

Очевидно, что у нас возникает объект GoldFish. Но это еще не все!

Также возникает уже "невидимый" объект - обязательства GoldFish перед OldMan. И это будет отдельный объект, при чем он будет спроектирован в логике связей - "многие к многим" (Для сравнения - связь OldMan - FishingTool - "один ко многим" - у одного рыбака может быть несколько девайсов для рыбалки, но у каждого девайса будет ровно один хозяин-рыбак)

GoldFish_OldMan_commitment - таблица по учету обязательств GoldFish (могу быть разные) перед OldMan (тоже могут быть разные; отсюда и логика связи "многие-к-многим"). Таблица для учета "рыбьей дебиторки" OldMan'а
 

При этом пока эта таблица - пуста («Бог с тобою, золотая рыбка! Твоего мне откупа не надо; Ступай себе в синее море, Гуляй там себе на просторе»)

Обратите внимание, что мы установили связь между GoldFish и Sea (убираем риск, что oldMan может забыть к какому Sea потом идти с каждым новым Commitment; сорри - спойлер)

Также по уму напрашиваются два существенных атрибута для GoldFish_OldMan_Commitment - дата и время возникновения обязательства (дебиторки), и дата и время исполнения обязательства (погашения дебиторки), но мы опустим данные параметры для упрощения модели (к тому же - точные данные этих параметров - безвозвратно утеряны)

Также обращаем внимание, что дальше меняется структура бизнес-процессов. FishingAct более не происходит - вся дальнейшая движуха происходит на связях OldMan с OldWoman и GoldFish

Воротился старик ко старухе,

Рассказал ей великое чудо.

«Я сегодня поймал было рыбку,

Золотую рыбку, не простую;

По-нашему говорила рыбка,

Домой в море синее просилась,

Дорогою ценою откупалась:

Откупалась чем только пожелаю.

Не посмел я взять с нее выкуп;

Так пустил ее в синее море».

Старика старуха забранила:

«Дурачина ты, простофиля!

Не умел ты взять выкупа с рыбки!

Хоть бы взял ты с нее корыто,

Наше-то совсем раскололось».

Не будем плодить новую информационную сущность про "коммуникационный акт" между OldMan и OldWoman (кстати, до этого и не коммуницировали в нашей кейс) - с управленческой точки зрения для нас важен факт того, что OldWoman формулирует содержание GoldFish_OldMan_Commitment и ставит соответствующую задач OldMan

Теперь у нас в базе данных появляется следующая запись (по аналогии с FishingAct)

Вот пошел он к синему морю;

Видит, — море слегка разыгралось.

Стал он кликать золотую рыбку,

Приплыла к нему рыбка и спросила:

«Чего тебе надобно, старче?»

Ей с поклоном старик отвечает:

«Смилуйся, государыня рыбка,

Разбранила меня моя старуха,

Не дает старику мне покою:

Надобно ей новое корыто;

Наше-то совсем раскололось».

Отвечает золотая рыбка:

«Не печалься, ступай себе с богом,

Будет вам новое корыто».

Воротился старик ко старухе,

У старухи новое корыто.

Еще пуще старуха бранится:

«Дурачина ты, простофиля!

Выпросил, дурачина, корыто!

В корыте много ль корысти?

Воротись, дурачина, ты к рыбке;

Поклонись ей, выпроси уж избу».

Ускорим сказку и сразу отразим всю историю транзакций в таблице GoldFish_OldMan_commitment

isKorytoExist - true
isKorytoBroken - true

Теперь вспомним вот эту фразу:

"По сути - Sea и Land это два фундаментальных объекта управления в кейсе про "Золотую рыбку". Так что игнорирование данных объектов значительно снизит качество нашей будущей информационной системы"

 

В итоге у финальная модель данных кейса "Сказка о рыбаке и рыбке" сложилась следующим образом

Информация - это различие

 

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

Грегори Бейтсон, "Разум и природа. Неизбежное единство", 1979г.

 

Оригинал статьи на нашем сайте

Наш телеграм канал - "Восстание машин"