Corretta modellizzazione e convenzione dei nomi per una tabella intermedia tra intermedi

Come presumo nominando la relazione ha un certo valore, possibilmente, per comunicare il modello agli uomini d'affari, deve avere un nome migliore. Non è facile indovinare tutti i dettagli della tua descrizione, ma la necessità per la relazione suggerisce che il modello che rappresenta non cattura tutte le informazioni importanti (ad esempio, ti manca qualche Entità importante? Forse, tutti e tre i prodotti intermedi possono essere messi insieme a uno, sacrificando la normalizzazione? Etc) o la relazione è abbastanza artificiale, quella del dominio della soluzione.

Per riformulare, se le relazioni non corrispondono a quelle di un dominio aziendale ragionevole, prova a scoprire se il dominio ha qualcos'altro. Chiedete agli esperti del dominio su come correlano flusso, evento, documento e messaggio - forse, menzionano qualcosa di utile. Quindi puoi acquisire tale conoscenza nel modello. Questo sarà il miglior risultato, perché la relazione avrà un nome naturale. Se quello che stai facendo è pesantemente nel dominio della soluzione a causa di alcuni problemi di ottimizzazione o semplicemente perché è troppo astratto, mi piacerebbe comunque raccomandare di assegnare un nome alle relazioni per riflettere la loro intenzione. Ad esempio, dal diagramma non è chiaro quale tipo di associazione event_message e flow_message si nascondano, tanto meno quando si aggiunge event_message_flow_message. Almeno, fai un tentativo di trovare un nome più significativo. Una cosa è certa: è impossibile suggerirti un nome (o addirittura approvare l'aggiunta di quelli che definisci come relazioni intermedie) senza conoscere il tuo dominio aziendale.

Avrei raccomandato di sfogliare almeno il libro "Modellazione di informazioni aziendali - Relazione di entità e modellazione di classi per analisti aziendali" di Keith Gordon, pubblicato da BCS Learning & Development Limited, 2017.

Ad esempio, dal libro, "Sebbene le relazioni e le associazioni molti a molti siano costrutti legittimi da avere su un modello, possono rappresentare un problema in quanto potrebbero nascondere alcune informazioni importanti che l'azienda dovrebbe essere interessata alla registrazione È compito dell'analista testare ognuna di queste relazioni e associazioni molti-a-molti per vedere quali informazioni, se ve ne sono, si nascondono ". E qui trovi più saggezza sulla modellazione delle informazioni aziendali, esattamente come suggerisce il nome del libro.