Bordet "fest" ser ikke rigtigt ud. Sammenlign med kildekoden fra dette andet SO-spørgsmål .
I denne form for struktur forplanter partiets id-nummer sig så at sige nedad. Det skal normalt være enten en primærnøgle eller en fremmednøgle i tabeller, der gemmer data om en person.
I din tabel "rapportering" ser det ud til, at den primære nøgle ikke skal være 'partyid'. Det ville kun tillade én række pr. medarbejder, hvilket jeg ikke tror, du havde til hensigt. (Jeg kan tage fejl.) Hvis jeg har ret i det, kan du overveje en NOT NULL UNIQUE begrænsning på {partyid, date} og en PRIMARY KEY begrænsning på en ny kolonne, 'rapportid'. Tabellerne "rejse" og "performance" vil sandsynligvis referere til "rapportid". (Men fortsæt med at læse.)
Der er steder i dit diagram, hvor en enhed får en ekstra nøgle:din virksomhed tildeler f.eks. et unikt medarbejder-id-nummer til sine medarbejdere. Der er ingen teoretisk grund til, at du ikke kan bruge 'employid' i stedet for 'partyid' fra det tidspunkt til at referere medarbejdere. Men der er en praktisk grund til, at du måske ikke ønsker at gøre det. Det øger antallet af joinforbindelser.
Hvis f.eks. tabellerne "legitimationsoplysninger", "værktøj", "certificering", "akademisk" og "overholdelse" refererede til ansat.ansættelsesid i stedet for medarbejder.partyid, kunne du ikke bare tilslutte dig "overholdelse" og "fest" til få personens navn. Du skal også slutte dig til "medarbejder".
De skal have en primær nøgle; den primære nøgle behøver ikke nødvendigvis at være et id-nummer. Hvis der er en eksisterende naturlig nøgle, skal du identificere den og erklære den UNIK alligevel.
Tabellen "ordrer" bør sandsynligvis kun have "orderid" som sin primære nøgle; bruge en fremmednøglereference til at identificere kunden. I nogle tilfælde giver det mening at omdøbe kolonner. I tilfælde af kunder, kan det være fornuftigt at kalde dens nøgle 'customerid' i stedet for 'parytid'. Jeg ville selv oprette et domæne.
create domain PARTY_ID as integer not null;
Derefter ville jeg bruge domænet i stedet for overalt, hvor der skulle have et parti-id.
create table customers (
customerid PARTY_ID primary key references parties (partyid),
...
Jeg vil også foretrække at se en tabel med ledere. En henvisning til det ville garantere, at manager.managerid ville løses til en faktisk leder, ikke kun til enhver medarbejder.