Defining views for report creation
A view is a metadata layer that sits between the source connection and the report builder in Remedy Smart Reporting(Smart Reporting). An administrator can create a view that defines relationships between tables, identifies fields that report writers can access, and defines default formatting for these fields. Without having to understand the underlying logic, a report writer can use the table relationships and defined fields to create their reports.
You can create a view that represents the data needs of any specific application, system, or group of users. For example, a view can contain fields that represent the data needs of the Marketing or Accounting departments in a company. A view can also represent the data needs of a section within a department or any set of organized procedures such as a payroll or inventory system.
Best practices
- Create multiple small views specific to use cases instead of one large view that covers all use cases.
- Plan for view objects like forms and fields that will be included in the new view.
- To make a view more useful, give business names to the view objects.
In addition to the information on this page, see the following subtopics:
- Views
- Creating a view of database tables and fields
- Editing, deleting, or rolling back a view
- Modifying an out-of-the-box view
- Customizing the fields in a view
Using views
Smart Reporting report writers use views to create reports and analyze data. The view should provide them with categories and fields relevant to their business domain.
End users connect to these views when they run reports. With a view, end users automatically have access to data within your source system. You can restrict the data access by the fields that are available in the view.
Process for designing and creating a view
The following table outlines the major phases in a typical view development cycle:
| Development phase | Description |
|---|---|
| Prepare | Identify the target data source and become familiar with its structure. Know what data is contained within each table for the view. Also know the joins that relate the tables to each other. |
| Analyze | Identify the information that users need and what standard reports they require. Involve users so that you can familiarize yourself with their business terminology and name views and fields logically. Identify a project strategy. For example, determine how many views you should create and which views should have the capacity to be linked and to what level. Analyzing user requirements and designing views are the most important steps in the process. If the Analyze phase is carried out properly, implementation can be very quick and easy. To ensure success during this phase, be sure to fully understand the following:
|
| Implement | Build the view on the database or through the Smart Reporting view builder. Test frequently during the build process for validity and reliability of inferred SQL. During implementation, create an entity relationship diagram for the underlying database structure of your view. This includes selecting the appropriate tables and columns of the source database and the joins by which they are linked. Define the fields. Select columns from your source system tables and organize these fields into categories. These are the fields that you have identified from an analysis of user reporting needs. To enhance user reporting capabilities and optimize query performance, create additional calculated fields and filters. |
| Test | Form a small group of users, preferably power users who have some knowledge of what information they expect to get from the view. Add these users to the access security list for the view, and ask the users to perform thorough tests simulating live usage of the views. |
| Deploy | Migrate the view from your Test to Production environments. Change access security of the view so that it is available to the target user base. |
| Evolve | Update and maintain the view as the data sources and user requirements change and grow. |
Note
User requirements and not the data source structure should be the primary driver for view design.
Comments
Log in or register to comment.