Судя по названию, должна быть вторая (третья...) часть, так что IMHO имеет смысл прочитать текст полностью.
Если же рассматривать только эту часть, то у меня она вызвала, мягко говоря, неоднозначную реакцию - при рассмотрении под таким углом прямой транзакционный VSAM будет выглядеть гораздо привлекательнее и DB2, и IMS, а BDAM так и вообще будет вне конкуренции)

в принципе, верно, потому во второй части будет про языки доступа к данным. Можно, кстати, и VSAM добавить, и посмотреть, зачем вообще нужна СУБД, может и без неё можно. Что такого даёт СУБД удобного, чего нету при использовании VSAM.

это ты насчет VSAM и использования СУБД может и перегибаешь палку. те, кто знают, что такое VSAM, и так знают, чем он хорош и чем плох. а те, кто не знают, все равно не поймут - для них СУБД это одно, а метод доступа - вообще другое, почти разные Вселенные.
однако пиши, я отслеживаю.

Ну для начала надо таки уточнить, что Gregory писал про transactional VSAM, и это делает некоторую разницу.
Но вот в чём ты прав - разницу делает для тех, кто понимает.
А теперь по поводу твоего опасения.
Поскольку я не вы, и не родился в мейнфрейме, а прошёл долгий путь, начиная от freebsd 2.2.1, и много чего пользовал,
то имею дурацкую привычку сравнивать.
Вот и для VSAM у меня есть сравнение.
И речь небыло за "хорош" или "плох".
Так нельзя.
В одном случае он будет очень хорош, а в другом очень плох - это влияют нефункциональные требования больше всего.
И расстановка приоритетов в требованиях.
Я просто хотел сказать, что индустрия не удовлетворилась VSAM-ом единым, а почему-то появились IMS, ADABAS, IDMC, и так далее, вплоть до DB2 (прости оссссспади )
А значит, раз сделали эту надстройку - СУБД - то наверное, был смысл. Что-то это даёт полезного.
И вот про это можно поговорить.
В первой части статьи автор явно пытался сравнивать у обоих СУБД примерно одинаковые по функицоналу, по назначению, вещи.
При использовании transactional VSAM, отдельно ли (что вряд ли), или с монитором транзакций (что вероятнее, и скорее всего CICS), многих этих вещей не будет out of box, придётся делать их самим. Этим и отличаются СУБД от того, что было до-СУБД.
Ещё раз - это не хорошо, и не плохо, это имеет свои особенности и области применения, и всё.
Вопрос правильный, важный, и почему бы кратенько не рассмотреть связочку "монитор транзакций плюс transactional VSAM"
Не вижу препятствий.
Ну, важный вопрос кому... Тому, кому интересно
Мы же just for fun
А не из под палки
Я правильно поясняю?

IMHO при сравнении имело бы смысл начать с обсуждения представления данных предметной области в рассматриваемых моделях управления данными, а затем уже рассматривать возможности управления данными каждой модели...

Ща мы потихоньку раскатаем Гришу Власова на полноценную монографию)))

Не, мне эта тема не нравится
Предметная область заявлена там.
Смоделировать данные можно по-разному.
И для
- VSAM
- IMS
- DB2
модели будут разные
Какая модель подходит лучше?
А по каким параметрам будем сравнивать?
А какие критерии оценки параметров будем применять?
Так что это направление ушло в отдельный документ

Методика выбора программно-аппаратной
платформы для финансово-учётных систем

Аннотация
Данный материал посвящен обсуждению проблемы выбора
программно-аппаратной платформы для транзакционных систем,
обеспечивающих перевод денежных средств между пользователя-
ми. К ним относятся финансово-учётные системы предприятия,
платежные системы международных и национальных масштабов,
биллинговые системы. Рассмотрены основные критерии выбора и
подход к их оценке: эффективность, сопровождаемость, достовер-
ность и своевременность возвращаемой информации. В статье да-
ется объяснение технологических причин, по которым платформы,
которые частно относят к разряду унаследованных, продолжают
эксплуатироваться по сей день.

Вот там и будет немного про модели данных.
А вот вам заключение ИПИ РАН - для платёжных систем применение реляционных баз не только не нужно, но и вредно.
Это я по памяти своими словами.

И вообще, я бы не рассматривал модели данных отдельно, сами по себе.
Бесполезно это.
Вне отрыва от конкретных задач - бесполезно.
Есть конкретная система, биллинг, приём массы поступающих событий, расчёт, и списывание денег со счета ну или выдачи ответа в аппаратуру о параметрах допустимой сессии.
Или - платёжная система, перевод средств между участниками.
Предполагаемый срок эксплуатации - лет 30. Лучше больше

И не важно, какая модель.
Важны качества получаемой системы.
Какие качества?
Вот и предлагается взять
- Достоверность и своевременность финансовой информации
- Сопровождаемость и эффективность самой системы.

Будут пожелания по рассматриваемым параметрам (качествам) - хорошо.

И ещё такой момент в плане время ожидания ответа.
Надеюсь, понятно, что ответ не обязательно "исполнен", это может быть и "постановка в очередь на исполнение за недостатком средств", и много чего ещё, например, если методо расчётов на основе многостороннего взаимозачёта, то просто что-то типа "принят для расчёта", а будет исполнен или нет в ближайшем сеансе многостороннего взаимозачёта - пока неизвестно.
То есть просто - ответ должен быть в гарантированный промежуток времени.
Может, автор платежа сможет предпринять какие-то действия, по пополнению ликвидности, или выберет другую площадку для платежа, короче - не будет томится в неизвестности.

OLTP и данные за несколько недель?
Честное слово - первый раз такое встречаю.
Вопрос объёма данных - не проблема для ОЛТП системы.
Даже если эти данные определить как ненужные - они не мешают работе системы.
Если она не на реляционке
Если мы предполагаем хранение года данных для тысячи участников платежей, то это и будет ключевыми параметрами для физического дизайна системы - по одной "записи" (в терминах IMS) на каждый опер день на участника. Обращение к одной любой записи константно по времени. Не вижу препятствий. Так же время константно будет для обработки массива "записей" за месяц, квартал, полугодие, год - количество "записей" за каждый промежуток времени константно, как и время обращения к ним.
Ну и, собственно, сама OLAP возникла немножко так по-позже электронных платёжных систем, на сколько, на два десятилетия? Или на полтора?
В принципе, для анализа данных не нужен OLAP, но OLAP может сократить время анализа.
Прямой зависимости типа "платёжная система не может существовать без аналитики" нету.
Это и вы подтверждаете фразой
Могут оказать, а могут и не оказать.
Можно иметь аналитику, а можно и не иметь.
Да, без ОЛАП анализ данных потребует уже отдела статистики из ряда сотрудников, пожалуй.
Но платёжной системе немного фиолетово - она сможет продолжить свою работу и выполнять свои функции безотносительно аналитики.
А если это монопольная, навязанная платёжная система.... То вообще по-барабану

Пы. Сы. Хотелосбь бы заметить, что между "историческими данными" и данными для OLAP есть большая разница. Исторические данные сырые, и попытки их переваривать вызовут несварение как у средств обработки данных, так и у потребителя)

Ок, тогда платёжная система Банка России - похожа на деревенский базар
Несколько недель - это мало.
Тысяча участников платежей - это пример, подставляйте другую переменную.
Роли особой не играет.
Наличие или отсутсвие прибыли не имеет прямой связи с внедрением OLAP.
Кроме того, что финансовая организация не благотворительная, но учредители платёжной системы могут не стмавить целью извлечение прибыли, а стоимость услуг всего лишь для покрытия затрат, справедливо как для Банка России, так и для Европеского ЦБ.
Что не отменяет факта наличия коммерческих платёжных систем.
Доказывает отсутсвие прямой  и жёсткой связи между наличием платёжной системы и наличием OLAP.
Ну нету такой связи

Пусть будет пример 100000 участников на один год (365 операционных дней).
Могу грубо подсчитать количество дисковых данных.
Не так уж и много будет, поверьте.

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

а наличие OLTP системы и степень ее навороченности имеет "прямую и жесткую связь" с наличием или отсутствием прибыли?

Не я отталкиваюсь.
Просто платёжные системы очень разные, под разные условия и разного назначения - межбанковские, или розничные.
Я просто хочу донести простую мысль - нет никакой жёсткой необходимости иметь ОЛАП для функционирования платёжной системы.

Нет, связь скорее косвенная, чем прямая, и очень сильно будет зависеть от того, что именно за платёжная система.
Но степень навороченности безусловно будет иметь жёсткую связь с нефункциональными требованиями, с качественными характеристиками платёжной системы.
Навороченность OLTP может способствовать получению прибыли от платёжной системы.
За счёт снижения издержек разного рода - на лицензионные отчисления, на сопровождение системы,
за счёт предоставления более качественного (нефункциональные характеристики) сервиса, что сделает систему более конкурентно-способной и подтолкнёт пользователя её выбрать (если выбор вообще возможен).
Вполне возможно, что начиная проект Union Pay китайское правительство во главу угла ставило вовсе не прибыль. А например, независимость, диверсификацию, и лучшие условия для переговоров с Visa и MasterCard.
А европейские банки создавая платёжную систему ЕЦБ и вовсе ориентировались не на прибыль.
Перейдём к России?
Нам что более актуально, срубить бабла по-быстрому получить прибыль, или получить безопасность, независимость, устойчивость финансовой системы и хорошие условия для переговоров с международными системами?
В этом вопросе может быть множество аспектов.
Но всё это не имеет отношение к ОЛАП.
Есть экономисты.
Есть дисциплина АХД (Анализ Хозяйственной Деятельности).
Есть перечень входных документов для АХД.
Для этого вовсе не обязательно иметь ОЛАП.
Полезно - да.
Обязательно - сомневаюсь.

про "онолитегу".

Тут с какой стороны подходить.

По количеству гемора -- 90% от сложности системы.

По количеству персонала -- базовый состав (только аналитика) + оперативный состав (процентов 20-25% заданий можно отнести к сфере аналитики). всего 38% персонала занимаются поддержкой разного рода "не основных" данных.

Под "основными" подразумеваю то, что относится непосредственно к ОЛТП части.

Все делается на инструментарии, который предоставляет СУБД + часть данных выгружается в 1С и часть обработки происходит там.

По размеру данных -- практически 100% от всех хранящихся данных

Может если есть какие-то конкретные вопросы -- могу ответить ))