このページをご覧になっている皆さんは業務システムの開発者または設計者だと想定しています。今回のような「ワクチン接種管理システム」を作って欲しいと依頼されたとき、どうされるでしょうか？
「どういう画面が必要ですか？」
「どういう項目を入力しますか？」
「登録されたらどういう処理が必要ですか？」
というようにヒヤリングされますか？このように処理から設計する手法を我々は「POA(Process Oriented Apploaach）と呼んでいます。私が若い頃、COBOLの時代ではこれが普通でした。今でも使い捨てのシステムや過去に開発経験があるシステムの場合はこの手法でも大丈夫でしょう。現実の手順に基づいてシステムの動作を考えて設計しますのでわかりやすく低コストで出来ます。POAで設計すると、まず処理が中心となりますので「処理を行い易い様に」データ（ファイルやデータベース）を考えます。そのため今回のように多少複雑なシステムを設計する場合、データの重複や不整合が発生しやすくなります。
POAの反省から生まれた手法が「DOA（Data Oriented Apploach：データ指向アプローチ）です。この手法ではまず「扱われるデータはどういう構造をしているのか？」を考えます。
ワクチン接種管理システムではどういう「データ」を扱うのでしょうか？必要な機能は次の2つでしょう。
ワクチンの在庫を管理する（出来ればロット管理と賞味期限管理をしたい）
接種する人の申し込みを行いたい（出来れば場所と日付と時間は管理したい）
こういう種類の「業務」を我々は帳簿組織と呼んでいます。帳簿組織とはもともとは簿記の用語です。いくつかの帳簿（会社の取引を記録する帳面）から仕訳帳に転記し、総勘定元帳として勘定科目で集計するといった組織（体系）のことです。我々ははもう少し広い意味で使います。簿記だけでなく会計全般の業務ごとに必要な「帳簿類の構造」を帳簿組織と呼んでいます。
では業務システムを設計するとき、何から手を付ければ良いでしょうか？
これについては設計者それぞれです。IT勉強宴会の（宴会の）中で何度も朝まで議論しましたが、「これが正解」というものはありません。ただオブジェクト指向設計が広がった時によく言われていた次の手順が間違っていることだけは確かです。
ユースケースとしてビジネスルールを文章で記述する
その中の名詞をみつけてクラス候補とする
クラスをエンティティとみなす
これがなぜ間違っているのでしょう。まずひとつは「ビジネスルール」が処理であれば上記に書いたPOAと同じだからです。もう一つはクラスをそのままエンティティ（テーブル）と強引にみなしているところです。この手順はエンティティを切り出す方法ではなくオブジェクト指向でクラスを切り出す方法として広がりました。
また、一部のデータモデリングの本に書いてある次の手順も間違いです。
データモデルを作成する
正規化する
正しい手順でデータモデルを作れば第３正規系にはなりますから正規化する必要がないはずです。もしこう書いてある本を読まれたなら時間の無駄ですのでもっと良い手順書を探しましょう。もしまったく正規化されていないデータモデルが作成されるならそれは処理に必要な項目を並べているだけなのでしょう。
それではモデルを作ってみましょう。XTEA Modelerを使って作りますのでまだ使ってことがない方は最初にインストール（無料）しましょう。
それではモデルを作ってみましょう。まずはどんな要件かを確認しましょう。