Комментарии 6
Практика показывает, что классический Anchor Modeling, несмотря на все его несомненные достоинства для ядра (детального слоя) хранилища данных, бывает очень неудобен в некоторых важных случаях. Например, в эту методологию не укладываются такие вещи, связанные с событиями, как таблица бухгалтерских проводок, лог (журнал), очередь сообщений. Поэтому Anchor Modeling модифицируют. Примеры:
Я добавил к своей статье комментарий на эту статью Николая Голова
Привет! Мы тоже используем в работе производную от Anchor Modeling модель (Minimal Modeling). С событиями да, тоже замечали такую проблематику.
Сори, сейчас будет длинный комментарий :)
Вообще интересно, откуда берутся event'ы (давайте для простоты про мобильные event'ы только поговорим). Event’ы берутся из взаимодействия пользователя с интерфейсными элементами. Например:
USER clicked BUTTON
USER viewed PRODUCT_CARD итп
Где button, product_card - это реально анкера (в терминах Anchor Modeling), а действие с ними (USER clicked BUTTON) - это честный линк.
Но вместо «USER clicked BUTTON» логируется событие «green_button_click», которое содержит в себе след этого линка с потерей анкера + атрибуты.
В общем event - это реально линк, в котором мы потеряли информацию, и поэтому оно такое стрёмное.
Ещё про event’ы отдельно интересно, что они (почти) всегда достаточно хорошо документированы. Потому что прежде чем event’ы появляются в мобилке или на сайте, например, сначала появляется натурально ЭКСЕЛЬКА, в которой написано как именно какой event называется, когда логируется, какое-то у него есть описание, иногда даже скриншоты места в приложении откуда оно логируется.
Ну то есть у отдельного event’а самого по себе так-то довольно много самостоятельных описательных атрибутов.
Ну и простое следствие из этих рассуждений - что рядом с этим вот стрёмным анкером event есть анкер event_catalog со списком логируемых событий и их честными атрибутами.
И следующая мысль: а не получится ли на уровне вот этого event_catalog’а восстановить у event’а потерянный анкер и семантику линка (все равно event catalog это полностью ручная штука), и не появится ли от этого в event’ах интересного слоя дополнительного смысла.
Ну то есть, например, событие green_button_click не получится ли восстановить до USER clicked Button (с двумя анкерами, ликнком между ними и атрибутом green).
Мы как-то провели эксперимент и раскрыли User made Event в недостающие анкера и получилась вот такая штука:
То есть, в трекинг-плане например были события:
onboarding_shown
onboarding_second_step_shown
onboarding_third_step_shown
onboarding_fourth_step_shown
onboarding_fifth_step_shown
Каждое из этих событий – это атрибут линка "USER views ONBOARDING_SCREEN".
В общем мы сейчас размышляем о том, как бы на уровне инструмента ведения трекинг-планов вернуть потерянные анкера для этих event'ов. Потому что если получается так делать, то возникает еще интересная связка события с объектом реального мира (например, с конкретным товаром, item'ом итп)
А откуда получается потеря сущностей (Anchor-ов)?
Потери вообще недопустимы.
USER clicked BUTTON - такое событие заполняет три сущности: UserEvent, User, Button.
Это обязательно и в классическом моделирование, и в концепции Streams.
Далее в классическом подходе нужно заполнить две связи (Link, Tie, Relation) событие->user, событие->button
А в концепции Streams ключевые связи интегрируются в денормализованную таблицу S_UserEvent, содержащую User_id и Button_id.
По поводу значительно количества событий - представьте, что аналитику нужно проанализировать все события, произошедшие с пользователем на сайте. Сколько таблиц ему нужно проанализировать? 10, 20.... или только одну: S_UserEvent?
Дилемма моделирования в рамках Data Vault/Anchor Modeling: объект или событие