Я провожу некоторые исследования о том, в каком наилучшем из возможных состояний должны быть данные, чтобы отчеты и аналитика BI работали хорошо, но бизнес-пользователи могли их создавать из набора различных наборов данных, которые соответствуют глоссарию бизнес-данных, который я
- Мы не выбрали конкретный инструмент c BI, но работали с Power BI и Sisense
- Мы не определились с технологией хранилища данных, чтобы используйте для отчетности
Исходные данные
Наше бизнес-приложение, из которого будут поступать данные, имеет нормализованную SQL реляционную базу данных. Существует довольно много таблиц и объединений, чтобы рассмотреть, какие из них работают нормально с точки зрения приложения, но я рекомендовал предоставлять выходные данные этих запросов в виде плоского денормализованного набора данных для увеличения избыточности и полного удаления объединений.
Глоссарий бизнес-данных
По мере того, как мы go определяем глоссарий бизнес-данных, количество столбцов увеличивается, но я не ожидаю, что в качестве полного набора отчетов будет более 100 столбцов на строку. данных. Я хотел убедиться, что каждая строка данных находится на глубине транзакции (уровень 0) и что свертывание данных будет выполняться путем агрегирования по различным значениям ключа и размерной таксономии.
Архитектура
Я хочу получить несколько советов о том, как выглядит современная архитектура и что работает для бизнес-пользователей, а не для пользователей, которым удобны запросы SQL и множество объединений в физической модели данных.
Я прочитал статью о настройке потоков данных для Power BI, которая выглядела так, как будто они хотят заниматься с точки зрения доступности данных, но не дает советов о том, как хранить данные и какую базу данных использовать. использовать.
Наборы данных
Данные, по которым мы должны предоставить отчеты, - это транзакции, где уровень 0 - это торговые позиции (отдельные транзакции от местного или контрагента) ), уровень 1 - сверки (связанные с местными и контрагентскими организациями и торговыми связями идентификатор) и уровень 2 будут там, где его можно свернуть с помощью таксономии, такой как тип актива или статус.
Текущий размер набора данных будет представлять собой снимок позиций каждый рабочий день, поэтому он дублируется каждый день со снимком дата применяется. Отчеты будут иметь возможность перемещаться по датам и отображать изменения во времени.
Буду очень признателен за любой совет о том, как решать вопросы отчетности и бизнес-аналитики в 2020 году. О-о-о, наконец, есть вероятность, что мы выиграли Нам не разрешено обрабатывать данные такого типа в облаке publi c, у нас есть собственная инфраструктура, которая находится в частном облаке, поэтому, возможно, потребуется рассмотреть это. Спасибо