MSSQL2005で会社の電話リストを設定しようとしています。
私が持っている現在のスキーマは機能しますが、「EmployeeCompany」という名前のEmployeeテーブルに列を追加し、Departmentの「CompanyName」列からプルさせたいと思います。
DepartmentテーブルのCompanyNameがPKでない場合、これら2つの列をどのようにリンクしますか?
どんな助けでも大歓迎です。
ありがとう、CJ
MSSQL2005で会社の電話リストを設定しようとしています。
私が持っている現在のスキーマは機能しますが、「EmployeeCompany」という名前のEmployeeテーブルに列を追加し、Departmentの「CompanyName」列からプルさせたいと思います。
DepartmentテーブルのCompanyNameがPKでない場合、これら2つの列をどのようにリンクしますか?
どんな助けでも大歓迎です。
ありがとう、CJ
company_id
部門テーブルには、キーではなくキーであるを保存しますcompany name
。
従業員の会社を照会する場合は、次のようにします。
SELECT
LastName,
FirstName,
CompanyName
FROM
Employee
INNER JOIN Department ON employee.department_id = department.department_id
INNER JOIN Company ON department.company_id = company.company_id
ケース1-IDを使用する
ケース2-自然な複合キー
従業員の部門を知っていて、部門の会社を知っている場合は、従業員の会社も知っています。これをSQLで単純なJOINとして表現できます。また、クライアントコードを単純化したい場合は、このJOINをVIEWの背後に「隠す」こともできます。
原則として、特定のパフォーマンスの問題を解決しようとしているのでない限り、推測できるデータは保存しないでください。
この考え方を分解してみましょう。
ただし、参照整合性が属性を移行するという事実を「悪用」することにより、冗長性と整合性の両方を実現する方法があります。ダミールの答えの「ケース2」は、ある方法を説明しています。別の方法を提供させてください。
ご覧のとおり、外部キー(FKx
上の図)は主キーを参照する必要はありません。代替キー(Ux
)を参照することもできます。これにより、をそれぞれのテーブルの主キーとして保持Company_id
し、モデル3の残りの部分を邪魔することを回避できます。Department_id
1同じことを説明するデータが2つあり、一方が更新された場合、もう一方を更新することを忘れてしまう可能性が常にあります(たとえば、アプリケーションのバグが原因です)。答えの下部で説明されているように、DBMS自体にそれを実行させることができない限り。
2過剰なJOINや高価な集計など。
3つまり、会社または部門を参照する可能性のある他のテーブル。
CompanyId(主キー)とCompanyNameの2つの列を持つCompanyという3番目のテーブルを作成します。次に、CompanyIdをDepartmentの外部キーとして使用し、次にDepartmentIdをEmployeeの外部キーとして使用します。