さ ～ そ
識別子
”処理系”の中で一意に識別できる名前(文字列)の事です。データを識別するための識別子は主キーと呼びます。処理系の中で一意と書きましたが、この処理系が曲者で、例えば学校のクラス内の処理であれば出席番号は識別子の様ですが、学年で処理しようとすると識別子としては使えなくなります。インターネットの発展に従いこの”処理系”は世界全体でなくてはならないという考え方が浸透してきました。例えばインターネットでよく使うURLは世界で同じものはありませんので識別子です。識別子は一つの文字列である事が必要ですが、運用上は複数の項目をあわせて識別する事も多用されています。例えば、先の出席番号もクラス名と組み合わせると一意に識別可能となります。
識別子には一意である事の他に大事な特徴があります。それは、不変という事です。途中で変わったのでは意味がありません。その観点では前出の出席番号は識別子ではありません。進級や進学すると別の出席番号になり、以前の出席番号は他の人に割り当てられてしまいます。そうすると、一意に識別できるという特性も失われてしまいます。
識別子は、一度使った文字列は二度と使わない事を前提に、値が変化たり増えたりする運用もあり得ます。例えばクレジットカードが誰かに悪用された場合や紛失した場合には番号が変わり以前の番号は失効します。これは、クレジットカード会社が名寄せという処理をして番号が変わってもどの人のカードであるのかを判別できる様にしているためです。この名寄せという機能を使うと、色々なことが出来ます。例えば、健康保険の番号と免許証番号とマイナンバーをそれぞれ付与しておいて、名寄せシステムで同じ人だと認識するシステムを作る事が可能です(実際にはそうはなっていませんが)。また、災害に識別子を付けたいというときに、各自治体が例えば”A市-地震-002″、”B町-火災-101″、”C村-渋滞-200″と言う様にバラバラに識別子を付与しておいて、後でそれらをまとめて”2025〇〇地方震災”という識別子を付与する様な運用も可能となります。
識別子の応用としては外部参照があります。例えば自治体や国が公開しているオープンデータに識別子を与えると、色々な業務で使う個々のデータには細かな情報を盛り込む必要がなくなる可能性があります。例えば、公共施設に識別子を付与して施設のオープンデータを公開すると、民間のそれぞれのデータにはその識別子を記載しておくだけで、施設の住所や開館時間帯などの情報をいつでも確認できる様になります。
施設
辞書などによると一般的に「施設」という言葉は何らかの目的のために設置した建築物および設備を指します。従って、「大型商業施設」が施設である事は勿論、その中の一部にある「医療モール」も施設ですし、医療モールの中にある個々の「医療施設」もまた施設です。この様に施設は入れ子の構造になっている場合があります。公共施設の場合も「複合施設」や「合同庁舎」があり、その中に個々の公共施設があります。公共施設の施設管理観点では一番外側の施設、つまり複合施設や合同庁舎が施設管理の単位になります。従って、単に「施設」と記述した場合は一番外側の施設を意味します。一番外側の施設である事を強調したい場合は全体の施設などと記述する場合もあります。また、中に入っている施設はテナント施設などと呼ぶ場合もあります。尚、辞書などでは建築物と設備となっていますが、公共施設ではその敷地も含めるのが妥当です。植栽の手入れや駐車場やグランドの管理も必要だからです。従って、共通データ用では施設には敷地も含まれると考えます。
主キー
データ一つひとつに割り当てられた識別子です。プライマリーキー、idなどとも呼びます。主キーがある事で、データは一意に識別できます。例えば、日本国内に住民登録をしている人だけを対象としたデータであれは、マイナンバーは主キーとして使えます。但し、このテータは災害時のの被災者データには使えません。マイナンバーは海外からの来街者には付与されていないので、主キーとしては余りいい項目ではありません。この様に主キーとする項目には幾つかの条件があります。以下、列挙します。
- データの母集団の中で、全てのデータに付与できること
この観点で、マイナンバーは日本に居る人間の主キーとしては注意が必要です。 - データの母集団の中で、個々のデータを一意に識別できること
- データのライフサイクルの中で値が変化しないこと
クレジットカードの番号の様に不正利用されると変わってしまうものを主キーとする時には「名寄せ」という運用を考える必要があります。名寄せとは、アレとコレは実際には同じとか、どちらかに含まれるなどの関係を管理する処理です。 - データが消失しても、焼失したデータの主キーは他のデータに使いまわされないこと
これは運用に対する要件です。例えば「部門番号」などはひょっとしたら部門が無くなると他の部門にその番号が割り振られる運用になっているかもしれません。その様な場合は部門番号は主キーには相応しくありません。 - 使える文字はURIの規定に従っていること
これは実装上の都合です。主キーはAPIに記述される事が多いため、URIの規定に従っていないと、インターネット上で不具合を起こす可能性があります。
但し、この様な条件を満たす「主キー」は簡単には見つかりません。例えば前記のマイナンバーは日本に居る全ての人に付与されている訳ではありません。だからと言って他に適切なキーがある訳ではありません。その様な場合、一般的にはUUIDなどの文字列を主キーとしておいて、マイナンバー、パスポートナンバー、ICカードの番号、クレジットカードなど、重複が無い複数の番号を組み合わせて使います。この複数の情報をひとつの情報に集める処理を「名寄せ」と言います。従って、電子データの作成者はこの名寄せをやりやすい様に配慮しておくことが望ましいです。
処理用電子データ
本協議会の造語です。電子データの内、CSVやJSONファイルの様に集計などの二次利用が可能なものを指します。処理用電子データは更に、CSVの様にシンプルな表形式でインタフェースに適したものと、JSONやXMLの様に複雑な構造を表現できるものに分類されます。区別する必要があ時には、前者を「表形式の処理用電子データ」や「表形式の電子データ」などと呼び、後者を「構造を表現可能な・・・」と呼びます。標準データ仕様のデータの形式(データモデル)は後者を意図して策定されています。前者は表形式なので、電子デーの仕様目的に合わせて個別にデータの形式を策定する必要がありますが、その際には個々の項目の定義や名称を参考にすることで、機械的な変換により構造を表現可能な電子データにすることが可能となります。
