データベース 重点教科書

データベースと聞くと「Excelの表がたくさん集まったもの」というイメージを持つ人が多いかもしれません。実はその理解、そんなに間違っていません。データベースとは、体系的に整理された数値や文字列などのデータの集まりのことです。ただし、ただ雑然と集めただけの箱ではなく、「後から取り出しやすいように整理された」データの集まりである、という点が重要です。この章では、そのデータベースを実際に管理するための仕組みや、データベースにもいろいろな種類があることを学びます。

データベースとは何か

会社では、顧客の名前や住所、商品の在庫数、社員の勤怠記録など、毎日大量のデータが発生します。これらをバラバラなファイルにメモしていたのでは、後から「A社の注文履歴を全部見たい」といった要望にすぐ応えられません。そこで登場するのがデータベースです。データベースは、データを一定のルールに従って構造的に整理しておくことで、必要なときに必要なデータをすばやく取り出せるようにする仕組みです。データをどのような形で整理するかという基本的な考え方をデータモデルと呼びます。代表的なデータモデルには、データを行と列からなる表（テーブル）の形で表す関係データモデルがあり、これがもっとも広く使われています。

データベース管理システム（DBMS）

データベースそのものは「整理されたデータの集まり」ですが、それを実際にコンピュータ上で操作するためのソフトウェアが必要です。これがデータベース管理システム（DBMS：Database Management System）です。DBMSは、データを構造的に蓄積し、複数の利用者が同時にアクセスしてもデータの一貫性（矛盾のない正しい状態）を保ち、効率よくデータを取り出すための機能を備えています。たとえるなら、データベースが「本がぎっしり詰まった図書館の書庫」だとすれば、DBMSは「その書庫から目的の本をすぐに探し出してくれる、優秀な司書さん」のような役割を果たしていると考えるとイメージしやすいでしょう。

DBMSの中でも、関係データモデルに基づいて表形式でデータを管理するものをRDBMS（Relational Database Management System）と呼びます。行と列からなる表でデータを表現し、表同士を関連づけて扱えることが特徴で、企業の基幹システムなどで広く使われている、いわば「データベースの王道」といえる存在です。

DBMSが存在することによって、私たちアプリケーションの利用者やプログラムを作る人は、データがハードディスクのどこに、どんな形式で保存されているかを意識する必要がなくなります。「このデータをください」と依頼すれば、あとの細かい管理はDBMSがすべて引き受けてくれるからです。また、複数の利用者が同時にデータへアクセスしてもデータの内容が壊れないように調整したり、同じデータを何か所にも重複して持たなくて済むようにしたりする役割も担っています。これらは「データの独立性」や「データの一元管理」と呼ばれる考え方で、DBMSが企業システムの土台として重宝される理由となっています。

表形式にとらわれない新しいデータベース（NoSQL）

RDBMSは表形式でデータをきっちり整理するのが得意ですが、世の中のデータは必ずしもきれいな表に収まるものばかりではありません。たとえばSNSの投稿データや、大量のセンサーから送られてくるデータなどは、表の形にうまく当てはめにくいことがあります。そこで登場したのが、関係データモデルの表形式にこだわらないNoSQLと呼ばれるデータベースの総称です。NoSQLにはいくつかの種類があります。「キー」と呼ばれる見出しと、それに対応する「値」をペアで保存するシンプルな仕組みのキーバリューストア（KVS）、Word文書のようなひとまとまりの文書（ドキュメント）単位でデータを保存するドキュメント指向データベース、人と人のつながりのような「モノとモノの関係性」を線（グラフ）で表現するのが得意なグラフ指向データベースなどがあり、扱うデータの性質に応じて使い分けられています。

よいデータベースは、いきなり作り始めるものではありません。家を建てるときに設計図が必要なように、データベースにも「どんな情報を、どんな形で持たせるか」を事前にしっかり考えるデータベース設計という工程があります。この章では、業務で使うデータを洗い出すところから、実際に表の形に落とし込むまでの流れを見ていきます。

データ分析：何のデータが必要かを洗い出す

データベースを設計する最初のステップは、いきなりテーブルを作ることではなく、「そもそも業務にはどんなデータが必要なのか」を洗い出して整理することです。これをデータ分析と呼びます。顧客管理、在庫管理、売上管理など、業務ごとに必要なデータの種類も量もまったく違うため、現場の業務をよく観察し、抜け漏れなく必要なデータを洗い出す必要があります。

このとき問題になりやすいのが、同じはずの情報が別々の場所で管理されていて、表記がバラバラになってしまうことです。たとえば「株式会社山田商店」と「(株)山田商店」が別の顧客として登録されてしまうようなケースです。複数の場所に散らばったデータを一つにまとめるデータの結合や、表記のゆれや誤り、重複を取り除いてデータをきれいに整えるデータクレンジングは、こうした問題を解消するために欠かせない作業です。汚れたデータのままではどんなに優れたデータベースを作っても正しい分析はできない、という意味で、地味に見えて非常に重要な工程です。

データの設計：表の形に落とし込む

必要なデータが洗い出せたら、次はそれらのデータと、データ同士の関連（つながり）を整理して表現する段階に進みます。ここでよく使われるのがE-R図（実体関連図）です。E-R図は、「顧客」「商品」「注文」といったデータのかたまり（実体）と、それらがどう関連しているか（顧客が商品を注文する、など）を図で表したもので、データベース設計の設計図にあたります。文章だけで説明するより、図にしたほうが関係者全員が同じイメージを共有しやすくなる、というのがE-R図を使う大きなメリットです。

データを分類・整理する際には、それぞれのデータに一定のルールに従った符号を割り当てるコード設計も重要になります。たとえば商品ごとに「A001」「A002」のような商品コードを振っておけば、名前の表記ゆれに悩まされずにデータを管理できます。

実際にデータを表の形で管理するとき、いくつかの基本用語を押さえておく必要があります。表の中の一つひとつの項目（「氏名」「電話番号」など）をフィールド（項目）、それらのフィールドが集まって1件分のデータになったもの（田中さん1人分のデータなど）をレコードと呼びます。そして、レコードが集まって一つのまとまりになったものをファイル、それを表形式で管理するときにテーブル（表）と呼びます。エクセルでたとえるなら、1つのセルの列見出しがフィールド、1行分のデータがレコード、シート全体がテーブルにあたるとイメージすると分かりやすいでしょう。

テーブルの中で、レコードを一意に、つまり「他と絶対に重複しない形で」特定するための項目を主キーと呼びます。学籍番号や社員番号のように、同じ値を持つ人がいないように設計された項目が主キーの代表例です。一方、別のテーブルにある主キーを自分のテーブルに持ち込んで、テーブル同士を関連づけるために使う項目を外部キーと呼びます。たとえば「注文」テーブルの中に「顧客ID」という項目を持たせておけば、その顧客IDを手がかりに「顧客」テーブルとひも付けることができる、というわけです。主キーは「自分自身を特定するための鍵」、外部キーは「他のテーブルとつながるための鍵」と覚えると整理しやすいでしょう。

また、大量のデータの中から目的のレコードを高速に検索できるようにする索引の仕組みをインデックスと呼びます。本の巻末にある索引を使えば知りたい単語のページをすぐに見つけられるのと同じように、インデックスを設定しておくことで、データベースは膨大なデータの中からでも目的のレコードを素早く探し出せるようになります。

データの正規化

テーブルの設計がずさんだと、同じデータがあちこちに重複して登録されてしまい、更新のたびに矛盾が生まれる原因になります。たとえば顧客の住所が「注文」テーブルにも「顧客」テーブルにも別々に保存されていると、引っ越しのたびに両方を書き換えなければならず、片方を直し忘れると情報が食い違ってしまいます。こうしたデータの重複や矛盾を防ぐために、テーブルの構造を整理していく作業を正規化と呼びます。ITパスポート試験では正規化の詳細な手順まで問われることはありませんが、「データの重複や矛盾を防ぐためにテーブルを整理する作業である」という目的そのものは押さえておきましょう。

設計をおろそかにするとどうなるか

データベース設計の重要性は、実際にトラブルが起きてはじめて実感することが多いものです。たとえば、顧客情報を「注文」テーブルの中にそのまま書き込んでしまう設計にしていたとします。この場合、同じ顧客が2回目の注文をするたびに、氏名や住所をもう一度まるごと入力し直すことになり、入力ミスによって同じ顧客なのに別人として登録されてしまう、といった不具合が起こりやすくなります。あらかじめE-R図を描いて「顧客」と「注文」を別々のテーブルに分け、外部キーでつなぐ設計にしておけば、こうした無駄な入力や表記のゆれを防ぐことができます。設計段階でのひと手間が、後々の運用の手間やデータの品質を大きく左右する、という点は覚えておきたいポイントです。

データベースは、ただデータをしまっておくための倉庫ではありません。実際の業務では、新しいデータを登録したり、古いデータを書き換えたり、条件に合うデータだけを取り出したりと、日々さまざまな操作が行われています。この章では、関係データベース（RDBMS）を実際に活用するうえで欠かせない、代表的なデータ操作の考え方を見ていきます。なお、ITパスポート試験では実際のSQL（データベースを操作するための専用の言語）の文法までは問われません。「どんな操作があり、それぞれ何をするものか」という考え方を理解しておけば十分です。

データを増やす・変える操作（挿入・更新）

もっとも基本となる操作が、新しいレコードをテーブルに追加する挿入です。新しく入会した会員の情報を「会員」テーブルに1件追加する、といった場面がこれにあたります。すでにあるレコードの内容を書き換える操作は更新と呼ばれます。引っ越しをした顧客の住所を書き換えたり、商品の価格を改定したりする作業がこれにあたります。挿入は「新しく加える」、更新は「すでにあるものを書き換える」と対比させて覚えておくと混同しにくくなります。

目的のデータだけを取り出す操作（選択・射影）

テーブルには大量のレコードが保存されていますが、すべてのデータが常に必要になるわけではありません。条件に合うレコード（行）だけを取り出す操作を選択と呼びます。たとえば「東京都在住の顧客だけを取り出したい」という場合、これは選択にあたります。一方、必要な列（フィールド）だけを取り出す操作を射影と呼びます。「全顧客の氏名と電話番号の列だけを取り出したい」という場合が射影の例です。選択は「行を絞り込む」、射影は「列を絞り込む」と覚えるとよいでしょう。表を横方向（行）に薄く切り出すのが選択、縦方向（列）に切り出すのが射影、とイメージすると視覚的にも整理しやすくなります。

複数のテーブルを組み合わせる操作（結合）

関係データベースの強みは、複数のテーブルに分けて保存しているデータを、必要なときにつなぎ合わせて活用できるところにあります。複数のテーブルを、共通の項目（前章で紹介した主キーや外部キーなど）を手がかりにつなぎ合わせる操作を結合と呼びます。たとえば「顧客」テーブルと「注文」テーブルを顧客IDで結合すれば、「どの顧客が何を注文したか」という一覧を作ることができます。データをあえて複数のテーブルに分けて保存し（正規化）、必要なときだけ結合して使う、という考え方こそが、関係データベースの設計思想の中核だといえます。挿入・更新・選択・射影・結合という5つの操作は、いずれも関係データベースを実際に業務で活用するための代表的な操作例として、セットで押さえておきましょう。

削除の操作も忘れずに

登録・更新・検索とあわせて、不要になったレコードをテーブルから取り除く「削除」の操作も、業務では日常的に発生します。退会した会員のデータを削除したり、キャンセルされた注文を取り除いたりする場面がこれにあたります。シラバスの用語例には明記されていませんが、挿入・更新と対になる操作としてあわせてイメージしておくと、データベースを使った業務の全体像がつかみやすくなります。試験対策としては、まず「挿入・更新・選択・射影・結合」の5つの名前と意味を確実に覚えることを優先しましょう。

会社のデータベースには、常に一人だけがアクセスしているわけではありません。同じ瞬間に何人もの社員がアクセスしたり、システムに突然の障害が起きたりすることもあります。それでもデータベースの中身が矛盾なく正しい状態に保たれるよう支えているのが、この章で学ぶトランザクション処理です。複数の利用者によるデータの参照や更新に備えて、同時にアクセスが起きても混乱しないようにする仕組みと、障害が起きてもデータを元通りに復旧できる仕組みの、大きく2つを見ていきます。

トランザクションとACID特性

データベースに対する一連の処理をひとまとまりとして扱う単位をトランザクションと呼びます。たとえば銀行の口座間でお金を振り込む処理を考えてみましょう。この処理は「Aさんの口座から1万円を引く」「Bさんの口座に1万円を足す」という2つの更新から成り立っています。もしこの途中でシステムが停止し、「Aさんの口座からは引かれたのに、Bさんの口座には振り込まれていない」という中途半端な状態になってしまったら大変です。そこでこの2つの更新処理を1つのトランザクションとしてまとめて扱い、「両方とも成功する」か「両方とも失敗して元に戻す」かのどちらかしか許さないようにします。

トランザクションが備えるべき4つの性質の頭文字を取ったものがACID特性です。処理が中途半端な状態を許さず「全部成功するか、全部失敗するか」のどちらかにする原子性（Atomicity）、処理の前後でデータの内容に矛盾が生じない一貫性（Consistency）、複数のトランザクションが同時に実行されても互いに干渉し合わない独立性（Isolation）、そして一度完了した処理の結果は障害が起きても失われない永続性（Durability）の4つです。振込の例でいえば、原子性のおかげで「引いたのに足されない」という事態が起きず、独立性のおかげで他の人の振込処理と混ざり合って混乱することもありません。

同時実行制御（排他制御）

複数の利用者が同時に同じデータへアクセスすると、データの整合性が崩れてしまうおそれがあります。たとえば同じ座席を2人が同時に予約しようとして、両方とも「予約できました」と表示されてしまっては困ります。そこで、あるデータを一人が更新している間は、他の人が同時にそのデータを書き換えられないようロックをかけるなどして制御する仕組みを同時実行制御（排他制御）と呼びます。

排他制御を行ううえで注意しなければならないのがデッドロックという現象です。これは、複数のトランザクションが互いに相手の処理が終わるのを待ち続けてしまい、結果としてどちらの処理も永遠に先に進めなくなってしまう状態のことです。たとえば、Aさんの処理がデータXをロックしたままデータYの解放を待ち、同時にBさんの処理がデータYをロックしたままデータXの解放を待っている、という状況を想像してみてください。お互いが相手を待ち続けるだけで、いつまで経っても処理が終わりません。まさに「相手が動くのを待っている者同士が、いつまでもにらみ合っている」ような膠着状態です。

また、複数のデータベースにまたがる処理をまとめて確定させるための仕組みとして2相コミットメントがあります。これは、まず関係するすべてのデータベースに対して「準備はできたか」を確認する段階(第1相)を行い、全員から「準備OK」の返事が得られた場合にのみ、実際に処理を確定させる段階(第2相)に進む、という2段階の手順を踏むことで、一部のデータベースだけ更新が反映されてしまうといった食い違いを防ぐ仕組みです。

障害回復（リカバリ機能）

どんなに注意していても、停電やハードウェアの故障といった予期せぬ障害は起こり得ます。そうした場合に備えて、データベースを正しい状態に復旧させるための機能をリカバリ機能と呼びます。

リカバリ機能の要となるのがチェックポイントです。これは、その時点でのデータベースの状態を記録しておく「セーブポイント」のようなもので、障害が起きたときには、最初からすべてをやり直すのではなく、直近のチェックポイントまで戻ってそこから復旧作業を始めることで、復旧にかかる時間を大幅に短縮できます。

復旧の方法には大きく2つの方向があります。一つは、更新前の記録を使って、トランザクションが始まる前の状態まで処理を巻き戻すバックワードリカバリ（ロールバック）です。処理の途中で異常が発生した場合や、そもそも処理自体を取り消したい場合に使われます。もう一つは、更新後の記録を使って、チェックポイントの時点から正常に完了していたはずの処理を再現し、障害発生の直前の状態まで処理を進め直すフォワードリカバリ（ロールフォワード）です。ハードディスクの故障などでデータそのものが失われてしまった場合に、バックアップとこの更新後の記録を組み合わせて最新の状態まで復旧させる際に使われます。ロールバックは「時間を巻き戻す」、ロールフォワードは「時間を進めて復元する」というイメージを持っておくと、2つの違いを混同しにくくなるでしょう。