RDBの体系的学習方法(モデリング)

Javaなどのオブジェクト指向を学習してる方々へ。

ソースコードだけをおっていろいろ実装したり、処理の流れをおっていませんか？

DBのテーブルを作るとき、意味も分からずCreateTableしていませんか？

結論から言うと、作図しましょう、分析や設計から学習しましょう。　　　　　　　　　　　　　　　　　　　　　　　　理由はたくさんあります。　　　　　　　　　

・自分自身が全体像を把握しやすい　　　　　　　　　　　　　　　　　　　　　　　　　

・だれかにレビューしてもらう時も説明がしやすい

などなどありますが、

１番の理由はDBの実装、つまり「SQLでの実装はDBの論理設計というものをしたのちにやるから、    設計を先に学ぶのが自然な流れ」だからです。　　　　　　　　　　　　　　　　　               

それにJavaなどでクラス設計とRDBの設計は非常に似通っています。　　　　　　　　　　　             なので１石２鳥です。

(注. 多重度に関してはUMLのクラス図、オブジェクト図で先に慣れておくのが望ましいです。)

それなのに、SQLから学習する意味、、、、、、全体像が分からない状態で正しく実装できるんでしょうか？　私には無理ですね。

RDBの論理設計のゴールはER図という、クラス図にものすごく近い考え方の図を作図し、テーブル間の多重度を定義してあげる事です。

そうすることでテーブル間の関係性を把握しやすくするのが目的です。

この時人によっては多重度を「０以上」か「１以上」なのか、そんなに意識しなくていいという人がいますが、絶対に明確にすべきです。

といいますのもER図には

・テーブル間の関係性を把握しやすくする　こと以外にも

・「その図を見た人が業務ロジックを正確に把握しやすくする」

て目的もあります。

同じ「多」の意味を持つ　「０以上」「１以上」でも業務ロジックがだいぶ異なります。

具体例として、以下のような２つのロジックで比較してみましょう。

①会員としてから初めて商品を購入できるロジック

②初めて商品を購入したら会員として登録されるロジック

ほら、全然違うものじゃないですか？

こういったほかの人が「これどういうロジックなん？」て思うのを防ぐためにも正確に多重度を設定して、システム要件をER図で表現してあげるのが大切なんです。

つづく