La table "fête" n'a pas l'air correcte. Comparez avec le code source de cette autre question SO .
Dans ce type de structure, le numéro d'identification du parti se propage vers le bas, pour ainsi dire. Il doit généralement s'agir d'une clé primaire ou d'une clé étrangère dans les tables qui stockent des données sur une personne.
Dans votre tableau "reporting", il semble que la clé primaire ne devrait pas être 'partyid'. Cela n'autoriserait qu'une seule ligne par employé, ce que je ne pense pas que vous vouliez. (Je peux me tromper.) Si j'ai raison, vous pourriez envisager un NOT NULL UNIQUE contrainte sur {partyid, date} et une PRIMARY KEY contrainte sur une nouvelle colonne, 'reportid'. Les tableaux "voyage" et "performance" feraient probablement référence à "reportid". (Mais continuez à lire.)
Il y a des endroits dans votre diagramme où une entité obtient une clé supplémentaire :votre entreprise attribue un numéro d'identification d'employé unique à ses employés, par exemple. Il n'y a aucune raison théorique pour laquelle vous ne pouvez pas utiliser 'employid' au lieu de 'partyid' à partir de ce moment pour référencer les employés. Mais il existe une raison pratique pour laquelle vous ne voudrez peut-être pas le faire. Cela augmente le nombre de jointures.
Par exemple, si les tables « credential », « tool », « certification », « academic » et « compliance » font référence à employee.employid au lieu de employee.partyid, vous ne pouvez pas simplement joindre « conformité » et « partie » à obtenir le nom de la personne. Vous devrez également rejoindre "employé".
Ils doivent avoir une clé primaire ; la clé primaire ne doit pas nécessairement être un numéro d'identification. S'il existe une clé naturelle, vous devez l'identifier et la déclarer UNIQUE quand même.
La table "orders" ne devrait probablement avoir que "orderid" comme clé primaire ; utiliser une référence de clé étrangère pour identifier le client. Dans certains cas, il est judicieux de renommer les colonnes. Dans le cas des clients, il peut être judicieux d'appeler sa clé 'customerid' au lieu de 'parytid'. Je créerais moi-même un domaine.
create domain PARTY_ID as integer not null;
Ensuite, partout où il fallait un numéro d'identification de partie, j'utilisais le domaine à la place.
create table customers (
customerid PARTY_ID primary key references parties (partyid),
...
Je préférerais aussi voir un tableau des managers. Une référence à celui-ci garantirait que manager.managerid se résoudrait à un véritable responsable, et pas seulement à n'importe quel employé.
