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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Logical models, hierarchy, network model

[ Lists Home | Date Index | Thread Index ]

Ken North wrote:

>>>The network model from the CODASYL DBTG supports many-to-many
>>>relationships but,
>>>like a hierarchical database, it's based on pointers.
>>>      
>>>
>>No, the model is not based on pointers: this is a popular myth. It is the
>>implementations that were based on pointers.
>>    
>>
>
>You've made an important point about separating the logical model for data from
>the physical model.
>
>For set members, the network model uses a link to the prior member, to the next,
>and to the set owner. The common practice for providing those links was to use
>pointers. That was not mandated by the logical model, it was simply industry
>practice (like digital computing and base 2 arithmetic).
>
>  
>
>>But it would be perfectly possible to design an implementation of the network
>>    
>>
>model that was optimised for evolution rather than being
>  
>
>>optimised for speed of navigation.
>>    
>>
>
>Even if you eliminate the pointer dependencies, the logical model requires
>someone to define set relationships that are necessary for determining access
>paths. Developers and/or tools need to understand how to navigate the sets (for
>example, whether the members are in ascending or descending order as you
>traverse a set).
>
>When the sets, relationships and access paths are dynamic, we need a good
>versioning system for schemas.
>
>
>(Aside: Software AG's Tamino might implement XML over a network model. Adabas
>was one of the most successful CODASYL DBMS products.)
>
>  
>
most of this was mandated by performance and a view that the semantic 
information had to be stored with the physical information.

fwiw it's like most of these things. there are levels and the confusion 
of levels is usually justified for performance reasons.

level 0. is the physical level. this has to be designed to meet the 
performance requirements of the levels above it.

my choice (because of the next few layers): rows of n-ary relations 
(matching the logical layer). (this implies they're all the same shape). 
multi-indexed with b+ trees.

level 1. is the logical layer - how does the data look? like sets of 
relations. and able to be mathematically manipulated (at least in 
principle) as sets. this by the way is what cj date is always on about. 
do what you like above and below, but the database is sets of n-ary 
relations.

level 2. is the model layer - how can you describe the data? this is 
where the network comes in. to be precise i use the term associations 
between sets to remove the confusion of the term "relation" which is 
really a single row in a set. the associations are defined by the tables 
being associated and the common data. this is significant because the 
data in the sets can be modified without rerefence to the model - no 
pointers etc have to be altered. the relations stand independent. the 
model is a meta view and like schrodinger's cat it's existence, 
location, and validity only exist when someone opens the box. note that 
while not essential to the logical layer, the model will however 
influence design choices at the physical layer - in particular how many 
and what indexes should be used to navigate quickly.

in my case i also put all the calculations at the model layer. this 
works because the expression evaluator can now navigate the database 
answering questions by itself like "how many orders does customer x 
have?" and "what are they worth?". a form of calculus can be used to 
express calculations and it can be evaluated quickly.

level 3.  is the application model. here markup languages (wish i had 
that term decades ago to describe what we do) can express what has to be 
done making use of the model. and leave the work to the parsers. again 
it's important that nothing has to be real (compiled etc) until 
required. it's like a quantum view of the application. and to be honest 
we take advantage of that to allow application development to proceed 
while the applications are being used.

i think a mathematically better view of xml would be to use xml to 
describe the relations (not the relationships == associations), and a 
separate document (like we do with xslt) to describe the associations. 
then an xslt like process could do far more with the information.

now if i could just find the hours in the day to use this to process 
xml.....

rick

>
>
>
>
>
>
>
>
>
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>  
>

begin:vcard
fn:Rick  Marshall
n:Marshall;Rick 
email;internet:rjm@zenucom.com
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard





 

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

Copyright 2001 XML.org. This site is hosted by OASIS