#oracle #obiee
#Oracle #obiee
Вопрос:
У меня есть анализ, который использует фильтр для ограничения результатов.
Я помещаю этот анализ в панель мониторинга вместе с приглашением панели мониторинга.
Приглашение панели мониторинга состоит из различных столбцов, и все они имеют тип «Список выбора», и у всех есть опция «Ограничить значения по» = «Все запросы».
Однако это работает не так, как я ожидал. Я думал, что значения, отображаемые в списке выбора, должны быть ограничены фильтрами, применяемыми при анализе, но, похоже, что приглашение панели мониторинга сначала показывает все возможные значения перед применением фильтра анализа.
Правильно ли это?
Если это так, как это работает, проблема, с которой я сталкиваюсь, заключается в том, что некоторые значения, отображаемые в списке выбора столбцов запроса, приведут к ОТСУТСТВИЮ ДАННЫХ в анализе.
Спасибо за вашу помощь!
Ответ №1:
«Я думал, что значения, отображаемые в списке выбора, должны быть ограничены фильтрами, применяемыми при анализе»
В точности наоборот. Запросы отправляют выбранные значения в фильтр, который находится в анализе, и, следовательно, отключают поток данных.
Обычно приглашение извлекает значения выбора, для которых определенная точка зрения не извлекает данных. Другой способ не имеет смысла. Представьте, что вы продаете 5 продуктов, а один вообще не продавался в августе. Вы хотите удалить август из запроса месяца?
Например, упомянутая вами взаимозависимость запросов — ограничить регионы только регионами выбранной страны. Ограничьте количество клиентов только клиентами выбранной бизнес-единицы и т. Д.
То, что вы пишете и ожидаете, — это то, что приглашение должно проходить по действующим данным (фактам) и извлекать только значения, для которых существуют данные (факты). Как было сказано выше, это не самая логичная вещь, которую можно сделать в аналитической среде, поскольку одно изменение точки зрения может означать, что данные «существуют» или «не существуют» — тогда вы меняете точку зрения, и ситуация меняется. И вы этого хотите. Вы не хотите жестко кодировать точки зрения, которые со временем или когда кто-то другой просматривает данные (персонализированная защита данных), они получат разные результаты.
Не вводите слишком много жесткого кода. Не ограничивайте систему искусственно.
Обновление: https://imgur.com/BxGnbbB Вот скриншот, на котором вы можете ограничить приглашение
Комментарии:
1. Спасибо, Крис! Но представьте, что из 5 продуктов, которые я продаю, у меня есть фильтр в моем анализе, чтобы учитывать только те, которые были проданы в первой половине года. Когда я запускаю этот анализ на панели мониторинга, я хочу, чтобы запрос за месяц показывал только с января по июнь, потому что, если у пользователя есть возможность выбрать август, это не даст НИКАКИХ ДАННЫХ, и это сбивает пользователя с толку. Я много лет работал с Oracle Discoverer, и это работает таким образом. Какой смысл предлагать выбор, для которого данные не будут доступны? Пользователь должен угадать, для какого варианта он получит результаты?
2. Конечно, вы всегда можете заставить фильтры проверять ваши таблицы фактов. Как только вы выбираете, например, продукт, а затем дополнительно ограничиваете его несвязанным измерением, таким как география, тогда ограничение распространяется на факт и извлекает только то, что действительно содержит данные. Да, Disco работал по-другому, но OBI содержит анализы и подсказки как абсолютно независимые и повторно используемые объекты. Подумайте о LEGO для взрослых. Соедините их вместе любым удобным для вас способом. Если вы принудительно привязываете свое приглашение к ОДНОМУ конкретному анализу и, следовательно, набору данных, оно становится непригодным для любого другого использования. Это означает больше одноразовых действий
3. одноразовые объекты в каталоге, которые необходимо управлять и поддерживать. Теперь представьте, что в исходном коде происходит изменение, и вам нужно адаптировать все объекты, построенные на этом. Изменить 5 объектов на повторно используемые объекты? Или изменить 500 одноразовых?
4. Предлагая варианты там, где нет данных …. ну … откуда вам знать? Вы можете узнать, только если вы ограничиваете и сокращаете набор данных до практически статического, неизменяемого. Что насчет завтра? Что делать, если есть новый продукт? Что делать, если вы повторно назначаете продукт другому торговому представителю, и у них применяется видимость личных данных? Что, если в модель будут добавлены дополнительные данные?
5. Большое спасибо за ваши полезные комментарии. Вы правы, я полагаю, мне нужно привыкнуть к новому образу мышления. Однако я попробую использовать другой пример: представьте, что запрос столбца содержит не месяцы (которые на самом деле имеют только 12 разных значений), а, например, имя службы или любой другой столбец с множеством разных значений. Когда пользователю нужно выбрать значение из списка выбора приглашения, это будет процесс проб и ошибок, пока он не выберет службу, для которой отображаются некоторые данные.