編集部注：本稿は初心者向けにプログラミングやWebデザインの講座を開催している TechAcademy（テックアカデミー）による連載企画。「非エンジニアの起業家が知っておくべきプログラミングの知識」というテーマで数回に分けて極めて基礎的なプログラミングの基礎知識をお伝えする。全連載はこちらから

「非エンジニアが知っておくべきプログラミングの知識」というテーマで、10回に分けてお届けする連載企画。第9回目のテーマは「データベースの基礎」です。

前回は「これから始めるRubyのエッセンス」というテーマでお送りしました。今回は、PHPやRubyなどサーバーサイドで動作するプログラミング言語と合わせて、ユーザーの登録情報といったWebサービスを構築する上で必要不可欠な「データベース」の考え方についてご紹介します。

本連載は、インターネット業界で、これまで技術的なバックグラウンドを持たないまま起業した方や、これから独立・起業しようと思い立った方をサポートするための、連載記事です。

データベースを学ぶ上で、書店に並んでいる技術書やWebの学習サイトなど多くの教材と同じく、まず「データベースの概念・本質」の理解、そして「リレーショナルデータベース」の概念を理解することからスタートしています。本稿でも、それらを初学者を対象にして広く浅く取り扱いつつ、後半は近年話題のトピックも交えたコラム形式でお届けします。

そもそもデータベースとはなにか？

IT・Web業界以外の一般の職種の人にとって、「データベース」は全く馴染みのない言葉かもしれません。データベースは、高等数学のように目に見えない「概念」を扱うものに近い存在のため、頭の中でその姿を連想することは非常に困難です。日常業務の中で、Excelなどで多くの「データ」に触れていても、データベースの意味合いとは異なります。

「価値のあるデータ」とはなにか？

データベースの学習を始める上で、まずは「データ」と「情報」の違いについて整理してみましょう。データを「客観的な事実性がある、数字や文字、バイナリデータ（画像/音声）で表すもの」と定義したとき、「8月1日の日経平均株価の終値」や「今日の東京都の最高気温」であったり、「B事業部の◯月◯日の売上金額」だったりと、世の中にあふれている普遍的なものです。これらを単なる「データ」として無機質に存在するものと考えたとき、改めて「情報」は何を指すか考えてみてください。

「情報」を辞書を引いてみると、”ある特定の目的について、適切な判断を下したり行動の意志決定をするために役立つ資料や知識” (大辞林 第二版) とあります。何らかの意思決定を下すとき、「参考に値する（価値ある）データ」＝「情報」である、ということですね。人や組織ごとに「価値あるデータ」の基準は異なりますし、時勢やとりまく市場環境によっても変化するでしょう。

データを扱うときに価値を生むとき、それは「情報」となります。ここで、価値あるデータの要件とは何か、Web上で動くアプリケーションがデータをやり取りをすることを前提にして、いくつか例を挙げて考えてみましょう。

• データの正確性：当然ですが、データそのもの間違っていると本末転倒です。
• データの独立性：データの構造が変更されても、アプリケーションに対して影響を及ぼさないことが重要です。
• データの整合性：データ同士に矛盾がなく正確で、それらの関係構造が保たれている度合いを意味します。
• 冗長性の排除：データを論理的な関係に基づいて設計されていた場合、データの重複による矛盾を防ぐことができます。
• 同時処理の制御：同じデータを複数のアプリケーションからアクセスした際に、データを保護します。（排他制御）
• データの可用性：データをすぐに取り出せる状態で保持しておくことを意味します。

上記にあげた項目は、データベースの特徴として一般的に箇条書きにされるものと、ほぼイコールです。現代は、非常に複雑な情報社会です。様々なデータがデジタル形式で偏在している中で、大量のデータを保持し、正確に管理する手法がデータベースです。

Webサーバー上のデータベースも、アプリケーションと連携して「情報」を作り出し、意思決定の判断を下すことを目的として、データベースが活用されています。
データベースを一言で要約すると「たくさんの情報を一元的に管理でき、いろいろな目的のために使用できる」。説明のための言葉はとても平易ですが、実際どのようになっているのか、背景知識から少しずつイメージを掴んでいきましょう。

データベースの背景知識

「人が利用可能な形式（モデル）を持ったデータの集積」という意味でのデータベースの概念が誕生し、コンピュータの世界で成立したのは20世紀の中盤頃のことです。1970年頃、当時IBMに在籍していた技術者 E.F.Codd氏によって「リレーショナル（関係）データベース」という革命的な概念が提唱されるまで、コンピューターサイエンスのデータベースは抽象度の低い、階層モデル（物理層をダイレクトに反映）やネットワークモデルが主流でした。

階層型モデルとは、データをツリー状の構造で管理する仕組みです。パソコンのファイル管理がイメージしやすい例でしょう。ファイルをフォルダの中に分類して整理し、またフォルダの中にフォルダを入れることもできる、階層型構造になっています。これはツリー構造（木構造）とも表現できます。

データベースの分類（一例）

• 階層型（ツリー）ネットワークデータベース 木のような構造を持ち、各レコードは、ただ1つの親レコードを持っています。パソコンのファイル構造が一例です。
• 網型（ネットワーク型）データベース 各レコードが複数の親レコードをもつことが出来ます。全体として「網目」になっています。
• リレーショナル（関係）データベース 1970年に理論化されたモデルで、Excelのような表形式でデータを管理しています。本稿でこのあと解説します。
• オブジェクト指向データベース オブジェクト指向型プログラミングの設計思想を、データベース設計に適用したモデルで、対象世界をデータとそのデータに対する操作を持つ「オブジェクト」の集まりとして定義します。

リレーショナルデータベースの考え方

現在、最もポピュラーとされているデータベースモデルは、リレーショナル（関係）データベース（RDB：Relational Data Base）です。1つのデータ郡（例えばユーザー情報、商品情報など）を「テーブル」として定義し、その中は利用者から見ると2次元の表としてデータが取り扱われます。

「社員情報」というテーブルがあったとき、その中には「社員コード」「名前」「入社年月日」などが「カラム」（列）として存在し、実際に存在する社員1人に対してデータの行（レコード）が存在します。

他のテーブル同士とリレーション（関係性）を持てる

さて、データベースの中にある「社員情報」テーブルには、名前や社員コードなどの情報が保持されていますが、ここに「部署」の情報を記入することを想定してみます。社員情報テーブルの中に「部署名」を入れることも出来ますが、リレーショナルデータベースの考え方では、「部署」という新たなテーブルを作成して独立させることが一般的です（既存のデータベースに対して行う場合、「正規化」と呼ばれます）。

「部署」のテーブルには、「部署コード」「部署名」といったカラム情報が定義されており、レコードとして「商品開発部」「営業部」などのデータ（レコード）が1件ずつ保持されています。

社員が1つの部署に所属するとしたとき、「社員情報」テーブルと「部署」テーブルにリレーションを張ることができます。「社員情報」テーブルに外部キー（他のテーブルと関連付けをするためのカラム）として「部署コード」を持ちます。「社員情報」テーブルには部署名のデータは存在しませんが、外部キーとして部署コードを持つことで、社員がどの部署に属しているか、「部署」テーブルから部署名を参照することができます。

データベース操作言語「SQL」

データベースと一緒に学ぶ必要がある「SQL（Structured Query Language）」とは、このデータベースを操作するための言語（記述）のことです。RubyやC言語などのアプリケーションのプログラミング言語とは異なり、リレーショナルデータベースを定義・操作することを目的としており、問い合わせ（クエリ）を記述します。

例えば、上記の2つのテーブル情報をもとに「広報部に所属する社員」の情報を取得したり、「商品開発部に所属している男性社員の数」などをカウントすることができます。本稿では一部のみしか紹介できないため、より具体的なSQLクエリの書き方については、SQLの学習サイトや、ITパスポート試験／基本情報技術者試験などの参考書籍を参考にすると良いでしょう。

SQLにも様々な種類がある

SQLはあくまで一般的な名称で、その中にはオープンソース・ソフトウェアの「MySQL」「PostgreSQL」や、米オラクル社が提供している「Oracle Database SQL」、よりミニマムなデータベース設計を想定して作られた「SQlite」などが挙げられます。

SELECT文

先ほど紹介した社員情報と部署のテーブルを使って、男性社員を取得するSQL文を書いてみましょう。

SELECT 名前 FROM 社員情報 WHERE 性別 = “男” //男性社員の名前を取得するSQL文

SELECT文は最も一般的なSQL文ですが、WHEREで条件を指定したり（この条件には、数字などで比較演算子 >= などを使うこともできます。）、ORDER BY句を用いることで、データ取得時の昇順・降順などを指定することができます。

リレーショナルデータベースは、ローカルネットワーク内で「顧客管理」「売上管理」「従業員管理」などに用いられていましたが、連載2の「インターネットとブラウザ」で紹介したWorld Wide Webの登場以後には、サーバーサイド上で動作するデータベース管理ソフトが誕生し、いわゆるユーザーが会員登録するCGM（Consumer Generated Media）アプリケーションや、商品情報データと顧客情報データ、そして決済するECサイトのような様々な「Webサービス」が誕生しました。

オブジェクト指向型言語の登場により変化した「リレーショナル」の概念

プログラミングを学ぶ上で「オブジェクト指向」といった言葉を耳にする読者も多いことでしょう。本連載の対象である初学者の場合は特に、プログラミングの勉強の独学の過程で、つまづくポイントの一つでもあります。（一方で、腹落ちできてしまうと、その後の学習効率が上がるでしょう。）

1990年代後半より、オブジェクト志向型プログラミングが勃興したことにより、従来のリレーショナルデータベースとの相性の悪さが問題として生じました。リレーショナルデータベースは、データを「テーブル」単位で管理して、オブジェクト指向型言語では、データは「オブジェクト」そのものとして扱います。

設計思想や構造が異なるため、データベースから取得したテーブル形式のデータを手動でオブジェクトのプロパティに割り当てる作業などが必要で、その逆も然りでした。このようにアプリケーションとデータベースの構造のギャップのことを「インピーダンスミスマッチ」と呼びます。

データベースから抽象化した「モデル」という考え方へ

オブジェクト指向とリレーショナルデータベースの相性の悪さ（インピーダンスミスマッチ）について触れましたが、現在はこれらを解消し、アプリケーションとデータベース間の橋渡しを受け持つ「O/Rマッパー（Object/Relational)」といったライブラリが登場しています。

よくスタートアップ企業で採用されている「Ruby on Rails」などのWAFにおいては、O/Rマッパーの標準ライブラリとして「Active Record」が有名です。このActive Recordの強力な機能が標準搭載されていることが、Railsを普及させた一つの要因ともいえます。

昨今のWebアプリケーション開発において、オブジェクト志向プログラミングとリレーショナルデータベースを橋渡しするメリットを2つ挙げるとすれば、(1) データベースにあるテーブル1つを1つのモデルクラスとして表現することができ（上記例では、社員情報というテーブルが1つのモデル）、リレーショナルデータベースとのギャップを防げます。

そして (2) MySQLやSQliteなど、データベース製品固有の方言については、O/Rマッパーが内部的に吸収するため、SQL命令文の微妙な違いに依存せず、アプリケーションへの影響を最小限に抑えることのメリットを享受できます。

脱リレーショナルのデータベース

データベースをとりまく近年の状況として、リレーショナル以外のデータモデルを持った「NoSQL」（一般的に”Not only SQL”と解釈）などが提唱されており、リレーショナルに依存しない KVS（Key-Value-Store）というモデルが普及しています。

KVSは、配列データでKeyに対してValueを1つ定めてデータを保持します。ハッシュ計算を行うことができるため、データマイニングなどより高速な処理が可能になります。GoogleのBigTable、アマゾンのAmazon DynamoDBなどで採用が行われています。NoSQLを広義の分類語句とすると、その中にある技術として「Redis」や「MongoDB」、以前までFacebook社の大規模データ格納に使われていた「Apache Cassandra」などが挙げられます。

データ構造（モデル）＝ビジネスロジック？

あくまで初学者向けにコラム形式で、広く浅くトピックを扱っている本連載ですが、この記事のボリュームからもわかるように、広義の「データベース」は非常に奥が深く、コンピュータサイエンスの学問体系の中で、技術的／研究分野としての日々開拓が続けられているほか、ビッグデータ・データマイニングなど、統計学・数学的アプローチ、現場のビジネスニーズからも最重要視されるようになりました。

個人開発者や、アジャイルソフトウェア開発を中心思想に据えたスタートアップが、Web上でのサービス・スマホアプリなどを企画するとき、そのサービスを構成する要素を洗い出して、データ構造（モデル）を設計するプロセスがあります。

極論すると、このデータ構造の設計プロセスのタイミングで、ソフトウェアが完成せずとも既にそのサービス（ビジネス）の将来価値は半分決まっているといっても過言ではないほど、モデル設計がビジネスロジックに直結していることもあります。

プログラミングの教養・開発スキルだけでなく、データベースの概念を本質的に理解し、世の中にあふれる無秩序なデータ群の中から、社会に影響力を与える新たな「価値」をどのように生み出していくか ─ アプリケーションでモデル設計をする際には、その設計から生み出される「価値」にフォーカスして、度重なる試行錯誤からソフトウェア開発・設計の「センス」を、読者の皆さんが身につけられることを願っています。

次回はいよいよ最終回です。