Publishing a DSF View will create a database View in the target database that matches the fields selected in the preview panel. Publishing a View is how you connect other third-party visualization/reporting tools to your database. As an example, step by step instructions on how to connect to Excel can be found here.
Any View created in DSF can be published to the physical database if the user has the database permissions to do so. If the current user does not have the database permissions, DSF will prompt for the elevated permissions before continuing. Users will always have permission to publish to a DSF Database.
Performance should be a consideration if utilizing the Data Selections Cloud Server. Depending on many variables beyond the scope of this document, accessing your physical data from our server may be slow. Creating a local DSF database on your own server is always a better option, if possible.
Which database you choose to publish to depends on the needs and policies of your organization's IT department.
DSF Views will need to be published if you expect to use them in any other tool.
A published DSF View creates a database View in the database Schema with the prefix entry as assigned to the user in the Members Manager.
When using a DSF cloud server with the demo data you will not be able to publish a view to our physical database.
Abstraction Layer
After DSF Views are publish the database View can be used as the data source to other third-party visualization/reporting tools. The third-party tools only know the data fields by the alias names provided by the database View as publish by DSF, not the low-level database table field names in the SQL Query. Having DSF as the abstract layer to your other reporting tools removes the need to modify your reports when things change in the database. Changes can be made in DSF and views are simply re-published. No changes in the actual reports are needed.
Example:
Let’s say there is a DSF View named “Employee List” which includes a field called PersonGender. The PersonGender field currently returns the value “M” or “F” and is derived from the low-level database location HumanResources.Employee.Gender AS PersonGender
As far as all your reports know, the field name is PersonGender. Your third-party tools use the alias name PersonGender from the data source (the published view) to link the data column to their system. You could have hundreds of reports pulling data from the same data source. If you wanted the reports to now display the full gender “Male” and “Female” value instead of “M” and “F”, just modify the DSF View and re-publish.
Even though the DSF View was changed to source the data from a new User Defined Field that you created which transforms the data, the publish View alias is still PersonGender. All reports now display the new value with no changes to the report.
This was a simple example of transforming data, a more complex scenario would be if HumanResources.Employee.Gender was no longer available or moved to a totally different table by a software vendor. This could happen if you upgraded to a new version of their system or for numerous other reasons.
What would happen if that database field was used in hundreds of different database Views or in hundreds of different reports and dashboards throughout your organization? What if the Vendor drastically changed their data model between versions and moved many fields in the system?
With DSF there are multiple ways to manage this. If the vendor totally changed their data model you can re-discover their entire database and then create matching DSF Views for your reports and re-publish. DSF will source the data from the new database locations but publish the alias names the same so that all third-party reports will just continue to work as usual.
The other option is to manually make the changes in the DSF mappings. Since DSF utilizes a building block system once the change is made, it works for ALL views in DSF. re-publishing the views will then fix all third-party tools.
These are just a few of the benefits enjoyed when using DSF as the abstract layer between your visualization/reporting tools and your database layer.
Because of the way DSF can handle change we say that DSF is version agnostic.
To DSF DB
Anybody can publish their views to the DSF database. However, there still may be special considerations needed to get your visualization/reporting tool to work with it. This should be discussed and setup during the implementation phase of DSF.
This option must be used when merging more than one physical database onto a single view or when publishing a view to the physical database is not an option. This can happen when using a Linked Server to access your data through Microsoft SQL Server.
To Cloud Server
Anybody can publish their views to the DSF cloud database. However, performance should be a consideration if utilizing the Data Selections Cloud Server. Depending on many variables beyond the scope of this document, accessing your physical data from our server may be slow. Creating a local DSF database on your own server is always a better option, if possible.
To Physical DB
Publishing the View to your physical database is the best option if allowed.
Most users' visualization/reporting tools will point their data source to the physical database. Your DBA may manage database views for reporting separately for security reasons. Speak to your DBA before publishing views to your physical database. You may need elevated database permissions to do so.
View Publish Options
Publish options are setup in the Members Manager per user. In an Enterprise Setup, the DBA may want to organize the publishing of database views by users into a specific Schema in the database (DSF_VIEWS). If a more detailed breakdown is required, they can separate the users into individual Schemas (i.e. BOBs_Views). Using Schemas and setting View Create permissions in a database is beyond the scope of this document.
Schema Name
When publishing, the view will be created in this Schema for the user.
Prefix
If publishing to a common Schema (DSF_VIEWS) the prefix will separate the view names by user or group within the Schema.
Schema Binding
Only enable schema binding if you know what it is used for and need it for your organization.
When a view is created in MSSQL the Schema binding option prevents any base tables from being modified in a way that would affect the view definition. The view definition would need to be deleted to remove the dependencies on the table to be modified. Most of the time this option is more trouble than it’s worth and is only included for those who need it.