Hadi Moshayedi wrote on 8/1/19 4:14 PM:
On Thu, Aug 1, 2019 at 12:23 PM Ryan Kramer <default.kra...@gmail.com
<mailto:default.kra...@gmail.com>> wrote:
This looks interesting! I have thought about trying to generate
Entity Relationship diagrams given a database schema, but assumed
that laying out the boxes would be a hard problem. Looks like
GraphViz might do a decent job at this. I'll try it out and let
you know how it goes.
Yesterday I learnt that also PlantUML can be used using stdin/stdout
interface and it can generate SVG, which can be converted to Pict
using rsvg. I was thinking spending some time on trying to have some
kind of Racket library for that too. It might be a better tool for
generating ER diagrams. See http://plantuml.com/ie-diagram
I tend to use UML's notation for "static object modeling" when doing
what's essentially entity-relationship modeling. (There's other UML
models, but usually people just mean the main diagram, and often just to
show only attributes and inheritance and nothing else. Few people might
do rigorous state modeling, protocol event traces, etc.)
Your DB schema is relational? If you're willing to represent DB
relational tables and columns as UML classes with attributes, the UML
notation might be more compact and understandable than an ER one you'd
use, but you have to decide how much of the DB semantics you want to
represent, and how. For example, if you want to talk about DB joins you
use, you might just use only attribute annotations for candidate keys,
*or* you might use much more visual UML associations that are in
addition to the attributes. (For target implementations *without* joins
like that, you'd probably instead use association roles, without
attributes at all, and indicate navigability directions of the
associations.)
Regarding laying out the boxes, that particular UML notation might be
modeled as a constraint satisfaction problem, but it's a tricky one.[1]
For example, in practice, you might usually want your generalization
associations to have a high priority for super being above sub, usually
less so for aggregation assemblies, link attributes (if you have those)
tending to come off a horizontal edge, etc. Then you get into things
like edge routing for reducing crossings and bends, while still spacing
out your vertices, plus the various adornments on edges that complicate
things. And maybe you want stability of layout between changes to also
be a factor... One of the several methodologists' camps that went into
UML (and from which that particular UML notation largely came), Rumbaugh
et al.'s OMT, developed an interactive diagramming tool that was more
limited than real CASE systems, but did the best job of constraint-based
interactive editing that I'd seen (but not enough constraints to do
automatic layout): OMTool, from a GE lab.[2]
[1] For a similar visual language, my industry R&D group once hired a
very smart PhD student in computational geometry graph drawing to tackle
it, and they made some progress, but it still wasn't entirely a solved
problem afterwards.
[2] Racket aside: I actually used OMTool, until I no longer had access
to it, and kludged up a simple but practical Java generator/updater for
it, "https://www.neilvandyke.org/jomtool/";. You'll notice Jomtool was
written in Emacs Lisp, rather than Java, even though I was an early Java
expert and advocate, and working in Java. When I went looking for a new
platform for rapid R&D work, especially in PL and symbolic Web
processing, I admitted that a Lisp was more productive than my beloved
Java for many things, and I ended up choosing Scheme. Even though
Scheme didn't have basic OO features, and I'd been working very heavily
in OO architecture/design/OOP/methodology, and had been invited to be on
a UML committee -- it still looked like a win. Scheme turned out to be
a good choice for those R&D purposes, but industry is a much longer and
more complicated story, and there are disruption opportunities close on
the horizon.
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/f36020f9-acbd-d126-3013-ebe8eb2655af%40neilvandyke.org.
