Are we are trying to replicate(rewrite) the data-modelling textbooks?
This is a extract from the KLEEN 'Asset Oriented Modelling' Tool introductory paper at:
http://www.aomodeling.org/KLEEN%20WhitePaper.pdf
"Introducing Asset Oriented Modeling (AOM)
Open scenarios
It seems that the closed world assumption of the enterprise data model has
become a thing of the past. The business requirements of electronic business,
supply chain integration, company mergers, outsourcing, and flat enterprise
business models ask for open data models that can easily interoperate.
The revolution of data models
These new requirements have led to new data models, data models that are
far more flexible, extensible, and dynamic than what we were used to in the
past. The widespread adoption of XML as a lingua franca throughout the IT-
community is a clear indication that the existing data models (like the relational
and object-oriented data models) are far too rigid and narrow to cope with
the new requirements. It is the document metaphor which characterizes these
new data models. The governing construction principle is no longer the
relational table or the hierarchical object but the grammar.
The revolution of data models has, of course, implications for conceptual
modeling. Every time a new data model was introduced in the short history of
computing, new conceptual modeling methods were introduced, too –
methods that would cope better with the new data model. The introduction
of the relational data model had sparked Entity Relationship Modeling, and
the introduction of the object-oriented data model resulted in object-oriented
modeling methods such as the UML and ORM.
While these modeling methods served very well for their respective data
models, they are not equally appropriate for the new grammar based data
models. The result is a semantic impedance mismatch between conceptual
model and implementation, a mismatch that adversely affects the communica-
tion between the partners in the developing process. And, as you know, bad
communication can be costly.
AOM removes this roadblock from dynamic application development."
Compare the above to an extract from the Graph Databases book i mentioned before.
"We Already Communicate in Graphs
Graph modeling naturally fits with the way we tend to abstract the salient details from
a domain using circles and boxes, and then describe the connections between these
things by joining them with arrows. Today’s graph databases, more than any other da‐
tabase technologies, are “whiteboard friendly.” The typical whiteboard view of a problem
is a graph. What we sketch in our creative and analytical modes maps closely to the data
model we implement inside the database. In terms of expressivity, graph databases re‐
duce the impedance mismatch between analysis and implementation that has plagued
relational database implementations for many years. What is particularly interesting
about such graph models is the fact that they not only communicate how we think things
are related, but they also clearly communicate the kinds of questions we want to ask of
our domain. As we’ll see throughout this chapter, graph models and graph queries are
really just two sides of the same coin."
So, apparently, the first approach is based on the theory of "grammars" and the second on that of "graphs". This does seem to me to be what we are trying to elucidate here. [Is "Whiteboard Serialisation Format" actually a Graph Database DDL?]
My personal interest in this does relate very much to the cost-benefit
equation, if my main purpose is to manage data via a web interface, it makes sense (to me) to model data in a way that allows cost-effective
generation of infra-structure (forms,query interfaces etc) using such a
"document metaphor". Or, is this likely to be a case of easy early gains but big
problems later?
