ボトムアップアプローチでデータモデル(エンティティ関連図)を作成するための第一歩はデータ項目の収集です。
既存システムが存在している場合であれば、データ項目を収集するといってもそれほど難しくないかもしれませんが、実際にはそのまま利用することができないケースが非常に多いのも事実です。
では、具体的にどのようにしてデータ項目を収集すればよいのでしょうか?
まずは、既存のドキュメントを分析します。
既存のシステム設計書(テーブル仕様書、ファイル仕様書、インタフェース仕様書等)からデータ項目を整理していくというのがオーソドックスな考え方でしょう。
しかし、そのようなドキュメントが存在しない、あるいは、運用段階でドキュメントのメンテナンスを確実に実施してこなかったため、実際のDBの内容と異なるというケースも多々あります。
その場合は、リバースエンジニアリングを検討します。
RDBMSで実装されている場合には、ツール(Xupper、ER/Studio、ERwin等)を利用しリバースエンジニアリングを行うことができます。
COBOLであれば、コピー句からデータ項目を捕捉するということも考えられます。
あてにできる資料がまったく存在しないという場合は、ゼロから整理する必要がありますが、いきなりユーザさんに「データ項目を全て出してください」といっても無理なことは明白です。
では、どうすればいいのでしょうか?
どんなユーザさんであろうと、業務を行っている限り、なんらかの「台帳」や「伝票」を使用しているはずです。
その「台帳」や「伝票」を元にデータ項目を収集します。
また、システム開発の過程で新システムの「画面」や「帳票」のレイアウトを作成していけば、おのずと必要なデータ項目が分かってくるはずです。
「画面」や「帳票」レイアウトや「外部インタフェース」レイアウトがあるのであれば、画面・帳票・外部インタフェースファイルレイアウトからデータ項目を収集します。
ただし、「画面」や「帳票」上に定義されている項目だけが、データ項目ではないことに注意する必要があります。
処理でのみ参照し、レイアウト上には現れていないデータ項目があるからです。
例えば、以下のような項目です。
①出力順序制御項目(作表シーケンス)
②選択および除外条件(抽出条件)
③チェックで参照している項目(与信チェック時の与信限度額等)
④編集・計算で使用している項目 等
既存システムが存在している場合であれば、データ項目を収集するといってもそれほど難しくないかもしれませんが、実際にはそのまま利用することができないケースが非常に多いのも事実です。
では、具体的にどのようにしてデータ項目を収集すればよいのでしょうか?
まずは、既存のドキュメントを分析します。
既存のシステム設計書(テーブル仕様書、ファイル仕様書、インタフェース仕様書等)からデータ項目を整理していくというのがオーソドックスな考え方でしょう。
しかし、そのようなドキュメントが存在しない、あるいは、運用段階でドキュメントのメンテナンスを確実に実施してこなかったため、実際のDBの内容と異なるというケースも多々あります。
その場合は、リバースエンジニアリングを検討します。
RDBMSで実装されている場合には、ツール(Xupper、ER/Studio、ERwin等)を利用しリバースエンジニアリングを行うことができます。
COBOLであれば、コピー句からデータ項目を捕捉するということも考えられます。
あてにできる資料がまったく存在しないという場合は、ゼロから整理する必要がありますが、いきなりユーザさんに「データ項目を全て出してください」といっても無理なことは明白です。
では、どうすればいいのでしょうか?
どんなユーザさんであろうと、業務を行っている限り、なんらかの「台帳」や「伝票」を使用しているはずです。
その「台帳」や「伝票」を元にデータ項目を収集します。
また、システム開発の過程で新システムの「画面」や「帳票」のレイアウトを作成していけば、おのずと必要なデータ項目が分かってくるはずです。
「画面」や「帳票」レイアウトや「外部インタフェース」レイアウトがあるのであれば、画面・帳票・外部インタフェースファイルレイアウトからデータ項目を収集します。
ただし、「画面」や「帳票」上に定義されている項目だけが、データ項目ではないことに注意する必要があります。
処理でのみ参照し、レイアウト上には現れていないデータ項目があるからです。
例えば、以下のような項目です。
①出力順序制御項目(作表シーケンス)
②選択および除外条件(抽出条件)
③チェックで参照している項目(与信チェック時の与信限度額等)
④編集・計算で使用している項目 等