前のページに戻りますホームへサイトマップへ
           
   
 
 



データベース設計基礎>データ分析手順  
 
     
   ホーム >お役立ち情報>データベース設計基礎>データ分析手順  
       

 データ分析手順
 データベース設計指南:DOA Evangelist 小見山 昌雄
  なお、運用設計以下の作業については、DBMSやハードウェアー、オペレーションシステムなどの制約を受けるので、ベンダー・メーカーの教育コース受講を勧める。

 作業手順
  データ分析作業は以下の手順で進めます。
1.分析対象の量的把握と分析準備
 分析対象スコープとなるビジネスが持つデータ量を把握する。
2. 分析作業計画
 把握したデータ量と作業体制から作業計画を策定する。
○以下の4工程は、ユーザインターフェース毎に繰り返し実施
3.データ分類
 ユーザインターフェース上のデータから分析対象を特定する。
4.エンティティの抽出
 ユーザインターフェースのデータからエンティティを抽出する。
5.関連の設定
 ユーザインターフェースのデータから関連を設定する。
6.属性整理
 ユーザインターフェース上のデータをエンティティに割り付ける。
7.レビュー
 ユーザインターフェース別のデータ分析結果をレビューする。
8.モデル統合
 ユーザインターフェース毎に概念データモデルを段階的に統合する。
9.詳細分析
 詳細なビジネスルールによる概念モデルの微調整。
10.モデル検証
 エンティティとデータ項目の過不足を中心にモデルを検証する。

 以下、手順を追って詳細に説明します。
スコープ
 「システムが拡大し、とても全体を一度に再構築するのは難しい」と思っているかも知れないが、データ構造を整理してデータと機能の冗長性を排除すれば、システム規模は少なくとも、1/3以下にはなる。
 と、今から10年以上前に、某有名コンピュータメーカの資料に書いてある。(正確に言うと「現在書き込まれている全コードの70%もが、様々なシステム間でのリンクを確立するためのインターフェース、プロトコル、プロシージャに使用されている」と主張している)
 これは正しく、そして状況は更に悪化しているだろうと思われるので、効果は更に増すと言う訳だ。
 システム規模が1/3になると言う事は、システムの開発・運用・管理に関わる全てのリソースが1/3以下に削減されると言う事だ。
 それだけ取ってもデータ分析/データモデリングのスキルを習得してデータベース設計の品質を上げる動機付けには十分だ。
 本来、コストに敏感な経営者にこの情報が伝われば、もちろんスキル修得が指示されるだろうが、残念ながら、情報システムのこの暗黒面を把握している経営者は少ない様だ。 

 1.分析対象の量的把握と分析準備
 作業計画立案の基礎資料とするために分析対象を量的に把握します。
 データ項目数とユーザインターフェースの種類別の数量把握は必須。
 ユーザインターフェースのデザインや操作を確認するために必要となる、画面や設計書へのアクセスの容易性などの確認も行う必要があります。
 なお、急ぐ場合や、概要レベルでのデータ構造が分かれば良い場合などは、主要なビジネスイベントに関する入力ユーザインターフェスだけを選んで分析しても、8〜9割程度のエンティティ・データ項目を網羅しているので、ユーザインターフェースに入出力で区分をしておくと、計画立案時に計画策定の選択肢が広がります。

 なお、分析対象の量的把握と並行して、以下の分析準備を行います。
・命名基準
 データ項目の命名ルールを規定します。(基本的にビジネスの中で流通している名称をそのまま継承しますが、思わぬ所で新たに命名する必要がある存在があるものです。)
・作図基準
 既存の方法論や技法を採用する場合でも、技法の限界、作図ツールの違い、組織外の要員動員などで、いつものやり方や暗黙の了解が通用しない場合が多いので、分析方法や作図要領を基準として標準化しておきます。
・教育コース
 要員の大量動員が必要となる規模が想定されている場合は、初期教育のための教育コース(テキスト・演習問題・ツール操作要領・作業環境・指導要領など)を、目標水準に達したか否かの判定方法・講師などを含めて用意します。
・データモデルの管理環境
 情報セキュリティの観点から、作業成果の保全と機密保持を図るため、本人確認とチェックイン・チェックアウト機能を持つライブラリ管理機能を設定します。
・指導レビュー体制
 促成されたデータ分析者を大量動員によって稼働する場合、適時の指導と、小さな単位での頻繁なレビューが欠かせません。
 所定レベルの要員で、必要な指導レビュー体制を構築します。
・文書管理システム
 成果物としてのデータモデルは前述の「データモデルの管理環境」で管理するとしても、作業に付帯的に発生する文書(例えば、データモデルレビュー評価表・指摘事項対応管理表・問題点管理表)など共用と履歴管理が必要な文書を管理するため、グループウェアなどの仕組みを用意します。
 もちろん、既存の文書管理システムがある場合はそれを利用すれば良いので、グループウェアーの管理責任者にプロジェクト用の環境設定を申請します。
概念
 概念データモデルの「概念」とは、頭の中で考えている事を指す。
 概念的は具体的の反対で、具体性の無い事に対する非難に使われる事が多い。
 では、概念モデルは頭の中で考えている事のモデルなのかと言うと、その通りである。
 「私はビジネスをこの様に理解しております」と言う事をデータモデルと言う表現で見せていると言う事だ。 通常、概念は外からうかがい知れない。
 そのため「分かりました」と言われても、本当に分かっているのかどうかは、分からない。
 そこで、概念データモデルに表現すると、対象のビジネスをどの様に理解していたかと言う事が、可視化されると言う訳だ。
 可視化されれば、間違いが分かる。
 間違いが分かれば直せば良い。
 誤解や思い違いが、テスト工程や移行作業の中でようやく発見される事に比べれば、モデルを描く手間が少々掛ったとしても遥かにましだ。

 2.分析作業計画
   ユーザインターフェース毎のデータ分析を幾つか実施して、平均分析時間を把握し、全体の分析工数を見積もります。
 作業部隊の習熟度やプロジェクトが分析しようとしている対象の状況や参考情報へのアクセス環境(担当者へのヒアリングなども含む)は机上で見積もる事が難しいので、パイロットテストで基礎データを収集します。
(作業に着手してから、業務担当者へのヒアリングやレビューがネックで作業が進まないなどは、良く聞く現象ですが、事前に把握して、体制的・組織的な対応をしておきましょう。)
 そうすれば、工数は簡単な掛け算で求めることが出来るのですが、基本的に後になれば成るほど、出てくるデータ項目は既に整理されている確率が高まるので、入力ユーザインターフェースは全て同様な作業負荷が掛るでしょうが、出力ユーザインターフェースは、最初の3割程度を分析すれば、後はほとんど重複確認だけで済んでしまいます。
 見積には、その辺りの状況も考慮して下さい
 但し、データモデルを作業グループ単位と全体で、一つに集約する作業につては、ユーザインターフェース毎の分析作業と同じペースで進む訳が無いので、一律の見積は不可能です。
 担当者が、経験と作業ボリュームから所要期間を設定するしかないので注意して下さい。
 また、既存要員のみで作業する場合は、所要期間は簡単な割り算となりますが、納期短縮のために外部要員を動員する場合には、教育期間と指導・レビューの負荷を追加する必要があります。
 なお、この段階で、作業体制と分析対象の割り当てを決め、進捗管理の指標も明確にしておきます。

 3.データ分類
例えば、データベースへの登録日時を、記録として持つ事は、データベースの運用管理上当然ですが、それは、データベースを運用・管理する上で必要なデータ項目であり、ビジネスの中で発生したデータではありません。
 また、当月売上合計金額などの集計項目は、売上として記録されたレコードの売上金額を、期間で集計したデータなので、データ構造上で、売上に入れる事は出来ません。
 つまり、存在する全データ項目を、実装するためにDDLの対象とする物理モデルと違い、概念モデルにはデータモデルとして表現出来るデータ項目とデータモデル上では扱えないデータ項目に分かれます。
 これら、ビジネスのモデルとしては対象外となるViewデータや運用・管理データはあらかじめ分析対象外として分類しておく事が出来ます。
 もちろんデータ分析に習熟し、十分なスキルがあれば、見ただけで対象外である事は自明なので問題ありませんが、特に、大規模作業で、促成の分析者を外部から動員しているようなケースでは、作業を円滑にするめるためには必要な配慮であると言えるでしょう。
 なお、分類されたデータ項目も一元管理するので、様式を決めて一元管理し、以後の重複発生を牽制する必要があります。
作図作法
 データモデルには、見易く理解し易いモデルと、見難く理解し難いモデルがある。
 よって、見易く理解し易いモデルの特長を抽出し、作図基準として標準化する事で、センスの悪い担当者によってもたらされる、分かり難さによる生産性の低下をかなり軽減する事が出来る。
 規定内容としては、全体のスペース分割や配置(上部にリソース、下部にイベントを配置するなど)、エンティティやエンティティグループの間隔、並べ方など。
 また、ツールを使う場合には、印刷時にエンティティが2ページに亘ってプリントされてしまうと非常に見難いので、必ず1ページに収める事などを追加する必要がある。

 4.エンティティの抽出
  識別子・ユーザインターフェースの名称・名称の接尾語(顧客名称など)などをヒントに、それぞれが示唆する対象をエンティティ候補とし、エンティティの存在を確認します。
 エンティティの存在が確認された場合は、名称を付与しリソース・イベントに分類します。
 名称は、基本的にビジネスの中でのエンティティの呼称となります。
 分析によって、通常、業務の中で意識していない存在が明らかとなり、ビジネスの中で呼称が存在しない場合は命名基準によって命名します。
 また、エンティティにはインスタンスを識別する情報が存在するので、当該データ項目、またはデータ項目群を、識別子として特定します。
 なお、リソースエンティティは、顧客に対する連絡先情報(電話番号やメールアドレスを複数持っている場合)や口座情報のように、識別子を共有または一部共有するものを集めてグループを形成し、図上は図の上方にグループ毎に配置します。
 また、イベントエンティティは、前後関係から左から右へと後続イベントを連ねて配置します。
 以上、エンティティの配置を識別容易となるように配慮して、企業毎の特性を配慮した標準配置を設定し、作図基準に含めておく事を勧めます。
 リソース・イベント
 エンティティは存在を表すリソースと行為・出来事を表すイベントに大別される。
リソースは関係に依存せず、独立して存在するが、とイベントは他エンティティとの関連で生成する。
 よって、モデル上での扱いも異なる。
 他にも、中間的なエンティティや補助的なエンティティが存在する。

 5.関連の設定
 実は、関連を完全にご理解頂く事は大変に困難です。
 セミナー受講者の演習問題の出来栄えを見ていても、データ分析やデータモデリングを学習する中で、もっとも理解が難しい概念だと思います。
 その証拠に、今まで見て来たデータモデルと称する図面の多くにに、如何に関連が少ないことか。
 全く関連を持たないエンティティが描かれている位は、まだましな方で、全く関連が表現されていないものを「ER図です」と見せられる事すらあります。
 と言う事で、ここでは、代表的な関連を例を使って説明するに止めて置きます。
構成を表す関連
 ビジネスは、存在する資源を組み合わせて、新しい行為・出来事を形成して行きます。
 「顧客から商品を受注する」と言う具合です。
 ここで、受注は、ある顧客が、ある商品を注文すると言う概念なので、顧客と受注・商品と受注の間に、それぞれ関連が存在すると言う事になります。
 また、イベントエンティティ(この場合は受注)に対して関連するリソースエンティティ(この例の場合は顧客と商品)が、多くの場合Who(誰が)・Whwre(何処で)・What(何を)として関連しているので、本講座では、この関連を分かり易く分類するために「構成関係」と言う表現を使っています。
 なお、構成関係は、イベントエンティティの概念を説明するビジネスルールから把握可能です。
 具体的には、イベントエンティティの入力ユーザインターフェースに、関連するエンティティの識別子の入力項目が、漏れなく存在しているので、この情報から関連を把握します。
 また冒頭の「顧客から商品を受注する」などとビジネスを規定する情報をビジネスルールと言います。
 データモデルは、ビジネスルールを、単純な表記法で図表に変換することで情報の集積度を高め、ビジネスの理解・把握を容易にしたものであるとの捉え方も出来ます。
先行関係を表す関連
 行為・出来事同士の先行関係を表す関連。
 「受注した商品を配送する」と言うビジネスルールが存在する場合には、配送エンティティは先行するイベントエンティティである受注と関連があると言うことになります。
 このようなイベントエンティティ間の関係を、この講座では「先行関係」と表現しています。
 ある意味で、構成関係のバリエーションですが、この関係を追う事で、ビジネスの骨格となる流れを追う事が出来る重要な関連なので、この関連を分かり易く、強調して表現すると分かりやすいデータモデルとなります。
従属を表す関連
 良くある例では、受注と受注明細の関連。
 受注明細は単独で存在する事はなく、受注の存在を前提としており、受注の識別子を持っています。
 このように関連を辿って挿入された識別子を自らの識別子、又は識別子の一部とする場合、識別子を挿入する側に、挿入される側が従属していると言います。
 これをこの講座では「従属関係」と表現しています。
 また、エンティティの中に不定の繰り返し構造がある場合、切り出して別エンティティとしますが、切り出されたエンティティは、元エンティティの識別子を継承するので、この場合も元エンティティと切り出されたエンティティの関連は従属関係と言うことになります。

 以上の関連を押さえておけば、9割方の関連については分析可能になると思います。
 これ以上の詳細については、紙面で解説するのは困難なので、別の機会に譲りたいと思います。⇒(オンサイトセミナーなどです)

 関連を設定したら、関連する二つのエンティティのインスタンス間の対応関係を多重度として明記しなければなりません。
 多重度の表現は表記法によって様々なので、自分たちの書き方を確認して下さい。
 表現の基本は、1件だけ対応するか、複数件対応するかです。
 例えば、顧客と受注の関係では、顧客側から見ると「一人の顧客は複数受注する」と言うビジネスルールなら、顧客一人に対する受注の多重度は「複数件多能する」となります。
 逆に、受注側から見ると「1件の受注は必ず一人の顧客から行われる」と言うビジネスルールがあるなら、受注1件に対する顧客の多重度は「1件だけ対応する」となります。
 これが重なって顧客と受注の関係の多重度は、1:n(ここで、1は1件だけ対応する事を表し、nは複数件対応する事を表現しています)となります。
 時々、A:Bの関係の多重度が1:nと言う事を、Aの1件にBのn件が対応しているとか、それぞれのエンティティのインスタンス数などと誤解している場合があります。
 この場合の1は、Bの1件に対してAが1件対応する事を表す1であり、Bのn件に対応するAの1件を表している訳ではないので注意して下さい。
 1:1、n:nの関係で多重度の考え方を確認して見て下さい。
 ここを疎かにしていると「複数のクラスに複数の学生が所属する」と言うビジネスモデルでクラスと学生の多重度を「エート、クラスも複数、学生も複数だからn:nか」などとしていまいかねません。
 この多重度も、詳細については、紙面で解説するのは困難なので、別に機会に譲りたいと思います。⇒(オンサイトセミナーなどです)

 ただ、基本的にビジネスのから捕捉されたエンティティに、関連の無いものは無いので、エンティティを抽出したら、必ず1本以上の関連を設定して下さい。
 データモデルを言語に例えると(例えなくても現実に言語ですが)エンティティは名詞や動詞に当たりますが、名詞と動詞だけでは文章にはなりません。
 助詞や助動詞など、いわゆる「てにをは」を付けて文章として成立させ、ビジネスルールを表現するには、関連の設定が必須であると言うことです。
物理モデル
 関連の無い(又は少ない)データモデルを見せられると、当然ながらなぜ関連を記入していないのかを聞かなければならない。
 また、元エンティティと明細エンティティにデータ項目の重複があるとか、エンティティ内に集団項目の繰り返し構造がある場合も、当然、何故かを確認する。
 その場合、良く聞く答えが「物理モデル」だ。
 あたかも「物理モデルで設計しました」と言う文言が、理不尽な受難に対する神の救済を求める祈りの言葉の様に繰り返されるのだ。
 「では、物理モデルを描くまえの概念モデルを見せて下さい」と言うと、再度「物理モデルで設計しましたから」と、物理モデルを作っているのだから、概念モデルなど必要無いと主張する。
 どうやら、彼らの理解では、最終的にDBMSへの実装形が決まれば良いのであって、概念モデルだ論理モデルだと言うものは単なる下書きのような中間生成物に過ぎず、自分のように優秀な設計者になると(と思っているとしか思えないのだが)そのようなものを描く必要は無く、物理モデルを描く事が出来ると思っているよだ。
 頭がおかしくなりそうである。
 改めて言うまでも無く、世の中にデータベース設計をその様に説明しているものを、少なくとも私の知る限りでは見た事が無い。
 多分、自分なりにファイル設計の方法からデータベース設計と言うものを外形的類似性から演繹的に考えた結論だろう。
 と考えると、同様の情報からスタートして同じように間違った結論に大勢が辿りついていると言う、システムエンジニアの思考経路の類似性には驚くばかりだが、学習時間も世の中の情報に触れる時間も十分にあると思われる、いわゆる大手メーカーや一流ベンダーの技術者の中にもその様な例があるので、これは不勉強や実力不足と言うよりは、慢心や顧客軽視の結果と言わざるを得まい。
 データモデルは骨董では無い。
 見れば善し悪しの判断は専門家でなくても容易だ。
 その最も容易な判断基準の一つが関連の数だ。
 少なくとも関連の無いエンティティなどは無いし、関連を書いていないデータモデルなどは論外だ。
 直ちに指摘するべきだろう。
 その回答が「物理モデルで描きました」なら、直ちに技術者の交代を要求すべきである事は言うまでも無い。

 6.属性整理
  データの分類作業で、エンティティに配置すべきデータに分類されたデータ項目を、それぞれが帰属するエンティティに配置します。
 この場合、導出項目は、一律に実装すべきで無い(都度、計算で求める)とする考え方もありますが、既に、容量的制約は無くなっているので、一度導出しておけば値の変わる事が無いデータ項目については、遠慮無く実装して構わないと言うか、一度だけ導出計算を行い、値を共用データとして実装しておく方が合理的です。
 本講座では導出データのこのような性質を指して再計算可能と表現しています。
 何度、再計算しても同じ値になると言う意味で、何度、再計算しても同じ値になるのだから、一度計算した値を保持しておけば再計算の手間がなくて良いと言う考え方をしています。
 これに対して、導出を実行する度に、値が変わる可能性があるデータ項目を、再計算不能と表現しています。
 例えば、取引先の債権残金額は、受注や入金の都度、値が増減しています。
 このデータ項目は、元よりViewなので、事実を記録している取引先エンティティに属性として加える事は出来ませんが、取引先を単位とするデータ項目としては、何れかに定義しなければなりません。
 その時に、値として実装し、関連イベントが記録される都度、再計算して値を更新しておくか、導出ルールの定義のみで値は実装せず、データ要求時に導出プログラムによって、その都度計算して値を提供するかは、計算負荷とデータ項目の利用頻度によって検討することになります。
 間違っても、これらView項目をビジネスの事実を記録している部分に混入してはならないので、注意して下さい。
 不要な更新を誘発することで、データベースの安定を損なう事になってしまいます。
 なお、データ分類からエンティティの抽出・関連の設定・属性整理を通しての、いわゆるデータ分析作業に関して、把握すべき事、理解すべき事などを整理するために、普段使っており、使い方に精通し、その技法やツールを利用すると作業がはかどるようなもの(例えばDFD・UMLのある種のダイアグラム・プロセスフロー図・DMMなど)があれば、大いに利用すべきですが、分析後の成果は基本的に全てデータモデル(とリポジトリなどのデータ項目毎の定義やルールを記録する補助機能)に収斂するので、作業途上で利用した中間生成物は保管・更新の対象にはしません。
 中間生成物を保管対象、保守対象とするとなると、作成要領や、成果物の仕様を統一しなければならなくなり、任意の技法と言う訳には行かなくなります。
 あくまでも、中間生成物と位置付ければ、外形的な管理の体裁に囚われずに有効活用出来ると言う訳です。

  

 7.レビュー
  ユーザインターフェース毎の概念データモデルは、断片的なので、ビジネスの流れやビジネスルールを読み取ったり検証する事は出来ません。
 それらのレビューは少なくとも、業務別、商品別など、ある程度モデルの統合が進んだ段階で、データ分析に対して情報や資料を提供した業務の精通者を交えて行う事になります。
 しかし、多くの要員を、データ分析者として促成で作業に当たらせている場合など、思わぬ思い違いや誤解がある可能性が考えられます。
 それら誤解や思い違いの早期発見と、作業の生産性向上に向けた、再教育・追加教育内容の把握のために、ユーザインターフェース毎のデータモデル完成の都度、レビューを行う事を勧めます。
 レビューは、作業の手順や表現形式の遵守性を中心に行いますが、明らかにビジネスモデルやビジネスルールとして不自然なものについては当然確認して頂いて構いません。
 また、レビューは対面で行い、指摘事項についてその場で指摘し説明をくわえても良いし、非対面でデータモデルの内容を確認し「概念データモデルレビュー指摘事項一覧」のようなドキュメントにして、担当者に指摘事項を伝達しても良いでしょう。
 経験的に言うと、当初は対面でレビューを行い、有る程度ミスがパターン化する段階で、頻発している指摘事項をあらかじめ設定した文書での結果伝達に変えるとレビュー工数の節約になります。
 もちろん「概念データモデルレビュー指摘事項一覧」の指摘で同じミスが改善されないようなら、対面の個別指導を適宜行う必要があります。


 

 8.モデル統合
 ユーザインターフェース毎などの作業単位で、レビューを完了した概念データモデルは、機能や商品などのモデル統合単位に、統合担当者の下に集めます。
 モデル統合担当者は、集まった概念データモデルを統合しますが、ここでもイベントエンティティの登録業務を優先して作業すると、関連するリソースやイベントの前後関係などを把握し易いので、全体の配置やバランスを考慮した作業が出来ます。
 リソースエンティティの登録業務だと、リソースエンティティの箱を一つずつ描くことになるので、全体のレイアウトが決まってから行った方が良いでしょう。
 作図基準のレイアウトの遵守事項として、図全体のレイアウトの要領も規定しておき、この段階から適用しておけば、最終的な全体統合時に余計な手間を省くことが出来ます。
 如何にレイアウトすると見易いかと言う事に関しては、表現の技法や使用するツールによって違って来るので、各自の環境で検討して、作図基準に加えておく事を勧めます。
 なお、モデル統合後の元のデータモデルは廃棄します。
 以降の変更・修正は統合モデルを直接直すので、中間生成物としてのユーザインターフェース毎のデータモデルを持っていなければならない理由は無いばかりか、変更の対応やモデル修正作業を混乱させる事に成りかねません。
 また、データモデルに反映されないデータ項目に関しても、名称・定義・ルールなどを統合管理情報に移管すれば個別に情報をもっておく必要はありません。
 と言う訳で、この辺りの作業段階から、共用データを一元的に記録し、チェックアウト・チェックインと変更履歴を管理する仕組みが必要となって来ます。
 もちろんソフトウェアー製品を導入しなければならない訳では無く、仕組みとして確立されていれば良いので、規模的に運営上の問題が無ければ、登録申請書や貸出管理台帳での運用で構いません。

 蛇足ながら、リポジトリなどのソフトウェアー製品の機能は、一般的にヘビーユーザの要求に答えようとして盛りだくさんになっています。
 開発者が豊富な機能を売り物にしようと、専門家やヘビーユーザに要件を確認して開発するのだから当然です。
 しかし、多くの場合、それら機能の大部分は使う事がありません。
 世の中にはプロ用とかプロ機と称するものが存在し、その多くに、一般機・汎用機にはないスイッチやつまみが付いています。
 つまり、プロとして活動していくためには、それらスイッチやつまみの機能による差別化が必要だと言う事でしょうが、最初はみんな素人です。
 普通は、素人には素人に相応しい入門機と言う位置づけの器材が存在するものです。
 プロ機か入門機かは、スイッチやつまみの数を見れば分かると言う仕掛けです。
 ソフトウェアー製品も必要に応じて使い分けて行けば良いので、良く分からないままに、高価な製品を買ってしまったなどと言う事にならないように気を付けて下さい。
 分からなければ、最初は必要な項目を表計算ソフトで管理するだけで十分です。
 機能の必要性が実感出来てから、相応しいツールを探せば、ニーズに合ったものを見つける事が出来るでしょう。
 本来、合理化省力化が目的のビジネスシステムで、使えもしない無駄な買い物をしていたのでは「何のこっちゃ」である。

 なお、モデル統合は、当然ながら、作業単位毎の統合を経て、全体の統合へと進むことになります。
 スコープが大きな場合は、数段階に分けて統合作業を進める方が、効率が良いような気がするかも知れませんが、既存システムのファイルやデータ項目の多寡に依らず、エンティティが5〜6百、データ項目は2千項目程度(改めて言いますが、View系の導出項目はここで言うデータモデルを構成するデータ項目ではありません)に整理されるので作業単位毎のレビューが正しく行われていれば、第二段階で全体統合を行う事は、大して難しく事でもありません。
 逆に、手に負えないほどの量のエンティティやデータ項目があると言う事は、名称の統一やデータ分類などが有効に行われていない可能性が大きいので、レビュー段階では、それらの対応状況についても確認しておく必要があります。
 また、全体図が出来たら、中間のデータモデルは廃棄し、以降の変更・修正は直接全体図に反映します。
 それに伴って、変更の申請から承認・作業内容確認までの一連の手続きを明確にし、運用の仕組みを確立して下さい。
 この手続きは、データベースの初期創生から、データ移行やテストを経て、運用/保守(最近は保守の表現は敬遠され、「拡張開発」とか「エンハンス」と呼ぶのが流行りのようです)になってもそのまま使う仕組みなので、プロジェクトに従属した運営から、全社レベルの変更対応業務へと円滑に移行出来るように、事前に検討しておく必要があります。
 極端な話、委託先別、プロジェクト別に申請書を変えていたのでは、運用が複雑で堪りません。
 プロジェクトに投入された要員は、余裕が無くなるものなので、全社レベルのマネジメントシステムとして業務要件の変更申請から、データモデルの変更、データベースの変更、変更の開示公表に至る一連の手続きを、予め十分に検討しておくべきでしょう。 
モデル統合図

 データ分析は、通常分析者を動員して作業期間を短縮する。
 しかし、ユーザインターフェース毎に作られたデータモデルは、最終的に一つに統合しなければならない。
 この時に、分析能力とは別に描画のセンスが問われる事になる。
 つまり、同じ描くにも見易く理解し易い書き方と見難く理解し難い書き方があると言う事だ。
 データモデルは、開発プロジェクトの全ての後続作業の基礎資料となるので、分かり難いモデルの悪影響は計り知れない。
 そのため、最終の全体統合図を作成管理する担当者は、是非、分かりやすくデータモデルをまとめる能力を持った者を選任する事を勧める。 

 9.詳細分析
 詳細分析とは、詳細な分析です。
 例えば、商品の価格として、商品価格と得意先別商品価格が存在した場合を考えて見ます。
 通常、商品価格は商品の属性なので、商品エンティティに入れます。
 ところが、得意先別と修飾されているので、このデータ項目は、得意先と商品の両方に従属している必要があるので、商品エンティティに入れて済ます訳には行きません。
 もし、この段階までに設定されていなければ、得意先と商品の両方に関係を持つ(両方の識別子を継承する)エンティティを設け、そこに得意先別商品価格を入れる事になります。
 また、価格が商品価格と得意先別商品価格に分かれると言う事は、一般の取引先と得意先で取引金額の計算式が異なる事を意味するので、名称も同じと言う訳には行きません。
 一般の取引先が金額なら、他方は得意先金額とでもするべきでしょう。
 導出ルールが違っているにも関わらず、同じ名前を使っていては、分かり難いと言う以上に、使い分け条件を一々説明する必要があり、プロセスに負担を掛ける事に留意しなけらばなりません。
 後で説明を加えれば良い、と言うものでもありません。
 後続作業全体の使い易さや誤解・思い違いのリスクを考えれば、何れが優れたやり方か、迷う必要は無いでしょう。
 また、金額導出の使い分けが発生するので、イベント自体もサブセットに分割されることになります。
 該当のイベントエンティティが受注であれば、一般受注と得意先受注と言う訳です。
 また、当然ながら、取引先に一般と得意先の区分が存在する事も明らかなので、得意先もサブセット化され、一般と得意先に分割されることになります。
 分かり難いので図で説明します。

 このモデルを受けて、受注登録のアプリケーションは、先ず、受注には一般受注と得意先受注があるので、どちらか判断が必要だと言う事が分かります。
 そこで、得意先別商品価格に得意先の識別子と商品の識別子が存在する事を確認する必要があるので、取引先の識別子と商品の識別子が入力された段階で、得意先別商品価格をアクセスし、どちらのサブセットかを特定すると言う仕様が自明となります。
 以上、詳細分析の中心となるサブセットについて例示しました。
 サブセットは日本語では分類構造、クラス図ではサブクラスと言われる概念ですが、要するに、一つの概念だと思っているが、その中にちょっとした違いがあるものが混ざっている状況を示す表現です。
 これを綺麗に表現出来るとモデルの表現力が数段向上します。
 逆に言うと、分類構造が詳細に表現できていないと概要レベルのレイアウトでしかなくなります。
 分類構造を表現する切っ掛けは、主に、既存システムのイベント系マスタに多く含まれている、区分・種別・フラグなどの情報です。
 それごとに、エンティティの何が違っている事を表そうとしている区分・種別・フラグなのかを分析して行きます。
 詳細分析の要素は、分類構造の他にも、明細構造・再帰構造・関連エンティティなどがありますが、分析のポイントは、ビジネスで認識しているエンティティに記録されるインスタンスの性質の画一性だ。
 少なくとも、システム内の扱いが同じものをエンティティに集めているはずなので、このデータは先ず〜区分で判定して、などと言うデータをまとめているようだと、分類構造での整理を検討する必要がある。
 また、逆に気持ちが先行して意味の無い分類をしてアプリケーションに無用の負荷を掛けているケースも考えられるので要注意です。
 これは、リソース側が分類構造となっているだけで、それを受けるイベント側がスーパーセット側としか関連していない様な場合、つまり分かれた側での関連が設定されていない様な場合が当たる。
 将来を見越して、設定した区分やフラグが、意味も無く設定され続けているが、一向に使われないと言う事も、レイアウト単位でデータを読み書きしていた時代の遺物でしょう。
 必要なデータ項目は必要な時点からカラム単位で追加・変更・削除が可能となっているので、これをうまく使わない理由は何もありません。 
ビジネスルール
 ビジネスの在り方を定義・説明するルールだが、文書になっている事は少ない。
 また、アプリケーションプログラムのロジックとして隠蔽されているケースもある。
 業務分析とはこのビジネスルールを明らかにする作業だと言っても良い位だが、その大部分はデータモデルと個別データ項目の導出ルールに収斂する。
 そのため、個別データ項目の導出ルールも、当然一元管理の対象だが、当然、データモデルの中に持てる情報では無いので、データモデルに対して補助的なデータ管理機能を持つ仕組み(データーディクショナリーとかリポジトリなどと言う)が必須と成って来る。 

 10.モデル検証
   さて、データ分析手順の最後はモデルの検証です。
 最終的に全体を統合して一枚のデータモデルにまとめ、詳細分析で得たビジネスルールも反映したものを検証すると言うことになります。
 この作業自体はモデル統合時のモデル検証と言う位置づけなので、各作業単位での統合作業も全体の統合作業も同様の作業となります。
全体の配置
・リソースについては、グループが明確か、イベントについては、流れが読み取れるか
・属性の多いエンティティは無いか
・関連の無いエンティティは無いか(こんな事をチェックしなければならない様だとちょっと情けない)
 など
エンティティ
・識別子は明確か
・関連キーは明確か
・属性に初期値設定をするものはないか
・属性に値がNullになるものはないか
・ただのコード表をエンティティ扱いしていないか(但し、描画ルールによる)
 など
関連
 これは一目見て、判断出来る要素は少なく、以下に示す外形的な不備程度です。
・多重度の記述はあるか
・関連による識別子の挿入方向は正しいか
 予断だが、ここで識別子の挿入方向の意味が分からなかった方はデータベースの設計を云々する資格はありません。
 関連は、存在から行為・出来事へ、先行する行為・出来事から後続する行為・出来事へと、何が組み合わされて何になるのかと言う、ビジネスルール上の明快な方向性があり、それに逆行する識別子の挿入は出来ません。ファイル操作上は有ったとしても、概念モデルでは時間を遡る図となるので、そのような関係は成り立ちません。
 そのため、1:nの関係では1側の識別子をn側に挿入するものと思い込んでいる方にも、もデータベースの設計を云々する資格はありません。
 その理屈が理解出来ていない場合は、すぐにFMSのセミナーに申込んで下さい
・ただのコード変換を関連として扱っていないか(但し、描画ルールによる)
属性
・属性に重複は無いか
・Wive系の導出項目を属性に置いていないか
・その逆は無いか
・同じデータ項目を別名で重複させていないか(当月〜・前月〜・全前月〜・3カ月前〜・・・・など)
・無用の更新を誘発するデータ項目を安定した構造に混入していないか
 など
 簡単な例だけを示しました。
 ビジネスルールを全て含んでいるので、ビジネスルールの意味内容面からの確認も行うようにして下さい。
 多分、作成者側がモデルをビジネスルールに翻訳して業務部門の情報提供者に説明する形式を想定しているのだろうが、もともと簡単な事が取りえの表記法です。
 簡単で、文章に書く様な、裏の意味とか含みとか思い入れとかが書けない事が良い所なので、データ分析を行ってモデルを作る事は難しくても、読んで、情報を共有するだけなら大した訓練は要りません。
 今後の情報共有(何しろ、データベース導入後のビジネスルールの維持は、今までの様に、曖昧な設計書や人の頭脳ではなく、データモデルとリポジトリで管理されるのだから)を前提にすれば、業務部門の主要なキーマンにも読み方を習得させる事が無駄にまる事は無いので、一度チャレンジしてみてはどうでしょうか。
 チャレンジして失敗したらどうするかですか?
 もう一度チャレンジするに決まってます。


。 
    
 データ分析に手順に関する説明は以上です。
 汎用的に通用する考え方のポイントを中心に解説した積りですが、何しろ世の中は多様なので、ここでの指導が適切でない場合も考えられます。
 と言う訳で教条的な利用は(生兵法は)怪我の元なので、自分が理解し納得出来る範囲で活用して下さい。
 世の中は教条的な分析で足りるほど、簡単な造りにはなっていないと言う事だが、日々知恵の限りを尽くして工夫と創造を重ねているビジネスにおいては尚更であると言うことか。。 

 お疲れ様でした
学習お疲れ様でした。
 取りあえずここまで読んだと言う事は、何某かの知識がえられた事と思います。
 知識が得られないまでも、少なからず疑問が湧いたのでは無いでしょうか。
 現在のビジネスシステム開発プロジェクトに於いては、データベースの設計品質がプロジェクトの成否を決定することになります。
 よって、プロジェクトの成功を期するためには、データベース設計スキルの修得は不可欠です。
 しかし、残念ながら十分なスキルが無いまま、いや、データベースと従来のファイルの違いすら理解しないまま、無謀にも巨大プロジェクトのデータベース設計に安易に取り組むプロジェクトは多いと言わざるを得ません。
 もちろん頓挫しますが、情けない事に彼らには、その理由すら理解出来ない場合が多いのです。

 孫子の形編第二節に「勝ちを見ること、衆人の知る所に過ぎざるは、善の善なる者に非ざるなり」と言う件(「くだり」と読みます)があります。
 岩波文庫の孫子(金谷治訳注)では「勝利を読み取るのに一般の人々にも分かる〔ようなはっきりしたものについて知る〕ていどでは、最高にすぐれたものではない」と注釈しています。
 システム開発プロジェクトでは、勝ち(プロジェクトの成功)を見るのなら、衆人の知る所に過ぎなくても何の問題も無いのですが、負け(プロジェクトの失敗)に関しては、他の誰よりも早く、その予兆を察知して、予兆のままに解決する必要があります。
 即ち、予兆の内に問題の発生を察知し、顕在化する前にすでに解決しているので、善の善なる者(有能なプロジェクトマネージャー)は常に平穏なプロジェクト運営をしている様に見え、顕在化してしまった問題を、如何に工夫して解決したかと言う手柄話や、どんな努力で乗り切ったと言う苦労話とも無縁なので、却って賞賛や尊敬の対象となる事も無いと言う事です。
 賞賛や尊敬の対象となる事が無いのはちょっと残念な気もしますが、その判断の中核となるのが、データベース設計の品質に他なりません。
 つまり、現在のビジネスシステム開発プロジェクトに於いて、善の善なるプロジェクトマネージャたるには、データベース設計の能力とは言わないまでも、データベース設計の能力を見抜く能力位は不可欠だと言う事でしょう。
 同様に、委託者責任が常識化しつつある今、委託先が失敗しましたで済むと思っているユーザが居るとも思えませんが、予算とプログラムの完成本数だけを管理しているのでは、効果的な委託先管理とは言えません。
 既に、半年先の破綻が、データベース設計の中に仕込まれているかも知れないのです。
 ここでも、データベース設計の能力とは言わないまでも、データベース設計の能力を見抜く能力位は不可欠だと言う事になります。
 納品された概念モデルを見ないまま放置し、検収依頼に確認印だけ押印する、などと言う事があってはなりません。
 分かりやすい事もあり、下流の実装工程の議論は、相変わらず盛んだが、データベースの品質有ればこその話です。
 第一、気の利いた開発者なら、造りのおかしなデーテベースに疑問を持たない筈は無いでしょう。
 ここでも、データベース利用者側からの、評価の目が必要である事は言うまでもありません。
 つまり、多くのシステム関係者にとって、データベース設計は「設計担当者がやれば良い」問題では無いのです。
 君が、あなたが、私が、僕が、データベース設計を知らない事が、プロジェクトを失敗へと誘導していたとしたら、もう、データベース設計スキルの習得に躊躇も迷いもあるはずは無いし、経営者・管理者はそれを進める以外に選択肢はありません。
 失敗に原因があるように、成功にも原因があります。
 このサイトが、皆さんの次回プロジェクト成功の切っ掛けに成れば望外の喜びです。


【データベース設計基礎】オンサイトセミナー
 このサイトで説明している「データベース設計基礎講座」の内容を、大量の演習問題を経験する事で短期間に使えるスキルとして修得するセミナーをオンサイトでご提供しています。
 世に「データベース設計」を教えるセミナーは沢山ありますが、そのほとんどは、データベース設計のHowから話が始まり、設計テクニックを中心に伝えようとするものです。
 特に、特定の分析技法・表記法・分析ツール・描画ツール・RDBMSなどを前提にした研修コースは、手っ取り早く作業に入れるので人気があるようです。
 しかし、それらの研修コースは手っ取り早い半面、一定パターンから外れた場合の分析や表現の応用力が身に付き難いと言う難点があります。
 そのため、決まった環境に合わせて作業補助要員を大量動員する場合の促成教育向けには良いかも知れませんが、プロジェクトのデータモデル全体図を統合したり、スコープ全体のデータ構造を管理したり、データベースを中心に運用されるビジネスシステムを統括管理して行くデータ管理者の育成には向きません。
 オンサイトで開催される「データベース設計基礎講座」は、もちろんデータベースの基本的考え方やデータベースの在るべき姿から理解頂く事を目指しているので、データ分析/データモデリングの原理原則からご理解頂けます。
 また、厳選した演習問題と個別の徹底指導により、即戦力の分析力養成も可能なので、大量の分析作業を行う場合の担当者の促成教育にも適しています。
 もちろん、如何なる局面にもあわてる事の無い応用力が身に付くので、使用する技法やツールに関わらず、高品質のデータベース設計を行うスキル修得が出来ます。
 くれぐれも、従来のファイル設計のやり方で何とかなるのではないかなどと、見当はずれで根拠の無い自信を持つ事が無いようにお願いします。

オンサイトセミナー開催要領
開催日  オンサイト開催なので、開催日は個別に調整させて頂きます。 
 【データベース設計基礎】は、二日間(12時間)での開催となります。
 通常の二日間開催が難しい場合は、土日開催、平日夜間開催(一日3時間×4日)などの変則日程での開催も相談に応じます。
 変則日程で開催することで、既にプロジェクトに着手した後に、データベース設計力が不足だと分かった場合にも、他の作業への影響を最小限にしたスキル習得が可能です。
 データベース設計の方法を知らな良場合は、考えたからと言ってどうにかなる事ではないので、どうにもならないと気付いた時には、是非、早めにご検討下さい。
会場  【データベース設計基礎】はオンサイト開催なので、研修の場所は申込者にご用意頂く事になります。
 必要な設備は、説明用スライドを映すプロジェクターとホワイトボードのみなので、通常の会議室があれば十分です。
 データベース設計を受注したベンダーやSierの場合、話が付けば客先で場所を確保して開催すれば、別に集まる手間が無いので、時間の節約になるし、ついでにユーザの参加も促せば、その後のコニュニケーション円滑化に役立ちます。
(開催場所によっては、実費で交通費・宿泊費を申し受けます。)
 定員  1回の研修定員は10名までとさせて頂きます。
 これは、回数を増やして受講料を取ろうと言うことでは無く、演習時に個別指導出来る人数に限界があるためです。
 但し、演習の個別指導が必要無い「聴講者」の参加に制限は無いので会場に入れるだけ入って貰って構いません。
 内容  内容はこのサイトで「データベース設計手順」と「データ分析手順」として説明しているものを、詳しく解説しながら、演習問題でスキルとして定着を図ります。
 前提  前提となる知識や経験は無いので、誰でも受講が可能です。
 データベース設計=データ分析/データモデリングの修得とは、ユーザインターフェースを使った業務分析と、作図要素の意味の理解と作図ルールの修得なので、IT知識やプログラミングのスキルは必要ありません。
受講料

 受講料は1名105,000円(本体 100,000円)です。
 但し、せっかくオンサイト開催なので、6名以上の参加分は割引とし、6名以上は630,000円で一定料金とさせて頂きます。
 また、聴講者の参加は、何人参加しても頂いても無料です。

開催条件  4名からの開催となります。
 但し、スケジュールが許せば、少人数の開催希望も検討させて頂きますので、先ずはご希望の人数でご相談下さい。
 効果  平均的な実績として、このセミナー受講者の30%以上が、データ管理業務の担当可能となり、残りの受講者もデータベース設計補助者として業務を分担することが可能となります。
申込方法

株式会社エフ・エム・エスのサイトから問合せメールでお申し込み下さい。


   トップページへ