Cosa fare con le chiavi esterne del database in una classe di entità?

Innanzitutto un paio di osservazioni:

1. Le classi non hanno chiavi esterne. stai assumendo che le classi rappresentino le tabelle in un database relazionale e questo è sbagliato. Non tutte le classi del mondo verranno mantenute su un RDBMS, né ogni tabella RDBMS avrà una classe modellata dopo di essa. È sbagliato all'inizio.
2. In che modo esattamente dici cosa "definisce lo stato" di un oggetto e cosa no? Forse per una classe Person la BankAccount non fa parte del suo stato interno ma per una classe Employee che fa.
3. dept_id e address_id non seguono alcuna convenzione di denominazione Java ampiamente accettata, dovrebbero essere denominate deptId , addressID , ecc.

Una classe Employee non dovrebbe avere un membro bankID ma un membro bankAccount che è di tipo BankAccount .

Non lo farei:

public class Employee{
    private int coBank;
    public int getCoBank(){};
}

ma questo

public class Employee{
    private BankAccount bankAccount;
    public BankAccount getBankAccount(){};
}

Nel caso di una persona, forse le informazioni bancarie non fanno parte della classe stessa, quindi, inverti la logica in modo che la persona non abbia un riferimento alle informazioni bancarie e lasci che BankAccount abbia un riferimento alla persona :

public class BankAccount{
    public Person owner getOwner(){};
}

Nel caso di un dipendente, tutti dovrebbero avere un conto bancario per funzionare correttamente, quindi è logico che il conto bancario faccia parte del suo stato.

Nel caso di una semplice persona che potrebbe non essere così, il conto bancario dovrebbe fare riferimento alla persona e non viceversa.

Modifica

@COMEFROM in un commento ha aggiunto alcune eccezioni valide al mio punto sull'opportunità o meno che le classi abbiano come referenti gli ID come membri:

I think it's worth to mention that having referencing ID:s as attributes is alright in a larger scale, if the referenced entity is out of the scope of the system under design or if it otherwise belongs to some other context than the parent object.

No, vanno nella stessa classe.

Cerca di non rimanere troppo bloccato dalle definizioni delle parole. Un "attributo" (ciò che il resto del mondo chiama un "campo") è solo una variabile membro privata della classe, e questo è tutto. Gli ID sono considerati parte dello stato dell'oggetto, proprio come qualsiasi altro campo.

Quando decidi se le cose dovrebbero andare insieme in una classe, considera solo se concorrono o meno insieme concettualmente. Non orientare la tua decisione sui punti più fini di alcune definizioni di parole come "stato".

Ok, penso che la risposta di @ Robert vada direttamente alla tua domanda.

Inoltre, il refactoring che suggerisci di introdurre un'altra relazione, EmployeeForeignKeys , avere tutte le chiavi esterne insieme in un oggetto / riga non aiuta.

Tuttavia, ho la sensazione che tu riconosca alcuni potenziali problemi di progettazione in quanto forse troppe responsabilità sono detenute dalla classe dei dipendenti.

Hai un paio di relazioni 1-1: mobile, banca, email, posizione, indirizzo. Sei sicuro che ogni dipendente abbia esattamente uno di questi interessi per la tua azienda? Questo deve essere preso in considerazione dall'azienda o dai soggetti interessati del dominio e concordato come requisito aziendale, piuttosto che come un problema da risolvere per i programmatori.

Ciò che può accadere è che nel tempo aggiungi il telefono di casa, la seconda email, il secondo indirizzo, il terzo telefono, la seconda posizione, ecc. Potresti trovare gli utenti che devono aggiungere un dipendente due volte per acquisire un telefono aggiuntivo o indirizzo o posizione. Questi tipi di relazioni a volte sono meglio modellati usando relazioni molte-a-molti (in tabelle) o liste (usando le classi).

La mia risposta è che non metterei queste cose come attributi individuali nella classe dei dipendenti. Per alcuni di questi, preferirei che altre relazioni facciano riferimento al dipendente (o magari utilizzino elenchi).