RE: BSR - the Basic Semantic Register

["Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com>]

Good People,

Like Phil aand a good many others, I too have "been there, done that" with
respect to hierarchical DB's and their advantages (yes there are some
advantages over RDBs), and their limitations.  I even authored a really good
DB manager way back then that our company still uses in some products.  

Given a relational organization of some business data, it is a trivial
exercise to construct a 'relational DB' message.  Just define a message
having 'n' compound 'elements', whose members are the set of primitive
'elements' that make up one DB record construct.  Define the message as
being a collection of such records, in any order, and in any quantity. 

But do we really want 100% relational-DB messages?

Hierarchical relationships are legend in the real world.  I would accomodate
that by designing hierarchical message constructs to the extent that they
model real world hierarchical relationships.  Then I would augment that
design with relational message constructs to handle the relationships
(key/key relations) that are not directly addressed by the hierarchical
model.  

Cheers,
        Bob




-----Original Message-----
From: Philip Goatly [mailto:philip.goatly@bolero.net]
Sent: Friday, January 26, 2001 6:11 AM
To: Martin Bryan; William J. Kammerer; ebXML Core
Cc: Peter Guldentops; Zahida Christie; kara.Wales@bolero.net
Subject: Re: BSR - the Basic Semantic Register


Hello Martin,

    Yes  agree that is one way to do it - been there done it in the 1970s-
however if hierarchies are 'deep' then the permutationsand combinations can
become large and cumbersome. I am suggesting therefore that 'deep'
hierachies are best avoided if the relationship/s are capable of many to
many.

 A 3 level many to many is capable of  6 combinations and 4 level 24 etc. or
something like that


Cheers, Phil

----- Original Message -----
From: "Martin Bryan" <mtbryan@sgml.u-net.com>
To: "Philip Goatly" <philip.goatly@bolero.net>; "William J. Kammerer"
<wkammerer@foresightcorp.com>; "ebXML Core" <ebxml-core@lists.ebxml.org>
Cc: "Peter Guldentops" <peter.guldentops@bolero.net>; "Zahida Christie"
<zahida.christie@bolero.net>; <kara.Wales@bolero.Net>
Sent: Friday, January 26, 2001 11:53 AM
Subject: Re: BSR - the Basic Semantic Register


> Philip
>
> >   There are 2 scenarios which I would liek to contemplate:
> >
> >   1. One Product packed in many containers.
> >
> >         The layout in XML could be as follows
> >
> >           <Product>
> >                 <Container> </Container>
> >                 <Container> </Container>
> >                 <Container> </Container>
> >                  ........
> >          </Product>
> > 2. Many products in one container
> >
> >           <Container>
> >                  <Product> </Product>
> >                  <Product> </Product>
> >                  <Product> </Product>
> >            </Container>
> >
> >   The challenge is one cannot predict how a packer will pack a
> consignment -
> > It will depend on many factors like the size
> > of containers, the dimension of product/s etc or just how a particualar
> > packer feels on a particular day !!!
>
> Agreed, but then what is the business process? If the process is shipping
> then you start from the container that has to be moved. If the process is
> ordering you start from the products that have to be packed in the
> container. The person ordering does not care how many containers are
needed.
> The shipper gets to match the orders with the containers.
> >
> >        There are of couyrse solutions to the above like allowing one OR
> "|"
> > the other BUT if a hierarchy is expressed in
> > sevearal levels the permutations become larger.
>
> XML models have choices defined using OR groups, and choices based on the
> use of all of a set of elements without ordering.
>
> > Thus this becomes a
> > generalised problem of many to many relationships
> > and how to handle them in a hierarchical structure.
>
> Any one instance of a message has a single hierarchy because it has chosen
> one of the alternatives, but the model allows for all possible
hierarchies.
>
> >        This was a common problem in the 1970's when virtually all DBs
were
> > Hierarchical. I remember it well.
>
> Those of us with fond memories of Hierarchical DBs are getting rarer by
the
> day :-)
>
> But do not confuse the hierarchical nature of the message for the need to
> store it in a hierarchical database. A good XML database uses XML
datatypes
> to define the hierarchy, not the XML elements that form the message.
> >
> >        In general designers tended to flatten the hierarchies as much as
> > possible and relate hierarchies thru data fields -
> >        and then Ted Codd et al 'invented' the relational Database which
is
> > the main paradigm today.
>
> >       How does XML deal with many to many ?
> >       How will ebXML deal with many to many ?
>
> Through divorcing modelling from instances. Each message has a single
> hierarchy that represents a choice from a model that defines the set of
> permitted hierarchies.
>
> Martin Bryan
>