normb@sequent.UUCP (Norm Browne) (07/19/89)
In article <AYknCfy00WB28IU6sk@andrew.cmu.edu> bg0l+@andrew.cmu.edu (Bruce E. Golightly) writes: >There are indeed times when you can't think in terms of the relational >model. Sometimes the users insist that they want what they want, and you >can't do it without breaking the model. We had to write an application ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >to do this kind of thing a while back. > [At the risk of being labeled a heretic in the contemporary dbms world. :-)] Does it strike anyone else that the above kind of statement indicates that the relational model is not a very accurate depiction of the real world? I concluded my graduate studies at Claremont Grad in I.S. last spring and this was one of the areas that I researched. I could find no substantiation that the relational model _really_ represented real world applications. Was my research simply incomplete? If so, please recommend some readings (conceptual modeling, semantic aspects of rdbms, etc.) that `prove' the ``realness'' of relational. (On the same line of thought what about the `intuitiveness' of the relational model, i.e. users more easily comprehend the relational approach than [hierarchical,network] dbms). If my failure to turn up any supporting evidence was not oversight, then why has no one bothered to work on the subject? BTW- I am not attacking relational per se (so cool the flamethrowers :-)), it just seems that the theory is lacking some empirical support. ---------------------------==========================-------------------------- Norm Browne <insert standard disclaimer> "Mathematics has nothing to do with the real world." -Richard Pick ===========================--------------------------==========================
tomg@ntpdvp1.UUCP (Thomas Groot) (07/21/89)
The group I'm in writes database applications for various tasks
on the factory floor. We've been at it for three or four years,
using both hierarchical and relational database engines. My
experience is that our users (high-school and college-educated)
tend to think in hierarchical terms: they see a single, sequential
set of data which they step forward and backward through. With
our most recent work in relational systems, it seems we end up
writing hierarchical interfaces to relational data models.
Maybe this is poor design on our part, but our customers are
happy. ;-) I would have a hard time explaining to some of
them how to view data in a relational manner.
In a recent evaluation we did of Oracle, one of our main problems
with their tools was lack of support for previous record retrieval.
Our customers expect to do previous record retrieval, even though
most of our application internals are relational.
------------------------------------+---------------------------------
Thomas Groot | [Now] even the freshest puns
Northern Telecom DMS-10 Division | circulate globally
Dept. 2154 NTP | at the speed of light and
P. O. Box 13010 | fade away like the morning dew.
Research Triangle Park, NC 27709 |
(919) 992-2610 | Stan Kelly-Bootle
------------------------------------+---------------------------------dbruck@ciss.Dayton.NCR.COM (Don Bruck@ciss.Dayton.NCR.COM) (07/22/89)
In article <18886@sequent.UUCP> normb@sequent.UUCP (Norm Browne) writes: >In article <AYknCfy00WB28IU6sk@andrew.cmu.edu> bg0l+@andrew.cmu.edu (Bruce E. Golightly) writes: >>There are indeed times when you can't think in terms of the relational >>model. Sometimes the users insist that they want what they want, and you >>can't do it without breaking the model. We had to write an application > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>to do this kind of thing a while back. >> > >[At the risk of being labeled a heretic in the contemporary dbms world. :-)] > > Does it strike anyone else that the above kind of > statement indicates that the relational model is > not a very accurate depiction of the real world? > <<< deleted stuff >>> > >BTW- I am not attacking relational per se (so cool the flamethrowers :-)), >it just seems that the theory is lacking some empirical support. > I wish to agree with both writers. The relational model implies that the world is un-ordered, that A is not necessarily the the predecessor to B, as in the word BAD. The relational model therefore does not support "PREVIOUS" and I understand the reasons. What bothers me is that some companies use this excuse and then support other things not in the relational model such as "NEXT" and indices. A solution to this is to realize that DATA and PROCESS are significantly different. Data is random, process is ordered. Store data randomly and allow the processes to order it as needed for the process. In this way of looking at the problem INDEXing, "NEXT", and "PREVIOUS" are part of the process. The INDEX is a tool of the process's need for "NEXT" "PREVIOUS" "LAST" "FIRST" and all of the other ordering functions needed. ------------------------------------------------------------------------------- Don Bruck My opinions are my own and my wife does know I have them.
mark@intek01.UUCP (Mark McWiggins) (07/22/89)
normb@sequent.UUCP (Norm Browne) writes: >[At the risk of being labeled a heretic in the contemporary dbms world. :-)] > Does it strike anyone else that the above kind of > statement indicates that the relational model is > not a very accurate depiction of the real world? >I concluded my graduate studies at Claremont Grad in I.S. last spring and >this was one of the areas that I researched. I could find no substantiation >that the relational model _really_ represented real world applications. >Was my research simply incomplete? If so, please recommend some readings >(conceptual modeling, semantic aspects of rdbms, etc.) that `prove' the >``realness'' of relational ... >If my failure to turn up any supporting evidence was not oversight, then >why has no one bothered to work on the subject? >BTW- I am not attacking relational per se (so cool the flamethrowers :-)), >it just seems that the theory is lacking some empirical support. The empirical support is everywhere: scads of working applications based on the relational model that deal more-or-less appropriately with real-world stuff. Why bother with any other proof? This is not to say that relational is always "best"; that depends on what you're doing. It's like any other language system. Some constructs that flow beautifully in one model are a total clunk in another. >---------------------------==========================-------------------------- >Norm Browne ><insert standard disclaimer> > "Mathematics has nothing to do with the real world." -Richard Pick >===========================--------------------------========================== Mark McWiggins Integration Technologies, Inc. (Intek) 1400 112th Ave. SE #202 Bellevue WA 98004 (206) 455-9935 uunet!intek01!mark
jkrueger@daitc.daitc.mil (Jonathan Krueger) (07/23/89)
In article <18886@sequent.UUCP>, normb@sequent (Norm Browne) writes: >I could find no substantiation >that the relational model _really_ represented real world applications. Lewis Carroll used to enjoy describing his map of England, which, he said, was better than all others. It represented the territory more accurately. In fact, it showed every detail: private roads, property boundaries, interiors of buildings, items on shelves, every leaf on every tree, the contents of every cell in every leaf. It managed this feat by using a 1:1 scale, which also lent the advantage that you could explore it quite literally. Everything you could see in the map was exactly true of England. In fact, it was England. England is a map of England. A perfect one. Also, a useless one: the first thing you need is a map of this map, of the sort you can carry around with you, for instance. Carroll's point was that all real maps are distortions, by necessity. The reasoning is by the contrapositive from the premise: if a map is NOT a distortion, it's not useful. This premise is easily granted by examining the denerate case. If the map is indistinguishable from the territory, in no way does it distort, and it's also completely useless (as a map). Therefore, if a map would be useful, it MUST differ in some way from the original. (Of course, the mere fact of differences does NOT prove usefulness: differences are necessary but not sufficient to make the map useful.) The same point can be made informally: why do we want maps anyway? Very much because they summarize and abstract some facts about the territory. In so doing, they all distort. Roads are shown as wider than they really are, for instance. Were they shown to scale, they'd be hard to draw and even harder to read. Map features such as borders are drawn inaccurately or out of scale, or omitted altogether. Were they correct in every particular, some would obscure the map features that users need to find. Even those that didn't would still drive up the production time and cost to years and millions. Users might prefer maps showing 90% as many details relevant to their use which cost 10% as much and were available in their lifetimes. So, have I made my point here? Or do I have to draw a map for ya? :-) Maps are models. Models are the general case. Good models MUST distort. Therefore, the question is not how well the model represents the real world, but how usefully. That the model omits or simplifies its account of the real world is NOT a fault, but rather a prerequisite for it ever to be useful. To avoid a potential area of confusion, the word `application', as in "the relational model _really_ represented real world applications", has two common usages: the task to be performed, and a computer program or set of them that is said to automate the task. In this article I have meant the first usage. The second may have been intended by Norm, however. If so, he's saying that he has no evidence that two models represent each other. This is probably true, and of no great consequence. How programs resemble each other is about as interesting as how maps resemble each other. How maps represent the territory in useful ways is more interesting, and similarly how programs automate tasks. -- Jon --
paul@csnz.co.nz (Paul Gillingwater) (07/24/89)
In article <18886@sequent.UUCP> normb@sequent.UUCP (Norm Browne) writes: >In article <AYknCfy00WB28IU6sk@andrew.cmu.edu> bg0l+@andrew.cmu.edu (Bruce E. Golightly) writes: >>There are indeed times when you can't think in terms of the relational >>model. Sometimes the users insist that they want what they want, and you >>can't do it without breaking the model. We had to write an application > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>to do this kind of thing a while back. > Does it strike anyone else that the above kind of > statement indicates that the relational model is > not a very accurate depiction of the real world? > >this was one of the areas that I researched. I could find no substantiation >that the relational model _really_ represented real world applications. >Norm Browne Experience tends to confirm that the relational approach is not an accurate model for all real-world situations. I could present an empirical "proof", but I'm not well enough versed in formal logic to present a rigorous argument for this. ;-) It seems "intuitive" to me that an object-oriented OODBMS is better at mapping real world situations. Further, there are some cases where a relational approach is very limited, e.g. large text databases, where a record may contain from a few bytes to several megabytes. This is where software like BRS/Search, which indexes *every single word*, is very useful. Relational approaches have their place -- although the implementations sometimes lack efficiencies in dealing with diverse data sets -- but I would not reject the relational approach in all cases. IBM have done a lot of work with other models, e.g. CODASYL. Here's a good example of a database which doesn't fit well with the relational approach: The Bible! Yes, I have this working just fine under BRS/Search... less than three seconds to find any chosen verse, based on keyword searching. -- Paul Gillingwater, Computer Sciences of New Zealand Limited Bang: ..!uunet!dsiramd!csnz!paul Domain: paul@csnz.co.nz Call Magic Tower BBS V21/23/22/22bis 24 hrs +0064 4 767 326
normb@sequent.UUCP (Norm Browne) (07/24/89)
In article <606@daitc.daitc.mil> jkrueger@daitc.daitc.mil (Jonathan Krueger) writes: >In article <18886@sequent.UUCP>, normb@sequent (Norm Browne) writes: >>I could find no substantiation >>that the relational model _really_ represented real world applications. > > [long digression on maps to the make the point that a model *isn't* > the real world] >-- and >From: mark@intek01.UUCP (Mark McWiggins) >Message-ID: <220@intek01.UUCP> > >The empirical support is everywhere: scads of working applications based >on the relational model that deal more-or-less appropriately with >real-world stuff. Why bother with any other proof? I concede the obvious above points on maps (models) as abstractions and lots of working applications. Now, back to the [basically academic] point I was trying to get at... One of the relational model's [supposed] major advantages is that it has a THEORETICAL underpinning (mathematical set theory). This is why it is ``superior'' to the Codasyl or hierarchical models. Does set theory really reflect the real world?[1] Is it more intuitive? What I could not find was substantiation of this (if the theory is `valid' there should be supporting empirical evidence, otherwise it's like economics :-) ). I have used DBMSs based on all three models and each had unique functionality, strengths, and weaknesses, so this is really a question about theory. BTW- answers that include ``thinking relationally'' do not qualify. In a separate thread was a discussion of normalization, E-R and relational. Normalization and E-R can be applied to network and hierarchical DBs so they also do not differentiate relational DBs. [1] Let me give a specific example. Set theory dictates that order is irrelevant (i.e. unordered sets). What real world application looks at data [usefully] as unordered? The first thing that is added is an index which is *NOT* part of set theory! ----Norm
jkrueger@daitc.daitc.mil (Jonathan Krueger) (07/25/89)
In article <19101@sequent.UUCP>, normb@sequent (Norm Browne) writes: >Does set theory really reflect the real world? [1] Sometimes, in some ways, which are occasionally useful. We could say the same about the integers. When I'm counting cookies and one of them breaks into halves, have we shown how poorly suited integers are for counting real world objects? >Is [set theory] more intuitive? Than what? For what? >What I could not find was substantiation of this (if the theory is >`valid' there should be supporting empirical evidence, otherwise it's >like economics :-) ). Okay, what would you accept as substantiation? If you can't specify what constitutes counterevidence, well, you don't want to be like economics, do you? :-) >[1] Let me give a specific example. Set theory dictates that order is > irrelevant (i.e. unordered sets). What real world application looks > at data [usefully] as unordered? The first thing that is added is > an index which is *NOT* part of set theory! Sorted != ordered != indexed. Grouping != inherent ordering of pairs != access methods. -- Jon --
elgie@canisius.UUCP (Bill Elgie) (07/25/89)
In article <19101@sequent.UUCP>, normb@sequent.UUCP (Norm Browne) writes: > > One of the relational model's [supposed] major advantages is that it has a > THEORETICAL underpinning (mathematical set theory). This is why it is > ``superior'' to the Codasyl or hierarchical models. Does set theory really > reflect the real world?[1] Is it more intuitive? > I do not understand this supposition, that a database "model" is supposed to "reflect the real world". Why ? Given the broad range of applications for which database systems have been implemented, it seems awfully simplis- tic to me to make such a generalization about any conceivable database model. Is there ANY model of ANY kind (dbms, economic, whatever) that can be said to "reflect the real world" ? Or simply certain instances/subsets of it ? A given database application must "reflect the real world" of the particular organization, or project, or whatever, for which that application was devel- oped (if that database is to be successful); the individual designing the database must structure it so that it does, in fact, reflect the organization, etc, faithfully; in my opinion: it is easier to do so using a database adhering to the CODASYL or hierar- chical model if the application model happens to fit AND if the applica- tion model remains static; it is easier to do so using a relational model dbms otherwise, precisely because the relational model is closest to being a "clean slate" by not trying to "reflect the real world". The relevance of a set theory under- pinning is NOT that it provides a view of a human organizational structure but that it provides a view of organized computer data which is replicable, robust, and, at the same time, flexible. It is up to the implementor of an application to establish a "reflection". In my opinion, this is more difficult to do and maintain (the real world tends to be dynamic) using dbms's based on models which attempt to mix data organization with human organization. > Normalization and E-R can be applied to network and hierarchical DBs so > they also do not differentiate relational DBs. > Much of what is considered to constitute the "relational data model" applies to (or should apply) to the design of a database for most applications: it is good S.O.P. greg pavlov (under borrowed account), fstrf, amherst, ny
stuart@bms-at.UUCP (Stuart Gathman) (07/27/89)
SQL and 'C' terminology used below:
Ordering in a relational system is like 'int' in 'C'. When no order is
specified, you get the most efficient order for the implementation. If
a specific order is desired, it can be requested. ("SORT BY").
'INDEX' is an optimization hint to the system, like 'register' in 'C'.
One thing in the relational model I disagree with: Duplicate records are
useless in any order. All tables should be required to have a "UNIQUE"
combination of fields. After all, we are dealing with *sets*, not *bags*. :-)
--
Stuart D. Gathman <stuart@bms-at.uucp>
<..!{vrdxhq|daitc}!bms-at!stuart>bg0l+@andrew.cmu.edu (Bruce E. Golightly) (07/27/89)
You need to be careful with the UNIQUE atribute. We had/have a considerable problem in this area. We converted our Telecommunications billing system to a relational database a couple of years ago. One of the things that nearly drove us nuts during the development was an attempt to duplicate output from an old COBOL based system. We were loosing records. We eventually discovered that the records being "lost" were being eliminated by the data base as duplicates. (NOTE: The dropping of dups here was the result of a poorly written WHERE clause) One examination, these records were found to be identical to any number of decimal places you care to name. It turns out that the granularity available within certain long distance operations is not fine enough to distinguish between two calls from the same phone to the same phone within a short period of time. And they wonder why my hair is turning grey and falling out! Bruce
davidm@cimshop.UUCP (David Masterson) (07/28/89)
>One thing in the relational model I disagree with: Duplicate records are >useless in any order. All tables should be required to have a "UNIQUE" >combination of fields. After all, we are dealing with *sets*, not *bags*. :-) > I think that is a requirement of the relational model (as defined by Codd). What we thus far have is a tradeoff that most (all?) database vendors place on the relational model for efficiency sake (can you imagine searching the database on every update to determine if a uniqueness constraint is violated?). Besides, most allow you to put a unique index on the key and enforce the constraint that way. David Masterson uunet!cimshop!davidm
johng@cavs.syd.dwt.oz (John Gardner) (08/01/89)
> >One thing in the relational model I disagree with: Duplicate records are >useless in any order. All tables should be required to have a "UNIQUE" >combination of fields. After all, we are dealing with *sets*, not *bags*. :-) This is precisely what the relational model defines. When the relational model says we have a set of tuples, it means that each tuple must be unique. There is an implicit "UNIQUE" in that all the fieilds combined must be unique. -- /*****************************************************************************/ PHONE : (02) 436 3438 ACSnet : johng@cavs.dwt.oz #include <sys/disclaimer.h> -- /*****************************************************************************/ PHONE : (02) 436 3438 ACSnet : johng@cavs.dwt.oz #include <sys/disclaimer.h>