Re: Navigation question

On Feb 28, 6:46 am, "JOG" <j..._at_cs.nott.ac.uk> wrote:
> 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.

How did the Address Relation turn into an Address object? We could model our Address set of attribute values as a Relation or as an Object, I guess, but calling it an object does not mean it cannot be modeled as a Relation.

> To navigate you need
> locations and objects give you that.

Introducing the term "locations" is not particularly helpful, but OK, if you want to call it a logical, this "logical location" includes

>From location:

A Relation, Person, with attribute addressId (or homeAddress or whatever) and a Person, personId in this relation with an addressId of "12345678". This value is our "From location"

To location:
A Relation, Address, with attribute addressId with value "12345678" and a city value. This value is our "To location"

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

Does bringing in the terms "object" "location" and "chain" help in some way? I'm working with data that can be mapped to mathematical relations, whether or not you might also view them as objects.

> Given this, you can now of course refer to all the objections to OO
> databases made over the years,

Gotta love this argument, JOG -- call my relations "objects" and then say that there have been many objections to objects over the years. QED.
> as well as to the evidence of their
> lack of uptake as an indication of why navigation in the logical model
> is suboptimal.

I heard recently that Caché is the fastest growing commercial DBMS, but I do not know by what measure it is growing (annual % revenue or profit growth, perhaps?) But I agree that nothing that advertises itself specifically as an object dbms has been strong. Other than Caché, where one can work with relations or objects, for example, I am not suggesting object databases, nor did I introduce the term object into this.

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

It was a fact that helps explain why I'm interested in getting to the bottom of it. So, why did you take the bait ;-)

> A post just in the name of
> discussing theory and not trying to goad people? I find this very sad :
> (

If anecdotes or conversational comments are uninteresting to you, just ignore them. I worked hard to ask this question and I do not see why tossing in one little anecdote should make you sad. You could, instead, consider it delightful, your choice.

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

but I did not ask about the relational model, I asked about navigation. It seems that one of the rationales for the relational model is that it helps us get away from navigation. So arguing that navigation is bad because it is not in the relational model is circular.

> so there can
> be no navigation. In a network model, there are locations and paths,
> so there is navigation.

Yes. So, if a developer chooses a design pattern that logically navigates the database (using whatever DBMS calls, which individually need not navigate), or if a combination of developer code, DBMS, and DBMS specifications logically navigates the DBMS, are those types of navigation folded into the "bad navigation" with physical pointers and such? I do not yet know if such logical navigation is part of the blanket statements opposing navigation, but they seem to be. If so, why?

> Surely its not rocket science.

You can toss that in, along with throwing objects, locations, and chains into the discussion and you do not like a one-line anecdote from me?

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

That was very poetic. I tried to come up with another word when writing it, since I had already used "aversion" in the thread and it seems to be stronger than that. Feel free to suggest a more accurate description.

> Its just not that
> exciting i'm afraid - opinion is just that declarative ...
>
> read more »

Dang, I hate that about the new google groups. If I come back later to reply, I don't get the entire discussion.

I am still not satisfied that I understand just what navigation is bad and why "logical navigation" of the types I have presented is clumped in with phyiscal navigation and considered an anti-pattern by some.

Thanks. --dawn Received on Wed Feb 28 2007 - 15:31:27 CET