楽々ERDレッスン読み終わり。

楽々ERDレッスン

とても実践的な内容で私は好き。

業務変更に強いDB設計にはテーブルの「主キーに自動採番のID(サロゲートキー, 代理キー)を設定する」こと、IDによってJOINさせること。コード(ナチュラルキー)ではないことが徹底されて書かれている。

@see

なぜIDを主キーにするのか？

正規化の教科書ではコードで連結されるのですが、コード(*ナチュラルキー)は業務体系が変わると変更しなくてはいけなくなる。最初は変更はないとしても、お客様やビジネス上の都合で変更しないといけない時がある。その時にIDを利用していればそういった変更に対しても問題がない。

IDを設定することでテーブル間の依存性が弱まり業務の変更に強くなる。
IDを利用するので、複合主キーは存在しなくなる。複合主キーを許さない。
またFrameworkのORMで自動採番のINT型のIDが採用されていることもあって相性が良い。

*ナチュラルキー･･･社員ID, 会社番号, 商品コードなど。自然キーとも呼ぶ。ナチュラルキーは業務に直結しているのでわかりやすいが、業務が変わりコード体系の変更の必要性が生じると変更が大変になる欠点がある。

後半はレシートや明細書からテーブル設計をしていく内容で実践的でわかりやすい。

テーブルの主キーに自動採番のID(アイデンティファ)を必ずつける

IDを利用することで業務上の変更に強くなる。JOINはIDで行う、コード(ナチュラルキー)ではない。

IDは一意な座標であり、IDに意味があってはならない。
テーブルとの紐づけはIDで行う
コードについてはFKとして利用しない。結合はIDで行う。
そうすることで業務的にコード体系が変わっても変更できる柔軟性がある、コードをFKに利用していると変更できなくなる。

事実を記録する

履歴などはシステム的に正しいものではなく、事実を記録する。

売上明細の合計金額
商品単価 × 個数で算出できるから必要ない？
実際は割引やセールなどが発生する、
売上明細については「合計金額」という事実を表す列をつくる。
単価は一つじゃない
顧客別単価、得意先単価、特別単価、期間別単価・・・など様々な単価が存在する。
顧客は「単価」と一言でしか呼ばないが、業務の現場では様々な複数の単価が存在する。しつこく聞かないと出てこない、様々な価格に関する事実が存在するケースがある。

イベント系を見出す、そしてリソース系

イベントを見出す

『〜する』という行為。動作を見出す
『注文する』
出来事
イベントのエンティティには日時カラムが発生する
・【〜日】といえるかどうか
・日時が発生するものか

イベントからエンティティを見出す

【誰が】
顧客が
【何を】
商品を
【明細】, 【詳細】を派生。
イベントIDをFKとする詳細、明細エンティティが生まれる場合がある。

テーブルの１つにカラムを追加してもリレーションが変わらない

リレーションが安定している。
テーブルの構造が安定した設計

SQLはバッチ処理

すべてのSQLはSELECTに始まり、SELECTで終わる
・UPDATEを行う際のWHEREはSELECTで見つける。
・テーブルがあるのか検索する際もSELECTが走る。
内部的にSQLでCRUDのどの処理をするにしてもSELECTが走る。
→SELECTが走るということはINDEXが重要
INSERTですらSELECTを行う
テーブルの有無、列のデータ型チェック

遅くなるから非正規化？

テーブルを増やすと容量がかかる？
１レコード256バイトなら1億レコードで24GB。容量は考慮する必要がない。
ディスク容量の単価が高い時代の話で今は気にしなくて良いし、クラウドなら後から増やすことも容易。
JOINが遅くなる？
今のCPU性能なら気にする必要がないぐらい早い。

正規化は行うべき。

複雑な業務内容だから、それを表現するとテーブル数が多くなるのは仕様がない。

[amazon_link asins=’4798110663,4297107171,4873115892′ template=’ProductCarousel’ store=’izayoi55-22′ marketplace=’JP’ link_id=’1ac3b791-fc3d-4823-86ed-cd7960af27ad’]