Bordet "fest" ser inte bra ut. Jämför med källkoden från denna andra SO-fråga .
I den här typen av struktur sprider sig partiets ID-nummer nedåt, så att säga. Det ska vanligtvis vara antingen en primärnyckel eller en främmande nyckel i tabeller som lagrar data om en person.
I din tabell "rapportering" ser det ut som att primärnyckeln inte ska vara 'partyid'. Det skulle bara tillåta en rad per anställd, vilket jag inte tror att du avsåg. (Jag kan ha fel.) Om jag har rätt i det kan du överväga en NOT NULL UNIQUE begränsning på {partyid, date} och en PRIMARY KEY begränsning på en ny kolumn, 'reportid'. Tabellerna "resor" och "prestanda" skulle förmodligen referera till "rapportid". (Men fortsätt läsa.)
Det finns platser i ditt diagram där en enhet får en extra nyckel:ditt företag tilldelar till exempel ett unikt medarbetar-ID till sina anställda. Det finns ingen teoretisk anledning till att du inte kan använda 'employid' istället för 'partyid' från den tidpunkten för att referera till anställda. Men det finns en praktisk anledning till att du kanske inte vill göra det. Det ökar antalet anslutningar.
Till exempel, om tabellerna "credential", "tool", "certification", "academic" och "compliance" refererade till anställd.anställd istället för anställd.partyid, kunde du inte bara gå med i "efterlevnad" och "fest" till få personens namn. Du måste också gå med i "anställd".
De måste ha en primärnyckel; primärnyckeln behöver inte nödvändigtvis vara ett id-nummer. Om det finns en befintlig naturlig nyckel måste du identifiera den och förklara den UNIK ändå.
Tabellen "order" bör förmodligen bara ha "orderid" som sin primära nyckel; använda en främmande nyckelreferens för att identifiera kunden. I vissa fall är det vettigt att byta namn på kolumner. När det gäller kunder kan det vara vettigt att kalla dess nyckel för 'customerid' istället för 'parytid'. Jag skulle skapa en domän själv.
create domain PARTY_ID as integer not null;
Sedan, överallt som behövde ett parti-ID-nummer, skulle jag använda domänen istället.
create table customers (
customerid PARTY_ID primary key references parties (partyid),
...
Jag skulle föredra att se en tabell med chefer också. En hänvisning till det skulle garantera att manager.managerid skulle lösas till en verklig chef, inte bara till vilken anställd som helst.