これも構造化技法で使われる道具ですが、いわゆる構造化技法以外でも使う人は結構いると思います。データの論理構造を定義するためのもので、あくまでも「構成」を焦点として扱い、「意味」は定めません。ちなみに構成には順番は入っていません。
見かけは、きわめて単純。
<定義されるもの> := <定義>
です。”:=” は “=” だけで済ますこともあります。さらにどうせ定義されるものと定義するものの対になっているので、表の形にしてしまうこともあり、Excel などで作る場合もあります。
例えば、
住所 := 都道府県名 + 市町村区名 + 町名 + 番地
都道府県名 := { 北海道 | ・・・ | 沖縄県 }
北海道 := 文字列 文字コード体系: UTF-8 値: “北海道”
：
：
沖縄県 := 文字列 文字コード体系: UTF-8 値: “沖縄県”
市町村区名 := 文字列 文字コード体系; UTF-8 文字列長: 2～7
；
こんな感じになります。基本、BNF 表記になりますが、BNF 表記自体が定義次第のところもあり、そこらへんの取り決めがちゃんとなされていることが必要でしょう。
その上で、最終的に自明な表記の右辺（定義）に解釈できるように<定義されるもの1> := <定義されるもの2> := ・・・ := <定義されるものn> := <定義> になるようにします。
最後の <定義> が不明確なら、まだデータディクショナリーは出来上がっていないことになります。
最後の <定義> が明確か否かは、どう書かれて(fomulation)いれば良いかを決めておいて、それで判断します。例えば、
文字列 文字コード体系: <文字コード体系識別子> 文字列長: { <零元> | <自然数> }
としておいて、<文字コード体系識別子> は有効なものを定めれば宜しいでしょう。例えば Unicode の UTF-8 や UTF–16、ASCII などです。もし UTF-8 でも日本語で扱っている範囲に絞りたいとかあれば、値範囲を指定した識別子を使うか、一般的な ja_JP.UTF8 などを使うなどもあるでしょう。
<零元> や <自然数> は、まあ問題ないでしょう。
これとは別に、
文字列 文字コード体系: <文字コード体系識別子> 値: “・・・”
などというのもありえるでしょう。この場合は、”・・・” のところに実際の値が入ります。”あれ” や “それ” や “これ” といった具合です。
上で、まあ問題ないでしょうとした、{ <零元> | <自然数> } ですが、要求分析のおしまいごろや、設計段階になると 8bit で表現可能な 0～255 の整数とか、より明確にします。
上記のような住所の定義ですと、都道府県名は現実に存在するものだけに限定できますが、市町村区名以下については長さは制限されても、現実に存在しないものも適合になってしまいます。たとえば、”北海道とんとかいも市なんちゃって町 0番地”でも良くなってしまいますが、これはこれでＯＫ。
この点が問題になる状況なら定義の仕方を替えれば良いのですが、私見ですがあまりこれはデータディクショナリーの段階でやるのは、分かりづらくなるし、そもそも初期の要求分析などの段階では、あまり意味が無いことが多いです。
それでも例えば、入力の最初の段階でありえない住所ははじきたいとかあると、作ることもあるかもしれませんが、通常は住所のデータベースなどとつき合わせてチェックということになるでしょうから、データディクショナリーで無理にすることもないと思います。
※ データベースとの絡みでいえば、データディクショナリーはデータベースのテーブル構造の設計に相当するので、そこに突っ込む実際のデータまでは・・・ということになります。
ちなみに、現実にありうる住所だけにしたいというなら、
住所 := { 北海道住所 | ・・・ | 沖縄住所 }
北海道住所 := 北海道 + 北海道市町村区住所
北海道市町村区住所 := { 札幌市住所 | ・・・ }
札幌市住所 := ・・・
などと分岐して落としていくかたちにすれば、このケースではできると思います。
とはいえ、ここまでやると論理構造も示すけれど、意味にも片足突っ込んでいる感あ出てきますから・・・やっぱりやりすぎでしょうね。