DB設計
データベース設計の基本について
本ブログについて
現在、Railsエンジニアを目指してFjord Boot Campで学習しています。 スクールの課題や自己学習の気づきをこちらのブログで掲載しています。
データベース設計(以下、DB設計と略)とは
システム開発において、業務を抽象化し、どのような情報をデータベース上で管理すべきかを設計すること。 そして、このDB設計のプロセスの中核をなすのが「正規化」です。
正規化とは何か
データの重複を排除し、整合的にデータを取り扱えるようにDBを設計することを、データベースの正規化と呼びます。
例えば、普通の伝票などをイメージしてみてください。
1つの仕入先に対して複数の商品が繰り返し存在していたり、必ず重複があるはずです。このようなテーブルは非正規形に該当します。
非正規形のデータから重複を排除していくプロセスを正規化と呼び、通常は以下のように３段階のプロセスで構成されます(本記事では説明を割愛します)。
第1正規形
- 繰り返し項目を持たないようにレコードを分割する
第2正規形
- 第1正規形を満たしている
- 主キーになっている項目の一部だけで決定される項目を分割する
第3正規形
- 第2正規形を満たしている
- 主キー以外の項目によって決定される項目を分割し、計算て求められる項目を削除する
DB設計の構成要素(ざっくり)
DB設計における重要な要素は以下の4つです。
- エンティティ(箱)
- 属性(アトリビュート)
- リレーションシップ
- カーディナリティ(関連の多重度)
まず、エンティティについて。エンティティとはデータベースのモデリング(ここではDB設計)における管理対象のことです。 以下のように、人や物、場所などのリソースから注文や販売などイベントまで様々な物を表します。
- 顧客
- 売上
- 発注
- 商品
- 学生
エンティティの種類については様々な分類が存在しますが、代表的なものが独立エンティティと依存エンティティです。
データベース設計の対象を中学校と仮定します。エンティティは「クラス」と「生徒」です。
クラスは単独で存在しますが、生徒は必ずクラスに所属しており単独では存在しません。この場合のクラスを独立エンティティ、生徒を依存エンティティと呼びます。
また、この場合クラスと生徒は「親子関係にある」とも言います。
2.の属性(アトリビュート)とは、エンティティの構成要素のことを指します。データ項目と考えるとわかりやすいかもしれません。
属性は大きく、キー属性と非キー属性に分類されます。キー属性は更に細かく分類できますが、主要な項目は以下の２種類です。
- 主キー(primary key)
- 外部キー(foreign key)
主キーはエンティティ内でデータを一意に識別できる属性のことです。生徒の例でいうと、生徒番号や学籍番号です。 生徒番号が分かれば、その生徒の情報が一意に取り出せるという訳です。
外部キーは、親にあたるエンティティを参照するための属性です。先程の例で言うと、親エンティティであるクラスの主キー(「クラスコード」)が子エンティティ(生徒)の外部キーとして表示されます。
非キー属性はキー属性以外のデータ項目のことです。
3.のリレーションとはエンティティ間の関係を表すもの、4.のカーディナリティはリレーションにおいて、親と子がそれぞれ何対何の関係であるかを定義したものです。カーディナリティは以下のように分類されます。
- 1対1
- 1対n
- 多対多(m:n)
先程の中学校の例では、クラスは通常複数の生徒を持つため、クラス対生徒の関係は「1 : n」と言えます。
これらの要素を用いて、データベースの関連を表した図を「ER図」と呼びます。ER図はEntity Relationship Diagramの略で、データベース設計には欠かせない設計ツールです。
ER図の種類について
- IE記法(リレーションが鳥の足のような形をしている)
- IDEF1X記法(リレーションを●で表現する)
代表的な種類は上記の２種類です。直感的に理解しやすいと言われているのはIE記法の方です。ER図の作成ツールなどによっても種類が異なります。
無料の作成ツールがたくさん存在しますので、検索してみてください(上の例では ERDPlusを使用しました)。
twitterのER図を書こう
BootcampのプラクティスではSNSのER図を作成する課題が出題されました。カンニング防止のため、成果物は載せられないのですが、 理解する上で参考になった内容をご紹介します。
twitterのサービスの中でも代表的な機能がフォロー機能です。
ブロックされていない限り、ユーザーは好きなアカウントをフォローできます。そして、お互いをフォローし合っている状況を「相互フォロー」と呼んだりしますね。
このフォロワーとフォロイーの関係は、1対nの関係で定義することができないため、どうER図で定義するかが非常に難しく感じるポイントでした。
カーディナリティで言うと、フォローは多対多の関係(m:n)を表していると言えます。
そこで、重要になるのが中間テーブルの考え方です。
フォローの申請元ユーザーとフォローの申請先ユーザーの間にもう一つテーブル(Relationshipテーブル)を挟み、そこでお互いのid(外部キー)を保存してあげるのです。
そうすることでお互いの結びつきを正しくDBに記録することができ、検索も容易になります。
この中間テーブルについては、RailsのDB設定・作成において多対多の関係を「関連付けする」際に非常に重要な概念になるため、理解が必須となります。
中間テーブルを理解するには？？
非常に参考になる記事を載せましたので、興味のある方はご一読ください。
最後に
DB設計を学ぶことで、後のクラス図作成やオブジェクト指向の理解へと繋がるため、この段階でしっかり理解できるようしたいですね。
参考文献:
