ALTER TABLE

開発者リファレンス : データアクセス方法 : SQL Engine Reference : SQL 構文リファレンス : ALTER TABLE

このページをシェアする

ALTER TABLE

ALTER TABLE ステートメントにより、テーブル定義を変更します。ALTER TABLE を使用して列を変更した場合、既存の列定義に追加されるのではなく、新しい定義に置き換えられることに留意してください。

構文

ALTER TABLE テーブル名 [IN DICTIONARY]

[USING 'パス名'] [WITH REPLACE] 変更オプション

テーブル名 ::= ユーザー定義名

オプション ::= DCOMPRESS | PCOMPRESS | PAGESIZE = サイズ | SYSDATA_KEY_2

パス名 ::= ファイル名のみ、または相対パスとファイル名

変更オプション ::= 変更オプション-リスト1 | 変更オプション-リスト2

変更オプション-リスト1 ::= 変更オプション | (変更オプション[, 変更オプション]...)

変更オプション ::= ADD [COLUMN] 列定義

| ADD テーブル制約定義

| ALTER [COLUMN] 列定義

| DROP [COLUMN] 列名

| DROP CONSTRAINT 制約名

| DROP PRIMARY KEY

| MODIFY [COLUMN] 列定義

変更オプション-リスト2 ::= PSQL_MOVE [COLUMN] 列名 TO [[PSQL_PHYSICAL] PSQL_POSITION] 新しい列位置 | RENAME COLUMN 列名 TO 新しい列名

列定義 ::= 列名データ型 [DEFAULT デフォルト値の式] [列制約定義 [列制約定義]...[CASE（文字列） | COLLATE 照合順序名]

列名 ::= ユーザー定義名

新しい列位置 ::= 新しい位置を表す序数値（正の整数値）。値は、0 より大きく、テーブル内の列の総数以下でなければなりません。

新しい列名 ::= ユーザー定義名

データ型 ::= データ型名 [(桁数[, 小数位])]

桁数 ::= 整数

小数位 ::= 整数

デフォルト値の式 ::= デフォルト値の式 + デフォルト値の式

| デフォルト値の式 - デフォルト値の式

| デフォルト値の式 * デフォルト値の式

| デフォルト値の式 / デフォルト値の式

| デフォルト値の式 & デフォルト値の式

| デフォルト値の式 | デフォルト値の式

| デフォルト値の式 ^ デフォルト値の式

| (デフォルト値の式)

| -デフォルト値の式

| +デフォルト値の式

| ~デフォルト値の式

| ?

| リテラル

| スカラー関数

| {fn スカラー関数｝

| USER

| NULL

デフォルトのリテラル ::= '文字列' | N'文字列'

| 数字

| {d '日付リテラル'}

| {t '時刻リテラル'}

| {ts 'タイムスタンプリテラル'}

デフォルトのスカラー関数 ::= USER( )

| NULL( )

| NOW()

| CURRENT_TIMESTAMP()

| CONVERT()

列制約定義 ::= [CONSTRAINT 制約名] 列制約

制約名 ::= ユーザー定義名

列制約 ::= NOT NULL

| NOT MODIFIABLE

| UNIQUE

| PRIMARY KEY

| REFERENCES テーブル名 [(列名)] [参照アクション]

参照アクション ::= 参照更新アクション [参照削除アクション]

| 参照削除アクション [参照更新アクション]

参照更新アクション ::= ON UPDATE RESTRICT

参照削除アクション ::= ON DELETE CASCADE

| ON DELETE RESTRICT

照合順序名 ::= '文字列'

テーブル制約定義 ::= [CONSTRAINT 制約名] テーブル制約

テーブル制約 ::= UNIQUE (列名[, 列名]...)

| PRIMARY KEY (列名[, 列名]...)

| FOREIGN KEY (列名[, 列名])

REFERENCES テーブル名

[(列名[, 列名]...)]

[参照アクション]

備考

主キーおよび外部キーと参照整合性に関する情報については、CREATE TABLE を参照してください。

CHAR、VARCHAR、または LONGVARCHAR と、NCHAR、NVARCHAR、または NLONGVARCHAR とにおける変換では、CHAR 値はデータベースコードページを使用してエンコードされていることを前提とします。LONGVARCHAR 型の列を NLONGVARCHAR 型に変更することも、NLONGVARCHAR 型を LONGVARCHAR 型に変更することもできません。

ALTER TABLE では、テーブルが排他ロックされている必要があります。別のステートメントにより同じテーブルが開いていると、ALTER TABLE は失敗してステータスコード 88 を返します。データ操作ステートメントを実行する前に、すべてのデータ定義ステートメントを実行しておいてください。これを示す例は、PSQL_MOVE を参照してください。

SYSDATA_KEY_2 キーワードを指定した ALTER TABLE ステートメントでは、ファイルのバージョンがまだ 13.0 形式でない場合には自動的に 13.0 に変更されます。その後、システムデータ v2 が追加され、仮想列 sys$create および sys$update をクエリで使用できるようになります。詳細については、システムデータ v2 のアクセスを参照してください。

SYSDATA_KEY_2 キーワードと一緒に IN DICTIONARY を使用した場合、ALTER TABLE ステートメントは SYSDATA_KEY_2 を無視するため、テーブルの sys$create および sys$update 仮想列は使用できません。

IN DICTIONARY

このキーワードを使用する目的は、基となる物理データは変更しないままで DDF に変更を加えたいことを、データベースエンジンに通知することです。IN DICTIONARY は上級ユーザー向けの強力な機能です。これは、絶対に必要な場合にだけ、システム管理者のみが使用してください。通常、Zen は DDF とデータファイルの完全な同期を保ちますが、この機能により、ユーザーは柔軟にテーブルの辞書定義を既存のデータファイルに合致させることが可能になります。このキーワードは、既存のデータファイルと合致する定義を辞書内に作成したい場合、あるいは USING 句を使ってテーブルのデータファイルパス名を変更したい場合に有用です。

IN DICTIONARY をバウンドデータベースで使うことはできません。

IN DICTIONARY は ALTER TABLE に加え、CREATE TABLE および DROP TABLE で使用できます。IN DICTIONARY は、どの CREATE/ALTER オプションが指定されていようと、辞書エントリにのみ影響します。Zen では複数のオプション（ADD、DROP、ADD CONSTRAINT などのあらゆる組み合わせ）が許可されることから、IN DICTIONARY は、DDF だけがスキーマの変更によって影響を受けることを保証するために、すべての状況下で優先されます。

デタッチされたテーブルまたは存在しないテーブルを照会すると、"テーブルが見つかりません" というエラーになります。テーブルの存在を確認したにもかかわらず "テーブルが見つかりません" エラーを受け取った場合、このエラーはデータファイルを開けなかったことが原因で発生しています。これはデタッチされたテーブルを示します。（DDF のみが存在する（データファイルは存在しない）テーブルは、「デタッチされた」エントリと呼ばれます。これらのテーブルには、クエリを介して、また、クエリ以外で基となる物理ファイルを開こうとする操作を介してアクセスできません。）

テーブルが実際に存在するかどうかは、カタログ関数（システムカタログ関数を参照）を使用するか、X$File の Xf$Name 列に直接クエリを実行することにより確認できます。

SELECT * FROM X$File WHERE Xf$Name = 'テーブル名'

SELECT ステートメントは Xf$Loc 値を返します。これは、テーブルの物理ファイルの名前です。この名前とデータベースに定義されているデータパスを組み合わせれば、ファイルの絶対パスを取得できます。

デタッチされたテーブルの場合は混乱を招く可能性があるので、IN DICTIONARY 機能は非常に注意して使用しなければなりません。テーブル定義を物理ファイルと合致させるために使用するものであり、テーブル定義のデタッチに使用してはならないということがきわめて重要です。次の例で、test123.btr ファイルは存在しないと仮定して考えてみましょう（USING は次のサブトピックで説明されています）。

CREATE TABLE t1 USING 't1.btr' (c1 INT)

ALTER TABLE t1 IN DICTIONARY USING 'test123.btr'

または、両方のステートメントを組み合わせると次のようになります。

CREATE TABLE t1 IN DICTIONARY USING 'test123.btr' (c1 INT)

その後 SELECT from t1 を実行すると、テーブルが見つからなかったというエラーが返されます。テーブルを作成しただけであって、どのようにしてもそれを見つけることができないので、混乱が生じることがあります。また、IN DICTIONARY を指定しないでテーブルを DROP しようとすると、同様のエラーが返されます。これらのエラーは、テーブルに関連付けられたデータファイルが存在しないことが原因で発生します。

既存の Btrieve データファイルに対してリレーショナルインデックス定義を作成する（たとえば、ALTER TABLE ステートメントを発行して IDENTITY 型の列定義を追加する）たびに、Zen はそのファイルに定義されている Btrieve インデックスを自動的にチェックし、既存の Btrieve インデックスがリレーショナルインデックス定義に必要なパラメーターのセットを提供しているかどうかを判定します。既存の Btrieve インデックスと作成する新しい定義が一致する場合は、リレーショナルインデックス定義と既存の Btrieve インデックスの間に関連付けが作成されます。一致するインデックスがない場合は、Zen は新しいインデックス定義を作成し、IN DICTIONARY が指定されていなければ、データファイルに新しいインデックスを作成します。

USING

USING キーワードを使用すると、特定のデータファイルを CREATE TABLE または ALTER TABLE アクションと関連付けることができます。

Zen は接続に名前付きデータベースを必要とするので、指定するパス名は常に単純なファイル名であるか、または相対パスとファイル名でなければなりません。パスは常に、接続する名前付きデータベースに指定された最初のデータパスとの相対になります。

渡されたパス名およびファイル名は、ステートメントの準備ができたときに部分的に検証されます。

パス名を指定するときは、次の規則に従う必要があります。

•テキストは、文法定義で示されているように、一重引用符で囲まなければなりません。

•テキストの長さは、X$File の Xf$Loc に収まるよう、メタデータバージョン 1 の場合は 1 から 64 文字まで、メタデータバージョン 2 の場合は 1 から 250 文字まででなければなりません。エントリは入力したまま正確に格納されます（ただし、後続の空白は切り捨てられ、無視されます）。

•パスは、単純な相対パスでなければなりません。サーバーまたはボリュームを参照するパスは許可されません。

•相対パスには、1 つのピリオド（"." は現在のディレクトリ）、2 つのピリオド（".." は親ディレクトリ）、円記号（"\"）、またはこれら 3 つのあらゆる組み合わせを含めることができます。パスは、SQL テーブル名を表すファイル名を含んでいる必要があります（パス名は円記号 "\" またはディレクトリ名で終わってはいけません）。CREATE TABEL または ALTER TABLE を使用してファイルを作成する場合、ファイル名は、相対パス付きで指定されたファイル名も含めてすべて、名前付きデータベースの設定で定義されている最初のデータパスとの相対にします。（IN DICTIONARY を使用する場合、ファイル名には最初のデータの場所への相対パスを付けません。）

•ルートベースの相対パスを使用できます。たとえば、最初のデータパスを D:\mydata\demodata とした場合、Zen は次のステートメント内のパス名を D:\temp\test123.btr と解釈します。

CREATE TABLE t1 USING '\temp\test123.btr' (c1 int)

•相対パス内の円記号（'\'）文字は、好みに応じて、Linux スタイル（'/'）と通常使われる円記号（'\'）のどちらを指定してもかまいません。必要であれば、2 種類の記号を混在させて使用することもできます。ディレクトリ構造スキーマは知っているかもしれませんが、接続されているサーバーの種類を知っている（あるいは管理している）とは限らないので、これは便利な機能です。パスは入力したとおりに X$File に格納されます。Zen エンジンは、パスを利用してファイルを開く際、円記号文字を適切なプラットフォームのタイプに変換します。また、データファイルはサポートされるすべてのプラットフォーム間でバイナリ互換性を共有するため、ディレクトリ構造がプラットフォーム間で同一である（および、パスに基づくファイル名が相対パスで指定されている）限りは、データベースファイルおよび DDF をこれらに変更を加えることなく、あるプラットフォームから別のプラットフォームへ移動することができます。これは、複数のプラットフォームにまたがって、標準化されたデータベーススキーマをより簡単に配置するのに役立ちます。

•相対パスを指定する場合、まず USING 句のディレクトリ構造は存在している必要があります。Zen は、USING 句で指定されたパス条件を満たすディレクトリを作成しません。

USING 句を使用して、既存のテーブルと関連付ける既存データファイルの物理的場所と名前を指定します。USING 句ではまた、既存の辞書定義を使用して、特定の場所に新しいデータファイルを作成することができます（USING 句に指定した文字列は、X$File 辞書ファイルの Xf$Loc 列に格納されます）。新しいファイルを作成するとき、ファイル情報のいくつかを元のデータファイルから取得する必要があるので、元のデータファイルは使用可能でなければなりません。

Demodata サンプルデータベースでは、Person テーブルは PERSON.MKD ファイルと関連付けられています。PERSON2.MKD という名前の新しいファイルを作成すると、次の例のステートメントは、Person テーブルが新しいファイルと関連付けられるように、Person テーブルの辞書定義を変更します。

ALTER TABLE Person IN DICTIONARY USING 'person2.mkd'

USING 句には単純なファイル名か相対パスのいずれかを使用しなければなりません。相対パスを指定した場合、Zen はそのパスを、データベース名と関連付けられている最初のデータファイルパスとの相対と解釈します。

USING 句は、ALTER TABLE のほかの標準オプションに加えて指定することができます。これは、USING パスを指定するステートメントと同じステートメント内で列を操作できるということです。

テーブルデータを格納するために現在使用しているデータファイル名と異なるデータファイル名を指定し、IN DICTIONARY を指定しないと、Zen は新しいファイルを作成し、既存ファイルのデータをすべて新規ファイルにコピーします。たとえば、Person テーブルのデータを保持している現在のデータファイルは person.mkd であると仮定します。上記のステートメントで示されるように、person2.mkd ファイルを使用するよう Person テーブルを変更します。person.mkd の内容が person2.mkd にコピーされます。そうすると、person2.mkd が Person テーブルと関連付けられたデータファイルとなり、データベース操作は person2.mkd に作用します。person.mkd は削除されませんが、データベースにはもう関連付けられなくなります。

データをコピーするのは、Zen では、USING と同時にそれ以外のすべての ALTER TABLE オプションを指定できるためです。作成された新しいデータファイルには、既存テーブルのデータが完全に読み込まれる必要があります。ファイル構造は単純にコピーされるのではなく、内容全体が移行されます。これは、Btrieve の BUTIL -CREATE と BUTIL -COPY を実行するのに似ています。このことは、SQL テーブルを再構築したり、以前は多数のレコードを格納していたが現在は少数のレコードしか格納していないファイルを圧縮したりするのに役立ちます。

メモ：ALTER TABLE USING は、既存のデータファイルの内容を新しく指定されたデータファイルにコピーし、古いデータファイルは元のまま、ただしリンクは解除して残しておきます。

WITH REPLACE

WITH REPLACE が USING と共に指定されたときはいつでも、Zen は既存のファイル名を指定されたファイル名で自動的に上書きします。オペレーティングシステムがファイルの上書きを許している限り、ファイルは常に上書きされます。

WITH REPLACE はデータファイルにのみ作用し、DDF には作用しません。

WITH REPLACE を使用する際には次の規則が適用されます。

•WITH REPLACE は USING と併せてのみ使用できます。

•IN DICTIONARY と一緒に使用すると、WITH REPLACE は無視されます。IN DICTIONARY は DDF にのみ作用することを指定するものだからです。

メモ：ALTER TABLE で WITH REPLACE を使用しても、データは消失したり破棄されたりしません。新しく作成されたデータファイルは、既存ファイルを上書きしたファイルであっても、以前のファイルのデータをすべて含んでいます。ALTER TABLE コマンドを使用することで、データを失うことはありません。

Zen に既存ファイル（ファイルは、USING 句で指定された場所になければなりません）を置き換えるよう指示するには、USING 句で WITH REPLACE を使用します。WITH REPLACE を使用すると、Zen は新しいファイルを作成し、既存ファイルのデータをすべて新規ファイルにコピーします。WITH REPLACE を使用していないとき、指定された場所にファイルが存在すると、Zen はステータスコードを返し、新しいファイルを作成しません。ステータスコードはエラー -4940 です。

MODIFY COLUMN と ALTER COLUMN

列のデータ型やヌル値を許可するかどうかを変更する機能は、次の制約を受けます。

•ターゲット列では、PRIMARY/FOREIGN KEY 制約を定義することはできません。

•旧データ型を新しいデータ型に変換することによって（演算またはサイズの）オーバーフローが発生する場合、ALTER TABLE 操作は中止されます。

•ヌル値を許可する列がヌル値を含む場合、その列をヌル値を許可しない列に変更することはできません。

主キー列または外部キー列のデータ型を変更する必要がある場合は、制約を削除し、列のデータ型を変更してから再び制約を追加することにより実現できます。関連するすべてのキー列の同期がとれているようにしなければならない、ということに留意してください。たとえば、テーブル T1 に主キーがあり、このキーがテーブル T2 および T3 の外部キーによって参照される場合は、まず外部キーを削除しなければなりません。外部キーを削除した後で、主キーを削除することができます。次に、3 つの列をすべて同じデータ型に変更する必要があります。最後に、主キーを再び追加してから、外部キーを追加します。

ANSI 標準には ALTER キーワードが含まれています。Zen では、ALTER TABLE ステートメントで MODIFY キーワードも使用できます。COLUMN キーワードは省略可能です。たとえば、次のようになります。

ALTER TABLE t1 MODIFY c1 INTEGER

ALTER TABLE t1 ALTER c1 INTEGER

ALTER TABLE t1 MODIFY COLUMN c1 INTEGER

ALTER TABLE t1 ALTER COLUMN c1 INTEGER

Zen では、実際のデータが、列の長さを小さくした新しい列でオーバーフローしないのであれば、列の長さを小さくすることができます。この動作は、Microsoft SQL Server の動作に似ています。

1 つの ALTER TABLE ステートメントで、複数の列を追加、削除、または変更することができます。これは操作を簡略化しますが、この動作は ANSI 互換とみなされません。次に、複数列の ALTER ステートメントの例を示します。

ALTER TABLE t1 (ALTER c2 INT, ADD D1 CHAR(20), DROP C4, ALTER C5 LONGVARCHAR, ADD D2 LONGVARCHAR NOT NULL)

旧データ型（Pervasive.SQL v7 以前）を、現在の Zen リリースでサポートされているネイティブなデータ型に変換できます。逆に、新データ型を旧データ型へ変換したい場合は、Zen サポートにお問い合わせください。

NOTE/LVAR 列を持つ古いテーブルに LONGVARCHAR/LONGVARBINARY 列を追加するには、まず、NOTE/LVAR 列を LONGVARCHAR または LONGVARBINARY 列に変換しなければなりません。NOTE/LVAR 列を LONGVARCHAR/LONGVARBINARY に変換したら、テーブルにそれ以外の LONGVARCHAR/LONGVARBINARY 列を追加できます。古いエンジンでは、テーブル当たり 1 つの可変長列しか扱うことができないため、前述の新しいテーブルを使って作業することはできないので注意してください。

PSQL_MOVE

PSQL_MOVE 構文を使用すると、テーブルの列を希望する位置に保持することができます。既存の列や、追加された新しい列の位置を変更したい場合があります。列を論理的および物理的に移動させることができます。

移動の種類	結果
論理的	結果セットにリストされる列の位置は変わりますが、テーブル内の列の物理的順序は変わりません。たとえば、"SELECT * FROM テーブル名" のようなクエリで生成される結果セットにおける列の配置方法を変更できます。論理的移動は、"SELECT * FROM テーブル名" のような、列を列挙するクエリにのみ影響を及ぼします。
物理的	列は、ファイル内の現在位置から新しい位置へ物理的に移動されます。物理的移動は、テーブルのデータファイルに影響を及ぼします。列を物理的に移動する場合は、PSQL_PHYSICAL キーワードを指定する必要があります。PSQL_PHYSICAL キーワードを省略すると、デフォルトで論理的移動が生じます。 ALTER TABLE ステートメントで IN DICTIONARY が使用されている場合は、DDF 内の列のオフセットのみが変更されるので注意してください。データファイルに対し、MOVE ... PSQL_PHYSICAL より IN DICTIONARY が優先されるため、データファイル内の列は物理的に移動されません。

移動の種類

結果

論理的

結果セットにリストされる列の位置は変わりますが、テーブル内の列の物理的順序は変わりません。たとえば、"SELECT * FROM テーブル名" のようなクエリで生成される結果セットにおける列の配置方法を変更できます。論理的移動は、"SELECT * FROM テーブル名" のような、列を列挙するクエリにのみ影響を及ぼします。

物理的

列は、ファイル内の現在位置から新しい位置へ物理的に移動されます。物理的移動は、テーブルのデータファイルに影響を及ぼします。列を物理的に移動する場合は、PSQL_PHYSICAL キーワードを指定する必要があります。PSQL_PHYSICAL キーワードを省略すると、デフォルトで論理的移動が生じます。

ALTER TABLE ステートメントで IN DICTIONARY が使用されている場合は、DDF 内の列のオフセットのみが変更されるので注意してください。データファイルに対し、MOVE ... PSQL_PHYSICAL より IN DICTIONARY が優先されるため、データファイル内の列は物理的に移動されません。

メモ：一度列を論理的に移動したら、その並び順が結果セットにおける列のデフォルトの列挙順になります。たとえば、列を論理的に移動させた後で物理的に移動させた場合、"SELECT * FROM テーブル名" のようなクエリでは、論理順が使用されます。論理的な列の変更は X$Attrib に格納されます。

PSQL_MOVE キーワードには、ゼロより大きく、列の総数よりも小さい値で列の位置を指定する必要があります。たとえば、テーブル t1 には col1 と col2 の 2 つの列だけがあるとします。次のステートメントはどちらもエラーを返します。

ALTER TABLE t1 PSQL_MOVE col1 to 0

ALTER TABLE t1 PSQL_MOVE col1 to 3

最初のステートメントは列を位置 0 へ移動しようとしています。2 番目のステートメントは列を位置 3 へ移動しようとしていますが、これは列の総数である 2 よりも大きい数値です。

ALTER TABLE では、テーブルが排他ロックされている必要があります。別のステートメントにより同じテーブルが開いていると、ALTER TABLE は失敗してステータスコード 88 を返します。データ操作ステートメントを実行する前に、すべてのデータ定義ステートメントを実行しておいてください。

たとえば、次のストアドプロシージャでは、INSERT ステートメントがテーブル t1 を開いていることにより、ALTER TABLE ステートメントが排他ロックを取得できないため、実行が失敗し、ステータスコード 88 が返されます。

CREATE PROCEDURE proc1() AS

BEGIN

CREATE TABLE t1(c1 INT,c2 INT,c3 INT);

INSERT INTO t1 VALUES (123,345,678);

ALTER TABLE t1 PSQL_MOVE c3 to 1;

END;

これを解決する方法は、最初にテーブル作成とデータ挿入に関連するステートメントを実行してから、プロシージャを呼び出すことです。

CREATE TABLE t1(c1 INT,c2 INT,c3 INT);

INSERT INTO t1 VALUES (123,345,678);

CALL proc1;

CREATE PROCEDURE proc1() AS

BEGIN

ALTER TABLE t1 PSQL_MOVE c3 to 1;

END;

RENAME COLUMN

RENAME COLUMN を使用すると、列の名前を別の名前に変更できます。ただし、同じテーブル内の既存の列名に変更することはできません。

列名を変更することにより、以前の名前を参照しているオブジェクトが無効になる場合があります。たとえば、あるトリガーがテーブル t1 の列 c1 を参照しているとします。列名を c1 から c5 に変更すると、トリガーは正常に実行できなくなります。

列の名前を変更する場合、psp_rename システムストアドプロシージャを使用することもできます。

メモ：データベースエンジンは、名前変更された列の依存関係をチェックしません。列の名前を変更したら、必ず、以前（変更元）の名前で依存関係が設定されているすべてのオブジェクトを適切に修正してください。

ON DELETE CASCADE

CREATE TABLE の削除規則を参照してください。

例

このセクションでは、ALTER TABLE のいくつかの例を示します。

次のステートメントによって、Emergency_Phone 列が Person テーブルに追加されます。

ALTER TABLE person add Emergency_Phone NUMERIC(10,0)

次のステートメントによって、col1 と col2 の 2 つの整数列が Class テーブルに追加されます。

ALTER TABLE class(add col1 INT, add col2 INT)

============

テーブル定義から列を削除するには、DROP 句内に列の名前を指定します。次のステートメントによって、Emergency_Phone 列が Person テーブルから削除されます。

ALTER TABLE person drop Emergency_Phone

次のステートメントによって、Class テーブルから col1 と col2 が削除されます。

ALTER TABLE class(drop col1, drop col2)

次のステートメントによって、Faculty テーブル内の制約 c1 が削除されます。

ALTER TABLE Faculty(drop CONSTRAINT c1)

============

この例では、Class テーブルに整数列 col3 が追加され、列 col2 が削除されます。

ALTER TABLE class(add col3 INT, drop col2)

============

次の例では、Faculty テーブル内の ID フィールドに c1 という名前の主キーが作成されます。ヌル値を許可する列には主キーを作成できないことに注意してください。作成しようとすると、エラーが返されます。

ALTER TABLE Faculty(add CONSTRAINT c1 PRIMARY KEY(ID))

次の例では、デフォルトのキー名である PK_ID を使用して、Faculty テーブルに主キーが作成されます。

ALTER TABLE Faculty(add PRIMARY KEY(ID))

============

次の例では、制約 UNIQUE が列 col1 と col2 に追加されます。すべての列の col1 と col2 の値の組み合わせが、テーブル内で一意になります。どちらの列も個々に一意である必要はありません。

ALTER TABLE Class(add UNIQUE(col1,col2))

============

次の例では、Faculty テーブル内の主キーが削除されます。テーブルに複数の主キーがあってはならないので、既に主キーが定義されているテーブルに主キーを追加することはできません。テーブルの主キーを変更するには、既存のキーを削除してから新しい主キーを追加します。

ALTER TABLE Faculty(drop PRIMARY KEY)

親テーブルから主キーを削除するには、その前に、従属テーブルから対応する外部キーをすべて削除する必要があります。

============

次の例は、Class テーブルに新規の外部キーを追加します。Faculty_ID 列はヌル値を含まない列として定義されます。ヌル値を許可する列には外部キーを作成できません。

ALTER TABLE Class ADD CONSTRAINT Teacher FOREIGN KEY (Faculty_ID) REFERENCES Faculty (ID) ON DELETE RESTRICT

この例では、削除制限規則によって、まず教職員の全講座を変更または削除してからでないと、その教職員をデータベースから削除できないようになっています。また、REFERENCES 句にリストされている列（ID）は任意であることに注目してください。ステートメントをより明確にするために、好みによって REFERENCES 句に列のリストを含めることができます。ただし、REFERENCES 句で参照できる列は参照テーブルの主キーのみです。

次のステートメントでは、上記の例で追加した外部キーを削除する方法を示します。Zen は従属テーブルから外部キーを削除し、従属テーブルと親テーブル間の参照制約を取り除きます。

ALTER TABLE Class DROP CONSTRAINT Teacher

============

次の例は、CONSTRAINT 句を使用しないで Class テーブルに外部キーを追加します。この場合、外部キーの制約は内部的に生成され、Faculty の主キー（ID）を参照するように定義されます。REFERENCES 句にリストされている列は任意です。ステートメントをより明確にするために、好みによって REFERENCES 句に列のリストを含めることができます。ただし、REFERENCES 句で使用できる列は参照テーブルの主キーのみです。

ALTER TABLE Class ADD FOREIGN KEY (Faculty_ID) REFERENCES Faculty (ID) ON DELETE RESTRICT

これにより、外部キー FK_Faculty_ID が作成されます。外部キーを削除するには、CONSTRAINT キーワードを指定します。

ALTER TABLE Class DROP CONSTRAINT FK_Faculty_ID

============

次の例では、テーブル内の制約と列を追加および削除する方法を示します。このステートメントにより、Faculty テーブル内の列 salary が削除され、整数型の列 col1 が追加され、制約 c1 が削除されます。

ALTER TABLE Faculty(DROP salary, ADD col1 INT, DROP CONSTRAINT c1)

============

次の例はどちらも、複数の列のデータ型を変更する方法を示しています。

ALTER TABLE t1 (ALTER c2 INT, ADD D1 CHAR(20), DROP C4, ALTER C5 LONGVARCHAR, ADD D2 LONGVARCHAR NOT NULL)

ALTER TABLE t2 (ALTER c1 CHAR(50), DROP CONSTRAINT MY_KEY, DROP PRIMARY KEY, ADD MYCOLUMN INT)

============

次の例では、列オプションの ALTER と MODIFY を使って、列のデフォルト値およびオルタネートコレーティングシーケンスを設定したり削除する方法が示されています。

CREATE TABLE t1 (c1 INT DEFAULT 10, c2 CHAR(10))

ALTER TABLE t1 ALTER c1 INT DEFAULT 20

－列 c1 のデフォルト値を 20 に再設定する

ALTER TABLE t1 ALTER c1 INT

－列 c1 のデフォルト値を削除する

ALTER TABLE t1 ALTER c2 CHAR(10)
COLLATE 'file_path\upper.alt'

－列 c2 のオルタネートコレーティングシーケンスを設定する

ALTER TABLE t1 ALTER c2 CHAR(10)

－列 c2 のオルタネートコレーティングシーケンスを削除する

upper.alt は、ソートする際に大文字と小文字を同等に扱います。たとえば、データベースに abc、ABC、DEF、Def という値がこの順序で挿入されている場合、upper.alt を使ってソートすると、abc、ABC、DEF、Def のように返されます（値 abc と ABC、DEF と Def は同じものと判断され、これらは挿入された順序で返されます）。標準の ASCII ソートでは、大文字は小文字の前に配列されており、ソート結果は ABC、DEF、Def、abc のようになります。

============

次のステートメントは、列 Registrar_ID が結果セットにリストされるときの位置を、現在位置から 2 番目へ論理的に移動させます。

ALTER TABLE Billing PSQL_MOVE Registrar_ID TO 2

次のステートメントは、列 Amount_Owed と Amount_Paid が結果セットにリストされるときの位置を、それぞれ現在位置から 2 番目と 3 番目へ移動させます。

ALTER TABLE Billing ( PSQL_MOVE Amount_Owed TO 2, PSQL_MOVE Amount_Paid TO 3 )

============

次のステートメントは、列 Registrar_ID のデータファイル内の位置を、現在位置から 2 列目へ物理的に移動させます。これにより、変更を反映させるためにデータファイルのリビルドが生じます。

ALTER TABLE Billing PSQL_MOVE Registrar_ID TO PSQL_PHYSICAL 2

次のステートメントは、列 Amount_Owed と Amount_Paid のデータファイル内の位置を、それぞれ現在位置から 2 列目と 3 列目へ移動させます。

ALTER TABLE Billing ( PSQL_MOVE Amount_Owed TO PSQL_PHYSICAL 2, PSQL_MOVE Amount_Paid TO PSQL_PHYSICAL 3 )

============

テーブル t1 には列 c1 と col2 があるとします。次のステートメントによって、列 c1 の名前が c2 に変更されます。

ALTER TABLE t1 RENAME COLUMN c1 TO c2

============

テーブル t1 には列 c1 と col2 があるとします。次のステートメントは、列の名前（col2）を既存の列の名前（c1）に変更しようとするため、エラー（列名が重複しています）が返されます。

ALTER TABLE t1 (RENAME COLUMN c1 TO c2, RENAME COLUMN col2 TO c1)

代わりに、2 つの ALTER ステートメントを発行する必要があります。1 つ目は c1 を c2 に名前変更します。2つ目は col2 を c1 に名前変更します。

ALTER TABLE t1 (RENAME COLUMN c1 TO c2)

ALTER TABLE t1 (RENAME COLUMN col2 TO c1)