[付録] 主キーらしきもの
コンピューターで現実のモノやコトの情報を処理する際には「主キー」というものが必要です。この主キーとは重複が無く変更されないという属性を持った項目の事です。主キーはモノやコトの一部を取り出しても変更したり削除したりする事はご法度です。この主キーというものが以外と難しく、色々な「デジタル化」に妨げています。本コラムではその辺りについて記載します。
例えば日本国内の住民に対してはマイナンバーが割り振られていますが、これは主キーとして使う事が可能な様に思いますが如何でしょうか。他えば不幸なことに大きな災害が発生したとして、自治体や政府がその被災者の情報を整理したいと考えたとします。そうすると、被災者にはマイナンバーを持たない人が居る事に気が付きます。そう、海外からの旅行者です。彼ら彼女らはマイナンバーを持っていません。従って、マイナンバーをそのまま主キーとして使う事が出来ません。そうは言ってもコンピューターの処理には主キーが必要なので、災害時には主キーらしきものをその場限りで作ります。例えば「被災者ID」と言う項目を作って、そこに番号を昇順に振っていくなどの方法です。そこでまた問題が発覚します。災害が発生した影響を受ける住民や来街者はどこまで被災者IDを発行すれば良いのでしょうか。罹災証明書が発行されるような甚大な影響を受けた人だけでなく、少しでも支援が必要な人、例えば断水で困っている人も何らかの支援が必要ですよね。そうすると元々「被災者の情報」を整理したいという要求自身がおかしかったことになります。
さて、ここで整理しましょう。マイナンバーも被災者IDも主キーとしては余りよくないものでした。それはどうしてかと言うと、マイナンバーの前提も被災者IDの前提もモノやコト全体を表していなかったからです。つまり、「住民票がある」とか「被災者である」というのはヒトの属性に過ぎないのです。この様に多くのデータはモノやコト全体を前提としておらず、その一部を前提としているため、その前提が崩れたりあやふやであったりすると、途端にどう運用すれば良いのか分からなくなります。
ではどうすれば良いのでしょうか。ひとつはちゃんと想定する母集団を「人」などの全体としておいて、住民票の有無などはその属性のひとつとすること。主キーは別に考えておくことです。例えば、マイナンバーを主キーとする代わりにマイナンバーを持たない人には12桁の数字の先頭一文字をアルファベットの”A”とし、残り11桁を独自に採番する運用を決めておくなどです。この様にする事により回避します。但し、外国からの旅行者に対し複数の番号が採番されるなどの問題は残りますので、属性に国籍やパスポート番号を追加しておいて、同じ人が複数登録されるリスクを軽減する必要はあります。この様に主キーは天与のものではなく、運用やリスク評価含めたものであるという事を意識しておくと良いでしょう。
余談ですが、主キーらしきものがあふれて業務が混乱する事を回避する方法のひとつに「データベース化」があります。データベースとはその名の通りデータ基地ですから、データが一か所に集められているシステムです。データベースの作り方にも幾つかありますが、企業などで用いられている方法は、多目的データ仕様の考え方に従い、モノやコト単位にデータベースを作る方法です。例えば企業内のシステムであれば、個々の社員の情報は人事部の「人事データベース」にのみ存在させて、他にコピーは作らせないという考え方です。人事データベースに無い項目が出てきたら、新たにデータベースを作るのではなく、人事データベースを拡張します。そうする事で、主キーらしきものアチコチに出現する事が回避できます。人事データベースの主キーが会社内全ての主キーという事になります。このデータベースの考え方は半世紀以上前から提唱されていて、データベースが出来た時にそれ以前のシステムの仕組みを「ファイルシステム」と名付けました。皆さんの職場で、どこからかデータを貰ってきてそれを加工して保存して、要求ががあればその加工したデータを渡す様な業務の進め方を指定方はいらっしゃらないでしょうか。その寄り方は半世紀以上前のファイルシステムのやり方です。是非ともデータベース的なやり方に変えていってもらえると業務の効率や柔軟性が改善されると思います。そうは言ってもいきなりデータベースシステムを導入する事は無理だと仰り方も多いと思います。その場合ではも主キーを何にすべきかを検討し、データを受け取って加工する時には主キーは変更しないし削除しないというルールだけでも守っておけば随分と改善されます。是非ともご検討下さい。
