テーブル「パーティー」は正しく見えません。 この他のSOの質問 。
この種の構造では、パーティID番号は、いわば下向きに伝播します。通常、個人に関するデータを格納するテーブルの主キーまたは外部キーのいずれかである必要があります。
テーブル「reporting」では、主キーを「partyid」にしないでください。これでは、従業員ごとに1行しか許可されませんが、これは意図したものではないと思います。 （私は間違っている可能性があります。）私がそれについて正しければ、NOT NULL UNIQUEを検討するかもしれません。 {partyid、date}、およびPRIMARY KEYに対する制約 新しい列の制約'reportid'。テーブル「travel」と「performance」は、おそらく「reportid」を参照します。 （しかし、読み続けてください。）
ダイアグラムには、エンティティが追加のキーを取得する場所があります。たとえば、会社は一意の従業員ID番号を従業員に割り当てます。その時点から、従業員を参照するために「partyid」の代わりに「employid」を使用できないという理論上の理由はありません。しかし、 あなたがそれをしたくないかもしれない実際的な理由。結合の数が増えます。
たとえば、テーブル「credential」、「tool」、「certification」、「academic」、および「compliance」がemployee.partyidではなくemployee.employidを参照している場合、「compliance」と「party」を単に結合することはできません。人の名前を取得します。あなたも「従業員」に参加する必要があります。
主キーが必要です。主キーは必ずしもID番号である必要はありません。既存の自然キーがある場合は、それを識別して、とにかく一意であると宣言する必要があります。
テーブル「orders」は、おそらく主キーとして「orderid」のみを持つ必要があります。外部キー参照を使用して顧客を識別します。場合によっては、列の名前を変更することが理にかなっています。顧客の場合、そのキーを「parytid」ではなく「customerid」と呼ぶのが理にかなっているかもしれません。自分でドメインを作成します。
create domain PARTY_ID as integer not null;
次に、パーティID番号が必要な場所では、代わりにドメインを使用します。
create table customers (
customerid PARTY_ID primary key references parties (partyid),
...
私もマネージャーのテーブルを見たいです。これを参照すると、manager.manageridが、従業員だけでなく実際のマネージャーに解決されることが保証されます。