次の原則について読んだことがあります。「データベース スキーマでは、すべてのデータ要素に一意の名前を付ける必要があります」(http://bytes.com/topic/sql-server/answers/439341-name-keyword) どのように強制しますか?
通常の手法では、列の意味のある名前の前に 3 文字の省略形を配置します。したがって、Employee.Name は Emp_Name になります。ここまでは順調ですね。ただし、Employer.Name も Emp_Name にする必要があります。したがって、ほとんど意味のない雇用主の不可解な略語を考え出さなければなりません。「Eml」としましょう。そして、スキーマが大きくなるにつれて、衝突を避けるためにより多くの努力が必要になります。
私の意見では、適切な妥協点は、常に適切なプレフィックスを使用することです。このようにして、雇用者の「Eml」のような直感的でない略語を使用せずに、衝突のほとんどを回避します。
すべてのデータ要素が一意の名前を持つという要件は、すべての列が一意の名前を持つと解釈されるべきではありません。
特に、外部キーは、参照しているテーブルに基づいて同じ名前を持つ必要があります。したがって、CustomerIDどこで発生しても同じことを意味します。テーブルへの主キーへの参照になりCustomerます。また、テーブルの主キーを と呼びますが、CustomerID単に と見なすこともありますID。
重複した名前で問題ない場合もあります。私が作成するすべてのテーブルには、各行にメタデータがあり、いつ、誰が行を作成したかを説明しています。これらはそれぞれ と と呼ばCreatedAtれCreatedByます。これらはすべてのテーブルにありますが、論理データ モデルの一部ではありません。
頭に浮かぶ重複した名前の別のケースは、ゆっくりと変化するディメンションの有効日と終了日です。通常、これらを一意にしようとするよりも、単にEffDateand (または何でも) と呼ぶ方が簡単です。EndDate
最後に、複数のステージング テーブルを含むデータ フロー メソッドを使用して多くの処理を行います。追跡のために、意図的に列名を同じにしています。
ただし、質問に対する答えは、テーブルに関連するプレフィックスを使用することです。そのテーブルに固有のデータ要素には短いプレフィックスを付けることができるため、それらが何であるかがわかります。たとえば、Cust_NameとAddr_Cityは、customer テーブルの顧客名と address テーブルの都市名に適した名前です。