「マイナンバーのテーブルでの持ち方がわからない。
合法的にはどう持てば、削除しても大丈夫なのか?」
と聞かれたので、こんな風に答えました。
■マイナンバーは原則別テーブル、他テーブルでは主キーにできない
マイナンバーは、目的外には使えません。
ということは、従業員マスターの主キーなどにしてしまうと(一意で便利なんだけど・・・)
従業員マスターを税務・年金以外の他の目的(人事評価や飲み会の参加者名簿など)に使うことが出来ません。
ということは、マイナンバーは原則別テーブルで持ち、必要時にJOINすることになります。
■外部キーにする場合JOIN注意
ということは、実際にJOINする場合
従業員マスタ 従業員ID、従業員氏名・・・
マイナンバーマスター マイナンバー、従業員IDとなり、
SELECT 従業員マスタ.*,マイナンバーマスター.マイナンバー
FROM 従業員マスタ
LEFT JOIN マイナンバーマスター
ON 従業員マスタ.従業員ID=マイナンバーマスター.マイナンバー
と(この場合)LEFT JOINにすることが基本だと思います。
というのも、マイナンバーは、退職した場合、削除しなければなりません。
従業員マスターは、過去データを扱う
(例えば、2010年度~2014年度の新入社員一覧を出すなどという場合)
こともあるので、データは削除していないかもしれません。
ここで、INNER JOINをしてしまうと、マイナンバーマスタに無い人が消えて
しまいます(例えば、2011年度入社、2013年退社の人は、そもそも
マイナンバーテーブルに登録されていないので、INNER JOINしてしまうと、
2011年度の新入社員から、この人は抜けてしまう)。
その場合、NULL値はどうするかは・・・時々で考えるということですね
(ケースバイケース)
・・・ということは、マイナンバーが必要な場合は、そのSQLは、一応考えないと
いけないということですね(というか、SQLを作成するときは、本やWebから
切り貼りするのではなく、一応、考えてくださいね。マイナンバーの場合に限らず!)
■扶養家族まで考えると・・・NoSQL?正規化くずし?別テーブル?
マイナンバーは、扶養家族まで必要になります。
![](https://blogimg.goo.ne.jp/user_image/37/34/875ed615ccfbfd05622ad098a9ec5352.png)
http://www.nta.go.jp/mynumberinfo/pdf/gaiyo.pdfより引用
ということは、扶養家族のデータをもたないといけない・・・のですが、
扶養家族は何人いるかわかりません。
正規化する場合、マイナンバーテーブルとは別テーブルになります。
それがめんどくさければ、マイナンバーテーブルに、扶養家族リストというのをもって、
(扶養家族マイナンバー,扶養家族名)・・・繰り返し・・・
というデータ項目を持つか、いっそのこと、KVSなどのNoSQLにするか・・
(これらのばあい、途中の扶養家族を削除、修正する場合大変かも?)
ということになります。
じつは、このあと、「複数の顧客がクラウド(Amazon VPC)にマイナンバーテーブルを持った場合、税理士さんは・・・」ということで、とんでもない!話になったんだけど、その話は長くなるので、ここできる。
P.S
【参考】
マイナンバーにおける帳票変更のための参考サイト
●国税庁関係
社会保障・税番号制度<マイナンバー>
http://www.nta.go.jp/mynumberinfo/index.htm
●厚生労働省関係
事業主の皆さまへ
http://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000063273.html
合法的にはどう持てば、削除しても大丈夫なのか?」
と聞かれたので、こんな風に答えました。
■マイナンバーは原則別テーブル、他テーブルでは主キーにできない
マイナンバーは、目的外には使えません。
ということは、従業員マスターの主キーなどにしてしまうと(一意で便利なんだけど・・・)
従業員マスターを税務・年金以外の他の目的(人事評価や飲み会の参加者名簿など)に使うことが出来ません。
ということは、マイナンバーは原則別テーブルで持ち、必要時にJOINすることになります。
■外部キーにする場合JOIN注意
ということは、実際にJOINする場合
従業員マスタ 従業員ID、従業員氏名・・・
マイナンバーマスター マイナンバー、従業員IDとなり、
SELECT 従業員マスタ.*,マイナンバーマスター.マイナンバー
FROM 従業員マスタ
LEFT JOIN マイナンバーマスター
ON 従業員マスタ.従業員ID=マイナンバーマスター.マイナンバー
と(この場合)LEFT JOINにすることが基本だと思います。
というのも、マイナンバーは、退職した場合、削除しなければなりません。
従業員マスターは、過去データを扱う
(例えば、2010年度~2014年度の新入社員一覧を出すなどという場合)
こともあるので、データは削除していないかもしれません。
ここで、INNER JOINをしてしまうと、マイナンバーマスタに無い人が消えて
しまいます(例えば、2011年度入社、2013年退社の人は、そもそも
マイナンバーテーブルに登録されていないので、INNER JOINしてしまうと、
2011年度の新入社員から、この人は抜けてしまう)。
その場合、NULL値はどうするかは・・・時々で考えるということですね
(ケースバイケース)
・・・ということは、マイナンバーが必要な場合は、そのSQLは、一応考えないと
いけないということですね(というか、SQLを作成するときは、本やWebから
切り貼りするのではなく、一応、考えてくださいね。マイナンバーの場合に限らず!)
■扶養家族まで考えると・・・NoSQL?正規化くずし?別テーブル?
マイナンバーは、扶養家族まで必要になります。
![](https://blogimg.goo.ne.jp/user_image/37/34/875ed615ccfbfd05622ad098a9ec5352.png)
http://www.nta.go.jp/mynumberinfo/pdf/gaiyo.pdfより引用
ということは、扶養家族のデータをもたないといけない・・・のですが、
扶養家族は何人いるかわかりません。
正規化する場合、マイナンバーテーブルとは別テーブルになります。
それがめんどくさければ、マイナンバーテーブルに、扶養家族リストというのをもって、
(扶養家族マイナンバー,扶養家族名)・・・繰り返し・・・
というデータ項目を持つか、いっそのこと、KVSなどのNoSQLにするか・・
(これらのばあい、途中の扶養家族を削除、修正する場合大変かも?)
ということになります。
じつは、このあと、「複数の顧客がクラウド(Amazon VPC)にマイナンバーテーブルを持った場合、税理士さんは・・・」ということで、とんでもない!話になったんだけど、その話は長くなるので、ここできる。
P.S
【参考】
マイナンバーにおける帳票変更のための参考サイト
●国税庁関係
社会保障・税番号制度<マイナンバー>
http://www.nta.go.jp/mynumberinfo/index.htm
●厚生労働省関係
事業主の皆さまへ
http://www.mhlw.go.jp/stf/seisakunitsuite/bunya/0000063273.html