Wiki Markup |
---|
ソースの表示 {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. フィールドタイプ ビューを作成するには、フィールドを定義および分類します。この定義はそのフィールドがレポートでどう扱われるかを既定するもので、フィールドは、ディメンション(次元)またはメトリック(数値)のどちらかに定義されます。その用途を以下の表に示します。 | !rpt_dimension.gif! | ディメンション(次元)フィールドはレポートにおける分析の基盤となるデータを取得します。一般的に文字データ(社員名、会社名など)、あるいは期間(年、四半期など)です。 \\ | | !rpt_measure.gif! | メトリック(数値)フィールドはデータベースのデータの計算結果である数値データです。 \\ メトリック(数値)データは変動します。その値は、共に使われるDimensionに依存します。たとえばクエリーに人物と年齢を指定すれば、年齢は人物ごとに計算されます。 \\ 基本的にメトリック(数値)データはそれ自体集計(合計や平均など)を必要としません。それらはレポート上で実行されます。 | | !rpt_filter.png! | 定義済みフィルターはビューの作成時に設定された条件セットです。これはユーザーがクエリーの結果を絞り込むのに役立ちます。たとえば「United States」というフィルターを使うと、アメリカ合衆国からのデータのみがクエリーの結果として返されるといった具合です。 | | !rpt_parameter.gif! | パラメーターは、ユーザー定義の値を取り込むために使用されるフィールドで、計算フィールドまたはフィルターに渡されます。このパラメーターは、What-If分析(仮説分析)を実行する際に役立ちます。 | | !view_filtergroup.png! | ビューフィルターグループは、フィルターとして使用するフィールドのセットであり、複数回再利用されます。フィルターグループには、フィルター従属関係階層、およびキャッシュされる値を含めることができます。これらのグループの設定は1回だけで済み、レポートごとに設定する必要がなくなります。 \\ | h2. ビューの使用 {styleclass: Class=topLink}[top|#top]{styleclass} ビューは、Yellowfinのレポート作成者によって使用されます。ビューのメタデータはYellowfinによって集中的に管理され、エンドユーザーはレポートの実行時に、ウェブブラウザーを通してビューにつながります。 ビューを使うことで、エンドユーザーは自動的にソースシステムのデータにアクセスします。データへのアクセスは、ビューで利用可能なフィールドにより制限されます。管理者はレポート使用者の必要に合わせてこれらのフィールドの定義を行います。 h3. データ分析の補助 ビューは必要に応じてどんなアプリケーション、システム、ユーザーグループに対してもデータを提供できます。たとえば、会社においてマーケティング担当部署や会計部署が必要とするフィールドを含めることができます。 ビューはまた、部署内にあるセクションや、給与支払いや在庫管理のシステムといった組織化された処理のニーズにも応えられます。 h3. ビューの利用者 レポート作成者は、レポートや分析のためにビューを使います。ビューは、作成者が必要とするカテゴリーとフィールドを提供しなければなりません。 h3. レポート作成者に提供されるフィールド フィールドは、以下のようにツリー構造のノードとして示されます。 !45.png|thumbnail,border=1! h2. ビューのデザイン方法 {styleclass: Class=topLink}[top|#top]{styleclass} ビューのデザインは、以下の4つの段階を踏んで行います: # ビジネス上の要件を分析し、それに応えられるビューを計画する # ビューを構築する # フィールドを定義し、計算フィールドを作成する # ビューをユーザーに公開する 各実装フェーズは、最初の計画フェーズを完了していることが前提となります。 # ビューを設計する ユーザー要件の分析とデザインは、最も重要なステージです。ビューで使用するフィールド名にユーザーが使うビジネス言語を使い、データアクセスに関して彼らのニーズを満たすためには、この段階でユーザーにかなり関与してもらわなければなりません。 このステージがきちんと実行できれば、実装は非常に速くまた簡単に行えます。それには以下の点に注意すべきです: ## データを分析し、ユーザーのレポートに対する要求を完全に理解しなければなりません。利用可能なカラムから機械的にフィールドを作成するのではなく、ユーザーのニーズを分析した結果としてそのカラムが必要であることを確認してください。 ## ソースシステムの持つデータとユーザーが要求するフィールドを作成するために必要なビジネスルールを理解してください。 # ビューを構築する ビューの背後にあるデータベース構造に対して、テーブル間の結合定義を行います。データベース内のテーブルとカラムを選択し、リンクされるべきものを結びつけてください。 # フィールドを定義する ソースシステムのテーブルからカラムを選び、それらをカテゴリーに分類します。これらのフィールドは、ユーザーのレポートに対するニーズの分析から特定されたものであるはずです。またレポートの有用性を拡張し、クエリー実行のパフォーマンスを向上させるために、必要に応じて計算フィールドやフィルターを追加することもできます。 定義が済んだらビューに対してテストを行います。ビューを使用して実際にレポートを作成するテストも行わなければなりません。 # ビューを公開する まずは少数のユーザーに対して試験的にビューを公開します。徐々にビューにアクセスするユーザーの数を増やして修正を繰り返し、実際の業務に供します。 以下の表は、一般的なビュー開発の主な段階を示したものです: || 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. データベース上で、あるいはYellowfinのビュービルダーを使ってビューを構築します。\\ 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} |
Page Comparison
General
Content
Integrations