DB設計 基本の鉄則3カ条とは？／SQL Server 2014が間もなく登場！：Database Watch（2014年3月版）（2/3 ページ）

[加山恵美，＠IT ]

正しいデータベース設計でデータベースを使おう

　次は奥野幹也氏による「データベース設計徹底指南！！」を紹介しましょう。

　奥野氏といえば日本オラクルのMySQLのサポートエンジニアであり、人気ブログ「漢のコンピュータ道」（リンク）の著者でもあります。

　もともとDBエンジニアのための技術勉強会で発表していた内容を、2014年2月14日に開催したIBM DB2のユーザーイベント「Club DB2」でも再演していました。プレゼン資料はSlideShareで公開されています（リンク）。

　この日の奥野氏は「個人」としての参加だったこともあり、こんなファッションでした（写真）。よく見ると、服には「GPL3」、さらに帽子には「GNU」。ライフワーク「自由なソフトウェアの普及」をアピールしていたんですね。

　さて本題です。この日のテーマは「データベース設計」。奥野氏は「データベース設計の欠陥は技術的負債になる」と指摘していました。もし、データベース設計が正しくないと、SQL文が無駄に長くなり、検索条件が複雑化し、結果的に性能が遅くなる事態を引き起こしかねません。

　さらに奥野氏は「データベースはリファクタリングが難しいため、放置された負債はさらに足かせに」と述べ、正しくない設計をずるずると引きずると致命傷にもなりかねないと警告していました。

　なぜ、正しくない設計のまま進んでしまうのでしょうか。それは単純に正しい設計が「分からない」からなのでしょう。

　奥野氏は冒頭に「RDBMSを使いこなすには『データモデルは超重要！！』で、RDBMSにおけるデータモデルとは『リレーショナルモデル！！』」と力説していました。そうか、私たちはまず、データモデルやリレーショナルモデルの何たるかを知るべきなんですね。

　では「リレーショナルモデル」を考えてみましょう。RDBMSにおける「リレーションとは？」と聞かれたら何を思い浮かべるでしょうか？ 筆者は最初、テーブルとテーブルの間に線が引かれた図を思い浮かべました。いわゆる「リレーションシップ」です。しかしこれでは「×」。間違いだといいます。

　RDBMSやSQLはもともと、集合論をベースにしています。それゆえ、RDBMSにおけるリレーションとは「（ある物事に対する事実の）集合」が答えとなります。RDBMSなら、おおよそテーブルの概念に近いと考えていいそうです。

　では「集合」を考えて見ましょう。ざっくり言うと「射影」は集合の中の1つの成分を取り出したもの、「直積」は集合と集合を掛け合わせた集合、「制限」は部分集合、といったところでしょうか*。

*注：ここでは、概念を簡便に紹介するにとどめています。正確な集合論の知識は専門文献で確認してください。

　これらの演算はSQLを考える上でとても重要です。なぜかは、SELECT文を思い出してもらえればお分かりかと思います。SELECTは「射影」、FROMは「直積」、WHEREは「制限」の概念に相当するからです。

　そして評価順序は、「FROM」→「WHERE」→「SELECT」の順になります。こういうこと、知っているのと知らないのとではデータベースと向き合うときの考え方が変わってきます。

　こうした基礎をきちんと理解することが正しいデータベース設計へとつながるのではないでしょうか。ぜひ、SlideShareで公開されている資料によく目を通して、リレーショナルモデルについての理解を深めてください。

　発表の最後に奥野氏は「DB設計鉄則三カ条」を大きな声で読み上げてくれました。

編集部注　この格言を、デザイン化しようと編集部が発注したところ、ありがたい画像が出来上がったのでこちらからダウンロードできるように致しました。ぜひ、飾ってください！

　余談ですが当日は2014年2月14日。関東を襲った大雪の日です。開始時点で既に雪は激しくなっていました。期待されたテーマでしたので70名ほどの参加登録があったにもかかわらず、実際の参加者は悪天候で半減してしまいました。しかし、UST中継の閲覧者は過去最高を記録したそうです。皆さん、雪で参加を断念したものの、ネット経由で聞いていたんですね。