Peter, let me try to connect your vision to the ground of an ordinary scenario.
Given a department (or larger unit) responsible for designing and maintaining a set of relational databases, as well as web services providing read and write access to these databases.
From what you write I conclude that the Enterprise-ready model is marked by (among others) the following features:
Feature "operational" - supports the export of operational data (e.g. a query system, an OO persistence store)Feature
"generative" - supports the generation of other models (e.g. an
operational model; generation may be automatic, semi- or non-automatic)
Feature "transmittable" - supports the construction of messages to be exchanged by program agents
Question #1: as your model is operational, it would remove the need for relational databases? If not, you might be more explicit about when it can be used as such, and when it shall be used as some kind of input for the construction of other models
Question #2: as your model is generative - supporting the generation of other models in a straightforward way - I would like to know how to proceed
(a) when desiring to design a relational database (required for whatever reasons)
(b) when desiring to design a webservice interface
Let me add that the forest-shaped reference model which I advocate offers a
straightforward and easily describable approach how to generate other models (here: relational database and web service messages):
(a) generate tree representations of the relevant core schemas which are augmented by annotation attributes in a target model specific way, (e.g. @database, @table, @column, @index etc. in the case of a relational target model), awaiting human editing
(b) edit the generated annotation attributes
(c) transform the annotated trees into database definition (SQL) and web service definition (XSD)
And note the alignment of target model items with reference schema items, which offers important benefits - for example the automatic transfer of documentation items into the target model.
The approach is not trivial, but it is a clean and well-defined concept, and the implementation should be feasible.
HOW would the task be solved using the Enterprise-ready
model?
Hans-Juergen
Von: Peter Hunsberger <peter.hunsberger@gmail.com>
An: Hans-Juergen Rennau <hrennau@yahoo.de>
CC: Michael Kay <mike@saxonica.com>; "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
Gesendet: 16:21 Donnerstag, 3.Oktober 2013
Betreff: Re: [xml-dev] XML Schema as a data modeling tool
What do you do with an Enterprise ready data
model? Anything and everything you want to do with the given data domains in the given Enterprise! By definition, the model is good to go for any task you throw at it and requires no more manipulation. At the implementation level you should be able to export to XSD or DDL or WSDL or whatever to the extent that the domain you're modelling makes sense for one of those implementations (though maybe not automagically, that's dependant on your tool set).
If you don't know the basics of what makes up a graph then a couple of hours with Google will dig up enough Academic resources to keep you busy for however long you may wish to devote to the topic (lifetimes included). Vertices and edges are common terminology for the abstract representations, nodes tend to show up more on the implementation side. Graphs are mathematical models, they are often represented with circles and arcs or squares and straight line connectors, but they aren't constrained to look like anything any more than the number 1 (one) is...
