データモデルとは (4/4)

主キー

　主キーとは個々のデータを一意に識別するための名前の事で、通常、主キーの項目をデータモデルで指定します。主キーはプライマリーキー、ID、idなどと呼ぶこともあります。識別子と呼ぶこともありますが、識別子は主キーだけでなく項目名などの他と区別をつける名称一般を指す言葉なので。本説明では区別がつく様に主キーと呼ぶことにします。コンピューターの世界では「原則として」データの一つひとつに必ずデータの主キーを付与します。主キーはデータ間の関係を表現するため、或いは複数のデータがあった場合、同じモノやコトである事を認識するために使用します。前頁の図ではにidと記述しました。同じモノやコトを認識するという意味では、データに主キーが付与されると考えるよりも、それらのデータが表現するモノやコトに主キーが付いていると考える方が妥当かもしれません。

　共通データ仕様ではデータはモノやコト毎に作成されますから、共通データ仕様でもモノやコトに主キーが付与される事になります。この考え方は実生活でも広く採用されています。自治体であれば自治体コード、人間であればマイナンバー、法人であれば法人番号が付与されています。この主キーが無いと、同姓同名の人の区別が付けられないなどがあります。データの主キーは一つの項目で構成されるとは限りません。部門であれば法人番号と部門番号を組み合わせれば一意に識別可能です。主キーを項目として持つ事で、他のデータと突き合わせをして二次利用する事が可能となります。例えば、「AED設置施設一覧」と「WiFi設置施設一覧」が、同じ主キー(この場合は施設を一意に区別するする通番など)を採用していれば、AEDとWiFIの両方を設置している施設を洗い出すことは容易になねりますね。

　コンピューターの世界では「原則として」主キーをつけると書きましたが、主キーは同じモノやコトを認識するため、或いはデータ間の関係を表すために使用するのですから、その必要が無い場合には主キーを用意する必要はありません。下表に主キーが必要な場合、不要な場合を例示しました。

　主キーを決めるときには、その前に対象となるモノやコトの範囲を決める必要があります。この範囲の事をスコープと呼びますが、他にも名前空間(Namespace)、ドメイン(Domain)、識別子空間(Identifier Space)など多様な呼び方があります。例えば社員番号を主キーとするデータであれは、スコープは特定の会社ということになります。マイナンバーが主キーという事であれば、日本で住民と登録されている人という事になります。

　主キーが満たすべき条件は以下の通りです。あとで述べる様にこれらの条件をすべて満たすことは難しいのですが、まずは理想論として記載します。

• データ毎にスコープ内で異なる値(名前や番号など)が割り当てられる
• 対象のモノやコトが存在する間、主キーの値は変わらない
  主キーは「関係」を表すために他のデータに格納されますので、主キーが変わったしまうと関係が分からなくなってしまいます。
• 対象のモノやコトが消えた後も、その値は他のモノやコトの主キーとして再割り当てされない
  多くの場合、データは後で分析等に活用したり検証するために残します。対象となるモノやコトが消えた後でもこれらの作業を可能とするためには、データが残され主キーで関係が確認できる様になっている事が必要です。
• 一つのモノやコトに対して複数の値が割り当てられない
  主キーが複数あるという事は複数のデータが登録される可能性があるという事です。そうなると、登録したデータの整合性を保持する事がとても難しくなります。但し、この条件が実装的には一番難しく、後述する「名寄せ」が必要であるという事に繋がります。

これらの全ての条件を満たすことは実装的には困難なので、多くの場合は必ずそれを補う運用や処理を行う事を検討しておきます。具体的な状況や対応例は後述します。

主キーを実装する主な考え方を以下に示します。

	説明	注意点
集中型	主キーを作成するシステムや組織があり、前記の条件を満たす文字列を発行する方式です。この「集中型」は後述の分散型の対比で用いられる分類であり、特定の仕様を指している訳ではありません。 集中型の例としては、日本の法人をスコープとすると法務省が法人番号を付与しており、法人番号が主キーとなり得ます。同様に社内の正社員をスコープとすると社員番号が社員の主キーになり得ます。	集中型は中心となる組織やシステムが必須です。その点で、例えばグローバルな活動では集中型は実装できません。逆に中心となる組織を設定するとスコープを狭めてしまう可能性があります。
分散型	DID（Decentralized Identifier）と省略する場合もあります。 中心となる組織と主キーを付与する組織が別々にあり、中心となる組織が重複が発生しない様にそれぞれの主キーを付与する組織に対し、付与する採番ルールを定める方式です。 分散型の例としては、URLのドメイン名などがあります。中心となる組織が国や地域ごとのドメインとサブドメイン以下のルールを決める一方、サブドメイン以下の付与は各国や地域の組織がそれぞれ担います。	同じモノやコトに対して別の組織が別の主キーを付与する可能性があります。この場合、後述する「名寄せ」を実装する必要があります。
非組織化型 ランダム型	UUIDやGUIDなどの乱数を使っ重複のない文字列を発生させる方式です。	分散型同様に同じモノやコトに別の主キーを付与する可能性があります。

主キーの「スコープ」

　ここまでの説明でわかる様に、主キーはそのスコープが大きく影響します。スコープを狭く取りすぎてしまうと、そのデータは他の目的には活用しにくいものになってしまいます。例えば、自治体の普段の業務では住民を対象としているために、例えば人々に対する主キーは住民票コードで構いませんし、避難所の準備も事前に附番した避難所IDで構いません。法人も法人番号で済むかもしれません。しかし、能登半島の地震では多くの住民・一時居住者・旅行者がビニールハウスや自動車に寝泊まりしていました。住民票を移していない一時的な共重者や住民票がない海外からの来街者はこのスコープに収まりません。法人番号も多くの町内会やボランティアグループは付与されていません。このため、既存のデータがあっても、震災発生後の状況の把握や整理には大変な苦労を伴った事は記憶に新しいところです。

　この様に主キーのスコープはそのデータを活用する局面を考えて、一番広くとっておくことが望ましい訳です。

　そうは言っても、あらゆる活用局面を想定する事は難しいですし、主キーとして適切なものが見つからない場合も多々あります。例えば、災害時にそこに居るかもしれない人に重複なく附番されている既存の番号はありません。この様な時には前記の多様なタイプの主キーを活用する事が一般的です。例えば、データ上は非組織化型で主キーを設定しつつ、パスポート番号やマイナンバーなどの副次キー(副次的なキー)を複数登録しておく方法、交通系ICカードなど集中型の主キーをもつカードを配布する方法などです。

　以下、主キーを構築する方法例を示します。

	説明	注意点
複数項目の 組み合わせ	ひとつの項目では主キーが構成できない場合、複数の項目を合わせて主キーとします。 例えば、企業グループであれば、法人番号と社員番号を合わせるて主キーとする方法を採用可能です。人の主キーも国コード(日本は”JP”)とマイナンバーまたはパスポート番号を組み合わせると主キーとすることも可能です。 共通データ仕様の主キー(id)の多くはこの方法で主キーの文字列を生成しています。尚、共通データ仕様ではNGSI V2の仕様に合わせるために一つの項目に生成した文字列を格納する運用としていますが、一般的にはひとつの項目にまとめず、バラバラの項目のままて運用しても構いません。	スコープを母集団だけでなく、時間軸でも検討する必要があります。例えば左記のパスポート番号は期限がありますから、「今回の震災対応の期間」などとスコープを決め直す必要があります。
名寄せ	最初は主キーが主キーの条件を満たしていない事には目をつぶり、事後的に主キーの条件に合わせるべくデータを整理していく方式です。	詳しくは後述します。
外部の主キー導入	集中型の主キーを運用している組織と協力し、一時的に主キーとして導入する方式です。 例えば、交通事業者に支援を仰ぎ、被災者に交通系のカードを配布し、その番号を主キーとする方法です。日本の例ではありませんが、海外からの旅行者に入国時にクレジットカードの登録を義務付け、その番号で税金の払い戻しや売れ筋分析を行っている例もあります。	やはり、スコープの検討や名寄せの要否の検討は必要です。

　主キーのスコープでよく間違える失敗は、あるデータから一部を取り出してスコープを狭くしたときに、主キーを採番しなおしてしまう事です。例えば、自治体職員が住民の台帳からある特定の人々を取り出し処理する事はよくあると思います。例えば、予防接種を受けていない人、ある地区の人、支援が必要な人などを抽出する作業です。この際に新たな主キーを採番しなおして、元の主キーの項目を削除してしまうミスは良く行われます。新たな主キーを採番する事自体は業務に必要であれば構わないのですが、元の主キーを削除してしまうと、元の情報との突き合わせができなくなってしまいます。邪魔かもしれませんか、残しておきましょう。もしどうしても消す必要がある時には、別のファイルやデータベースに元の主キーと新たな主キーの対応表を保存しておきましょう。

名寄せ

　既に説明した様に理想的な主キーを定義し重複が無い様に運用する事は困難です。従って、同じモノやコトに複数の主キーが付与され、複数のデータが登録されてしまう可能性があります。例えば前出の震災の例では、広域災害が発生した時にある人が住んでいる自治体から他の自治体に出かけたタイミングで被災して、出かけた先の避難所に収容されたとします。そうすると、その人は両方の自治体で被災者としてデータ登録される事になります。具体的に言うと、避難者に付与する主キーをそれぞれの自治体で採番し、それぞれのシステムに被災者としてデータ登録されます。これは非常時には避けられない現象なので、事後的に運用しながら「名寄せ」していく事になります。名寄せとは、同じモノやコトの情報を統合したり紐づけたりすることで、コンピューターの世界では広く活用されている運用です。被災者支援が進むに従い自治体間や都道府県と被災者情報を共有し、同じ人のデータをまとめる必要が出てきますがこれが名寄せです。名寄せでは、データをひとつにまとめて片方を削除する場合もありますが、多くの場合は前ページに示したように「関係」を登録しデータは残します。尚、名寄せと言う言葉は、単に同じモノやコトを整理する作業だけでなく、家族、親戚、友人などの関係を整理する場合にも用いられる事があります。但し、ここの説明では同じモノやコトのデータを整理するという意味で使用します。

　この名寄せをするためには、事前に名寄せに寄与可能な項目をデータに登録しておくことが有効です。また、名寄せは100%正しく実施できるとは限りませんし、名寄せした前の各種手続きにも影響するかもしれませんから、名寄せ作業そのものに関する情報も残しておいた方が良いでしょう。

　以下、名寄せのために考慮しておいた方が良いことをまとめました。

	説明
副次キー	主キーではないものの、主キーに近い特性を持つ項目を設けておくと、名寄せが楽になります。例えば、以下の項目があります。 ・マイナンバー、パスポートナンバー、運転免許証ナンバー、法人番号の様に、スコープや期間が限られているもの、その範囲では主キーとしての特性を有すると共に、母集団の中でそれなりに大きい割合で付与されているもの ・住所+氏名+生年月日の様に、項目を幾つか並べる事で、重複がそれなりに低い確率になるもの ・或いは、それらの情報に機械的に変換可能な情報 よく、他の部署からもらったデータを流用して、新たな主キーを設定して、元の主キーを削除する運用が見られますが、これは避けるべきです。新たな主キーを採用する事は構いませんが、元の主キーも参考情報として残しておくと、後でそのデータを名寄せして二次活用しやすくなります。
名寄せの項目	名寄せでは「関係」を登録する、つまり同じモノやコトに関するデータの主キーを登録しておく項目と共に、その主キーがどのシステムや組織の主キーであるのかを示す項目が必要です。
名寄せ作業の情報	名寄せは人的作業を伴いますので、間違いもあり得ます。そこで、作業の履歴が分かる様な情報も残しておく方が良いです。例えば、作業者、日付、根拠となった情報などです。また、名寄せ作業は一瞬で終わるわけではなく、同じモノやコトのデータである可能性があるデータの抽出、確認、名寄せの確定などの一連の作業があります。そこで、関係を示す項目には同時に確認済みなのかどうかを示す項目が必要となる場合が多いです。