Абстракция базы данных в приложении отчетности

Question

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

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

Является ли разумным решение использовать слой веб-сервисов / WCF посередине? Какие еще варианты можно рассмотреть?

Answer 1

Я согласен с предложением NXC по хранилищу данных:

• Если это была разовая работа, то нет, но, поскольку это "приложение для составления отчетов", весьма вероятно, что многие ваши отчеты будут вписываться в парадигму OLAP.
• Это, очевидно, выполнимая задача, так как на рынке доступно множество успешных инструментов запросов OLAP с различной степенью сложности
• Схемы OLAP, например, стандартная звездная схема , предназначены , чтобы их можно было легко запрашивать. Они имеют плоскую природу, при этом таблица фактов соединяется с одной или несколькими таблицами измерений с использованием простых ключей очень простым способом.
• типы операций, которые люди захотят выполнять с отчетами, предсказуемы: фильтровать, сортировать, группировать, добавлять или удалять столбцы, экспортировать в CSV и т. Д.
• вы получите хороший уровень гибкости с генерируемыми отчетами - возможность исследовать данные для различных отношений очень затягивает
• как только вы напишите инструмент запросов, он будет переносим для повторного использования с любой другой звездообразной схемой - неплохо!
• "Можно ли абстрагировать логику отчетности и детали схемы базы данных?" - да, схемы OLAP предназначены именно для этого - они обеспечивают соответствие всех данных стандартизированной схеме. Конечно, это переносит бизнес-логику на уровень ETL, но я бы сказал, что именно к ней и принадлежит.

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

Answer 2

В общем случае было бы трудно сделать все это одним и тем же способом, но вы можете попробовать один из них:

• Построить некоторые представления по схеме базы данных и написать отчеты о противодействии те. Это означает, что вы обладаете некоторой гибкостью в базовой схеме базы данных и можете использовать представления в качестве уровня абстракции.

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

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

WCF - это система сетевой связи. Вы обнаружите, что трудно заставить архитектуру такого типа обрабатывать большие объемы данных по транзакциям в зависимости от транзакции - процесс ETL с пакетной загрузкой будет гораздо более эффективным. Однако, если вам нужен канал в реальном времени (возможно, для системы торговой площадки), вы можете сделать это с помощью чего-то подобного.

Если вам нужен канал с низкой задержкой, другим подходом будет исследование жанра инструментов под названием Интеграция корпоративной информации . Возможно, наиболее широко доступным инструментом, который может это сделать, является Представление источника данных в SSIS , которое дает вам некоторую гибкость при сопоставлении произвольных источников данных с согласованной схемой. Он не такой сложный, как лучшие в своем роде инструменты EII, но вы можете поместить поверх него пакеты служб SSIS и использовать их в качестве источника данных для своих отчетов, если вам потребуется дальнейшее преобразование данных.

Тем не менее, я никогда не создавал систему, подобную этой, поэтому я не могу подтвердить, насколько хорошо она работает на практике. Я предполагаю, что это будет довольно хрупким и трудным разбить на части, которые могут быть проверены модулем, поэтому разработка и обслуживание будет довольно трудоемким для системы нетривиальной сложности.

Если вы хотите исследовать другие системы EII на рынке Эта ссылка - это каталог различных статей о EII и некоторых других поставщиках инструментов EII.

Answer 3

Ответ, который я думаю, как правило, вернется, чтобы кусать вас в тылу, но, как я знаю других, состоит в том, чтобы производить данные в виде XML из каждой базы данных. Это дает вам согласованный набор данных в форме, с которой легко справится большинство продуктов.

Если вы сделаете это, убедитесь, что запросы XPath, которые вы будете выполнять, будут быстрыми.