【データベース設計基礎講座】-データベース設計手順

Home > Database design process >

データベース設計手順

作業手順

　データベース設計作業は以下の手順で進める。

スコープ設定
　データベース設計の対象となるビジネスの範囲を特定する。

情報収集
　スコープ内の情報資源を収集する。

情報整理
　スコープ内の情報資源を整理する。

情報整備
　スコープ内の情報を整備する。

データ分析
　スコープ内のデータ構造を分析し概念データモデルを作る。

運用設計（並行作業）
　データベースの運用方式を設計する。

データベース創生
　概念データモデルとデータベース運用方式からデータベースを創生する。

データ移行
　現行システムデータ又は新規登録データをデータベースにロードする。

チューニング
　試験や訓練を通じて得た情報を元にチューニングを行う。

　以下、スコープ設定からデータ分析までを、手順を追って詳細に説明する。

　なお、運用設計以下の作業については、ＤＢＭＳやハードウェアー、オペレーションシステムなどの制約を受けるので、ベンダー・メーカーの教育コース受講を勧める。

スコープ設定

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

情報収集

　ボトムアップ分析を行うからには、分析対象となるデータ項目を集めなければならない。
　分析対象の量的把握は、進捗管理の上からも必須なので、データ項目の一覧表は無くてはならない。
　しかし、データ項目が一覧表になっていても、具体的なビジネスの状況を想定し難いので、実際に業務で使うユーザインターフェースとしても収集することも必要だ。
　更に、スコープ外とのデータ授受に関する電文やファイルのレイアウトの類も網羅する必要がある。
　表に、収集対象となる情報資産の例を説明する。

情報資産カテゴリ	情報資産例	目的
・データ関係	・データ項目一覧・データ項目定義書・エンティティ別データ一覧・ファイル（テーブル）別データ一覧・ユーザインターフェース別データ一覧　など	・データ分析対象の量的把握と検証・導出ルールの整備状況の把握・現行システムの冗長性の把握
・プログラム関係	・プログラム一覧・プログラム仕様書（プログラム別ファイル（テーブル）一覧）・（サブ）システム別プログラム一覧・プログラム間関連表　など	・検証・導出ルール調査時の参考情報
・ユーザインターフェース関係	・ユーザインターフェース一覧・（サブ）システム別ユーザインターフェース一覧・ユーザインターフェース定義書・ユーザインターフェースサンプル　など	・分析作業単位の設定や分析の範囲や順序の検討の参考情報

　ここでの作業は、データベース設計の中核作業となるデータ分析に使うための情報を集める事だ。
　しかし、
　一覧表は無い。
　管理表も無い。
　定義書も無い。
　サンプルも無い。
　管理部署や管理者の一覧表は組織変更前の名称や辞めた担当者が掲載されている。
　更新履歴も無い。
　あれも無い、これも無い。
　となると残るのは絶望だけだ。
　凡そ、システムの再構築を行おうと言う場合に、プロセス側から行おうが、データ側から行おうが、分析の対象とするものは現行情報資産のみである。
　どのようなプロセスがあるか、どのような機能があるか、どのようなデータ構造であるかなどについて、業務自体を分析して情報を得ようとする者は居ない。（もし居たら申し訳ない。申し訳ないが、そのやり方は非効率で不正確なので止めた方が良い）
　なぜなら、現行システムも新システムもビジネスを支援する機能を提供すると言う意味では同じなので、システムの作りや実装方法の合理化や、生産性の向上に向けた工夫などは数々あっても、支援対象が同じである限り、本質的な支援内容には変化が無いので、現行システムを分析すれば、欲しい情報が入手可能だからだ。
　そのため、本来、整備されているであろうと思われる、一覧表や定義表、管理表の類が無い、又は、整備されて無い事が分かると、大きなショックを受けると言う事だ。
　システムに対する希望・要望と言うものは、経営者・利用部門はもちろん、システム部門にもあるが、ビジネスを支援するシステムはこうでなきゃと言う情報は、長い間ビジネスを支援して来た現行システムにしか存在しない場合が多い。
　基本的に、外部の取引先や製品の利用者の事を考えると、現行機能は継承が前提なので、現行機能の把握・継承を無視して、ユーザニーズだ、経営者方針だと浮かれても、システムを作る事は難しいだろう。
　孫子も計編第一節の最後に「戦う前に、五事茄七計に従って考え、勝算が多ければ勝つし、勝算が少なければ負けるかも知れないが、勝ち目が全くないとなると話にならない。と言うふうに戦う前から情報を分析すれば勝ち負けは自ずと知れる。」と言っている。（注釈は筆者意訳）
　そう言う意味では、現行情報資産が未整備であると言う情報は、負け戦と判断するに十分な情報と言える。
　その事は事前の調査で把握し、プロクエクト劈頭で現行情報資産整備の工程を組み込むとなれば、システム開発のプロジェクトマネージメントとしては満点だろう。
　我々は、ビジネスの実態に即した支援システムを作るのであり、断片的な思いつきや、抽象的な思い入れからシステムを作っている訳ではない。

情報整理

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

情報整備

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

データ分析

　さて、分析すべき情報が揃ったら、データ分析に着手する。
　データ分析作業は、それだけで細かい段取りがあるので、取りだして別ページで説明しているので、そちらを見て欲しい。⇒データ分析手順

データ分析の後工程

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

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

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

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