Page Comparison

ソースの表示
{anchor:top}
{toc: class=contents}

h2. 概要
{styleclass: Class=topLink}[top|#top]{styleclass}
Yellowfinのビューは、データソース内の物理的なビューあるいはテーブルのメタデータです。レポート作成者は、データベースに対してクエリーを発行するビューを選ぶだけで、データベースの実際の構造について理解することなしに、データの分析やビューのフィールドを使ってのレポート作成を行うことができます。


ビューは、レポート作成者が技術的なスキルなしにレポートの実行やデータの分析を行えるよう、直観的なインターフェースを提供します。








bq. See [View Creation] for more information.
h3. ビューの管理

ビューは管理者によって作成されます。どんな人がビュー管理者になるかについて基準はありません。たとえば社内のデータベース管理者やアプリケーションマネージャー、あるいはプロジェクトマネージャーなど、あるいは十分な技術力のあるビジネスユーザーが他のユーザーのためにビューを作成することになるでしょう。


ビュー管理者には、以下のような技術的なスキルと知識が必要です：


|| *スキルと知識* \\ || *説明* \\ ||
| ユーザーのニーズを分析する能力 \\ | ビュー管理者には、ユーザーのニーズを分析して解りやすいカテゴリーやフィールドを定義し、ユーザーコミュニティの要件を満たすようなビューを作成できる能力が必要です。 \\ |
| データベースの知識 \\ | ビュー管理者は会社のデータベース管理システム（DBMS）に関する実用的知識が必要です。データベースの運用状況やその論理的構造、そしてデータベースに収められているデータに関して熟知していなければなりません。 \\ |
| SQL（Structured Query Language） \\ | SQLの実用的知識が必要です。 \\ |

h3. ビューの構成要素

ビューには以下の構造が含まれます：


| *カテゴリー* \\ | カテゴリーの目的は、ビューに含まれるフィールドを論理的グループに分類することです。カテゴリーの名称はビジネスユーザーにとって直観的で、それに含まれるフィールドが想像できるようなものであるべきです。  \\
たとえば「個人の詳細」という名前のカテゴリーは、人名、年齢、性別を含んでいることを想像させます。 \\ |
| *フィールド* \\ | フィールドは、データベース内のデータあるいはデータからの派生物を示す構成要素です。フィールド名にはビューを使うユーザーグループの使用するビジネス用語をあてるべきです。  \\
たとえば、プロダクトマネージャーが使うであろうビューのフィールド名は、製品、ライフサイクル、出荷日といったものになります。財務アナリストの場合は、利福とか投資利益率というものになるでしょう。 \\
レポート作成者がビュー上で使うフィールドは、データベースのスキーマに挿入されるSQL構造に対応します。 \\ |

h3. Fieldフィールドタイプ
Types

When creating a VIEW, you define and categorise fields. The definition of a field reveals how it can be used in analysis and reports. A field can be defined as a dimension or a metric. Each type of field serves a different purpose:


ビューを作成するには、フィールドを定義および分類します。この定義はそのフィールドがレポートでどう扱われるかを既定するもので、フィールドは、ディメンション（次元）またはメトリック（数値）のどちらかに定義されます。その用途を以下の表に示します。


| !rpt_dimension.gif! | 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.) ディメンション（次元）フィールドはレポートにおける分析の基盤となるデータを取得します。一般的に文字データ（社員名、会社名など）、あるいは期間（年、四半期など）です。 \\ |
| !rpt_measure.gif! | 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. \\
Basic Metrics do not need to have an aggregate calculation (such as a SUM or AVERAGE) performed on them within a report. メトリック（数値）フィールドはデータベースのデータの計算結果である数値データです。 \\
メトリック（数値）データは変動します。その値は、共に使われるDimensionに依存します。たとえばクエリーに人物と年齢を指定すれば、年齢は人物ごとに計算されます。 \\
基本的にメトリック（数値）データはそれ自体集計（合計や平均など）を必要としません。それらはレポート上で実行されます。 |
| !rpt_filter.png! | 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. 定義済みフィルターはビューの作成時に設定された条件セットです。これはユーザーがクエリーの結果を絞り込むのに役立ちます。たとえば「United States」というフィルターを使うと、アメリカ合衆国からのデータのみがクエリーの結果として返されるといった具合です。 |
| !rpt_parameter.gif! | 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. パラメーターは、ユーザー定義の値を取り込むために使用されるフィールドで、計算フィールドまたはフィルターに渡されます。このパラメーターは、What-If分析（仮説分析）を実行する際に役立ちます。 |
| !view_filtergroup.png! | 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.ビューフィルターグループは、フィルターとして使用するフィールドのセットであり、複数回再利用されます。フィルターグループには、フィルター従属関係階層、およびキャッシュされる値を含めることができます。これらのグループの設定は1回だけで済み、レポートごとに設定する必要がなくなります。\\ |


h2. How are views used?
{styleclass: Class=topLink}[top|#top]{styleclass}
Views are used by Yellowfin report writers. The view meta-data is stored within the Centralised Yellowfin repository. An end user connects to a view via a web browser when running a report.

By using a view, the end user automatically has access to data within your source system. Access to data is restricted by the fields that are available in the view. These fields have been created by the administrator based on the report users needs.

h3. Assisting Data Analysis

A view can represent 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.

h3. Who uses views?

Yellowfin report writers use views for reporting and analysis. The view should provide them with categories and fields relevant to their business domain.

h3. How are fields presented for report writers?

Fields are displayed as nodes in a folder tree as shown below.

!45.png|thumbnail,border=1!


h2. View design methodology
{styleclass: Class=topLink}[top|#top]{styleclass}
The view design methodology consists of four stages:
# Analysis of business problem and planning the view solution
# Building the view
# Defining fields and Creating Calculated Fields
# Publishing the view to users

Each implementation phase is based on an assumption that you have completed an initial planning phase.

# Plan the view
The analysis of user requirements and design are the most important stages in the process. Users must be heavily involved in the development process if the view is going to fulfil their needs both with the business language used to name fields and the data that can be accessed.
Implementation will be very quick and easy if this stage is carried out properly. You should note the following points:
## You must fully understand the data analysis and reporting needs of the target audience for the view. Do not create fields by looking at the columns available in the database, but identify columns that are required as a result your user needs analysis.
## Understand the source system data and business rules required for generating the required fields for users.
# Building the view
You create an entity relationship diagram for the underlying database structure of your view. This includes the selecting the appropriate tables and columns of the source database and the joins by which they are linked.
# Defining Fields
Select columns form your source system tables and organise these fields into categories. These are fields that you have identified from an analysis of user reporting needs. You can create additional calculated fields and filters to enhance user reporting capabilities and optimise query performance.
Test the integrity of your view structure. You should also perform tests using the report writer on the view.
# Publish the View
You can publish your view to users for testing, and eventually for production use, by expanding the number of users that have access to the view.

The table below 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 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. |
{color:#c00000}{*}Note:*{color} View design should always be driven primarily by user requirements and NOT the data source structure.
\\
\\
{horizontalrule}
{styleclass: Class=topLink}[top|#top]{styleclass}