Pull to refresh

Comments 27

Так в чем плюс-то от того, что факты заменяются на лишние anchors ???
Становятся реальными не только slow changing dimensions, но и slow changing facts. Историчность становится очень простой, доступной для включения в любой точке — как в измерениях, так и в фактах.
все равно не понятно. почему факт с ценой не позволяет историчность делать, а чек с ценой позволяет??
Факт (линк) с ценой в атрибуте: постарайтесь смоделировать ситуацию, когда у вас у факта меняется цена И ссылка на измерение. Например, для продажи — неправильный товар и неправильная цена.
Подскажу: проблема в том, что факт идентифицируется ссылками на измерение.
Т.е. честная полная историчность приводит к изменению идентификатора.
Проблему можно решить, но тут огромный риск ошибиться.
А у чека номер есть :)
Тогда получается можно создать промежуточную структуру между стандартной и анкор — для всех атрибутов для которых нужна историчность создаются отдельные таблица (или даже одна таблица), а атрибуты для которых не нужна историчность хранятся в одной таблицы и имеют один суррогатный ключ. Рассматривали такой подход?
Этот подход называется DataVault, ему уже 20 лет.
Спасибо за интересную статью. Никогда не думал о том, чтобы разбивать сущности настолько мелко, хоть и стараюсь провести полную нормализацию БД. Но по опыту могу сказать, что во всех проектах боязнь получить большое количество таблиц «душит» только вначале, а потом, когда уже все нормализовано, становится очень даже удобно и просто.

У меня к вам вопрос, влияет ли на скорость выполнение запроса (по сравнению с «обычной» БД) такое количество таблиц, например, когда надо за раз выбрать ФИО + ИНН + еще какие-то персональные данные?
Конечно, извлечение из единой денормализованной таблицы работает быстрее. Но не принципиально быстрее. Описанная стратегия сегментации гарантирует очень высокую эффективность join-а атрибутов отдой сущностив рамках нашей кластерной MPP базы.
В нашей практике мы делаем денормализованные витрины, где храним, например актуальные ФИО+ИНН+перс. данные людей. Но только актуальные. Кому нужна историчность, ретроспектива, люди работают уже с полностью историчными нормализованными таблицам атрибутов.
Я не делал такие замеры. Но, скажем, есть денормализованная таблица с 50 столбцами. Если из них запрашивается только часть, скажем, 5 столбцов, то наверное join'ы будут быстрее?
Это же колоночная база (!).
Даже при запросе 5 из 50 денормализованных простой селект будет быстрее.
Нормализация нужна для хранения. Если у вас с начала времен и до тепловой смерти вселенной будет 50 столбцов — одна денормализованная таблица выгоднее. Веселье начинается, когда у вас, например, у объявления сначала появляется метро, потом оно становится историчным, а потом разрешают вводить несколько метро (много-ко-многим). И такое за год-другой может произойти с дюжинами полей. В 2013 у нас у событий веб-лога было 30 атрибутов. Сейчас 90…
Точно, колоночная, тупанул :) Просто это один из мифов, что нормализация приводит к какой-то дикой просадке производительности. Даже эта ветка началась с воспроса о производительности. Если данные хранятся по строкам, то, скорее наоборот, возможен рост производительности.

А, кстати, зачем денормализовывать? Чтобы была проще реализация клиентской части?
Бизнес пользователи боятся кучи таблиц.
Опять же, в денормализванной таблице проще навернуть бизнес-логику.
Например, платежи можно представить тремя разными образами из одних и тех же сырых данных (сырые платежи, завершенные платежи, отраженные в фин-отчетности). Проще сделать три денормализованных таблицы платежей для разных подразделений. Меньше риск запутаться.
Спасибо за статью, есть несколько вопросов:
1. Не совсем понятно, по какому механизму генерируются суррогатные ключи, и где хранятся натуральные?
2. Как и какими средствами документируете все это?
3. С каким проблемами приходится сталкиваться?
1. Суррогат — автоинкремент. Identity в Vertica. Натуральные — либо в атрибутах, либо в особом поле в анкоре. Тут уже нюансы реализации.
2. Google Sheet + автогенерация документации для Confluence.
3… Постараюсь рассказать в следующих статьях :)
Возможно, будет интересно. Я делал редактор Anchor моделей с помощью Eclipse Sirius:
Разработка метамодели с помощью Eclipse Modeling Framework (и немного про моделирование данных)
Разработка визуального языка моделирования с помощью Sirius
Цикл статей планировал закончить генератором SQL, но пока пришлось отложить.
Да, мы с Ларсом видели, сразу был неожиданный скачок посетителей из РФ :)
У нас, кстати, в одном проекте используется похожий подход. Немного похвастаюсь :) В модели порядка 1000 сущностей, 2200 повторно используемых атрибутов (в Anchor, на сколько я понимаю, их нельзя повторно использовать, хотя, имхо, в этом и соль сильной нормализации… с другой стороны, это можно понять), 1200 связей и 700 типов данных.
Ну и хорошо. А что за проект, с чем связан?
Прибыльный?
Межгосударственный интеграционный проект типа того чем занимается UN/CEFACT или NIEM.
«Когда первый раз читаешь про Anchor Modeling, становится страшно.»
Это точно :). Очень смелое решение, учитывая масштаб проекта. Смотрел видео вашего доклада на конференции HPE и судя по вопросам, присутствующие там дядьки были весьма удивлены :). Респект!
Пару вопросов:
1) Витрины для Tableau у вас по Кимбаллу или другой подход? И сколько в них примерно таблиц и Тб?
2) Учитывая поддержку историчности для атрибутов, как аналитики пишут запросы, когда нужно получить срез на заданную дату (в срезе, например, несколько десятков полей). В Data Vault для этого можно использовать PIT таблицы. Интересно посмотреть на такой SQL запрос.
Спасибо :)
1. Либо по Кимбалу, либо еще более денормализованные, в единую таблицу. Tableau предпочитает минимум таблиц :) Таблиц — 160, примерно 15Тб. Про это будет следующая статья, с графиками.
2… Видимо, тоже следующая статья :)… Без PIT таблиц. Несколько подходов, все на основе оконных функций, либо через WITH, либо через join подзапросов. Выглядит немного тяжеловесно (в случае десятков таблиц), но очень единообразно, поэтому в реальности такой код обычно пишут формулы Excel. Размер кода, боюсь, будет слегка великоват для комента, поэтому — в следующей большой публикации :)
Добавил ссылочку на онлайн курс Ларса по Anchor Modeling, http://anchor.teachable.com/courses/enrolled/124660.
Интересно, как решается проблема с производительностью при загрузке новых данных в систему, а конкретно добавление анкоров.

Ведь если для самих атрибутов возможно делать простой append, то анкор нужно перед этим идентифицировать по атрибутам, чтобы принять решение, новая это сущность или нет, что выливается во множественные запросы для выборки, которые на базах данных такого типа обычно довольно медленны.
Для производительности мы материализуем атрибуты, использующиеся для идентификации анкора, вместе с суррогатным ключем анкора, и из этой материализации — расшифровываем, старый ли это анкор, или нужно добавить новый.
Так можно на автора клинуть, и там все мои статьи будут :)…
PS. Скоро будут новые :)… про Anchor Modeling на бессерверных базах.
Да, я уже потом догнал что можно не на блог, а на вас.
Но все таки лучше было бы добавить, потому что на эту статью сейчас много идет трафика после вчерашней публикации, и было бы людям удобней.
Sign up to leave a comment.