Re: Navigation question

On Feb 21, 9:01 am, mAsterdam <mAster..._at_vrijdag.org> wrote:
> dawn wrote:
> > In another thread "navigation" is again mentioned as undesirable.
>
> Navigation is from here to there.
> Things like distance, direction, movement, traveling time, location,
> path and space are relevant concepts.
>
> In RM the database (at the logical level(*)) is a single-point
> thing. No navigational term has any meaning in a
> single point. Conversely, non of the RM terms
> have any navigational meaning.
>
> (*) Some may maintain that the RM covers no other level.
> A lower, physical level is implied, and AFAIK most
> book that cover RM also touch it. A lot of
> navigation is going on at that level. Without further
> qualification, every navigational remark is, by default
> about that level, the physical level.
>
> Nothing good, nothing bad here, just: navigation is something that
> does not exist within the RM. 'From a fk in a child to a parent tuple'
> is at best metaphor (and btw. borrows hierarchical terms).
>
> Now why do people (seem to) want to discuss RM at
> the exclusion of anything else? I don't know. I know I don't.
>
> You want to discuss navigation? Ok. The RM will not proliferate
> vocabulary. Furthermore, the first thing people will associate
> it with is the physical level hidden by the DBMS. You have clearly
> stated that that is not what you want to talk about.
>
> Let's go navigating the database - not at the physical level, but
> somewhere else; 'Navigating foreign keys', example:
>
> Let's have a db browser like this:
>
> In the top-bar you can select any table (say A) from the schema,
> directly below it you can see all data in A
> in a spreadsheet display.
>
> In the second bar you can select any table (say B) having a foreign
> key referencing A. Directly below it etc...
>
> Now expand it (release 2) to a network browser,
> where it is possible have a place for selecting data from all tables C
> referenced by the foreign keys in B.
>
> This is something one could describe in navigational terms,
> loosely borrowing RM terms.
> Navigation here is the metaphor serving as a guideline for the user
> interface.
>
> Release 3 would add the extra luxury feature of not just
> having foreign keys as paths between tables, but any join.

At fundamental level navigation totally ignores manipulation and operational issues. Comparing *navigational* approaches (for whatever fuzzy concept that is) to RM concepts is pretty much like comparing porn movies to anatomy lessons. Received on Wed Feb 21 2007 - 09:52:52 CET