このトピックでは、スキーマ設計の基本的な設定、チェックポイント、要素、アクション、およびテンプレートライブラリについて紹介し、デフォルトの承認テンプレートを変更して新しいルールを追加する方法を解説します。
背景情報
スキーマ設計チケットは通常、複数のインスタンスを対象とし、標準的なプロセスに従います。具体的には、テスト環境でスキーマを設計し、その後、本番環境に公開します。そのため、スキーマ設計のセキュリティルールに含まれる [基本設定]、[設計ルール]、および [リスク識別ルール]は、[変更ベースラインデータベース] (テスト環境のデータベース) が配置されているインスタンスのセキュリティルールを使用します。
-
[設計ルール]には、[Save and Edit - Check Table Header]、[Save and Edit - Check Field]、および [Save and Edit - Check Index] が含まれます。セキュリティルールの編集ページでは、これら 3 つのチェックポイントが チェックポイント セクションのタブとして表示されます。
-
[リスク識別ルール]には、[テーブル作成のリスクコントロール]、[フィールド変更のリスクコントロール]、[インデックス変更のリスクコントロール]、および [SQL 実行のリスクコントロール] が含まれます。これらも チェックポイント セクションのタブとして表示されます。
ただし、承認プロセスでは、本番環境のデータベースが配置されているインスタンスのセキュリティルールを使用します。たとえば、スキーマ設計チケットがデータベース B に公開された場合、システムはインスタンス B のセキュリティルールを適用します。
基本設定
スキーマ設計には、いくつかの基本設定があります:
-
非対称パブリッシングの有効化:デフォルトでは、スキーマ設計の変更は対称的にのみ公開できます。つまり、テーブルへの変更は、別のデータベースにある同じ名前のテーブルにのみ公開できます。非対称パブリッシングを有効にすると、名前に関係なく、任意のターゲットテーブルに変更を公開できます。
警告この機能には重大なリスクが伴います。特定のシナリオでのみ、注意して有効にしてください。
-
開発プロセス:これは、スキーマ設計のセキュリティルールにおける主要な設定です。スキーマ設計チケットのライフサイクルにおけるすべての段階を定義します。次の表で、これらのオプションについて説明します。
パラメーター
説明
[ステップ]
[設計]ノードと[公開]ノードで構成されます。
-
設計ノード:設計ノードはデフォルトであり、削除できません。スキーマ変更タスクを設計する環境を決定します。
-
公開ノード:設計が完了すると、プロセスは変更を適用するための公開ステージに移行します。複数の公開ノードを追加できます。
[ノード名]
最大 10 文字のカスタムノード名。
[データベース環境]
ノードが実行される環境。
[実行戦略]
-
[即時]:タスクは承認されるとすぐに実行されます。
-
[時間指定]:タスクを公開する時間を指定できます。タスクが指定された時間より前に承認された場合、その時間に実行されます。それ以外の場合、タスクはキャンセルされます。
[ロールバック可能]
公開タスクを[設計]ノードにロールバックできるかどうかを指定します。
[スキップ可能]
現在のステップをスキップできるかどうかを指定します。
[アンカー]
チケットの編集が凍結されるポイントをマークします。アンカーが設定されたステップが正常に完了すると、スキーマは編集できなくなり、チケットのステータスが [公開済み] に変わります。
[操作]
要件に応じて[公開]ノードを削除できます。
-
-
フィールドタイプ設定:[Add Field] オプションで使用できるデータ型を設定します。
-
インデックスタイプ設定:[Add Index] で使用できるデータ型を指定します。
-
テーブル作成テンプレート:テーブルを作成するためのテンプレートを設定します。新しいテーブルは、デフォルトでこのテンプレートを読み込みます。このテンプレートはオプションであり、テーブル作成時に変更できます。
-
元のフィールドのデータ型の変更の禁止:テーブルを変更する際に、既存のフィールドのデータ型を変更することを禁止します。
-
元のフィールドの削除の禁止:テーブルを変更する際に、既存のフィールドを削除することを禁止するかどうかを指定します。これはリスクの高い操作であるため、このオプションを有効にすることを推奨します。
-
元のフィールドの名前変更の禁止:テーブルを変更する際に、既存のフィールドの名前を変更することを禁止するかどうかを指定します。既存のフィールドの名前変更はリスクの高い操作です。このオプションを有効にすることを推奨します。
-
テーブル文字セット権限設定:新しいテーブルで使用できる文字セット (utf8 や utf8mb4 など) を設定します。
-
スキーマ設計のデフォルト承認テンプレート:[Approval Rule Check] チェックポイントに承認ルールが設定されていない場合、スキーマ設計チケットはこのデフォルトの承認テンプレートを使用します。[Switch Approval Template] 機能を使用して、デフォルトテンプレートの承認プロセスを変更できます。詳細については、「デフォルトの承認テンプレートの変更」をご参照ください。
-
リリース時にチケットを自動的にクローズ状態に進める:有効にすると、開発プロセスで[アンカー]を含むノードが変更を正常に実行した後、システムはチケットを自動的にクローズ状態に移行させます。 (アンカーは、開発プロセスの最後のリリースノードに設定する必要があります。)
チェックポイント
スキーマ設計には 2 つのプロセスがあります。
-
保存と編集プロセス: このプロセスは次の 3 つのチェックポイントで構成され、テーブルヘッダー、フィールド、インデックスの仕様を順次チェックします。
-
[保存と編集 - テーブルヘッダーのチェック]
-
[保存と編集 - フィールドのチェック]
-
[保存と編集 - インデックスのチェック]
-
-
変更実行プロセス: このプロセスは次の 5 つのチェックポイントで構成されます。最初の 4 つのチェックポイントではデータ定義言語 (DDL) 変更のリスクを識別し、最後の 1 つでは各リスクの承認プロセスを指定します。
-
[テーブル作成のリスクコントロール]
-
[フィールド変更のリスクコントロール]
-
[インデックス変更のリスクコントロール]
-
[SQL 実行のリスクコントロール]
-
[承認ルールチェック]
-
両方のプロセスには、直接使用またはカスタマイズ可能な組み込みのセキュリティルールテンプレートが多数用意されています。詳細については、「新しいルールの追加」をご参照ください。
ファクターとアクション
-
ファクター: ファクターとは、SQL タイプや影響を受ける行数など、セキュリティルールチェック用のコンテキスト情報を提供する組み込みのシステム変数です。すべてのファクターは
@fac.で始まり、その後にファクター名が続きます。各モジュールは、チェックポイントごとに異なるファクターを提供します。次の表では、[スキーマ変更] で使用できるファクターについて説明します。ファクター
説明
@fac.table_kind
編集対象のテーブルタイプです。有効な値:
-
new:新規テーブル。
-
old:既存テーブル。
@fac.column_kind
テーブルスキーマ内のフィールドタイプです。有効な値:
-
new:新規フィールド。
-
old:既存フィールド。
@fac.xxxx_old
比較のために、フィールドまたはインデックスの元の値を取得します。
@fac.column_is_primary
フィールドがプライマリキーに含まれるかどうかを示します。有効な値:
-
true:フィールドはプライマリキーに含まれます。
-
false:フィールドはプライマリキーに含まれません。
@fac.column_type_support_default
フィールドのデータ型でデフォルト値を設定できるかどうかを示します。有効な値:
-
true:サポートされています。
-
false:サポートされていません。
例えば、
CHARデータ型はデフォルト値をサポートしていますが、TEXTデータ型はサポートしていません。@fac.index_kind
テーブルスキーマ内のインデックスタイプです。有効な値:
-
new:新規インデックス。
-
old:既存インデックス。
@fac.index_column_count
インデックスに含まれるフィールド数です。
@fac.change_type
DDL 文を実行するデータベースが識別したフィールドまたはインデックスの変更タイプです。有効な値:
-
add
-
modify
-
delete
@fac.altered_table_size
変更されたテーブルのサイズ (MB) です。
@fac.online_execute
変更をオンラインで実行できるかどうかを示します。有効な値:
-
true:ONLINE
-
false:NOT ONLINE
@fac.change_risk_level
変更のリスクレベルです。有効な値:
-
high:高リスク
-
medium:中リスク
-
low:低リスク
@fac.env_type
環境タイプは、
DEVやPRODUCTなどの環境識別子です。 環境タイプの詳細については、「インスタンスの環境タイプを変更する」をご参照ください。 -
-
アクション: アクションとは、チケットの提出の禁止、ワークフローの選択、実行の許可、実行の拒否など、
if条件が満たされた後にシステムが実行する動作です。これらのアクションは、セキュリティルールの主な目的を定義します。すべてのアクションは@act.で始まり、その後にアクション名が続きます。各モジュールは、チェックポイントごとに異なるアクションを提供します。次の表では、[スキーマ設計] で使用できるアクションについて説明します。アクション
説明
@act.block_submit
テーブルの保存段階で送信をブロックし、エラーメッセージを表示します。 使用方法:
@act.block_submit 'ブロックする理由'。@act.show_warning
テーブルの保存段階で使用されます。送信をブロックせずに警告メッセージを表示します。使用方法:
@act.show_warning 'Warning content'。@act.mark_middle_risk
リスク識別段階で使用され、変更を中リスクとしてマークします。使用方法:
@act.mark_middle_risk 'Reason'。@act.mark_high_risk
リスク識別段階で使用します。変更をハイリスクとしてマークします。使用方法:
@act.mark_high_risk 'Reason'。@act.forbid_submit_publish
承認プロセスの設定段階で使用されます。変更の実行をブロックします。使用方法:
@act.forbid_submit_publish 'Reason'。@act.do_not_approve
Specifies the ID of an approval template. For more information, see Set the approval process.
@act.choose_approve_template
@act.choose_approve_template_with_reason
テンプレートライブラリ
セキュリティルールは、直接有効化できる、または有効化する前に変更できるルールテンプレートを多数提供しています。次の表に、[スキーマ変更] のテンプレートを示します。
|
チェックポイント |
テンプレート |
|
[Save and Edit - Check Table Header] |
新規テーブル名にキーワードを使用することを禁止 |
|
新規テーブルの名前の長さを制限 |
|
|
新規テーブルにコメントを必須化 |
|
|
新規テーブルの名前を小文字にすることを必須化 |
|
|
新規テーブルにプライマリキー (PK) を必須化 |
|
|
新規テーブルに一意キー (PK/UK) を必須化 |
|
|
インデックス数をチェックし、過剰な場合はユーザーに警告 |
|
|
新規テーブルに特定のフィールドが存在するかどうかをチェック |
|
|
[Save and Edit - Check Field] |
新規フィールド名にキーワードを使用することを禁止 |
|
新規フィールドにコメントを必須化 |
|
|
新規フィールド名の大文字と小文字の区別を指定 |
|
|
既存テーブルに NOT NULL フィールドを追加する場合、デフォルト値を必須化 |
|
|
既存フィールドを NULL 許容から NULL 非許容に変更する場合、デフォルト値を必須化 |
|
|
新規プライマリキーフィールドを整数型にすることを必須化 |
|
|
新規テーブル内のすべてのフィールドを NULL 非許容にすることを必須化 |
|
|
CHAR 型の新規フィールドの長さを制限 |
|
|
VARCHAR 型の新規フィールドの長さを制限 |
|
|
[Save and Edit - Check Index] |
新規インデックス名にキーワードを使用することを禁止 |
|
新規インデックス名の大文字と小文字の区別を指定 |
|
|
新規一意のインデックス名のフォーマットを制限 |
|
|
新規通常インデックス名のフォーマットを制限 |
|
|
新規 FULLTEXT インデックス名のフォーマットを制限 |
|
|
新規空間インデックス名のフォーマットを制限 |
|
|
新規プライマリキーフィールド数を制限 |
|
|
新規インデックスフィールド数を制限 |
|
|
[テーブル作成リスクの制御] |
論理テーブルのシャード数を制御 |
|
テーブルのプライマリキーを制御 |
|
|
テーブル内のインデックス総数を制御 |
|
|
[フィールド変更リスクの制御] |
フィールドの削除を制御 |
|
新規フィールドのデータ型を制御 |
|
|
フィールドの名前変更を制御 |
|
|
フィールドのデータ型変更を制御 |
|
|
[インデックス変更リスクの制御] |
プライマリキーの削除を制御 |
|
インデックスの削除を制御 |
|
|
プライマリキーからインデックスへの変更を制御 |
|
|
プライマリキーのカラム変更を制御 |
|
|
通常インデックスの変更を制御 |
|
|
新規インデックスのタイプを制御 |
|
|
[SQL 実行リスクの制御] |
コアインスタンスのリスクを制御 |
|
テーブルのストレージエンジンを制御 |
|
|
テーブルロックまたは大規模なテーブルスキーマ変更のリスクを制御 |
|
|
[Approval Rule Check] |
データベースへのすべての DDL 変更の適用を禁止 |
|
本番データベースへのすべての DDL 変更の適用を禁止 |
|
|
テストデータベースに対して承認不要の DDL 変更を設定 |
|
|
本番環境のリスクレベルに基づいて承認ルールを設定 |
デフォルト承認テンプレートの変更
DMSコンソールV5.0 にログインします。
左上隅にある
アイコンにポインターを移動し、 を選択します。説明DMS コンソールを通常モードで使用している場合は、上部のナビゲーションバーで を選択します。
-
[セキュリティルール] ページで、対象のルールセットを見つけ、[アクション] 列で [編集] をクリックします。
-
[詳細] ページの左側のナビゲーションペインで、[スキーマ設計] をクリックします。
-
[スキーマ設計] タブで、[基本設定] をクリックします。
-
[スキーマ設計のデフォルト承認テンプレート] を見つけ、[アクション] 列で [編集] をクリックします。
-
[設定項目を編集] ダイアログボックスで、[承認テンプレートの切り替え] をクリックします。
-
[テンプレート名] で対象のテンプレートを見つけ、[アクション] 列で [選択] をクリックします。
説明[承認なしにリセット] をクリックして、チケットが承認プロセスをスキップできるようにすることもできます。
-
[送信] をクリックします。
新しいルールの追加
DMSコンソールV5.0 にログインします。
左上隅にある
アイコンにポインターを移動し、 を選択します。説明DMS コンソールを通常モードで使用している場合は、上部のナビゲーションバーで を選択します。
-
[セキュリティルール] ページで、対象のルールセットを見つけ、[アクション] 列の [編集] をクリックします。
-
[詳細] ページの左側のナビゲーションウィンドウで、[スキーマ設計] をクリックします。
-
[スキーマ設計] タブで、[アクション] の右側にある [ルールの追加] をクリックします。
-
[ルールの追加 - スキーマ設計] ダイアログボックスで、次のパラメーターを設定します。
パラメーター
説明
[チェックポイント] (必須)
新しいルールのチェックポイントを選択します。スキーマ設計には複数のチェックポイントがあります。詳細については、「チェックポイント」をご参照ください。
[テンプレートライブラリ] (オプション)
テンプレートライブラリには、多くのルールテンプレートが用意されています。[チェックポイント] を選択すると、[テンプレートライブラリ] からルールテンプレートを読み込むことができます。利用可能なテンプレートの一覧については、「テンプレートライブラリ」をご参照ください。
[ルール名] (必須)
ルールのカスタム名。[テンプレートライブラリ] からルールテンプレートを選択した場合、このフィールドは自動的に入力されます。
[ルール DSL] (必須)
ルール DSL を入力します。DSL 構文の詳細については、ドキュメントをご参照ください。([テンプレートライブラリ] でルールテンプレートを選択した場合、このフィールドは自動的に入力されます。)
-
[送信] をクリックします。
-
デフォルトでは、新しいルールは [無効] 状態です。ルールを見つけ、[アクション] 列の [有効化] をクリックします。
-
表示されるダイアログボックスで、[OK] をクリックします。