まさ@ブログ書き込み中

自由に生きるための英語、プログラミング、考えごとについて色々書いています。

『楽々ERDレッスン』を読んだので感想をまとめた【DB設計】

 

こんばんは、昨日のRubyKaigiに関する記事がたくさんの人に読んでもらったようで嬉しいまさです。

 

今日は、僕が会社の研修の一環として読んだ本についてまとめたいと思います。その本のタイトルは「楽々ERDレッスン」です。

 

楽々ERDレッスン (CodeZine BOOKS)

楽々ERDレッスン (CodeZine BOOKS)

 

 

今回はこの本について書いていこうと思います。

 

 

ERDってなに

この本がどんな本なのかは、ERDという言葉の意味を知ることでわかります。ERDとはエンティティ・リレーションシップ・ダイアグラム(Entity Relationship Diagram)という意味です。「エンティティの関係図」ということですね。それでは、エンティティとは何でしょうか。

 

少し他のサイトを調べてみると、以下のように書かれています。

具体的にどんな存在のことをエンティティと呼ぶかは分野や製品によって異なるため一概には言えないが、一つの物事を表すひとまとまりのデータの集合などを意味することが多い。類義語には「インスタンス」(instance)、「オブジェクト」(object)などがある。

エンティティ(実体)とは - IT用語辞典

 

この本でも「箱」と言ったり「集合」といったりしています。とにかく、ここまでこればエンティティが何か掴んだのではないでしょうか。この本はテーブル設計、DB設計に関する本なのです。

 

 

本の構成

本書は大きく分けて三部から成り立っています。

 

  1. DB設計総論:DB設計の基礎知識、正規化など
  2. RDBMS総論:RDBMSの必要性、経営資産としてのDB設計など
  3. 楽々ERDレッスン:演習を通してDB設計をする

 

正直に言って、第二部は小難しい割に、僕にとって身近に感じれなかったので、もし実際に使うDB設計について学ぶとしたら、第一部と第三部から学んだ方がいいと思います。

 

 

本書を読んでの感想

この本は先の構成から見ての通り、まず色んな視点からDB(RDBMS)について理解をして実際のDB設計のトレーニングを行います。

 

僕がこの本の後に読んだ『達人に学ぶDB設計徹底指南書』と比べると、とにかく実務を意識した内容になっていた気がします。それが故に基礎知識だけをとにかく頭に入れたい人にとってはあまり興味無いかも・・・。

 

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

 

 

例えば、あるテーブルの主キーとして「コード」を利用するケースが実務の現場にはあるらしいですが、本書の著者からするとそれはあまり好ましく無いと口すっぱく言われます。ある属性によってレコードが一意に決まるとしても、ビジネスの論理で変わりうるからです。

 

例えば商品名をカラムに持つ「商品」テーブルの「ビール」の商品コードがA001だとして、ビール以外の商品はA001以外のコードが振られるようになっていたとしましょう。確かに商品コード(A001)は商品テーブルのビールというレコードを一意に決めますが、所詮それは会社側が割り振ったコードなので、ビジネスの都合によって(例えば取引先が商品コードを変えたなど)商品コードが変わったとき、一意性が失われてしまいます。

 

そのため、各テーブルにはそのエンティティが表したい情報とは全く関係ないアイデンティファイア(ID)を割り振るべきだと言っています。Railsをやっているエンジニアからすると慣れ親しんだ考え方ですね。

 

ちなみに、『達人に学ぶDB設計徹底指南書』の中では主キーに関するそういった言及はなかったと思います。

 

 

印象に残ったポイント

先ほどエンティティの概念について説明しました。実際のDB設計ではそのエンティティをうまく考えつき、切り分けることが大切になります。例えばTwitterのようなアプリを作るならUserエンティティとPost(Tweet)エンティティが必要になるな、とかフォロー関係を表すRelationshipエンティティが必要になるな、といった具合にです。

 

そういったエンティティを思いつくポイントとして、本書ではエンティティの種類を二つに分けています。一つはイベント系エンティティ、もう一つはリソース系エンティティです。

 

イベント系エンティティは何らかの行為に関するエンティティです。言うなれば動詞で言い表せることです。Twitterの例で言えばフォローする、フォローされるという実態をRelationshipエンティティとしました。あるお店のあらゆる情報を扱うDBであれば注文エンティティがあるでしょう。

 

リソース系エンティティは実際に在るモノに関するエンティティです。TwitterでいえばUserやPostがまさにそれです。お店のDBであれば店舗、顧客、従業員のエンティティが思いつきます。

 

 

DB設計がアプリケーションの形をつくる

設計というのはとても大切なことです。なぜなら、設計がそのモノを決めるからです。どこかで「物事は二度作られる。まず最初に想像され、次に製造される」というような言葉を聞いたことがありますが、まさに設計(デザイン)というのは一つ目の想像に近い行為です。プログラミングは二つ目の製造の方です。

 

さて、そういった意味でどんな物事においても設計は重要なのですが、DB設計はDB自体(テーブル)のあり方を決めるだけでなく、ソフトウェアのあり方を決め、会社のあり方を決めるという意味で大変重要です。

 

本書ではそういった考え方をデータ中心アプローチと読んでいます。これはどういったことなのでしょうか。

 

ある形でDBが設計されると、そのDBに合わせたI/Oの方法をアプリケーションは取るように作られます。極端な例ですが「あるユーザーの購入した商品を知りたい」となった時に該当するテーブルが「注文テーブル」なのか「ユーザーテーブル」と「商品テーブル」の組み合わせなのかによってSQL文が変わります。処理速度、得意なことも変わるかもしれません。

 

また、DB設計の段階で無駄なデータを保持しないことにすれば、無駄なトランザクション(アプリケーションとDBの間の一連の処理の単位のこと)が排除され、無駄なUI(クライアント)を作らないことになり、社員の無駄な役割がなくなるわけです。更に言えば、無駄な組織(部署)は解体されます。

 

このように、DB設計のあり方によってアプリケーションや会社のあり方さえも変わる可能性があるのです。

 

 

最後に

これで僕が読んだ『楽々ERDレッスン』のまとめは終わりです。本書はDB設計のみならず、RDBMSやDBの価値について実務の例を多く交えながら学ぶことのできる本です。

 

個人的には、興味のないところや難しいところは読み飛ばしておいて、必要になった時に読み返すのがいいのかな、と思います。

 

それでは、今日はここまで。ありがとうございました。