La "festa" del tavolo non sembra a posto. Confronta con il codice sorgente di quest'altra domanda SO .
In questo tipo di struttura, il numero ID del partito si propaga verso il basso, per così dire. Di solito dovrebbe essere una chiave primaria o una chiave esterna nelle tabelle che memorizzano i dati su una persona.
Nella tabella "reporting", sembra che la chiave primaria non debba essere "partyid". Ciò consentirebbe solo una riga per dipendente, cosa che non penso tu intendessi. (Potrei sbagliarmi.) Se ho ragione, potresti considerare un NOT NULL UNIQUE vincolo su {partyid, date} e una PRIMARY KEY vincolo su una nuova colonna, 'reportid'. Le tabelle "travel" e "performance" farebbero probabilmente riferimento a "reportid". (Ma continua a leggere.)
Ci sono punti nel tuo diagramma in cui un'entità ottiene una chiave aggiuntiva:la tua azienda assegna un numero ID univoco ai suoi dipendenti, ad esempio. Non c'è alcun motivo teorico per cui non puoi usare "employid" invece di "partyid" da quel momento in poi per fare riferimento ai dipendenti. Ma c'è un motivo pratico per cui potresti non volerlo fare. Aumenta il numero di join.
Ad esempio, se le tabelle "credential", "tool", "certification", "academic" e "compliance" facevano riferimento a employee.employid invece di employee.partyid, non puoi semplicemente unire "compliance" e "party" a ottenere il nome della persona. Dovresti anche unirti a "dipendente".
Devono avere una chiave primaria; la chiave primaria non deve necessariamente essere un numero ID. Se esiste una chiave naturale esistente, devi identificarla e dichiararla comunque UNICA.
La tabella "orders" dovrebbe probabilmente avere solo "orderid" come chiave primaria; utilizzare un riferimento di chiave esterna per identificare il cliente. In alcuni casi, ha senso rinominare le colonne. Nel caso dei clienti, potrebbe avere senso chiamare la sua chiave "customerid" invece di "paritid". Creerei un dominio io stesso.
create domain PARTY_ID as integer not null;
Quindi, ovunque fosse necessario un numero ID della parte, userei invece il dominio.
create table customers (
customerid PARTY_ID primary key references parties (partyid),
...
Preferirei vedere anche un tavolo di manager. Un riferimento ad esso garantirebbe che manager.managerid risolverebbe un vero manager, non solo un dipendente qualsiasi.
