テーブルでのフィールドの定義
フィールドは、テーブルに構造を提供するコンポーネントであるため、実際には、フィールドのないテーブルを作成することはできません。ただしフィールドが定義されていれば、行（レコード）が存在しない、空のテーブルを作成することができます。
データベースでは、フィールドはテーブル間のリレーションシップの維持にも使用されます。これは、複数のテーブルのフィールドを照合することによって実現されます。たとえば、toy_store という名前のテーブルと各店舗の従業員を管理するための employee テーブルがデータベースに格納されている場合には、2 つのテーブルに店舗 ID などを設定する共通のフィールドを作成します。特定の店舗の店舗 ID の値は、どちらのテーブルでも同じになります。
次の図は、toy_store テーブルに追加された店舗 ID フィールド（STORE_ID）を示しています。
 |
店舗 ID（STORE_ID）付きの店舗テーブル |
toy_store テーブルは、employee テーブルに店舗 ID でリンクされます。次のテーブルは、「The Play House」の 3 人の従業員を示しています。
 |
STORE_ID で店舗テーブルにリンクされた従業員テーブル |
テーブルとそれらの属性インデックスのリレーションシップを維持するために、特定のフィールドも使用されます。
テーブルのフィールドには、同じカテゴリのデータが同じデータ タイプで格納されます。たとえば、顧客テーブルに NAME という名前のフィールドがある場合、このフィールドのエントリはすべて顧客名であり、テキストとして格納されます。エントリを混在させることはできません。あるレコードでこのフィールドに顧客名を設定し、別のレコードで製品名を設定することはできません。
テーブルを作成する、または既存のテーブルにフィールドを追加する際には、各フィールドでのデータの格納に使用するデータ タイプを定義します。場合によっては、フィールドの長さも指定します。
フィールド名
フィールド名は、テーブルの列に割り当てる名前です。フィールド名は、その列に含まれるデータを示すものにする必要があります。たとえば、ArcCatalog でフィーチャクラスを新規作成する際、テーブルにはあらかじめ ObjectID フィールドと Shape フィールドが設定されています。ObjectID フィールドには、フィーチャクラス内の各オブジェクトの一意な ID 番号が含まれています。Shape フィールドは、フィーチャクラスに格納されるシェープ タイプ（ポイント、ライン、ポリゴン、マルチポイント、またはマルチパッチ）を定義します。
また、列のタイプを示すために慣用句を使用することもできます。たとえば、テーブルにインデックス付けに使用するための一意な ID を別に作成する場合は、UK が一意なキーであることを示すために、フィールドに ID_UK という名前を付けます。
同じテーブルに含まれるフィールドの名前は一意でなければなりません。たとえば、2 つの列に ObjectID という名前を付けることはできません。フィールド名は文字で始まらなければならず、スペースや予約語が含まれていてはなりません。フィールド名は最大 31 文字に制限されています（Oracle と DB2 のジオデータベースでは最大 30 文字、dBASE では最大 10 文字に制限されます）。
テーブル名のセクションで説明したように、ArcGIS では、ArcSDE ジオデータベース内に格納されているテーブルの特定のフィールド名が完全修飾名で表示されます。たとえば、Area という名前のフィールドが含まれたポリゴン フィーチャクラスを作成またはインポートする場合は、それにデータベース、スキーマ、テーブルの名前が追加されます。これはフィーチャクラスの属性テーブルに表示される名前です。つまり、archsites という名前のポリゴン フィーチャクラスが museum データベースの prof スキーマに格納されていた場合、Area フィールドは次のように表示されます。
MUSEUM.PROF.ARCHSITES.AREA
ArcSDE ジオデータベースで完全修飾名となるフィールド名は、次のとおりです。
FID、AREA、LEN、POINTS、NUMOFPTS、ENTITY、EMINX、EMINY、EMAXX、EMAXY、EMINZ、EMAXZ、MIN_MEASURE、MAX_MEASURE
このような場合は、異なるフィールド名またはフィールド エイリアスの使用を検討する必要があります。
フィールド エイリアス
フィールド エイリアスを使用して、フィールドに別の名前を割り当てることができます。通常は、そのフィールドにどのようなデータが格納されるのかが伝わる範囲で、最も短いフィールド名を使用します。また、先に示したように、フィールド名にスペースや特殊文字を使用することはできず、特定のフィールドはテーブルに完全修飾名で表示されます。このような場合には、フィールド エイリアスを使用して、フィールドによりわかりやすい名前を付けることができます。たとえば、道路の種類を格納する ST_SUFX という名前のフィールドがあり、道路の種類が道路名に使用されている接尾辞によって示される場合は、このフィールドに「Street name suffix」というエイリアスを割り当てることができます。
フィールド名自体は変更できないので、後で別の名前を表示したくなった場合は、エイリアスを使用してユーザに表示されるフィールド名を「変更」することができます。ST_SUFX という名前のフィールドを作成したものの、ST_SUFX と言う名称ではユーザに意味が伝わりにくいと考えている場合は、フィールド エイリアスを使用して、ユーザに ST_SUFX の代わりに「Street type」を表示することができます。
ヒント: ドメインによるフィールド値の制御
属性ドメインは、フィールドの有効な値を示すルールです。属性ドメインは、ユーザが特定のフィールドに追加できるデータ値を制限することにより、データの整合性を保証します。
属性ドメインをフィールドに適用するのは、そのフィールドに設定できる値の集合または範囲を定義できる場合だけです。たとえば、「好きな食べ物は何ですか」というアンケート調査への回答を格納するフィールドは、回答の数が多すぎるため、属性ドメインを適用するのは困難です。これに対し、瞳の色のデータを格納するフィールドは、有効な値が数種類に限られるため、属性ドメインを適用することが可能です。
- Black
- Brown
- Blue
- Green
- Hazel
- Gray
- Violet
瞳の色を格納するフィールドに属性ドメインを使用すると、値の一貫性が保証されます。アンケート担当者が瞳の色のテキスト フィールドに好きな色を入力できる場合は、担当者によっては「青」の瞳として次のような値が入力されてしまう可能性があります。
- Azure（青）
- Navy（濃紺）
- Sky blue（空色）
- Cobalt（コバルト）
- Aquamarine（アクアマリン）
属性ドメインはスペルミスや入力ミスも防ぎます。アンケート担当者が青の瞳に「blue」と入力しなければならないことを知っていたとしても、単語のスペルを誤ったり（bleu）、テキスト フィールドに「blue」と入力するつもりが別のキーを押すこともあります。
属性ドメインの種類
フィールド値の制約に使用できる属性ドメインは次の 2 種類です。
コード値ドメイン - コードを使用して、個別のデータを格納するフィールドに設定できる値を定義します。
コード値ドメインは任意のデータ タイプに使用することができます。瞳の色のフィールドでは、コード値ドメインを作成することができます。次に、データタイプによって作成可能なコード セットの例を 2 つ（テキストおよび数値型）示します。
Blk = Black
Brn = Brown
Blu = Blue
Grn = Green
Hzl = Hazel
Gra = Gray
Vlt = Violet
または
1 = Black
2 = Brown
3 = Blue
4 = Green
5 = Hazel
6 = Gray
7 = Violet
範囲ドメイン - フィールドに設定可能な数値の範囲を定義します。
範囲ドメインを使用するフィールドのデータ タイプは数値または日付でなければなりません。範囲ドメインを適用できるフィールドの例としては、動物園で誕生したニシローランドゴリラの赤ちゃんの体重を格納するフィールドが挙げられます。この場合の範囲は、最低体重（1kg）から最高体重（2.5kg）までとなります。
属性ドメインの詳細については、「属性ドメインの概要」をご参照ください。
属性ドメインの作成方法の詳細については、「属性範囲ドメインの新規作成」および「属性コード値ドメインの新規作成」をご参照ください。
サブタイプの使用
サブタイプは、フィーチャクラスまたはテーブル内での分類です。これにより、データの一意な特性や振舞いに基づいて、フィーチャを論理的にグループ化することができます。この特性や振舞いは、テーブルの 1 つのフィールドの値によって表されます。たとえば、水文学のテーブルの場合は、河口、支流、水道（澪）、運河、河川などの水路の種類に基づいて、サブタイプを定義することができます。これらのサブタイプごとに、異なるトポロジ ルール、接続性ルール、デフォルト値、リレーションシップ ルールを適用することができます。
サブタイプを使用して関連するフィーチャのグループを格納すると、クエリのパフォーマンスを向上させることができます。サブタイプを使用せずに、種類の異なるデータを別々のフィーチャクラスに格納すると、データベースのフィーチャクラスの数が増え、検索に時間がかかるようになります。
サブタイプに関するルールは次のとおりです。
- サブタイプを適用できるのは、テーブルまたはフィーチャクラスの 1 つのフィールドだけです。
- サブタイプを使用するには、サブタイプのベースとなるフィールドが long または short integer タイプのフィールドでなければなりません。
- サブタイプごとに異なるトポロジ ルールおよびリレーションシップ ルールを適用することができます。また、テーブルの他のフィールドに、サブタイプに基づいて異なる属性ドメインやコード値ドメインを適用することもできます。注意: ドメインは特定のサブタイプのフィールドに適用されます。
以下の手順に従ってサブタイプを適用します。
- サブタイプを適用するフィールドが long または short integer タイプであることを確認します。そうでない場合は、テーブルまたはフィーチャクラスに long または short integer タイプのフィールドを追加します。ほとんどの場合は、short integer で十分です。ただし、サブタイプの値が 32,767 を超える可能性がある場合は、long integer フィールドを使用します。
たとえば、河川のフィーチャクラスの場合は、Watershed という名前の short integer フィールドを追加して、河川が合流する分水界に基づいてサブタイプを作成することができます。
- テーブルまたはフィーチャクラスのテーブルの [プロパティ] ダイアログ ボックスを開き、[サブタイプ] タブの最初のドロップダウン リストからサブタイプ フィールドを選択します。
河川の例の場合は、[サブタイプ フィールド] リストから Watershed フィールドを選択します。
- 新しいサブタイプが Subtypes テーブルに自動的に追加されます。デフォルトのサブタイプは、コードが 0、説明が「New Subtype」に設定されています。これらのフィールドのいずれかをダブルクリックして、サブタイプ コードと適切な説明を入力することができます。
最初のコードを 1、説明を最初の分水界の名前に変更することができます。
- さらにサブタイプを追加するには、引き続き Subtypes テーブルにサブタイプのコードと説明を追加します。
コード 1 の下のフィールドにコード 2 を追加して、[説明] フィールドに該当する分水界の名前を入力し、その下のフィールドにコード 3 を追加して、再び該当する分水界の名前を入力するという要領で、河川フィーチャクラスで表されるすべての分水界のコードと説明を作成していきます。
- サブタイプごとに異なるデフォルト値やドメインを指定するには、[サブタイプ] リストでサブタイプをクリックします。[デフォルト値とドメイン] リストで、任意のフィールドのデフォルト値を入力することができます。また、リスト内のフィールドにコード値ドメインまたは属性ドメインを適用することもできます。そのためには、[ドメイン] フィールドをクリックして、ドロップダウン リストからドメインを選択します。まだドメインが存在しない場合は、新しいドメインを作成することができます。[プロパティ] ダイアログ ボックスの下部にある [ドメイン] ボタンをクリックして、[ワークスペース ドメイン] ダイアログ ボックスを開きます。
指定したデフォルト値とドメインは、[サブタイプ] リストから選択したサブタイプにのみ適用されます。[サブタイプ] リストから別のサブタイプを選択すると、（そのサブタイプのデフォルト値またはドメインを指定していない場合は）デフォルト値またはドメインが空になるか、選択したサブタイプの値が表示されます。