シス開発：使いやすいデータベースの構築法 |
データベースを構築するには、設計以外に、分析やテストなどいろいろな作業が必要となる。慣れた設計者なら、自分独自の作業手順を持っているが、そうでない人は何をどうしたらよいのか迷いがちだ。そこで、標準的な作業手順を用意してみた。本格的な手順を簡素化したものなので、初心者には難しいかも知れないが、構築を失敗しないためにも、できるだけ守ったほうがよい。最初のうちはこれを参考にして、慣れてきたら自分なりに修正を加えるとよいだろう。
データベースを使う人が、データベースを構築する技術を持っているなら、ニーズから外れたデータベースが出来上がることはない。しかし現実には、使用者がデータベース技術を持っておらず、別な人が設計する場合がほとんどだ。すると、どんなシステムを求めているのか、設計者は調査して分析する必要がある。このことが、問題を難しくする。
もう１つの問題点は、使用者の知識と意見だけでは不十分な点だ。データベース化によって、手作業とは異なるメリットが生まれる。手作業では不可能な新しい機能を加えることが多く、それを十分に考慮してシステムを設計しなければならない。ところが、コンピュータやデータベースの特徴を理解していない使用者だと、現在の作業をそのままデータベース化する傾向が強い。それでは、十分なメリットが得られない。
設計者に必要なのは、対象となる業界の知識も十分に入手して、業界の数年後を見つめ、より高いレベルからシステムを捉える視点だ。使用者の意見と業界の方向を天秤に掛け、適切な判断をしなければならない。だたし、使用者の要望を無視しすぎると、出来上がったときに使ってもらえない心配もある。非常に厄介な点だ。良いシステムを構築するためには、使用者の意識を高める努力も必要とされる。
以上のように、使用者とは別な人が設計するのに加え、使用者の意見だけで決められないからこそ、構築の作業は大変になる。ここで紹介する手順は、データベースを使う人ではなく、別な人が設計することを前提としている。そのため、分析や確認などの作業も含めた。
自分が使うデータベースでも、ある程度以上の規模になると、きちんとした分析を事前にしたほうがよい。システム全体の構造が単純ではないため、データベース全体を整理する意味から、分析は必須である。より良いシステムを構築したいなら、自分用でも他人用でも、マトモな作業手順を採用して、分析から始めたほうがよい。
ここで紹介する手順の基本的な考え方は、最初にきちんと業務を分析し、それをもとにシステムを設計して、システムの細かな仕様を固めてからデータベースを作り始めることだ（表１）。設計した内容が良いかどうかを判断するためには、途中の各段階で仕様を書類として記述しなければならない。書類を残すと、きちんとしたレビューが可能であり、別な人にバトンタッチするときも比較的容易である。データベースを更新するのが、最初に作った人だとは限らないので、できるだけ親切に書いておきたい。
対象業務を詳しく調べない段階から、データベース・ソフトを動かして作り始める方法こそ、悪いものができあがる大きな原因だ。分析を十分せずに作り始めると、手直しが何度も発生して、結局は非効率的でもある。加えて、内部的な構造もだんだんと崩れ、信頼性も低くなりやすい。業務分析や設計が終わるまで作り始めないことは、大原則といえるほど大切だ。
表１、ここで紹介する手順のもとになる考え方。各段階がきちんと終わってから、次の段階へと進む。
分析段階：業務をきちんと分析 ↓（業務分析が終わってから設計を始める） 設計段階：業務分析を参考に設計 ↓（設計が終わってから作り始める） 作成段階：データベース・ソフトを用いて作成 ↓（作成がひととおり終わったら本格的にテスト） テスト段階：設計どおり動くかを確認 ↓（きちんとテストしてから実際に使い始める） 本番移行段階：入念に準備して本番を開始
注：システム開発では、実際に使うことを本番と表現する。本番以外はテストと呼び、テストから本番へと移行する。
データベースの構築手順は、最初の分析から立ち上げまでを含めた（図２）。本格的な手順を簡素化したものなので、きちんとした作業手順になっている。実際に経験しなければ気付かない注意点を重視して、手順を作ってある。これに準じることで、使い物にならないデータベースを作る可能性や、実際に使うまでのトラブルを、ある程度減らせる。絶対的な解決方法ではないが、自分なりの方法を身に付けていない人には参考になるはずだ。
表２、お勧めのデータベース構築手順。良いデータベースを効率的に作るためのもの。
作業の段階 作業ステップ 分析 １、業務の内容を分析して、ニーズをまとめる ２、業務分析の結果から、データ構造をまとめる 設計 ３、実現すべきシステムの構造を設計する ４、データベースのデータ構造を設計する ５、画面や印刷のレイアウトを設計する ６、細かな加工＆検査処理を設計する 作成 ７、データベースのフィールドを定義する ８、画面や印刷のレイアウトを作成する ９、切り替えや加工のプロシージャを加える 10、バックアップやリカバリー処理を作成する テスト 11、仕様どおり動くのか、動作確認テスト 12、実際のデータを用いた本番前のテスト 本番移行 13、本番移行に向けて、データを用意する 14、問題がないか観察しながら使い始める 15、出た問題点を解消し、通常の業務に組み込む
続けて、各ステップの内容を簡単に解説する。
どのような業務のデータベースを構築する場合でも、一番最初に行うのが業務分析。対象となる業務で、どんなデータを扱い、どのように処理するのかを詳しく調べる作業だ。その結果が適切でないと、役立つデータベースは構築できない。
よく起こりがちな失敗は、きちんと分析せずにデータベース・ソフトで作り始めるケース。作りながら考えようとするが、分析せずに作成した内容では、間違っていることが多い。大きく変更するのはイヤなので、小手先の手直しで済まそうとする。結果として、目的から外れたデータベースになりがちだ。また、何度も手直しするので、システム全体の構造も汚くなる。この種の失敗は、実はかなり多い。こんな失敗を起こさないためにも、ソフトで作り始める前に、業務分析は必ず実施したい。
どんな業務をデータベース化するのかに加えて、本当の目的を明確化することも重要である。在庫管理のデータベースを作るとしても、作業の省力化を求めるだけとは限らない。より良い経営のために、在庫数の半減を狙うこともあるだろう。目的が異なると、求められるデータベースの姿はまったく違う。さらに、目的によっては、業務分析として調べる範囲も変わる。そのため、業務分析を始める前に、本当の目的を明確に設定する。
業務を分析している段階で、最初に考えもしなかった良い目的が分かることもある。その場合には、途中で目的を変更しても構わない。業務を調べる人が、その分野に詳しくなければ、よく起こることだからだ。その意味から、目的が定まっていないときは、目的を確定するための調査を先に実施する。その際に重要なのは、業務に関係する分野が、今後５年か10年の間にどのような変化をするのか見極めることだ。
業務分析では、項目の種類だけでなく、データの量も調査する。どの項目が何件ぐらいあるのか、だいたいの数を求める。また、データベースを使用する人数や、アクセスする頻度なども調べる。これらの結果は、データベース・ソフトやマシン環境を選択に役立てる。レコード件数やアクセス件数が多い場合は、応答速度が低下するので、より高速なマシンを用意しなければならない。
業務分析の結果から、データ分析としてデータ構造を明確化する。データ分析は業務分析の一部だが、データベースに限った開発の話なので、あえて手順を分けた。
業務分析で作成する資料だが、これといって決まった書式はない。業務の流れ図を加えるなど、自由に作っているのが現状だ。大事なのは調べる項目なので、以下に列挙してみた（表３）。これを参考にしてほしい。
表３、業務分析で明らかにすべき内容の一覧。作業や項目を論理的に分解して整理するのが目的。
システムの目的 ・一番重要な目的
・現状の問題点と、期待される効果業務上の作業 ・現在行っている全部の作業の洗い出し（管理者の作業も含む）
・作業ごとの目的、実施担当者、扱うデータ
・作業ごとの実施時期や頻度
・各作業の関連性（実行順序も含む）例外処理 ・作業ごとの例外処理の洗い出し
・例外処理の内容と対処方法業務で扱う帳票 ・現在使っている全部の帳票
・帳票ごとの目的と記述内容関連する他の業務 ・業務ごとの相手部署と関連の内容
・どんなデータをやり取りするか扱うデータの種類 ・扱う全データの意味、実際の値、件数
・記入時のチェック内容
・承認の必要性と承認担当者業務内容の整理 ・システム化する業務の範囲
・業務担当者を中心にして、作業の流れを整理
・データを中心にして、物や情報の流れを整理
業務分析が終わったら、設計に移る（表４）。まず最初は、作成するシステム全体での基本構造を決める。入力と表示と印刷の各画面を基本要素とし、それらを階層的に関連づける方法が、比較的やりやすいだろう。加えて、どの画面からどの画面へ移動できたら使いやすいかを考えて、画面切り替えのルートも決める。得られた基本構造は階層的な図として描き、画面切り替えの方向は矢印として加える（図１）。画面切り替えの矢印が多くなる場合は、階層構造と一致しない切り替えだけを、もう１枚の図に分けてまとめる。
表４、設計段階で決めるべき内容の一例。全体の構成や画面レイアウトなど、すべてを細かく規定する。
全体の構成 ・画面の構成（ヘルプなども含む）
・画面間の切り替え画面レイアウト ・レイアウト内容と項目
・ボタンごとに対応する処理
・対応する業務上の作業印刷レイアウト ・レイアウト内容と項目 データ構造 ・正規化した基本となる表
・項目の意味、属性、値の範囲
・項目間の関連
・画面ごとの論理演算処理 ・処理内容の正確な定義
・チェック内容の正確な定義
図１、全画面の関連を階層構想として図で描く。画面切り替えの方向も、矢印で加える。
どのような画面が必要かは、業務上の作業と関連づけることで分かる。作業ごとに専用の画面を用意するのが理想だが、作るのは大変なので、似たような情報を扱う作業では、画面を共通化するのが一般的だ。業務ややりにくくならない範囲内で、画面の共通化を考える。洗い出した全作業に画面や印刷レイアウトを割り当てられるまで、画面を追加する。１つの作業で、複数の画面を用いることもあるため、作業の目的を考えながら、必要な画面を洗い出す。なお、作業用の画面に加えて、メニューやヘルプ、メンテナンス用の画面も用意する（表５）。
表５、一般的に用意すべきレイアウトの一覧。これを満たせば、一定レベルの機能を確保できる。
入力用 ・データの入力と更新（データの種類分） 表示用 ・個別表示（データの種類分）
・一覧表示（必要な用途分）
・検索条件設定（必要な条件分）
・入力確認表示（１日分など必要な種類分）印刷用 ・一覧表（必要な用途分）
・ラベル印刷
・入力記録の保存［１日分の入力内容を紙で保存］その他の一般処理用 ・メニュー、サブメニュー
・ヘルプ
・いろいろな特殊処理［他のソフトとのデータ交換など］メンテナンス用 ・全項目の入力と更新［更新日付なども含む］
・全項目の一覧表示
次は、データベースのデータ構造を設計する。データ分析がきちんとできていれば、比較的容易な作業だ。リレーショナル型では、まず基本となる表を規定する。それから、各画面ごとの必要な項目を洗い出し、それを表から生成するために、どのような演算が必要かを求める。これは、処理を作成するために必要な情報だが、データ構造が間違ってないかを確認するために、この段階で調べるわけだ。
データベース・ソフトの選択も設計の一部であり、業務分析の結果を参考にして、設計の初期段階で決める。他の業務で利用しているソフトを選ぶのが、一般的だ。リレーショナル型であれば、多くの業務に適応できる。
データ構造が定まったら、画面や印刷のレイアウトを設計する。どの項目が必要かは分かっているので、それを見やすいように並べる。入力や表示のレイアウトでは、画面切り替えのボタンを忘れずに付ける。この段階でレイアウト上に描くボタンは、単純な四角で構わない。その中に文字を入れて、ボタンの機能を示せば、役割は十分に伝わる。
設計した画面および印刷のレイアウトは、業務の担当者やデータベースの使用者に見てもらう。項目に漏れがないかや、画面や印刷のレイアウトが不足していないかどうかを、確認するわけだ。実際の作業と関連づけながら確かめると、機能の不足を発見しやすい。
業務上の例外処理を洗い出し忘れてないか、この段階でも再度確認を求める。どんな例外処理があるか尋ねても、なかなか出てこない。用意した画面ごとに、関連する作業上での過去のトラブルを尋ねると、例外処理を引き出しやすい。例外処理に関しては、業務分析の段階で洗い出しているはずだが、全部を拾い上げられることはまれだ。全部の例外処理を一度に思い出すのは難しく、何度も尋ねることで、より多くの例外処理を見付け出せる。画面を見ながらのほうが、例外処理を思い出しやすいので、この段階で尋ねるわけだ。この時点で見付かったほうが、データベースを作り終わってから見付かるよりも、修正の作業量ははるかに小さい。
設計の最後では、検査や加工の処理を規定する。これも、画面や印刷のレイアウトと関連づけてまとめると考えやすい。データの検査は入力画面に、表示だけで必要な加工は表示画面に、という具合にだ。もし共通の処理がある場合は、処理を別紙にまとめて、各画面から参照する形で記述する。
画面設計とは別に、運用面から見た作業の流れも作成する。データの登録といった、複数の画面を使った一連の作業を、作業別に洗い出して整理する。必要な画面の不足が発見できるなど、別な確度からシステムを検証する手助けとなる。
業務分析の結果にある程度の自信があり、データベースの構築に慣れているなら、最初からデータベースソフトを用いても構わない。仮のフィールドを定義し、次に画面レイアウトや印刷レイアウトを作る。それを印刷して見せることで、内容の確認ができる。業務分析が正しいほど後で修正する部分が少ないので、直す手間は最小限で済む。ここでのフィールド定義も、あとで修正しなくて済むように、できるだけきちんと作る。
業務分析が上手になると、複雑な業務でない限り、修正はあまり発生しない。最初のうちは、どんな部分で直しが求められるのか、よく観察するとよいだろう。
ただし、このような方法が使えるのは、データベースの規模が小さいときだけだ。大きな業務をデータベース化するときは、設計作業が終わるまで、データベース・ソフトを使わないほうがよい。
構築するシステムの仕様が固まったら、いよいよデータベース・ソフトの出番だ。データ構造の設計結果をもとに、フィールドを定義する。フィールドごとに、データのタイプ、値の範囲、計算式、入力値の自動生成ルールなどを設定する。
次は、画面レイアウトの作成だ。メニューや表示など、本コーナーの別ページで解説した工夫を盛り込みながら、使いやすい表示内容に仕上げる。画面上のボタンは正式なものを付けるが、ヘルプの説明文などは、あとから入力するように枠だけを用意する。ある程度できあがって、実際に使ってみてから書いたほうが、ヘルプの内容が良くなるからだ。
入力と表示の違いを色やデザインで明確に区別するなら、そのルールを事前に決めておく必要がある。会社全体でルールを統一したほうが良いので、関係部署と協議しながら標準ルールを決める。一度決まると、それに従えばよいので、作成時点では悩まずに済む。
レイアウトができあがったら、ボタンに処理を加える。プロシージャを用いて、入力データのチェックやデータの加工などを作る。作成するプロシージャには、処理内容を説明した詳しいコメントを付けておく。たとえ自分が修正する場合でも、後で必ず役に立つからだ。
プロシージャもプログラムなので、デバッグが必要。簡単なテストは、作成しながら行なう。本格的なテストまでには、単純なバグをなくしておきたい。
データベース本体だけでなく、バックアップやリカバリーの処理も、実際のシステムには必要だ。データベース本体ができたら、それに合わせてバックアップの手順やツールを用意する。実際の運用を考慮しながら、手間をできるだけ省ける形で作成する。
バックアップやリカバリーの処理では、誤った操作でデータを失わないように設計する必要がある。バックアップ媒体をロックするとか、重要な注意点も含めて、初心者でも間違わないような手順書を用意する。処理内容を作るというより、手順を作るといった気持ちで取り組んだほうがよい。
作成したデータベースは、実際に使い始める前に、ひととおりのテストを実施する。テストは２段階あり、最初は仕様どおり動くかの動作確認テストで、次が実際のデータを用いた実データ・テスト。どちらのテストも、データベースの作成者とは異なる人が実施すべきである。作成者自身が行うと、どうしてもテストが甘くなるからだ。
動作確認テストは、仕様書に記載したとおりに動くかどうかを確かめるのが目的である（表６）。データベースの設定ミスやプロシージャのバグなどを発見する。テストに用いるデータは、仕様を見て作成する。たとえば、入力の金額チェックで５万円以上をエラーにする処理があった場合、４万9999円のデータと、５万円のデータを用意する。４万9999円がエラーにならず、５万円がエラーになることを確認する。このように、作成した処理が仕様で定められたとおり動くかどうか、１つずつ確かめられるように、テスト用のデータを用意する。入力のテストでは、入力する項目を事前に整理しておき、それを見ながらタイプする。例外処理を数多く組み込んであるほど、テストすべき項目が増えるため、作業は大変だ。それでも、使い始めてからトラブルが発生するよりは良いので、面倒でもきちんとテストしたい。
表６、代表的なテスト内容。実現する仕様によって大きく違うので、設計仕様書を見ながらテスト内容を設計すべき。
画面切り替え ・指定した画面に切り替わるか 入力のチェック ・入力した内容が記録されるか
・自動入力の項目が、正しく入力されるか
・エラーを発見できるか
・正しいデータをエラーにしないか
・エラーを発見したときの表示データ加工 ・仕様どおりの処理が行われているか
・条件付きの処理が正しく動くか
・処理内でのエラー検出とエラー表示が正しく動くか一覧表 ・指定した順序で並んでいるか
・予定した長さのデータが、オシリまで表示できるか印刷 ・指定した順序で並んでいるか
・予定した長さのデータが、オシリまで印刷できるか
・予定した用紙サイズに、きっちりと収まるかバックアップとリカバリ ・手順書どおりにバックアップできるか
・バックアップからデータを修復できるか
テストで見付かったバグの修正は、データベース作成者の仕事だ。重要なバグを優先的に直し、正しく修正できたかどうか再びテストして確認する。テストの回数を減らす意味から、ある程度のバグをまとめて直し、テストへ回したほうがよい。
重要なバグを優先するのは、そのようなバグの修正は別なバグを生みやすいから。優先して直すことで、新たなバグの発生を前倒しでき、テスト期間の短縮につながる。
用意した全テストでバグが発見されなくなったら、テストを終わりにする。例外として、運用開始までに時間がない場合には、軽いバグを残したまま次へ進むことがある。その場合でも、できる限り早目に修正して、本番開始までに解消しておきたい。
動作確認テストがひととおり終わったら、実データ・テストに移る。実際のデータを用いて、正しく動くかどうか確かめる。ここでは、実際の業務に合わせてテストを進める。新規データを登録するなど、すべての機能を試す。
この段階では、正しい動作の確認に加え、使いやすいかどうかも見極める。使いやすさに関して気付いた点を何でも記録する。どんな小さなことでも記録するが、そのすべてを修正するわけではない。本当に使いにくい部分や、簡単に修正できる部分だけを修正する。残った使いにくい点は、半年後や１年後などにまとめて大きく改良するのが、一般的だ。もし時間や工数に余裕があるなら、使いにくい点を全部直しても構わない。
忘れてならないのが、バックアップやリカバリーのテスト。非常に大切な処理なので、正しく動くかどうか細かくチェックする。実際に行う人が間違いそうだとか、少しでも不安に感じた点は、できるだけ改良したほうがよい。
通常の操作でもバックアップでも、使用者向けの手順書を用意する。ヘルプとしてデータベースに組み込んでも構わない。これらの内容が適切かどうかも、使用者と一緒に確かめる。分かりづらい部分が見つかったなら、この段階で修正する。
テストが終わったら、本当に使うための準備作業に移る（表７）。たいていのデータベースでは、作り終わってすぐに本番で使い始められるわけではない。商品や取引先などのデータを事前に入力しなければ、使いものにならないからだ。また、過去の全データを入れておかないと、役に立たないデータベースもある。これらのデータは、実際に使い始める前に入力しておく。難しいのは、新しいデータが毎日発生する場合だ。使い始める段階で追いつけるようなスケジュールを組み、事前に段々と入力していくとか、本番移行直前にデータを移すなどの処理を用意する。
本番で用いるマシンの環境整備も忘れてはならない。接続する機器は、すべて動作を確認する。バックアップ用のディスクなども、その場で慌てないように事前に用意する。ディスクには必ずラベルを貼り付けて、何の目的で使用するのかを明確にしておく。
本番のマシンが他で使われていたものなら、システム・ソフトウェアやデータベース・ソフトをインストールし直す。システム・ソフトウェアが壊れていてトラブルが発生したなんて、笑い話にもならない。関係のない原因で無駄な時間をとられないように、間違いが起こりにくい条件を可能な限り整える。
表７、本番移行前に準備すべき内容。入念な準備が、本番でのトラブルを防止する。
マスターなど過去のデータの入力 ・データの値と件数で確認
・入力したデータはバックアップしておく使用説明書 ・使用者が調べられるように マシンなどハード環境の整備 ・正しく動くかを確かめる
・OSやアプリケーションの再インストールバックアップやリカバリーの試験 ・メディアを用意して実際に試す ネットワークでのアクセス ・他のマシンからアクセスできるかを確認
・アクセス制限は正しく設定されているかトラブル発生時の対処を決めておく ・中止の条件、中止した場合の作業方法、など
ひととおりの準備が終わったら、基本的な機能を動かしてみる。とくにバックアップやリカバリーの作業は、使っている環境が変わると正常に動かないことがよくある。実際に使う環境で試しておかないと、安心できない。必ず動作確認すべきだ。
このような準備を経て、ようやく本番で使い始める。どんなトラブルが発生するか予想できないため、細かく観察しながら作業を見守る。また、きちんと動いていることを確かめる意味から、途中で作業を中断してもらい、入力したデータを調べたりする。どの部分を調べたらよいのか事前に整理しておくと、スムーズに作業できる。
使用者の質問や意見は、今後の改良のネタになるので、忘れないようにメモする。重要な問題点を優先して、できるだけ早目に解消する。新たなバグを誘発しそうな修正は、前のテスト段階をやり直してから組み込む。
明らかになった問題の中には、データベース側で解決できないものもある。人間側の作業の運用ルールを変えるなど、いろいろな方法を検討して解決する。この種の問題は、実際の運用を十分に考慮せずに設計したデータベースで起こりやすい。この時点で大きな問題が出るのは、設計者としてレベルが低いことを意味する（例外として、設計者が優秀でも、業務担当者が相当にいい加減なら起こりうる。きちんとした分析が達成できないからだ。このような状況は、対処するのが非常に難しい）。
本番で大きなトラブルが発生した場合、手作業に戻すこともあり得る。そのときに混乱しないよう、手作業に戻す条件や手順を、事前に決めておくのがベストだ。準備が十分であれば、大きなトラブルは起こりにくいだろう。
良いデータベースを作成して、スムーズに立ち上げる作業は、残念なことに簡単ではない。最初の分析から本番移行までの間に、人間関係も含めて、いろいろなことが起こる。コンピュータ化するのを快く思わない人がいれば、露骨に邪魔されることもある。そんな状況でも構築しなければならず、大変な仕事なのだ。
ここで示した手順を参考にすれば、実際の構築での苦労を少しは軽減できる。データベース・ソフトの使い方やプログラミングの基礎は単行本やマニュアルで勉強するとして、それ以外の設計ノウハウや運用ノウハウは、本コーナーの別ページを参考にしてほしい。ひととおりマスターすれば、どんなデータベース・ソフトを使う場合にも、きっと役立つはずだ。
（1998年３月17日）
良いシステムを効率的に作れる構築手順 |
