Архитектура данных для решения отчетности в.NET

Question

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

Очевидный следующий шаг (по крайней мере, на мой взгляд) - передать создание отчетов в руки бизнес-пользователя. Это может быть что-то вроде Crystal Reports, SQL Server Reporting Services или инструменты BI, такие как Tableau. Не имея большого опыта работы со многими из этих инструментов, я в растерянности. Более того, я борюсь с проблемой сложных таблиц базы данных и верю, что сообщество пользователей может понять сложные взаимосвязи таблиц в дополнение к открытию нашей схемы со всеми ее вычислительными полями только для базы данных, которые пользователь никогда не должен видеть,

Я считаю, что у меня есть несколько вариантов здесь (с точки зрения архитектуры данных и с точки зрения направления в целом), и они включают в себя:

1. Упрощение схемы для бизнес-пользователя через API или более упрощенное "представление" таблиц базы данных - что лучше для бизнес-пользователя, но требует предварительной работы и обслуживания.
2. Предоставление бизнес-пользователю возможности видеть все таблицы - что, очевидно, облегчает обслуживание, но требует документации, обучения, объяснений и т. Д.
3. Другие варианты BI (с которыми я, честно говоря, не знаком) - куб OLAP и т. Д.

Мне нужны отзывы об опыте в этой области и предлагаемые направления с точки зрения архитектуры данных и / или использования продукта.

Answer 1

Решение, о котором вы думали, является сложным.

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

2-й шаг - предложить пользователям что-то вроде селектора. Это было бы очень сложной задачей, так как вы должны были бы позволить пользователям выбирать, какие бизнес-объекты им следует использовать? как они хотят объединить данные из разных объектов, соединяя их каким-либо образом? какие данные они хотели бы видеть в отчетах? они могут захотеть применить некоторые функции, такие как Sum, Avg, Min, Max и т. д. перед отображением, и иногда они могут захотеть сгруппировать поля. иногда требуется сортировка по разным полям, а иногда ваши пользователи могут захотеть указать критерии. поэтому ваше приложение должно каким-то образом разрешать это.

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

Изначально, просто для демонстрации, спроектируйте несколько простых и небольших бизнес-объектов. 2 или 3 объекта с не более чем 7-8 свойствами будут в порядке. В настоящее время никакие функции не должны быть доступны, они только усложнят реализацию для вас / вашей команды. Пользователи на этом этапе должны иметь возможность определять простые критерии и порядок сортировки не более того, и они имеют предопределенный формат отчета, который можно отобразить. Если идея увенчалась успехом, и вашему клиенту она понравилась, вы можете стремиться распространить ее на свои более 100 таблиц, сложные функции и условия критериев.

Answer 2

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

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

После того, как вы решите проблему с разработкой отчетов, вам нужно найти способ запуска отчетов. Вам нужен универсальный движок, который сможет добавлять и запускать внешние отчеты. Полагаю, вам нужно будет разработать новый модуль или приложение, которое будет анализировать отчеты, подготавливать экран параметров и запускать их. Службы отчетов будут хорошим выбором, потому что вы можете установить и настроить сервер, и все готово. Это бесплатно, если у них есть лицензия SQLServer. Если вы решите использовать Crystal Reports - сервер Crystal Reports будет делать то же самое, но это слишком дорого, поэтому я предполагаю, что это будет вариант, только если у вашего клиента уже есть лицензия. Если приложение представляет собой приложение для внутренней сети, вы можете попробовать некоторые из сторонних зрителей. Они довольно дешевые. Я считаю, что 1000 долларов хватит на покупку лицензий на 100 пользователей. С хорошим списком сторонних наблюдателей Crystal Reports можно ознакомиться по этой ссылке: http://kenhamady.com/cru/comparisons/crystal-reports-viewers

Я использовал несколько из них, и я бы посоветовал вам проверить R-Tag ( http://www.r-tag.com/) - он работает как с отчетами Crystal, так и с SSRS и поддерживает установку в интрасети. Jeff-net ( http://www.jeff-net.com/jnrrv.htm) тоже подойдет (для отчетов Crystal). Вы можете попробовать другие - есть некоторые бесплатные, но сначала протестируйте их с небольшим количеством пользователей, потому что обслуживание в сетевой среде может быть дорогим.

Answer 3

Честно говоря, главной проблемой для вас будет то, на что похожа ваша архитектура интерфейса? Клиент как с WPF или Windows Forms или ASP.NET или HTML? Это действительно имеет огромное значение, так как я, например, поражен разнообразием инструментов отчетности, построенных вокруг Jquery и Javascript, таких как "HighCharts", "FusionCharts", "DevExpress" (часть более крупного дополнения) в том, что они могут сделать по сравнению с более традиционными SSRS и Crystal Reports. Веб-отчеты превосходят возможности клиентских отчетов в таких областях, как управляемые событиями отчеты, многоуровневая отчетность или срезы

Честно говоря, если бы это был выбор между Crystal и SSRS, я бы выбрал SSRS, поскольку я, как разработчик, считаю, что SSRS проще использовать его части. Как правило, SSRS состоит из трех частей:

1. Соединение (я) с базой данных, плоским файлом или службой (или другими контейнерами данных тоже). Можно поделиться для повторного использования.
2. Набор (ы) данных, представляющий данные для доступа. Можно поделиться для повторного использования.
3. Набор объектов, которые могут быть таблицами, матрицами или графическими диаграммами.

Основным преимуществом SSRS является то, что вы можете быстро освоить основы построения отчетов и публиковать отчеты, а также иметь встроенный сервис, который позволяет включать подписки по электронной почте (при условии, что у вас есть работающий SMTP-сервер), сохранять файлы в подписках, кэшировать наборы данных и получать доступ к отчеты через.NET с непосредственным общением со службой, чтобы заставить службу предоставлять отчеты по запросу о событиях в приложении.

Несмотря на то, что SSRS имеет некоторые ограничения, сервис можно использовать через форму HTML, доступ.NET или оставшийся URI, что делает его достаточно гибким.

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