Имхо, аналитик (постановщик задач) ни с какими БД не работает.
Он решает проблемы по автоматизации некой деятельности.
Например, ему нужен некий аналитический отчет.
Со своим предложением он обращается к администратору БД.
Возможны следующие ответы на его просьбу:
1 в БД нет необходимых данных для нужного отчета. Задача не выполнима;
2 в БД есть необходимые данные, но сложность отчета не позволяет сформировать его только SQL-запросами. Необходимы дополнительные инструментальные средства (например, процедурный язык);
3 в БД есть необходимые данные и отчет может быть сформирован с помощью SQL-запросов, но для его оптимального выполнения необходимо изменить частично схему БД (например, создать некие представления или временные рабочие таблицы);
4 в БД есть необходимые данные и отчет можно сформировать с помощью SQL-запроса. Такой SQL-запрос ему предоставляется

Я исходил из своего понимания функции аналитика информационных систем, а именно:

Системный аналитик в ИТ-сфере чаще всего занимается задачами автоматизации процессов. ... Основные задачи системного аналитика — анализ бизнес-процессов с точки зрения их последующей автоматизации, разработка технических заданий и спецификаций, тестирование программного обеспечения, составление аналитических отчетов.

Да, у нас есть люди, которые прекрасно разбираются во всех банковских операциях, но мало понимают в SQL,
и есть те, которые прекрасно владеют языком SQL, но мало чего смыслят в банковском деле.
И их обязанности не пересекаются.

Расширяйте свой кругозор, не ограничивайтесь только своим личным опытом.
И зачем, скажите, программисту вникать в тонкости банковского дела (завтра он может уйти совсем в другую сферу деятельности),
а аналитику - в конструкции SQL.
Пусть каждый совершенствуется в своем деле.

Охотно верю, что "вникающих" программистов - полно.
Особенно когда в реальности наблюдаю цифровизацию - чем больше в каком-то процессе обслуживания компьютеров, тем длиннее очереди. Потому что программисты любят в первую очередь и главным образом себя, а не клиентов.

Удивительна логика!
Мир уже сотни лет отказался от натурального хозяйства и перешел к разделению труда.
Банкиру нужно знать только как пользоваться компьютером, а не как работает ОС или СУБД.
Аналогично, водитель авто не обязан знать, как разобрать и отремонтировать двигатель, а больному надо обратиться к узкому специалисту-врачу, а не самостоятельно лечиться по книгам.

Создавать выборки по запросам аналитиков программистами - мне кажется, плохой вариант в системе без DWH.
Так думает большинство руководителей и ищут специалиста квалификации типа AnуKey (в переводе на русский ”и швец, и жнец, и на дуде игрец”), поэтому в вакансиях выдвигают соответствующие требования типа “Требуется уборщица, способная после своих действий восстановить работоспособность UNIX-систем” .
Что имеем?
Использование всяких OLAP-решений не предполагается.
Создавать выборки по запросам аналитиков программистами – не устраивает, т.к. Аналитики навыбирают сами себе что хотят и не тратят время программистов. А тут придется им на взаимодействие человека выделять.
Остается научить бизнес-аналитиков самих добывать нужные данные.
И они это делают, но
строят свои хитрые запросы. Запросы эти настолько хитрые, насколько и неоптимизированные. После этого пишут разработчикам, что, мол "запрос долго работает, почему?"
В этой ситуации вариант один – научить бизнес-аналитиков еще одной профессии.
Если речь идет о реляционной БД, то это освоить язык баз данных SQL.
Документ “Стандарт SQL” - толстенный талмуд объемом более 1000 страниц. По нему трудно изучить SQL (да и документ не предназначен для этого) – он нужен только программистам, разрабатывающим трансляторы с SQL и реализующих обработку SQL-запросов. Для остальных есть пособия типа “Понимание SQL” или “SQL для ржавых чайников”.
Допустим, бизнес-аналитик освоил азы SQL
Но SQL-запросы для анализа данных
как известно апросы эти настолько хитрые, насколько и неоптимизированные.. Потому что для качественного написания нужна большая практика и не на тестовой (учебной) БД, а на копии рабочей БД.
Да, состряпанные запросы, как правило, неоптимизированные, но транслируются и даже выполняются (правда, иногда часами). На предложение выполнять их в глухое ночное время (когда СУБД не загружена обслуживанием других пользователей) руководство реагирует с кислой рожей.
Да, изучив план выполнения запроса, можно его немного оптимизировать.
Но это не всегда помогает - и тогда в ход должны идти силы “тяжелой артиллерии”, а именно использование всех возможностей и ухищрений, предоставляемых самой СУБД: предопределенные выборки, материализуемые представления, таблицы “в памяти”, временные рабочие накопительные таблицы, секционирование таблиц, кэшируемые запросы (запросы, результат которых СУБД сохраняет у себя и при повторных обращениях к ним результат, в большинстве случае, выдает мгновенно), подсказки (hint) СУБД по выполнению запроса, конфигурирование параметров СУБД под специфику выполняемых запросов и т. п.
Это уже другой уровень квалификации.
Если учесть, что в компьютерных фирмах и ЦОД (центрах обработки данных) нет давки в дверях от толп высокопрофессиональных SQL-программистов и знатоков архитектуры СУБД (их еще поискать), то найти бизнес-аналитика, способного квалифицированно извлекать нужные для анализа данные еще труднее.
Придется потратить время и деньги на его обучение.

После того как бизнес-аналитик получит вторую профессию (станет высококвалифицированным SQL-программистом и администратором СУБД), он найдет себе другое, более привлекательное, по сравнению с вашим, место применения своих способностей.