|
企画/開発の段階の会議でも――特に技術者が出席すれば――データベースに関する用語がポンポンと飛び交います。その発言や提出資料の意味がまったく理解できないまま生返事で会議を進めてしまうと，あとからいろいろと不都合がでてくることがあります。一番大切なのは，わかったフリはせず，その場で質問して疑問点はすべて解消するという姿勢なんですが，「こんなことも知らないのか」と思われたくないというのは誰にでもある感情ですね。そこで今回は“会議レベルでわかっていたい”データベースの構造を理解しましょう。
Excelとの比較で学ぶデータベース構造
データベースの構造を理解していただくために，今回はMicrosoft Excelを使います。Microsoft Accessではありません。Excelです。なおExcelのバージョンは一切問いません。だまされたつもりで以下の説明どおりに操作してください。
まず「マイドキュメント」の中に新しく「データベースサーバ」というフォルダを作ってください。
 |
| 図1●マイドキュメントの中に「データベースサーバ」というフォルダを作ります |
Excelを起動します。まっさらなドキュメントが開きますから，これを「名前を付けて保存」します。保存するときの名前は「データベース1」とします。
 |
| 図2●まっさらなドキュメントを「名前を付けて保存」します |
 |
| 図3●保存するときの名前は「データベース1」にします |
同様の操作を繰り返してデータベース2，データベース3というファイルを作ります。
 |
| 図4●操作を繰り返してデータベース1からデータベース3までを作ります |
図4のファイル名表示で .xls と最後に表示されているのは筆者の設定によるものです。ファイル名の「．（ドット）」の後ろの部分を拡張子と呼びます。デフォルトのエクスプローラでは拡張子は表示されませんが，なるべく表示するようにしておきましょう。
ここまでの作業が終了したら，データベース1.xlsを開きます。今度はシートです。Excelの下のほうに表示されているSheet1～3のタブを右クリックして「名前の変更」をクリックします。Sheet1を「テーブル1」に変えてください。同様に操作してSheet2と3もテーブル2，テーブル3にします。
 |
| 図5●Excelのシート（Sheet）の名前を変えます |
 |
| 図6●テーブル1～3に変更した |
これで下準備は完了です。ここでデータベース構造の概念を説明してもいいんですが，ちょっとイメージが沸きにくいので，もう少しデータらしきものを入れてみます。
データベースの雰囲気を体験
図7を参考にして，データベース1のテーブル1にデータを入れてみてください。簡易名簿です。図はわかりやすくするために1行目は色を変えたりしていますが，そこまで凝ったことをする必要はありません。
 |
| 図7●テーブル1にデータを入れます |
「都道府県」の列が1，2，3という数字になっている点に注目しておきます。続いてテーブル2のシートです。こちらは2列しかありません。
 |
| 図8●テーブル2にデータを入れます |
これでテーブル1の都道府県欄に入っていた数値の意味が見えてきます。すなわちテーブル1の都道府県欄に「1」と書かれていたユーザーは，テーブル2の都道府県ID「1」の都道府県（東京都）の人らしいというわけです。このテーブル1とテーブル2の関係を「リレーションシップ」と言います。テーブル1とテーブル2の連携によって，あるデータが完成するわけです。リレーションシップについてはまた別に機会を設けて説明していきます。今はなんとなく「テーブル1とテーブル2の間には，つながりがあるんだ」というぼんやりとした認識で結構です。では，テーブル3を作りましょう。
 |
| 図9●テーブル3にデータを入れます |
テーブル3は単独ではとても意味のわかりにくいものになっています。「点数」とありますから，なんらかのテスト結果であったんだろうと推測できます。結果IDというのは単なる連番です。ユーザIDというのは，どうやらテーブル1のユーザーに割り当てられている番号のようです。したがって1行目の「ユーザIDが3の人の点数は68点」というのは，テーブル1を見て「鈴木太郎君の点数は68点」だったらしいということになります。テストを複数回受けた人もいるようです。例えばユーザIDが1の人は，結果の記録が2回（結果IDが5番と9番）があって，85点と87点です。
データベース全体の構成を学ぶ
細かなところがちょっと気になってきましたが（あえてそういう展開にしたんですけど）一度視点を大きなところに戻します。
データベース・サーバの中には，まず“データベース”という単位があります。"データベース"というのはちょっと面倒な単語で，Web＋DBのシステムで定番であるMySQL，PostgreSQL，Microsoft SQL Server，Oracleといったデータベース・サービス（ときにはデータベース・サーバー，データベース・アプリケーションとも呼ぶ）そのものも「データベース」と呼ばれることがあります。この区別は付けておかなくてはなりません。ここでいうデータベースは，テーブルの集合体の意味です。
今回，最初にマイドキュメントの中に「データベースサーバ」というフォルダを作りました。このフォルダそのものが，MySQLやPostgreSQLを示すものです。その中にデータベース1から3までのExcelドキュメント・ファイルを作りました。ファイルに付けた名前そのものが意味するように，これが「データベース」という記録単位です。
データベースの中にテーブル1から3というシートを作っています。これまた名前の通り「テーブル」という単位になります。
各テーブルにはデータを記録する列があります。1列ずつのことを「カラム」といいます。
カラムの集合体がテーブルであり，テーブルの集合体がデータベースです。データベース・システムは，この三つの単位で構成されています。
 |
| 図10●データベースの構造模式図 |
最初にこの図を出してしまうと，どうしてもわかった気にだけなってしまう人が大勢います。じゃあ実際のテーブルというのはどういうものなんだという部分が，すぽっと抜け落ちてしまうんですね。そこでExcelを操作しつつ，ちょっと回り道をしていただくことにしました。ここまできちんと読んでいただいた方にとっては，この階層構造図はまったく意味の違うものに見えてくるはずです。
Web＋DBの1案件では，基本的に1データベースで開発が行われます。その下に案件によりけりですがおよそ20から100のテーブルが作られます。各テーブルのカラム数はまちまちですが，少ないもので3カラム，多いものでは（実際私が体験したものの中では不動産の物件情報テーブルが最多でしたが）150カラム程度になります。
カラム同士はExcelでいうところの同じシートに書かれたものなので，なんら関連性を持ちませんが，先ほども少し見たように，テーブル間はリレーションシップでつながることがあります。すべてがリレーションシップによって連鎖しているということはなくて，完全に独立したテーブルというものもあります。
Web＋DB案件を進めていくうえで，初期の企画段階から開発途中でのプログラマとのやりとりなどにおいても，用語の把握とデータベース構造の把握は非常に大切です。
どうしてExcelで体験してもらったのか
Microsoft OfficeシリーズにはAccessという，ずばりデータベース・ソフトがあります。しかし今回あえて皆さんにはExcelのイメージでデータベース構造を学んでいただきました。その理由を説明しておかなくてはなりません。
例えばECサイトを作ります。Web＋DBシステムです。開発を進めるにあたって何が必要なのかといえば，実際の商品リストです。プログラマは販売のプロではありません。いったいどんな項目で商品を管理すればいいのかがわかりません。そこでプログラマからこういうメールが届きます。
「システム構築と試験のために，商品リストを送ってください」
このメールに対して，間違っても自社製品のカタログをFAXで送ったり，郵便で送付してはいけません。
皆さんには，この段階で商品リストはどう構成されているべきかを検討していただきたいわけです。すなわち，今までやってきたように，Excelの上に直接リストを作ってみてください。シートもきちんと分けます。1シートにベタベタといろんな表を貼ってはいけません。シートはテーブルなんだと考えて作ります。
データベースの構造とExcelの構造はとてもよく似ていて，Excelを見ることでプログラマはテーブルの構成を決めることができます。システムとしての見通しがグンと良くなると同時に，依頼する企業側もおおよそのデータベース・イメージが把握できます。結果的に以後の開発において，双方で真ん中にExcelを置いて，イメージを共有しつつ相談ができるようになります。「商品リストのテーブルに，カラムを一つ増やして欲しいんだけど」といった会話ができるようになれば完璧です。
このときにリレーションシップ構成までを深く考える必要はありません。複雑な構成には大きな落とし穴もあります。
Accessはデータベース・ソフトとして優れていますが，いかんせん最初からデータベース専門用語の山です。したがって「価格リストをください」という依頼に対して，システムに詳しくない経理担当や営業担当がAccessの操作ができるかといった問題がついて回ります。しかしExcelならば，今どきの社会人の一般常識レベルのアプリケーションであり，それほどシステムに詳しくない人でも簡単に作成や確認ができます。簡単であるということは，無駄な誤解が生じないということでもあります。
ちょっと怖い本当の話
きちんとカラム（列）にはまらないようなリストは，データベースに置き換えることができません。例えば価格欄。他の商品は単価が記入されているのに，一部商品だけ「100～200円」というデータが入るものはデータとして成立しません。こうした商品があるのなら，「最低価格」「最高価格」というカラムを作成して，100と200をそこに記入すべきです。
 |
| 図11●データとしてありえない一例。この場合，一つだけでも「価格」とはいえないものが価格欄に混ざってはいけません。「時価」のようなものも不適切です |
 |
| 図12●図11の場合の解決策の一例。すべての商品に対して「最低価格」「最高価格」の二つのカラムで設定します。固定価格のものは最低/最高を同額記入しています |
Excelを使って考えることで，こうした問題を発見しやすくなるというわけです。プログラマはビジネス・モデルに沿ったシステムを作ります。しかしビジネス・モデルが見えない状態では，想像でしか作れません。商品リストを出すのが遅くなると，プログラマは価格というのは固定だろうという意識でデータベースを設計し，システムを構築してしまうかもしれません。そうなると，後から「価格変動する商品がありました」と言っても簡単には直せず，システム全体の作り直しが必要になってしまうというわけです。
リアルなお話をしておきますと，往々にしてこの手の問題はカットオーバー（システムの完成）直前に発覚します。「最終データをください」で届いたデータに上の例のようなものが混ざりこんできます。このあとは言った言わないの押し問答で，依頼主と開発会社の関係がどんどん悪化します。納期は延びる，プログラマは過労で倒れる，依頼主は予定時期のずれ込みで営業的な被害をこうむる…。なんにもいいことがありません。
こうした問題の解決策は二つあります。図12のようなExcelを発注主が考えるか，開発に着手する前にプログラマが作成するか，です。いずれにしてもExcelを真ん中にはさみ，実際の商品データを10でも20でもいいので記載してみます。ベースになるExcelはプログラマに作らせてみて，データはこちらで入れてみるのがベストです。結果的に例外的なデータがあるのかないのか，上の図のような改変が必要かどうかが初期段階でわかってきます。
プログラム業界は慢性的な技術者不足で，孫受け，ひ孫受けといった形態が多数あります。自社の開発陣で足りない分を社外に外注して補っていたりします。最上流である発注主と実際にシステムを作っているプログラマの間に4社，5社が介在していることも少なくありません。何か疑問点があり，プログラマが質問メールを投げても，返答が戻ってくるのは一週間後ということも珍しくありません。これは途中の仲介業者のところで遅延が発生しているためです。
開発/進ちょくミーティングに，毎回開発会社の営業担当だけが来ているときには特に注意してください。できうる限り開発担当と直接メール連絡ができ，理想としては電話で直接やりとりもできる環境が一番望ましいと思います。ただし開発と直接連絡で案件を進めていくと，営業が非常に煙たい顔をしますのでバランス感覚と“大人の配慮”は必要です。
円滑な作業と意思の疎通のためには，データベースとはどういう構造になっているのかを具体的にExcelのイメージで把握しておくことが，とにかく大切なんですというお話でした。
