Infology.Ru

 Автор: Егор Демьянов

Знойным майским днем (пока не очень привычное словосочетание для Москвы) сидя на прохладной веранде дачи, я решил посмотреть функцию OBI EE под названием Write Back. Функция Write Back позволяет вводить значения прямо в ячейки отчета, при этом в зависимости от введенного значения автоматически обновлять отчеты.
Читать дальше »

Дата публикации оригинала - 2008-05-23

Несколько последних дней я работал совместно с разработчиками заказчика над созданием нестандартных дэшбордов. Основным требованием заказчика было создание prompt’ов в виде чекбоксов. В результате у нас получились такие вот симпатичные дэшборды, как на скриншоте внизу.
Читать дальше »

При создании эффективной аналитической системы, удовлетворяющей нужды десятков или сотен пользователей и имеющей разумные требования к железу, практически не обойтись без такого механизма, как кэширование. В этой заметке я хотел бы поговорить о кэшировании в Oracle BI Suite. В OBI кэширование реализовано в двух компонентах – в BI Server и в BI Presentation Server.

Читать дальше »

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

Существует распространенный миф, что ETL-инструменты самодокументируются. Это верно только в сравнении с самописными системами. Не верьте этому! Всегда нужно проектировать архитектуру ETL-системы. И всегда нужно документировать эту систему. Да, нужно писать документ.

Читать дальше »

ETL-поток начинается с передачи из источника (source system) в хранилище (DHW) свежей порции данных. Почти в любом хранилище требуется передавать только данные, изменившиеся с момента предыдущей загрузки. Полное обновление таблиц фактов (fact) и измерений (dimension) обычно нежелательно.

Вычленение в источнике только новых данных называется «захват изменившахся данных» (changed data capture) и часто сокращается до CDC в архитектурных диаграммах. Идея CDC кажется достаточно простой: передавать данные, которые изменились с момента последней загрузки. Но создать хорошую систему CDC не так просто, как кажется.
Читать дальше »

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

Читать дальше »

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

У других команд противоположные проблемы. Они являются приверженцами тщательной предварительной проработки всех критичных задач. Они нацелены на качество, полноту и согласованность данных. Тем не менее, эти команды часто увязают в вопросах, которые должны были быть решены уже давным-давно. Как правило, это тупиковое положение становится очевидным в самый неподходящий момент: когда сроки уже поджимают, а решения, которые должны быть уже приняты и находиться в стадии реализации, остаются непринятыми.

Читать дальше »

Пользователи часто хотят видеть данные, сгруппированные различным образом. В простейшем случае одно подразделение (к примеру, маркетинговый департамент) имеет свою иерархию клиентов, а другое подразделение (к примеру, отдел продаж) хочет видеть другую иерархию. Если все действительно настолько просто, то имеет смысл включить обе иерархии в измерение «Клиент» и назвать их правильным образом. К сожалению, большее число иерархий, встроенных прямо в измерение, сделает его малопригодным для использования.

Читать дальше »

Достаточно часто мы встречаем несколько десятков различных дат, представляющих важную информацию для бизнеса, и каждая из этих дат должна быть включена в многомерную модель. Например, в финансовой организации мы имеем дело с датой внесения вклада, датой снятия со счета, датой выписки чека, датой обработки чека, датой открытия счета, датой выпуска карты, датой представления продукта, датой начала рекламной кампании, датой рождения клиента, датой начала действия записи, датой загрузки записи, отчетным месяцем и т.д.

В первую очередь необходимо знать, что не все даты создаются и обрабатываются одинаково. В основном даты хранятся в таблицах фактов как внешние ключи на измерение «Дата». Большая часть оставшихся дат становятся атрибутами прочих других измерений. Наконец, некоторые даты добавляются в модель для поддержки ETL или возможностей аудита.

Читать дальше »

При создании хранилищ данных обычно предполагается, что измеряемые процессы (факты) появляется в хранилище тогда же, когда и контекст этих процессов (измерения). Если у нас есть и факты, и актуальные состояния измерений, то мы можем позволить себе некоторую роскошь: сначала вычислить нужные суррогатные ключи измерений, а затем использовать эти актуальные ключи при вставке записей в таблицу фактов.

При обработке измерений существует три варианта действий: Читать дальше »