Игорь Стерхов
О, моя тема :)
В общем, различие oltp/olap это основа, которая за последние 20+ лет особо и не изменилась
Всегда, вне зависимости от BI системы, данные для отчетов всегда стремились денормализовать вплоть до 1й плоской таблицы.
Но сам вопрос шире, и тут нужны годы, чтобы не только понять теорию, но и освоить, набить шишек на практике.
Можете попробовать пройти курсы для подготовки к экзаменам МС по разработке хранилищ данных и моделей данных.
К примеру курсы Специалиста, от Самородова, - для начинающих очень неплохо, мне в свое время понравилось, дается некий фундамент, подход Инмона, Кимбалла, отличие olap и oltp, построение всяких SCD2, паттерны захвата измененных данных и тд
Книжки итальянцев тоже хорошо раскрывают тонкости проектирования ХД и olap, причем старые книжки навроде "Expert Cube Development with SSAS Multidimensional Models" - раскрывают подходы к построению ХД в тч.. хотя новые наверное тоже )
Далее - уже практика и самостоятельное изучение. чтение статей, посещение конференций, вебинаров и тд. Подходов очень много, Кимбалл и Инмон - только основа, кроме них есть подходы гибридные, а есть вообще никак с ними не связанные, к примеру - на 6НФ (anchor modelling), плюс еще делают гибридную OLTP/OLAP базу, когда поверх OLTP базы строятся Nonclustered columnstore indexes для целей аналитики, плюс есть MPP базы для сверхбольших данных. Очень много всего, и это почти никак не структурировано концептуально, тк все очень специфично, структурированы только основы.
Teradata же, это Massive parallel processing БД, для реально больших объемов (десятки, сотни миллиардов и больше строк). На практике я дела с ними не имел, но опыт коллег мониторил. И тут подход в части BI уже другой, тут отказываются от какого либо импорта данных в средство BI или олап кубов ( ну либо только если есть возможность импортировать совсем сверхагрегированные данные), - от всего этого отказываются, а работают с помощью прямого подключения, Direct Query, т.е. БД должна отрабатывать все запросы к данным, фильтрацию, агрегацию - на лету, и понятно, что для этого необходимо специально проектировать хранилище, чтобы запросы максимально и равномерно параллелились между нодами. И соответственно куча заморочек, специфичных именно для MPP СУБД.
