#1 2017-07-24 12:33:32

Nomii5007
Member
Registered: 2017-07-24

Report Server semantic layer

Hello! I cant figure out where is the semantic layer functionality in report server? and how can i use local mysql schema in report server?

Offline

#2 2017-07-25 08:21:50

eduardo
Administrator
Registered: 2016-11-01
Website

Re: Report Server semantic layer

Hello Nomii5007,

what exactly do you mean by "semantic layer functionality"?

For using datasources, e.g. mysql, take a look here: https://reportserver.net/en/guides/admi … a-Sources/
If what you are trying to do is to install reportserver on a mysql database, take a look at the manual installation guide: https://reportserver.net/en/tutorials/i … -practice/ or https://reportserver.net/en/tutorials/i … n-windows/
There, you can use whatever database you need.

Best regards,
Eduardo

Offline

#3 2017-08-02 13:51:07

Nomii5007
Member
Registered: 2017-07-24

Re: Report Server semantic layer

Thanks for your responce
by semantic layer means where we can place our datasource's metadata and apply joins and aggregation on our tables for reporting
mostly every BI tool has that functionality but i couldn't find in reportserver.

Offline

#4 2017-08-03 15:17:21

jalbrecht
Administrator
Registered: 2016-10-21

Re: Report Server semantic layer

Hi Nomii5007,

Reportserver does not support join functionality to end users. The Semantic layer in for Example in Cognos or BW is a description of the semantic relations between underlying data Objects. The semantic Layer generates Queries during execution of reports. This semantic layer is usually stored in a proprietary repository and is maintained manually, i.e. integration of new columns and so forth is done manually.

Reportserver does not support join functionality on the end user side. One of our priorities was provide comparability of report and especially of numbers, meaning that two different users of the same data that approach the same content in different ways can explain the differences between their resp. results.

We decided to use queries as a base for reporting, queries that we wrote ourself. In doing so we ensured that:

a. we take the maximum out of the given RDBMS engine (thus the performace for heavy duty reports is in our hand)
b. we save a lot of maintenance time during changes and achieve a maximum of reusability of a single SQL Query
c. we achieved comparaibility of report result by using the same query for different users (see auto report documentation) and we do not have to explain funny effects of joins to people who never should have thought about it in the first place. If Users need a join i can write it everybody else can use it (and its always the same...)

We considered the ups of this approach a lot more valuable than the downs ...

wbr jan

Offline

Board footer

Powered by FluxBB