Re: Navigation question

From: dawn <>
Date: 26 Feb 2007 07:58:49 -0800
Message-ID: <>

On Feb 26, 8:28 am, "Walt" <> wrote:
> "dawn" <> wrote in message
> > On Feb 23, 10:10 am, "Walt" <> wrote:
> > > "dawn" <> 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 with

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. 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."
> Two responses:
> First, fair enough. But I think it's also correct for you to modify your
> original comment regarding Codd, Date, and Pascal "frowning on navigation"
> to apply to "navigation within the database".

That is what I intended -- database navigation (but not necessarily strictly DBMS navigation). BTW, I didn't mention Pascal. I included JOG as the third.

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

> Conceptual modeling of data is not necessarily directly relevant to database
> theory.

OK. Logical data modeling is directly relevant to database theory. Conceptual modeling is directly relevant to logical modeling. IIRC both were considered relevant to cdt in the charter. Thanks. --dawn

> Conceptual modeling of data is directly relvant to data management.
> Database theory (and practice) is directly relevant to data management.
> So, indirectly, conceptual modeling of data and database theory will be
> relevant to each other. But it's useful to be explicit about data
> management as the bridge between them.
<snip> Received on Mon Feb 26 2007 - 16:58:49 CET

Original text of this message