Importanza dei diagrammi ER

Sono uno studente e sto sviluppando diversi progetti come parte della mia università.

Durante lo sviluppo del database per uno dei progetti, ci siamo imbattuti in una situazione in cui abbiamo pensato alla necessità o meno di ERD. Al momento, non tutti noi siamo d'accordo nello sviluppare prima l'ERD e poi nello sviluppare un database da esso.

La maggior parte delle persone preferisce sviluppare verbalmente il database al volo in base ai requisiti di sistema direttamente sulla carta.

Ora seguo rigorosamente i principi del database. Penso che il database dovrebbe essere sviluppato solo dall'ERD. Quindi, voglio solo sapere quanto segue:

• L'industria sta seguendo questi principi?
• Sto solo perdendo tempo a sviluppare un ERD?
• Quali sono i vantaggi dello sviluppo di un ERD?

Semplice e chiaro, pensa a sviluppare un database senza ERD come a costruire una casa senza un piano di costruzione. Potrebbe essere fattibile perché pensi che semplicemente costruire un mattone sopra l'altro sia sufficiente per costruire qualcosa, tuttavia nel momento in cui qualcun altro si assume la responsabilità del progetto c'è un potenziale disastro.

Nella mia esperienza non beneficerai molto degli ERD se non li utilizzi insieme agli strumenti CASE (ERWin, MySQL Workbench ecc.) Che ti permetteranno inoltre di eseguire alcune operazioni davvero utili come il forward e il reverse engineering. Anche senza queste funzioni avere uno schema centralizzato dell'intero database è utile perché a volte i vincoli implementati nel database stesso non sono sufficienti per raccontare l'intera storia delle relazioni tra particolari entità del database.

Ecco un esempio di MySQL che, come forse saprai, implementa diversi motori di archiviazione interni, in particolare MyISAM e InnoDB. Esistono differenze significative tra loro, una delle più importanti è che MyISAM non supporta i vincoli. Nonostante ciò, MyISAM è ampiamente utilizzato per le applicazioni Web, il che significa che la logica relazionale deve essere implementata attraverso la logica aziendale (codice dell'applicazione) o in altro modo. Il problema è quando si progetta in avanti un ERD con tabelle (entità) MyISAM MySQL ignorerà silenziosamente i vincoli impostati dall'ERD e si finirà con un database che non identifica chiaramente la natura delle relazioni tra entità. In altre parole, dopo aver sviluppato il layout del database, gli sviluppatori di codice non possono implementare la logica di business corretta senza un ERD.

Gli ERD sono davvero belli avere una chiara immagine della struttura del database. Oltre ad essere un importante artefatto del documento per il tuo progetto, si facilita quando è necessario implementare le query, in particolare i join tra le tabelle. Immagina quanto sia bello avere una configurazione a doppio monitor, sul lato sinistro hai il tuo ERD e sul lato destro il tuo editor di query. Puoi vedere chiaramente le relazioni tra le tabelle e scrivere le tue query in base a ciò. Se il tuo progetto di database è abbastanza semplice e il tuo progetto non lo richiede, forse è ok vivere senza di esso.

ERD ti farà risparmiare molto più tempo di quanto pensi. Se fai tutto al volo, rimarrai bloccato quando vuoi generare tabelle di giunzione.

Se ti imbatti nel database qualche anno dopo senza ERD, devi dedicare molto tempo a vedere cosa sta succedendo nel tuo progetto.

Ho compagnia e progettiamo ERD, non pensare mai al database senza ERD (in realtà questo è il mio esperimento personale)

Le ERD erano più tradizionali qualche tempo fa. IMO sono più o meno opzionali ora.

Attualmente, alcuni team di grande successo non si preoccupano affatto degli ERD, ma forniscono sistemi eccellenti: robusti, performanti e facili da mantenere a lungo termine. Ciò è particolarmente vero nello sviluppo Agile, quando iniziamo in piccolo, con un set minimalista di strumenti.

Le ERD sono un buon modo di comunicare, ovviamente, ma assolutamente non l'unico, o il migliore in tutte le circostanze. Alcuni team preferiscono altri modi di documentazione e comunicazione.

Non ci sono regole generali in questo settore.

È importante progettare prima di scrivere il codice di produzione. È anche importante prototipare; le persone del database sviluppano prototipi scrivendo SQL. (Ricordi cosa ha detto Fred Brooks sui prototipi?)

I linguaggi grafici, di cui ER è solo uno, non hanno dimostrato di essere molto bravi a catturare tutta la semantica di un database in un modo facile e semplice da capire.

Inoltre, non hanno dimostrato di essere strumenti di comunicazione molto efficaci, tranne tra gli sviluppatori. Ma nella progettazione di database, la comunicazione cruciale non è tra gli sviluppatori; è tra sviluppatori ed esperti di dominio (tra sviluppatori e uomini d'affari).

Object-Role Modeling (ORM) ha un linguaggio grafico, ma si basa su "fatti" (frasi semplici). Gli uomini d'affari possono validare i fatti abbastanza facilmente. Gli uomini d'affari non possono validare facilmente un diagramma ER o un diagramma ORM.