⇧ AIとかでソースコードが妥当かどうかをチェックできれば良いんですけどね。
結合テストで拾えない可能性もありますし...
コストはかかりますが、
スイスチーズモデル（英: Swiss cheese model）は、マンチェスター大学のジェームズ・リーズンが提唱したリスクマネジメントおよびリスク分析のモデル。航空や船舶といった交通の安全、エンジニアリングや医療現場の安全に加え、ITセキュリティにおける多層防御に応用されている
⇧「スイスチーズモデル」のように、複数の対策で検知する仕組みを導入するなどのリスクヘッジが必要ということですかね。
ソースコードの実装者だけに負担させるのは酷ですからな...
複合主キーを構成する属性（カラム）数は減らせないものなのか...
データベーススペシャリストの過去問の午後Ⅱの問題を見ていて思ったのが、「複合主キー」を構成する属性（カラム）数が多いなと。
データベーススペシャリストって言うぐらいだから、データベースにおけるテーブル設計のお手本となるものと思われるからして、模範となるテーブル設計なんだとは思うのだけど、「複合主キー」を構成する属性（カラム）数が4つ以上になることが多く、5つになるケースも拝見されたことから、実際の現場におけるテーブル設計も同様なのかが分からず...
ちなみに、
tanakakoichi9230.hatenablog.com
tanakakoichi9230.hatenablog.com
⇧ 上記サイト様によりますと、「複合主キー」自体を無くすことは難しいと。
それは、分かったのだけど、「複合主キー」を構成する属性（カラム）数を減らすことはできないのか？
このあたり、議論している情報が見当たらず、際限なく「複合主キー」を構成する属性（カラム）数を増やしても問題ないのかがサッパリ分からない...
まぁ、データベーススペシャリストでは、5つの属性（カラム）で構成した「複合主キー」を扱っているので、少なくとも5つの属性（カラム）で構成した「複合主キー」については、推奨されるということなんですかね？
「複合主キー」でしか実現できないテーブル構成があることは分かったのだけど、「複合主キー」を構成する属性（カラム）数が妥当かどうかの判断が難しいんよね...
そもそも、データベーススペシャリストの過去問で令和2年の午後Ⅱの問題文で、
⇧ 上記のようなテーブル構造が説明されてるのだけど、
「使用電力」に登録するテーブルってアプリケーション側で制御するってことなんかね？
「複合主キー」の構成的に、1分以内に、2回登録処理が走ったら、エラーになることになるっぽいので。
そうなった場合に、「秒」も「複合主キー」の構成に含むのは駄目なのか？とか疑問が起こるからして、「複合主キー」を構成する属性（カラム）数の妥当性が皆目見当が付かないと...
「秒」を追加したら、「複合主キー」を構成する属性（カラム）数が6つになってしまうことになり、「複合主キー」を構成する属性（カラム）数が増えてしまうのだけどね...
何と言うか、「RDBMS（Relational DataBase Management System）」におけるテーブル設計のお手本が無いのが辛いですな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
