[
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
|
