Happy to see GraphViz used for these things! We tried to use it at one of my jobs but it wasn't as good as what was being rolled by hand with a tree of thousand

Happy to see GraphViz used for these things! We tried to use it at one of my jobs but it wasn't as good as what was being rolled by hand with a tree of thousands of nodes, so we created something bespoke. But it has been in my toolkit since then, and I used it at one point to draw a flow chart for a choose-your-own-adventure style book. The word “many” is clutter in an ERM, every arrow by default is a one to many arrow. It's presence probably suggests that your arrows are backwards from what I would do, they should point in the direction of data access which you can do, they are always many to one. The word “one” is nice, but because in practice it is created by a unique index on a column on the referring table, I have always denoted it with a small black line perpendicular to the arrow on that root side. Also missing seems to be nullable foreign keys, which should be denoted with an open circle at the root of the arrow, for the same reason. The fact that you have to put so much stuff on this side is the only reason I don't like Crow's Foot notation. And, like, one of course wants bi-directional arrows representing a many-to-many relationship but one would like to zoom in on that and see the actual table maybe. Growing this thing outward, you want to teach people how to think with it. Two diagrams two paths on a diagram which start from the same place and follow arrows until they get to the same place, suggests a consistency danger. Probably you intend one row in the source table to only map to one row in the destination table, what happens if the two paths give me a different answer? Is there a way to rephrase this so that this is no longer a problem? Furthermore, there always is because arrows come in different strengths. I can always downgrade a one-to-one into a many-to-one arrow. I can always downgrade that into a nullable many-to-one arrow. I can always downgrade that into a many-to-many double arrow. and this is enough to open that sort of double pointing relationship, deciding one of these relations to be many to many instead of many to one. I would love to teach a virtual class on this, but the one thing I struggle with is standardizing some idea of type so that the BS is kind of cleared away. Like a lot of tables could be written as “string ComponentAssemblyCategory,” okay, it has a creation date and version tracking and whatever else, but fundamentally there is just a unique varchar in there which is the point of the table to hold. This is also necessary for those many-to-many tables to be auto-collapsible, you would find after all of the other fields are removed it would just be a `null ClientProjects` table allowing every project to have many clients or each client to have many projects.