Amazon Redshift は、パッチ 198 以降、新しい Python UDF の作成をサポートしなくなります。既存の Python UDF は、2026 年 6 月 30 日まで引き続き機能します。詳細については、[ブログ記事](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)を参照してください。 # CREATE TABLE 現在のデータベースに新しいテーブルを作成します。各列が異なる型のデータを保持する列のリストを定義します。テーブルの所有者は CREATE TABLE コマンドの発行者です。 ## 必要な権限 以下に、CREATE TABLE に必要な権限を示します。 + スーパーユーザー + CREATE TABLE の権限を持つユーザー ## 構文 ``` CREATE [ [LOCAL ] { TEMPORARY | TEMP } ] TABLE [ IF NOT EXISTS ] table_name ( { column_name data_type [column_attributes] [ column_constraints ] | table_constraints | LIKE parent_table [ { INCLUDING | EXCLUDING } DEFAULTS ] } [, ... ] ) [ BACKUP { YES | NO } ] [table_attributes] where column_attributes are: [ DEFAULT default_expr ] [ IDENTITY ( seed, step ) ] [ GENERATED BY DEFAULT AS IDENTITY ( seed, step ) ] [ ENCODE encoding ] [ DISTKEY ] [ SORTKEY ] [ COLLATE { CASE_SENSITIVE | CS | CASE_INSENSITIVE | CI } ] and column_constraints are: [ { NOT NULL | NULL } ] [ { UNIQUE | PRIMARY KEY } ] [ REFERENCES reftable [ ( refcolumn ) ] ] and table_constraints are: [ UNIQUE ( column_name [, ... ] ) ] [ PRIMARY KEY ( column_name [, ... ] ) ] [ FOREIGN KEY (column_name [, ... ] ) REFERENCES reftable [ ( refcolumn ) ] and table_attributes are: [ DISTSTYLE { AUTO | EVEN | KEY | ALL } ] [ DISTKEY ( column_name ) ] [ [COMPOUND | INTERLEAVED ] SORTKEY ( column_name [,...]) | [ SORTKEY AUTO ] ] [ ENCODE AUTO ] ``` ## パラメータ LOCAL 省略可能。このキーワードは、ステートメントに指定できますが、Amazon Redshift では効果がありません。 TEMPORARY \| TEMP 現在のセッション内でのみ表示可能な一時テーブルを作成するキーワード。このテーブルは、作成したセッションの終了時に自動的に削除されます。一時テーブルには永続テーブルと同じ名前を付けることができます。一時テーブルは、別のセッション固有のスキーマ内に作成されます (このスキーマの名前を指定することはできません)。この一時スキーマは検索パスの最初のスキーマになるため、永続テーブルにアクセスするようにスキーマ名でテーブル名を修飾しない限り、一時テーブルは永続テーブルよりも優先されます。スキーマと優先順位の詳細については、「[search\_path](r_search_path.md)」を参照してください。 デフォルトでは、データベースユーザーは、PUBLIC グループの自動メンバーシップにより、一時テーブルを作成するアクセス許可を持ちます。あるユーザーにこの権限が付与されないようにするには、PUBLIC グループから TEMP 権限を取り消して、特定のユーザーまたはユーザーグループにのみ TEMP 権限を明示的に付与します。 IF NOT EXISTS 指定されたテーブルが既に存在する場合、コマンドはエラーで終了するのではなく、何も変更せずに、テーブルが存在するというメッセージを返すことを示す句。既存のテーブルの内容が、作成予定のテーブルとはまったく異なる可能性があることに注意してください。比較されるのはテーブル名のみです。 この句は、CREATE TABLE で既存のテーブルを作成しようとしてもスクリプトが失敗しないため、スクリプトを作成する際に便利です。 *table\_name* 作成するテーブルの名前。 「\#」で始まるテーブル名を指定すると、そのテーブルは一時テーブルとして作成されます。次に例を示します。 ``` create table #newtable (id int); ``` また、「\#」を使用してテーブルを参照します。例えば、次のようになります。 ``` select * from #newtable; ``` テーブル名の最大長は 127 バイトです。それより長い名前は 127 バイトまで切り詰められます。最大 4 バイトまで UTF-8 マルチバイト文字を使用できます。Amazon Redshift は、ユーザー定義の一時テーブルや、クエリ処理またはシステムメンテナンス中に Amazon Redshift によって作成された一時テーブルを含む、各ノードタイプのクラスターあたりのテーブル数のクォータを適用します。オプションで、テーブル名は、データベース名およびスキーマ名で修飾することができます。次の例では、データベース名は `tickit`、スキーマ名は `public`、テーブル名は `test` です。 ``` create table tickit.public.test (c1 int); ``` データベースまたはスキーマが存在し、テーブルが作成されていない場合、このステートメントはエラーを返します。システムデータベース `template0`、`template1`、`padb_harvest`、または `sys:internal` にテーブルまたはビューを作成することはできません。 スキーマ名を指定すると、新しいテーブルはそのスキーマ内に作成されます (作成者がスキーマにアクセス権を持っている場合)。テーブル名は、そのスキーマで一意の名前にする必要があります。スキーマを指定しない場合、現在のデータベーススキーマを使用してテーブルが作成されます。一時テーブルを作成する場合、一時テーブルは特殊なスキーマに作成されるので、スキーマ名を指定することはできません。 同じ名前の一時テーブルでも、別のセッションで作成される場合は同じデータベース内に同時に存在することができます。これは、テーブルに割り当てられるスキーマが異なるためです。有効な名前の詳細については、「[名前と識別子](r_names.md)」を参照してください。 *column\_name* 新しいテーブルで作成される列の名前。列名の最大長は 127 バイトです。それより長い名前は 127 バイトまで切り詰められます。最大 4 バイトまで UTF-8 マルチバイト文字を使用できます。1 つのテーブルで定義できる列の最大数は 1,600 です。有効な名前の詳細については、「[名前と識別子](r_names.md)」を参照してください。 「横長のテーブル」を作成する場合は、ロードとクエリ処理の結果が即時に表示されるように、列リストが行幅の限度を超えないように注意します。詳細については、「[使用に関する注意事項](#r_CREATE_TABLE_usage)」を参照してください。 *data\_type* 作成する列のデータ型。CHAR および VARCHAR の列の場合、最大長を宣言する代わりに MAX キーワードを使用できます。MAX は、最大長を CHAR では 4096 バイト、VARCHAR では 65535 バイトに設定します。GEOMETRY オブジェクトの最大サイズは 1,048,447 バイトです。 Amazon Redshift でサポートされているデータ型の詳細については、「[データ型](c_Supported_data_types.md)」を参照してください。 DEFAULT *default\_expr* 列のデフォルトのデータ値を割り当てる句。*default\_expr* のデータ型は列のデータ型に一致する必要があります。DEFAULT 値は、変数を使用しない式にする必要があります。サブクエリ、現在のテーブルに含まれる他の列の相互参照、およびユーザー定義の関数は使用できません。 *default\_expr* 式は、列の値を指定しないすべての INSERT 操作で使用されます。デフォルト値を指定しなかった場合、列のデフォルト値は null です。 定義済み列リストの COPY 操作で、DEFAULT 値が含まれている列を省略すると、COPY コマンドで *default\_expr* の値が挿入されます。 IDENTITY(*seed*, *step*) 列が IDENTITY 列であることを指定する句。IDENTITY 列には、一意の自動生成値が含まれます。IDENTITY 列のデータ型は、INT または BIGINT にする必要があります。 `INSERT` または `INSERT INTO [tablename] VALUES()` ステートメントを使用して行を追加する場合、これらの値は、*seed* として指定された値で始まり、*step* として指定された数が増分されます。 `INSERT INTO [tablename] SELECT * FROM` または `COPY` ステートメントを使用してテーブルをロードすると、データはパラレルにロードされ、ノードスライスに分散されます。ID 値が一意であることを確認するために、Amazon Redshift は ID 値を作成するときにいくつかの値をスキップします。ID 値は一意ですが、順序はソースファイルの順序と一致しない場合があります。 GENERATED BY DEFAULT AS IDENTITY (*seed*、*step*) 列がデフォルトの IDENTITY 列であることを指定し、一意の値を列に自動的に割り当てることができるようにする句。IDENTITY 列のデータ型は、INT または BIGINT にする必要があります。値のない行を追加する場合、これらの値は、*seed* として指定された値で始まり、*step* として指定された数が増分されます。値の生成方法については、「[IDENTITY](#identity-clause)」を参照してください。 また、INSERT、UPDATE、または COPY の間に、EXPLICIT\_IDS なしで値を指定できます。Amazon Redshift は、システムで生成された値を使用する代わりに、その値を使用して ID 列に挿入します。値は、重複、seed より小さい値、または step 値間の値にすることができます。Amazon Redshift は、列値の一意性を確認しません。値を指定しても、システムが生成する次の値には影響しません。 列に一意性が必要な場合は、重複する値を追加しないでください。代わりに、seed より小さい値または step 値の間にある一意の値を追加します。 デフォルトの identity 列については、次のことに注意してください。 + デフォルトの identity 列は NOT NULL です。NULL は挿入できません。 + 生成された値をデフォルトの identity 列に挿入するには、キーワード `DEFAULT` を使用します。 ``` INSERT INTO {{tablename}} ({{identity-column-name}}) VALUES (DEFAULT); ``` + デフォルトの identity 列の値をオーバーライドしても、次に生成される値には影響しません。 + ALTER TABLE ADD COLUMN ステートメントでデフォルトの identity 列を追加することはできません。 + ALTER TABLE APPEND ステートメントを使用して、デフォルトの IDENTITY 列を追加できます。 ENCODE *encoding* 列の圧縮エンコード。ENCODE AUTO は、テーブルのデフォルトです。Amazon Redshift は、テーブル内のすべての列の圧縮エンコードを自動的に管理します。テーブル内のいずれかの列に圧縮エンコードを指定すると、テーブルは ENCODE AUTO に設定されなくなります。Amazon Redshift は、テーブルにあるすべての列の圧縮エンコードを自動的に管理しないようになりました。テーブルに ENCODE AUTO オプションを指定して、Amazon Redshift がテーブルにあるすべての列の圧縮エンコードを自動的に管理できるようになります。 Amazon Redshift は、圧縮エンコードを指定していない列に、次のように初期圧縮エンコードを自動的に割り当てます。 + 一時テーブルのすべての列には RAW 圧縮がデフォルトで割り当てられます。 + ソートキーとして定義されている列には、RAW 圧縮が割り当てられます。 + BOOLEAN、REAL、DOUBLE PRECISION、GEOMETRY、もしくは GEOGRAPHY の各データ型で定義されている列には、RAW 圧縮が割り当てられます。 + SMALLINT、INTEGER、BIGINT、DECIMAL、DATE、TIME、TIMETZ、TIMESTAMP、または TIMESTAMPTZ として定義された列には AZ64 圧縮が割り当てられます。 + CHAR、VARCHAR、または VARBYTE として定義されている列には、LZO 圧縮が割り当てられます。 列を圧縮しない場合は、明示的に RAW エンコードを指定します。 次の [compression encodings](c_Compression_encodings.md#compression-encoding-list) がサポートされています。 + AZ64 + BYTEDICT + DELTA + DELTA32K + LZO + MOSTLY8 + MOSTLY16 + MOSTLY32 + RAW (非圧縮) + RUNLENGTH + TEXT255 + TEXT32K + ZSTD DISTKEY 列がテーブルの分散キーであることを指定するキーワード。テーブル内の 1 つの列のみを分散キーに指定できます。DISTKEY キーワードは列名の後に使用するか、DISTKEY (*column\_name*) 構文を使用してテーブル定義の一部として使用できます。どちらの方法でも同じ結果が得られます。詳細については、このトピックで後述する DISTSTYLE パラメータを参照してください。 ディストリビューションキー列のデータ型には、BOOLEAN、REAL、DOUBLE PRECISION、SMALLINT、INTEGER、BIGINT、DECIMAL、DATE、TIME、TIMETZ、TIMESTAMP、または TIMESTAMPTZ、CHAR、または VARCHAR のいずれかを使用できます。 SORTKEY 列がテーブルのソートキーであることを指定するキーワード。データをテーブルにロードすると、データはソートキーとして指定された 1 つまたは複数の列に従ってソートされます。列名の後に SORTKEY キーワードを使用して 1 列のソートキーを指定することができます。または、SORTKEY (*column\_name* [, ...]) 構文を使用して、テーブルのソートキーとして 1 つまたは数の列を指定することができます。この構文では複合ソートキーのみが作成されます。 1 つのテーブルで、最大 400 の SORTKEY 列を定義できます。 ソートキー列のデータ型には、BOOLEAN、REAL、DOUBLE PRECISION、SMALLINT、INTEGER、BIGINT、DECIMAL、DATE、TIME、TIMETZ、TIMESTAMP、または TIMESTAMPTZ、CHAR、または VARCHAR のいずれかを使用できます。 COLLATE { CASE\_SENSITIVE \| CS \| CASE\_INSENSITIVE \| CI } 列での文字列の検索または比較において、大文字と小文字を区別するか、区別しないかを指定する句。デフォルト値は、大文字と小文字を区別する、現行のデータベースの設定と同じです。 COLLATE は、SUPER 列内の CHAR、VARCHAR、文字列値など、文字列ベースのデータ型でのみサポートされています。SUPER データの大文字と小文字を区別しないクエリの詳細については、「[大文字と小文字を区別しないクエリ](query-super.md#case-insensitive-super-queries)」を参照してください。 データベース照合に関する情報を検索するには、次のコマンドを使用します。 ``` SELECT db_collation(); db_collation ---------------- case_sensitive (1 row) ``` CASE\_SENSITIVE と CS は互換性があり、同じ結果が得られます。同様に、CASE\_INSENSITIVE と CI は互換性があり、同じ結果が得られます。 NOT NULL \| NULL NOT NULL は、列に null 値を使用できないことを指定します。NULL はデフォルトであり、列で null 値を使用できることを指定します。IDENTITY 列はデフォルトで NOT NULL として宣言されます。 UNIQUE 列に一意の値のみを含めることができることを指定するキーワード。一意のテーブル制約の動作は、列制約の動作と同じですが、さらに複数の列に適用される点が異なります。一意のテーブル制約を定義するには、UNIQUE ( *column\_name* [, ... ] ) 構文を使用します。 一意の制約は情報提供に使用され、システムで強制されることはありません。 PRIMARY KEY 列がテーブルのプライマリキーであることを指定するキーワード。列定義を使用してプライマリキーとして定義できるのは 1 列だけです。複数列のプライマリキーを使用してテーブル制約を定義するには、PRIMARY KEY ( *column\_name* [, ... ] ) 構文を使用します。 列をプライマリキーに指定すると、スキーマの設計に関するメタデータが提供されます。プライマリキーは、他のテーブルが、行の一意の識別子としてこの列セットに依存している可能性があることを示します。列制約かテーブル制約かにかかわらず、テーブルに指定できるプライマリキーは 1 つです。プライマリキーの制約は、同じテーブルに定義されている一意の制約で指定された列セットとは異なる列セットを指定する必要があります。 PRIMARY KEY 列は NOT NULL としても定義されます。 プライマリキーの制約は情報提供にのみ使用されます。プライマリキーの制約がシステムに強制されることはありませんが、プランナーによって使用されます。 References *reftable* [ ( *refcolumn* ) ] 参照テーブルの行の参照列に含まれている値と一致する値を列に格納する必要があることを意味する、外部キー制約を指定する句。参照列は、参照テーブルの一意の制約またはプライマリキーの制約の列にする必要があります。 外部キーの制約は情報提供にのみ使用されます。プライマリキーの制約がシステムに強制されることはありませんが、プランナーによって使用されます。 LIKE *parent\_table* [ { INCLUDING \| EXCLUDING } DEFAULTS ] 新しいテーブルで、列名、データ型、NOT NULL 制約を自動的にコピーする既存のテーブルを指定する句。新しいテーブルと親テーブル間に関連付けはなく、親テーブルを変更しても、新しいテーブルに変更は適用されません。コピーした列定義のデフォルトの式は、INCLUDING DEFAULTS を指定した場合にのみコピーされます。デフォルトの動作では、デフォルトの式が除外されるため、新しいテーブルのすべての列は NULL のデフォルト値になります。 LIKE オプションを指定して作成したテーブルは、プライマリキーと外部キーの制約を継承しません。分散スタイル、ソートキー、BACKUP、NULL のプロパティは LIKE テーブルで継承されますが、CREATE TABLE ..。LIKE ステートメントで明示的に設定することはできません。 BACKUP { YES \| NO } テーブルを自動および手動クラスター スナップショットに含めるかどうかを指定する句。 重要なデータを含まないステージングテーブルなどのテーブルについては、スナップショットの作成やスナップショットからの復元にかかる時間を節約し、Amazon Simple Storage Service のストレージスペースを節約するため、BACKUP NO を指定します。BACKUP NO の設定は、クラスター内の別ノードへのデータの自動レプリケーションには影響しません。そのため、BACKUP NO が指定されたテーブルはノードの障害時に回復されます。デフォルトは BACKUP YES です。 RA3 でプロビジョニングされたクラスターと Amazon Redshift Serverless ワークグループでは、バックアップ用ではないテーブルはサポートされていません。RA3 クラスターおよびサーバーレスワークグループでバックアップしないとマークされたテーブルは、スナップショットの作成中に常にバックアップされ、スナップショットから復元するときに復元される永続テーブルとして扱われます。バックアップ用ではないテーブルのスナップショットコストを回避するには、スナップショットを作成する前にそれらを切り捨てます。 DISTSTYLE { AUTO \| EVEN \| KEY \| ALL } テーブル全体のデータディストリビューションスタイルを定義するキーワード。Amazon Redshift は、テーブルに指定されたディストリビューションスタイルに従って、テーブルの行をコンピューティングノードに分散します。デフォルトは AUTO です。 テーブルにどの分散スタイルを選択するかによって、データベースの全体的なパフォーマンスが左右されます。詳細については、「[クエリ最適化のためのデータのディストリビューション](t_Distributing_data.md)」を参照してください。可能な分散スタイルは次のとおりです。 + AUTO: Amazon Redshift がテーブルデータに基づいて最適な分散スタイルを割り当てます。例えば、AUTO 分散スタイルが指定された場合、Amazon Redshift ではまず、ALL 分散スタイルを小さなテーブルに割り当てます。テーブルが大きくなると、Amazon Redshift は分散スタイルを KEY に変更し、プライマリキー (または複合プライマリキーの列) を DISTKEY として選択する場合があります。テーブルが大きくなり、DISTKEY に適した列がない場合、Amazon Redshift は分散スタイルを EVEN に変更します。ディストリビューションスタイルの変更は、ユーザークエリへの影響を最小限に抑え、バックグラウンドで発生します。 テーブルに適用された分散スタイルを表示するには、PG\_CLASS システムカタログテーブルに対してクエリを実行します。詳細については、「[分散スタイルの表示](viewing-distribution-styles.md)」を参照してください。 + EVEN: テーブルのデータは、ラウンドロビン分散方式で、クラスター内のノード全体に均等に分散されます。行 ID は分散を決定するために使用され、およそ同じ行数が各ノードに分散されます。 + KEY: データは、DISTKEY 列の値で分散されます。結合するテーブルの結合列を分散キーとして設定すると、両方のテーブルの結合列がコンピューティングノードによりコロケーションされます。データがコロケーションされることで、オプティマイザーはより効率的に結合を実行できます。DISTSTYLE KEY を指定する場合は、テーブルに対して、または列定義の一部として、DISTKEY 列に名前を付ける必要があります。詳細については、このトピックで先述した DISTKEY パラメータを参照してください。 + ALL: テーブル全体のコピーがすべてのノードに分散されます。この分散方式により、結合に必要なすべての列が確実にすべてのノードで使用可能になりますが、ストレージ要件が倍増し、テーブルに関する負荷とメンテナンス時間が増大します。ALL 分散を指定する場合、KEY 分散が適さない特定のディメンションテーブルで使用する場合には実行時間が改善される可能性がありますが、パフォーマンスの改善とメンテナンスコストを比較検討する必要があります。 DISTKEY ( *column\_name* ) テーブルの分散キーとして使用する列を指定する制約。DISTKEY キーワードは列名の後に使用するか、DISTKEY (*column\_name*) 構文を使用してテーブル定義の一部として使用できます。どちらの方法でも同じ結果が得られます。詳細については、このトピックで先述した DISTSTYLE パラメータを参照してください。 [COMPOUND \| INTERLEAVED ] SORTKEY (* column\_name* [,...]) \| [ SORTKEY AUTO ] テーブルに対して 1 つ以上のソートキーを指定します。データをテーブルにロードすると、データはソートキーとして指定された列に従ってソートされます。列名の後に SORTKEY キーワードを使用して 1 列のソートキーを指定することができます。または、`SORTKEY (column_name [ , ... ] )`構文を使用して、テーブルのソートキーとして 1 つまたは数の列を指定することができます。 オプションでソート方式として COMPOUND または INTERLEAVED を指定できます。列とともに SORTKEY を指定した場合、デフォルトは COMPOUND です。詳細については、「[ソートキー](t_Sorting_data.md)」を参照してください。 ソートキーオプションを指定しない場合、デフォルトは AUTO です。 1 つのテーブルで最大 400 の COMPOUND SORTKEY 列または 8 の INTERLEAVED SORTKEY 列を定義できます。 AUTO Amazon Redshift がテーブルデータに基づいて最適なソートキーを割り当てることを指定します。例えば、AUTO ソートキーが指定されている場合、Amazon Redshift は最初にテーブルにソートキーを割り当てません。ソートキーによってクエリのパフォーマンスが向上すると Amazon Redshift が判断した場合、Amazon Redshift はテーブルのソートキーを変更する可能性があります。テーブルの実際のソートは、自動テーブルソートによって行われます。詳細については、「[自動テーブルソート](t_Reclaiming_storage_space202.md#automatic-table-sort)」を参照してください。 Amazon Redshift は、既存のソートキーまたはディストリビューションキーを持つテーブルを変更しません。1 つの例外を除き、テーブルに JOIN で使用されたことがないディストリビューションキーがある場合、Amazon Redshift がより適切なキーがあると判断すると、キーが変更される可能性があります。 テーブルのソートキーを表示するには、SVV\_TABLE\_INFO システムカタログビューに対してクエリを実行します。詳細については、「[SVV\_TABLE\_INFO](r_SVV_TABLE_INFO.md)」を参照してください。テーブルの Amazon Redshift Advisor のレコメンデーションを表示するには、SVV\_ALTER\_TABLE\_RECOMMENDATIONS システムカタログビューをクエリします。詳細については、「[SVV\_ALTER\_TABLE\_RECOMMENDATIONS](r_SVV_ALTER_TABLE_RECOMMENDATIONS.md)」を参照してください。Amazon Redshift が実行したアクションを表示するには、SVL\_AUTO\_WORKER\_ACTION システムカタログビューにクエリを実行します。詳細については、「[SVL\_AUTO\_WORKER\_ACTION](r_SVL_AUTO_WORKER_ACTION.md)」を参照してください。 COMPOUND リストされているすべての列から成る複合キーを使用して、データがリスト順にソートされるように指定します。複合ソートキーは、クエリがソート列の順序に従って行をスキャンする場合に最も便利です。複合キーを使用したソートのパフォーマンス上のメリットは、クエリがセカンダリソート列に依存する状況が減少する点にあります。1 つのテーブルで、最大 400 の COMPOUND SORTKEY 列を定義できます。 INTERLEAVED インターリーブソートキーを使用してデータがソートされるように指定します。インターリーブソートキーには、最大 8 つの列を指定できます。 インターリーブソートは、ソートキーの各列または列のサブセットに等しい重みを割り当てるため、クエリはソートキーの列の順序に依存しません。クエリが 1 つ以上のセカンダリソート列を使用すると、インターリーブソートによってクエリのパフォーマンスは大幅に向上します。インターリーブソートでは、データのロード操作とバキューム操作にわずかなオーバーヘッドコストがかかります。 ID 列、日付、タイムスタンプなど、一定間隔で増加する属性を持つ列で、インターリーブソートキーを使用しないでください。 ENCODE AUTO Amazon Redshift がテーブル内のすべての列のエンコードタイプを自動的に調整して、クエリのパフォーマンスを最適化できるようにします。ENCODE AUTO は、テーブルの作成時に指定した初期エンコードタイプを保持します。その後、Amazon Redshift が新しいエンコードタイプによってクエリのパフォーマンスが向上すると判断した場合、Amazon Redshift はテーブル列のエンコードタイプを変更できます。テーブルのどの列にもエンコード型を指定しない場合、デフォルトは ENCODE AUTO です。 UNIQUE ( *column\_name* [,...] ) テーブルの 1 つまたは複数の列のグループに、一意の値のみを含めることができることを指定する制約。一意のテーブル制約の動作は、列制約の動作と同じですが、さらに複数の列に適用される点が異なります。一意の制約がある場合、NULL 値は等値と見なされません。各一意のテーブル制約は、テーブルに定義されている他の一意のキーまたはプライマリキーで指定された列セットとは異なる列セットを指定する必要があります。 一意の制約は情報提供に使用され、システムで強制されることはありません。 PRIMARY KEY ( *column\_name* [,...] ) テーブルの 1 つまたは複数の列のグループに、一意の (重複しない) NULL 以外の値のみを含めることができることを指定する制約。列セットをプライマリキーに指定すると、スキーマの設計に関するメタデータも提供されます。プライマリキーは、他のテーブルが、行の一意の識別子としてこの列セットに依存している可能性があることを示します。単一の列制約かテーブル制約かにかかわらず、テーブルに指定できるプライマリキーは 1 つです。プライマリキーの制約は、同じテーブルに定義されている一意の制約で指定された列セットとは異なる列セットを指定する必要があります。 プライマリキーの制約は情報提供にのみ使用されます。プライマリキーの制約がシステムに強制されることはありませんが、プランナーによって使用されます。 FOREIGN KEY ( *column\_name* [, ... ] ) REFERENCES *reftable* [ ( *refcolumn* ) ] 外部キーの制約を指定する制約。この制約では、新しいテーブルの 1 列以上のグループに、参照テーブルのいずれかの行の参照列の値と一致する値のみを含める必要があります。*refcolumn* を省略すると、*reftable* のプライマリキーが使用されます。参照列は、参照テーブルの一意の制約またはプライマリキーの制約の列にする必要があります。 外部キーの制約は情報提供にのみ使用されます。プライマリキーの制約がシステムに強制されることはありませんが、プランナーによって使用されます。 ## 使用に関する注意事項 一意性、プライマリキー、および外部キーの制約は情報提供のみを目的としており、テーブルに値を入れるときに *Amazon Redshift によって強要されるわけではありません*。例えば、依存関係のあるテーブルにデータを挿入する場合、制約に違反していても挿入は成功します。ただし、プライマリキーと外部キーはプランニング時のヒントとして使用されます。アプリケーションの ETL プロセスまたは他の何らかのプロセスによってこれらのキーの整合性が強要される場合は、これらのキーを宣言する必要があります。依存関係のあるテーブルを削除する方法については、「[DROP TABLE](r_DROP_TABLE.md)」を参照してください。 ### 制限とクォータ テーブルを作成するときは、次の制限を考慮してください。 + ノードタイプごとにクラスター内のテーブルの最大数には制限があります。詳細については、「*Amazon Redshift 管理ガイド*」の「[制限](https://docs.aws.amazon.com/redshift/latest/mgmt/amazon-redshift-limits.html)」を参照してください。 + テーブルの最大文字数は 127 です。 + 1 つのテーブルで定義できる列の最大数は 1,600 です。 + 1 つのテーブルで定義できる SORTKEY 列の最大数は 400 です。 ### 列レベルの設定とテーブルレベルの設定の概要 列レベルまたはテーブルレベルで設定できる属性と設定値がいくつかあります。属性または制約を列レベルまたはテーブルレベルで設定して同じ結果が得られる場合もあれば、異なる結果が得られる場合もあります。 次のリストは、列レベルとテーブルレベルの設定値の概要を示したものです。 DISTKEY 列レベルで設定されるかテーブルレベルで設定されるかにかかわらず、結果に違いはありません。 列レベルかテーブルレベルかにかかわらず、DISTKEY が設定されている場合は、DISTSTYLE を KEY に設定するか、まったく設定しない必要があります。DISTSTYLE はテーブルレベルでしか設定できません。 SORTKEY 列レベルで設定されている場合、SORTKEY は 1 列でなければなりません。SORTKEY がテーブルレベルで設定されている場合は、1 つまたは複数の列で複合ソートキーまたはインターリーブコンポジットソートキーを構成できます。 COLLATE CASE\_SENSITIVE \| COLLATE CASE\_INSENSITIVE Amazon Redshift では、列での大文字と小文字の区別に関する設定の変更はサポートされていません。新しい列をテーブルに追加すると、Amazon Redshift は、大文字と小文字の区別に関するデフォルト値を適用します。Amazon Redshift は、新しい列を追加するときに、COLLATE キーワードをサポートしません。 データベース照合を使用してデータベースを作成する方法については、「[CREATE DATABASE](r_CREATE_DATABASE.md)」を参照してください。 COLLATE 関数の詳細については、「[COLLATE 関数](r_COLLATE.md)」を参照してください。 UNIQUE 列レベルでは、1 つまたは複数のキーを UNIQUE に設定できます。UNIQUE 制約は各列に個別に適用されます。UNIQUE がテーブルレベルで設定されている場合は、1 つまたは複数の列で複合 UNIQUE 制約を構成できます。 PRIMARY KEY 列レベルで設定されている場合、PRIMARY KEY は 1 列でなければなりません。PRIMARY KEY がテーブルレベルで設定されている場合は、1 つまたは複数の列で複合プライマリキーを構成できます。 外部キー FOREIGN KEY が列レベルで設定されるかテーブルレベルで設定されるかにかかわらず、結果に違いはありません。列レベルでは、構文は単に `REFERENCES` *reftable* [ ( *refcolumn* )] になります。 ### 受信データの分散 受信データのハッシュ分散スキームが、ターゲットテーブルのスキームと同じ場合、データをロードするときに、データを物理的に分散させる必要はありません。例えば、新しいテーブルに分散キーが設定されており、同じキー列で分散されている別のテーブルからデータが挿入される場合、同じノードとスライスを使用してデータが所定の位置にロードされます。ただし、ソーステーブルとターゲットテーブルの両方が EVEN 分散に設定されている場合、データはターゲットテーブルで再分散されます。 ### 横長のテーブル 非常に横長のテーブルは、作成できても、そのテーブルに対して INSERT や SELECT などのクエリ処理を実行できないことがあります。CHAR のように固定幅の列を持つテーブルの最大幅は、64KB マイナス 1 (つまり 65535 バイト) です。テーブルに VARCHAR 列がある場合は、エラーを返さないで、より大きな幅を宣言できます。VARCHAR 列は、宣言した幅がクエリ処理の制限の算出に関係しないためです。VARCHAR 列に関する有効なクエリ処理の制限は、いくつかの要因に応じて変わります。 テーブルの幅が広すぎて挿入や選択ができない場合は、次のエラーが発生します。 ``` ERROR: 8001 DETAIL: The combined length of columns processed in the SQL statement exceeded the query-processing limit of 65535 characters (pid:7627) ``` ## 例 ALTER TABLE コマンドの使用方法を示す例については、「[例](r_CREATE_TABLE_examples.md)」のトピックを参照してください。