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