Importance des diagrammes ER

Je suis étudiante et je développe plusieurs projets dans le cadre de mon université.

Lors du développement de la base de données pour l'un des projets, nous sommes tombés sur une situation où nous nous sommes demandé si la DRE était nécessaire ou non. À l'heure actuelle, nous ne sommes pas tous d'accord pour développer d'abord l'ERD, puis développer une base de données à partir de celui-ci.

La majorité des gens préfèrent développer la base de données à la volée verbalement selon les exigences du système sur papier directement.

Maintenant, je suis un adepte strict des principes de la base de données. Je pense que la base de données devrait être développée uniquement à partir de la DRE. Donc, je veux juste savoir ce qui suit:

• L'industrie suit-elle ces principes?
• Suis-je en train de perdre mon temps à développer un ERD?
• Quels sont les avantages de développer un ERD?

Clair et simple, pensez à développer une base de données sans ERD comme construire une maison sans plan de construction. Cela pourrait être faisable parce que vous pensez que la simple pose d'une brique l'une sur l'autre est suffisante pour construire quelque chose, mais au moment où quelqu'un d'autre prend la responsabilité du projet, il y a un risque de catastrophe.

D'après mon expérience, vous ne bénéficierez pas beaucoup des ERD à moins que vous ne les utilisiez en conjonction avec des outils CASE (ERWin, MySQL Workbench, etc.) qui vous permettront en outre d'effectuer des opérations vraiment utiles telles que l'ingénierie directe et inverse. Même sans que ces fonctions aient un schéma centralisé de la base de données complète est utile parce que parfois les contraintes implémentées dans la base de données elle-même ne sont pas suffisantes pour raconter toute l'histoire des relations entre des entités de base de données particulières.

Voici un exemple impliquant MySQL qui, comme vous le savez peut-être, implémente plusieurs moteurs de stockage interne, notamment MyISAM et InnoDB. Il existe des différences importantes entre eux, l'une des plus importantes étant que MyISAM ne prend pas en charge les contraintes. Malgré cela, MyISAM est largement utilisé pour les applications Web, ce qui signifie que la logique relationnelle doit être implémentée soit via la logique métier (code d'application), soit d'une autre manière. Le problème est lorsque vous transférez un ERD avec des tables MyISAM (entités) MySQL ignorera silencieusement les contraintes définies par l'ERD et vous vous retrouverez avec une base de données qui n'identifie pas clairement la nature des relations entre les entités. En d'autres termes, une fois que vous avez développé la disposition de la base de données, les développeurs de code n'ont aucun moyen d'implémenter une logique métier appropriée sans ERD.

Les ERD sont vraiment agréables pour avoir une image claire de la structure de votre base de données. En plus d'être un artefact de document important pour votre projet, il est plus facile lorsque vous devez implémenter des requêtes, en particulier des jointures entre les tables. Imaginez à quel point c'est agréable d'avoir une configuration double moniteur, à gauche vous avez votre ERD et à droite votre éditeur de requête. Vous pouvez clairement voir les relations entre les tables et écrire vos requêtes en fonction de cela. Si votre projet de base de données est assez simple et que votre projet n'en a pas besoin, il est peut-être acceptable de s'en passer.

ERD vous fera gagner beaucoup plus de temps que vous ne le pensez. Si vous faites tout à la volée, vous serez bloqué lorsque vous souhaitez générer des tables de jonction.

Si vous tombez sur la base de données quelques années plus tard sans ERD, vous devez passer beaucoup de temps pour voir ce qui se passe dans votre projet.

J'ai une entreprise et nous concevons ERD, ne pensez jamais à une base de données sans ERD (en fait, c'est ma propre expérience personnelle)

Il y a quelque temps, les DRE étaient plus courants. OMI, ils sont plus ou moins facultatifs maintenant.

Actuellement, certaines équipes très performantes ne se soucient pas du tout des ERD, mais fournissent d'excellents systèmes: robustes, performants et faciles à entretenir à long terme. Cela est particulièrement vrai dans le développement Agile, lorsque nous commençons petit, avec un ensemble d'outils minimaliste.

Les DRE sont un bon moyen de communication, bien sûr, mais en aucun cas le seul moyen, ou le meilleur en toutes circonstances. Certaines équipes préfèrent d'autres modes de documentation et de communication.

Il n'y a pas de règles générales dans cette industrie.

Il est important de concevoir avant d'écrire du code de production. Il est également important de prototyper; les gens de base de données développent des prototypes en écrivant SQL. (Rappelez-vous ce que Fred Brooks a dit sur les prototypes?)

Les langages graphiques, dont ER n'est qu'un, ne se sont pas révélés très efficaces pour capturer toute la sémantique d'une base de données d'une manière facile et simple à comprendre.

Ils ne se sont pas non plus révélés être des outils de communication très efficaces, sauf entre développeurs. Mais dans la conception de bases de données, la communication cruciale n'est pas entre les développeurs; c'est entre les développeurs et les experts du domaine (entre les développeurs et les gens d'affaires).

La modélisation objet-rôle (ORM) a un langage graphique, mais il est basé sur des "faits" (phrases simples). Les gens d'affaires peuvent valider les faits assez facilement. Les gens d'affaires ne peuvent pas facilement valider un diagramme ER ou un diagramme ORM.