＜chatでの質問を転記＞
かなり肉厚になっていて凄い本気のモデルになっていますね。渡辺さんの意図を読み取るのに結構時間が掛かりました（笑）
疾病区分や条件行番の扱いが面白いですね。以下何点か質問です。
１）接種日程テーブルの条件行番がカッコ付き項目なので導出項目になっていますが、これは別データから導出出来ない気がします。恐らく同一の予防接種NO＋拠点番号＋接種日に対して、条件行番は１種類のみとなる仕様で考えているのではと予想しているのですが、このキー情報から条件行番を辿る事は出来ないと思います。
条件行番が、一度抽出に使った後はあまり気にしない存在になる部分は面白いですね。
２）接種日程テーブルにワクチンCがありますが、同一の予防接種NO＋拠点番号＋接種日に対して、ワクチンは1種類という制約にしているのでしょうか？予防接種NOに対しては複数の種類のワクチンを定義可能（疾病区分が同一ならば）ですが、拠点、日に対しては１種類で運用するという制約で認識はあっていますか？
３）在庫推移を作る際に、出庫予定の容量が計算できない気がします。解説ページに「接種時程」を使って計算を行うとありますが、接種時程テーブルは最大接種人数しか持っていないので、どの位の容量が必要なのかが分からないのではないでしょうか？出庫容量を算出するには各人の月齢に対する接種容量を積み上げる必要がある気がします。もしくは接種時程テーブルに割り当て容量を持たせる方法もあるかと思います。
４）現在庫数の単位は容量で良いでしょうか？１つの瓶から複数回の接種が出来るという話を聞いたのでビン数などではなく容量で管理すべきかなと思っています。
５）条件行番を判断するのに、６５歳以上という条件は住民テーブルの生年月日から導出できますが医療従事者や既往症ありといった情報は得られません。どこか住民テーブルなどに追加が必要でしょうか？
ーーー
あ、４）の質問ですが管理という観点からするとビン（個数）で管理すべきですね。中途半端な容量で管理するってあり得ないですね。
＜渡辺さん回答＞
> １）接種日程テーブルの条件行番がカッコ付き項目なので導出項目になっていますが、これは別データから導出出来ない気がします。恐らく同一の予防接種NO＋拠点番号＋接種日に対して、条件行番は１種類のみとなる仕様で考えているのではと予想しているのですが、このキー情報から条件行番を辿る事は出来ないと思います。条件行番が、一度抽出に使った後はあまり気にしない存在になる部分は面白いですね。
確かにキーの関係からは理解できない項目なんですが、拠点をはずして考えると、その接種日においてどの条件が適用されるかは導出可能です。たとえば医療関係者が「一般（その他）」の条件で接種することは許容されますが（逆は許されない）、その日付はあくまでも「一般（その他）」なんですよね。予防接種プログラムにおいて、条件は重複しながらも固有値は決まる。なんだか説明しにくいんですが。
> ２）接種日程テーブルにワクチンCがありますが、同一の予防接種NO＋拠点番号＋接種日に対して、ワクチンは1種類という制約にしているのでしょうか？予防接種NOに対しては複数の種類のワクチンを定義可能（疾病区分が同一ならば）ですが、拠点、日に対しては１種類で運用するという制約で認識はあっていますか？
鋭い。そこが私の工夫です。それによって現場の混乱を減らすという意図もありますが、接種者が接種予約する際にワクチンCを選ぶ必要がなくなるという効果があります。１回目については制約なしですが、２回目は１回目と同じでないといけない。それをシステムが監視するために効果的な制約だと考えて組み込みました。
> ３）在庫推移を作る際に、出庫予定の容量が計算できない気がします。解説ページに「接種時程」を使って計算を行うとありますが、接種時程テーブルは最大接種人数しか持っていないので、どの位の容量が必要なのかが分からないのではないでしょうか？出庫容量を算出するには各人の月齢に対する接種容量を積み上げる必要がある気がします。もしくは接種時程テーブルに割り当て容量を持たせる方法もあるかと思います。
上の回答にもあるように、「接種時程」のレベルで、関連する接種予約（接種申請明細）の用量の合計から、製品の容量にもとつくバイアル数が計算されることになります。
> ４）現在庫数の単位は容量で良いでしょうか？１つの瓶から複数回の接種が出来るという話を聞いたのでビン数などではなく容量で管理すべきかなと思っています。
上述のように、１回あたりの消費量は用量で計算され、それが「接種時程」のレベルでバイアル数に換算され、在庫推移に参与されます。ワクチン在庫取引はバイアル数基準です。なお、佐野さんは開発経験が長いので箱の「入り数」を気にしていますが、このシステムでは透過的に扱えると考えました。箱が１種類であれば入り数は問題にならないし、仮に箱が何種類もあっても、ワクチンという製品の特殊性を考えた場合、現場でよしなに対応できるような気がします。佐野さん、いかがでしょう。
> ５）条件行番を判断するのに、６５歳以上という条件は住民テーブルの生年月日から導出できますが医療従事者や既往症ありといった情報は得られません。どこか住民テーブルなどに追加が必要でしょうか？
いい質問ですねぇ。説明しすぎると誰も読んでくれないと思って書いていなかったのですが、重大な論点です。たしかに、統一自治体システムが存在したとしても、住民が優先接種されるべき「医療従事者」であることは判断できません。せいぜい自治体は、医師や看護師のライセンスは把握しているようです。
しかし、医師や看護師が働いている事業所が医療施設であるかどうかは厳密には定義できません。いっぽう医療ライセンスがなくても、医療施設で働いていれば優先接種対象者です。また、持病持ちかどうかも医師しか判断できません。ゆえに、穏当に言えば、システムが自動的に判定できるのは（ライセンス属性を除けば）年齢属性のみ、ということになります。
現実的には、まずは一律に「年齢に応じた接種条件」が与えられることになるでしょう。ただし、「接種者自身による予約申請」と「拠点管理者による接種認可」では、接種条件の扱いが変化します。前者ではシステムは年齢に応じた予約優先順位が強制されますが、後者では条件をオーバーライドすることが許されます。それはこのシステムの基本要件になるような気がしています。