Path: utzoo!mnetor!uunet!husc6!mailrus!nrl-cmf!ames!pasteur!ucbvax!ucsfcgl!cca.ucsf.edu!daedalus!brianc
From: brianc@daedalus (Brian Colfer)
Newsgroups: comp.databases
Subject: Re: relational flaws
Message-ID: <1171@ucsfcca.ucsf.edu>
Date: 7 Mar 88 18:57:11 GMT
References: <91@coot.AUSTIN.LOCKHEED.COM>
Sender: root@cca.ucsf.edu
Reply-To: brianc@daedalus.UUCP (Brian Colfer)
Organization: UCSF Dept. of Lab Med
Lines: 91
Keywords: relational flaws, cursors, relational model
Summary: Another idea about this problem

In article <91@coot.AUSTIN.LOCKHEED.COM> chris@AUSTIN.LOCKHEED.COM (Chris Wood) writes:
>In article <1169@ucsfcca.ucsf.edu>, brianc@daedalus (Brian Colfer) writes:

>> In a relational database there is no notion of "nextness"..."

>> >   Can someone with a deeper knowledge of relational theory comment
>> >on this, especially with respect to saying
>> >	1) "give me one of"  -- the current problem
>> >	2) "give me the first n of" -- from a problem in bibliographic
>> >					search
>> >	3) "give me any n of"
>> 
As another angle at the problem from an INFORMIX-4GL perspective
how about using CURSORS?

	 DECLARE c_x SCROLL CURSOR FOR
	     Select * From  tbl Where tbl.x = something

	 Then
1)	 FETCH FIRST c_x INTO pr_tbl.*

2)   FETCH ABSOLUTE (or RELATIVE) n c_x INTO pa_tbl.* (pa = program array)
	 or
	 FOR i = i to n
	 FETCH c_x INTO pr_tbl.*
		  DISPLAY pr_tbl.*
     END FOR
3)   I'm not sure of the difference between the 
	  "first n of" and "any n of"

Of course the cursor must be opened and closed...

How CURSORs fit into this concept of non-nextness is somewhat of a
mystery but I suspect that the non-nextness quality is preserved in the 
SELECTing rows.

>
>
>   Repeating fields or groups of fields violate "normalization" and thus
>   are not generally supported even though they would frequently provide
>   noticeable increases in processing efficiency.

	Yes, and for some applications this may be exactly what you want
	to do.  What we gain through the relational model is flexibility
	and logical power.  For most applications the trade off in
	efficiency is not worth giving up these features.

	I think that more the "relational" a data base is the better.  Its
	a goal not a law.
>
>   Pre-declared relationships violate the spirit of relational theory.
>   Views are close, but they are not as dynamic to use as "canned" 
>   relationships.  Current relational implementations basically put 

    Canned relationships can take away much of the power and
	flexibilty of the relational model.  By "canned" I assume we are
	talking about relations which are built into the data base and 
	are therefore difficult to modify.

>   the burden of navigating through the data relationships on the person
>   who enters the query, not on the designer of the database.  This goes
>   against the ongoing trend of increasing user-friendliness and ease-of-use

	Providing ease-of-use should not prohibit database power.  I see a
	database as the foundation for applications.  There may be several
	applications talking with the same database in different ways.
	What I think is important is that while an application may
	interact with a user in a friendly way it interacts with the database
	in according to the relational model.

>   in computer software.  I helped write a DBMS that put "canned" relationships
>   on top of a underlying "relational" DBMS.  Then I wrote a report writer
>   that popped up a list of all records and their fields in the entire
>   database.  The user simply marked the desired fields in whatever records
>   he wanted, and using the canned relationships the software calculated the
>   "best" retrieval path to get the results, and produced the report.  This

    Obviously you are not talking about "canned" relationships in the
	sense of a hierarchical or network database model.  It seems to me
	that if the data requirements or relation network changes it will
	be relatively easy for the application to adapt.

>   was not a hierarchical database, the records were highly networked.  The



==========================================================================
             : UC San Francisco            : brianc@daedalus.ucsf.edu 
Brian Colfer : Dept. of Lab. Medicine      : ...!ucbvax!cgl!brianc 
             :  PH. 415-476-2325           : brianc@ucsfcca.bitnet
==========================================================================