Importancia de los diagramas ER

Soy estudiante y estoy desarrollando varios proyectos como parte de mi academia.

Al desarrollar la base de datos para uno de los proyectos, nos encontramos con una situación en la que pensamos si ERD es necesario o no. En este momento, no todos estamos de acuerdo en desarrollar el ERD primero, y luego desarrollar la base de datos a partir de él.

La mayoría de las personas prefiere desarrollar la base de datos sobre la marcha verbalmente de acuerdo con el sistema requerido en papel directamente.

Ahora, soy un seguidor estricto de los principios de la base de datos. Creo que la base de datos debe desarrollarse solo desde el ERD. Entonces, solo quiero saber lo siguiente:

• ¿La industria sigue estos principios?
• ¿Estoy perdiendo el tiempo desarrollando un ERD?
• ¿Cuáles son los beneficios de desarrollar un ERD?

Simple y simple, piense en desarrollar una base de datos sin ERD como construir una casa sin un plan de construcción. Puede ser factible porque cree que simplemente colocar un ladrillo uno sobre otro es suficiente para construir algo, sin embargo, en el momento en que alguien más se responsabiliza del proyecto, existe un potencial de desastre.

En mi experiencia, no se beneficiará mucho de los ERD a menos que los use junto con las herramientas CASE (ERWin, MySQL Workbench, etc.) que además le permitirán realizar algunas operaciones realmente útiles, como la ingeniería directa e inversa. Incluso sin estas funciones, tener un esquema centralizado de la base de datos completa es útil porque a veces las restricciones implementadas en la base de datos en sí no son suficientes para contar la historia completa sobre las relaciones entre entidades de bases de datos particulares.

Aquí hay un ejemplo que involucra a MySQL que, como ya sabrá, implementa varios motores de almacenamiento interno, especialmente MyISAM e InnoDB. Hay diferencias significativas entre ellos, uno de los más importantes es que MyISAM no admite restricciones. A pesar de ese hecho, MyISAM se usa mucho para aplicaciones web, lo que significa que la lógica relacional debe implementarse a través de la lógica de negocios (código de aplicación) o de otra manera. El problema es cuando reenvías un ERD con tablas (entidades) MyISAM MySQL ignorará silenciosamente las restricciones establecidas por el ERD y terminarás con una base de datos que no identifica claramente la naturaleza de las relaciones entre las entidades. En otras palabras, después de desarrollar el diseño de la base de datos, no hay forma de que los desarrolladores de código implementen una lógica comercial adecuada sin un ERD.

Los ERD son realmente agradables para tener una imagen clara de la estructura de su base de datos. Además de ser un artefacto de documento importante para su proyecto, se facilita cuando necesita implementar consultas, especialmente las uniones entre tablas. Imagine lo bueno que es tener una configuración de monitor dual, en el lado izquierdo tiene su ERD y en el lado derecho su editor de consultas. Puede ver claramente las relaciones entre las tablas y escribir sus consultas en función de eso. Si su proyecto de base de datos es bastante simple y su proyecto no lo requiere, tal vez esté bien vivir sin él.

ERD le ahorrará mucho más tiempo de lo que piensa. Si hace todo sobre la marcha, se quedará atascado cuando desee generar tablas de unión.

Si se encuentra con la base de datos unos años más tarde sin ERD, tiene que pasar mucho tiempo para ver qué está sucediendo en su proyecto.

Tengo compañía y diseñamos ERD, nunca piense en una base de datos sin ERD (en realidad, este es mi propio experimento personal)

Los ERD solían ser más convencionales hace algún tiempo. OMI son más o menos opcionales ahora.

Actualmente, algunos equipos altamente exitosos no se molestan en absoluto con los ERD, pero ofrecen sistemas excelentes: robustos, de alto rendimiento y fáciles de mantener a largo plazo. Esto es especialmente cierto en el desarrollo ágil, cuando comenzamos de a poco, con un conjunto minimalista de herramientas.

Los ERD son una buena forma de comunicación, por supuesto, pero de ninguna manera son la única o la mejor en todas las circunstancias. Algunos equipos prefieren otras formas de documentación y comunicación.

No hay reglas generales en esta industria.

Es importante diseñar antes de escribir el código de producción. También es importante hacer un prototipo; la gente de la base de datos desarrolla prototipos escribiendo SQL. (¿Recuerdas lo que dijo Fred Brooks sobre los prototipos?)

Los lenguajes gráficos, de los cuales ER es solo uno, no han demostrado ser muy buenos para capturar toda la semántica de una base de datos de una manera fácil y simple de entender.

Tampoco han demostrado ser herramientas de comunicación muy efectivas, excepto entre desarrolladores. Pero al diseñar bases de datos, la comunicación crucial no es entre desarrolladores; es entre desarrolladores y expertos en dominios (entre desarrolladores y gente de negocios).

El modelado de roles de objetos (ORM) tiene un lenguaje gráfico, pero se basa en "hechos" (oraciones simples). La gente de negocios puede validar los hechos con bastante facilidad. La gente de negocios no puede validar fácilmente un diagrama ER o un diagrama ORM.