clock2015.01.28 08:59
SERVICE
home

第3回・フラットファイル(固定長フォーマット)|CSV、XML、JSON…データフォーマットの変遷について考える

AUTHOR :  岩谷 和男

3.3k
岩谷 和男
data_format_title

beaconまずはじめはフラットフォーマットから

本連載の第1回はデータフォーマットの変遷を考える上で取り上げるデータの概要を説明しました。また第2回(前回)は、テキストデータ処理を考える上で必要となる「データを処理する際の共通的な取り決め」について説明しました。第3回である今回からいよいよ各フォーマットについて説明していきます。第一弾はフラットフォーマット(固定長フォーマット)です。参考までに、これから取り上げていくフォーマットの一覧を再掲します。

  1. フラットフォーマット(固定長フォーマット) ←今回
  2. Character-Separated Valuesフォーマット(CSV,TSV,SSVなど)
  3. XMLフォーマット
  4. JSONフォーマット

また、これまで例題としてきたサンプルデータも再掲します。

順位 氏名 本数
1 王貞治 868
2 野村克也 657
3 門田博光 567
4 山本浩二 536
5 清原和博 525

※出展:日本プロ野球機構オフィシャルサイト・歴代最高記録 本塁打 【通算記録】より

フラットファイルはデータの長さが固定されている

連載第1回でも申し上げましたが、上記サンプルデータをフラットフォーマット(固定長フォーマット)で表すと以下のようになります。

001王貞治□□0868002野村克也657003門田博光567004山本浩二536005清原和博525

注.□は半角空白文字をあらわします。

各データがフラットに並んでいます。改行もありません。固定長データは「Xバイト目~からYバイト目まではZという項目である」というルールでデータを処理していきます。本データにおいては、「1バイト目から3バイト目までは順位、4バイト目から11バイト目までは氏名、12バイト目から15バイト目まではホームラン数、ここまでを1人分のデータとして、16バイト目以降は2人目のデータ、3人目のデータを同じルールで繰り返す。」というルールになっています。また、ここでは全角文字は2バイトとして計算するというルールも存在します。こんなデータを「前回説明した6つの共通的な取り決め」に照らし合わせて特徴を明らかにしていきましょう。

① データ構造

前回私は、

  • 1人目のデータを格納しているのはどの場所か。2人目のデータを格納しているのはどの場所か。
  • 1人分のデータの中で、順位を格納しているのはどの部分か。同様に氏名は。ホームラン数は?それぞれどの場所に格納されているか。

これらに関する取り決めを定めている(=持っている)のは誰でしょうか?入力データでしょうか?プログラムでしょうか?という質問をしました。

フラットファイルの場合、それを定めているのはプログラムです。データの中に構造を定める要素はなにもありません。このホームラン順位のデータを処理するプログラムだけが(もしくはそのプログラムの作成に関わった人だけが)このデータの構造を知っている事になります。それ以外の第三者は、このファイルを渡されてもどんなデータがどのように格納されているかを知ることができません。

例えば、このデータをAさん(Aさんのプログラム)が作って、そのデータをAさん→Bさん→Cさん→Dさんが利用していく場合、B・C・DさんはAさんから「プログラムが処理するデータ仕様(ファイルレイアウト)」が提供されないと処理ができないのです。参考までに本サンプルデータのデータ仕様の例を以下に示します。

データ仕様
データ名 歴代ホームラン数の順位
文字コード Shift_JIS
項目№ 項目名 桁数 開始桁位置
1 順位 3桁 1桁目
2 氏名 8桁 4桁目
3 本塁打数 3桁 12桁目

 

ここでみなさんに気にとめておいていただきたい事があります。

それは、Aさん→Bさん→Cさん→Dさんとデータが手渡されていく際に上記のデータ仕様も一緒に手渡されていかなければならないという事です。データだけではなくその仕様も一緒に連携されていかなければ、データが処理できないのです。これは素直に「面倒くさい」事です。「データ仕様書の受け渡しなんて面倒くさい。データだけが手渡されていけば、受け渡し先の人が処理できるようにしたい。」とみなさん思うはずです。この面倒くさい状態は、「データの再利用性が低い」と言われます。この観点において、「固定長フォーマットは再利用性の低いデータフォーマットである」と言えるわけです。次回以降説明する他のデータフォーマットについても同様の比較を行いますので、みなさん気にとめておいてください。

② 項目の最大データサイズ

このルールを持っているのも上記①と同じくプログラムです。固定長データは「項目データサイズを構造的に固定して処理を行う」というフォーマットなので、実はこの②の取り決めは上記①のデータ構造に関する取り決めに包含されることになります。ゆえに取り決めを定めているのもプログラムになるわけです。

ここで着目したいのが、「一度決定した項目の最大データサイズを後から変更する場合、それまでに作成したプログラムにどの程度の影響が発生するのか?」という事です。例えば、本サンプルデータの仕様においては、氏名は8桁(全角文字で4文字)が最大データサイズなので、例えば「ランディ・バース」さんは、「ランディ」までしか入りません。これを全て格納するためには、データ仕様を変更することになります(8桁:全角4文字→16桁:全角8文字)。そしてデータ仕様の取り決めを定めているのはプログラムなので、プログラムに変更を加えることになるのです。またデータ仕様の変更前のファイルとデータ仕様の変更後のファイルはデータ構造が異なりますが、プログラムはそれを区別できません。このような場合はデータ仕様変更前のファイルを一括でデータ仕様変更後のファイルに変換する「移行処理」を行うか、データ仕様の変更前後のファイルをそれぞれシステム上別の処理としてプログラム処理を分割する必要が発生します。

ちなみに、「それなら上記の項目最大データサイズをはじめから500桁(全角250文字)にしておけば問題ないじゃないか?」と思われるかたもいらっしゃることでしょう。サンプルデータの王貞治さんの箇所を見てください。「王貞治□□」と、お名前の後ろに半角スペースが2つ入っていることにお気づきいただけると思います。固定長データはデータ構造上長さを固定しているので、「データの長さが項目長に満たなかった場合、文字列データに関しては右側をスペースで埋める、数値データに関しては左側を0で埋めたフル桁のデータを格納する」というルールになっているのです。この場合王貞治の左側に494個の半角スペースを入れることになります。これはデータの無駄遣いであり処理全体の効率を低下させます。また人名に関しては500桁を設ければOKかもしれませんが、これが「メールの本文を格納する」という要件であったならどうでしょうか?1メールの本文全てを格納する必要な桁を取り決めることは非常に困難です。

項目の最大データサイズに変更が発生した場合、プログラムや変更前の既存データに変更が発生する。これは素直に「不自由な事」です。「項目のサイズ変更ぐらい、プログラムが柔軟に対応してほしい。」とみなさん思うはずです。この不自由な状態は、「データの自由度が低い」と言われます。この観点において、「固定長フォーマットは自由度の低いデータフォーマットである」と言えるわけです。

③ レコードの最大データサイズ

この取り決めを定めているのは、データになります。本サンプルは歴代1位の王さんから歴代5位清原さんまで掲載していますが、このデータに6位のかたが加わったとしても、プログラムの処理に変更はありません(ちなみに6位は落合さん)。データレコードの最大データサイズ(レコードの件数)はに関しては、「固定長フォーマットは再利用性・自由度ともに高いデータフォーマットである」と言えるのです。

④ 文字コード

この取り決めを定めているのはプログラムです。データの中に構造を定める要素はなにもありません。このホームラン順位のデータを処理するプログラムだけが(もしくはそのプログラムの作成に関わった人だけが)このデータの文字コードを知っている事になります。それ以外の第三者は、このファイルを渡されてもどんなデータがどのように格納されているかを知ることができません。この点においては上記①のデータ構造についての説明とまったく同じです。したがってデータの再利用性に関しても高いとはいえません。

⑤ エスケープ文字

この取り決めを定めているのは、データになります。というのも「フラットファイルはエスケープ文字が存在しない。」という取り決めがデータ側によって定められているのです。エスケープ文字は「データ処理ルールにおいて、特殊な意味を持つ文字の意味を無効化する」事です。フラットフォーマットは「項目データサイズを構造的に固定して処理を行う」というフォーマットなので、「特殊な意味を持つ文字」が存在しないのです。よってこの点においては「フラットフォーマットは再利用性・自由度ともに高いデータフォーマットである」と言えるのです。

⑥ 処理速度

固定長フォーマットファンの皆さんお待たせ致しました。いままではネガティブな説明を多くしてきましたが、ここでフラットフォーマットの最大の長所を説明させてください。処理速度は高速です。本連載で紹介する4フォーマットの中で間違いなく最速です。企業のシステムにおいては、いまだに固定長フォーマットを使用している企業も数多く存在しますが、それは大容量データを扱う上でこの高速処理可能というフォーマットの優位性が依然として価値を持っているからだといえるでしょう。

ここで、なぜこのフォーマットが高速な処理を可能とするのかを簡単に説明します。例えばCSVファイルは改行文字をデータ1レコード分の区切り文字としたルールを持っていますが、これを処理するプログラムはCSVファイルのデータ1バイトずつを順番に見ていってそれが改行文字であるかを判断しているのです。1メガのファイルであれば100万回判断しているのです。対してフラットフォーマットは、あらかじめ決められた(=固定長の)データサイズを一気にファイルやメモリから読み出すので、この判断を必要としません。この差が処理速度の差となって現れているのです。XMLファイルやJSONファイルは、CSVよりも複雑なフォーマットを持っています。ゆえにこの速度差はより開いていくことになります。

今回は、各フォーマット説明の第一弾として、フラット(固定長)フォーマットについて説明しました。まとめをもうしあげますとこのフォーマットは、

  • データ仕様に関する情報をデータ側にほとんど持っていないので、データの再利用性や自由度が劣る。
  • シンプルであるがゆえに処理速度は速い。

ということが言えるでしょう。

次回は、みなさんもよく目にするCSVファイルについての説明をさせていただきます。

本連載について

 

SERVICE

SERVICE

BANNER

graffe

grip

GiXo BLOG

recruit

Aibou

amazon web service partner network

TAG BOX