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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: Re: [ubl-dev] Tools for database support for UBL?


i am pleased that stephen posted this question and got some valuable 
responses because it always me to clarify the UBL approach to developing 
its library.

i think those developing UBL applications will find that the document 
component model as expressed in the UML Class Diagrams is actually a 
relational model - the mapping has been done for you!

a database designer need only take this model and reconcile things like 
many-to-many associations and duplicate pathways to create the necessary 
tables.

it is also worth point out that trying to use the document assembly 
models (as expressed in the UBL spreadsheets or schemas) for database 
design is not only unnecessary reverse engineering but also too restrictive.

the best way to think of this is that UBL has a normalized relational 
model (what we call the document component model).  we then use this to 
create various document assembly models.  for a database designer these 
would be called views.  so UBL has a view called Invoice, Order, 
Despatch Advice, etc..  the important thing about these views is that 
they are hierarchical not relational.  that is because the data models 
of documents always have been and always will be hierarchical (inverted 
tree structures).  and once we have created a specific hierarchical view 
for a document type (what we call the document assembly model) it is 
very easy to apply rules for a hierarchical respresentation language 
like XML and create schemas. in other words we are doing at a conceptual 
level what CAM defines at the physical XML syntax level.  We assemble 
individual document models from a common model based on their context of 
use.

NB what can cause confusion is that the artifact we know of as the UBL 
library of re-usable structures (ABIEs in the CAC module) and components 
(BBIEs in the CBC module) are simply the set of common assemblies for 
the UBL 1.0 set of documents.  they do not represent the complete 
conceptual model.

Stephen Green wrote:

>Dear UBL-DEV, Hi
>
>If anyone has interest in the possibility of developing tools to help store UBL
>and UBL-based instances in a relational database I've been thinking along the 
>following lines:
>
>1. What sort of tables could UBL map to? What would be the relational mapping, say?
>
>2. Need to map Schemas to 'CREATE' SQL and develop a generator for that
>
>3. Need to map instances to 'UPDATE' SQL (etc ...?) and develop a generator for that
>
>I wonder if any have thoughts of devloping something like the above, perhaps as opensource
>or priced attractively to foster wider UBL / UBL-like Schema adoption (the key to successful
>use of UBL perhaps).
>
>What worries me is the complexity of UBL but there's the challenge and the drive I suppose.
>It would seem obvious to just treat every ABIE as a table and every document as an
>ABIE/table too. The relationships are where I get a bit lost.
>
>Another key factor would be to make the tools generic - to handle any Schemas built 
>by the UBL NDR rules and from the UBL spreadsheets (e.g. see UBLish from softml.com 
>which uses a scripting language similar to perl). 
>
>All the best
>
>Steve
>
>  
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160

DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
(coming soon from MIT Press)
http://mitpress.mit.edu/catalog/item/default.asp?sid=632C40AB-4E94-4930-A94E-22FF8CA5641F&ttype=2&tid=10476






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