データ・ディクショナリ （Data Dictionary） と リポジトリ （repository）は、専門用語として、ちがう概念である。
　ただ、同じように使うことが多い。

　データ・ディクショナリ は、DD/DS という考えかたとして提示された。DD/DS とは、Data Dictionary/ Directory System の略語である。ディレクトリ （directory） は、DBMS （Data Base Management System） の 1つの管理 ツール として、ディスク のなかに記憶されている ファイル の管理情報 （ファイル 名称や、そのほかの物理的定義情報） を収録している。ディレクトリ は、ファイル・キャビネット （a filing cabinet） の 「抽き出し （a drawer）」 のなかにある フォルダ （a folder） として考えてもよい。1つの フォルダ には、複数の物理的 ファイル が収録されている。すなわち、ディレクトリ には、[ machine-readable な ] データストア （data store） 情報が収められている。

　いっぽう、ディクショナリ は、IRM （Information Resource Management） の観点から提示された。
　[ machine-readable な ] 物理的情報を作る前に、データ の構造を、まず、設計する。データ 設計には、以下の 3つの段階がある [ 280 ページ を参照されたい ]。
　（1） 概念設計
　（2） 論理設計
　（3） 物理設計

　それらの設計情報を収めて、（情報を収録する） データベース と、（情報を使う） 事業の 「橋渡し （接点）」 として作用する ツール が、ディクショナリ である。言い換えれば、ディクショナリ は、「データベース のなかに収録される情報」 に関する記述を収めていて、データベース を 「一元管理」 する ツール である。
　言い換えれば、ディレクトリ のなかに収められている データ は、データベース のなかに ロード された実 データ に対する 「メタ・データ」 であり、ディクショナリ のなかに収められる データ は、（ディレクトリ の 「メタ・データ」 を定義する） 「メタ・メタ・データ」 である。ディクショナリ のなかに定義される情報には、たとえば、物理設計の アウトプット であれば、以下のような情報がある。

　（1） データ 情報 （database、area、file、record、field、key、element、dataview など）
　（2） アプリケーション 情報 （system、job、step、module、program、report、panel など）
　（3） セキュリティ 情報 （person、authorization　など）
　（4） 分散処理情報 （node など）

　ちなみに、データ・ディクショナリ が、DBMS に対して作用する形態 （データ・オペレーション 形態） として、「active」 という言いかた がある。「active」 とは、ディクショナリ が、DBMS を一元管理して、ディクショナリ のなかに定義されない情報は、DBMS のなかにも定義されない──逆に言えば、DBMS のなかで使う情報は、かならず、ディクショナリ のなかに定義されなければならない──ということである。その形態のことを 「dictionary-driven （ディクショナリ 駆動型）」 ともいう。

　1980年代前半、いくつかの データ・ディクショナリ が出てきた。それぞれ、特徴のある ディクショナリ であった。
　しかし、たとえば、2種類の DBMS を導入した際、2種類の DD/DS を導入することになって、本来、一元管理されるべき情報資源が、事実上、（仕様および管理手法がちがう） 2つの ディクショナリ のなかに散らばってしまい、2つの ディクショナリ のあいだでは、データ の移植性・互換性が確約されていなかった。
　「情報資源管理用 ツール の情報資源を管理する ツール」 を考えなければならない、という事態に陥ってしまった。

　そういう事態を避けるために、ANSI （American National Standards Institute） が、「標準的な」 ディクショナリ 仕様を、IRDS （Information Resource Dictionary System） として、1988年に公表した。「ANS/IRDS」と略称されることが多い。

　DD/DS および IRM の観点から、ディクショナリ が論点になっていた頃、リポジトリ という用語は、ディクショナリ の性質を定義するための一般名詞にすぎなかった。たとえば、「Data Dictionary is a repository...」。

　いっぽう、1980年代後半、CASE （Computer-Aided Software Engineering） ツール が出てきた。
　CASE は、以下の 2点を狙いとしていた。

　（1） 構造化手法の自動化
　（2） SDLC の自動化

　つまり、SDLC のそれぞれの工程 （分析工程・設計工程・製造工程・保守工程） のなかで使われている手法 （構造化手法） を自動化して、SDLC の全工程を自動化することを狙いとしていた。
　しかし、構造化手法を自動化しても、それぞれの工程を結ぶことができなかった。^（参考）

　SDLC の全工程を自動化した CASE ツール を 「I-CASE （Integrated CASE）」 といい──たとえば、テキサスインスツールメンツ 社 の IEF （Information Engineering Facilities） は、I-CASE であった──、1つ以上の構造化手法を自動化したけれど、全工程を自動化しない CASE ツール を「C-CASE （Component CASE）」 という──たとえば、DFD の自動化 ツール とか、ER 手法の自動化 ツール とか、プログラム・ジェネレータ とか。

　C-CASE を接続するために、IBM 社が、AD/Cycle （Application Development Cycle） のなかで、「リポジトリ」 を使う （作る） 構想を、1989年に公表した。IBM 社の 「リポジトリ」 は、AD/Cycle のなかで使われる C-CASE を接続して、かつ、DB2 の ディクショナリ として使うことを目的としていた。
　すなわち、リポジトリ は、（DB2 に対する ディクショナリ であると同時に、） C-CASE を接続する役割を担う。言い換えれば、リポジトリ は、C-CASE が使っている ダイアグラム 法をも対象にしている。

　ディクショナリ が出た頃には、CASE は出ていなかった。したがって、ディクショナリ は、ダイアグラム の生成を考慮していなかった。いっぽう、リポジトリ は、C-CASE を接続するために出てきたので、ダイアグラム の生成を考慮している。すなわち、CASE ツール が、ダイアグラム のなかで オブジェクト を生成しても、その オブジェクト に対応する定義を、自動的に、ディクショナリ のなかに生成することができなければ、「ディクショナリ 型」 の ツール である。あるいは、ディクショナリ のなかに、直接、情報を入力して、その情報に対応する ダイアグラム を生成できなければ、「ディクショナリ 型」 ツール である。

　したがって、単純に言い切ってしまえば、リポジトリ は、データベース に対する ディクショナリ としての役割のほかに、ダイアグラム に対する配慮を加味した、と理解してよい。