I think that, in this case, the nugget of truth is actually pretty self-evident. The idea is to have a document that specifies the current design of a database and a tool that can update any database to have that design. If you scrape away the part of that sentence that is obviously magical thinking, you are left with this:
"The idea is to have a document that specifies the current design of a database."The part that is not quite as readily-apparent is that the motivation runs just a little bit deeper than that. The real drive behind a tool that can update any database to a well-understood definition of the most recent design is that you have a document that codifies the current design and a tool that enforces the current design.
That's a noble goal, actually and an attainable one at that. Think about it...
Disregarding all the ancient ideas, don't we still have a way of doing that when defining a "regular" object model? We just do it a different way. Instead of technical specifications and UML diagrams, we have unit tests. Instead of a tool that generates code from high-level specifications, we have test runners.
Given a class of databases, using unit tests as the primary specification of design is a discipline that transfers straight over to database development; practically unmodified.
So that's the positive takeaway from the era of magical design-application tool mysticism: that we do in fact need a way to specify and enforce the current design of a class of databases and that, like Java, .Net, or C++ classes, that should be automated unit tests specifying how a database behaves and enforcing that specification on a regular basis.
