データベース設計：データベース内のエンティティ間の関係を定義する

Question

私のアプリケーションのデータベースを設計したいと思います。エンティティ間の関係を定義する方法について質問があります。

私はIDが化合物である2つの関連するエンティティを持っています。例えば：

• 特性によって識別されるアドレスエンティティ[街路番号、家の番号、都市、国]、および電話番号（XX-YYYYYY）
• 特性によって識別されたエンティティ[地域番号、番号]。 。

関係は、各アドレスについて、いくつかの電話番号がある」である私は、テーブルを定義するには2つの方法があります：すべてのIDフィールドで

• アドレスを接続
  1. テーブルを→ [街路番号、住宅番号、市町村、国名、地域番号、番号]
  2. 電話番号→ [地域番号、番号、...]

このフィールドで接続されたIDフィールド（GUID）を持つテーブル。

• 住所→ [ID、街路番号、家屋番号、市、国、...、]
• のPhoneNumber → [ID、領域番号、番号、...、あるAddressId]

第1の解決策では、プライマリキーはエンティティを識別するすべてのフィールドになり、第2のソートではプライマリキーはIDフィールドのみになります。

私の質問は - より良い方法は何ですか？

Answer 1

（パフォーマンス、maintanance、デザイン、等...で）主キーは「テーブル内のすべてのフィールド」になることはありませんます。これは、リレーショナルデータベースがどのように動作するのかということではないので、そのアプローチを忘れてしまいます。

キーはキーであり、データはデータです。 2人を混ぜ合わせることは決してありません。それらを混在させると、キーと、データが変更されるとすぐにそれを使用するデータベース内のすべてのレコードを変更する必要が生じます。どちらが悪いですか。

のみ適切これを設計する方法（共通）1：nの関係は：

 
Address    PhoneNumber 
-------    ----------- 
*ID   <---+  *ID 
StreetNumber +--- AddressID 
HouseNumber   RegionNumber 
City     TheNumber 
Country    ... 
... 

*は主キー、その上に一意のインデックスを持つ典型的自動インクリメント数を表します。

矢印は外部キーの関係を示します。

Answer 2

G UIDのいずれであっても、コード化とデザインが容易です。 2つのテーブルを結合してデータを選択する場合は、インデックス付きの識別子列のみが必要です。 これ以外の方法では、この結合だけの複合インデックスが必要です。

エンタープライズ企業システムのテーブルに一意のプライマリキーを持つことは、私の経験では貴重な練習です。 （dbaと開発者の両方の観点から）

パフォーマンスのためのデータベースの設計は、多くの基準を含む複雑な問題です。実際には2つの方法でOracleを手にして、説明計画ツールを使用している場合は、理論を踏襲してください。私はあなたの言及したアプローチでテーブルを作成し、インデックスで遊んで、説明計画を使用することを意味します。私が誤解していない場合でも、Oracleは投影によるクエリのパフォーマンスについての考え方を提供します（つまり、テーブルの行数を見積もることによって）。私はExpress Editionのバージョンがこのサポートを持っているのか分かりません