Talk:Relational model

A database built on the pure relational model would be entirely normalized.

Under any reasonable interpretation of "entirely normalized" that would seem false to me. The relational model only requires that the relation is in 1NF and according to Chris Date even that is no longer required. -- Jan Hidders 15:05 Mar 4, 2003 (UTC)

Mr. Hidders, I don't remember Chris Date saying "1NF is no longer required" in any of his books. Can you kindly provide us a reference for it? What I know is that a relation is already in 1NF by definition (Warning: Don't confuse "relation" with "table"), and Date extended the definition of 1NF to include relations having relation-valued attributes (i.e., they have attributes whose values themselves are relations). See also Date's What First Normal Form Really Means and Fabian Pascal's What First Normal Form Means NOT for a more precise definition of 1NF. Oops, forgive me for referencing DBDebunk's papers. :-) -- Perry V. 02:53, 18 September 2005 (UTC)

I meant the term "1NF" is it is usually understood by database researchers and practitioners, and not how Chris Date and Fabian Pascal have redefined it. -- Jan Hidders 12:16, 24 January 2006 (UTC)

A tuple is a set of attributes, which are ordered pairs of domain and value.

That's a very sloppy definition if not simply wrong. An attribute should be defined as a pair of attribute name and value, and it should be stated that a tuples cannot contain two attributes with the same name. It's probably better to simply define it as a partial function from attribute names to values. -- Jan Hidders 15:05 Mar 4, 2003 (UTC)

The Information Principle is stated in a misleading way. Not all information in a database is in the values used; rather, it is in the way these values are structured in the database. For example, the value 5 doesn't give us any nformation; but when it is an attribute named Age of a relation named Person, it does, owing to our interpretation of these names. The given examples even use values that have no meaning at all, except to indicate structure!

Date phrases the principle as follows:

 All information in the database must be cast explicitly in terms of values in tables and in no other way.

The addition "in tables" is what is missing from the present text.

More than Codd, Date & Darwen . .

The article is kind of selective when it implies that two individuals are responsible for the subsequent maintenance and development of Codd's original work. Reading the research literature for the period 1975-2000 (TODS, SIGMOD, VLDB), you find that many others made substantial contributions; Fagin, Ullman, Goodman, Beeri, etc. In tone and substance the write-up reflects 'the gospel according to Date & Pascal' and not the more broad perspective found in most text-books.

FWIW, I fully agree. Any concrete suggestions on how to rewrite it? I'm afraid I'm lacking the time to do that properly. -- Jan Hidders 17:47, 1 Jun 2004 (UTC)

Just to chime in here, I was quite surprised that the page wasn't written by Fabian Pascal (honestly). From a neutral POV, there are (to my knowledge) at least three distinctly different constructions of the relational model that differ even in how they define a "tuple":

1. An n-tuple of values (as in Codd's RM/V1,p.379; RM/T, p.399; Elmasri & Navathe, p.128)
2. A set of ordered pairs <attribute-name, value> (e.g. in Codd's RM/T, p.399 and E&N, p.130)
3. A set of ordered triples: <attribute-name, type-name, value> (Date, p.141)

Of these, I would guess that the first is probably the most widely taught and easiest to grasp (but I don't know). Also, the very extreme anti-null stance of Date and Darwen, while deserving of presentation, shouldn't be presented as being essential to the relational model, IMHO, since some constructions of the relational model (Codd's RM/T, p.400), Codd himself until the day he died (IIRC according to Date, anectdotally), and common practice regard nulls as important and useful.

I can see this getting controversial :o)

As a final comment, while others may disagree, the link to DBDebunk seems pretty inappropriate to me - AFAICT (and I've been around that site quite a lot over the last couple of years), it just seems to funnel people into buying stuff and doesn't explain much unless you're prepared to pay $10 for each "paper"; I wouldn't regard it as the least bit useful for anyone who needs to look up "relational model" in an encylopaedia, and (although not that important) it is pretty dreadful (HTML and design-wise).

My 2¢ worth EmmetCaulfield 05:40, 17 Nov 2004 (UTC)

I've removed the link to dbdebunk. I agree with your description of it, and is clearly mainly devoted to selling their papers. Not approriate for an encyclopedia. It was added on 04:14, 9 Sep 2002. If someone wants to defend it, feel free to add it back in. JesseW 09:12, 22 Nov 2004 (UTC)

References to Chen?

Why are there references to Chen on this page? I think they should be on the page on ERDs. Note that ERDs are not part of the relational model and also not a way of describing a relational schema. They are a way of describing a conceptual data model that later may or may not be mapped the data model of a relational database, or to the data model of another type of databases. -- Jan Hidders 14:15, 26 Jun 2004 (UTC)

If you look at references link you should understand how Peter chen references are foundamentals 'cause I can't find other than pdf files for illustrating how the concept taken from chinese written language evolution was adapted to computer science for the creation of the relational model, but I can't find any png or gif on the net, so images and descriptions are on those pdf... look at them, very cool 16:45, 26 Jun 2004 (CET)

Sure, they are interesting, but that is besides the point. They are perhaps fundamental for ERDs but not for the relational model, so I still don't think this article is the most appropriate place for them. -- Jan Hidders

But according to those "papers" there is nothing concerning the diagrams, all is about Relational Model! I can't found the word "diagram" or the ERD acronym anywere on those pages/links... all seems to mean "Peter Chen is the author of Relational Model. and that's all the story about that..." 23:54 26 Jun 2004 (CET)

The phrase "Entity-Relationship Diagram" appears in all those articles and none of them contain the claim that Peter Chen is the inventor of the relational model. Like I said, these articles are interesting and should certainly be linked to, but not in the article on the Relational Model. -- Jan Hidders 23:37, 26 Jun 2004 (UTC)

Dr. Peter Chen's original paper on the Entity-Relationship model (ER model) is one of the most cited papers in the computer software field. Recently, Dr. Chen was honored by the selection of his original ER model paper as one of the 38 most influential papers in Computer Science according to a survey of 1,000 computer science college professors (Table of Contents, Great Papers in Computer Science, edited by P. Laplante, West Publishing, 1996). Based on one particular citation database, Chen's paper is the 35th most cited article in Computer Science This is taken from the home page of peter chen and a CTRL+F "diagram" shows no results, please tell me where you find that word, please User:Aytharn 13:10 27 JUN 2004 (CET)

For example, see the last paragraph of section 1 in http://bit.csc.lsu.edu/~chen/pdf/erd.pdf . But with all respect, you seem to be missing the point. The point was that that the relational model and the entity-relationship model are two different things. Since Chen invented the latter and not the first the statements concerning him were moved to entity-relationship model. By the way, you might want to add the information that you mention here in your citation above on the article entity-relationship model. A description like "a recent survey shows" should be detailed a bit more and written such that it is also correct if the reader reads it 100 years later. -- Jan Hidders 11:29, 27 Jun 2004 (UTC)

Set Theory Stuff From the Database Normalization Article

There were complaints (which I agreed with) that the set theory definitions in the database normalization article were very off-putting and technical. Unfortunately, this is just a subset of the definitions--the ones most applicable to normalization. However, as these definitions apply to more than just normalization, it seems that they would be more appropriately defined in the relational model--or perhaps an article of their own? They certainly were making the other article unreadable. Metaeducation 11:41, 30 May 2005 (UTC)

Naming Conventions: Singular Vs. Plural

• There is no real establishment or discussion thusfar for naming conventions in the Relational model. Some preach about singular table names and some preach about plural names. I don't think we could ever come to a concensus on that, but I would like to propose a new note or preferably a section concerning singular and plural table naming that highlights the pros and cons of each. -- 24.173.83.230 18:06, 6 December 2005 (UTC)

Misimplementation disputed statement

Relational database management system describes two schools of thought. One considers SQL to follow the relational model, and the other does not. This article says that it does not. The two articles need to be reconciled. It would be nice if both schools of thought could be documented in external sources. -- Beland 06:56, 18 December 2005 (UTC)

Also, this section doesn't really say how SQL is considered to violation the relational model, other than using different vocabulary to describe its data structures. -- Beland 07:20, 18 December 2005 (UTC)

Probably the most obvious violation of the relational model is that SQL permits duplicate rows; in contrast, a mathematical relation is a set (not a multiset) of tuples in which a duplicate cannot arise by definition. Inclusion in recent versions of the standard of other things like ARRAYs (SQL99) and XML (SQL03) have further distanced SQL from the conventional relational model, which requires values in tuples to be single values from the corresponding domain: arrays are, by definition, multiple values from some domain and hence violate this requirement. -- EmmetCaulfield 03:43, 22 December 2005 (UTC)

I think it's pretty well accepted that SQL is not now relational, but was inspired by the relational model, and can be used to implement a relational database, albeit with some care. It is probably safe to say that available SQL DBMSs implement an ill-defined superset of the features required by the relational model. What is a religious issue is whether the bits "added on" are a good idea or not: in making ad-hoc additions, the guarantees of the relational model (e.g. that all expressible queries are answerable, and that all answerable queries are expressible), which arise solely from the mathematical foundations, are lost.

The SQL99 Standard (I don't have the 2003 version to check) does not use the word "relation" or "relational" at all (just searched the PDFs), and I doubt the terms have been reintroduced into SQL'03, so I think it's probably fair to say that even the SQL standards committee have distanced SQL somewhat from the term "relational". -- EmmetCaulfield 03:43, 22 December 2005 (UTC)

Proposed Merger

No, I think the term "relational database" still has its uses, while the term "relational model" suffers from the general overloading of the word "model". Whereas "model" in database theory means something like a style of formalism or a canonical form, the term "relational model" raises the question: Do they mean models in the sense of model theory? This would lead to a different idea than a concrete database. Jon Awbrey 05:40, 6 January 2006 (UTC) llllll

table

small definition question is a table not rather the visual representation of a relation instead of the visual representation of a relvar? see third alinea of first 'chapter'