Talk:Relational database

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Computing (Rated Start-class, Top-importance)
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Top  This article has been rated as Top-importance on the project's importance scale.
 
WikiProject Databases / Computer science  (Rated Start-class, Top-importance)
WikiProject icon This article is within the scope of WikiProject Databases, a collaborative effort to improve the coverage of database related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Top  This article has been rated as Top-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computer science (marked as Top-importance).
 
WikiProject Computer science (Rated Start-class, Top-importance)
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Top  This article has been rated as Top-importance on the project's importance scale.
 

(don't like this site)

Archive

Archives


Current Talk 1 2

What's a...[edit]

What is this? I bite herewith the hands that feeds me; often well: but why is it that the contributions unto Wiki, most of them reasonably clear -- and the whole concept a piece of genius probably ACCIDENTENTAL to the purpose (as most such things are) as it may re-invoke the ability to write with some vivacity yet be concise [perhaps all Wiki contributors should sign a sworn statement that they have read Strunk and White: A timeless THIN volume which can do wonders for anyone].

It is the realm of the realm in which these and its mass of reciprocating, complimenting words exist that is most oddly paired with the intent of a dissemination of knowledge. In this case, I cannot think of a more ‘Mobius Strip' meaningless circuitry than the following; I wish to amplify and depersonalize the complaint as MOST OF THE COMPUTER ENTREIES IN THEIR BURGEONING GEOMETRICS are just as this: I shudder to think what will become of a human race that rests MASSIVELY ALREADY on the persons who see the processes of a reasonable goal of efficiency in THIS way.

This ‘edit’ is a fie; an editorial; however, I wish to emphasize that no person but a few could possible glean anything from this: to wit:

For all tuples in the referencing relation projected over the referencing attributes, there must exist a tuple in the referenced relation projected over those same attributes such that the values in each of the referencing attributes match the corresponding values in the referenced attributes."

It is at least 4 years since we were chided (2009 or earlier) by this reader for the quality level of this article. We are doing better, guys, but, IMHO, we still ain't looking good.
Jerry-VA (talk) 16:12, 1 January 2014 (UTC)

What's a Key[edit]

The word 'key' is used in talking about foreign keys and it's used without being defined. I'm a CS major but I'm not sure what a "key" is formally when talking about DBs. —Preceding unsigned comment added by 70.91.87.110 (talk) 12:59, 15 June 2009 (UTC)

In database theory, each row can be divided into the something the row is about and the attributes of that something. The something is the primary key, the attributes of that something are all columns that are not part of the primary key. The "somethings" the table deals with won't change that much and "should" be unique, in theory, but attributes might change a lot and may be common to a lot of rows. In practice, you almost never see this done in practice. Practice usually doesn't have this neat division in column meanings - primary key fields may well be picked according to how to get the best performance out of any indexes, for example, and have nothing to do with the model of the data. —Preceding unsigned comment added by 173.11.23.233 (talk) 18:21, 10 June 2010 (UTC)

Unclear reference[edit]

The article begins with "The resulting "clumps" of organized data are much easier for people to understand."

Easier than what? —Preceding unsigned comment added by 62.84.193.250 (talk) 11:21, 9 December 2008 (UTC)

Another new archive[edit]

I created a new archive, because the page was getting a bit long, and most of it was me just being pedantic. As always, we're looking for ways to improve the article. Be bold. McKay 04:16, 16 August 2006 (UTC)

Request - its still incomprehensible[edit]

Any chance someone could make this page more readable to the layman? Sections such as 'advantages and disadvantages over other types of database' or 'uses' might help, or just inclusion of this info in the intro. —The preceding unsigned comment was added by 85.210.173.159 (talkcontribs) 14:54, 18 September 2006 (UTC2)

I replied to his talk page that he probably meant RDBMS McKay 23:50, 18 September 2006 (UTC)

There still needs to be an introduction (ideally at the beginning) that says in proper English what is meant by a 'relational database', and why and when you need it (and also what just comprises an ordinary database presumably) I had hoped to get something from this page, but its one of the most circular examples of clunky "programmer's english" I've seen since it took me a day to find that "ERROR: DISK WRITE NO DATA BLOCK" meant "disk is full", in CPM80. Meanwhile, I'm off to find some-one who can tell me. If their explanation is lucid, maybe I'll come back and have a go. And, an aside, which language is 'tuple' from -its presumably not European, or is it an acronym, as otherwise I've only ever seen it in serial PROM data sheets ? Mike (still puzzled about databases and how they relate!)

Dump the quibbles[edit]

Too great a percentage of the introductory matter is scolding laymen (or marketing droids) for abusing terms like RDBMS and relational database. Okay, we get it: the software is not the database (any more than a word processor is a document). Let's cut to the chase.

I propose adding one sentence, and tucking it away somewhere less prominent, pointing out the distinction between, say MS SQL Server (a database program) and the abstract idea of a database (a collection of related tables). --Uncle Ed 22:06, 1 December 2006 (UTC)

Drat, I can't please everyone. Maybe it could be less berating, but the comments I kept getting while writing this article were "well, why would I use one relational database over another" Where such a concept is probably referring to DBMSs. It is very common for people to misuse the term. I belive it is WP's policy to include such misuses (especially very popular ones) in the intro paragraph. Additional discussion on the subject would be most welcome. McKay 03:43, 4 December 2006 (UTC)
Oh, sorry. I get it now. The colloquial usage is to refer to database software as a "relational database". If I can come up with a gentler way to point out the distinction, I'll add it to the article.
Something like,
  • In discussions about software, some people blur the distinction between a relational database and a DBMS. For example, they may refer to Oracle as a "database" when strictly speaking it is software which manages a database.
Okay, McKay? --Uncle Ed 17:03, 4 December 2006 (UTC)
Hmm, I want to emphasize that an RDBMS is not a relational database, though some people use it mistakenly, Other than that, I like it, and it is better than what we have in explaining that. McKay 19:01, 4 December 2006 (UTC)

figures?[edit]

There might be a case for adding some figures for examples. – Kaihsu 10:18, 24 April 2007 (UTC)

relation[edit]

relation —The preceding unsigned comment was added by Jitendraapi (talkcontribs) 07:59, 25 April 2007 (UTC).

wording?[edit]

I found this page highly redundant. The first few paragraphs say the same phrase "is a database that conforms to the relational model" about three times. I would alter it myself, but I don't have enough knowledge on the topic yet.--Vince | Talk 18:52, 23 July 2007 (UTC)

Constraint not part of database[edit]

The constraint bit states: "....constraints are not considered part of the relational database"

Many constraints however are a way of defining the domain of the type. The domains are part of the relational database, even (or: especially) in the strictest sense. Please comment, if OK I'll try a rewording.

Also: the link to Constraint refers to the disambiguation page, if suppose it should direct to "Constraint satisfaction" (in computer science).

Pukkie 07:35, 17 August 2007 (UTC)

I made a few minor modifications to the sections on data domain and constraints. I think the wording on the "constraints are not considered part of the relational database" part are confusing. That sentence should be made a little more clear and it should definitely be referenced. Thanks. SqlPac (talk) 05:21, 26 December 2007 (UTC)

It might help...[edit]

...To include a summary of terminology. I'm thinking a table summary that compares the official academic RDBMS terminology and the SQL-ized versions. For instance, relation = table/tuple = row/attribute = column. I know it's spelled out in bits and pieces throughout the article, but it might help casual readers to see a quick summary all in one shot. I think it will make the article a bit more accessible. I'll check back later and see if I can add a little something if someone else doesn't take it up. SqlPac (talk) 05:33, 26 December 2007 (UTC)

Added a little something, although it can probably be expanded. 69.116.243.84 (talk) 18:44, 26 December 2007 (UTC)

Relational Operations Section[edit]

Could use a lot more beefing up. We can discuss and give examples of the different operations, including all 8 of Codd's original operators (relational division, etc.) 69.116.243.84 (talk) 05:17, 27 December 2007 (UTC)


I believe it's 12 not 8.. but, let's not quibble lol

Rp64127 (talk) 13:31, 22 September 2009 (UTC)

XML Databases[edit]

I've removed the claim that it "remains to be seen" whether relational databases will survive the threat of XML databases (and reverted a revert of my change). As far as I'm aware, XML databases haven't made significant inroads in the database marketplace. This is in part because the major relational database vendors are including significant XML functionality in their databases, so I suppose one could say that XML databases are making inroads in the sense of being assimilated. But I'd say that we need some pretty good references to support a claim that relational databases are under any significant threat from XML databases. Klausness (talk) 15:31, 6 June 2008 (UTC)

XML Databases are a relatively new technology to the ancient by comparison Relational Databases, it is wrong to say that Relational Databases have outlived and survived XML Databases because of this fact. Businesses have been taking up XML Databases and making use of them because of performance benefits over Relational Databases for when data that is deeply complex by nature or if the data is highly changable or if they are dealing heavily with XML, e.g. Web Services. Saying that this new technology has been beaten by Relational databases because there is still a wide use of Relational Databases is like saying that CORBA has beaten Web Services!. Get over it, and get objective!, 13:42 9 June 2008 (BST) —Preceding unsigned comment added by 82.153.252.39 (talk) 12:42, 9 June 2008 (UTC)
XML Databases are not that new, and I see no sign that pure XML databases have made significant headway since their introcuction. As I mentioned, XML functionality is being included by relational database vendors, which is why I added a note to that effect, and relational database vendors do appear to be focusing a lot of development effort on adding addtional XML functionality. Also, the wording "Whether they will survive XML databases is another matter" is just not very encyclopedic (and sounds somewhat biased towards XML databases). I've partially reverted to the previous version again, but I've changed the wording a bit. Please do not keep reverting without getting some sort of consensus here on the talk page. Klausness (talk) 15:17, 9 June 2008 (UTC)
XML Databases are new in comparison to the time relational databases have been around just as humans are new in comparison to the time the earth has been around. Yes, relational database vendors are including XML functionality in their products because the world is going in the direction of XML, but the support is quite basic in comparison to native XML databases and one day developers will find it just too cumbersome working with relational databases when a better alternative is available[1]. Relational Databases performance of processing/shredding XML (XML-Enabled) is very poor in comparison to native XML storage[2]. As for XML Databases not making headway commercially, I know that the Inland Revenue and Customs in the UK uses Tamino as its core database and has done so for a few years now, also the giant retailer Comet Electricals which as far as I'm aware has the 5th largest amount of traffic in the UK uses Tamino as its back-end database layer, I also know of a major UK bank which is now using Berkeley DB XML as its major database persistence layer and Symbian use X-Hive for their document and information management. Also the wording "relational database vendors have fought off challenges from XML databases" is biased towards relational databases. —Preceding unsigned comment added by 82.153.252.37 (talk) 08:30, 10 June 2008 (UTC)
Without references, your claims that some people are using XML databases are pretty meaningless (and even with references, showing that some companies use XML databases doesn't show that they're actually gaining significant market share). As for the reference you have inside the ref tag (Native XML versus CLOB and Shredding), if you look at the study that cites, it's a study by IBM that shows how much better DB2's XML support is compared to Oracle's. Hardly something that argues against XML support in relational databases. Also, "have attempted to fight off" is at least as biased as "have fought off". Oh, and the note in your latest edit summary about "reporting me to wikipedia" (whatever that means) is just silly. We're supposed to be trying to reach some sort of consensus here about the article. Failing that, I'm trying to make edits that take the article closer to a NPOV. Klausness (talk) 11:45, 10 June 2008 (UTC)
Thinking about it a bit more, this stuff is all really more about relational database management systems than about relational databases, so it probably doesn't belong in the intro at all. I've moved it to a separate section. Klausness (talk) 12:22, 10 June 2008 (UTC)

Recursive Definition?[edit]

"A relational database is a database that conforms to the relational model, and refers to a database's data and schema (the database's structure of how those data are arranged)."

I'm a little tired right now, but would it make more sense to say something more like this?

"A relational database is a database that conforms to the relational model. The term relational refers to the underlying logical model that supports both storage of data and definition of schemas (structures that contain and constrain data)."SqlPac (talk) 05:01, 28 June 2008 (UTC)

It sounds a little ambiguous, unless it is taken that all database models other than a single flat-file database are relational. Anything else (hierarchical, star schema, object-oriented, or what-have-you) can encode schemas and data. —Preceding unsigned comment added by 173.11.23.233 (talk) 18:28, 10 June 2010 (UTC)

Supporting efficiency edit[edit]

Just commenting to support the recent edit by User:66.109.210.3 with edit summary "deleted the paragraph saying that "Relational databases are among the least efficient of all types of database organization..." because it is demonstably and patently false." This unsourced and vague information is completely contrary to my impressions, in which the structural simplicity of the relational model is precisely what enables it to be more efficient in practice by enabling it to be reasoned about formally for the purpose of query optimization. I can't imagine what database model is supposed to be "more complex but more efficient" (surely not flat files or hierarchical databases?) Let's keep this deleted. Dcoetzee 02:48, 9 December 2008 (UTC)

Poor quality article; needs major work[edit]

This article is poorly written. Just in the first screenful or so, there are errors in every sentence, and in the illustration:

The illustration has many errors and should be removed: 1. The "ID" column on EMPLOYEE should be named "EMP_ID". Data element names should be consistent across the schema. 2. All the data element names are not conformant to ISO standards. They are all uppercased; names like "F_NAME", "L_NAME", and "MGR_ID" are improperly abbreviated. 3. None of the tables have a primary key.


The definition of relational database emphasizes grouping, or "clumps", instead of relations between sets of data. It is wrong and should be rewritten.


"Such a grouping uses the relational model (a technical term for this schema)." is wrong on several levels. The referent of "this schema" is not clear, and "schema" has a meaning in database theory that is different from how it is used in the quoted sentence. It does not make clear that grouping the data is a data retrieval operation, and it's clumsy writing to say that the grouping "uses the relational model".


"Relational databases are currently the predominate choice in storing financial records, manufacturing and logistical information, personnel data and much more."

Misspelled "predominant", and no source...


It should be made clear that the article is of poor quality at best. It needs major work.75.111.158.23 (talk) 23:52, 29 March 2009 (UTC)

I cant beleive you spent all this time writing this, and _didn't bother to edit the article_ -A234092 (talk) 22:52, 2 July 2009 (UTC)

Practical Application and Alternative Solutions[edit]

It would be useful if someone could add few words on what is the practical application of relationship databases in enterprises and how this relates to new solutions such as cloud computing. —Preceding unsigned comment added by 81.108.133.218 (talk) 12:10, 7 June 2009 (UTC)

Relational database management systems[edit]

The three leading commercial relational database vendors are Oracle, Microsoft, and IBM.[citation needed] The three leading open source implementations are MySQL, PostgreSQL, and SQLite.


the proceeding statement was mis-quoted and possibly partially baised as I found a reference to the above but reads somewhat differently. Possibly, a source to used as the citation. The writer seems to have added bias as to vendors as it says leading products but, possibly not just 3... This seems to be an americanize point of view...

Also, it seems to me that this would be a seperate article to go under systems not the definition of the database itself.. link or whatever..


RELATIONAL DATABASE MANAGEMENT SOFTWARE DEFINITION (continued): … A relational database management system (RDBMS) is a program that lets you create, update, and administer a relational database. Most commercial RDBMS's use the Structured Query Language (SQL) to access the database, although SQL was invented after the development of the relational model and is not necessary for its use. The leading RDBMS products are Oracle, IBM's DB2 and Microsoft's SQL Server. Despite repeated challenges by competing technologies, as well as the claim by some experts that no current RDBMS has fully implemented relational principles, the majority of new corporate databases are still being created and managed with an RDBMS.

Relational Database Management Software definition sponsored by SearchSQLServer.com, powered by [3] WhatIs.com an online computer dictionary

Rp64127 (talk) 16:02, 22 September 2009 (UTC)

No sources?[edit]

There are no sources in almost this entire article. In an article on a technical subject, that is pretty much equivalent to having no content. How can anyone rely on this? It may as well be mostly deleted. 66.213.10.5 (talk) 16:28, 28 September 2010 (UTC)

doi:10.4156/jdcta.vol5.issue8.17 A Weight-based Semi-Fragile Watermarking Scheme for Integrity Verification of Relational Data — Preceding unsigned comment added by 99.90.197.87 (talk) 04:02, 11 October 2011 (UTC)

Normalization[edit]

Normalization trades reducing redundancy for increased information entropy. Normalization is criticised because it increases complexity and processing overhead required to join multiple tables representing what are conceptually a single item.

This is a very strange claim and unless cited I propose to remove it.

  • Regarding entropy

Reducing redundancy actually decreases information entropy. Database that can store contradicting (for example non 3NF) facts certainly has higher entropy compared to database that can not.

  • Regarding splitting

Normalisation actually splits conceptually different entities and not single items. Someone who claims otherwise does not really understand concept of base and base and derived relations (Also the grammar is not correct ...what are... a single item. plural/singular mixed.)

  • Regarding complexity

Claim of increased complexity is questionable and that should be presented: one point of view is that denormalized data is always more complex (denormalised is either a) redundancy - which must be maintained through triggers or other mechanisms which are not necessary less complex then having an extra table, b) repeating groups or multivalue columns - which require decomposing and recomposing and lead to complicated queries and other complex things).

Only the complexity complain is actually common (but badly presented). The other claims are just... plain wrong. —Preceding unsigned comment added by Viewviewer (talkcontribs) 09:18, 17 November 2010 (UTC)

I agree with the above, particularly point about splitting conceptually different entities. --Fjleonhardt (talk) 13:32, 6 November 2011 (UTC)

Databases Template[edit]

Added the Databases Template {{Databases}} to the page because this page is referenced by the template and it provides useful context to the subject.

What it is[edit]

The first sentence actually describes a join, not a relational database. This is too bad, because I came here to add the following comment by Scott Ambler (a world-class expert on databases):

  • relational databases have effectively become the defacto standard for storing data.

I don't want to say that a "join" is the standard for storing data. Joins are important, of course, but let's get the terminology straight. --Uncle Ed (talk) 22:05, 4 February 2011 (UTC)

Merger proposal[edit]

The article Relational database management system should be merged with the Relational database management systems section of the Relational database article.

That section starts with "Main article: Relational database management system" but that very section actually has much more content than the "main article" itself which has only 4 lines of text.

While having only 4 lines of text, the Relational database management system article is marked with {{refimprove}} since March 2009 and has some other problems as well (see: Talk:Relational database management system).

All of the redirects:

redirect to Relational database management system which doesn't even link to Relational database (outside of the Template:Databases navbox below the External links) while one actually needs to read Relational database to learn anything at all about the relational database management systems. The only 3 links in the Relational database management system article are to: database management system, relational model and E. F. Codd.

Considering all of the above my proposal is to merge any content that isn't already there from Relational database management system into the Relational database#Relational database management systems section and make Relational database management system a redirect to Relational database#Relational database management systems. —Rafał Pocztarski, Rfl (talk | contribs) 22:24, 17 October 2011 (UTC)

I think not: while a RDBMS is a system that allows creation of RDB:s, the articles won't profit from mixing implementation and system issues with the theoretical aspects of RDB:s, normal forms and such, and RDB:s compared with ODB:s. I think the best thing is to leave them separate. Rursus dixit. (mbork3!) 09:56, 7 January 2012 (UTC)
What we need is some reorganization of the articles. A merger is not the first thing I would think of. Maybe better links? Or an infobox? --Uncle Ed (talk) 04:49, 8 January 2012 (UTC)
I think the Relational database management system article almost approaches "worse than nothing" quality. The External Links section is longer than the body, and is truly arbitrary, POV, and poorly-written. A reorganization that greatly improved it would be fine, but I don't think we should wait on such a hypothetical event, when the fairly substantial Relational Database article provides much better info, now. I just happened on the RDBMS article, and couldn't imagine Wikipedia had so little information about one of the technologies it's built upon. In fact there is better information, and the existing RDBMS article mostly stands in its way. I'm strongly in favor of the proposed merger. Which you probably guessed by now; pardon me if I'm intemperate. Thanks. Ale And Quail (talk) 04:55, 10 May 2012 (UTC)

Watermarking?[edit]

Why is there a section on watermarking in this general article? It appears to exist simply to promote an external paper on the subject. --Fjleonhardt (talk) 13:35, 6 November 2011 (UTC) I agree. I believe this section should be removed. — Preceding unsigned comment added by 131.107.0.73 (talk) 00:51, 8 November 2011 (UTC)

Cart before the horse[edit]

The sentence: "Relational database theory uses a set of mathematical terms, which are roughly equivalent to SQL database terminology." puts the SQL cart before the mathematical horse. -- PBS (talk) 20:32, 21 December 2011 (UTC)

Right. WP:BOLD. Rursus dixit. (mbork3!) 09:59, 7 January 2012 (UTC)

Much reorganization needed[edit]

I've been professionally involved with relational databases for over 10 years. Wikipedia is absolutely the last place I would look, for information about what one is, how to use one ... let alone how to design one.

A relational database consists of two or more related table. The usual relation between two tables is a key or linking field (see foreign key). This key defines a parent-child relationship between one row of a table any number of rows in another table.

For example a department may have several employees. Instead of repeating the name and other information about the department in each related employee record, we simply record the department_id there. Later, a query can assemble the required information for a report.

These simple points form the core of my professional knowledge. It's interesting to get further into database normalization, and Codd's 12 rules, and all that, too. Plus just about everybody in the field considers SQL the standard way to communicate with a database management system. --Uncle Ed (talk) 23:01, 8 January 2012 (UTC)

The adjective before Edgar Codd[edit]

Beneath the Terminology header, the adjective "homosexual" is used to describe Mr. Codd.

The biography for Mr. Codd mentions nothing about this.

Either this should be dropped to describe Mr. Codd or it should be added to his birography.

As it is, I believe it is tone deaf.

Atlas21521 (talk) 05:34, 6 August 2012 (UTC)

Contradiction about primary keys[edit]

In the introductory section, it is stated, in no uncertain terms, that "[i]n the relational model, each table schema must identify a column or group of columns, called the primary key, to uniquely identify each row." However, the "Relations or Tables" section seems to contradict this: "If the tuple contains a candidate or primary key then obviously it is unique; however, a primary key need not be defined for a row or record to be a tuple. The definition of a tuple requires that it be unique, but does not require a primary key to be defined." From my understanding, a primary key is not necessary; in fact, if one is not defined, then the entire set of attributes (columns) could be used, as that is guaranteed to uniquely identify a tuple.

On a related note, there seems to be some inconsistency around how "primary key" is used. From my understanding, a primary key is a single attribute; when a set of attributes performs the same function, it is called a superkey, and can be called a candidate key if it's a minimal set of attributes.

LyricalCat (talk) 23:40, 30 September 2013 (UTC)

A superkey is an attribute set whose subtuple values are unique. A candidate key is a superkey containing no smaller superkey. So a candidate key is an attribute set whose subtuple values are unique containing no smaller attribute set whose subtuple values are unique One candidate key can be labelled the primary key (without theoretical basis).
There are no limitations on number of attributes. A superkey, candidate key and primary key can have zero, one or more attributes. One with more than one attribute is called composite. The set of all attributes must be a superkey as a consequence of the definitions.
In SQL syntax PRIMARY KEY is equivalent to UNIQUE NOT NULL and so actually declares a superkey. It can't have no columns.
So both the entry & you are mistaken. The article has a lot of problems. Altdb (talk) 21:53, 4 July 2014 (UTC)

Contradiction about foreign keys[edit]

There seems to be a contradiction in the "Foreign key" section. The first sentence therein states that a foreign key "is a field in a relational table that matches the primary key column of another table." The last sentence, however, says that a foreign key can be described as satisfying the following statement: "For all tuples in the referencing relation projected over the referencing attributes, there must exist a tuple in the referenced relation projected over those same attributes such that the values in each of the referencing attributes match the corresponding values in the referenced attributes." This implies that a foreign key can consist of multiple attributes, and thus does not need to match the primary key of the referenced relation. The article on foreign keys also states that a foreign key can be a set of attributes, in which case it matches a superkey of the referenced relation. So, am I correct in assuming that the first sentence in the "Foreign key" section of this article should be revised?

LyricalCat (talk) 23:51, 30 September 2013 (UTC)

We say that there is a foreign key on a set of attributes in one table referencing corresponding attributes in another table when each subtuple value on the attributes in the one table must appear as a subtuple value on the corresponding attributes in the other table and the corresponding attributes form a candidate key in the other table.
There are no limitations on number of attributes. A foreign key can have zero, one or more attributes. One with more than one attribute is called composite.
In SQL a FOREIGN KEY declaration references a unique (declared PRIMARY KEY or UNIQUE) subrow of another table so it actually declares a foreign superkey. (So it's a foreign key when the superkey is a candidate key.) It must involve at least one column.
The various entries have a lot of problems. (And you are mistaken that a primary key can't be composite.) Altdb (talk) 22:21, 4 July 2014 (UTC)

Sentences need work, or removal[edit]

In the Constraints section the last two sentences have problems:

This sentence seems clumsy:

"Since every attribute has an associated domain, there are constraints (domain constraints)."

This sentence probably doesn't belong in this section:

"The two principal rules for the relational model are known as entity integrity and referential integrity."

-- Dougher (talk) 20:01, 14 October 2013 (UTC)

New Opening Intro[edit]

This page has drawn several complaints.

" it's used without being defined"
"unclear reference . . . easier than what?" what are you referring to?"
"it's still incomprehensible. . . . There still needs to be an introduction (ideally at the beginning) that says in proper English what is meant by a 'relational database', and why and when you need it (and also what just comprises an ordinary database presumably) "
"Recursive Definition? -- 'A relational database is a database that conforms to the relational model,. . .' "
"Poor quality article; needs major work -- This article is poorly written."
"I've been professionally involved with relational databases for over 10 years." "Much reorganization needed"

I myself came here and quickly left to seek elsewhere an answer to the question, What is a relational database?

I came back with the following answer, which I will put in as the article's opening introduction. The current opening text now follows this text, with a new heading ("Overview"; could also be entitled "Origins and Overview"). So the good news is no text has been removed, and the bad news is now I've given everybody else the editing work because no text has been removed.

NEW INTRO TEXT AS ORIGINALLY WRITTEN
In relational databases, each data item has a row of attributes, so the database displays a fundamentally tabular organization. The table goes down a row of items (the records) and across many columns of attributes or fields. The same data (along with new and different attributes) can be organized into different tables. It is the links between tables that make a relational database relational. Important columns in any relational database's tables will be a column whose entry (customer ID, serial number) can uniquely identify any particular item or record (the primary key), and any column(s) that link to other tables (the foreign key(s)). The size and complexity of relational databases typically requires stored procedures to support the relationships and provide access (interfaces) to external programs which, for example, "query" the relational database to retrieve and present selected data.

Relational databases are both created and queried by DataBase Management Systems (DBMSs). Relational databases displaced hierarchical databases because the ability to add new relations made it possible to add new information that was valuable but "broke" a database's original hierarchical conception. The trend continues as a networked planet and social media create the world of "big data" which is larger and less structured than the datasets and tasks that relational databases handle well (it is instructive to compare Hadoop).
Jerry-VA (talk) 18:50, 1 January 2014 (UTC)

Needs example[edit]

As it stands this article is very technical. After the definitions perhaps a simple example would help make everything clear - something at the level of (only an example) a database of candy with such attributes as color, flavor, hard/soft, etc. Peter Flass (talk) 17:23, 19 February 2014 (UTC)

First sentence gives wrong impression[edit]

I'd like to respectfully suggest that the first sentence in this article, "A relational database is a database that stores information about both the data and how it is related." could be improved. In particular, the use of the word "related" gives the wrong impression. A database with one table containing one column and row is a relational database (if it is SQL Server and not NoSQL). This database would store data, as the sentence says, but it does not store any information about "how it is related". Related to what in this case?

"A common misconception is that the name 'relational' has to do with relationships between tables (that is, foreign keys). Actually, the true source for the model's name is the mathematical concept relation."[4]

Plattprogram12 (talk) 19:05, 20 August 2014 (UTC)

Hello Plattprogram12, I just took a first run at improving the lead. You're welcome to improve it. Reducing potential confusion is a good thing.
There may be a couple other considerations too. To begin with, I wouldn't base the definition a 100% on Microsoft's implementation. I'm not sure if I have a true parallel example, but I wouldn't consider a document as a file that was created in Microsoft Word with only a space character in it. Technically, it would be a MS Word doc, but generally most people would not consider it much of a document.
A database with one table and one column may be comparable to the older way of storing data non-relationally, that is in a flat file. Maybe a comparison would be to have a race care with no fuel; it can be used as a seat and a paper weight, but most people who own one wouldn't use it that way.
Regarding how data is related: Data is also related within a table, assuming there is more than one column. This is brought out in normalization discussions, design, and implementations. So, you are correct. Thanks for asking.
I noticed the comment on the article having shorter lead, so that's another project. Alrich44 (talk) 00:53, 27 August 2014 (UTC)

References[edit]

  1. ^ See XML Databases - the business case
  2. ^ see Native XML versus CLOB and Shredding
  3. ^ link title
  4. ^ Ben-Gan, Itzik. Querying Microsoft SQL Server 2012. Microsoft. p. 4. ISBN 978-0-7356-6605-4.