De tafel "party" ziet er niet goed uit. Vergelijk met de broncode van deze andere SO-vraag .
In dit soort structuur verspreidt het partij-ID-nummer zich als het ware naar beneden. Het moet meestal een primaire sleutel of een externe sleutel zijn in tabellen die gegevens over een persoon opslaan.
In je tabel "reporting", lijkt het alsof de primaire sleutel niet 'partyid' mag zijn. Dat zou slechts één rij per werknemer toestaan, wat volgens mij niet je bedoeling was. (Ik kan het mis hebben.) Als ik daar gelijk in heb, zou je een NOT NULL UNIQUE kunnen overwegen> beperking op {partyid, date} en een PRIMARY KEY beperking op een nieuwe kolom, 'reportid'. De tabellen "reizen" en "prestaties" zouden waarschijnlijk verwijzen naar 'reportid'. (Maar blijf lezen.)
Er zijn plaatsen in uw diagram waar een entiteit een extra sleutel krijgt:uw bedrijf kent bijvoorbeeld een uniek werknemers-ID-nummer toe aan zijn werknemers. Er is geen theoretische reden waarom je vanaf dat moment 'employid' in plaats van 'partyid' niet meer kunt gebruiken om werknemers te verwijzen. Maar er is een praktische reden om dat misschien niet te doen. Het verhoogt het aantal joins.
Als de tabellen "credential", "tool", "certification", "academic" en "compliance" bijvoorbeeld verwijzen naar employee.employid in plaats van employee.partyid, kunt u niet zomaar "compliance" en "party" toevoegen aan de naam van de persoon krijgen. Je zou ook lid moeten worden van "employee".
Ze moeten een primaire sleutel hebben; de primaire sleutel hoeft niet per se een id-nummer te zijn. Als er een bestaande natuurlijke sleutel is, moet je deze identificeren en hoe dan ook UNIEK verklaren.
De tabel "orders" zou waarschijnlijk alleen "orderid" als primaire sleutel moeten hebben; gebruik een refererende sleutelreferentie om de klant te identificeren. In sommige gevallen is het zinvol om kolommen te hernoemen. In het geval van klanten kan het zinvol zijn om de sleutel 'customerid' te noemen in plaats van 'parytid'. Ik zou zelf een domein maken.
create domain PARTY_ID as integer not null;
Dan, overal waar een partij-ID-nummer nodig was, zou ik in plaats daarvan het domein gebruiken.
create table customers (
customerid PARTY_ID primary key references parties (partyid),
...
Ik zou ook liever een tabel met managers zien. Een verwijzing ernaar zou garanderen dat manager.managerid zou oplossen met een echte manager, niet zomaar een werknemer.