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



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

 データベース設計手順
 データベース設計指南:DOA Evangelist 小見山 昌雄
 データベース設計作業は以下の手順で進めます。
1.スコープ設定
 データベース設計の対象となるビジネスの範囲を特定する。
2.情報収集
 スコープ内の情報資源を収集する。
3.情報整理
 スコープ内の情報資源を整理する。
4.情報整備
 スコープ内の情報を整備する。
5.データ分析
 スコープ内のデータ構造を分析し概念データモデルを作る。
6.運用設計(並行作業)
 データベースの運用方式を設計する。
7.データベース創生
 概念データモデルとデータベース運用方式からデータベースを創生する。
8.データ移行
 現行システムデータ又は新規登録データをデータベースにロードする。
9.チューニング
 試験や訓練を通じて得た情報を元にチューニングを行う。

 以下、スコープ設定からデータ分析までを、手順を追って詳細に説明します。
  なお、運用設計以下の作業については、DBMSやハードウェアー、オペレーションシステムなどの制約を受けるので、ベンダー・メーカーの教育コース受講を勧めます。

 前提
本講座は以下の前提で、データベース設計について説明しています。

・ビジネスシステム(最近はエンタープライズシステムと表現する事も多い)のデータベースを対象とします。
・(概念設計の段階では余り関係ありませんが)実装はRDBを前提としています。
・ボトムアップアプローチでの対応を前提としています。
・特定の技法には依存していないので、技法特有の表現が含まれていたとしても、それは偶然です。
・特定のツールに依存しているつもりは無いので、特定のツールで使われる表現や操作用語が含まれていたとしても、それは偶然です。
・特定のメーカやベンダーには依存していないので、特定のメーカーやベンダー固有の表現が使われているとしても、それは偶然の一致です。

その他の注意
 本講座の中で、説明の便宜のために、商標・登録商標となっているメーカー名・システム名・製品名を記載する事がありますが、それらの商標権の侵害を行う意志や目的はありません。
 また、特定の企業名・個人名の使用にあたっても、プライバシーの保護などについては、十分留意していますが、万が一にも不適切な表現などがあれば、宜しくご指摘下さい。

 1.スコープ設定
全社システムを一挙に再構築するので無ければ、分析範囲を特定する必要があります。
 スコープの設定は、ロケーション別(工場・関連会社ごと)、商品別(性質の違う商品・取り扱う部門や事業部ごと)、機能別(受注・在庫管理など)など、多様な切り口で可能です。
 再構築範囲を限定するのだから、当然、既存システムとのデータ関連が残ります。
 そこで、スコープ設定にも、なるべくデータの関連を最小にする工夫が必要となります。
 事前に全社を対象とした、概要レベルの概念データモデルを作成した上で、関連が極小となるスコープ設定を検討することが出来れば、最適なスコープ設定が可能となるでしょう。
 なお、スコープ全体での最終的なデータ管理の在り方によって、スコープ設定にも影響があります。
 例えば、現行システムは現状のままで、一旦全社概念モデルに従って横断的にデータを一元管理する統合デーテベースを作り、横断的分析情報を始めとする新規ニーズに対応しつつ、既存のシステム毎に処理していた管理資料や分析資料も、随時類似機能の統廃合を図りながら、新しいデータベースからの検索に置きかえる場合は、移行の単位はファイル毎・ユーザインターフェース毎になり、対応能力に応じた柔軟な計画策定が可能となります。
 このレベルで、情報システムの根幹をなす考え方や方針を、本講座では「データ管理ポリシー」と呼びますが、必要な技術を見極め、体制を整え、スキルを習得し、環境を整備し、計画的で間違いの無いシステム運営を継続的に行うためには、是非検討しておく事を勧めます。
 局面毎にベストプラクティスだと勧められた結果、混乱と不整合しか残らなかったと嘆く前に、信じられる判断力を自ら養っておくのが、CIOやシステム部門管理者の使命ではないでしょうか。

 2.情報収集
 ボトムアップ分析を行うからには、分析対象となるデータ項目を集めなければなりません。
 分析対象の量的把握は、進捗管理の上からも必須なので、データ項目の一覧表は無くてはならないので、現状を反映したものが無ければ、ここで整備する必要があります。
一覧表を整備すると言うと、一時的に作れば良いと考えるかも知れませんが、基本的には、現状の変化を反映する仕組みから整備しておかないと、イザと言う時に、その都度基本情報から調査しなければならなくなるので、生産性を下げてしまいます。
 変わった部分を反映するだけで、信頼出来る情報を継続的に維持できる管理システムの運営は、管理の基本なので、もし、そのような基本的管理機能が整備されていなければ、なるべき早い機会に体制を整える事を勧めます。
 しかし、データ項目が一覧表になっていてもビジネスの状況を想定し難いので、加えて具体的なユーザインターフェースのサンプルや設計書も収集する必要もあります。
 更に、スコープ外とのデータ授受に関する電文やファイルのレイアウトの類も、忘れず網羅する必要があります。
 ここでの作業は、データベース設計の中核作業となるデータ分析に使うための情報の収集です。
 しかし、
 一覧表は無い。
 管理表も無い。
 定義書も無い。
 設計書も無い。
 サンプルも無い。
 管理部署や管理者の一覧表は組織変更前の名称や辞めた担当者が掲載されている。
 更新履歴も無い。
 あれも無い、これも無い。
 となると残るのは絶望だけと言う事になってしまいます。
 凡そ、システムの再構築を行おうと言う場合に、プロセス側から行おうが、データ側から行おうが、分析の対象とするものは、現行システムの情報資産が中心となります。
 どのようなプロセスがあるか、どのような機能があるか、どのようなデータ構造であるかなどについて、業務自体を分析して情報を得ようとする者は居ません。(もし居たら申し訳ない。申し訳ないが、そのやり方は非効率で不正確なので止めた方が良いと思います)
 なぜなら、現行システムも新システムも、ビジネスを支援する機能を提供すると言う意味では同じなので、システムの作りや実装方法の合理化や、生産性の向上に向けた工夫などは数々あっても、支援対象が同じである限り、本質的な支援内容には違いが無いので、現行システムを分析すれば、欲しい情報が入手可能だからです。
 そのため、本来、整備されているであろうと思われる、一覧表や定義表、管理表の類が無い、又は、整備されて無い事が分かると、大きなショックを受けることになります。
 因みに、それが経営会議でコストや期間の見込みについての決裁を受けた後だと、話はややこしくなってしまいます。⇒(「そんな馬鹿な事あるか」と憤られた方、あなたの会社のITガバナンスは健全です。)
 システムに対する希望・要望と言うものは、経営者・利用部門はもちろん、システム部門にもありますが、ビジネスを支援するシステムはこうでなきゃと言う現行ビジネスを如何に支援して来たかと言う情報は、長い間ビジネスを支援して来た現行システムにしか存在しません。
 基本的に、外部の取引先や製品の利用者の事を考えると、現行機能は継承が前提なので、現行機能の把握・継承を無視して、ユーザニーズだ、経営者方針だと浮かれても、システムを作る事は難しいだろう事は容易にご理解頂けると思います。
 孫子も計編第一節の最後に「戦う前に、五事茄七計に従って考え、勝算が多ければ勝つし、勝算が少なければ負けるかも知れないが、勝ち目が全くないとなると話にならない。と言うふうに戦う前から情報を分析すれば勝ち負けは自ずと知れる。」と言っています。(筆者意訳)
 そう言う意味では、現行情報資産が未整備であると言う情報は、負け戦と判断するに十分な情報と言っても問題無いでしょう。
 その事が事前の調査で把握されれば、プロクエクト劈頭(又は事前に別の整備プロジェクトとして分離)で現行情報資産整備の工程を組み込めば、システム開発のプロジェクトマネージメントとしては満点と言えるでしょう。
 我々は、ビジネスの実態に即した支援システムを作るのであり、断片的な思いつきや、抽象的な思い入れからシステムを作っている訳ではないと言う事に気を付けて、十分な情報収集を心がけましょう。

 3.情報整理
 収集した情報資産を整理します。
 整理とは、データ項目、ユーザインターフェース、管理部署、入力部署、関連プロセスなど、収集した情報のリストを作り(もちろん、リストに沿って収集する、又は、リストと共に管理されている状況が理想ですが)相互の関連を明確にすることです。
 例えば、取引入力画面と画面に表示されているデータ項目の関係は、入力(外部からの入力)・検索(入力された情報を基にシステム内から検索)・導出(入力または検索された情報から導出)の区別があり、それらを把握することは、データ分析に大いに参考になります。
 また、取引入力画面は各支店の営業部門が操作を担当しており、その管理は本社営業統括部で行っている(つまり、当該画面とそれら部署は入力部署・管理部署と言う関係にある)ことが情報として把握されていれば、不明点や要望事項の確認先や聴取先が特定されるので、どこで情報収集すれば良いかを個別に調査する手間が掛りません。
 その程度の事なら、個別のデータ項目やユーザインターフェースの定義書辺りに書いてあるだろうと思っていませんか。
 確かに書いてあるかも知れませんが、データ項目一件、ユーザインターフェース一つ毎に確認先を探して聞きに行くと言う訳には行きません。
 そんなことをしていては、3件目辺りで相手にされなくなるのは目に見えています。
 少なくとも、部署ごとに数量を確定し、担当者を選任して頂いて、予め質問票を渡した上で、聴取の日程調整をする位の段取りはしなくてはエンジニアどころか、社会人として失格です。
 と言う訳で、他にも有用な情報が有るかもしれませんが、前述の情報に関しては一覧表にリストアップした上で相互の関連を明確にしておく必要があります。
 なお、ここで現行システムでの実装情報との関連付けをしておけば、データ移行で調査の手間が無くなるのでお勧めですが、現行システムのデータは冗長で代表を容易に決められない可能性もあるので新たな課題となる場合もあります。⇒最終的にはどこかで調査しなければならない事なので、早めに把握して計画的な調査を行う事を勧めます。
 現行調査は,必要で避けて通れませんが、地味で後ろ向きなイメージが付きまとうので、あまり時間が掛るようなら、データ分析を優先しつつ並行作業を行うなどの方法で、目標とする成果物を具体的にする事で、プロジェクトの士気を維持・向上する配慮も必要となって来ます。

 4.情報整備
作業に着手して見て、自分の読みの甘さを痛感する事は、残念ながら良くある事です。
 何度も見込み違いを経験したお陰で、私は実際に計らないものを想像で補う事はしません。
 例えば、前工程の作業について言えば、現行情報資産の管理状況によって、大きく作業負荷が変わって来ます。
 そのような場合には、必ずサンプルを収集し確認する必要があります。
 確認して、現行情報資産の管理状況が悪い場合に発生するのが本工程と言う事になります。
 例えば、ユーザインターフェースのサンプルを収集したとしても、該当スコープの全ユーザインターフェースを一覧表などで確認する手だてが無ければ、集めたものがどの程度の量なのか分かりません。
 例えば、ユーザインターフェースが2,000あるシステムで、100件程度の情報を集めただけでは話に成りません。
 分からないでは計画も立たないので、他の情報から整理するとか、実物を確認するとかで、仮にせよ全体を把握する情報を整えなければなりません。
 それがこの工程だと言うことです。
 情報を整理して見たら、使い物にならないので整備するのか、使い物にならないので、整備して整理するのかは、見かけの程度によりますが、情報整備を実施する場合は情報整理とセット作業となります。
 最悪なのは、本当に情報整理に着手して見て、見かけの情報が実態と遊離している事が判明する場合です。
 工数的にも日程的にも取り返しがつかない場合が多いのでプロジェクトそのものが頓挫してしまいます。
 見た目に麗しい一覧表であっても、記載内容が本当に実態とマッチしているか、サンプルチェックをやる位は大した手間では無いので、念のために確認をする事を勧めます。

 5.データ分析
さて、分析すべき情報が揃ったら、いよいよデータ分析に着手することになります。
 データ分析作業は、それだけで細かい段取りがあるので、取りだして説明しているので、そちらを見て下さい。⇒データ分析手順

 6.データ分析の後工程
データベースを中心に構築しようとするビジネスシステムにとって、データベースの設計が出来たと言う事は、
1.入力系アプリケーションの設計と開発
(出力系アプリケーションの仕様は、なかなか決まらないものなので、その作業の成果を待ったり、当てにしていません。 最後の最後、心行くまで検討していて構いません。⇒データ分析はあくまでも既存システムベースで進めており、もし追加すべき情報が出た場合は、後で追加するが、現行システムを馬鹿にしてはいけません。 現場の継続的な努力でほとんどの場合、ビジネスに必要なデータは最大限に収集されています。 つまり、同じビジネスに関するビジネスシステムを作っている限りでは、新システムを作りますと言って、新たに収集可能となるデータは基本的には無いと考えても問題無いでしょう。 二次導出する導出項目は、色々な視点・観点が加わる事で大量発生が予想されます、それがエンティティや関連など、データベース設計部分に影響する事はありません。)
2.データ移行の設計と移行の実施
3.データベースの初期設定
4.テストデータの設定
 が着手可能になったと言う事です。
 この中で何を措いても優先すべきは2です。
 理由は明白です。
 他の作業は単なる作業に過ぎませんが、データ移行の設計は、検討すべき事が残っています。
 例えば、漠然と正月休みに一斉移行で何とかしようと考えていたとして、仮プログラムを作ってパイロットテストを行った結果、全データを移行するには20日必要だと分かった段階で、移行方式から見直す必要が発生してしまいます。
 もっとも、最初からデータ移行・並行運用・運用切替の段取りで考えていれば問題無いのですが。
 また、2が順調に進めば、先にデータ移行を済まし、並行運用中のデータベースで試験を行う事も可能です。
 むしろ、単体テストからテストデータを提供できるタイミングで移行を先行して完了出来れば、アプリケーションの品質向上に、計り知れない効果をもたらすことにるので、データベースを活かすためには、是非、移行先行のアプローチをお勧めします。
   トップページへ