> ＫＥＹ構成 「テーブル」に含まれる「キー」を管理するためのノード群です。 ■メインツリービュー上での操作 メインツリービュー上の「 KEY構成」のノードを選択すれば、コンテンツペインに定義済みの「KEY」が一覧されます。このノードの左側の"＋"をクリックすれば、定義済みの「ＫＥＹ（ ＸＸＸＸ）」が子ノードとして展開されます。それらのいずれかを選択すれば、コンテンツペインに定義内容が現れます。また、「 ＫＥＹ構成」のノード指定で右クリックすれば、ノードを追加したり（「下位要素を追加」）、コピーされた内容を貼り付けるためのポップアップメニューが現れ、「KEY（ ＸＸＸＸ）」のノード指定で右クリックすれば、この定義を削除したり、コピーするためのポップアップメニューが現れます。 ■コンテンツペイン上での操作 上述のように、「 KEY構成」のノードを選択すればコンテンツペインに定義済みKEYの一覧が表示されます。それらの行を右クリックすれば追加、削除、ジャンプ等のためのポップアップメニューが現れます。また、ツリービュー上の特定の「ＫＥＹ（ ＸＸＸＸ）」のノードを選択すれば、コンテンツペインに定義内容（名称等の入力項目や表示項目）等が示されます。以下でそれらの使い方を説明します。 ―「KEYタイプ」、「一覧順」の使い方 「KEYタイプ」は、KEY定義を新規追加するときだけに指定可能（*1）で、追加した後では変更できません。また、新規のテーブル定義が追加されると最初のKEY定義が「一次識別子(PK, Primary Key)」として自動追加され（*2）、これ以外に「一次識別子」を追加することはできません。「一覧順」は２つ目以降のKEY定義（つまり、一次識別子以外）においてのみ指定可能で、一覧のトップは常に（自動追加された）一次識別子となります。 *1.「二次識別子(Secondary Key, SK)」、「外部キー(Foreign Key, FK)」、「インデックスキー(Index Key, XK)」のいずれかを選択できます。インデックスキーでテーブル関連は構成できません。 *2.最初に自動追加される場合、KEYにはまだフィールドが含まれないので"*none"というＫＥＹ名称で示されます。KEY定義のノードを選んで現れる「フィールド構成」のパネルを用いてKEY定義の編集を行ってください（次項参照）。 ―「フィールド構成」の使い方 KEYのフィールド構成を変更するためのパネルです。メインツリービューの「フィールド（ ＸＸＸＸ）」のノードをこの一覧にドラッグ＆ドロップしてください（他のテーブルに含まれるフィールドをドラッグ＆ドロップすることはできません）。組み込み済みのフィールドをはずすためには、一覧上のそのフィールドを選んで右クリックして表示されるポップアップメニューを使ってください。ただし、後述する「テーブル関連」をすでにともなうKEY定義であれば、フィールド構成を変更することはできません（この場合には、テーブル関連を削除してからフィールド構成を変更するようにしてください）。なお、インデックスキー(XK)の場合は、フィールドを右クリックすれば昇順・降順を切り替えるためのコンテキストメニューが使えます。 ―「テーブル関連一覧」の使い方 「テーブル関連」は２つのKEY定義の組み合わせに対して定義されます。「テーブル関連一覧」は選択されたKEY定義について、既に定義されているテーブル関連が一覧されたものです。このパネルか上述の「KEYフィールド構成」のパネルに、メインツリービュー上の他の「KEY（ ＸＸＸＸ）」のノードをドラッグ＆ドロップすれば、新しいテーブル関連が作成されます。ただし、対応するキーフィールドのデータタイプが異なっている場合にはその旨を示す警告メッセージが表示されます。また、どのようなKEYの組み合わせも有効というわけではありません。キーのタイプの組み合わせ別に説明します。（ここはX-TEA Modelerでもっとも理解しにくい部分でしょう。言い換えれば、これさえ理解すれば他はどうということはありません。より深く理解するためにチュートリアルをお奨めします） ・PK/SKにPK/SKをドラッグ＆ドロップした場合 フィールド構成が完全に一致(*3)する場合には「派生関係」、一方のフィールド構成がもう一方のフィールド構成の一部である場合には前者を「親テーブル」、後者を「子テーブル」とした「親子関係」のテーブル関連が生成されます。これらの条件に一致しない場合には、有効な組み合わせとはみなされません。 *3.「フィールド構成が完全に一致する」とは、２つのＫＥＹ定義のフィールド構成の「数」と「データタイプ」が完全に一致することを意味します。フィールド名やフィールドの並び順は無視されることに注意してください。 なお、親子関係が成立した場合、「ツール」メニューの「CreateTable文生成」において、子テーブルの識別子にもとづく親テーブルへの参照制約(REFERENCESステートメント)」が生成されます。（したがって、親子関係を定義したなら、子から親への参照関係をあらためて定義する必要はありません） これに関連して、PK、SKのタイプのキーを定義する際、同一データタイプのフィールドを複数組み込むことはエラーではありませんが、なるべく避けてください（そのときには警告メッセージが表示されます）。なぜなら、「CreateTable文生成」において、そのキーにもとづく親テーブルへの参照制約(REFERENCESステートメント)が正しく設定されません。 たとえば、上図のテーブル１やテーブル３のPKを構成するフィールドｄ１、ｄ２、ｄ３が３つとも同一のデータタイプだったとします。その場合、テーブル１とテーブル３の親子関係において、子（テーブル３）のPKに含まれるはずの「親（テーブル１）のPKに対応する部分」がｄ１＋ｄ２なのか、ｄ２＋ｄ３なのか、ｄ１＋ｄ３なのかをModelerは判断できません（なぜならModelerはフィールドの名称ではなく、データタイプで対応を決定するからです）。結果的に、FOREIGN KEYステートメント中の項目名に、参照制約を決定できない旨を示す"(?)"がセットされた形でテーブル３のCreate文が示されます。 したがって、データタイプは、フィールド毎に指定するのがつらすぎない程度に少なく、識別子を構成するフィールドが同一のデータタイプを持たない程度に多く、という方針で定義される必要があります。 ・PK/SKにFKをドラッグ＆ドロップした場合（または、FKにPK/SKをドラッグ＆ドロップした場合） フィールド構成が完全に一致する場合には、PK/SK側を「参照先テーブル」、FK側を「参照元テーブル」とする「参照関係」のテーブル関連が生成されます。この条件に一致しない場合には、有効な組み合わせとはみなされません。 また、「テーブル関連一覧」には「存在条件」と呼ばれる入力項目が含まれています。これは「派生関係同士」と「参照元から参照先」に対してだけ指定可能な項目で、こちらのテーブルの１レコードに対して、相手のテーブルの対応レコードがどのような場合に存在するかを必要に応じて指定してください（この項目がブランクならば、相手テーブルの対応レコードが常に存在する、とみなされます）。多くの場合、相手レコードは常に存在しますが、場合によっては「FKのフィールドがブランクでない場合にのみ存在する」などといった条件が指定されることがあります。 なお、「CreateTable文生成」において、存在条件の指定された参照関係は、参照制約(REFERENCESステートメント)の生成対象から除外される点に注意してください。「相手テーブルに、対応するレコードが１件だけ必ず存在する」ようなテーブル関連のみが、CreateTableにおける参照制約の基礎になります。

> 「概要と目次」へ