OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] XML Schema as a data modeling tool

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?

On Fri, Oct 4, 2013 at 5:41 AM, 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?


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS