Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Logical models, hierarchy, network model
 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@z... tel;cell:+61 411 287 530 x-mozilla-html:TRUE version:2.1 end:vcard 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
