CSV等の表形式の電子データの設計方法
さて、ここまでは主に準備段階について記載してきました。ここからはオーナーからCSVなどの表形式のファイルで電子データの提出をも取れられた際の表形式のデータモデル(項目の定義)について記載します。CSV等の表形式のデータには、例えばグラフを描画するためのデータの様な一時的なデータと、誰かに渡したり保存したりするデータがあります。前者は目的に合わせて自由に作って構わないのですが、後者は後で困らない様にする必要があります。そこで本章では、この誰かに渡したり保存したりすることを前提に記載します。
表形式の電子データにおいてどの様な項目があると良いのかについては、ここまで記述してきた「FMシステムへの事前登録」に記載した内容と考え方は同じです。但し、幾つか追加して考えておくべき事項があります。以下、代表的なものについて列挙します。
| 説明 | |
|---|---|
| 主キーの保存 | 主キーは絶対に削除せず更新もせずにそのまま渡す必要があります。そうしないと、例えば今月のデータを先月のデータと比較するなどの際に困ります。また、主キーがあるという事は、表データの中の「何行目のデータ」という事を考える必要がなくなるので、複数のファイルを一つにまとめたりする作業の自由度も上がります。 尚、副次キー(主キー以外のキー項目)を作る事は構いません。例えば、何かの作業で別の番号を振ったとしても主キーを削除せず更新もせずにそのまま残しておけば問題ありません。 |
| 抽出範囲 | 抽出範囲は多くの場合、オーナーから指示されると思います。例えば「月ごとの不具合一覧」とか「未完了の不具合一覧」などです。 |
| 利用目的 | 表形式の電子データは表現できる情報に制約があります。そこで、「共通データ仕様の活用方法」にも記載したように利用目的を予め明確にします。利用目的が分からないと、大変な数の表を用意する事が必要となり、データを作成する側も利用する側も大変な苦労をすることになります。 |
| 文字コード | できればUNICODEのUTF-8が望ましいです。これは、インターネットにおけるデファクトスタンダードとなってるいためで、文字化けなどを避けるのに有利であるためです。尚、ソフトウェアによっては同じUTF-8でもBOMなしとBOM付きを選択できる場合があります。これはBOMなしが望ましいです。UTF-8には本来BOMは無いので、BOMなしを選択します。 |
| リスト表現の対策 | リスト表現とはひとつの項目に複数の値を登録する表現方法です。例えば法人の通称を登録する事を考えると、東日本旅客鉄道株式会社の場合利用者はJR東日本、JR東、JR East、JREなどの多様な呼び方をしています。これをそのままCSVにすることはできないので回避方法を前記の利用目的に照らして選択する必要があります。一つ目の回避方法は項目を分ける方法であり、前記の例では「通称1」「通称2」「通称3」などといった複数の項目を設けて登録する方法です。この場合は登録できる個数に上限ができてしまいます。上限を設ける事が出来ない場合は表を分ける方法を採用します。例えば「通称一覧表」というものを別に作ります。繰り返しになりますが、その場合も通称一覧表には元の表(東日本旅客鉄道株式会社を登録した表)の主キーを格納しておくことが必須です。 |
| 構造表現の対策 | 構造表現とは例えば住所の様に都道府県・市区町村・それ以下の複数の値から構成されている様な項目です。この場合、まとめてひとつの項目にすることもできますが、後で加工が難しくなるので出来れば項目を分けて下さい。前記の例では「住所都道府県」「住所市区町村」「住所それ以下」の様に三つの項目に分けます。 |
| 項目名 | 項目名はオーナーから指定される場合もあると思いますが、もし可能であれば各データモデルに記載してある「呼称」を採用してください。本協議会のホームページでは主に呼称を使って説明しています。 |
あとは、共通データ仕様の活用方法に記載した手順を参考に表形式の電子データを設計して頂けば共通データ仕様の観点では良いと思います。
