Torihaji's Growth Diary

Little by little, no hurry.

初心者が達人に学ぶDB設計を読んだら達人になれるのか

はじめに

みなさんこんにちは. torihaziです。

今回はこちらの書籍を読んだので、そのアウトプット会になります。

達人に学ぶDB設計 徹底指南書 | ミック | 工学 | Kindleストア | Amazon

前回に引き続き、このデータベース周りは理解が大変でした。

本当に疲れました......

それではl .. t.. g....

よかったこと

稼働させるDBサーバのハードウェアに関する説明があった

どういうことかというと、物理設計に関する記述があったということです。

物理設計とはDBMSを稼働させる実際のハードウェアのサイズ(容量)を決める設計フェーズのことです。

前に読了したSQLドリルには今回のようなハードウェアに関する記述はそこまでなかったのに対し、

本書籍は 1章の1節を丸ごと物理設計の説明に充てられています。

もちろん、実際に扱った経験がないので「そうなんだ」程度の知識でしかありませんが

全く知らない人と比べたらあるほうだと思います。

初めて使うようになった時に「そういえばこういうものあったよな」という引き出しができるので

全く勉強していない人に比べたら有利だと思います。

DB設計のアンチパターンが掲載されている

アンチパターンとは文字通り「やらないほうがいい設計、手法」のことです。

著者がこれまで遭遇してきたものから様々なパターンが取り上げられています。

実務でDB設計を行っている人間による説明なので、詳細に説明がされています。

ただこちらも私は実務で扱ったことがないので、

本当に使えるようになっているかは不安です。

しかし、「聞いたことはある」状態ではあるので他の初心者に比べたら

多少有利であるはずです。

読んでいて一番ありそうだなと思ったのが、「サイクリックな一意キー」ですね。

昨今の人口減少に起因する市町村合併によって日本各地で起きているはずです。

悪かったこと

今回に関してはありませんでした。

ともかく私のレベルがまだまだ書籍に追いついていないなと思いました。

アンチパターンについては

将来自分がやってしまった時に見返すと思います。

DB設計について悩むようなことがあったら繰り返し読み返して

吸収していきたいと思います。

学んだこと

バックアップの種類

バックアップには3つの種類があります。

フルバックアップ、差分バックアップ増分バックアップ

それぞれに使用する場面や用途に違いがあります。

フルバックアップは字の如く、全体のバックアップを取得します。

現時点におけるDBMSを丸々複製して保存するようなイメージです。

スナップショットともいいます。

長所としてはスナップショットを取ることができることです。

短所としては、以下があります。

  • バックアップにかかる時間が長い。
  • ハードウェアにかかる負荷が大きい
  • システムを停止させる必要があること

これだけ長所短所の量に差があるといい所ないのではと思いますが、

フルバックアップ単体で使うことはあまりないそうです。

後述する増分、差分バックアップと併用する形です。

増分バックアップは「増えた分だけバックアップ」で

バックアップ量は一番少なく済むけど、元に戻すのが大変で

差分バックアップは「前フルバックアップからの差分をバックアップ」で

バックアップ量は増分より多いが、元に戻すのは増分に比べたら楽

というものになります。

イメージは下記です。

これが差分バックアップ

これが増分バックアップ

これを見れば違いは一目瞭然ですね。

増分は少なそうだけど、それぞれ繋げて復元することが大変そうだし、

差分は増分に比べたら多いけど、1回で済みそうです。

一般的にバックアップの方式は

となります。要件によって使い分けることが大事、だそうです。

関連実体

難しい日本語です。

この用語はエンティティ間に多対多の関連があるときに使用されるものです。

中間テーブル、Junction テーブルなどとも呼ばれます。

学生テーブルと講義テーブルを次のように定義します

学生コード 学生名
0001 a
0002 b
0003 c
講義コード 講義名
001 線形代数
002 力学
003 流体力学

ここで学生の講義登録状況を表してみると

学生コード 学生名 講義コード (FK)
0001 a 001
0001 a 002
0001 a 003
0002 b 002
0003 c 001

となり一見良さそうですが、これでは講義を登録しない学生はこのテーブルに登録できません。

この問題を解決するために人口的に次のテーブルを作成します。

学生コード 講義コード
0001 001
0001 001
0001 002
0002 002

こうすれば講義が未登録な学生も学生テーブルに登録することができます。

難しかったこと

第二正規系にするにあたって、一方の主キーに部分関数従属しているカラムの見極め方に

苦戦していましたが、この記事を書いている間に理解しました。

そもそも主キーを誤解していたようです。

主キーとはそのカラムの値を指定すれば必ず1行を特定できるというもの。

おそらくこの理解で大丈夫なはずです。

つまづいたらまた戻ってくることにします。

終わりに

いかがだったでしょうか。

このHappinessChainをやってきて

一番しんどかったと思います。

どこまで理解したらゴールと言えるのだろうか

とくに正規形の箇所は正直不安です。

関数従属は理解しましたが、エンティティの定義、抽出ができるかどうか。

とりあえず何度もやって身につけていきたいと思います。

皆さんも頑張ってください。

僕も頑張ります。