4

現在SQLの割り当てを行っていますが、作成したデータベースのテーブルに妥当性確認と検証を実装する必要があるという特定のタスクがあります。

ただし、このトピックについては何も学びませんでした。何時間もグーグルした後、createtableステートメントで指定できるチェック制約しか見つかりませんでした。

SQLテーブルまたはデータベースの妥当性確認と検証の手法のいくつかに言及してください。

4

3 に答える 3

9

通常、データに対して何らかのテストを実行して検証します。

データが通過するさまざまなレイヤーがあり、さまざまなタイプのテストがあります。

次のシステムレイヤーを検討する場合：

  • ユーザーインターフェイス/クライアントレイヤー
  • アプリケーション層
  • データベース層

これらのレイヤーのいずれかでデータ検証を行うことができますが、次の違いがあります

  • 異なるアプリケーションを同じデータベースに接続できるため、データベースレイヤーでの検証が推奨されます。これは良いことですが、それらのアプリケーションでの検証は必ずしも同じではないため、データベースレイヤーで実装される検証の方が優れています。データの整合性
  • 同時に、データベースレイヤーはデータに最も近いため、データベースレイヤーでの検証が最も高速になります（データは他のレイヤーを通過して処理される必要はありません。この場合は検証されます）。
  • 例外は、検証ルールが静的であり、データベースの他のデータに依存しない場合（たとえば、入力が正の整数であるかどうかのテスト）、クライアントはデータベースの前にデータを検証し、アプリケーション層に不必要なタスクを実行することを回避できます。またはデータベース層。（同時に、バグがある場合や他のアプリケーションがデータベースに接続する場合に備えて、データベース層でも検証を実装する必要があります）。同じ原則がアプリケーション層にも当てはまります。アプリケーション層がデータベースサーバーにアクセスせずに実行できる検証がある場合は、それを実行する必要がありますが、データベース層でも同じことを実行（保証）する必要があります。

以下を検証テスト（検証タイプ）と見なすことができます。

  • 型の検証（例：挿入されるデータは整数ですか？）。これは、列で適切なタイプを宣言することにより、データベース層で確認できます。）
  • ドメイン検証（例：データは正の整数ですか？）これは、CHECK制約を使用してデータベース層でチェックできます。
  • 関係の検証（例：追加するレコードの場合、別のテーブルにすでにレコードがあります）。これは、外部キーを適切に使用することにより、データベース層で確認できます。
  • ビジネスルールの検証（たとえば、記録しようとしている値が100を超える場合は、ユーザーのIPを記録できることを確認してください。そうでない場合は、トランザクションをキャンセルしてください。気にしない場合は、 '）これらの種類検証は、トリガーとストアドプロシージャを介して実行できます。実際のビジネスルールでは、検証はアプリケーション層で実装されることがよくあります（さまざまな理由で、PL / SQLの相対的な非保守性と非移植性（通常はトリガーを記述しなければならない言語）から、実装するという事実まで）複雑なトリガーはパフォーマンスを低下させ、最終的にシステムを非常に複雑にする可能性があります）。
于 2010-11-05T12:31:17.887 に答える
2

教師からの仕様に基づいて作成したスキーマが実際に機能することを確認する必要があります。検証は、別の手段を使用して何かをテストするプロセスです。だから...悪いデータを挿入しようとする小さな検証プログラムを書いてください。いくつかのテストケースを作成します。スキーマ設計が検証に合格すると、検証または検証されたと言えます。

于 2010-11-05T12:00:23.430 に答える
1

区別する必要がvalidationありverificationます。フォーマル検証の概念に従っていると仮定します。

検証：「私たちは正しいものを作ろうとしていますか？」、つまり、製品はユーザーの実際のニーズに合わせて指定されていますか？

検証：「私たちが作ろうとしていたものを作りましたか？」、つまり、製品は仕様に準拠していますか？

まず、特定のシナリオで両方の定義が必要です。たとえば、会社の従業員情報を保存するテーブルスキーマがあります。

Employee

ID | Name | Age | Salary

たとえば、すべての従業員が一意のIDを持っているとします（これがゼロになることはありません）。ID=0次に、が無効なレコードである行を定義できます。（ユーザーのニーズに合わせて）

すべてのレコードをテーブルに挿入した後は、。を含む行がないはずID=0です。SELECT * from Employee WHERE ID=0行が返されないはずのクエリで確認できます。（私たちはそれを作りましたか？）

于 2019-12-23T07:29:35.600 に答える