フラットファイルデータベース

「フラットファイル」とはプレーンテキストまたはテキストとバイナリの混合であり、通常1行が1レコードになっている^[2]。レコード内はフィールドを区切り文字（デリミタ）で区切った構造になっており、例えばカンマで区切ったり、固定の文字数で区切ったりする。後者の場合は、規定の長さを満たすためにパディングを必要とする。一般にデリミタはフィールド内では使えない文字になるため、注意が必要である（フィールド内にデリミタと同じ文字があると、そこが区切りだと誤って解釈してしまうため）。レコード同士の間には構造的関連性はない。

フラットファイルの典型例としては、Unix系オペレーティングシステムの /etc/passwd や /etc/group がある。例えば、各行に名前と住所と電話番号をその順番で記述したファイルは、住所録のフラットファイルである。

フラットファイルは人間が手で書いて紙上に作成することもでき、それも一種のフラットファイルデータベースである。もちろん、タイプライターでもワードプロセッサでも作成できる。

計算機械の初期の用途として、単純なデータベースの実装があった。ハーマン・ホレリスは国勢調査のデータを穴を開けた紙製のカードで表し、機械を使って作表するというアイデアを思いついた（タビュレーティングマシン）。彼はこのコンセプトをアメリカ合衆国国勢調査局に売り込んだ。これにより、1890年のアメリカの国勢調査は史上初めて計算機械を使ってデータベース化されたと言える。ただし、そのデータベースは無数のパンチカードで構成されていた。

ホレリスの企業はIBMの元となり、IBMは20世紀のデータ処理市場を支配し続けた。IBMの固定長フィールドの80桁のパンチカードは1970年代ごろまでデータ入力の一般的手段として使われ続けた。

1980年代になると、DOSまたはMacintosh上で設定変更可能なフラットファイルデータベースがアプリケーションソフトウェアとして多数開発された。それらは、個人的なデータベースを簡単に設計でき、ワードプロセッサや表計算ソフトと同じ程度には売れていた。フラットファイルデータベース製品の例としては、初期のFileMaker、シェアウェアのPC-Fileなどがある。関係を表す能力は限定的だったが、複数ファイル間でデータを共有することができた。

FairComのC-treeは、企業向けの最近の実装例である。しかしそれ以外では、初心者が簡単にフラットファイルデータベースを利用できるようなソフトウェア製品は少ない。そのような機能は Microsoft Works のデータベース機能（一部バージョンのWindowsでのみ利用可能）、クラリスワークスの名称でも知られているAppleWorks（Macintosh版とWindows版があった）にあった。ボーランドのParadoxやマイクロソフトのAccessのようなデータベースソフトが関係データベース的な機能を提供するようになり、同時に組み込みのプログラミング言語を使うようになっていった。MySQLやOracleのようなデータベース管理システム (DBMS) は一般に初心者が扱えるものではなく、プログラマがアプリケーションを組んで初めて利用可能となる。

多くのアプリケーションソフトは内部的にフラットファイルデータベースを使って設定データを格納している。ユーザーが情報を入力したり引き出したりする形態のアプリケーションは内部でフラットファイルを使っていることがある。例えば、何らかのコレクションの管理ソフトや予定表などのソフトウェアである。小さな住所録ソフトも内部ではフラットファイルに情報を格納していることが多い。

XMLはプレーンテキストのファイルにデータを格納する用途でよく使われるが、XMLは非常に構造的で、格納すべきデータについても定義されている。したがって、フラットファイルモデルとは全く異なる。

「フラットファイルデータベース」という用語は、データベース論における狭い意味と、一般に使われる広い意味を持つ。

厳密には、レコード長やデリミタがどうであれ、データ以外を含まない。より広義には、単一のファイルで構成されるデータベースで、表形式になっているものの、各フィールドやレコード間にリンク（あるいは関係）が存在しないものを指す。

データベースや関連ツールを表す用語は実装によって様々だが、概念は同じである。FileMaker で Find と言った場合、MySQL の Query と同じ概念を意味している。FileMaker の「ファイル」はMySQLの「表」と同じである。

ただし、「レコード」と「フィールド」という基本用語はどんなフラットファイルデータベースの実装でもほぼ間違いなく使われている。

ここでは、フラットファイルデータベースの基本要素を例で解説する。データは行と列で配置され、1つのテーブルを構成する。ここでは単一のテーブルを使用して説明する。

列として name（人物名、第2列）、team（その人物が属する運動会のチーム名、第3列）、数を値とする id（レコードを一意に識別するのに使われる。第1列）がある。

この形式のデータをテキストで表した例を以下に示す。

id    name    team
1     Amy     Blues
2     Bob     Reds
3     Chuck   Blues
4     Dick    Blues
5     Ethel   Reds
6     Fred    Blues
7     Gilly   Blues
8     Hank    Reds

このようなデータ表現はフラットファイルデータベースでは極めて一般的だが、テキスト表現からは分からない以下のような考慮すべき点がいくつかある。

データ型

上のようなデータベースの表のそれぞれの列は、特定のデータ型でなければならない。そのような制限は通常、規約によって確立されるが、データが関係データベースシステムに転送されるまで正式に示されることはない。

列の分離

上の例では列と列の間は空白文字で区切られている。また、固定フィールド長のフォーマットになっているともいえる。他のデリミタ文字を使って列を区切る場合もある。列やフィールドの区切り方には様々な規約がある（例えば CSV、マークアップ言語、プログラミング言語などを参照）。固定フィールド長でない場合、デリミタに出会うまで一文字ずつ調べる必要があり、若干のオーバーヘッドが生じる。しかし、カンマを代表とするデリミタを使うことでデータ量を減らすことができ（無駄な空白の連続がないため）、データ転送目的には重要だった。固定フィールド長でかつデリミタ文字を併用することは珍しいが、フィールドを素早く切り出すことができるという利点がある。

関係代数

上記の例での行あるいはレコードは、関係代数におけるタプルの定義に適っている（上の例では3-タプル）。さらに、1行目はフィールド名になっており、それが他の行のそれぞれの値を関係付けられる。

データベース管理システム

テキストファイルでの形式操作は非常に限られている。そのため、上記の例はデータベース管理システムに転送される前のデータの中間状態を表していると解釈するのが妥当である。すなわち、フラットファイルデータベースであっても、実際にデータベースアプリケーションで利用する際にはフラットファイルのままデータを内部に保持するのではない。

• Berkeley DB - フラットファイルデータベースでありながら、ACIDトランザクションをサポートしている。
• Borland Reflex
• TextDB - 高負荷にも耐えるフラットファイルベースのデータベース
• Mimesis - 複数のファイルを扱えるフラットファイルデータベース
• MySQL CSV - MySQL 5.x 用ストレージエンジン