DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

menuclear
ホーム > ブログ > 中山 嘉之の記事一覧 > リポジトリを作ってみよう!(その2)


リポジトリを作ってみよう!(その2)


今回のブログは前回のリポジトリ作成がデータ部品の基本部だけであったので、これをもう少し範囲拡張してみたい。前回は触れなかったが、ここでご紹介するメタモデルは1982年私がユーザ企業の情報システム部門に転籍後、最初に手がけたプロジェクトで用いたものとほぼ同様である。という事は30数年たっても企業システムの論理的なデータ・コンボーネントは変わらないという事だ。このメタモデルを用いて社内の全基幹系システムのメタデータを同僚とともに日夜登録し続けたおかげで、悲しいかなこのモデルをほとんど暗記している。

さて、図1にサンプルメタデータモデルを掲載する。図上では新たに追加した3つのエンティティを色付けしている。前回のモデルに加えて、まずはレコード定義と1:Nの関係にあるファイル(物理テーブル)定義を加えてみる。ファイル定義は、FD-XXnnn(FD:File Description、XX:アプリ番号、nnn:連番)をPK(Primary Key)として、テーブル名称、意味説明などの属性を保持する。レコード(エンティティ)との関係はファイル定義側の属性にRD番号をFK(Foreign Key)として保有し、その関係性を定義する。図1では、この後で登場する画面/帳票レコード定義と区別して、前回のレコード定義を汎化概念テーブルとして点線で表記し、新たにDBレコード定義として特化サブタイプテーブルを表記し、これにファイル定義を連携させている。これで、ドメイン定義の変更がテーブル変更に及ぼす影響分析が可能となる。サンプルメタモデル

次に、データの集合体としてのインプット画面、アウトプット画面・帳票の定義を加えてみたい。PKEYはID/OD-XXnnn(略 ID:Input Description、OD:Output Description)で、属性には画面や帳票の用途や利用者などの意味とともに、画面/帳票に用いる仮想レコードのRD番号を定義する。この仮想レコードはデータベースの複数テーブルからなるVIEWや、複数テーブルをJOINしたテンポラリなスキーマをもとに実装される。いわゆるUI(User Interface)の定義なのであるが、ここでは操作性に関する部品は無視して、データに関する部品のみに着目する。余談であるが、昨今の”POA(Process Oriented Approach、造語)”ではユーザビリティにとらわれるあまり、この基本動作が出来ないSEが多い 。このことは少なからず後工程での揺り戻しの大きな原因となっている。話しを戻して、画面/帳票の部品となるデータは仮想的な画面/帳票レコード(外部スキーマ)を経由して1:Nの関係で画面や帳票につながる。よって、まず画面/帳票レコードを定義する必要がある。ここでは画面や帳票の“明細行”に着目して外部スキーマを抽出する。このレコード定義の登録では一般のエンティティと区別する為に、P-KEYをRD-XX9nn(連番nnnの先頭桁を9)とする等の工夫をするのが良い。このレコード定義の属性には”XXXX画面明細レコード”などのレコード名称を登録する。そしてデータ部品との関係は、DBのデータ項目の場合と同様にレコードレイアウト定義を用いて外部スキーマの要素データを”縦持ち”に登録する。これにより、先程の画面/帳票レコードとN:1で紐付けされる。

ここまでで、原始的ドメインデータから始まり、”情報”としての付加価値を備えたアウトプットに至るまで、基本的なデータ部品の関係を整理する事が出来た。どうであろうか、システム設計において出来るだけ早い段階で、このデータのトレーサビリティを確立しておけば、残るはデータ間を繋ぐ加工ロジック(加工のないものは単なるマッピング)を詰めて行けば良いことになり、こちらがもう一方のプロセス部品定義という事になる。私はこの一連のデータ部品定義を要件定義工程で行う事を推奨する。今更ながらだが、これがDOA(Data Oriented Approach)である。モックアップ若しくは本物の画面(データはいい加減)を1日も早くユーザに見せて、”承認”を取る事も大事だが、これと並行してデータ設計を行う事が、少なくとも後工程における”やり直し”を防ぐ最も確実な方法である。ウオータフォール型開発における基本設計以降のアウトソースが一般的な今日、ビジネスを熟知している社員が関与できる要件定義工程で行う事が何よりの品質保証となる。速い段階からモノ作りに入るアジャイル型開発でも、要件定義工程まではウオータフオール手法でDB論理設計までを行い、それ以降の設計・開発・テスト工程にアジャイルを適用すれば良い。DB物理設計はイタレーションの中で十分にまかなう事ができるであろう。

 もう一方のプロセス部品の定義に入る前にかなりの行数を費やしてしまったので、今回はデータ部品関連の完了迄ということにして、プロセス部品は次回のブログに持ち越すことにしたい。ぜひ、次回にご期待下さい。いつも最後まで読んでいただいている読者に感謝。

| 目次

採用情報
PM-waigaya
PM-WaiGaya
コンサルタントのトーク動画
PM Weekly Talk
PM Weekly Talk
コンサルタントが語る「PMBOK®12 の原理・原則」

Profileプロフィール

Avatar photo
中山 嘉之
1982年より協和発酵工業(現、協和発酵キリン)にて、社内システムの構築に携わる。メインフレーム~オープンへとITが変遷する中、DBモデラー兼PMを担い、2013年にエンタープライズ・データHubを中核とする疎結合アーキテクチャの完成に至る。2013年1月よりアイ・ティ・イノベーションにてコンサルタントを務める。【著書】「システム構築の大前提 ― ITアーキテクチャのセオリー」(リックテレコム)

Recent Entries最近の記事