Re: [xml-dev] XML Schema as a data modeling tool

[Peter Hunsberger <peter.hunsberger@gmail.com>]

Hans-Jurgen (or do you go by Hans?),

see my reply I just sent off to John, some of your questions are answered there.  But yes, I am talking about a system that no longer has a relational database, at least not necessarily as it's primary data store, although that can still happen.  In the model I talk about a relational database is just another storage mechanism with certain data management capabilities and certain IO characteristics that may or may not match up with the logical and physical models that you build.  The metadata for finding the best fit can itself be built out and if you follow what companies like EMC are doing you'll see a vision of that all the way down to the hardware level where data is shuffled off to different storage media on the fly to best optimize data delivery.

If part of your business is to generate a relational database or spit out WSDL then you will need a way  to build those artifacts from your business metadata.  However, if you don't mind taking on the recursive overhead (and it's tiny for what were're talking about) then those processes themselves can be defined in metadata and the "XML output" module can spit out XSD, XSLT or what have you as long as you feed it the correct metadata to traverse the other metadata...

Peter Hunsberger

On Thu, Oct 3, 2013 at 2:41 PM, Hans-Juergen Rennau <hrennau@yahoo.de> wrote:

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...

Peter Hunsberger