カテゴリーが削除されたかのboolean値。id、actはそれぞれuser、memoと同じなので割愛する。nameに関してもmemoのtitleと設定は同じなので更に割愛する。このテーブルで唯一、新たな役割を持つのがparentカラムだ。親のidここで初めてNULLが登場することになる。許可する設定であればデータ型に関係なく設定できる値となる。プログラミング言語の世界では独立した型であることが多いので理解に注意が必要だ。許容する場合は「NULL」にチェックを入れればOKである。このparentカラムの役割はカテゴリーの親子関係を表すことである。NULLなら最上位のカテゴリー、parentに既存カテゴリーのidが設定されていればそれが親カテゴリーとなるといった具合に設定すれば、親は必ず一つ、子は複数の通称「木構造」を作ることができる。カテゴリーがあり、「仕事」カテゴリーの子カテゴリーとして「緊急」というカテゴリーがあったとするならばcategoryテーブルは以下のようになるだろう。・直近の親を探す時は自身のparentとidが一致するレコード(親)・直近の子を探す時は自身のidと一致するparentを持つレコード(子)・自身と同じ親を持つカテゴリーを探す時は自身のparentと一致するparentを持つレコード(兄弟)という検索を行うことができる。この設計には直近ではない親や子、つまり先祖レコードや子孫レコードを一発で取得できないという弱点が存在する。ナイーブツリー)」と呼ばれる設計モデルで、ある程度小規模な木構造ならあまり問題にならないが、大量のレコードを扱ったり高速な検索を行うには不向きだ。今回は名前の紹介に留めるが、大規模な木構造データを実践開発する際は以下4種類の設計モデルを検討してみよう。(肥沃な森林モデル)中間テーブルで多対多へ対応する最後にmemo_category_relationテーブルを作成しよう。設定のidを設定してきたが、このテーブルのみ設定が違う。idというように設定する。おいてはそれぞれのカラムが一意性を保つ必要があった。よってidカラム一つで一意性を保っていたが、このmemo_category_relationテーブルではmemo_idとcategory_idの2カラムによる複数主キーによって一意性を保つ。このmemo_category_relationテーブルにおいては、片方が他のレコードと被ってももう片方が被っているレコードと違えばOKということだ。このテーブルの役割はメモとカテゴリーの関係を表すことだが、ユーザーとメモの関係はお互いのテーブルだけで済んでいたのになぜ今回は第三のテーブルが必要なのだろうか。それはユーザーとメモの関係は1対nなのに対しメモとカテゴリーの関係はn対nだからである。対して、あるメモが属しているカテゴリーは0~複数存在する可能性があり、あるカテゴリーに属しているメモも0~複数存在する可能性があるという違いがあるのだ。このようなn対nの関係を表現するには「中間テーブル」と呼ばれる第三のテーブルが必要になる。このテーブルは物理削除を想定しているためactカラムを用意していないが、メモに対するカテゴリー登録の記録を削除後も残しておきたいのであれば論理削除用にactテーブルと重複防止用にidカラムが必要になるので注意しよう。まとめデータベース設計に慣れないうちは直感的ではない常識や振る舞いに四苦八苦するだろうが、実際にそのデータを扱ってサービスを稼働させるバックエンド・フロントエンド開発と合わせて勉強していけば自ずと理解できる時が来るだろう。データを操作するデータベースという仕組みは知れば知るほど奥が深く、楽しいものでもある。この記事がとっつき辛いであろうデータベースという開発領域の敷居を下げ、読者が興味を持つきっかけになれば嬉しい。どんなに見た目が変わろうと、何時の時代だって大抵のサービスは、何らかのデータを映し出す鏡なのである。コメントをキャンセル入力エリアすべてが必須項目です。designerTwitterhttps://twitter.com/Facebookhttps://www.facebook.com/others小田原産Webエンジニア。フロント/バック半々。最近はCodeigniterでECサイトばっかり作っている。