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

Question

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

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

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

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

Итак, вам необходимо выполнить ETL с таким подходом - одним из вариантов является выполнение некоторой формы РОЛАП, но на практике я обнаружил, что писать ETL-скрипты так же легко, как добиваться хорошей производительности при настройке ROLAP.

Answer 3

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

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