マイナンバー話で、思い出した！
昔の日曜討論で、なんかコンピューター知ってますよ！の意識高い系の人が
「マイナンバーは主キーになる」って、意味不明なこと言ってた。
・・・皆さんこんな認識？だとすると、
マイナンバーは原則別テーブル、他テーブルでは主キーにできず、JOIN注意 - ウィリアムのいたずらの、まちあるき、たべあるき
「マイナンバーのテーブルでの持ち方がわからない。合法的にはどう持てば、削除しても大丈夫なのか？」と聞かれたので、こんな風に答えました。■マイナンバーは原則別テーブ...
goo blog
の意味通じないし、先の話も通じないので、ここで整理しておく
■その前に、キー、テーブル、レコードとは
（キーの違いが知りたい人は、次の段落に飛んでね！）
キーの違いを話す前に、そもそも、キーって何？ってところから。
ある値を入れると、それに関連する１つ以上の値が返ってくるとき（場合によっては１個も返ってこないってのは可。常に返ってこないのは、意味がないね ＾＾；）
キー：入れた値
バリュー（値）：返ってきた値たち
という。このキー・バリューの組を保存しているものを、キーバリューストアといい、実現方法としては、データベースを使ってもいいし、連想配列（ハッシュマップ）を使ってもいい（他の方法もある）。ここでは、データベースの場合を考える。
キーを入れれば、世界のあらゆるバリューが返ってくる・・・っていうことは不可能だし、意味もない。現実的には、あるキーを入れると、ある事項に関連した値が返ってくるようにしていて、複数事項について、データベースが入っていることになる。
具体的に言うと、事項としては、従業員、患者、売買取引、病院・・・など
それぞれに、キーとなる項目があり、キーの値を指定すると、関連する値が返ってくる。
従業員の場合、普通の企業だと、従業員番号という項目があり、
従業員番号（例えば３２５とか）入れると
鈴木一郎、男、３６歳、総務課・・・
などと値（バリュー）が返ってくる。
このとき、
テーブル：上記で「ある事項」と書いたもの
タプル：DBの用語で、キー＆バリューの値をまとめたもの、日本語だと「組」
レコード：DBの用語でいうタプルのこと
（キー＆バリューの値をまとめたもの）
もともと、DBでなくファイルを使っていたんだけど、
そのときに「レコード」という概念が既にあり、
DBが出てきても、タプルという用語を使わず、
レコードという言葉を使う人が多いと思う。
ここでは、以下の説明で、
テーブル、レコード、キー、値（＝バリューの意味で）
という用語を使って説明していきます
■候補キー、主キー、代理キー
※候補キー：あるテーブルにおいて、ある項目の値をキーとして決めると、
レコードが１つに決まる場合
（＝このことを一意（いちい）という）、
この項目の値のことを、候補キーという
例えば、従業員テーブルだと、
従業員番号、マイナンバー、（保険証の）被保険者番号等が、候補キー
（マイナンバーが決まれば、従業員は一人に決まる。
ほかの候補キーも同じ）
患者テーブルだと
患者番号、マイナンバー、（今月提示された保険証の）被保険者番号等が、候補キー
※主キー：候補キーのうち、テーブルを代表する項目として決めた、
その値を指定すると、レコードが一意に決まる項目のこと。
主キーはレコードが発生するときに、決まっていなければならない。
例えば、患者テーブルにおいて、日曜討論のように、マイナンバーを主キーにしてしまうと
（患者テーブルのキーに紐づいて（紐づくはあとで説明する）
電子カルテ、心電図などの検査結果が連結するため、
心電図など検査を始める前には、患者テーブルにレコード
が登録され、主キーが決まっている必要があるので）
ぴーぽーぴーぽー
って救急車がくると、
バイタルは？出血しているから輸血必要、血液型は・・・
・・・ちょっとまって！
その検査するのに、患者テーブルに登録する必要があるから、
マイナンバー教えてもらって！
（意識のない患者さんに）「マイナンバー教えてください、
マイナンバーわかんないと、検査も治療もできないんですよ・・・！！」
ってことになってしまう。
これは許されないので
（・・・って思っているけど、日曜討論の人は、このつもりで
言ってるのかな？？この点は気が向いたら、このブログの後で議論する）
実際には、患者テーブルはたいてい、患者キーという主キーを用意して、
病院が独自に（人工的に）割り当てる。上記の場合だったら、
ぴーぽーぴーぽー
患者来るな・・病院スタッフは
患者テーブルに１人追加患者番号を用意して
（その時点では名前も被保険者番号もマイナンバーも不明）
それに、検査データを結びつけていく、っていう形になる
※代理キー（オルタネートキー）：あるテーブルにおいて、
主キー以外の候補キーのこと
つまり、そのキーによって、一意にレコードは決まるが、
主キーではないもの
上記の例で分かるように、患者テーブルにおいて、
主キーの患者番号は、
未入力（データベースの値だとNULL)ということはありえない
→一般に、主キーがNULLはありえない
しかし、オルタネートキーは、NULLがあり得るというか、
上記例では、検査中、治療中は常識的に考えれば、マイナンバーはNULLだ
（って思ってるけど、日曜討論の人は ちがうのかなあ・・・）、
「現行制度では」被保険者番号もNULLで問題なく、
これは、月末ないしは退院時に医療費請求する際までに
埋まっていれば問題ない。
■外部キーとは、「紐づける」とは
※紐づける：
システムの中にテーブルが複数ある場合（普通、複数ある）
あるテーブルの主キーの値に対応する、
他のテーブルの値を参照したいということがある。
例えば、病院は、治療すると、お金を請求するんだけど
（診療報酬といいます）
診療報酬のテーブルから、
患者テーブルを参照して、患者の名前とか請求すべき保険者
（患者からは３割、保険者からは７割お金もらう、
みたいな形になっているので、保険者の情報がいる。
国保の人は地方自治体、会社員の人は、健保組合または
協会けんぽが、それ）
とかが参照したい。
この場合、Ａのテーブルの項目の一つとして、
Ｂのテーブルの主キーを入れておくと、
Ａのテーブルの主キーが決まれば、
＝Ａのテーブルの値を持ってこれる
＝Ａのテーブルに入っているＢのテーブルの主キーも取得でき
＝Ｂのテーブルの主キーからＢの値も取ってこれる
という形で、Ｂの項目の値が取得できる
このように、あるテーブル（ここではＡテーブルとする）から、
他のテーブル（ここではＢテーブルとする）の値を参照したいため、
Ａテーブルの項目の１つとして、Ｂテーブルの主キーの項目を含めて、
実際にＡテーブルからＢテーブルに検索できるように、Ａテーブルの
その項目に、「Ｂテーブルの値を設定すること」を、
紐づけるといいます。
※外部キー：
上記の「紐づける」行為をした際に、他のテーブルの主キーのことを
外部キーといいます。
上記の例だと、Ａのテーブルに入った、Ｂのテーブルの主キーのことを
（Ａのテーブルの視点で見た時）外部キーということになります。
患者テーブルから見た時、マイナンバーは、
（マイナンバーテーブルというのがもしあれば、
その主キーはマイナンバーなので）
外部キーということになります。
マイナンバーは主キーというのは、
マイナンバーテーブルから見ればその通りですが、それは当たり前です。
それ以外のテーブルでは、マイナンバーは候補キーです。
患者キーとマイナンバーを紐づける場合、
患者テーブルの中に「マイナンバー」という項目を含めて、
その項目に、該当患者のマイナンバーの値を入れた時に、
紐づいたことになります。
（上記例だと、患者テーブルの主キーは設定したが、マイナンバーは
入っていないので紐づいていない。
患者が紐づけることを認め、マイナンバーを教えてもらい、
その値をテーブルに設定した時、「紐づく」
（本編はここまでで終わり）
■後で議論するといった
「マイナンバーがわからないと治療が受けられない？」話
上記では、ブラックジョークとして、これはないとしたが、
これを政府は本気で考えている、
つまり、マイナンバーがないと医療が受けられないという
状態を考えている可能性があるのだ！
以前のブログで（他の日の）日曜討論で
「マイナンバーカードによりリアルタイムで
医療情報を集計し・・・」と言っていましたが、
リアルタイムで集めるということは、
患者の診察、治療（手術）が終わったらすぐに・・・
ということになってしまいます。
つまり、意識のない救急患者の場合、手術が終わっても意識ない
（もし、意識あって手術中に目覚めたとしたら、麻酔科のミス）
ので、マイナンバーを聞く機会がないのに
マイナンバーがわかんないといけない、
そうしないとリアルタイムに集計できない・・・
・・・これを実現するには、マイナンバーカードをマイクロチップにして埋め込むと、（その人は意識なくても、埋め込まれたチップをスキャンすればわかるので）できるのですが、政府は「チップ埋め込み」を狙っているんですかね？？
アクセス
トータル
ランキング
