2.1 設計手順

辞書に登録するデータ項目および業務ルールは,システム開発の基盤となる情報です。アプリケーションを標準化して,システム開発や保守の効率を向上させるためには,アプリケーション開発に先駆けて,データ中心アプローチの考え方に基づいたデータ分析が必要です。ここでは,そのデータ分析の作業の中で,辞書の仕組みを生かしてデータ項目や業務ルールを効果的に利用するための,辞書の設計手順を説明します。

<この節の構成>
(1) データ分析の中での辞書の設計手順
(2) 効果的なデータ分析をするには

(1) データ分析の中での辞書の設計手順

データ中心アプローチでは,現行システムや,目標とする新システム,全体的または長期的なニーズを基にデータ分析をします。データ分析とは,データを共有資源として活用するために業務システムで使用するデータの要素や相互関係を分析し,その名称,構造,意味,表現形式や値の制限などを定義する作業をいいます。このデータ分析の過程で,システム開発で共有するデータ項目や業務ルールを設計し,辞書に登録していきます。

ここでは,データ分析の中で,どのような手順で辞書を設計すればよいのかについて説明します。辞書の設計手順と,システム開発の上流工程での位置づけを,図2-1に示します。

図2-1 辞書の設計手順

[図データ]

  1. 業務で使用するデータを調査します
    業務分析によって求められた,分析対象とする現行システムと,新システムの要求仕様の内容を引き継ぎ,業務で使用するデータを調査します。ここでは,システム開発のすべての工程で使用するデータが対象になります。現行システムからは,既存の帳票,画面,データベース,ファイルなどからデータ項目を抽出し,そのデータの属性,性質や制約条件を詳細に調査します。このとき,あらかじめ収集しておいた運用マニュアルなどを参考資料とします。また,システムで新しく使用するデータについても同様に,データの属性や性質などについて詳細に検討します。
  2. ドメインを分析します
    1.の調査結果を基に,業務システムに使用するデータから,共通の値域(タイプ,けた数,意味など)を持つデータをグルーピングします。これが,ドメインとなります(例:「年月日」,「金額」など)。システム開発に効果的に使用できる辞書を設計するには,あらかじめ,このドメインを分析する作業が必要です。ドメインの考え方や,分析の進め方については,「2.2 ドメインの分析」を参照してください。
  3. 名称基準を決め,それに従って名称を標準化します
    データ項目は,辞書の中で最も基本となる情報です。このデータ項目を効率良く利用するには,データ項目の名称によって各データを識別し,その意味を知ることができなければなりません。このために,あらかじめ名称基準を定めておき,それに基づいて名称を決めるようにします。詳細は,「2.3 名称の標準化」を参照してください。
  4. データモデルを作成します(データモデリング)
    データモデリングとは,業務システムの静的なデータの構造を,全体像としてまとめることをいいます。データを正規化する作業も,このデータモデリングに含まれます。作成するデータモデルは,実体を表すエンティティとエンティティ属性,エンティティ間の関連であるリレーションシップで構成されます。
    大規模システムのデータモデリングには,これを支援するツールを利用すると効率良く作業できます。データモデリングの進め方については,使用するツールのマニュアルを参照してください。ERwin/ERXを使用する場合には,作成したデータモデルから,エンティティやエンティティ属性の情報を,CSV形式ファイルを経由してデータ項目辞書に登録できます。
  5. データ項目を設計してデータ項目辞書に登録します
    ドメインの分析,名称の標準化およびデータモデリングの結果を基に,各データ項目の名称,意味,タイプ,けた数などを検討し,データ項目辞書に登録します。まず,2.で分析したドメインに相当するデータ項目をデータ項目辞書に登録します。そのあと,ドメインのデータ項目を継承して,下位のデータ項目をデータ項目辞書に登録します。詳細は,「2.4 データ項目の設計」を参照してください。なお,データ項目の設計には,SEWB+/STANDARD-DICTIONARYが提供する標準データ項目を利用できます。概要については,「付録A 標準データ項目辞書の紹介」を参照してください。
  6. レコード構造を設計してデータ項目辞書に登録します
    アプリケーション開発の準備として,サーバアプリケーション,およびクライアントとサーバのインタフェースに使用するレコードの構造やレポート出力に使用するレコードの構造をデータ項目辞書に用意します。このレコード構造には,データベースやファイルの設計結果,業務設計から求められたC/S(クライアントサーバ)システムのインタフェース仕様などを反映します。
    SEWB+/CONSTRUCTION,EUR Professional EditionおよびAPPGALLERY Enterpriseでレコード構造をどのように利用するかを考慮しながら設計します。 レコードの構造は5.で登録したデータ項目を組み合わせて,登録します。詳細は,「2.5 レコード構造の設計」を参照してください。
    なお,レコード構造は,SEWB+/RECORD DEFINERでも定義できます。SEWB+/RECORD DEFINERでは,データ項目辞書に登録されていないデータ項目(COBOL言語のFILLERなど)をレコードの構成要素として使用できます。
  7. 業務ルールを設計して業務ルール辞書に登録します
    ドメイン分析や業務設計の結果を基に,各データ項目特有の処理を抽出して,業務ルール辞書に登録します。業務ルールは,SEWB+/CONSTRUCTIONで作成するアプリケーションにどのように利用するかを考慮しながら設計します。データ項目と同様に,まず,継承関係の上位のデータ項目(ドメインに相当するデータ項目)の業務ルールから登録し,それに基づいて下位のデータ項目の業務ルールを登録します。詳細は,「2.6 業務ルールの設計」を参照してください。なお,業務ルールの設計には,SEWB+/STANDARD-DICTIONARYが提供する標準業務ルールを利用できます。概要については,「付録A 標準データ項目辞書の紹介」を参照してください。

(2) 効果的なデータ分析をするには

データ分析の分析対象は,データ分析をする際の目的やプロジェクトの開発体制や制限によって,現行システムを主体とするか,現行システムに対するニーズとするか,またはその両方とするかが異なります。しかし,実際にデータ分析をするときには,現行システムや現行システムに対するニーズおよび目標を取り混ぜた分析が必要といえます。また,システムが大規模であったり,複雑なシステムを扱うときや,分析作業に多くの時間を費やせない場合など,ユーザのおかれるシステム開発の環境はさまざまです。

したがって,データ分析作業は,一律ではないと考えられます。データ分析を始める前に,自プロジェクトではどのような分析方法,手順を採用すれば開発の目的を達成できるか検討し,状況に応じた適切な手段でデータ分析を実施するようにしてください。