Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Anchor
top
top

Table of Contents
classcontents

Overview

A Yellowfin View is a metadata layer that sits between the Source Connection and the Report Builder. It's used to define relationships between tables, identify fields to be accessed by report writers, and define default formatting for these fields. A report writer will use the relationships and fields defined in the view to base their reports on, without having to understand the underlying logic.

See View Creation ビュー作成 for more information.

Who is the view Administrator?

...

A view contains the following structures:

Categories

The purpose of field categories is to provide logical groupings of fields within a view. The name of a category should intuitive to the business user and provide an indication of the fields that it is likely to contain.
For example a category called ‘Private details’ is likely to contain a person’s name, age and gender.

Fields

A field is a named component that maps to data or a derivation of data in the database. The name of a field should be drawn from the business vocabulary of the targeted user group.
For example, fields used in a view used by a product manager could be Product, Life Cycle, or Release Date. A view used by a financial analyst could contain fields such as Profit Margin, and Return on Investment.
The fields that report writers see in a view infer SQL structures that have been inserted into a database schema.

...

Dimension fields retrieve the data that will provide the basis for analysis in a report. Dimensions typically retrieve character-type data (employee names, company names, etc.), or dates (years, quarters, etc.)

Metric fields retrieve numeric data that is the result of calculations on data in the database. Metrics tend to be dynamic: the values they return depend on the dimensions they are used with. For example, if you include Person and Age in a query, Age per person is calculated.

View Geography Fields are fields linked to a GeoPack.

Pre-Defined Filters are fields where a set of conditions have been set up when the view was created. This assists users to limit the data returned in a query to only the expected results. For example if the filter is called ‘United States’ then only data from the united states would be included in the results.

Parameters パラメーター are fields which are used to capture user defined values and pass them into calculated fields or filters. These parameters can assist in conducting what if analysis.

View Filter Groups are sets fields to be used as filters, reused multiple times. Filter Groups can contain filter dependency hierarchies, as well as cached values. These only have to be set up once, rather than for each report.

...

Development phase

Description

Prepare

Identify the target data source and become familiar with its structure.
Know what data is contained within each table required for the view and the joins that related the tables to each other.

Analyse

Identify what information the users need. Identify what standard reports they require.
Familiarise yourself with their business terminology so that you can name fields sensibly.
Plan Identify a project strategy. For example, how many views should be created and which ones should have the capacity to be linked and to what level.

Implement

Build the view either on the database or through the Yellowfin view builder.
Test frequently during the build process for validity and reliability of inferred SQL.

Test

Form a small group of users, preferably power users who have some knowledge of what information they expect to get from the view.
Pre-Release the view to these users by adding them the access security list for the view.
Ask the users to perform thorough tests simulating live usage of the view(s).

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: View design should always be driven primarily by user requirements and NOT the data source structure.