Il modello ER utilizzato nella progettazione del database e nella progettazione del software è lo stesso?

Il modello Entity-Relation era all'origine sviluppato pensando al design del database.

È abbastanza generale da essere utilizzato per la modellazione dei dati e l'analisi del sistema (già menzionato nell'articolo originale di Chen), in quanto offre una visione concettuale dei dati, non vincolata da alcun approccio tecnico.

Il modello ER affronta però solo i dati. Non è stato progettato per il comportamento o l'elaborazione del modello. Quindi, se lo usassi nella progettazione del software, avresti bisogno di integrarlo con altri modelli come ad esempio un modello di flusso di dati (per identificare le elaborazioni) o un modello di funzione (ad es. IDEF0 e simili).

Al giorno d'oggi, tuttavia, è abbastanza comune usare UML , che offre un insieme completo e coerente di tecniche di modellazione che coprono entrambe le strutture del sistema e comportamento. Il suo diagramma di classe può descrivere quasi tutto ciò che puoi descrivere in un diagramma ER. Ma è più preciso (puoi ad esempio indicare i vincoli di navigazione delle relazioni, che non puoi in ER dato che tutte le relazioni sono bidirezionali). E permette di descrivere in esso i metodi che ogni entità sta offrendo.

Suppongo che tu intenda la progettazione orientata agli oggetti al contrario di altre metodologie di progettazione del software.

I diagrammi ER sono stati sviluppati per la modellazione dei dati che si è evoluta nella progettazione orientata agli oggetti. Ad esempio, nei database per rappresentare l'ereditarietà è possibile inserire la chiave genitore come chiave esterna nel figlio. Analogamente, in un linguaggio orientato agli oggetti come C ++, la struttura figlio contiene un puntatore al genitore. In entrambi i casi la relazione è di molti a uno, ma l'implementazione fisica è diversa.