データベーススペシャリスト　エンティティライフサイクル分析のやり方

開発アプローチとエンティティライフサイクル分析のお話。

意外と最近エンティティライフサイクル分析は試験に出ているので

押さえておく必要あり。

開発アプローチ

プロセス中心設計

 

開発アプローチには大きく分けて2つある。

一つはプロセス中心設計で，

どのような機能が必要かという観点から

設計を始める。

しかしこのやり方では

データの管理がうまくできず

昔のやり方というイメージ。

 

現在のDB設計はデータ中心設計で行う。

データ中心設計

どのようなデータが必要かという観点
から設計を始める

業務を分析して必要なデータ項目を洗い出す

 

エンティティライフサイクル分析

すべてのデータにはライフサイクルがあり

生まれて使われて死んでいくまでを分析する方法。

生成　C

参照　R

更新　U

削除　D

の頭文字をとってCRUD図と呼ぶ。

 

基本的にこの４つのプロセスが

各エンティティに存在するはずという観点で

分析する。

 

次のような感じで縦軸に処理，横軸にエンティティを書いて分析する

	顧客	商品
顧客登録	C
顧客更新	U

 

分析のポイント

原則的にCRUDの4つがそろっているかどうか
→業務の内容によっては４つそろっていなくてもよいこともある

ある箇所にCRUDが集中していないか
→集中している場合は処理を分ける必要があるかを検討する

あるプロセスと別のプロセスで同じパターンになってないか
→同じパターンがある場合はどちらか1つでよい場合がある

SQLやデータベースについてもっと学びたい方は次の記事でおすすめの書籍を紹介しています↓

SQLServerやデータベースに関する書籍のおすすめランキング！SQLをこれからはじめようと思っている人や，普段SQLを使った仕事をしているけどもっと詳しくなりたい！という方向けに，どんな本を読めばい...

<<   1   2   3   4   5   6   7   8   9    10   11   12   >>

トップページへ戻る

オブジェクト指向の原則 単一責務の原則

C#を正しい3層構造で造れてますか？

非売品コースを受け取る

#00_はじめに
#01_単一責務の原則とは
#02_原則違反の例
#03_変更理由単位でクラスを分ける
#04_3層構造の例
#05_修正箇所を最小にできる
#06_修正する場所が明確になる
#07_共通化しましょうという話ではない
#08_少々悪いコードでも問題視しない理由
#09_探しやすいコード
#10_クラスは機能ごとに小さく作る
#11_小さなクラスがそれぞれに協調して目的を達成させる
#12_多数の部品群のなかから摘まんで作る
#13_クラスはどこまで小さくすればいいのか
#14_アンダーソン式単一責務の原則
#15_最小カプセルの検証_監視タイマークラス
#16_最小カプセルの検証_受注画面クラス
#17_最小カプセルの検証_ユーザークラス
#18_最小カプセルの検証_商品マスターデータアクセス
#19_登場人物に合わせたモデリングの四角と線
#20_四角と線を最小カプセル化する
#21_アンダーソン式手順
#22_パターンを見つけ出す
#23_プログラミングの自問
#24_さいごに