ばらばらの記録を「キー」で結び付ける
名簿を表計算ソフトで作ると、氏名、住所、連絡先などを列に分け、1人分を1行に並べられます。関係データベースも行と列を持つ表を使いますが、単に大きな表を保存するだけではありません。扱う対象ごとに表を分け、共通する項目を手掛かりに必要な情報を組み合わせます。
例えば通販サービスなら、利用者の表、商品の表、注文の表を分けて持てます。注文の表に利用者の住所を毎回書き写すのではなく、利用者を重複なく識別する番号を記録します。このように行を識別する項目を主キー、別の表の行を指し示す項目を外部キーと呼びます。氏名や商品名は同じものが存在したり変更されたりするため、それだけを識別の手掛かりにするのは適切ではありません。
表を適切に分ければ、同じ情報を何度も保存する重複を減らせます。住所を変更するときに複数の注文記録をすべて書き換える、といった不整合も避けやすくなります。ただし、表を細かく分けるほど、検索時には複数の表を結合する処理が必要です。保存のしやすさ、検索の速さ、更新時の正確さを考えて設計することが重要です。
DBMSが検索と更新の門番になる
蓄積されたデータそのものと、それを管理するソフトウェアは同じではありません。データベース管理システム（DBMS）は、アプリケーションから要求を受け取り、検索、追加、更新、削除を実行するソフトウェアです。関係データベースでは、SQLという言語で「どの表から、どの条件に合う行を取り出すか」などを指定する方法が広く使われています。
DBMSには、利用者ごとに許可する操作を分ける役割もあります。閲覧だけできる利用者と、内容を更新できる利用者を区別すれば、誤操作や不必要な変更を防ぎやすくなります。検索対象の列などに索引（インデックス）を用意すると、すべての行を先頭から調べずに目的のデータへ到達しやすくなります。一方、索引も保存領域を使い、データを更新するときには索引側の更新も必要になるため、多ければよいわけではありません。
アプリケーションとDBMSは別のコンピュータで動くこともあります。その場合は、要求する側と応答する側に役割を分けるクライアントサーバモデルとして捉えられます。画面からデータベースへ自由に直接接続させるのではなく、アプリケーションが入力内容や権限を確認してからDBMSへ要求する構成が一般的です。
「最後の1個」を二人が注文したらどうなるか
在庫が1個の商品に、ほぼ同時に二つの注文が届く場面を考えます。どちらの処理も在庫数を読んでから無条件に注文を確定すると、存在する数を超えて販売してしまいます。データベースでは、互いに関連する複数の処理を一つのまとまりとして扱うトランザクションという仕組みを利用できます。
在庫が残っていることの確認、在庫数の減少、注文記録の追加をひとまとまりにし、すべて成功した場合だけ結果を確定します。途中で失敗した場合は、まとまり全体を取り消して開始前の状態に戻します。また、同じデータを同時に変更する処理の順序を調整し、矛盾した結果を防ぎます。こうした制御は、売上と在庫を結び付けるPOSシステムなど、複数の処理が同時に進む仕組みを支えています。
ただし、トランザクションがあればあらゆる事故を防げるわけではありません。誤った値を正しい操作で登録すれば、その値は矛盾なく保存されます。機器の故障や操作ミスに備えるにはバックアップも必要です。正確な処理、適切な権限、障害への備えは、それぞれ別の役割を持ちます。
空欄とゼロを同じものにしない設計
データベースを役立てるには、どんな値をどの形式で保存するかを先に決めます。数値、文字列、日付などの型を定め、数量に文字を入れられないようにすると、誤った入力を減らせます。「必ず値を入れる」「識別番号を重複させない」「存在する商品番号だけを注文に使う」といった制約も、データの一貫性を守ります。
値の意味も統一しなければなりません。回答がない空欄と、測定結果が0だった場合は意味が異なります。未入力、測定不能、該当なしをすべて同じ空欄にすると、後から区別できません。質的データと量的データの違いを踏まえ、単位や入力規則もそろえる必要があります。外れ値と欠損値を分析時にどう扱うかも、保存された値の意味を確認して判断します。
検索結果が出たというだけで、その内容が現実を正しく表すとは限りません。古い情報、入力範囲の偏り、重複した記録があれば、集計結果も影響を受けます。データベースは整然と保存し処理する道具であり、集め方や解釈の妥当性まで自動的に保証するものではありません。
実は「表に入らないデータ」も管理できる
データベースという言葉から表を思い浮かべやすいものの、すべてが関係データベースではありません。文書に近いまとまりで保存する方式、キーと値の組で保存する方式、人物同士のつながりのような関係を中心に表す方式などがあります。まとめてNoSQLと呼ばれることがありますが、単一の仕組みを指す名称ではありません。
商品検索、座席予約、蔵書検索、ゲームの状態保存など、画面上では表が見えないサービスにもデータベースが使われます。大量かつ多様なビッグデータを扱う場合も、データの形、検索方法、更新頻度に応じて方式を選びます。関係データベースとそれ以外は優劣だけで分かれるのではなく、一つのサービスで用途別に併用されることもあります。見えない場所で目的に合った整理方法が選ばれていることが、データベースの興味深い点です。