テーブルでのフィールドの定義

フィールドは、テーブルに構造を提供するコンポーネントです。 フィールドのないテーブルを作成することはできません。 ただしフィールドが定義されていれば、行 (レコード) が存在しない、空のテーブルを作成することができます。

データベースでは、フィールドはテーブル間のリレーションシップの維持に使用されます。 これは、複数のテーブルの一致フィールドを作成することによって実現されます。 たとえば、toy_store という名前のテーブルと各店舗の従業員をトラックするための従業員テーブルがデータベースに格納されている場合には、2 つのテーブルに、店舗 ID などを設定する共通のフィールドを作成します。 特定の店舗の店舗 ID の値は、どちらのテーブルでも同じになります。

次の図は、toy_store テーブルに追加された STORE_ID フィールドを示しています。

店舗 ID 付きの toy_store テーブル
STORE_ID フィールド付きの toy_store テーブルが表示されます。

toy_store テーブルは、店舗 ID で従業員テーブルにリンクされています。 次のテーブルには、「The Play House」の 3 人の従業員が示されています。

従業員テーブル
従業員テーブルは、STORE_ID フィールドで toy_store テーブルにリンクされています。

テーブルとそれらの属性インデックスのリレーションシップを維持するために、特定のフィールドも使用されます。

テーブルのフィールドには、同じカテゴリのデータが同じデータ タイプで格納されます。 たとえば、顧客テーブルに CUSTOMER_NAME フィールドがある場合、このフィールドのエントリはすべて顧客名であり、テキストとして格納されます。 エントリを混在させることはできません。つまり、あるレコードでこのフィールドに顧客名を設定し、別のレコードで製品名を設定することはできません。

テーブルを作成する、または既存のテーブルにフィールドを追加する際には、各フィールドでのデータの格納に使用するデータ タイプを定義します。 場合によっては、フィールドの長さも指定します。

フィールド名

フィールド名は、テーブルの列に割り当てる名前です。 フィールド名は、各列に含まれるデータを示す必要があります。 たとえば、ArcGIS でフィーチャクラスを新規に作成すると、テーブルには ObjectID フィールドと Shape フィールドが設定されています。 ObjectID フィールドには、フィーチャクラス内の各オブジェクトの一意な ID 番号が含まれています。 Shape フィールドは、フィーチャクラスに格納されるシェープ タイプ (ポイント、ライン、ポリゴン、マルチポイント、またはマルチパッチ) を定義します。

また、列のタイプを示すために慣用句を使用することもできます。 たとえば、テーブルにインデックス付けに使用するための一意な ID を別に作成する場合は、一意なキーであることを示す UK を使用して、フィールドに ID_UK という名前を付けます。

同じテーブルに含まれるフィールドの名前は一意でなければなりません。たとえば、2 つのフィールドに ObjectID という名前を付けることはできません。 フィールド名は文字で始まらなければならず、スペースや予約語が含まれていてはなりません。 データベース固有の制限事項の詳細については、「ファイル ジオデータベースのサイズと名前の制限」、「モバイル ジオデータベースのサイズと名前の制限」、または「データベース データと ArcGIS」をご参照ください。

ArcGIS では、エンタープライズ ジオデータベース内に格納されるテーブルに対して、特定のフィールド名が完全修飾名で表示されます。 たとえば、Area という名前のフィールドを含むポリゴン フィーチャクラスを作成またはインポートすると、それにデータベース、スキーマ、テーブルの名前が追加されます。 これはフィーチャクラスの属性テーブルに表示される名前です。 つまり、archsites という名前のポリゴン フィーチャクラスが museum データベースの prof スキーマに格納されている場合、Area フィールドは MUSEUM.PROF.ARCHSITES.AREA と表示されます。

エンタープライズ ジオデータベースで完全修飾名となるフィールド名は、次のとおりです。

  • FID
  • AREA
  • LEN
  • POINTS
  • NUMOFPTS
  • ENTITY
  • EMINX
  • EMINY
  • EMAXX
  • EMAXY
  • EMINZ
  • EMAXZ
  • MIN_MEASURE
  • MAX_MEASURE

このような場合は、異なるフィールド名またはフィールド エイリアスの使用を検討する必要があります。

フィールド名の変更

フィールド ビューでテーブルまたはフィーチャクラス内のフィールドの名前を変更できます。

フィールドの名前を変更するには、[カタログ] ウィンドウで該当するフィーチャクラスまたはテーブルを右クリックした後、[データ設計] > [フィールド] の順にクリックします。 フィールド ビューが開き、フィールドのプロパティを変更できます。 変更するフィールド名のセルをダブルクリックして、新しいフィールド名を入力します。 変更をコミットするには、[フィールド] タブの [変更] グループで [保存] 保存 ボタンをクリックします。

次のフィールド名は変更できません。

  • ObjectID および GlobalID フィールド
  • シェープに関連するフィールド (Shape、shape length、shape area)
  • 有効になっている、ネットワーク フィーチャクラスの補助役割フィールドまたはネットワーク ウェイト フィールド
  • リプレゼンテーション フィールド
  • ネットワーク データセット、テレイン、またはパーセル ファブリックに関連しているフィーチャクラス内のフィールド
  • 編集情報の記録に使用されているフィールド
  • リレーションシップ クラスの主キーと外部キーのフィールド
  • サブタイプ フィールド
  • ラスター フィールド

フィールド名のルールと制限事項

次の表に、サポートされているフィールド名の文字ルールを示します。

文字名前の先頭その他の位置エイリアス

文字 (A から Z)

はいはいはい

アンダースコア ( _ )

はいはい

数字 (0–9)

はいはい

スペース

はい

シンボル (アンダースコア以外)

はい

上付き英数字

はい

下付き英数字

はい

その他のフィールド名のルールと制限事項は次のとおりです。

注意:

詳細については、「フィーチャクラスのプロパティの定義」のフィーチャクラス名とテーブル名のルールと制限事項をまとめた表をご参照ください。

フィールド エイリアス

フィールド エイリアスを使用して、フィールドに別の名前を割り当てることができます。 通常は、そのフィールドにどのようなデータが格納されるのかが伝わる範囲で、最も短いフィールド名を使用します。 フィールド名にスペースや特殊文字を使用することができないため、特定のフィールドはテーブルに完全修飾名で表示されます。 このような場合には、フィールド エイリアスを使用して、フィールドによりわかりやすい名前を付けることができます。 たとえば、道路の種類を格納する ST_SUFX という名前のフィールドがあり、道路の種類が道路名に使用されている接尾辞によって示される場合は、このフィールドに「Street name suffix」というエイリアスを割り当てることができます。

フィールド エイリアスを設定する方法の詳細

ヒント:
ジオプロセシング メソッドを使用すると、テーブル名とフィールド名を整合チェックできます。 詳細については、「Python でのテーブル名とフィールド名の検証」をご参照ください。

ドメインによるフィールド値の制御

属性ドメインとは、ジオデータベースのテーブルのフィールドについての有効な値を示すルールです。 属性ドメインは、ユーザーが特定のフィールドに追加できるデータ値を制限することにより、データの整合性を保証します。

属性ドメインをフィールドに適用できるのは、そのフィールドに設定できる値の集合または範囲を定義できる場合だけです。たとえば、「好きな食べ物は何ですか」というアンケート調査への回答を格納するフィールドは、 回答の数が多すぎるため、属性ドメインを適用するのは困難です。これに対し、瞳の色のデータを格納するフィールドは、有効な値が数種類に限られるため、属性ドメインを適用することが可能です。

  • ヘーゼル
  • 灰色
  • バイオレット

瞳の色を格納するフィールドに属性ドメインを使用すると、値の一貫性が保証されます。 アンケート担当者が瞳の色のテキスト フィールドに好きな色を入力できる場合は、担当者によっては青の瞳として次のような値が入力されてしまう可能性があります。

  • 濃紺
  • 空色
  • コバルト
  • アクアマリン

属性ドメインはスペルミスや入力ミスも防ぎます。 アンケート担当者が青の瞳に「blue」と入力しなければならないことを知っていたとしても、単語のスペルを誤ったり (bleu)、テキスト フィールドに「blue」と入力するつもりが別のキーを押したりすることもあります。

属性ドメインの種類

フィールド値の制約に使用できる属性ドメインとして、コード値ドメインと範囲ドメインの 2 種類があります。

コード値ドメイン

コード値ドメインは、コードを使用して、個別のデータを格納するフィールドに設定できる値を定義します。

コード値ドメインは任意のデータ タイプに使用することができます。 瞳の色のフィールドでは、次の例のコードセットを使用してコード値ドメインを作成することができます。

  • 例 1
    • Blk = Black
    • Brn = Brown
    • Blu = Blue
    • Grn = Green
    • Hzl = Hazel
    • Gra = Gray
    • Vlt = Violet
  • 例 2
    • 1 = Black
    • 2 = Brown
    • 3 = Blue
    • 4 = Green
    • 5 = Hazel
    • 6 = Gray
    • 7 = Violet

範囲ドメイン

範囲ドメインは、フィールドに設定可能な数値の範囲を定義します。

範囲ドメインを使用するフィールドのデータ タイプは数値または日付でなければなりません。 範囲ドメインを適用できるフィールドの例としては、動物園で誕生したニシローランドゴリラの赤ちゃんの体重を格納するフィールドが挙げられます。 この場合の範囲は、最低体重 (1kg) から最高体重 (2.5kg) までとなります。

属性ドメインの詳細

ドメインの作成方法と管理方法の詳細

サブタイプの使用

サブタイプは、ジオデータベースのフィーチャクラスまたはテーブル内での分類です。 これにより、データの一意な特性や振舞いに基づいて、フィーチャを論理的にグループ化することができます。 この特性や振舞いは、テーブルの 1 つのフィールドの値によって表されます。 たとえば、水文学のテーブルの場合は、河口、支流、水道 (澪)、運河、河川などの水路の種類に基づいて、サブタイプを定義することができます。 これらのサブタイプごとに、異なるトポロジ ルール、接続性ルール、デフォルト値、リレーションシップ ルールを適用することができます。

サブタイプを使用して関連するフィーチャのグループを格納すると、クエリのパフォーマンスを向上させることができます。 サブタイプを使用せずに、種類の異なるデータを別々のフィーチャクラスに格納すると、データベースのフィーチャクラスの数が増え、検索に時間がかかるようになります。

サブタイプの使用時は、次のルールが適用されます。

  • サブタイプを適用できるのは、テーブルまたはフィーチャクラスの 1 つのフィールドだけです。
  • サブタイプのベースとなるフィールドが long または short integer タイプのフィールドでなければなりません。
  • サブタイプごとに異なるトポロジ ルールおよびリレーションシップ ルールを適用することができます。
  • テーブルの他のフィールドに、サブタイプに基づいて異なる属性ドメインやコード値ドメインを適用できます。
    注意:

    ドメインは特定のサブタイプのフィールドに適用されます。

サブタイプの詳細

サブタイプを作成し管理する方法の詳細