Re: [sqlite] What is a Relation?

[Simon Slavin]

On 27 Jul 2009, at 7:37pm, Paul Claessen wrote:

> So .. would anyone know a good book for seasoned programmers, who  
> are new to databases, that addresses all these issues?

If you're a seasoned programmer you probably don't need my advice.   
The problem is not databases, it's an understanding of how data in  
general can be handled: most RDBS systems are really just clever and  
intensive applications of balanced trees.  The archetypal books are

Knuth: _Art of Computer Programming_

once you've looked at those try

Aho, Ullman, Hopcroft: _Data Structures and Algorithms_

but these days you can learn a hell of a lot just Googling for  
'introduction theory RDBS' or variations on it.  Textbooks might be  
obsolete.  And I'm sorry but I learned this stuff so long ago I can no  
longer evaluate which books are good at teaching it: I can't put  
myself in the shoes of a learner.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] What is a Relation?

[Darren Duncan]

Paul Claessen wrote:
> So .. would anyone know a good book for seasoned programmers, who are new to 
> databases, that addresses all these issues?

I suggest one of C. J. Date's latest works:

See http://oreilly.com/catalog/9780596523060/ .

SQL and Relational Theory
How to Write Accurate SQL Code
By C.J. Date
January 2009
Pages: 426
Series: Theory In Practice
ISBN 10: 0-596-52306-8 | ISBN 13: 978059652306

Description
Understanding SQL's underlying theory is the best way to guarantee that your 
SQL 
code is correct and your database schema is robust and maintainable. In SQL and 
Relational Theory, author C.J. Date demonstrates how you can apply relational 
theory directly to your use of SQL, with numerous examples and clear 
explanations of the reasoning behind them. Anyone with a modest to advanced 
background in SQL will benefit from the many insights in this book.

-- Darren Duncan
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] What is a Relation?

[Rich Shepard]

On Mon, 27 Jul 2009, Paul Claessen wrote:

> So .. would anyone know a good book for seasoned programmers, who are new
> to databases, that addresses all these issues?

Paul,

   Any of Joe Celko's books. His "SQL Programming Style" is particularly good
for an overview. The amazon.com listing lets you examine the ToC, among
other extracts.

   Also, Rick van der Lans's "Introduction to SQL, 4th Ed."

Rich

-- 
Richard B. Shepard, Ph.D.   |  IntegrityCredibility
Applied Ecosystem Services, Inc.|Innovation
 Voice: 503-667-4517  Fax: 503-667-8863
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] What is a Relation?

[John Elrick]

Beau Wilkinson wrote:
>>> There are still people who just want
>>> a cursor to a chunk of data which they pull in and iterate over rather than
>>> use SQL's power to manage data a set-at-a-time
>>>   
>
> I am dealing with such a project now. The schema consists of time stamp plus 
> blob, where the blobs "map" directly to C++ structs. Of course, there are all 
> sorts of useful data items in those blobs, and many of the capabilities of 
> SQL are lost by reducing data to blobs. I think this is an extreme example of 
> what you describe. The architectural excuse given was, I think, performance.
>
>   
>>> Call me old fashioned but object-relational mappers worry me on this score
>>>   
>
> I agree, except that you're not old-fashioned. In fact, I think you're on the 
> cutting edge here. OO (including any attempt to apply it to database work) is 
> no longer trendy. At best, it is tolerated... perhaps many people still 
> haven't admitted that the proverbial emporer has no clothes, but no one's 
> bragging about his (i.e. OOP's) new jacket, either.
>
> Microsoft, for example, is moving rapidly to functional programming and 
> generic programming. Implementation inheritance has been lobotomized in C# 
> compared to C++, for example, and Microsoft's new "Linq" database client 
> technology is functional and generic.
>
> As for ORM, OODBMS (whatever that is), etc. proponents of such technologies 
> continue to hem and haw about "object-relational impedance." This is just  a 
> fancy way of describing the problems that result when a good (Relational) 
> model of reality must interface with a dysfunctional (OO) model. OO creates 
> problems (or "opportunities"...) because it doesn't work. MIT has been saying 
> this for 30 years. Few people are willing to consciously stick their necks 
> out and say, "you know, I've always thought OOP was a bunch of B.S" but the 
> sentiment's out there and it's justified.

I believe this is too broad a condemnation.  Every approach has 
limitations and areas where it is more or less useful; Object Oriented 
programming is no exception, and the fact that OO has been misused does 
not in and of itself support the assertion that it is "dysfunctional".

To highlight two examples, functional languages such as Haskell are 
elegant and pure...until you add petty, non-deterministic things such as 
I/O and user interactions.  Monads are a workaround, and even their 
physical and syntactic representation demonstrate the limitations of the 
pure functional approach.

Example two is an oft asked issue with SQL in general.  One of the most 
common needs of a system which interacts with a human being via a 
graphic interface is the ability to reference an object by its position 
within a given resultset.  Although there are many workarounds for this 
issue, workarounds they are and a strategy which is both fast and 
non-cumbersome for accessing the nth element in a given resultset via 
pure SQL continues to elude the profession.

The fact that monads are cumbersome and SQL cannot easily return results 
which can be accessed as though they were an array are not indictments 
of Haskell or SQL.  Likewise the obvious issues of attempting a simple 
mechanism for persisting in-memory objects to an auxiliary storage 
medium are limitations of the Object Oriented approach, and, in my 
opinion, should not be considered a condemnation of Object Oriented 
design as a whole.

Our organization has been using OO based languages for over a decade 
and, while we have encountered cases where other approaches are 
superior, we have found it in general to be an excellent method for 
solving our client's problems.

FWIW


John Elrick
Fenestra Technologies


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] What is a Relation?

[Darren Duncan]

Rich Shepard wrote:
> On Mon, 27 Jul 2009, Darren Duncan wrote:
>> Object orientation has nothing to do with all this per se, though objects
>> can easily be mapped to tuples.
> 
>A related issue is that object orientation is almost always used in the
> context of procedural languages (e.g., C++, Python, Ruby) while SQL is _not_
> a procedural language. SQL is a language for working with sets (tables, or
> relations).

I think I realized after I said it that I should have stated that last point 
better.  What I meant to say is that ...

Object orientation is just syntactic sugar for working with values, types, 
routines/functions, etc, and OO issues are orthogonal to the relational model 
of 
data; you can talk about relations/etc without talking about OO.

Also, given that in typical OO languages, an object can represent either an 
(immutable) value or a (mutable) variable, all of the concepts in the 
relational 
model or in SQL can be cleanly represented by objects.

Relations (rowsets) and tuples (rows) are *values*, and are fundamentally 
immutable, same as numbers/etc; they are like having array or hash-map values 
of 
a typical programming language.  You can give them as arguments to functions, 
return them from functions, assign them to variables, etc.  So SQL tables are 
essentially variables that hold relation values; when you make a change to a 
table, you are substituting its previous relation value for a new one, 
conceptually the same thing as when you change a numeric variable.

The relational types and operators can all be implemented in general purpose 
languages if one wanted to and integrated into a normal program.  For example, 
see http://search.cpan.org/dist/Set-Relation/ where I did just that; note that 
this is more of a demonstration, and I'm sure any SQL DBMS has it beat for 
performance.

-- Darren Duncan
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] What is a Relation?

[Paul Claessen]

So .. would anyone know a good book for seasoned programmers, who are new to 
databases, that addresses all these issues?

~ Paul Claessen

> -Original Message-
> From: sqlite-users-boun...@sqlite.org 
> [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Simon
> Slavin
> Sent: Monday, July 27, 2009 12:34 PM
> To: j...@kreibi.ch; General Discussion of SQLite Database
> Subject: Re: [sqlite] What is a Relation?
> 
> 
> On 27 Jul 2009, at 2:49pm, Jay A. Kreibich wrote:
> 
> >  That's because most people are, unfortunately, taught SQL in a vacuum
> >  with none of the theory or background.
> 
> 
> Yes yes.  Hence the recent rash of people on this list who can't dry-
> run their software, don't understand what an index is, have no
> appreciation of how to guess him much work a computer is doing, etc..
> This is a big problem in the industry in general: they teach you how
> to declare an index without explaining why or what kind of index will
> help you.
> 
> I keep wanting to scream "If you don't grok the need you shouldn't be
> a programmer to start with.".  But it's not their fault, it's their
> bosses' fault.
> 
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] What is a Relation?

[Simon Slavin]

On 27 Jul 2009, at 2:49pm, Jay A. Kreibich wrote:

>  That's because most people are, unfortunately, taught SQL in a vacuum
>  with none of the theory or background.


Yes yes.  Hence the recent rash of people on this list who can't dry- 
run their software, don't understand what an index is, have no  
appreciation of how to guess him much work a computer is doing, etc..   
This is a big problem in the industry in general: they teach you how  
to declare an index without explaining why or what kind of index will  
help you.

I keep wanting to scream "If you don't grok the need you shouldn't be  
a programmer to start with.".  But it's not their fault, it's their  
bosses' fault.

Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] What is a Relation?

[Beau Wilkinson]

>> Rich Shepard wrote:
>>What is more unfortunate is when someone with greater knowledge takes over
>> a project but is prevented from re-doing it in a more efficient way because
>> someone else's ego will be bruised or the powers that be cannot appreciate
>> the need.

I think my knowledge is just broader than my predecessor on that project. He 
cultivated a really detailed knowledge of the Windows / Intel platform, which 
didn't seem to allow any time or brainpower to learn about more general 
concepts.

I try to be more of a generalist, although it can be unpopular. My colleagues 
seem to prefer to pick a single nascent technology and cling mightily to it 
until they perceive something better. Trying to discuss architecture with 
people who do that is like talking to someone in a cult... no matter what the 
topic or question is, the discussion eventually flows back to You Know What. 
The sad result is that I end up gravitating toward maintenance programming, 
simply because the arguments have already been had.

From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] On 
Behalf Of Rich Shepard [rshep...@appl-ecosys.com]
Sent: Monday, July 27, 2009 10:46 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] What is a Relation?

On Mon, 27 Jul 2009, Beau Wilkinson wrote:

> I am dealing with such a project now. The schema consists of time stamp
> plus blob, where the blobs "map" directly to C++ structs. Of course, there
> are all sorts of useful data items in those blobs, and many of the
> capabilities of SQL are lost by reducing data to blobs. I think this is an
> extreme example of what you describe. The architectural excuse given was,
> I think, performance.

   I'm not a professional coder or DBA, but I've been writing code and
building database applications for about 3 decades. The problem, I believe,
is shifting paradigms and the difficulties people have in doing so.

   The original spaghetti-code model I used with FORTRAN in the early 1970s
gave way to structured programming with C. Most of us still effectively use
structured programming with procedural languages, either compiled or
interpreted. While OO is a nice concept, and does have use in the
appropriate applications, it produces bloated binaries because all classes
in the hierarchy need to be compiled and included, even if one function is
all that's needed. However, even within the huge tribe of procedural
languages, there are different paradigms that one needs to understand to
most efficiently use a language. The differences between C and Common LISP
immediately come to mind.

   Regardless, it is very common to see those new to SQL take whatever
knowledge and experience they have with procedural languages and try to
apply it to working with sets. Your project summarized above seems to be an
example of this. Trying to apply the flow control and other structures of a
procedural language to SQL tends to result in a mess. Too few books or other
resources stress these differences so newcomers are taught to look at the
whole database manipulation language (principally the SELECT statement) in a
different way.

   What is more unfortunate is when someone with greater knowledge takes over
a project but is prevented from re-doing it in a more efficient way because
someone else's ego will be bruised or the powers that be cannot appreciate
the need.

Rich

--
Richard B. Shepard, Ph.D.   |  IntegrityCredibility
Applied Ecosystem Services, Inc.|Innovation
<http://www.appl-ecosys.com> Voice: 503-667-4517  Fax: 503-667-8863
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

The information contained in this e-mail is privileged and confidential 
information intended only for the use of the individual or entity named.  If 
you are not the intended recipient, or the employee or agent responsible for 
delivering this message to the intended recipient, you are hereby notified that 
any disclosure, dissemination, distribution, or copying of this communication 
is strictly prohibited.  If you have received this e-mail in error, please 
immediately notify the sender and delete any copies from your system.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] What is a Relation?

[Rich Shepard]

On Mon, 27 Jul 2009, Beau Wilkinson wrote:

> I am dealing with such a project now. The schema consists of time stamp
> plus blob, where the blobs "map" directly to C++ structs. Of course, there
> are all sorts of useful data items in those blobs, and many of the
> capabilities of SQL are lost by reducing data to blobs. I think this is an
> extreme example of what you describe. The architectural excuse given was,
> I think, performance.

   I'm not a professional coder or DBA, but I've been writing code and
building database applications for about 3 decades. The problem, I believe,
is shifting paradigms and the difficulties people have in doing so.

   The original spaghetti-code model I used with FORTRAN in the early 1970s
gave way to structured programming with C. Most of us still effectively use
structured programming with procedural languages, either compiled or
interpreted. While OO is a nice concept, and does have use in the
appropriate applications, it produces bloated binaries because all classes
in the hierarchy need to be compiled and included, even if one function is
all that's needed. However, even within the huge tribe of procedural
languages, there are different paradigms that one needs to understand to
most efficiently use a language. The differences between C and Common LISP
immediately come to mind.

   Regardless, it is very common to see those new to SQL take whatever
knowledge and experience they have with procedural languages and try to
apply it to working with sets. Your project summarized above seems to be an
example of this. Trying to apply the flow control and other structures of a
procedural language to SQL tends to result in a mess. Too few books or other
resources stress these differences so newcomers are taught to look at the
whole database manipulation language (principally the SELECT statement) in a
different way.

   What is more unfortunate is when someone with greater knowledge takes over
a project but is prevented from re-doing it in a more efficient way because
someone else's ego will be bruised or the powers that be cannot appreciate
the need.

Rich

-- 
Richard B. Shepard, Ph.D.   |  IntegrityCredibility
Applied Ecosystem Services, Inc.|Innovation
 Voice: 503-667-4517  Fax: 503-667-8863
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] What is a Relation?

[Beau Wilkinson]

>> There are still people who just want
>> a cursor to a chunk of data which they pull in and iterate over rather than
>> use SQL's power to manage data a set-at-a-time

I am dealing with such a project now. The schema consists of time stamp plus 
blob, where the blobs "map" directly to C++ structs. Of course, there are all 
sorts of useful data items in those blobs, and many of the capabilities of SQL 
are lost by reducing data to blobs. I think this is an extreme example of what 
you describe. The architectural excuse given was, I think, performance.

>> Call me old fashioned but object-relational mappers worry me on this score

I agree, except that you're not old-fashioned. In fact, I think you're on the 
cutting edge here. OO (including any attempt to apply it to database work) is 
no longer trendy. At best, it is tolerated... perhaps many people still haven't 
admitted that the proverbial emporer has no clothes, but no one's bragging 
about his (i.e. OOP's) new jacket, either.

Microsoft, for example, is moving rapidly to functional programming and generic 
programming. Implementation inheritance has been lobotomized in C# compared to 
C++, for example, and Microsoft's new "Linq" database client technology is 
functional and generic.

As for ORM, OODBMS (whatever that is), etc. proponents of such technologies 
continue to hem and haw about "object-relational impedance." This is just  a 
fancy way of describing the problems that result when a good (Relational) model 
of reality must interface with a dysfunctional (OO) model. OO creates problems 
(or "opportunities"...) because it doesn't work. MIT has been saying this for 
30 years. Few people are willing to consciously stick their necks out and say, 
"you know, I've always thought OOP was a bunch of B.S" but the sentiment's out 
there and it's justified.


From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] On 
Behalf Of CityDev [nab...@recitel.net]
Sent: Monday, July 27, 2009 9:33 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] What is a Relation?

It's true that Codd and Date used the term 'relational' (They championed the
N-ary Relational Model - others were around at the same time) but it's not
easy to track the origin of the term in mathematics. Certainly the word
implies joining things together. I guess the joining refers to fields
(domains) within each row (n-tuple).

If you look at other forums you often see novices (and others) using the
word 'relate' as if it is some special way of joining information between
two tables. They also clearly feel that you need to declare foreign keys in
order to have a logical connection between tables. As you are no doubt
aware, one of the guiding principles of the relational model is there is
nothing that is not a data value so you are totally free to join anything to
anything as long as you feel it might make sense. Relationships between
tables are contingent - they can be there one day and gone the next. Any
persistent relationship information (eg foreign keys) is optional and there
for other purposes (eg documentation or referential integrity enforcement).

Another common conceptual misunderstanding I've seen over the years is that
the database is just a fancy filestore. There are still people who just want
a cursor to a chunk of data which they pull in and iterate over rather than
use SQL's power to manage data a set-at-a-time. Call me old fashioned but
object-relational mappers worry me on this score.

--
View this message in context: 
http://www.nabble.com/What-is-a-Relation--tp24674278p24681797.html
Sent from the SQLite mailing list archive at Nabble.com.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

The information contained in this e-mail is privileged and confidential 
information intended only for the use of the individual or entity named.  If 
you are not the intended recipient, or the employee or agent responsible for 
delivering this message to the intended recipient, you are hereby notified that 
any disclosure, dissemination, distribution, or copying of this communication 
is strictly prohibited.  If you have received this e-mail in error, please 
immediately notify the sender and delete any copies from your system.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] What is a Relation?

[Doug Currie]

On Jul 27, 2009, at 10:33 AM, CityDev wrote:

> It's true that Codd and Date used the term 'relational' (They  
> championed the
> N-ary Relational Model - others were around at the same time) but  
> it's not
> easy to track the origin of the term in mathematics.

http://en.wikipedia.org/wiki/Relation_(mathematics)

e


___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] What is a Relation?

[Jean-Denis Muys]

On 7/27/09 16:33 , "CityDev"  wrote:

> 
>  it's not
> easy to track the origin of the term in mathematics.

For what it's worth (ie probably not much), my formal mathematics training
in set theory taught me that a relation from a set A to a set B is a subset
R of the cartesian product AxB.

The special cases on A, B and R lead to further definitions and properties,
eventually leading to group and field theory. I would have to go back to
Evariste Galois' work to check whether he already used the term "relation"
though.

Jean-Denis



___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] What is a Relation?

[CityDev]

It's true that Codd and Date used the term 'relational' (They championed the
N-ary Relational Model - others were around at the same time) but it's not
easy to track the origin of the term in mathematics. Certainly the word
implies joining things together. I guess the joining refers to fields
(domains) within each row (n-tuple).

If you look at other forums you often see novices (and others) using the
word 'relate' as if it is some special way of joining information between
two tables. They also clearly feel that you need to declare foreign keys in
order to have a logical connection between tables. As you are no doubt
aware, one of the guiding principles of the relational model is there is
nothing that is not a data value so you are totally free to join anything to
anything as long as you feel it might make sense. Relationships between
tables are contingent - they can be there one day and gone the next. Any
persistent relationship information (eg foreign keys) is optional and there
for other purposes (eg documentation or referential integrity enforcement).

Another common conceptual misunderstanding I've seen over the years is that
the database is just a fancy filestore. There are still people who just want
a cursor to a chunk of data which they pull in and iterate over rather than
use SQL's power to manage data a set-at-a-time. Call me old fashioned but
object-relational mappers worry me on this score.

-- 
View this message in context: 
http://www.nabble.com/What-is-a-Relation--tp24674278p24681797.html
Sent from the SQLite mailing list archive at Nabble.com.

___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] What is a Relation?

[Jay A. Kreibich]

On Sun, Jul 26, 2009 at 11:42:23PM -0700, CityDev scratched on the wall:
> 
> Just to kill time over coffee - what do you take the word to mean?

  http://en.wikipedia.org/wiki/Relational_model

  A "relation" is a data structure that anyone familiar with SQL would
  call a table.  It comes from the Relational Model, a formal
  mathematical system devised by E.F. Codd in the late 1960s, and is
  the basis for all modern SQL database systems.

> Chris Date was very specific that a relation was essentially a table. 

  C.J. Date is one of the people that worked with Codd.  Pick you
  cliche: He's forgotten more about formal database theory than most
  of us will every know, or how his little finger knows more about
  database theory than most of us, etc.  He's that kind of authority.

> Mainly however, people seem to use the word to describe the
> connections you can make by performing joins between tables.

  That's because most people are, unfortunately, taught SQL in a vacuum
  with none of the theory or background.  Since it is common to call
  the links between tables "relationships" (e.g. "one-to-many
  relationship"), people without any theory knowledge tend to assume
  this is what "relation" is all about.  That's only sorta-kinda true
  in a very abstract way.

  "What does the 'R' in RDBMS stand for?" makes a great DBA interview
  question.  If you're hiring a full-time DBA, it weeds out those that
  know and care about their craft from those that just know some SQL.
  I wouldn't expect that kind of theory and history knowledge from a
  programmer that was using a database, but I do expect it of a DBA
  that does nothing but manage and design databases.
  
   -j

-- 
Jay A. Kreibich < J A Y  @  K R E I B I.C H >

"Our opponent is an alien starship packed with atomic bombs.  We have
 a protractor."   "I'll go home and see if I can scrounge up a ruler
 and a piece of string."  --from Anathem by Neal Stephenson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] What is a Relation?

[Rich Shepard]

On Mon, 27 Jul 2009, Darren Duncan wrote:

> Object orientation has nothing to do with all this per se, though objects
> can easily be mapped to tuples.

Darren,

   A related issue is that object orientation is almost always used in the
context of procedural languages (e.g., C++, Python, Ruby) while SQL is _not_
a procedural language. SQL is a language for working with sets (tables, or
relations).

Rich

-- 
Richard B. Shepard, Ph.D.   |  IntegrityCredibility
Applied Ecosystem Services, Inc.|Innovation
 Voice: 503-667-4517  Fax: 503-667-8863
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] What is a Relation?

[Darren Duncan]

CityDev wrote:
> Just to kill time over coffee - what do you take the word to mean?
> 
> I've just been reading a 1991 James Martin book on Object Orientation and he
> was using it to talk about links between entities. Chris Date was very
> specific that a relation was essentially a table. Mainly however, people
> seem to use the word to describe the connections you can make by performing
> joins between tables. What do you think is 'correct'? How did the other
> meaning gain currency?

In the context of relational databases or mathematics, you want to use Chris 
Date's meaning, which comes from mathematics dating from before we had 
computers 
as we know them today.

A relation is a set of tuples where all tuples are of the same degree and have 
the same set of attribute names/types.  For example, you can have a "people" 
relation where each tuple represents a "person" and every tuple has 3 
attributes, ["name", "birthdate", "address"].

A relation gets its name from that, for every tuple in it, each attribute value 
is related to the other attribute values.  For example, in a "person" tuple 
["Joe", "Feb 17, 1989", "53 Cherry Dr."], the "Joe" is related to "53 Cherry 
Dr."] and so on.

A relational database is called that because it consists of a set of relations, 
each of which having a name.

SQL uses the terms ["rowset","row","column/field"] to refer to a 
["relation","tuple","attribute"], and the term "table" to refer to a 
relation-typed variable, such being what a persisting database consists of.

A relational join is an operation that takes several relation values (rowsets) 
as input and combines them to yield another relation value (rowset) as output, 
such that member tuples (rows) are matched up with each other and catenated 
into 
a new set of tuples (rows).

So the term relation refers both to the contents of a SQL table *and* to a 
process of connecting tables.

Object orientation has nothing to do with all this per se, though objects can 
easily be mapped to tuples.

-- Darren Duncan
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users