Data Sources are the fundamental first step in the Zoola™ Workflow. Data Sources are customized connections to your data source that provide access to specified data instead of the entire data source.
LMS data sources can contain an overwhelmingly large amount of information—a Data Source functions as a way to filter out unnecessary data right from the source. Ad Hoc Views are based on Data Sources, and the creation of a View is entirely dependent on the fields and measures selected from the specified Data Source.
Lambda Zoola™ includes many pre-built Data Sources in the Public folder of the Repository. You can also use the Data Source Designer to create custom Data Sources, or to copy and configure an existing Data Source to suit your reporting and analytics needs.
Data Sources can be further separated into Data Sources and Data Source Topics. Typically, you base the decision to use Data Sources or Data Source Topics on the complexity of the data needed for your business needs. You can also opt to use saved Reports and templates, if necessary.
The following use-cases present two scenarios in which a Data Source or Data Source Topic is preferable to a saved report:
Case A | Case B |
|---|---|
Data Sources and Data Source Topics can be designed to give users great freedom in designing reports. There are also security features that prevent unauthorized access to data. | Administrators can create very targeted Data Sources and Data Source Topics, using repository access permissions to make sure users cannot modify them. |
In Case A, a Data Source could contain dozens of tables in several unjoined sets, limiting initial filtering, but effectively defining a strong data-level security policy. Users of this Data Source might see only a single set of tables, because of their security permissions. They could then perform their own filtering, re-label columns for their own needs, and save their settings as a Data Source Topic for future use in other Ad Hoc views. In this case, there might be only one Data Source within the organization, but there would likely be many Data Source Topics that users have created for specific needs. | In Case B, Data Sources can be used to perform complex joins, filter data, apply formulae to calculate new columns, and select sets of columns for specific users or specific report types. Perhaps the report types also require internationalization—the administrator would then create corresponding locale bundles and a single Data Source Topic. In this scenario, there are many specific Data Sources, and each would have corresponding locale bundles and a single Data Source Topic. Users would have a wide variety of Data Source topics to choose from, each for a specific purpose. However, they would have no opportunity to access the Data Sources to perform their own filtering. |
The preceding examples illustrate two extreme cases, but there are many common scenarios that combine some degree of both scenarios. The number of users in your production environment and their level of proficiency also determine your general use cases. A small number of users who understand their database might be given administrator privileges to define complex Data Sources as an extension of the Ad Hoc view design process. On the other hand, with large numbers of users or with users who have limited database skills, administrators will want to create Data Sources that help the users meet their business goals. Using a Data Source instead of a Topic has the following advantages:
Data Sources can be created directly through the server's user interface.
Data Source creators can write SQL queries, joins, filter expressions, and security files to specify what data can be accessed, as well as labels and locale bundles to specify how the data appears.
When designing a report based on a Data Source, the server can optimize database access to allow editing of reports that access huge datasets.
A Data Source design typically includes data filtering, but users who create reports using the Data Source can filter data even further. Users can select a subset of columns to appear in the Ad Hoc Editor and give them custom labels—users can then filter the data for each column.
Users who create reports can design prompts for input from report readers to filter data that appears in the document.