Comments 19
Вопрос - l_sales_order_order_detail_product какая из сущностей этого линка является драйвером? Как определить драйвер линка? Как регистрируются и где хранятся изменения в линках?
ER диаграмма ужасная, линии и объекты пересекаются и не видно, что от чего зависит.
Самое интересное в DV это линки, и по ним можно понять умеет автор в DV или нет. Любые транзакции, факты, проводки - это линк, а не хаб, в данной схеме h_order_detail - лишний, и должен быть линком.
Ну и тема историчности линков в статье не раскрыта, спойлер в самом линке не должно быть периода действия. Так же не раскрыта тема сателлита на линк.
А что такое вообще историчность проводки? Ну то есть какой бизнес-атрибут проводки может быть изменён во времени, который требует историчности? Кроме например какой-то реверсивной проводки.
Хороший вопрос, правильный, для этого у Линстеда есть определение "транзакционного линка" (transaction link, т.е. линка у которого нет сроков действия), но поскольку мы не только про банк, то тут может быть понятие историчности, скажем, я наблюдал при реализации DV для крупного поставщика, когда строка в заказе без сторно "пропадала" задним числом в течении месяца, или появлялась новая строка. Или скажем менеджер по заказу менялся несколько раз, если есть хаб заказ и хаб сотрудние и линк менеджер по заказу, и тут надо поддерживать историчность для этого линка, т.е. если бы мы получили отчет с 5 по 10 сентября, то менеджер был бы один, а если 11 сентября то другой.
Вообще говоря, весь DV про то, чтобы получить отчет за август, как он выглядел 8 сентября, сегодня 16 октября, когда прошла масса изменений задним числом. Если нет изменений задним числом, и отчет нужен только как он выглядит сегодня, то DV вообще не нужен.
с чего вдруг h_order_detail это линк. Что он с чем связывает? ордер с ордердетейлом? так уже есть один такой, линк на линк делать будешь???
Подумал, что о DV уже наконец забыли.
Картинка, позволяющая понять смысл проблемы с дата волтом https://habr.com/ru/articles/505292/comments/#comment_21704338
Перечислены конкретные проблемные моменты https://habr.com/ru/articles/502968/comments/#comment_21683308
Ну DV служит вполне определенной цели и не является, конечно же, панацеей. Во главу угла ставиться расширяемость в условиях неопределенности. Сколько раз в моей практике было, что приходилось ломать голову как изменить модель детального слоя хранилища (спроектированную не по DV), чтобы загрузить в него новый источник или доработать под поддержку совершенно нового бизнес кейса (после измерений в бизнес-системе), при этом не сломав уже то, что работает.
By design DV не подходит для аналитики. Поэтому пенять на необходимость множества джоинов и наличия множества таблиц, и тем более сложность использования для аналитики - не совсем разумно. Для аналитики надо архитектурно предусмотреть как минимум витрины поверх DV.
ну отодвинули проблему доработки под новый бизнес кейс на уровень витрин. От этого она не исчезнет.
Поскольку Data Vault 2.0 не зависит от платформ, NoSQL можно использовать на всех уровнях хранилища данных, включая подготовку данных, корпоративное хранилище и уровень предоставления информации.
Хм... Автор действительно "Эксперт в инженерии данных" если предлагает NoSQL для "корпоративного хранилища данных"? Все же "6 лет опыта" - мало чтобы считаться "экспертом".
Имхо, очередной вольный пересказ матчасти. Вопрос - зачем?
Технология проектирования хранилищ данных Data Vault 2.0