Neuro Lab! Algorithms

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

Мастер-класс проектирования модели данных (как части информационной модели)
на примере кейса "Золотая рыбка"

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

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

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

Жил старик со своею старухой


У самого синего моря

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

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

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г.
Котики и цифровизация бизнеса
Также материал по теме