Ｔ字形 ER図を実装するためには、以下の実装形を判断しなければならない。

　（1） 対照表
　（2） サブセット
　（3） VE

　
　以上の実装形の作りかたは、拙著を参照されたい。

　さて、RDB は （マーケット のなかで セールス される） プロダクト だから、値段 （製造費用） を考慮して、搭載されている しくみ には、制限がある。高い値段の プロダクト であれば、正規形を、そのまま、実装して、高 パフォーマンス を実現できるが、廉価な プロダクト であれば、（高価な プロダクト に比べて、） 搭載されている しくみ が制限されている点は、やむを得ない。

　もし、（高性能な プロダクト を使えば、パフォーマンス を苦慮しなくても済むにもかかわらず、なんらかの理由があって、） 廉価な プロダクト を使わざるを得ないときには、正規形を、そのまま、実装すれば、高 パフォーマンス を実現できないかもしれない。そして、そういう状態を回避するために--I/O を削減するために--、正規形を崩すことがある。それが、いわゆる 「非正規化」 といわれている作業である。

　非正規化は、往々にして、多くの テーブル を （アウトプット の形に近い） 1つの テーブル として まとめることをいうが、逆に、正規形を、もっと、割ることも考えてみればよい。

　
● 記録されたあとで、更新されない データ に対しては、集計用 ターボ・ファイル を用意してもよい。

　多くの テーブル を 1つの テーブル にして まとめることが、高 パフォーマンス を実現することもある--たとえば、「event」 系の データ を集計して、レポート （報告書） を作成するとか。「event」 系の データ は、時系列のなかで記録されるので、いったん、記録されたら、変更されることが、ほとんど、ない。いったん、記録されたら、変更されない データ に対しては、集計を、同時に作成しても、（重複を対象にした変更が起こらないので、） 組織変更・事業変更・プログラム 修正が起こっても、データ そのものを変更しなければならない事態を招くことが、ほとんど、ない。

　そういう 「event」 系の データ に対しては、（データ を正規化しないで、） インプット の形を、そのまま、記録して、同時に、アウトプット 用の テーブル を作成しても、データ 構造上、大きな混乱 （メンテナンス 性の低下） は起こらない。（そういう 「event 系」 の データ は、変更されないのだから、） 当然ながら、「event」 系の データ を 「正規化して」、集計用の 「非正規化」 テーブル （スーパー・ターボ・ファイル） を作成しても、ほとんど、同じことである。
　つまり、入力された データ を正規化するが、いっぽうで、アウトプット （集計レポート） のための テーブル も、同時に用意する、という非正規化である。

　ターボ・ファイル （非正規形） を用意する理由は、RDB には、更新 （UPDATE） の I/O を削減する しくみ （pipeline） が搭載されているが--pipeline を搭載していない RDB も多いが--、照会 （READ） の I/O を、直接に削減する しくみ がないので、照会の パフォーマンス を高める点にある。

　
● 「INDEX-only」 を前提にすれば、正規形 テーブル を、さらに、割ることを考えればよい。

　照会の I/O を削減するために、SDI/RAD では、「INDEX-only」 を推奨している。「INDEX-only」 を応用すれば、物理設計では、テーブル （正規形） を、さらに、割る技巧を使えばよい。「INDEX-only」 を前提にした「JOIN （あるいは、PROJECTION）」 を使えば、照会の I/O を、圧倒的に削減できる。

　「INDEX-only」 は、廉価な プロダクト では、（更新の パフォーマンス が低下しないように配慮して、） 1つの テーブル に対して、CREATE INDEX を 3つ以内に制限している。1つの正規形 テーブル を、さらに、（アクセス の効率を配慮して、） 2つ以上に割って、（切り離された テーブル 群に対して、） 「INDEX-only」 の 「JOIN （あるいは、PROJECTION）」 を使えば、（割った テーブル に対して、それぞれ、3つの インデックス を生成できるので、1つの テーブル に対する インデックス に比べて、インデックス を多く使うことができるから、） 「INDEX-only」 を使った 「view」 の数を増やすことができ、高 パフォーマンス を実現できる。

　「INDEX-only」 （index-key を view のように使うこと） を使うのであれば、「正規形」 は大前提である。そういうふうに言えば、論点先取りであって、「正規形」 を、そのまま、実装して、「正規形」 に対して 「view」 を適用するのであれば、（すべての データ・テーブル が メモリー のなかに収録されないかぎり、） 「INDEX-only」 を使うのが最良法である。

　RDB を使うのであれば、RDB の特徴点は、（集合論演算のほかに、） 独特の データ 演算として リレーショナル 代数演算 （SELECT、JOIN および PROJECTION） にあるのだから、リレーショナル 代数演算を最大限に活用することを考えたほうが良い。すなわち、データ 演算は、SELECT で済ませるように、アルゴリズム を できるかぎり I/O 化して、テーブル を JOIN して、PROJECTION を高 パフォーマンス で作ることを考えたほうが良い。しかも、RDB は、コッド 関係 モデル とは無関係な indexing を搭載しているので、RDB の機能を最大限に使って、コッド 関係 モデル の特性を活かすようにすれば良い。言い換えれば、レコード・アット・ア・タイム 法 （indexing） を セット・アット・ア・タイム 法のように使うというのが、RDB 活用法の コツ である。それを実現する手法が 「INDEX-only」 である。

　そして、「INDEX-only」 を最大限に使いこなすためには、データ は正規形でなければならず、高 パフォーマンス を実現したいなら、（「意味」 の最小単位である） 正規形を、さらに、分割すれば良い。「テーブル を千切 （ちぎ） って千切って、さらに、千切る」 というのが高 パフォーマンス を実現する コツ である [ これも、或る意味では 「非正規化」 かもしれない ]。複数の テーブル を 1つに まとめて、従来の レコード・アット・ア・タイム 法を適用しても、（単純な セット・アット・ア・タイム 法に比べて、パフォーマンス が良くなるが、） 多量 データ・多量 トランザクション を対象にして高 パフォーマンス を実現できる訳ではない点に注意されたい。