 | |
The Relational Model & Queries That Naturally Return Duplicate Rows
comp.databases.theory comp.databases.theory
 |
| | Thread Tools | Display Modes |
#21
 
| |||
| |||
|
Re: The Relational Model & Queries That Naturally Return Duplicate Rows -
10-14-2010
, 05:50 PM
|
On Sun, 10 Oct 2010 19:35:44 +1000, Erwin <e.sm... (AT) myonline (DOT) be> wrote: On 10 okt, 04:56, "Joe Thurbon" <use... (AT) thurbon (DOT) com> wrote: In the context of recent discussion on the ttm mailing list regarding * ORDER BY, it's not clear to me that correct answer is indeed obvious. * (In fact, given my track record on cdt, I'm not sure that I am thinking * of the correct answer). With that caveat in mind, given that, with the OP's database, the query SELECT FIRST_NAME from USERS order by FIRST_NAME presents the user with something that is not a relation, it seems * strange to require that SELECT LAST_NAME from USERS should. (Apart from that projection is a relational operator, and order * by isn't, but that seems to me at least to be slightly subtle). Cheers, Joe- - Tekst uit oorspronkelijk bericht weergeven - "slightly subtle" ?????? You mean as in "that difference could equally well not exist at all" ????? No I don't mean that at all. I mean that the distinction requires some * thought and/or experience to arrive at, rather than being obvious. The * 'slightly' was meant to modify the 'subtle'. [...] If one wants SELECT to mean something different than relational projection, then I refer to "Logic and Databases", chapter 12. *There, "bag algebra" is investigated (and its inferiority to relational algebra exposed). In the context of this thread, I don't want SELECT to do any particular * thing. I merely make the point that - given that ORDER BY is seen as useful, and - ORDER BY is not a relational operator (*), that - the argument that SELECT should be the same as relational projection is* not a foregone conclusion. I was not attempting to address the correctness of any answer, just the * obviousness. As to Logic and Databases, I've had the book for a while, but I'm not up * to chapter 12 yet. I'm not sure if I'll ever get there. Chapter 2 worries* me a little - for example the exposition of |- and |= is completely * different from every logic textbook I've ever read. Cheers, Joe (*) by which I mean it doesn't 'return a relation', I'm not sure if I've * used the terminology correctly. |
probably not competent to, anyway) it does mystify me why an
implementation that support relational theory (the original post
seemed to be about SQL db's, not the same thing) can't manage to
produce, in effect, two results, one that is a relation. I don't see
why implementations of relational operators can't 'ignore' facets or
aspects of inputs that are immaterial to the operators.
#22
| |||
| |||
|
|
If someone runs the query "select LAST_NAME from USERS", a typical database will return: LAST_NAME Stone Stone Stone Since this is not a relation - because it contains duplicate rows - what should an ideal RDBMS return? |
Stone
No duplicates. Simple as that. If you want duplicates, just count them
explicitly. In Codd's language, explicitly cause the resulting
relation to be "framed", as in:
LAST_NAME, COUNT
Stone, 3
#23
| |||
| |||
|
|
If you want duplicates, just count them explicitly. In Codd's language, explicitly cause the resulting relation to be "framed", as in: LAST_NAME, COUNT Stone, 3 |
just relational algebra/calculus. Those are about first order
predicate logic which cannot do this sort of thing. That is then a
reasoned choice by the early relational pioneers; they externalized
arithmetic axioms from the basic relational algebra to make it more
manageable.
That doesn't mean you can't build such operations into your query
language at a higher level. Even Codd called for aggregate and
algebraic operations within a single domain. Especially in his OLAP
work. But that sort of thing is mostly orthogonal to the basic
relational model, and a necessary, or even a wanted, part of it.
#24
| |||
| |||
|
|
Hi, It's commonly understood that in the relational model: * *1. Every relational operation should yield a relation. * *2. Relations, being sets, cannot contain duplicate rows. Imagine a 'USERS' relation that contains the following data. ID FIRST_NAME LAST_NAME *1 Mark * * * Stone *2 Jane * * * Stone *3 Michael * *Stone If someone runs the query "select LAST_NAME from USERS", a typical database will return: LAST_NAME Stone Stone Stone Since this is not a relation - because it contains duplicate rows - what should an ideal RDBMS return? |
cubic equation
x^3 = 9x
? I'd suggest it's
{0,3,3}
#25
| |||
| |||
|
|
Let me rephrase your question a little bit. What are the roots of cubic equation x^3 = 9x ? I'd suggest it's {0,3,3} |
{0,3,-3}
#26
| |||
| |||
|
|
On 20 okt, 20:21, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote: Let me rephrase your question a little bit. What are the roots of cubic equation x^3 = 9x ? I'd suggest it's {0,3,3} ?????????????????????????????? {0,3,-3} |
x^3 = 3x^2
{0,0,3}
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.