Talk:Codd's 12 rules

Entry contents

The contents of this entry seems to be a copy of what can be found here:

http://www.databaseanswers.com/codds_rules.htm

Note that this is (at least marked as) Chris Date's version, an interpretation of Codd's rules. Chris Date is himself a "thinker" in this field, and while quite insightful, also prone to re-interpreting the past (particularly when it comes to NULL and other concepts which have evolved over time.) It would be helpful if this entry had original quotes, mis-thoughts and all, no?

13 rules

There are 12 rules. Shouldn't the article (albeit not the title) be updated to reflect this, if we're going to include a "rule zero"? Neilc 01:19, 11 Aug 2004 (UTC)

Codd himself called them 12 rules, even though there are, in fact, 13 rules. McKay 12:10, 13 September 2006 (UTC)

albeit 0 still stands as a place (number) value. With this in mind 13 is actually 14, and so on. —Preceding unsigned comment added by 64.16.57.4 (talk) 22:58, 13 December 2007 (UTC)

They were called the "12 Rules", but there are 13 of them. This has been noted in the article now. SqlPac (talk) 03:19, 21 March 2008 (UTC)

Reasons & examples

This article would be a lot more valuable if examples were shown to illustrate why the rules are necessary. I'll give an example example:

For Rule 3 (regarding null values) There have been several reports [1] of law-enforcement agencies designating the use of a value (e.g. "NOTAG", "NO PLATE") on parking tickets to indicate the absence of a license plate on the violator's vehicle. Later, an individual jokingly or inadverdently registers a custom license plate having one of these key values and is inundated with notices regarding unpaid parking tickets.

--Theodore Kloba 16:21, July 21, 2005 (UTC)

I'm not opposed to having examples on the pages, but I don't think that we want to clutter up the rules more than they already are. Maybe having some sort of summary at the top, and examples at the bottom. If you'd like to organize such an effort feel free. I've a bunch of examples (in SQL Systems mostly), of why violations of any of these rules are very bad. McKay 16:14, 26 July 2005 (UTC)

The interconnectivity of Rules 4 and 9. Rule 9 is very difficult to achieve (Dataphor), but for many reasons is very desirable, but without Rule 4, how are applications to be able to adapt, if it can't ask the DBMS what each of the tables look like. Removing a column from a table, and if the application doesn't look at the structure to see if the columnn is still there, who knows what will happen? (Well, the application develper might be able to figure it out, if he knows what he's doing. McKay 03:44, 13 August 2005 (UTC)

You are suggesting original content, which is not allowed on wikipedia.70.189.92.82 (talk) 22:53, 10 January 2018 (UTC)

The Actual 12 Rules

I think that this article should have two main sections. The first section would be the actual rules, as stated by Codd, verbatim, without interpretation. This is the closest I could find: http://www.cse.ohio-state.edu/~sgomori/570/coddsrules.html The second section would be an elaboration of the rules and "what they mean". The distinction of course is to allow Wikipedians to separate the actual rules from sections they can supply valuable input into. // Brick Thrower 08:21, 11 September 2006 (UTC)

How about:

Rule [Rule #]: [Rule Name]:

[Codd's description]

[What it means]

Just an idea McKay 21:02, 11 September 2006 (UTC)

You are suggesting original content, which is not allowed on wikipedia. 70.189.92.82 (talk) 22:53, 10 January 2018 (UTC)

13 Rules Revisited

There seems to be no discussion of Neilc's 2004 comment pointing out that there are actually 13 rules in the article while the article's title is Codd's 12 Rules. I note that links to this article from others, e.g. the one defining a true relational database management system, also refer to 12 rules. This certainly led me to expect to see 12 rules when I clicked on the Codd's 12 Rules hotlink on that page. I was first startled and then annoyed when I encoun- tered 13 rules instead of 12.

After looking into this matter, I've concluded that what this article refers to as Rule 1 should really be called Rule 0, since that is how it is referred to by commentators such as Date and Hite. I suggest four modifications to the article: 1) The first sentence could be modified to read "Codd's 12 rules are a set of rules proposed by......"; 2) A sentence could be added to the effect that "While Codd's rules are typically referred to as Codd's 12 Rules, references to them usually list 13 rules, starting with Rule Zero."; 3) the list of rules should be renumbered so as to run from Rule 0 through Rule 12; 4) a reference to Codd's 1985 Computerworld articles (Computerworld October 14th 1985 and Computerworld October 21st 1985) should be added somewhere in the first or second paragraph.

I'm writing this as a computer user, not a computing historian or information technologist, so I will leave it to others to evaluate my comments and make any suitable edits to the article rather than be presumptuous and actually edit it myself. --JRamlow 10:55, 13 September 2006 (UTC)

The numbering of the rules seems correct, though such an introductary paragraph would be welcome. As would a link or reference to his original work. McKay 12:12, 13 September 2006 (UTC)

Modified intro to indicate there are actually 13 rules numbered 0 through 12. SqlPac (talk) 03:21, 21 March 2008 (UTC)

Reference to SQL

The sentence "In fact, however, the rules are so strict that even systems whose only interface is the SQL language fail on some of the criteria" seems to be completely out of place here. SQL does not guarantee in any way that the system is relational. It might be a good idea to rephrase that as "In fact, some of today's most popular and sophisticated systems fail on some of the criteria". Rkrush 12:32, 22 October 2006 (UTC)

The sentence is original content, I'm removing it.70.189.92.82 (talk) 22:53, 10 January 2018 (UTC)

Rule 6

Since the publication of Codd's rules a paper which demonstrated that Rule 6 is undecideable has been written and acknowledged by Codd as being correct. See H. W. Buff: Why Codd's Rule No. 6 Must be Reformulated. SIGMOD Record 17(4): 79-80(1988) and E. F. Codd: Response to "Why Codd's Rule No. 6 Must be Reformulated". SIGMOD Record 18(1): 16(1989). Codd has subsequently issued a major revision to rule 6 which appears in his book on the Relational Model Version 2. 82.37.0.72 18:15, 28 May 2007 (UTC)

I don't have my copy handy. Can someone add it and source it (if it hasn't been yet)? SqlPac (talk) 03:21, 21 March 2008 (UTC)

Rule 3 ?

Rule 3: Systematic treatment of null values: blah blah blah Does someone care to explain? I'm no SQl expert, but all rules make sense, except rule 3. I understand the first part, treatment of null values; it's really the "blah blah blah" that's bothering me. —Preceding unsigned comment added by 66.36.128.134 (talk) 09:43, 29 February 2008 (UTC)

"The DBMS must allow each field to remain null (or empty)." - In SQL terms, the DBMS must allow you to place NULL in columns which are... "nullable".

"Specifically, it must support a representation of 'missing information and inapplicable information'..." - In SQL terms, NULL represents missing information or inapplicable information.

"...that is systematic, distinct from all regular values (for example, 'distinct from zero or any other number,' in the case of numeric values),..." - In SQL terms, NULL is not equal to any other value. NULL is not equal to zero, it is not equal to one, it is not equal to an empty string, it is not equal to anything.

"...and independent of data type." - In SQL terms, NULL can be used in place of integers, floating point numbers, fixed point decimals, character data, or any other data type.

"It is also implied that such representations must be manipulated by the DBMS in a systematic way." - In SQL terms, NULL behavior and manipulations are well-defined by the standard. SqlPac (talk) 15:57, 15 March 2008 (UTC)

NULL values are "undefined values", much in the same way that division by zero is "undefined". What is important here is that they are handled by the RDBMS consistently. Therefore any opperation between two or more columns (values) where one column contains a NULL value should result in a NULL! In otherwords not matter what you try and do with a NULL, add it, subtract it, concatenate it convert it will always result in a NULL value. This is a valuable concept, even though it sometimes causes programmers and DBA's considerable more work to process these values. — Preceding unsigned comment added by BitBangerDBA (talk • contribs) 00:11, 22 February 2011 (UTC)

No, thats not true. NULL can produce true and false values in three-valued logic when used with logic operators. Also, you can test whether some value is NULL or not, and this produces true/false. 93.87.212.7 (talk) 11:02, 3 November 2011 (UTC)

I beg to differ. You are not differentiating comparison operations from manipulation operations. The results of manipulating a variable or column whose value is NULL with any other variable or column will always produce a NULL. Comparing a variable or column for a value of NULL is not the same thing. For example the following statemant returns 0 rows: "SELECT * FROM SYSCOLUMNS WHERE AUTOVAL = NULL". However the following statement returns thousands of rows: "SELECT * FROM SYSCOLUMNS WHERE AUTOVAL IS NULL".

Please note the following in the SQL Server books online: "The SQL-92 standard requires that an equals (=) or not equal to (<>) comparison against a null value evaluates to FALSE. When SET ANSI_NULLS is ON, a SELECT statement using WHERE column_name = NULL returns zero rows even if there are null values in column_name. A SELECT statement using WHERE column_name <> NULL returns zero rows even if there are nonnull values in column_name." By default the ANSI_NULLS setting is turned ON in SQL Server sessions. There is another SQL-92 setting as well. CONCAT_NULL_YIELDS_NULL is another SQL-92 standard that is set to "ON" by default for all sessions. Very rarely if ever would you want to change these default settings.

These are the same for every RDBMS that claims to adhear to the SQL-92 standards.

no popular "relational" DBMSs are actually relational . . .

Even if such repackaged non-relational products eventually gave way to SQL DBMSs, no popular "relational" DBMSs are actually relational, be it by Codd’s twelve rules or by the more formal definitions in his papers, in his books or in succeeding works in the academia or by its coworkers and successors, Christopher J. Date, Hugh Darwen, David McGoveran and Fabian Pascal. Only less known DBMSs, most of them academic, strive to comply. The only commercial example, as of December 2010, is Dataphor.

What is ORACLE or INGRESS then?

Wikipedia's article states it so . . .

I am confused :S — Preceding unsigned comment added by 117.199.51.138 (talk) 13:36, 30 August 2011 (UTC)

SQL is based on relational algebra, but it's far, far from being 100% relational. Also, ORACLE or INGRESS are far, far from being 100% compliant with SQL standard. 93.87.212.7 (talk) 11:05, 3 November 2011 (UTC)

Re: The comments above, it's INGRES or Ingres, not INGRESS. Originally named for the machine where the source for the University Ingres project lived. The machine was one of the 'painters' systems at UC Berkeley and was named for Jean Auguste Dominique Ingres, a French Neoclassical painter. The back-formation "INteractive GRaphical Retrieval System" was used in marketing.98.248.42.250 (talk) 03:15, 15 April 2013 (UTC)

By Cohen's logic since T,F,N that makes sense. The problem is you are use 2v when 3v is required. 2601:6:1780:DE6:24F6:20:7468:99C6 (talk) — Preceding undated comment added 13:13, 24 December 2014 (UTC) http://www.storyofmathematics.com/20th_cohen.html 2601:6:1780:DE6:24F6:20:7468:99C6 (talk) — Preceding undated comment added 13:18, 24 December 2014 (UTC)