La mesa "fiesta" no se ve bien. Compare con el código fuente de esta otra pregunta SO .
En este tipo de estructura, el número de identificación del partido se propaga hacia abajo, por así decirlo. Por lo general, debe ser una clave principal o una clave externa en las tablas que almacenan datos sobre una persona.
En su tabla de "informes", parece que la clave principal no debería ser 'partyid'. Eso permitiría solo una fila por empleado, lo cual no creo que haya sido su intención. (Podría estar equivocado). Si tengo razón en eso, podría considerar un NOT NULL UNIQUE restricción en {partyid, date} y una PRIMARY KEY restricción en una nueva columna, 'reportid'. Las tablas "viaje" y "rendimiento" probablemente harían referencia a 'reportid'. (Pero sigue leyendo).
Hay lugares en su diagrama donde una entidad obtiene una clave adicional:su empresa asigna un número de identificación de empleado único a sus empleados, por ejemplo. No hay ninguna razón teórica por la que no pueda usar 'employid' en lugar de 'partyid' a partir de ese momento para hacer referencia a los empleados. Pero hay es una razón práctica por la que es posible que no quieras hacer eso. Aumenta el número de uniones.
Por ejemplo, si las tablas "credencial", "herramienta", "certificación", "académico" y "cumplimiento" hacen referencia a employee.employid en lugar de employee.partyid, no podría simplemente unir "cumplimiento" y "parte" para obtener el nombre de la persona. También tendrías que unirte a "empleado".
Necesitan tener una clave principal; la clave principal no tiene que ser necesariamente un número de identificación. Si existe una clave natural, debe identificarla y declararla ÚNICA de todos modos.
La tabla "orders" probablemente debería tener solo "orderid" como clave principal; utilice una referencia de clave externa para identificar al cliente. En algunos casos, tiene sentido cambiar el nombre de las columnas. En el caso de los clientes, podría tener sentido llamar a su clave 'customerid' en lugar de 'parytid'. Yo mismo crearía un dominio.
create domain PARTY_ID as integer not null;
Entonces, en todos los lugares que necesitaban un número de identificación de parte, usaría el dominio en su lugar.
create table customers (
customerid PARTY_ID primary key references parties (partyid),
...
Yo también preferiría ver una mesa de gerentes. Una referencia a él garantizaría que manager.managerid se resolvería en un gerente real, no solo en cualquier empleado.
