0

私は住宅ローン/ローンデータベースを作成しています - フィールドを持つ住宅ローンと呼ばれるテーブルがあります:

  • 住宅ローン_id
  • クライアントID
  • *rate_type* (固定またはトラッカー) ...など

rate_type の選択に応じて、それに続くフィールドが異なります。たとえば、固定利率タイプの住宅ローンが選択されている場合、ユーザーはその固定利率のみを入力します。トラッカー モーゲージの場合は、トラック レート (例: +0.90%) とベース レート (トラッキングされている) (例: 0.50%) が必要です [調整されたレート = 1.40% を与える]。

私の質問は次のとおりです。これに正しいテーブル/フィールド構造を実装するにはどうすればよいですか。理想的には、すべてのフィールドを持ちたくありません (強調表示):

  • 住宅ローン_id
  • クライアントID
  • rate_type
  • 固定レート
  • track_rate
  • 基準率

混乱を招きかねないからです。これらを他のテーブルに分ける方法はありますか? おそらく、1 対 1 の関係を持つ rate_details (固定用とトラッカー用) を持つ別のテーブルでしょうか?

4

5 に答える 5

1

あなたが持っているのは、追加のサブタイプ固有の属性を提供する、それぞれが 0 または 1 つのサブタイプのインスタンスである、共通の属性セットを提供するタイプ (住宅ローン) を持つ ER モデルです。で私の答えを見てください

派生概念 - データベース設計の考慮事項

と

UNION に依存するように SQL Server データベースを設計する必要がありますか?

これを解決する方法について。

タイプ/サブタイプ モデル

于 2011-11-02T20:58:24.380 に答える
1

あなたの質問に基づいて、3 つのテーブルを作成できることをお勧めします。

基本情報 1、固定料金の詳細を格納するテーブル、および基本料金の詳細を格納するテーブル。

tbl住宅ローン:

住宅ローンID | クライアント ID | 料金タイプ

tblFixedRates:

ID | 住宅ローンID | 固定レート

tblTrackerRates:

ID | 住宅ローンID | track_rate、base_rate

于 2011-11-02T20:48:04.977 に答える
0

同じテーブルに3つの列すべてを含めることは有効ですが、必要に応じて1つまたは2つの列のみを使用してください。3つの列はすべてNULL可能にすることができます。

もう1つの方法は、どちらのタイプのレートタイプにも2列を使用しますが、固定レートを処理する場合は、列の1つを0に設定します。2つのレートを加算して合計追跡レートを算出するため、固定レートに0を加えた値が固定レートになります。

[dbo].[theTable]
   [mortgage_id],
   [client_id],
   [rate_type],
   [base_rate],
   [rate]       // or whatever generic name is appropriate

したがって、[rate_type]がtrackの場合、

[base_rate] = 0.50%
[rate] = 0.90%

total = 1.40%

しかし、[rate_type]が修正されると、

[base_rate] = 0%
[rate] = 0.70%

total = 0.70%
于 2011-11-02T20:56:08.707 に答える
0

FOREIGN KEYSQL制約を使用して達成できる最善の方法は、各住宅ローンの種類が各サブタイプテーブルに最大で1回表示されるようにすることです。必要に応じて、1対0または1の関係になります。この制約を適用する1つの方法は{ ID , type }、スキーマ全体で使用される2列の複合キーを使用しtype、サブテーブル制約でテストできるようにすることです。これは、2つの住宅ローンのサブタイプを使用した大まかなスケッチです（中括弧は、暗黙の順序のないリストを示します）。

Mortgages { mortgage_ID , mortgage_type } 
   KEY { mortgage_ID } 
   KEY { mortgage_ID , mortgage_type }
   CONSTRAINT mortgage_type = 'Tracker'
              OR mortgage_type = 'Fixed'

FixedRateMortgages { mortgage_ID , mortgage_type , fixed_rate }
   KEY { mortgage_ID , mortgage_type }
   FOREIGN KEY { mortgage_ID , mortgage_type } REFERENCES Mortgages
   CONSTRAINT mortgage_type = 'Fixed';

FixedRateMortgages { mortgage_ID , mortgage_type , base_rate , track_rate }
   KEY { mortgage_ID , mortgage_type }
   FOREIGN KEY { mortgage_ID , mortgage_type } REFERENCES Mortgages
   CONSTRAINT mortgage_type = 'Tracker';

Clients { client_ID } 
   KEY { client_ID } ;

Agreements { mortgage_ID , mortgage_type , client_ID }
   KEY { mortgage_ID , mortgage_type , client_ID }
   FOREIGN KEY { mortgage_ID , mortgage_type } REFERENCES Mortgages
   FOREIGN KEY { client_ID } REFERENCES Client;

SQL製品を指定していません。厳密な1対1の参照整合性は、サブタイプテーブルロジックごとにこの「分散」されたものをカプセル化するようにCREATE ASSERTION宣言された制約を使用して、標準SQL-92で維持できます。DEFERRABLE INITIALLY DEFERRED次に、SQLステートメントは、トランザクションでASSERTIONsを延期し、参照テーブルと参照テーブルを変更してから、ASSERTIONsを再適用できます（またはトランザクションをコミットすることでこれを自動的に実行します）。残念ながら、をサポートする実際のSQL製品はありませんCREATE ASSERTION。ベンダーに応じて回避策があります。たとえば、トリガー、行レベルのCHECK制約から呼び出されるSQL関数のテーブル式、テーブルからの書き込み権限の取り消し、参照整合性を保証するCRUDプロシージャを介したテーブルの更新をユーザーに強制するなどです。

とは言うものの、SQLでは通常1対0または1の関係を持つことが許容され、実際にそうすることには利点があります。たとえば、データベースの制約を記述しやすくする（したがってバグを減らす）、ユーザーを強制しない柔軟性1セットの手順などを使用します。

于 2011-11-03T09:31:55.937 に答える
0

他の人が示唆したように、私のアドバイスは FixedRateMortgages と TrackerRateMortgages の 2 つのサブテーブルで、主キーとして MortgageID を持ち、メインの Mortgages テーブルに戻る外部キーとしても使用します。

これにより、1 対 1 が保証されますが、住宅ローンが 2 つのサブテーブルの 1 つにのみ存在する必要はありません。これは、データベースがうまく適用できない制約であり、ここで話している参照整合性ではありません。サブテーブルでトリガーを使用して、他のサブテーブルに存在しない住宅ローンのみが挿入されるようにすることができますが、トリガーはかなり醜いです。私はおそらく、データベースではなく、アプリケーション層 (つまりコード) でその不変条件を強制することに固執するでしょう。

于 2011-11-02T21:05:39.290 に答える