Jump to content

Talk:Relational database

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Lfstevens (talk | contribs) at 18:35, 28 April 2019 (→Points following April 2019 merger.: r). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Archive

Archives

Current Talk 1 2

What's a...

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)[reply]
cannot find it anymore, it must be sorted lol Market1G (talk) 21:56, 15 February 2017 (UTC)[reply]

What's a Key

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)[reply]

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)[reply]

Unclear reference

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)[reply]

That means that data are much easier to understand when they are organized than when they are not! Organisation can be somewhat subjective and present different perspectives but it is a matter of fact. Cannot find this text anylore anyway. Market1G (talk) 21:50, 15 February 2017 (UTC)[reply]

Another new archive

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)[reply]

Request - its still incomprehensible

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 (talk • contribs) 14:54, 18 September 2006 (UTC2)

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

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

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)[reply]

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)[reply]
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)[reply]
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)[reply]

figures?

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

relation

relation —The preceding unsigned comment was added by Jitendraapi (talk • contribs) 07:59, 25 April 2007 (UTC).[reply]

wording?

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)[reply]

Constraint not part of database

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)[reply]

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)[reply]

It might help...

...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)[reply]

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

Relational Operations Section

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)[reply]


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

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

XML Databases

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Recursive Definition?

"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)[reply]

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)[reply]

Supporting efficiency 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)[reply]

Poor quality article; needs major work

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)[reply]

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)[reply]

Practical Application and Alternative Solutions

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)[reply]

Relational database management systems

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)[reply]

No sources?

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)[reply]

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)[reply]

Normalization

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 (talk • contribs) 09:18, 17 November 2010 (UTC)[reply]

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

Databases Template

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

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)[reply]

Merger proposal

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
No consensus to merge ... (This 2012 discussion was succeeded by a later discussion)

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)[reply]

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)[reply]
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)[reply]
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)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Watermarking?

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)[reply]

Cart before the horse

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)[reply]

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

Much reorganization needed

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)[reply]

The adjective before Edgar Codd

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)[reply]

Contradiction about primary keys

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)[reply]

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)[reply]

Contradiction about foreign keys

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)[reply]

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)[reply]

Sentences need work, or removal

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)[reply]

New Opening Intro

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)[reply]

Needs example

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)[reply]

First sentence gives wrong impression

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)[reply]

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)[reply]

References

  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.

New merger proposal

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The result of this discussion was merge. Djm-leighpark (talk) 08:14, 28 April 2019 (UTC)[reply]

See also: an older merger proposal.

I propose to merge Relational database management system into Relational database. The first article is more like a stub, it's content can be easily merged into Database management system and Relational database articles. Of course, logically thinking "Relational database management system" and "Relational database" are different things, but: do we have any amount of content that is specific to Relational database management system, but not to Relational database? Sasha1024 (talk) 06:22, 13 April 2018 (UTC)[reply]

Go for it. NE Ent 14:36, 13 June 2018 (UTC)[reply]
Don't merge. I find enough reliable sources for independent articles on RDB [1] and RDBMS [2]. I agree that these topics are "different things" (consider Codd's 12 rules in the context of each article, for example), and for that reason should link to different articles. It may be "more like a stub," but it can be improved. Yappy2bhere (talk) 04:03, 19 August 2018 (UTC)[reply]
Oppose These are completely different things. A relational database is just a set of related data connected using a relational model. A relational database management system is a system for creating and managing relational databases--the physical implementation, the language used to manipulate it, access controls, etc. They should have separate articles. --{{u|Mark viking}} {Talk} 08:30, 19 August 2018 (UTC)[reply]
A reasonable argument. However, as of now Relational database management system is not that article, so it should remain a redirect to Relational database until some time as an editor decides to write Relational database management system. NE Ent 12:57, 19 August 2018 (UTC)[reply]
You're arguing to delete the article because it's not all that it should be. At 8,200 bytes it's substantially more than a stub, there are WP:RS available with which to improve it, and there seems to be consensus at least that these are two substantially different topics that each deserve an article. Even were it only a stub it should remain.
Leave the imperfect article in place. Editors continue to improve it, incrementally perhaps yet it is being improved, but only while they can stumble upon it. If it's removed from view then incremental improvement stops, and we'll wait for an editor with time and interest enough to recreate two articles from the melange created by a merge. Yappy2bhere (talk) 17:20, 19 August 2018 (UTC)[reply]
It's a waste of reader's time to have two article with essentially duplicated information. The stub can be listed at Wikipedia:Requested articles/Applied arts and sciences/Computer science, computing, and Internet to direct potentials editors to the opportunity. NE Ent 11:05, 20 August 2018 (UTC)[reply]
  • Support I support the merge for a few reasons.
    First, Database management system redirects to Database. In general, "database" is synonymous with "database management system" (or "database software") in all contexts. MySQL is described as a "relational database" just as often (if not more often) than it is called an RDBMS.
    Second, purely-theoretical content is probably best discussed at Relational model.
    Third, there is not really a significant reason to discuss databases "in the abstract", that is, separate from an implementation. Even if one were to try to have a relational database implemented with pen and paper, it would still be a management system.
    Overall, I don't see enough distinction to justify two separate articles. A single paragraph on the differences in definitions is likely sufficient. power~enwiki (π, ν) 18:01, 19 August 2018 (UTC)[reply]
  • Note I have notified Wikipedia:WikiProject_Databases of this discussion. --{{u|Mark viking}} {Talk} 19:12, 19 August 2018 (UTC)[reply]
  • Comment: Oppose original oppose struck for clarity as I am making a slightly varied proposal. Roughly speaking 'database' (DB) is about the data and its organisation (though it can be used in a number of contexts to mean different things) whilst 'management system' (DBMS) is about implementations to manage the data. Looking holistically at several articles (generally rated 'top' importance but 'start') class I think a messy situation has arisen and this merge wont really help, or at least it isn't really the fundamental problem. And its actually useful if Wikipedia:WikiProject_Databases get involved in this to decide where several articles should be going.
  • As a reference point Connolly/Begg isbn:9781292061184 define database as A shared collection of logically related data and its description, designed to meet the needs of an organisation and DBMS as A software system and that enables users to define, create, maintain and control access to the database. They then go on to define 10 functions of a DBMS 8 of which were proposed by Codd.
  • I'd argue an RDBMS is basically a DBMS that manages a Relational database therefore Relational database management system (RDBMS) should simply be a redirect to Database management system (DBMS) so that can be managed in one place without danger of a content fork.
  • We of course have the issue Database management system (DBMS) is currently a redirect to Database and is handled within that article. This good faith merge seems to have occurred in 2013 and while solving some I think it has have introduced others. I'm not sure it got the discussion it deserved. Albeit in the content of categories concern about the mixing of DB and DBMS was has been expressed. Anyway the net result is to make RDMBS->DBMS redirect somewhat unsuitable as things stand.
  • ( Update: I am currently proposing a set of changes on the Database article to consolidate Database Management System to one section. Should that persist then a merge/redirect of RDBMS to that section would I believe be the best solution. Djm-leighpark (talk) 21:54, 23 August 2018 (UTC) )[reply]
  • I'm kind of happy with the Relational database article as it generic and about its topic and steers away from implementation specific which starts to happen if (R)DBMS is merged in. It does however cover much the same ground as Relational model, albeit in a less intimidating manner. However there may be a case for making it a DAB page, as sometimes 'Relational database' is used at short for RDBMS, sometimes for 'Relational model' and sometimes for a particular instance of a database that follows the relational model, e.g. The CISP relational database.
Djm-leighpark (talk) 20:35, 20 August 2018 (UTC)[reply]

Merger proposal April 2019

See also: an older merger proposal.
See also: a still older merger proposal.

  • This merge has just been carried out and I've reverted it especially as did not properly attribute. This merge seems to have been carried out without contributing to the discussion here or evaluating the consensus. I think my last remark was 8 months ago or so. We may need to restart the discussion first. Djm-leighpark (talk) 06:03, 13 April 2019 (UTC)[reply]

I am the merger in question. I felt empowered to do so because the old RDBMS article had almost no value. I put what little there was into RD. If someone wants to write a proper RDBMS article, more power to them. But this has been simmering for a long time, with no resolution and no volunteers. Needless to say, I think the merged piece is much better than what was there before. I note that Object database is a similarly merged creature. Lfstevens (talk) 20:21, 13 April 2019 (UTC)[reply]

  • I agree this has been hanging around too long. The results of Lfstevens good faith merge is at Template:Relational database. One reason it was reverted was as it seemed not to follow WP:MERGETEXT. There may also be an issue with concensus. From memory in the Summer of 2018 one reasoning for this merge went along the lines : We merged Database Management System (DBMS) into Database therefore we merge Relational Database Management System (RDBMS) into Relational Database. This discussion somewhat stalled waiting for work following DBMS->RDBMS merge to complete. The alternative thought is an RDBMS is simply a DBMS that manages a Relational Database. We also have issues with regards to what is where between Relational Model and Relational Database.

* I propose after 24hrs to close the old discussion as no consensus and restart a new discussion with notification to WikiProject Database and all previous discussion contributors. If anyone wishes to simply continue the previous discussion please raise objections here within 24 hours. Thankyou. Djm-leighpark (talk) 21:04, 13 April 2019 (UTC) (I might not be able to make this proposal within procedure ... will revisit soon). Djm-leighpark (talk) 21:47, 13 April 2019 (UTC)[reply]

Here's the diff on the reverted merger. (I see only a red-linked template above.) Yappy2bhere (talk) 02:04, 17 April 2019 (UTC)[reply]

I have just had a thought that creating a RDBMS section which indicates DBMS (which is a section in Database) is the main topic area would work for me and enable a merge from would enable Relational database management system which would become a redirect to the RDBMS section. It is minimally intrusive and small effort to create such a section (and easy to discard it and if done would enable an alternative specific merge proposal to be created which *might* resolve some of the opposition in this discussion. For a starter I will create such an RDBMS section. Thankyou.Djm-leighpark (talk) 23:10, 13 April 2019 (UTC) {Done}}. Now I'd like to introduce an alternative merger from Relational Database Management System with Redirect to section that uses WP:MERGETEXT procedure to copy entire contents from that source to avoid attribution issues followed by an immediate hard prune. The contents of the Relational database article can be modified under normal editing rules/discussions etc. I will shortly ask at Wikipedia talk:WikiProject Databases#Merge discussion of Relational database management system into Relational database for an independent to close the previous discussion and allow a new one to be started or to otherwise oversee management of this process. Thankyou.Djm-leighpark (talk) 23:37, 13 April 2019 (UTC)[reply]

I have reviewed the required merge from a content point of view of the result of the target. I believe I had come to the same conclusion that Lfstevens had; namely the history elements were the key content that can usefully be merged. In fact the existing Relational database management system seems to contain little body content other than history. Thus I have the following procedure:

  1. Perform full context merge of Relational database management system to Relational database per WP:MERGETEXT
  2. Remove all merged-in content except for History sections
  3. Tidy result slightly ... perhaps review any removed references
  4. Convert Relational database management system to a redirect to section with appropriate Redirect category shells: R from merge; R to section; R printworthy; R with history.
  5. RDBMS main template to be pointed to be repointed from Relational database management system to Database#Database management system (added Djm-leighpark (talk) 05:47, 17 April 2019 (UTC))[reply]
  • I intend to omit R with possibilities and leave a cautionary note on talk about attempting to convert from redirect to article is likely to cause WP:CFORK and other issues. I don't say it can't be done by an experienced editor but it will require good work to not have issues. If the difference in gaining concensus is R with possibilities is present I will do that.14:49, 16 April 2019 (UTC)

I have re-read the discussions above, and noted no-one has joined the discussion here. I therefore am pinging others previously involved/interested (Sasha1024, NE Ent, Mark viking, Yappy2bhere, Lfstevens (Hopefully got everyone)) to confirm/re-confirm their opinion of this proposal variation in the spirit of WP:MERGEPROP/WP:MERGECLOSE. If there is an impasse after a week I will consider going to WP:ANRFC. Thankyou.Djm-leighpark (talk) 14:49, 16 April 2019 (UTC)[reply]

Just a WP:VOTE then, or can you give reasons? Yappy2bhere (talk) 04:17, 17 April 2019 (UTC)[reply]
WP:OFCOURSE it's a vote. Relational database management system is a crap article that doesn't benefit the reader, and been for a long time. LfStevens stepped up to fix that, and their version should be restored. Any differences between Relational Database and Relational database management system are insignificantly minor. NE Ent 01:17, 18 April 2019 (UTC)[reply]
Please don't play WP:GAMEs. Who on your list checks in every 24hrs weekly? Anyway, why should anyone need to "confirm/re-confirm their opinion"? You have their opinions; you simply disagree with them. Do you hope they will be disregarded if they don't repeat themselves? Rather, you should include opinions expressed in 2011 on this same matter in your deliberations.
Merging these articles has been proposed twice, once in 2011 and again in 2018. The arguments for merging haven't changed: "too short, poorly written, easily merged, can't wait." None of these are good reasons for merger.
The argument against merging is still "these are very different topics", has been since 2006, and as I said earlier can be independently expanded and improved. Those are good reasons not to merge.
There was no consensus to merge in 2011, and no consensus to merge in 2018. What really has changed since August? Yappy2bhere (talk) 01:18, 17 April 2019 (UTC)[reply]
Mmmm, maybe Wikipedia figures out this fictitious editor who's going to editor Relational database management system into something worth reading turns out not to exist after all? NE Ent 01:17, 18 April 2019 (UTC)[reply]
  • Comment: @Yappy2bhere I see you have reverted my changes to the article twice and accused me of playing WP:GAMES, presumably with the objective of disrupting the merge variation proposed. I do not wish to get into an edit war. I would prefer this is oversighted by a neutral mediator as soon as possible. Do you have any preferred suggestions. Thankyou. Djm-leighpark (talk) 04:36, 17 April 2019 (UTC)[reply]
You're mistaken. I reverted one unsourced addition, and corrected one substantive error. Perhaps I should have reverted that too -- a copy+paste from Database#Database management system followed by a line of WP:OR designed to anchor an empty section -- but I didn't want to distract you from a "major edit."
I've no doubt that you're playing WP:GAMES. There's no consensus for merging the articles, hasn't been since it was first proposed in 2011, so you're hoping to neutralize contrary opinion by "restarting" the discussion and directing editors to return and "confirm/re-confirm" what they said in the "previous" discussion, implying that those who don't won't have a say in the outcome. Similarly, you hope to neutralize my opposition by accusing me of "disrupting the merge variation proposed," when there is in fact nothing to disrupt if you are seeking consensus before merging the articles as you say you are.
My "preferred suggestion" is that you not hijack or derail the ongoing merger discussion, that you refrain from merging the articles until there is a consensus that they should be merged, that you cite supporting references whenever possible, and that you not misrepresent my edits. Yappy2bhere (talk) 06:49, 17 April 2019 (UTC)[reply]
OK ... at this point I plan to WP:DISENGAGE for a least just under a week and then post a call Wikipedia:Administrators' noticeboard/Requests for closure, this subject to there being no relevant comments from other parties or other significant event. Thankyou. Djm-leighpark (talk) 08:04, 17 April 2019 (UTC)[reply]
@Yappy2bhere: As far as I can see you are the only person remaining not in support of this merge. I would be grateful if you confirm I can close and this merge discussion perform this merge at a time convenient to myself per WP:MERGECLOSE or do you require me raise a request at Wikipedia:Administrators' noticeboard/Requests for closure. Thankyou. Djm-leighpark (talk) 16:35, 25 April 2019 (UTC)[reply]
  • Merge. I still consider these articles as the two that should be merged (reasoning is the same: these things are distinct, but they're very closely related, so it's better to have one comprehensive article describing both subjects than two incomplete articles).
Additionally I might say that "Object-relational database" and "Object-relational database management system" are described in the same article, the "Object database" article also mixes both subjects (database and DBMS) and etc. Per my perception we should aim either to keep all these things separate (RDB, RDBMS, ORDB, ORDBMS, ODB, ODBMS), or to merge all these things (RDB+RDBMS, ORDB+ORDMBS, ODB+ODBMS). But the all-are-merged state is the closest of the two states that I consider to be practically-consistent (all-are-separated and all-are-merged). (In future, if we find enough data and reasons then we could switch to all-are-separated mode, but I don't see reasons for that now.)
Additionally merging these topics would make the navigation easier. The "Database management systems" template currently lists only Relational database (and Relational model), but not on RDBMS. The "Database models" template currently lists only Relational model (though I'd prefer it to have an entry like • Relational (see also RDBMS) •).
P.S.: I appreciate those who're saying "these're different things" (they're really different things). But Wikipedia is a human-oriented encyclopedia, not an ideal database for AI — I mean Wikipedia's primary goal is not to keep perfect logically-correct structure, but to make articles for humans and to organize them in navigatable way — so IMHO sometimes ideal logically-correct structure should step back due to some irrational-but-practical considerations. IMHO WikiData certainly should have 2 separate entries for RDB and RDBMS, but Wikipedia would benefit from having them separate only if they contain enough data and we have good nagivation. Sasha1024 (talk) 08:53, 17 April 2019 (UTC)[reply]
  • Merge My thinking on this issue has evolved over time. While RDBs and RDBMSes are still two different things, in practice, the section of the database article Database#Database_management_system and other sections of that article cover what I would want in a RDBMS article. That is, database management issues--ACID, concurrency, sharding, etc.--are similar enough across different data models that a general treatment suffices for most issues. The main specialization for RDBMSses, the API, is covered by our various SQL articles. While it could be possible to write a good RDBMS article, a merge now won't sacrifice good content and database management topics can refer to the general database or SQL articles for reader edification. --{{u|Mark viking}} {Talk} 04:23, 18 April 2019 (UTC)[reply]

 Resolved Resolving discussion per WP:MERGECLOSE as consensus to merge. Djm-leighpark (talk) 08:14, 28 April 2019 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Inaccurate title/category - SQL databases are not relational

I think there's a serious issue in titling this article "Relational database". It appears that all of the terminology and content is about "SQL databases" and their implementations, and not at all about "relational databases" (as defined in the relational model). As has been pointed out by Chris Date (one of the original promoters of the model), there doesn't exist a current commercial implementation of the relational model, though there have been several academic efforts on this point. (Database in depth : relational theory for practitioners. O'Reilly. ISBN 0-596-10012-4.)

The biggest thing I would like to see would be a renaming of this article to be "SQL Databases", since that is the main subject of this article. —207.170.206.90 (talk • contribs) 21:58, 15 October 2018‎ (UTC)[reply]

I don't support this rename or the point; regardless of how Codd defined the term in the 1960s, the common use today is to refer to certain uses of SQL databases as relational (as opposed to a non-relational database like MongoDB that doesn't easily support joins). power~enwiki (π, ν) 22:01, 15 October 2018 (UTC)[reply]

Record and field are not relational model terms.

I contradict to state that "record" and "field" are counter part to "row" and "column" respectively. This is a popular mistake. Record and field are neither relational model terms or SQL terms. Don't use these words. They are totally different concepts. Refer to ISBN 978-1491941171. — Preceding unsigned comment added by Nippondanjigeek (talk • contribs) 13:14, 6 March 2019 (UTC)[reply]

Points following April 2019 merger.

Thankyou everyone who contributed to the merge discussion. In general I focused towards a loss-less merge under procedure rather than attempting to achieve a more perfect result in terms of content. People will note somewhat of a 'wing-it technique under an In-use banner rather than pre-prepare in sandbox ... The latter can be better but also risks someone forking the main article in the interim. Wahtever in all events the result is open to normal editing rules but I'll point out the following:

  • I used Lfstevens [3] as a rough guideline which was helpful, but I also noticed I may not have duplicated some of those improvements (certainly some header section renames and I think a little in the history section}}. I wished to avoid Should I?/Shouldn't? in the middle of the merge operation and leave that for others later.
  • When doing the history section I because a little concerned about how the initial dates were working especially with the Micro Database of 1969 preceding Codd 1970. This possibly needs a check as there was a lot of research around that time. I've templated the section with a semi-appropriate as a means of saying ... check and review this ....
  • As you may have noticed I had kludged up a definition for the RDBMS ssection to make it work as a redirect target. Having worked out most of the merged in article I was left with the lede from the Relational Dataabse managmeent system article. I was looking at at and thinking do I delete it ? Do I try to see if it is any good. Is it contents any good or does it have issues. Then I had a brainwave ... put it in the RDBMS section. So I sort of kludged it pretty well as tagged onto the bottom of the definition I had provided out of Begg/Connolly which I obvious have COI interest in retaining. Anyway that is how the RDBMS section got populated with what its now got and may help people understand how it got to be how it is rather than thinking I may had a subtle clever reason. The section may need improvement.

In short ... article is available for normal improvements. Thankyou.Djm-leighpark (talk) 12:11, 28 April 2019 (UTC)[reply]

Thanks for your efforts! Lfstevens (talk) 18:35, 28 April 2019 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Talk:Relational_database&oldid=894576464"