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>
>
> take
>
>
> layers
>
>
> specifically
>
>
> finding a
>
>
> can
>
>
> from,
>
>
> talking
>
>
> interfaces
>
>
> to
>
>
> use
>
>
> application
>
>
> and a
>
>
> the
>
>
> of
>
>
> I'm
>
>
> exchanged
>
>
> "Surely
>
>
> software
>
>
> the
>
>
> there
>
>
> Layer.
>
>
> within
>
>
> "physical
>
>
> layers
>
>
> included
>
>
> comments
>
>
> the
>
>
> application
>
>
> the
>
>
> the
>
>
> something
>
>
> Data can
>
>
> term), and
>
>
> point
>
>
> The
>
>
> database
>
>
> disdain for
>
>
> 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.
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