テーブルでのフィールドの定義
フィールドは、テーブルに構造を提供するコンポーネントです。 フィールドのないテーブルを作成することはできません。 ただしフィールドが定義されていれば、行 (レコード) が存在しない、空のテーブルを作成することができます。
データベースでは、フィールドはテーブル間のリレーションシップの維持に使用されます。 これは、複数のテーブルの一致フィールドを作成することによって実現されます。 たとえば、toy_store という名前のテーブルと各店舗の従業員をトラッキングするための従業員テーブルがデータベースに格納されている場合には、2 つのテーブルに、店舗 ID などを設定する共通のフィールドを作成します。 特定の店舗の店舗 ID の値は、どちらのテーブルでも同じになります。
次の図は、toy_store テーブルに追加された STORE_ID フィールドを示しています。
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 と表示されます。
エンタープライズ ジオデータベースで完全修飾名となるフィールド名は、次のとおりです。
FIDAREALENPOINTSNUMOFPTSENTITYEMINXEMINYEMAXXEMAXYEMINZEMAXZMIN_MEASUREMAX_MEASURE
このような場合は、異なるフィールド名またはフィールド エイリアスの使用を検討する必要があります。
フィールド名の長さ
ArcGIS Pro では、フィールド名の最大長は、ほとんどのジオデータベース形式で 128 文字です。 ただし、使用できる文字数は、基盤となる DBMS (データベース管理システム) が課す制限と、使用する文字エンコーディングに依存します。 フィールド名が切詰められるのを防ぐには、フィールド名の長さが次のテーブルの最大文字数と最大バイト数の制限内であることを確認します。
フィールド名の長さの制限は、文字数またはバイト数のいずれかに基づきます。
文字 - 入力する文字、数字、記号です。 たとえば、 "A"、 "1"、 "!" はすべて文字です。 文字を格納するのに必要なバイト数は、使用されるエンコーディングによって異なります。
バイト - 8 ビットで構成されるデジタル情報の単位です。 文字によって使用できるバイト数は異なります。 たとえば、文字 "A" が 1 バイトであった場合、 "é" のような発音区分符号を含む文字が 2 バイトになる可能性があります。
データベースやジオデータベースの種類によって、フィールド名の長さの制限が異なります。 たとえば、ファイル ジオデータベースやメモリー ワークスペースのデータを扱う場合、フィールドの最大長は 128 文字です。 モバイル ジオデータベースとエンタープライズ ジオデータベースでは、ArcGIS Pro は最大 128 文字または 256 バイトのどちらか、最初に達した制限を許容します。 PostgreSQL や Oracle のようなより厳しいバイト制限を持つデータベースでは、許容されるフィールド名が切詰められたり、短くなったりすることがあります。
注意:
このように、サポートされているフィールド名の長さが異なっているため、ジオデータベース間でデータをコピーするときにフィールド名が切詰められる場合があります。 これは、ArcGIS Pro のジオデータベース間で直接データを移動するワークフロー (テーブルとフィーチャクラスのエクスポートとインポートまたはコピーと貼り付けなど) のほか、ジオデータベース レプリケーション、データを ArcGIS Enterprise にコピーするフィーチャ レイヤーの公開、ArcGIS Enterprise での分散コラボレーションの使用に当てはまります。
文字エンコーディングは、各文字がバイト内でどのように表現されるかを決定します。 以下に一般的な文字エンコーディングを示します。
ASCII - 1 文字につき 1 バイトを使用し、主に英字、数字、句読点、制御文字を含む英文テキストに使用されます。
UTF-8 - 1 文字につき 1 ～ 4 バイトを使用します。 Web ページや電子メールに広く使用されており、ASCII との下位互換性を保ちながら、Unicode 標準のあらゆる文字を表現することができます。
UTF-16 - 1 文字あたり 2 バイトまたは 4 バイトを使用し、多くのオペレーティング システムや環境で一般的に使用されています。 ASCII 文字以外の文字を含むテキストでは、Unicode 文字をすべて効率的に表現することができます。
ISO-8859-1 - 1 文字につき 1 バイトを使用し、西ヨーロッパの言語に使用され、これらの言語で使用されるほとんどの文字をカバーしています。
次の表に、さまざまなジオデータベース タイプで ArcGIS がフィールド名の長さに対して作成できる最大文字数とバイト数の制限の概要を示します。
|
ジオデータベース タイプ |
フィールドの最大長 |
計測単位 |
文字数制限 |
|---|---|---|---|
|
ファイル ジオデータベースとメモリー ワークスペース |
128 文字 |
文字 |
各文字のバイト サイズに関係なく、128 文字。 |
|
モバイル ジオデータベースおよびエンタープライズ ジオデータベース |
128 文字、最大 256 バイト* |
Bytes |
文字エンコーディングによって異なる。 (例: 128 UTF-16 文字) |
* データベースで使用できる文字数が ArcGIS Pro より少ない場合は、データベースで使用できる文字数に制限されます。 データベース固有の制限事項の詳細については、「ファイル ジオデータベースのサイズと名前の制限」、「モバイル ジオデータベースのサイズと名前の制限」、または「ArcGIS のデータベースとクラウド データ ウェアハウスのデータ」をご参照ください。
フィールド名に複数のバイトを使用する文字を使用する場合、文字数の制限に達する前にバイト数の制限に達する可能性があります。 これらの概念を理解するために、次の例について考えてみましょう。
例 1: 100 文字のフィールド名で、1 文字が 3 バイト (UTF-8 エンコーディング) を使用する場合。
総バイト数 = 100 文字 * 3 バイト/文字 = 300 バイト
この場合、256 バイトの制限を超えるため、切詰められます。
例 2: 128 文字のフィールド名で、1 文字が 2 バイト (UTF-16 エンコーディング) を使用する場合。
総バイト数 = 128 文字 * 2 バイト/文字 = 256 バイト
この場合、256 バイトの制限を満たしており、許容されます。
ヒント:
DBMS のドキュメントを参照する - DBMS の特定のオブジェクト名の制限を常に確認します。
明確で簡潔な名称を使用する - 説明的でありながら、文字数とバイト数の制限内に収まるフィールド名を目指します。
フィールド エイリアスを使用する - ジオデータベースに登録されているテーブルでは、フィールド エイリアスを使用して、フィールドによりわかりやすい名前、または記号やスペースを使用した名前を付けることができます。
複数のデータベースでテストする - 複数のデータベースで作業する場合、フィールド名をテストし、各 DBMS の制限を満たしていることを確認します。
これらの制限と、異なるタイプのジオデータベースへの適用方法を理解することで、ArcGIS Pro でフィールド名を効果的に管理し、フィールド名の切詰めに関する問題を防ぐことができます。
フィールド名の変更
フィールド ビューでテーブルまたはフィーチャクラス内のフィールドの名前を変更できます。
フィールドの名前を変更するには、カタログ ウィンドウで該当するフィーチャクラスまたはテーブルを右クリックした後、データ設計 > フィールド の順にクリックします。 フィールド ビューが開き、フィールドのプロパティを変更できます。 変更するフィールド名のセルをダブルクリックして、新しいフィールド名を入力します。 変更をコミットするには、フィールド タブの 変更 グループで 保存 
ボタンをクリックします。
次のフィールド名は変更できません。
ObjectID および Global ID フィールド
シェープに関連するフィールド (Shape、shape length、shape area)
有効になっている、ネットワーク フィーチャクラスの補助役割フィールドまたはネットワーク ウェイト フィールド
リプレゼンテーション フィールド
ネットワーク データセット、テレイン、またはパーセル ファブリックに関連しているフィーチャクラス内のフィールド
編集情報の記録に使用されているフィールド
リレーションシップ クラスの主キーと外部キーのフィールド
サブタイプ フィールド
ラスター フィールド
フィールド名のルールと制限事項
次の表に、サポートされているフィールド名の文字ルールを示します。
|
文字 |
名前の先頭 |
その他の位置 |
エイリアス |
|---|---|---|---|
|
文字 (A から Z) |
|
|
|
|
アンダースコア ( _ ) |
|
|
|
|
数字 (0–9) |
|
|
|
|
空間 |
|
||
|
シンボル (アンダースコア以外) |
|
||
|
上付き英数字 |
|
||
|
下付き英数字 |
|
その他のフィールド名のルールと制限事項は次のとおりです。
フィールド名に予約語 (all、result など) を含めることはできません。
その他の予約語については、DBMS のドキュメントをご参照ください。
フィールド (列) 名の長さは基盤となるデータベースによって異なります。
データベース固有の制限事項の詳細については、「ファイル ジオデータベースのサイズと名前の制限」、「モバイル ジオデータベースのサイズと名前の制限」、または「ArcGIS のデータベースとクラウド データ ウェアハウスのデータ」をご参照ください。
注意:
詳細については、「フィーチャクラスのプロパティの定義」のフィーチャクラス名とテーブル名のルールと制限事項をまとめた表をご参照ください。
フィールド エイリアス
フィールド エイリアスを使用して、フィールドに別の名前を割り当てることができます。 通常は、そのフィールドにどのようなデータが格納されるのかが伝わる範囲で、最も短いフィールド名を使用します。 フィールド名にスペースや特殊文字を使用することができないため、特定のフィールドはテーブルに完全修飾名で表示されます。 このような場合には、フィールド エイリアスを使用して、フィールドによりわかりやすい名前を付けることができます。 たとえば、道路の種類を格納する ST_SUFX という名前のフィールドがあり、道路の種類が道路名に使用されている接尾辞によって示される場合は、このフィールドに「Street name suffix」というエイリアスを割り当てることができます。
ヒント:
ジオプロセシング メソッドを使用すると、テーブル名とフィールド名を検証できます。 詳細については、「Python でのテーブル名とフィールド名の検証」をご参照ください。
ドメインによるフィールド値の制御
属性ドメインとは、ジオデータベースのテーブルのフィールドについての有効な値を示すルールです。 属性ドメインは、ユーザーが特定のフィールドに追加できるデータ値を制限することにより、データの整合性を保証します。
そのフィールドに設定できる特定の値の集合または範囲を定義できる場合にのみ、属性ドメインをフィールドに適用できます。 たとえば、「あなたの好きな食べ物は何ですか？」というアンケートの質問の答えを保存するフィールドでは、多くの回答が考えられるため、ドメインを適用するのは困難です。 一方、目の色に関するデータを格納するフィールドなら、考えうる有効な値が限られているため、属性ドメインを割り当てることができます。
黒
茶
青
緑
ヘーゼル
灰色
バイオレット
瞳の色のデータを格納するフィールドに属性ドメインを使用すると、値の一貫性が保証されます。 データ収集者が瞳の色のテキスト フィールドに好きな色を入力できると、次のような値が入力されてしまう可能性があります。
Azure
濃紺
空色
コバルト
アクアマリン
属性ドメインはスペルミスや入力ミスも防ぎます。 データ収集者が青色の瞳について「blue」と入力しなければならないと知っていたとしても、テキスト フィールドに入力するとき単語のスペルを誤ったり (bleu)、間違った文字を入力したりしてしまう (vlue) こともあります。
属性ドメインの種類
フィールド値の制約に使用できる属性ドメインとして、コード値ドメインと範囲ドメインの 2 種類があります。
コード値ドメイン
コード値ドメインは、コードを使用して、個別のデータを格納するフィールドに設定できる値を定義します。 コード値ドメインは、ほとんどのフィールド データ タイプに使用できます。
注意:
Date、Date only、Time only のフィールド タイプのドメインは、秒単位の精度のみをサポートします。
Global ID、Object ID、Blob、Raste、Timestamp offset のフィールドのドメインでは、コード値と範囲はサポートされません。
瞳の色のフィールドでは、次の例のコードセットを使用してコード値ドメインを作成することができます。
例 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
範囲ドメイン
範囲ドメインは、フィールドに設定可能な数値の範囲を定義します。
範囲ドメインを使用するフィールドのデータ タイプは数値または日付でなければなりません。 範囲ドメインは、short integer、long integer、big integer、float、double、date、date only、time only のフィールド タイプに適用できます。 範囲ドメインを適用できるフィールドの例としては、動物園で誕生したニシローランドゴリラの赤ちゃんの体重を格納するフィールドが挙げられます。 この場合の範囲は、最低体重 (1kg) から最高体重 (2.5kg) までとなります。
サブタイプの使用
サブタイプは、ジオデータベースのフィーチャクラスまたはテーブル内での分類です。 これにより、データの一意な特性や振舞いに基づいて、フィーチャを論理的にグループ化することができます。 この特性や振舞いは、テーブルの 1 つのフィールドの値によって表されます。 たとえば、水文学のテーブルの場合は、河口、支流、水道 (澪)、運河、河川などの水路の種類に基づいて、サブタイプを定義することができます。 これらのサブタイプごとに、異なるトポロジー ルール、接続性ルール、デフォルト値、リレーションシップ ルールを適用することができます。
サブタイプを使用して関連するフィーチャのグループを格納すると、クエリのパフォーマンスを向上させることができます。 サブタイプを使用せずに、種類の異なるデータを別々のフィーチャクラスに格納すると、データベースのフィーチャクラスの数が増え、検索に時間がかかるようになります。
サブタイプの使用時は、次のルールが適用されます。
サブタイプを適用できるのは、テーブルまたはフィーチャクラスの 1 つのフィールドだけです。
サブタイプのベースとなるフィールドが long または short integer タイプのフィールドでなければなりません。
サブタイプごとに異なるトポロジー ルールおよびリレーションシップ ルールを適用することができます。
テーブルの他のフィールドに、サブタイプに基づいて異なる属性ドメインやコード値ドメインを適用できます。
注意:
ドメインは特定のサブタイプのフィールドに適用されます。