Re: Navigation question

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 28 Feb 2007 14:20:21 GMT
Message-ID: <FcgFh.2398$PV3.33178_at_ursa-nb00s0.nbnet.nb.ca>


Walt wrote:

> "JOG" <jog_at_cs.nott.ac.uk> wrote in message
> news:1172666781.609148.240850_at_m58g2000cwm.googlegroups.com...
>

>>On 27 Feb, 20:14, "dawn" <dawnwolth..._at_gmail.com> wrote:
>>
>>>On Feb 27, 8:58 am, "Walt" <wami..._at_verizon.net> wrote:
>>>
>>>
>>>
>>>
>>>>"dawn" <dawnwolth..._at_gmail.com> wrote in message
>>>
>>>>news:1172534823.070193.104950_at_k78g2000cwa.googlegroups.com...
>>>
>>>>>Walt wrote:
>>>>>
>>>>>>"dawn" <dawnwolth..._at_gmail.com> wrote in message
>>>>>>news:1172505529.681070.131640_at_q2g2000cwa.googlegroups.com...
>>>>>>
>>>>>>>On Feb 26, 8:28 am, "Walt" <wami..._at_verizon.net> wrote:
>>>>>>>
>>>>>>>>"dawn" <dawnwolth..._at_gmail.com> wrote in message
>>>
>>>>>>>>news:1172444333.974143.227280_at_q2g2000cwa.googlegroups.com...
>>>
>>>>>>>>>On Feb 23, 10:10 am, "Walt" <wami..._at_verizon.net> wrote:
>>>>>>>>>
>>>>>>>>>>"dawn" <dawnwolth..._at_gmail.com> wrote in message
>>>>>>>>>><snip> My questions are regarding
>>>>>>>>>>
>>>>>>>>>>>layer 7, where "logical navigation" of a database might

>
> take
>
>>>>>>place.
>>>>>>
>>>>>>>>>>>Does that work for you?  --dawn
>>>
>>>>>>>>>>what do  you mean by "OSI layers?"  Are you talking about

>
> layers
>
>>>>of
>>>>
>>>>>>>>>>protocols?
>>>
>>>>>>>>>First, I'll grant that the OSI layers are not in my area of
>>>>
>>>>expertise,
>>>>
>>>>>>>>>so I might very well have this wrong.  I am talking

>
> specifically
>
>>>>of
>>>>
>>>>>>>>>the 7 layers (of protocols) identified as the "OSI layers."
>>>
>>>>>>>>Could you list the layers, and give a link to a web page that
>>>>
>>>>describes
>>>>
>>>>>>>>them?
>>>
>>>>>>>I just did a google and I'm not sure whether you had trouble

>
> finding a
>
>>>>>>>link or if this is a test to see which link I would choose.  We

>
> can
>
>>>>>>>start withhttp://en.wikipedia.org/wiki/OSI_model
>>>
>>>>>>I know how to google.  I wanted to see what page you were reading

>
> from,
>
>>>>so
>>>>
>>>>>>that we could read from the same page.
>>>
>>>>>Perhaps I should have been reading from a page.
>>>
>>>>>>The page you pointed me to is a good starting place.  So you are

>
> talking
>
>>>>>>about protocols.
>>>
>>>>>No, I'm talking about layers and not specifically about the

>
> interfaces
>
>>>>>between them (protocols).  I'm talking about that which takes place
>>>>>within the application layer, using the OSI terminology only to try

>
> to
>
>>>>>get the focus within the app layer, rather than below it.  If the

>
> use
>
>>>>>of the OSI layers was distracting, then simply zero in on

>
> application
>
>>>>>software development, including all software (code, metadata,
>>>>>database, DBMS specs of any kind) that run or serve as input to
>>>>>executables running on top of an OS, for example.
>>>
>>>>>>>If I had been quizzed, I would have gotten the top, the bottom,

>
> and a
>
>>>>>>>few others by name, but I have never studied nor memorized these
>>>>>>>layers.  I only referred to them in order to get the focus of

>
> the
>
>>>>>>>question on the application layer.
>>>
>>>>>>>>>Given
>>>>>>>>>these 7 layers, I am not then talking about taking any one

>
> of
>
>>>>these
>>>>
>>>>>>>>>layers and further subdividiing it by protocol, but simply
>>>>
>>>>referring
>>>>
>>>>>>>>>to it so that it is clear (that obviously did not work) that

>
> I'm
>
>>>>>>>>>talking about the Application Layer.
>>>
>>>>>>>>>> If so, it seems to me that application to
>>>>>>>>>>database theory is limited to the areas where data is

>
> exchanged
>
>>>>in
>>>>
>>>>>>some
>>>>>>
>>>>>>>>sort
>>>>>>>>
>>>>>>>>>>of formal protocol.
>>>
>>>>>>>>>Surely not.
>>>
>>>>>>I don't understand the above.  "Surely not" what?  Do you mean

>
> "Surely
>
>>>>not
>>>>
>>>>>>limited to areas where data is exchanged in some sort of formal
>>>>
>>>>protocol"?
>>>>
>>>>>>If that's the case,  why did you refer to  "the OSI Layers"?
>>>
>>>>>I hope I explained that satisfactorily.  Since it is getting in the
>>>>>way, rather than helping, ignore OSI and focus on application

>
> software
>
>>>>>and the development thereof, including specification for and
>>>>>instructions to a DBMS, for example.
>>>
>>>>>> Database theory is highly relevant to conceptual
>>>>>>
>>>>>>>>>modeling, outside of this list of 7 layers, as well as to

>
> the
>
>>>>>>>>>interface between developer and DBMS, for example.  While

>
> there
>
>>>>are
>>>>
>>>>>>>>>surely some here who have an interest in data in some
>>>>
>>>>machine-readable
>>>>
>>>>>>>>>format that might not be all that useful for human eyes or
>>>>
>>>>application
>>>>
>>>>>>>>>programmers, I'm interested in Layer 7, the Application

>
> Layer.
>
>>>>Again,
>>>>
>>>>>>>>>I am not bringing this in so that we can discuss protocols

>
> within
>
>>>>that
>>>>
>>>>>>>>>layer, simply so that it is clear I'm not talking about

>
> "physical
>
>>>>>>>>>navigation."
>>>
>>>>>>If you are not talking about protocols,  then why are the OSI

>
> layers
>
>>>>>>relevant to your discussion?
>>>
>>>>>>I'm terribly confused by what you have written.
>>>
>>>>>>>strictly DBMS navigation).  BTW, I didn't mention Pascal.  I

>
> included
>
>>>>>>>JOG as the third.
>>>
>>>>>>Noted.
>>>
>>>>>>>>Any navigation a programmer
>>>>>>>>does entirely within the application is not relevant to the

>
> comments
>
>>>>>>Cdd,
>>>>>>
>>>>>>>>Date, and Pascal have made regarding database data.
>>>
>>>>>>>Really?  I thought they were opposed to "database navigation" in
>>>>>>>general, whether the application is navigating its way through

>
> the
>
>>>>>>>data or the DBMS is, or some combination.  Hmmm.  Perhaps one
>>>>>>>difficulty with the terms is that I consider DBMS specifications
>>>>>>>related to any application suite to be "part of" that

>
> application
>
>>>>>>>suite.
>>>
>>>>>Did this clarify at all?  Thanks.  --dawn
>>>
>>>>It clarified a little, but I'm still confused.  You can in fact divide
>>>>things into "layers" without regard to protocols,  and the phrase
>>>>"application layer" means something to me.  However, your reference to

>
> the
>
>>>>OSI layers suggested a common interpretation (between you and me) of

>
> the
>
>>>>term "application layer",  and you are using the phrase to convey

>
> something
>
>>>>a little different than the OSI people intended.
>>>
>>>>Let's distinguish between "database data"  and "application data".

>
> Data can
>
>>>>exist in a database,  in "working storage"  (to use an old COBOL

>
> term), and
>
>>>>be exchange across the interface.
>>>
>>>>Whether you navigate in working storage or not is entirely beside the

>
> point
>
>>>>that Codd, Date, and JOG have made, if I understand that point at all.

>
> The
>
>>>>point about user navigation interfering with both independence and
>>>>optimization within the DBMS is about the navigation of database data.
>>>
>>>>And, just in case,  "database data"  does *not* refer to copies of

>
> database
>
>>>>data in working storage.
>>>
>>>Agreed, so we are talking about "logical navigation" of a database by
>>>way of DBMS processes, metadata specified to the DBMS (such as foreign
>>>key & target declarations), and application code.  The DBMS and other
>>>code might very well work in layers below the application layer at run-
>>>time, but all specifications for this navigation are done in the
>>>application layer.  Under the app layer, the database need not be
>>>navigated, I don't care about that, but the navigation of the database
>>>takes place by way of specs that indicate that addressId is a foreign
>>>key in the Person relation that "points to" the addressId in the
>>>Address relation.  Then a query can be made such as
>>>
>>>select lastName, Address.city from Person;
>>>
>>>This, from my perspective, is "logical navigation" where the developer
>>>is specifying that the DBMS can "get to" the Address information from
>>>the Person information following a certain "path" (the link
>>>specification), then further specifying in some chunk of code that
>>>what needs to be retrieved related to the Person is their lastName and
>>>the city, which we know to be in Address.
>>>
>>>I recognize the beauty of
>>>
>>>select lastName, city from Person;
>>>
>>>which can also be accomplished with a virtual field in the Person
>>>relation that logically "goes to" the Address relation to retrieve the
>>>city.  So, this looks less like navigation in the query statement, but
>>>in the specifications to the DBMS (the virtual field) a path is
>>>presented.
>>>
>>>This can obviously also be accomplished with a vew so that we have
>>>
>>>select lastName, city from PersonAddrView;
>>>
>>>But in most code against an SQL-DBMS it is accomplished with a JOIN
>>>statement, which serves the same purpose as the "navigational" link
>>>information except that the JOIN data are repeated (considerable
>>>redundancy) and are spread around throughout the code rather than
>>>having a single specification.
>>>
>>>So, does the navigation above sound like what Codd etc think to be a
>>>bad thing?
>>
>>Yes. You have now created an Address object. To navigate you need
>>locations and objects give you that. Perhaps your Address object has a
>>house object inside it, with a number object and street object too, or
>>whatever you might want to hide away in your chain of russian dolls.
>>
>>Given this, you can now of course refer to all the objections to OO
>>databases made over the years, as well as to the evidence of their
>>lack of uptake as an indication of why navigation in the logical model
>>is suboptimal.
>>
>>
>>>I know that there are people who have been taught that it
>>>is a bad thing (I have to repair this when I hire them).
>>
>>Good grief. It never ends. What price a single thread, nay just one
>>post, without this sort of baiting. A post just in the name of
>>discussing theory and not trying to goad people? I find this very sad :
>>(
>>
>>
>>>I would like for there to be a clearer statement on navigation
>>
>>Statements have been extremely clear and I really don't understand
>>what is confusing- Navigation is the movement from one point to
>>another. In the relational model there are no locations, so there can
>>be no navigation. In a network model, there are locations and paths,
>>so there is navigation. Surely its not rocket science.
>>
>>
>>>-- particularly,whether the above is within the scope of the seeming

>
> disdain for
>
>>>navigation or outside of it
>>
>>"disdain"? Pffft. Purple prose to emote reactions. Its just not that
>>exciting i'm afraid - opinion is just that declarative approaches are
>>preferable to navigation, nothing more.
>>
>>
>>>and just what "logical" database navigation is wrong and why.
>>
>>Navigation is not 'wrong' or 'evil' - its just that declaration is
>>preferable in a logical model. And the arguments seem pretty clear to
>>me:
>>
>>1) Nothing can be done via Navigation that cannot be done with a
>>Declarative approach. Navigation however requires an extra mechanism
>>that is superfluous and brittle. (The Einstein, keep a mechanism as
>>simple as possible but no simpler argument)
>>2) Navigation in a network, and the locations or objects that it
>>requires, leads to query bias due to the arbitrary nesting that it
>>mandates you do. (This is the shared data, or changing requirements
>>argument). Modelling using propositions instead of objects is more
>>flexible.
>>3) As object composition increases navigational queries to extract
>>them get ever more complex and convoluted (Codds argument to IBM, a
>>lumbering company with a enormous inertia and mass entrenched in
>>network database technology. Yet even they were convinced.)
>>
>>Navigation has its place (hypertext and the web for example). Its just
>>that a logical data model is probably not that place.
>>
>>
>>>Thanks for your help and patience with me.  --dawn
>>
>>I find myself more and more just posting to balance opinion for
>>neutral readers. I have given up trying to convince you of anything -
>>you appear too entrenched in your anti-RM crusade to be pragmatic and
>>recognize the good points that the evolution to RM has to offer, or to
>>see why it has been so successful despite its flaws :(

>
> JOG,
>
> You have to understand... Dawn teaches SQL at a bible school. Hence the
> constant infusion of theology into what might simply be a logical
> discussion. Her anti RM crusade resonates with the "RM is the holy grail"
> crusade that is often voiced in here.

Huh? By whom, I wonder?

In any case, the only way to defeat a troll is to ignore her. Received on Wed Feb 28 2007 - 15:20:21 CET

Original text of this message