Importância dos diagramas de ER

Sou estudante e estou desenvolvendo vários projetos como parte da minha academia.

Ao desenvolver o banco de dados para um dos projetos, nos deparamos com uma situação em que pensávamos se o ERD é necessário ou não. No momento, nem todos concordamos em desenvolver o ERD primeiro e depois desenvolver o banco de dados a partir dele.

A maioria das pessoas prefere desenvolver o banco de dados em tempo real verbalmente, de acordo com os requisitos do sistema em papel diretamente.

Agora, sou seguidor rigoroso dos princípios do banco de dados. Eu acho que o banco de dados deve ser desenvolvido apenas a partir do ERD. Então, eu só quero saber o seguinte:

• A indústria está seguindo esses princípios?
• Estou apenas perdendo meu tempo desenvolvendo um ERD?
• Quais são os benefícios do desenvolvimento de um ERD?

Puro e simples, pense em desenvolver um banco de dados sem um ERD como construir uma casa sem um plano de construção. Pode ser possível porque você acha que simplesmente colocar um tijolo um sobre o outro é suficiente para construir algo; no entanto, no momento em que outra pessoa assume a responsabilidade pelo projeto, há um potencial de desastre.

Na minha experiência, você não se beneficiará muito dos ERDs, a menos que os use em conjunto com as ferramentas CASE (ERWin, MySQL Workbench etc.), que também permitirão a você executar algumas operações realmente úteis, como engenharia direta e reversa. Mesmo sem essas funções, ter um esquema centralizado do banco de dados completo é útil porque às vezes as restrições implementadas no próprio banco de dados não são suficientes para contar a história completa sobre os relacionamentos entre entidades específicas do banco de dados.

Aqui está um exemplo envolvendo o MySQL que, como você deve saber, implementa vários mecanismos de armazenamento interno, principalmente MyISAM e InnoDB. Existem diferenças significativas entre elas, uma das mais importantes, sendo que o MyISAM não suporta restrições. Apesar disso, o MyISAM é muito usado em aplicativos da Web, o que significa que a lógica relacional precisa ser implementada por meio da lógica de negócios (código do aplicativo) ou de outra maneira. O problema é quando você encaminha um engenheiro de ERD com tabelas (entidades) MyISAM. O MySQL silenciosamente ignora as restrições definidas pelo ERD e você termina com um banco de dados que não identifica claramente a natureza dos relacionamentos entre as entidades. Em outras palavras, depois de desenvolver o layout do banco de dados, não há como os desenvolvedores de código implementarem a lógica de negócios adequada sem um ERD.

É muito bom ter ERDs para ter uma imagem clara da sua estrutura de banco de dados. Além de ser um artefato de documento importante para o seu projeto, facilita quando você precisa implementar consultas, especialmente junções entre tabelas. Imagine como é bom ter uma configuração de monitor duplo, no lado esquerdo você tem ERD e no lado direito seu editor de consultas. Você pode ver claramente os relacionamentos entre tabelas e escrever suas consultas com base nisso. Se o seu projeto de banco de dados é bastante simples e não o exige, talvez seja bom viver sem ele.

O ERD economizará muito mais tempo do que você pensa: se você fizer tudo rapidamente, ficará bloqueado quando desejar gerar tabelas de junção.

Se você se deparar com o banco de dados alguns anos depois sem o ERD, precisará gastar muito tempo para ver o que está acontecendo no seu projeto.

Eu tenho empresa e criamos ERD, nunca pense em banco de dados sem ERD. (Na verdade, esse é meu experimento pessoal)

Os ERDs costumavam ser mais populares há algum tempo. IMO eles são mais ou menos opcionais agora.

Atualmente, algumas equipes de grande sucesso não se preocupam com os ERDs, mas oferecem sistemas excelentes: robustos, com bom desempenho e fáceis de manter a longo prazo. Isso é especialmente verdade no desenvolvimento ágil, quando começamos pequenos, com um conjunto minimalista de ferramentas.

ERDs são uma boa maneira de comunicação, é claro, mas de nenhuma maneira a única maneira, ou a melhor em todas as circunstâncias. Algumas equipes preferem outras formas de documentação e comunicação.

Não há regras gerais neste setor.

É importante projetar antes de escrever o código de produção. Também é importante prototipar; as pessoas do banco de dados desenvolvem protótipos escrevendo SQL. (Lembra o que Fred Brooks disse sobre protótipos?)

Linguagens gráficas, das quais ER é apenas uma, não provaram ser muito boas em capturar toda a semântica de um banco de dados de uma maneira fácil e simples de entender.

Eles também não provaram ser ferramentas de comunicação muito eficazes, exceto entre desenvolvedores. Mas, ao projetar bancos de dados, a comunicação crucial não é entre desenvolvedores; é entre desenvolvedores e especialistas em domínio (entre desenvolvedores e pessoas de negócios).

A Modelagem de Função de Objeto (ORM) tem uma linguagem gráfica, mas é baseada em "fatos" (frases simples). Pessoas de negócios podem validar fatos com bastante facilidade. As pessoas de negócios não podem validar facilmente um diagrama de ER ou ORM.