1.1　データベースという概念

　データベースといっても、特に難しい概念ではありません。スマホに入っている連絡先、メールが格納されているメールボックス、電子データ以外では紙の辞書、最近めっきり見なくなりましたがタウンページのような電話帳も、データベースと言えないことはありません。

　端的に言いますと、データベースとは、「参照したり修正したりできるデータの蓄積」のことです。

1.2　データベースを管理する

　「データベース」という概念の意味はおわかりいただけたでしょうか。しかし、いかに膨大なデータが蓄積されていてもそれが整理されていなければ使いにくく、どんなに有益なデータでも有効に使えなければ宝の持ち腐れです。また、量が多すぎて更新するのも一苦労で、更新漏れがないように確認するだけでも大仕事となると、誰もデータをアップデートできず、結果としてデータの価値が落ちてしまいます。

　そんなデータを簡単に検索したり、矛盾なく更新したり、使いやすく管理可能にするソフトウェア。そのような製品を、「データベースマネージメントシステム（Database Management System）」略してDBMSといいます。

　図書館で例えてみましょう。本一つ一つがデータです。どんなに有益な本がたくさんあったとしても、それらが雑然と積まれているだけでは、利用者は読みたい本を探すのも大変ですし、どんな本があるのか把握するのも一苦労でしょう。

　探しやすいようしっかりと本を分類して本棚にしまい、時には利用者からの問い合わせに対応して本を探す。古くなった本の補修を行うこともあるでしょう。図書館で言えば、司書や図書館職員にあたるのがDBMSです。

1.3　データを破壊から守る

　DBMSは、データベースを扱いやすくする以外に、もう一つ大きな使命を持っています。

　それは、「データを破壊から守ること」。なぜデータを守ることがそんなに重要なのでしょうか？

　考えてもみてください。あまり意識しないだけで、実は世の中にはたくさんのデータベースで溢れています。それらのデータベースは、私達ユーザーが直接いじることはほとんどなく、何かしらのアプリケーションを介して操作します。

　もう一度、図書館で例えてみましょう。

　本がデータ、図書館の本棚がデータベース、図書館の利用そのものがアプリケーションです。図書館の価値は何で決まるでしょう？立地や見た目の良さなども重要ですが、蔵書は傷だらけ、ところどころ抜けているページがある、整理されておらずどこに何があるかわからない、どこの本屋にでも置いてあるような雑誌はたくさんあるのに図書館にこそ求められる学術的な本はない……そんな図書館に価値はあるでしょうか？どんなにきれいな建物でもそんな図書館に用がある人は少ないですよね。

　つまり、データの価値がシステムの価値を決めると言っても過言ではないのです。しかし、そのデータはちょっとした操作で壊れてしまいやすいものなのです。

　データの破壊にはふたつの種類があります。ひとつは保存している媒体そのものが故障してしまう「物理的破壊」。もうひとつは、データが現実と乖離したり、データが相互に矛盾してしまったりする「論理的破壊」です。

　図書館の例えを続けると、紙の本はちょっと乱暴に扱うだけで破れますし（物理的破壊）、元あった本棚に戻さないと、その本がどこにあるのか探すのが大変になりますよね（論理的破壊）。

　このふたつの破壊からデータを守る。これがDBMSの使命であり、そんな壊れやすいデータを守る最後の砦、それがDBMSです。したがって、DBMSにはデータを破壊から守るための管理方法や機能がたくさん搭載されています。

1.4　関係モデルとは

　では、どのようにすればデータを破壊から守れるのでしょうか。昔から、「こうすればデータを管理しやすくできる」と考えた人が、様々な管理手法やデータのモデルを考案してきました。そしてそのたびに、その管理方法を実装したDBMSがいくつも世に出てきました。

　データの管理方法の概念の一つであり、現在主流となっているのが、「関係モデル」です。英語で「リレーショナルモデル」ということもあります。

　関係モデルとは、IBM社員だった故エドガー・F・コッド氏¹が、数学の集合論と述語論理に基づいて考案し、1970年に提唱したデータ管理モデルで、データを縦軸と横軸の二次元表のような形式²で扱うものです。

　たとえば、書籍を関係モデルで表してみましょう。

　まずデータが持つ属性を決めます。書籍なら、「タイトル」「著者」「出版社」「発行年月日」「価格」などでしょうか。架空の書籍ですが、たとえばこのようになります。

　他の書籍も、同様に表現してみましょう。

　どうでしょうか。同じ属性を持つデータの「集合」が、まるで縦横の二次元表のように見えてきたのではないでしょうか。実際に、関係モデルではこの「集合」のことを「テーブル」、つまり「表」と呼びます。

　このテーブルがいくつも存在し、テーブル同士を関連付けてデータを管理できます。そのため、「テーブル同士を関連付けてデータを管理できるから、『関係モデル』というんだ」という誤解がよく見受けられます。実際は、関係モデルではテーブル同士の関連のことを「関係」と呼んでいるのではなく、この「集合」のことを、「関係」と呼びます。

　このモデルは人間的にもわかりやすく、非常に有効で、現在でも主流となっています。

　この関係モデルを実装してデータを管理するDBMSを、「リレーショナルデータベースマネージメントシステム（Relational Database Management System）」、略してRDBMSといいます。

　そして、本書で扱うPostgreSQLも、RDBMS製品の一つです。他のRDBMS製品として有名なところでは、Oracle Database、MySQL、SQL Serverなどがあります。

　しかし、この関係モデルの概念が提唱されたのはおよそ半世紀も前。そんな昔に提唱された理論が現在なお主流となっているのですから、いかに安定した理論であるかがわかるというものです。

1.4.1　関係モデルの用語

　RDBMSでよく使う用語をここで解説します。

表（テーブル）

　関係モデルでいうところの「関係」、すなわちデータの集合。これを「表」や「テーブル」といいます。数学的には「集合」。関係モデルの概念では「関係」。関係モデルを実装したDBMSでは「テーブル」といい、細かい違いはありますが、すべて同じ概念を違う言葉で言っているようなものです。普段の会話でデータベースの話をするときは、「テーブル」といえばみんなわかってくれるでしょう。

列（カラム）

　テーブルで表現したときに、縦の列になるものです。すなわち、ある集合の属性のことです。

行（レコード、タプル）

　テーブルで表現したときに、横の行になるものです。すなわち、ある集合の1件のデータのことです。一般的には「レコード」ということが多いですが、PostgreSQLでは「タプル」と呼ぶことも多いです。

キー

　テーブルで重要な意味を持つ列のことを「キー」や「キー列」といいます。特に、その列の値が決まればそのテーブルの中でレコードが1行に特定できるキーのことを、テーブルの「主キー」とか、「プライマリキー」などといいます。1行に特定しなければならないので、主キーはテーブル内で重複はありません³。

　たとえば世の中には同じタイトルのつけられた本が山程ありますが、ISBNという全世界の書籍一つ一つにつけられたコードがわかれば、そのなかから1冊の書籍を特定できます。同じISBNが全く異なる書籍に振られていたら、ちょっと世間が混乱するでしょう。

1.5　なぜDBMSを使うのか

　データベースについて説明してきましたが、皆さんの中には「DBMSをいちいち使わなくても、表計算ソフトやCSVなどのテキストベースのファイル管理でも別にいいんじゃないの？」と思った方がいるかもしれません。

　筆者自身データベースをよく知らなかったときはそう思いましたし、データベースにあまり詳しくない人にそう言われたこともあります。

　DBMSを使うと何が便利なのか？たとえば次のような点が挙げられます。

1.5.1　同時にデータにアクセスできる

　たとえば、あなたの会社ではExcelで作成したプロジェクトの管理表がファイルサーバーに置いてあり、各自がそれぞれアクセスして更新していませんか？⁴

　そういう運用をしているところでは、「誰かが更新してるから自分が更新できない」とか、「自分がローカルで更新したファイルをサーバにアップロードして、誰かが更新した内容を消してしまった」ということを体験した人も多いと思います⁵。

　DBMSを使えばこのようなことを心配する必要はありません。同時にデータにアクセスする仕組みをきちんと備えているからです。

1.5.2　大容量データを扱える

　あなたは何10メガも何100メガもあるExcelファイルを開かざるを得なかったことはありませんか？それなりの性能のPCでも、まず開くだけで時間がかかります。Excelは1シートにつき100万行以上のレコードを扱えますが、実際に100万行データを入れることはまずないでしょうし、数千から10000行でもExcelにしては多いな、と思います。

　また、何100メガのテキストファイルをエディタで開き、必要な行を見つけてデータの参照や更新をするのは一苦労というのは容易に想像できることでしょう。

　RDBでは何10メガ何100メガは当たり前。ギガ単位はざらにあります。100万行のレコードを保持しているテーブルなんてゴロゴロあります。何億行だって存在します。

　それでも高速に必要なデータを参照したり更新したりできる仕組みが存在しています。

1.5.3　データの矛盾・重複を防ぐ

　Excelのような表計算ソフトやCSVのようなテキストファイルでは、データの分散と重複が防げません。そのため、あるデータを更新するために複数のシートやファイルを更新しなければならず、更新漏れを防ぐのは本人の努力以外にありません。

　また、本来ならば数値を入れるべき箇所に誤って文字を入力した場合、エラーとして弾くのも難しいでしょう。

　DBMSなら、このようなデータの矛盾や重複を防ぐ仕組みがあります。

1.5.4　別テーブルを関連付けて検索できる

　この機能がRDBMSの真骨頂と言っていいでしょう。複数のテーブルを同時に検索し、検索結果としては一つの表として表示できます。プログラムを書かずにExcelやCSVで同じ芸当をこなすのはかなり難しいでしょう。

　　

　どうでしょう、DBMS、特にRDBMSについて、なんとなく理解できたでしょうか。ではデータベースについて理解できたところで、次章では本書で扱うPostgreSQLというRDBMSについて、もう少し詳しく説明します。

2.1　PostgreSQL前史

　PostgreSQL。日本語では「ぽすとぐれえすきゅーえる」と読み、略して「ぽすぐれ」とか、「ぽすとぐれす」などと言ったりもします。

　PostgreSQLの大本をたどると、カリフォルニア大学バークレイ校の助教授だったマイケル・ストーンブレーカー氏¹が、「1.4 関係モデルとは」で登場したコッド氏の論文を読み、RDBMSの研究として1973年に開発を始めたIngres²に突き当たります。

　Ingresで採用した関係モデルに行き詰まりを感じたストーンブレーカー氏は、Ingresの後継となるプロジェクトを始めます。それがPOSTGRES(Post-INGRES)プロジェクトです。

　POSTGRESは研究用や教材、商用として広まったのですが、ユーザー数が増えた結果ソースの保守開発に研究室のリソースの大半が取られてしまうということで、1993年にPOSTGRESプロジェクトはPostgres 4.2をリリースして正式に終了します。

　翌1994年、Postgres95がオリジナルのPOSTGRESバークレイコードの後続としてWeb上でリリースされます。さらに1996年名前を「PostgreSQL」に変え、バージョンを6.0としてリリースします。

　これが今日まで続くPostgreSQLの歴史の始まりです。

2.2　PostgreSQLの開発形態

　ソフトウェアは、売り物として販売されている商用ソフトウェアと、ソースコードが公開され、ライセンスさえ守れば誰でも無償で自由に使用や修正、さらに再配布が可能なオープンソースソフトウェアのふたつに大別できます。

　DBMSにもこのふたつが存在し、PostgreSQLは後者のオープンソースソフトウェアにあたります。

　同じオープンソースソフトウェアのRDBMSとして有名なMySQLは、開発はOracle社が中心となっていますが³、PostgreSQLは、現在もどの企業にも属さずコミュニティが中心となって開発が行われています。メジャーバージョンアップは原則1年に1回行われ、今も機能の拡充と性能向上が続けられています。

　一昔、いや二昔くらい前までは、オープンソースソフトウェアというと、無料で利用できる分、商用よりも劣る品質のものであると考える人も多かったのですが、PostgreSQLは常に機能の拡充と性能の向上を行っており、商用DBMSと遜色ないくらいの機能と品質を持っています。今では実際のサービスでPostgreSQLや他のオープンソースソフトウェアのRDBMSが採用されていることは珍しくありません。

PostgreSQLのバージョン番号

　PostgreSQLのバージョンが9.6から10になったときに、小数点以下の数字がなくなったことにお気づきでしょうか。これは、10がリリースされたときに、小数点第一位までがメジャーバージョンを表していた従来のバージョン番号の方式を改め、整数部分がメジャーバージョン、小数点がセキュリティアップデートやバグフィックスでバージョンアップするマイナーバージョンとすることになったからです。

　どのPostgreSQLを使うか迷ったときは、とりあえず性能や機能が改善されている最新版を使うことをおすすめします。

2.3　PostgreSQLの特徴

2.3.1　ライセンス

　オープンソースソフトウェアはソースコードを公開しているとはいえ、決して権利を放棄しているのではありません。ちゃんとライセンスを公開しており、ライセンスに従わない場合は訴訟もありえます。

　オープンソースソフトウェアで広く使われているラインセンスはGPL(GNU General Public License)というものです。これは利用を認めているが、修正して再配布する場合は同じGPLライセンスで配布しなければならないという規約があり、ちょっと厳しいライセンスです⁴。

　しかしPostgreSQLは独自の「PostgreSQLライセンス」というライセンスを使用しています。これはBSDライセンスをもとにしたライセンスで、ほとんど制限がありません。そのため、PostgreSQLをベースにした商用RDBMSも各社から発売されています。

表2.1: 各社から販売されているPostgreSQLベースの商用DB

企業	製品名	特徴
EnterpriseDB	EDB Postgres	Oracleとの互換性に優れている。
富士通	Enterprise Postgres	透過的データ暗号化機能を備えている。
Pivotal	Greenplum	マルチコアの並列処理が得意。

　表2.1に挙げたものはほんの一部に過ぎません。その他、Amazon RDS⁵でもPostgreSQLを使うことができますし、Amazon Aurora⁶もPostgreSQLと互換性があります。

　これらのRDBMSはベースがPostgreSQLとはいえ有償で販売しているものであり、購入費用やサポート費用が必要です。しかしコミュニティが公開しているPostgreSQLに関しては、当然、本書を執筆している筆者も、お読みいただいているあなたも、無償で自由に使用することができます。

2.3.2　豊富な拡張機能

　PostgreSQLはオープンソースソフトウェアであり、また比較的自由なライセンスを採用しているため、PostgreSQLの機能を補う拡張機能が有志によって開発・リリースされています。

　そのうちいくつかの拡張機能をご紹介しましょう。詳細は省きますので、使用する場合は各自調べてください。

pg_stat_statements

　SQLの性能問題はDBMSを使用する上で避けては通れない道です⁷。PostgreSQLには時間がかかったSQLをログに出力する機能は存在しますが、さらに情報を必要とする場合に有効となるのがこの拡張機能です。

　SQLごとの実行回数や平均実行時間など、SQLの性能を確認するのに重要な情報を取得することができます。

pg_hint_plan

　PostgreSQLでは稼働しているインスタンスから統計情報という情報を収集しており、SQLがどのように実行されるかは、統計情報からPostgreSQLが実行計画を決めて実行するため、使用者が制御するのは困難です。

　しかし、この拡張機能を使うと、SQLに実行計画を指示することができるようになります。便利な拡張機能なのですが、本来であればSQLの実行はPostgreSQL任せにするのが理想ですので、使いすぎには注意です。

pg_statsinfo

　PostgreSQL稼働状況を定期的に収集・蓄積してくれるツールです。日々の状況を把握でき、性能劣化の兆候や問題発生時の原因特定に役立ちます。

　同じ拡張機能のpg_stats_reporterと組み合わせることでブラウザ上からグラフィカルに収集した情報を確認することができます。

　　

　他にもデータベースを停止することなくテーブルの再編が行えるpg_repack、バックアップとリストアをやりやすくするpg_rmanなど、数え切れないくらいの拡張機能があります。「こういう機能がないか」と疑問に思ったら、調べてみると何かしら出てくると思います。

2.4　なぜPostgreSQLを使うの？

　さて、本書ではこれから今までご紹介したPostgreSQLを使用します。しかし、他にもRDBMSはあるのに、なぜPostgreSQLなのか？と思った方もいるかも知れません。

　確かに、シェアで言えばOracle、MySQL、SQL Serverには遥かに及びませんから、覚えるならそちらのほうがお得だと考える人もいるでしょう。

　それなのになぜ、あえてPostgreSQLなのでしょうか。理由は以下の通りです。

　・無償で使用できる

　PostgreSQLはオープンソースソフトウェアであり、かつライセンスでもかなり自由に使うことが許されています。初心者の練習にはもってこいと言えるでしょう。

　しかし、同じオープンソースのMySQLも当然無償で使用できますし、商用ソフトウェアであるOracleやSQL Serverも試用版があります。これだけではPostgreSQLを使う理由にはならないでしょう。

　・標準SQLに準拠することを重視しており、SQLの練習にちょうどいい

　RDBMSは、データの定義や操作をSQLという言語⁸で行います。そして、ISOによって何年かに一度標準SQLというものが策定されており、PostgreSQLはこれに準拠することを重視しています。ですから、PostgreSQLでSQLを学ぶことで、他のDBMSを使うときにも応用できるでしょう。しかし、残念ながら100%標準SQLに準拠しているRDBMSは存在しません。SQLは製品ごとに方言があるのが当たり前⁹で、決まった製品を使う予定があるならそれを使うべきで、これも決め手には欠けます。

　・今注目のDBMSの一つである

　これは本当です。ドイツのハイルブロンにあるITコンサルタント会社のsolid IT社が毎年発表しているデータベース・オブ・ザ・イヤー¹⁰に、PostgreSQLは2017年と2018年の2年連続選ばれました¹¹。RDBMSに要求される機能を幅広く実装しており、開発コミュニティも活発で、技術者からも信頼があり、様々なシーンで採用が増えています。AWSでもAzureでも使用できるようになっていることから、今後も需要が見込めると思います。シーンの最前線に立ち続ける覚悟はあるという方は、使い方を覚えて損はないでしょう！

　・好きだから

　結局のところ、これです。好きだから広めたい。みんなに使ってほしい。みんなに良さを知ってもらって、さらに広めてほしい。かなり個人的な理由ですがそれが一番大きな動機ですよね。

2.5　日本PostgreSQLユーザー会

　日本PostgreSQLユーザー会は、日本におけるPostgreSQLの普及と発展を主な目的とした、PostgreSQLユーザーによる組織です。

　イベントも定期的に行われており、そこでPostgreSQL有識者と交流することができます。

　その他にもメーリングリストで質問を投げかけることもできますし、日本語のSlackチャンネルもあり、初心者もたまに質問を投げかけていますが、親切な人が答えてくれます。ぜひ、何か困ったことがあったら活用してみてはいかがでしょうか。