ライターの内藤です。普段は主にコーディングやサーバ管理などを担当しております。その前は小規模データベース技術者、兼C++プログラマでした。地味です。
聞いたことがある方も多いと思いますが、WordPressはMySQLというデータベースに依存しています。この記事も、MySQLに保存された文字や写真などのデータが様々な条件で取り出されて、みなさんにこうして見てもらえています。でも、実際にそれがどのように働いているのか、ご存知でしょうか。
データベースはWordPressをはじめ多くの分野で利用されているので、基本的な構造を理解しておくと、少なくともWordPressのインストールやカスタマイズで悩む機会は減るはずです。
そこで今回はWordPressのMySQLを題材に、データベース（正確には広く普及しているリレーショナルデータベース）と、データモデリング（後述）の基本について簡単にご紹介したいと思います。
目次
データベースとは
まず、データベースとは「Database = Data（データ） + Base（基地・拠点）」という意味の造語です。よくDBと略されます。
データベース（英: database, DB）は、特定のテーマに沿ったデータを集めて管理し、容易に検索・抽出などの再利用をできるようにしたもの。狭義には、コンピュータによって実現されたものを言う。OSが提供するファイルシステム上に直接構築されるものや、データベース管理システムを用いて構築されるものを含む。
出典：データベース – Wikipedia
つまり、電話帳やテレビ番組表もデータベースと言えなくもありません。でも今回は、狭義である「コンピュータによって実現されたもの」について説明します。
エクセルはデータベースか
データベースの説明をすると、必ずと言っていいほど聞かれるんです、「エクセルでもできるじゃん」と。もちろんエクセルをデータベースとして使うことも可能です。でもここで、以下で示すような条件について考えてみます。
図で示したようなエクセルの表について、
- IllustratorやPhotoshopはWeb制作のカテゴリもつけたい。PhotoshopにはWebデザインというカテゴリも追加したい。
- 毎年4月1日に公開されているものだけ取り出したい。
と思ったとします。
それぞれについて対応を考えてみると、新しい欄を設けたり、マクロを書いたりしないと難しそうです。
でも、めんどくさいなぁ…と思ったあなたに朗報です。後述のDBMS（DataBase Management System）を使えば、これらのことを簡単に実現できてしまうのです。
ちなみに、このように、いかにデータを簡単に管理するかを考えながら表を作っていく（設計する）作業をデータモデリングと言います。データモデリングされた表が、データベースであるとも言えます。
色々なデータベース
さて、みなさんはデータベースを何個ご存じですか？
MySQL、Access、SQLServer、PostgreSQL、FileMakerなど、色々と挙げられそうな気がしますが、正確には全てDBMSというデータベースを扱うシステムの名称で、データベースそのものではありません。
普通はめんどくさいので、「データベースは何を使いましょうか？」のように言われます。その文脈ではつまり「DBMS何を使おうか？」という意味です。
結局、データベースとは
一方、WordPressのインストール画面で入力するべき「データベース」名とは、1つのテーマに沿ったデータか、データを取り出す仕組みも含めた「ひとかたまり」のことを指します。
この「ひとかたまり」について、MySQLとAccessを例にして視覚化してみると下図のようになります。
このように、データベースという言葉には複数の使い方があり、最終的には文脈で決まります。
ここでは、この「ひとかたまり」をデータベースであるとして、その中身がどのようなものか見ていきたいと思います。
データベースの中身について
MySQLの中身をブラウザで視覚的に見られるphpMyAdminというウェブツールがあります。これでMySQLの中身を見てみると、大抵「テーブル」と呼ばれるものが並んでいて、「ビュー」や「トリガー」なども見られるかもしれません。
また、Accessのファイルを開くと、テーブル・クエリ・レポートなどなどが1つのファイルに入っているのがわかります。
「ひとかたまり」のデータベースには、このように「テーブル」を中心として、データを取り出す仕組みなどがパックになって入っています。
中心になるのはテーブル
この「テーブル」こそがデータをためておく場所ですが、難しいものではなくて、普通の表を想像してもらえれば大丈夫です。
横並びに項目名があって、縦方向にデータが並んでいる表です。エクセルなどでよく作るアレ。
DataのBaseなので、このデータをためるテーブルが中心になります。
最初に説明した通り、このテーブル設計を誤るととんでもなく使いづらくなってしまいます。逆に言えば、上手く設計できたらこの上なく便利になります。というわけで、ここからはテーブル設計≒データモデリングについて書きたいと思います。
WordPressのデータモデリングを見てみよう
データモデリングとは「ある目的に合わせてデータを簡単に管理するかを考えながら表を作っていく（設計する）作業」と言えます。では、簡単にデータを扱えるとはどういうことでしょうか？WordPressを例に考えてみたいと思います。
そもそもWordPressは、ウェブサイトの中身（文字や画像など）を、簡単に見せたり作ったりできるようにするのが目的です。では、どういうテーブル（表）を作ったら、アップロードされたデータを活用してウェブサイトを作ることができるでしょうか？
実物を見てみよう
下図のようなWordPressのテーブルをご覧ください。
※デフォルトのテーブル名となっています。環境によっては「wp」が違う文字列かもしれません。
これはWordPress3.8.1を動かすデータベースのテーブル一覧です。私は最初にこれを見たとき、たった11個のテーブルがWordPressを支えているということにビックリしました。ここにWordPressのデータモデリングの面白さが詰まっています。
各テーブルについて簡単に説明します。
- wp_commentmeta
コメントに付随するデータを保存します。例えば、スパム対策プラグインがどのように判定したか、などもここに入ります。 - wp_comments
ダッシュボードの左メニューにある「コメント」で見られるデータです。コメントの本文や日付、コメントした人のブラウザ情報などが保存されます。 - wp_links
WordPress3.5未満の時に管理画面にあった「リンク」を利用していた場合以外はプラグインLink Managerで管理画面に出せるリンク集の情報です。 - wp_options
主に管理画面の左メニュー「設定」「外観」の中で設定する項目を保存しています。サイト名やパーマリンクを始め、使用中のテーマやウィジェット情報もここに保存されます。 - wp_postmeta
投稿・固定ページ・カスタム投稿に付随するデータを保存します。カスタムフィールドなどはここに保存されています。 - wp_posts
投稿・固定ページ・カスタム投稿の本体です。タイトルや本文、更新日時などが保存されます。 - wp_terms
管理画面の「投稿」から見られる「カテゴリー」が保存されます。カテゴリーに加えて、タグ・タクソノミーの名前もここに保存されています。 - wp_term_relationships
カテゴリー・タグ・タクソノミーと記事を紐付けるためのテーブルです。 - wp_term_taxonomy
カテゴリー・タグ・タクソノミーのシステム上の名前が登録されます。 - wp_usermeta
主に管理画面の左メニュー「ユーザー」の「あなたのプロフィール」で見られるユーザー名・パスワード・メールアドレス以外の情報が格納されています。ユーザーのニックネームや表示名などが格納されます。 - wp_users
管理画面の左メニュー「ユーザー」で新規追加する時に必要な情報が主に格納されます。ユーザー名・パスワード・メールアドレスが主です。ただしパスワードは暗号化されて格納されますので、ここを見てもわかりません。
詰まりそうなところだけ念のため抜粋して解説しておきます。
- カスタム投稿とは
- 最初からある「投稿」「固定ページ」とは別に、独自の入力画面や書式、カテゴリーを持たせたものを指します。
- タクソノミーとは
- カスタム投稿に紐付ける独自のカテゴリーのことを指します。
ここでは、赤い文字で書いた、記事にまつわるテーブルについて、データモデリングの観点から見てみます。
投稿・固定ページの正体
WordPressの「投稿」も「固定ページ」も実は同じテーブルに保存されています。つまり、この2つは同じモノ扱いなのです。
では、どこでそれが区別されているのか？下図をご覧ください。
これは、テーブル定義と呼ばれる表です。一般的に言うところの項目がどんなものなのかを定義しています。「タイトルは文字が入るところだよ」とか、「IDは数字しか入らないよ」とかそういうことを定義しています。
この中で、post_typeという項目をご覧ください。デフォルト値が「post」となっています。当然ですが、postとは「投稿」です。
そう、ここが「投稿」と「固定ページ」を区別する項目です。では、具体的な中身はどうなっているか、テーブルの中身を見てみます。それぞれ「post＝投稿」「page＝ページ」「revision＝リビジョン」となっていることが分かると思います。
なぜこんな構造を取ったのでしょう？普通なら、投稿は投稿テーブルに、固定ページは固定ページテーブルに…と考えてしまいそうです。
でも、タイトル・本文・投稿日時など、同じような内容の表を別々に作るよりも、1つの表で全ての内容を一元管理してしまえば、いくつものテーブルを見に行く手間も省けます。
さらに、「カスタム投稿」などを作ったときも、新しいテーブルを作らなくてもいいんです。エクセルで言うとシートを分けなくていい、という感じでしょうか。これは便利ですね。
つまり、共通の部分だけを取り出して表にしているとも言えます。ここがデータモデリングの基本です。つまり無駄を省き、シンプルにしていくことが基本になっています。
ここで、共通の部品以外はどうやって管理しているのでしょうか？実は、アイキャッチ画像やカスタムフィールド、その他プラグインで利用する値なども、だいたいwp-postmetaというテーブルで一元管理されています。
そこで、wp-postmetaテーブルの中身を見てみましょう。
post_idごとに赤枠にしてみました。このpost_idには、wp-postテーブルの中のIDが格納されています。つまり、この行がどの投稿に紐付くデータなのかはここで判断できます。
ところで、この図では、post_idが1の投稿には5つの情報が紐付いています。けれども、post_idが2の投稿には3つの情報しかありません。
もし、これをwp-postという投稿のテーブルに入れていたらどうなっているでしょう。項目が追加されるたびにテーブルの定義で項目を増やして、横にどんどん項目を足していくことになります。ただし、各投稿で実際に使う項目は限られているので空欄も多くなってしまうことが予想されます。
しかし、いっそ別のテーブルに分けて、「投稿によって増減する項目＝本来であれば横並びにしたいもの」を縦方向に増やしていくようにすれば、簡単にデータの追加が可能になります。
冒頭にありましたエクセルはデータベースじゃないの？の1は、この方法で解決できます。
WordPressのデータモデリングで面白いと思うところ
カテゴリーに関しても同じことが言えます。WordPressでは、カテゴリーやタグ、タクソノミーなどが利用できますが、これも全て同じカテゴライズのデータとしてwp_termsテーブルに格納されています。
そして、どれがカテゴリーでどれがタグなのかを管理するwp_term_taxonomy、それを各投稿に紐付けて管理するwp_term_relationshipsというテーブルが用意されているのです。
このような柔軟な設計は、ユーザのカスタマイズや、プラグイン開発を容易にしていると言えます。もちろん、バージョンアップでテーブル構造が変わることもあるとは思いますが、最小限の変更で済むような拡張性のあるデータモデリングは、ある意味で発想の転換であり、私は面白いと思います。
最後に
カテゴリーの部分は少し駆け足になってしまいましたが、無駄を省く、共通部分を抜き出すというデータモデリングの考え方が少しでも伝わりましたら幸いです。
普段の生活で、なんかごちゃごちゃ～っとしてきたら、データモデリングの考え方をちょっと思い出してみてください。共通部分を取り出して、残りを別にしてみるといいことがあるかもしれません。
最後まで読んでくださってありがとうございました。
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
