Почему структура транзакционной базы не подходит для аналитики?

Структура БД здесь является лишь выражением назначения БД (я даже не уверен, что правильно говорить именно о структуре БД в обсуждаемом аспекте, так как не подходит в первую очередь сама транзакционная БД). Так как транзакционная БД предназначена для непрерывной обработки транзакций (каких-нибудь заказов, например) - совершения операций без использования исторических данных, то для повышения эффективности исторические данные будут удалены, или, в лучшем случае, архивированы. А хорошая аналитика предполагает работу с историческими данными для выявления взаимосвязей и т.д. Формально говоря можно, конечно, иметь аналитику "в моменте" для каких-то операционых текущих задач, тогда и транзакционная база подойдёт, но всё же это очень ограниченное использование.

Для нормальной аналитики используют реляционные БД с информацией за прошедшие периоды.

Транзакционные БД следуют определённым парадигмам. Надёжность, непротиворечивость данных и т.д. Для выполнения этих требований БД нормализуется - избавляется от избыточности. Есть отдельные "справочники" для сущностей, где каждой сущности соответствует свой id, по которому на эту сущность могут ссылаться другие сущности из других таблиц. Поэтому для того, чтобы собрать все данные по какой-то сущности обычно нужно соединять вместе несколько таблиц, это отнимает определённые ресурсы. Зато если нужно обновить какую-то сущность (например, списать деньги со счета в банке), то не нужно затрагивать лишние данные, это можно сделать быстро и надёжно.

У БД для анализа данных совсем другие требования. Обычно это "кубы" OLAP, в них данные денормализованы. Все нужные для анализа данные там уже расположены вместе, ничего не нужно соединять, наоборот, всё что нужно доступно сразу, просто нужно выкинуть лишнее, сгруппировать, отсортировать. Для хранения данных такой формат сильно избыточен по месту хранения и сложен для обновления данных. Но зато анализ данных в таких БД делается быстро и просто.