PMMLの中の階層の表\現は親/子供関係に基づきます。平板状(tabular)のフォーマットはこれらの関係にデータを供給するために使用されます。

分類は、1つ以上の親/子供テーブルのシーケンスから構\築されます。実価は外部テーブルに格納することができます。そのようなテーブルは、テーブル用の1種のURLをインプリメントするTableLocatorによって、参照されます。平板状のデータはさらにPMMLドキュメントそれ自身の一部でありえます。その場合では、要素InlineTableがTableLocatorの代わりに使用されます。以下に、私たちはこれらのテーブル参照の例を示しましょう。しかしながら、内容の実際の定義はPMMLの範囲の外にあります。XMLの中のデータ・ベース・テーブルの表\現に対処する他の標準は、今後利用可能\になる予\定です。PMMLの中の現在の定義は、もっと今後、改良されるフレームワークであるように意図されます。

<!ELEMENT Taxonomy ( ChildParent+ ) >
<!ATTLIST Taxonomy
	name 			CDATA 		#REQUIRED
>

<!ENTITY % TABLE "( TableLocator | InlineTable ) " >


<!ELEMENT ChildParent ( %TABLE; ) >
<!ATTLIST ChildParent
	childField 		CDATA 		#REQUIRED
	parentField 		CDATA 		#REQUIRED
	parentLevelField 	CDATA 		#IMPLIED
	isRecursive 		(no | yes) 	"no"
>

<!ELEMENT TableLocator (Extension*) >
<!ELEMENT InlineTable (Extension*) >

属性記述（Attribute Description）

childField:レコード毎に子値（child value）を含んでいるフィールド名を定義します。

parentField:レコード毎に親値（parent value）を含んでいるフィールド名を定義します。

parentLevelField:親のレベル数を含んでいるフィールド名を定義します。最低のレベルの子は通常レベル０メンバーと呼ばれます。すなわち、親のレベル数は1でスタートします。レベルが子供/親データそれ自身から導出されうるので、parentLevelFieldはオプションです。

isRecursive:再帰的（recursive）なテーブルは1つのテーブルに完全な分類を定義することができます。すなわち、親フィールドでの値も子フィールドの中で使用することができます。

TableLocatorは、アプリケーションがあるテーブルを見つけるのを助けるすべての記述を含んでいるでしょう。PMML 2.0はまだ内容を定義しません。PMMLユーザは自分の拡張を使用しなければなりません。同じことはInlineTableなことに当てはまります。

例:

ZIP code、Cityおよびstatesを持った階層を以下のように定義してみましょう。

<Taxonomy name="ZIP-City-State">

<ChildParent childColumn="ZIP code" parentColumn="City">
	<TableLocator x-dbname="myDB" x-tableName="ZIP_City" />
</ChildParent>

<ChildParent childColumn="cities" parentColumn="states">
	<TableLocator x-dbname="myDB" x-tableName="Cities_States" />
</ChildParent>

<ChildParent childColumn="State" parentColumn="Country">
	<TableLocator x-dbname="myDB" x-tableName="AllStates" />
</ChildParent>

</Taxonomy>

実際のデータは、ロケータによって与えられるような名前を備えたテーブルに存在するだろう。

ZIP_City | ZIP code    | City
===================================
         | CA 95126    | San Jose
         | CA 95020    | Gilroy
         | CA 90806    | Long Beach
         | IL 60463    | Oak Lawn
         | MA 02149    | Everett


Cities_States | cities     | states
===================================
              | San Jose   | CA
              | Gilroy     | CA
              | Long Beach | CA
              | Oak Lawn   | IL
              | Everett    | MA


AllStates | State | Country
===========================
          | CA    | USA
          | IL    | USA
          | MA    | USA

3つの異なるテーブルに子/親データを格納する必要がないことに注意してください。さらに、私たちは、statesのためのカラムを含めるためにテーブルZIP_Cityを拡張することができました。これは「City, State ZIP」を持つ典型的なアドレス・フォーマット（typical address format）に近いものになるでしょう。

階層は、2つのテーブルで以下のように表\わされうる:レベル0アイテムの1つのテーブル、それらの親、上位の要素/カテゴリーレベルの他のテーブル、それらの親用テーブル。後者のテーブルは、親カラムの値が子カラムにも現れるという意味で、再帰的でしょう。付加的な属性「isRecursive」は、ルートレベルまでの親/子供関係を定義するテーブルにフラグを立てることを意図しています。再帰的なテーブルがそのとき要素分類(Taxonomy)の内容に現われるなら、それはシーケンスの最後のテーブルでなければなりません。

TableLocatorとInlineTable

要素TableLocatorとInlineTableは、他の標準化グループがこれらの問題を手がけているので、まだ完全には定義されません。PMML 2.0のためのこれらの要素の予\備（preliminary）定義は次の例のようにすることが出来るでしょう。

<Taxonomy name="ZIP-City-State">

<ChildParent childColumn="ZIP code" parentColumn="City">
	<TableLocator x-dbname="myDB" x-tableName="ZIP_City" />
</ChildParent>

<ChildParent childColumn="member" parentColumn="group" isRecursive="yes" >
	<InlineTable><Extension extender="MySystem">
		<row member="San Jose" group="CA"/>
		<row member="Gilroy" group="CA"/>
		<row member="Long Beach" group="CA"/>
		<row member="Oak Lawn" group="IL"/>
		<row member="Everett" group="MA"/>
		<row member="CA" group="USA"/>
		<row member="IL" group="USA"/>
		<row member="MA" group="USA"/>
	</Extension></InlineTable>
</ChildParent>

</Taxonomy>