リレーショナル データベースでデータの独立性がどのように確保されているか説明できる人はいますか? データベースの構造が変わっても、ユーザーにとって何も変わらないというのはどういうことですか?
たとえば、リレーション R があり (このリレーションを使用するアプリケーションを作成しました)、データベース管理者が R を R1 と R2 に分解することにしました。エンドユーザーにとってアプリケーションの不変性はどのように保証されますか?
リレーショナル データベースでデータの独立性がどのように確保されているか説明できる人はいますか? データベースの構造が変わっても、ユーザーにとって何も変わらないというのはどういうことですか?
たとえば、リレーション R があり (このリレーションを使用するアプリケーションを作成しました)、データベース管理者が R を R1 と R2 に分解することにしました。エンドユーザーにとってアプリケーションの不変性はどのように保証されますか?
データベースのクラスで、まったく同じ質問を自問しました。
Codd の 12 の規則によると、データの独立性には次の 2 種類があります。
あなたの質問はあまり明確に表現されていません。「データの独立性」と「アプリケーションの不変性」の関係がわかりません。
適切なリレーショナル構造は、データをエンティティと関係に分解します。考え方としては、値が変更されると、1 つの場所だけが変更されるということです。これが、データのさまざまな「通常の形式」の背後にある理由です。
ほとんどのユーザー アプリケーションは、データを正規化された形式で表示することを望んでいません。多くの場合、多くのフィールドが 1 行にまとめられた、非正規化された形式でデータを表示したいと考えています。同様に、更新にはさまざまなエンティティの複数のフィールドが含まれる場合がありますが、ユーザーにとっては 1 つのことです。
リレーショナル データベースは、データの構造を維持し、さまざまな観点からデータを組み合わせることができます。それはあなたの2番目のポイントとは何の関係もありません。アプリケーションの独立性 (これは「不変性」よりも適切な言葉だと思います) は、アプリケーションの設計方法に依存します。適切に設計されたアプリケーションには、適切に設計されたアプリケーション プログラミング インターフェイス(API とも呼ばれます) があります。
多くのデータベース開発者は、物理的なデータ構造が API として十分であると考えているようです。ただし、これは多くの場合、設計上の決定として不適切です。多くの場合、より適切な設計上の決定は、ストアド プロシージャ、ビュー、およびユーザー定義関数を使用してすべてのデータベース操作を実行することです。つまり、テーブルを直接更新しないでください。フィールドを取得してテーブルを更新する usp_table_update という名前のストアド プロシージャを作成します。
このような構造を使用すると、基礎となるデータベース構造を変更すると同時に、ユーザー アプリケーションを保守できます。
データベース構造が変更されても、ユーザーにとって何も変わらないということは何ですか?
データベース構造は、さまざまな理由で変更される可能性があります。大まかに言えば、次の 2 つの可能性があります。
@1: この場合、DBA はパフォーマンスのために何らかの構造を変更することを決定しました。または ... その場合、たとえばストアド プロシージャ、ビューなどを使用する追加のレイヤーは、アプリケーション/ユーザーへの変更を「隠す」のに役立ちます。 . または、アプリケーション側の優れたデータ層が役立つ場合があります。
@2: 外の世界が変わったり、ビジネス ルールが変わったりした場合、データベース レベルでできることは何もなくても、それをユーザーから遠ざけることはできません。たとえば、データベースで常に 1 つの通貨のみを使用していた会社が突然国際化する場合があります。その場合、データベースは複数の通貨をサポートするように採用する必要があり、データベースとユーザーのために深刻な変更が必要になります。
たとえば、私はリレーション R (およびこのリレーションを使用するアプリケーションを作成) を持っており、データベース管理者は R を R1 と R2 に分解することを望んでいます。エンドユーザーにとってアプリケーションの不変性はどのように保証されますか?
管理者は、元のR1
とを表すビューを作成する必要があります。R2
R