「データ」と「データベース」。人に例えるなら、データは「血液」であり、それをコントロールするデータベースは「心臓」に当たると思います。システムの目的は「データを蓄積し活用すること」。無駄なく漏れなくデータを活用するためには、安定して無駄のない心臓は欠かせません。

ファイル形式の選択

1件以上のデータが含まれるものを「ファイル」と呼び、その形式は「シーケンシャルファイル」か「データベース（インデックス付き）ファイル」に分けられます。

「シーケンシャルファイル」とは、一般的なベタ打ちデータです。例えば、「名前＋郵便番号＋住所＋電話番号」の情報を、１人につき１行ずつ書き出します。見やすいように各項目の打ち出し位置を揃えて出来上がり。この住所ファイルの形式が「シーケンシャルファイル」と呼ばれます。基本的な使い方は、1行目から最終行まで順次読み込んで処理を行ないます。

「データベースファイル」は、「シーケンシャルファイル」に検索用のキー情報を付加したものです。ファイルイメージは「シーケンシャルファイル」と同様ですが、使い方はキー項目を指定した限定読み込みです。

何れのファイル形式を選択すべきか？その判断条件は「オンライン処理で使うなら、データベースファイル形式」です。「データベースファイル」の方が機能上位だからといって、なんでもかんでも「データベースファイル」を使うわけではありません。バッチ処理では「シーケンシャルファイル」が主に使われます（大量データの処理に有効）。適材適所、ファイル形式を使い分けることが大事ですね。

データベースの種類

「ネットワーク型データベース」や「階層（ツリー）型データベース」は長年、ホストコンピュータやオフコン上でのデータベースシステムを支えてきました。「リレーショナル型データベース（RDB）」が主流となりつつある今でも、複数のデータベースシステムを適材適所で使い分けるシステムもあります。

RDBは、他のデータベースシステムに比べ構造がシンプルで、Excelなどの表計算ソフトに触れたことがあれば、直感的に理解できる容易さが魅力だと思います。ブログのエンジンとして使われるMySQLなどは馴染み深いRDBですね。

以降、このコンテンツ内では「データベース＝RDB」として説明を続けます。

データベース設計の基礎

データベース設計の良し悪しに関わらず、システムは概ね要件どおりに動きます。しかし、その質はレスポンスに現れ、データ量の増加に比例した遅延が、顕著に現れることでしょう。

とはいえ、ＳＥ（設計者）の能力差ほど、違いが出難いのがデータベース設計だと、個人的には思います。斬新である必要はなく、基本に沿って手堅く設計すれば、（到達時間に差こそあれ）最終的に行き着くところに大差はないでしょう。

データベース設計にも興味を持ちましょう

ＵＩ設計とは異なりデータベース設計は、ユーザーにしてみれば興味も薄く、全てお任せで終わらせてしまうかもしれません。

ユーザーが設計能力を持つ必要はありませんが、検証するための視点はあったほうがいいでしょう。要件どおりに動いていることを前提に、より良くするための「チェックの視点」を挙げておきます。

複数のテーブルにまたがって同じ項目がないか？

システム制御用のフラグや登録日、アクセス用のキー項目などを除き、項目の重複は許してはいけません。

違和感ある項目が含まれていないか？

目的や機能をもとに、必要となる項目をピックアップしてテーブルは設計されます。「なぜこの項目がここに？」は、適当さが透けて見えますね。

二次（加工）情報が含まれていないか？

「税込価格」のような加工項目（計算結果）は持たずに都度計算しましょう。

データの修正を行なった場合、どのように履歴情報を残すのか？

「削除フラグ」や「有効日」、テーブル分割など手法は様々ですが、どのような手法で対処を講じるのか確認しましょう。

細々したことを挙げれば多々ありますが、素人目線での質問は時として、ＳＥに間違いを気付かせる重要なヒントを含みます。どんどん質問をぶつけていきましょう。