「楽々ERDレッスン」を読みました

まとめると

  • データベースのテーブル設計をする時に必要な考え方が掴める
  • 現実に即した実例が数個あり理論と実践が近づいたように感じられる(わかった気になる)
  • テーブル設計で聞く「正規化」について解説をしないが、ビジネス要件での正規化についてわかる
  • One Fact in One Place 「1つの事実は1つの場所に

読んだきっかけ

  • SQLアンチパターンを読んでから、「適切なテーブル設計」って何?と思っていたので
  • 会社の課題図書になりました

読んでみて

正規化

「正規化」という言葉をテーブル設計では聞くけれど、「正規化をあえてしない場面がある」という言葉も聞いていたので、「どいうことなんだろう?」と思っていました。その理由も書いてあるんですが、それよりも「ビジネス要件での正規化」について考えることが実務では大切そう。
でも、「正規化」について知る必要性も感じます。「正規化」についてしったうえで、「ビジネス要件での正規化」をする方が自分の設計について賢者から学ぶことができるように感じます。

ヒアリングの大切さ

テーブル設計をするときに、業務についてのことをヒアリングすることの大切さについて書かれています。
ビジネス要件をヒアリングしないと、運用に入っていくと使えない、というのは納得。ヒアリングをして、テーブル設計をしていくことが何回か出てきます。見えるところだけではなく、ビジネス要件を聞くことが、テーブル設計の前提にあるのを忘れないようにします。

データーベース設計で手を抜くと、プログラムに負担をかける

実感中...

設計の手順

  • 大まかにブロック分けする
  • ブロック毎にイベント系を洗い出す
  • イベント系に対する正規化をして、リソース系を洗い出す
  • リソース系に対する分類の洗い出しを行なって、リソース系の正規化を行う
  • ブロック間でリソース系の統合を行い、さらに正規化を、行う
  • 導出系の整理をして、最終的な正規化を行う

Amazon

📅 月別アーカイブ