chris@AUSTIN.LOCKHEED.COM (Chris Wood) (03/05/88)
In article <1169@ucsfcca.ucsf.edu>, brianc@daedalus (Brian Colfer) writes: > > This is interesting, in that it is a perfectly plausible request > >that does not **seem** to be well-defined in the relational > >algebra/calculus (and perhaps even less well-defined in the *#%!@?&& > >sublanguages we get with them). > > [Here's the big one!] > In a relational database there is no notion of "nextness"..." > > Following there is no such thing as the first or last > so how can SQL support it?! > > > > > 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" > > Non-sensical from a relationship model perspective. Plus from a > application perspective to arbitrarialy select a set of row(s) because of > its position is illogical. The better task formulation is: I just love it when a "real-world" need is considered "non-sensical" by relational theory. Other examples: 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. 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 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 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 was not a hierarchical database, the records were highly networked. The path navigation algorithm was smart enough to recognize cycles and prune them from the list of candidate paths. It also made use of the user specified sort keys for pruning the tree of possible paths. It works! This is in a current commercially marketed package from NMS in Alexandria, Va. called the Workstation Builder. It runs on PCs. Chris Wood
rfm%urth@Sun.COM (Richard McAllister) (03/05/88)
In article <91@coot.AUSTIN.LOCKHEED.COM> chris@AUSTIN.LOCKHEED.COM (Chris Wood) writes: >I just love it when a "real-world" need is considered "non-sensical" by >relational theory. > >Other examples: > > 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. Nothing in the relational model prevents you from storing a group of rows that differ in only one column as the non-varying part followed by the deltas. Just don't present it that way to the user who may want to join on that column and is going to have a hard time doing it if the column values are n-tuples > 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. Sounds like IBM's Query by Example front end to DB2, which does the query optimization ("calculates the 'best' retrieval path".) That system's about as relational as they come. Rich
brianc@daedalus (Brian Colfer) (03/08/88)
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 ==========================================================================