Talk:Relational model

message: I see the term "key" used by itself, with no prefix many times in articles. I am confused by what this means, is it a super key, a candidate key, or something else?
:Typically, when "key" is used by itself, it refers to a superkey, (i.e., any kind of key, except for a foreign key. Any set of attributes which uniquely defines the relation). McKay 13:58, 14 August 2006 (UTC)
replies: text: Okay, so using the key in this sense isn't really preferred, as it is ambiguous (especially to beginners), so I decided to look at it's usage in this article, and I only found one instance of key in the article that isn't specified, so I fixed it. In this case, the usage means either kind. It's a bit verbose, partially because superkeys are not referenced in that paragraph, but saying candidate keys isn't technically correct, so if anyone wants to improve readability, that's fine. McKay 14:02, 14 August 2006 (UTC)

text: It is my understanding that the term key does not apply to the Relational Model. Keys are a function of the DBMS but not the Relational Model. So that might explain why the term is used so seldom in this article. If my understandinis correct then the diagram in the upper-right is misleading. Sam Tomato (talk) 02:08, 18 March 2015 (UTC)
thread_title: Key ambiguity

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

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

message: :relational model MERGE relational database
It is wrong to merge the entry for 'Relational Model' with 'Relational Database' .  Relational Data Model is the blueprint for a Relational database.  Merging the entry for 'Relational Model' with 'Relational Database' is like merging the entry for 'Blueprint' with the physical thing for which the blueprint was made.  First design, then build.
* JA: No, I think the term "relational database" still has its uses, while the term "relational model" suffers from the general overloading of the word "model".  Whereas "model" in database theory means something like a style of formalism or a canonical form, the term "relational model" raises the question:  Do they mean models in the sense of model theory?  This would lead to a different idea than a concrete database.  Jon Awbrey 05:40, 6 January 2006 (UTC)
replies: text: First define what is meant by model. It can refer to the design of relational databases as invented by Edgar F. Codd or it could refer to the design of a specific database. There is a huge difference. Saying "First design, then build" refers to the design of specific databases. Sam Tomato (talk) 02:17, 18 March 2015 (UTC)
thread_title: Proposed Merger with [[relational database]]

message: small definition question
is a table not rather the visual representation of a relation instead of the visual representation of a relvar?
see third line of first 'chapter'
:Quite right! By the way, it has been observed that there are two relations that cannot reasonably be represented this way, namely, the ones I chose to call TABLE_DEE and TABLE_DUM back in 1988! AndrewWarden 13:40, 30 January 2006 (UTC)
replies: text: Having written my agreement, I then went and made the obvious correction to the article.  I suppose it might help to remove the comment altogether now, but I'm not sure what the policy should be or is on such matters. AndrewWarden 14:14, 31 January 2006 (UTC)
thread_title:  table 

message: DONT DO IT SCOTTY!! NOOOOOOOOOOOOOO!!!!!
and also - can u ever explain stuff for dumb a*rses that use the site - trying to write a report on stuff I dont understand is hard enough.... stop making it hard!!
:No, we refuse... 210.50.86.217 14:11, 9 May 2006 (UTC)
thread_title:  never 

message: First things first. I'm definitely in the "truly relational" camp. If you ask me, DBMSs that violate some of Codd's 12 rules (like EVERY SQL DMBS), shouldn't be considered "relational". Yes, I understand that my feelings on the matter shouldn't be the only definition in Wikipedia, because there is a large group of people who considers SQL DBMSs relational. So, beacuse I'm a bigot, I'm going to show everyone the error of SQLs ways in wikipedia, and enforce this when I have time. SQL violates the row ordering rule, it basically comes down to the fact that DISTINCT (in SELECT DISTINCT), is not the default option. This sample doesn't show how this relates to DISTINCT very clearly, but it does clearly show that row order matters in this DBMS, because of SQL.
//"random" database code, translate to your favorite (R)DBMS
create table Foo
{
   ID : Integer,
   Name : String,
   Data : String,
   key { ID } // think unique index, or primary key if you have a hard time with non-primary keys
};
insert table { row { 1 ID, "Codd" Name, "Database Guy" Data }, row { 2, "Codd", "Relational Guy" }, { 3, "Ellison", "Pseudo-relational guy" } } into Foo;
// Now (MS)SQL viewing on that table
select top 1
   Data
   from Foo
   where Name = "Codd"
// What gets returned? "Database Guy" or "Relational Guy"
Some might complain that their DBMS is better than this, because it doesn't support the "top" clause. Sadly, this probably isn't the case: SQL standard: ROW_NUMBER()
PostgreSQL, MySQL: LIMIT clause
MSSQL: TOP clause
 (note his "top-n" query is how it "should" work)
McKay 08:18, 1 August 2006 (UTC)
thread_title:  "truly" relational 

message: JA: There was a lot of thought and discussion early this year on the coordination of the articles related to relational databases, especially these three, in order of decreasing abstraction:
# Relational algebra
# Relational model
# Relational database
JA: The relational model article was intended to form a middle ground between the abstractions of relational algebra and the concrete specifics of relational databases, but still keep to the general principles of the underlying logical model.  The relational database article was intended to deal with specializations of and the departures from the relational model that arise in practical implementations.  Somewhere along the line that organization has gotten totally messed over.  There is now a lot of stuff in the relational model article that  just plain does not belong there, and should be taken up in the relational database article.  Jon Awbrey 13:46, 9 August 2006 (UTC)
replies: text: "Intended"? Intended by who? The way I see it is that the relational model is the framework for creating relational databases, and relational algebra is the query language that can be used to grab data from it. I'm not saying that this article is correct, but I think we should define what should be where, kinda before we continue. I've rewritten "Relational database", Is there anyone that thinks that it should be different? How should we proceed? McKay 17:27, 28 September 2006 (UTC)
thread_title: Organization of Articles Related to Relational Databases

message: What kind of model is the relational model. Relational model is an alternative to Network model, and network model calls itself a database model. That seemed a little wrong to me (because I've got a database model, aka a database schema, for the database I'm working on, for example). But Database model lists relational and network models as it's kind. So, I guess it's right with that article in mind. Thoughts? Some brick thrower has changed the reference to a link on the model page, which shouldn't be used because it's a dab page, and Model (abstract), specificialyl referencing "structure of models", which doesn't seem right to me either. It isn't a conceptual model, it's a model for how to make conceptual models. I think that Database model fits neatly, partially because network model also refers to database model, but it's a different meaning than database schema, but I'm open to new suggestions. McKay 17:11, 28 September 2006 (UTC)
replies: text: The common meaning of the term "database model" usually indicates a specific model of a specific database, but I do see your argument. I will first try to disambiguate the meaning on that page, similar to the distinction made in the article object model (numbers 1. and 2.), except give them headers and thus an anchor to link back from relational model here.  // Brick Thrower 19:15, 28 September 2006 (UTC)
replies: text: In our database course they were distinguished as "database model" (the kind) vs. "data model" (a particular example) if I remember correctly, but here on Wikipedia we have to live with the fact that both terms are used in both meanings. Rp (talk) 08:22, 23 October 2008 (UTC)

text: The relational model isn't really "record"-based: its tuples/rows do not have addresses, while the term "record" suggests that they do.  Of course in practice we often see relational schemass in which tables have "ID columns" that act as symbolic row addresses, but the model doesn't assume or require this. Rp (talk) 17:47, 23 May 2008 (UTC)
thread_title:  kind of model 

message: I'm sorry, but I couldn't extract the GENERAL definition of "Relational model" from the
first paragraph or two of this Wikipedia entry.
Can someone give a GENERAL meaning of "Relational model"
in the FIRST sentence or paragraph of the Wikipedia entry?
I've heard that "Relational model" means, in general terms,
"keeping data separate from function."
But yet, when I came to this entry,
I have no clue whether that is accurate statement or not.
:What you heard is wrong.  Keeping data separate from function is indeed one of the main motivations of use for the relational model, but this motivation is not itself a model, let alone a relational one. Rp (talk) 08:27, 23 October 2008 (UTC)
replies: text: Hmm. In a RDBMS, any scalar is acessible by the tuple (table name, column name, primary key). Relational means that a scalar value in a table my be used as (all or part of) a primary key to refer to some other value. Paul Murray 02:39, 24 January 2007 (UTC)
replies: text: I added such a general introduction a while back, but it needs further improvement. Rp (talk) 08:27, 23 October 2008 (UTC)
thread_title:  Can we get a good definition "Relational model"? 

message: : but note that in the database language SQL the columns and the rows of a table are ordered
Eh? AFAIK, this is silpy not the case. —The preceding unsigned comment was added by Paul Murray (talk • contribs) 02:32, 24 January 2007 (UTC)
replies: text: You appear to be confusing the ordering of rows (which the relational model doesn't, while SQL does) with the ordering of columns (which is indeed an alternative to naming them). Rp (talk) 08:29, 23 October 2008 (UTC)
thread_title:  the columns and the rows of a table are ordered 

message: It may be somewhat arbitrary but in fact there are very clear rules for selecting primary keys.  The term "arbitrary" seems wrong to me in this context.
DruidZ 15:27, 24 October 2007 (UTC)
replies: text: What is meant is that these rules aren't cast in stone and cannot be expressed in terms of the mathematical model.  Rp (talk) 17:49, 23 May 2008 (UTC)
thread_title:  Use of "arbitrary" for selecting primary keys 

message: While a general characterization of relations are presented (an 'extension of first-order predicate logic'), this should be given in formal detail.  I had to bolt to another site to get this information.  (http://www.cs.sfu.ca/CC/354/zaiane/material/notes/Chapter3/node1.html)
BadZen 21:57, 2 February 2008 (UTC)
thread_title:  Formal definition of Relation needed 

message: I've removed (again) the "Criticism" section added by User:194.66.238.27:
 The relational database model is not turing complete.
 There is a direct impediance mismatch between physical and logical views of data.
 The relational database model suffer poor abstractional capabilities due its use of untyped strings and numerical values.
on the grounds that:
* it is not cited
* the assertions are not justified in any way, or even explained, and may be original research
(The poor spelling, grammar and formatting could be fixed but not until the text is more suitable for inclusion.) AndrewWTaylor (talk) 12:46, 2 January 2008 (UTC)
thread_title:  "Criticism" 

message: This section is extremely weak. It falls into that category that is all-too-common in technical articles, of "made-up history". Just a few criticisms:
* the higher the level of abstraction in an existing system, the easier it is to migrate. The difficulty in migrating many applications is because they have too low a level of abstraction.
* the notion that object databases are not true DBMSs but "construction kits" seems to have no basis in reality
* the description of the binary relational model as "recent" is ridiculous; it can be traced back at least to Abrial and Bracchi (independently) around 1971, and is closely related to work on the functional data model by Shipman and others in the early 1980s
* The notion that the network model was only formulated after the relational model is bizarre, unless you have some definition of the term "model" that for some reason excludes the DBTG report of 1969.
Mhkay (talk) 21:37, 5 April 2008 (UTC)
replies: text: I agree - now who is going to rewrite the text? Rp (talk) 08:31, 23 October 2008 (UTC)
thread_title:  "Competition" 

message: This is wrong: cartesian products are mathematical tuples, that is, ordered sets. What becomes commutative is a "db version" of the cartesian product, which is a "db version" of tuples.
"Normal" cartesian product AxB = { (a,b) | a in A and b in B }.
"DB" cartesian product     AxB = { {a,b} | a in A and b in B }.
Arthur Gabriel de Santana (talk) 05:52, 21 April 2008 (UTC)
replies: text: The point is that the "db version" is also called "cartesian product". Rp (talk) 17:50, 23 May 2008 (UTC)
thread_title:  "Cartesian product becomes commutative" 

message: This model seems VERY similar to the PROLOG language implementation.  I think there
should be some comments on that. Predicates, arguments, arity, query, etc. are
all PROLOG terms and a traditional PROLOG program is, as far as I can see, really
close to what is been defined here as a true relational database.  —Preceding unsigned comment added by 200.96.162.36 (talk) 19:05, 21 June 2008 (UTC)
replies: text: It is indeed similar in that it is based on predicate logic and there are in fact intermediate forms (see e.g. Datalog); but Prolog is much more liberal and expressive than relational query languages, and as a consqeuence, the implementations and applications are very different.  Rp (talk) 08:35, 23 October 2008 (UTC)
thread_title:  PROLOG 

message: I'm fairly new round here so excuse me if I get the protocol wrong.
 
The sentence: "IBM implemented Codd's ideas with the DB2 database management system; it introduced the SQL data definition and query language. Other relational database management systems followed, most of them using SQL as well." in "Introduction" may inadvertantly mislead. 
IBM certainly did "implement Codd's ideas with the DB2..." but DB2 was not the first implementation (eg System R, SQL/DS, and S/38) and many people would argue that Oracle was the first commercial implementation. 
I think a more neutral statement like "There have been several commercial products based on Codd's ideas, including DB2, Oracle and SQL Server. Most of these use the SQL data definition and query language." would be better. This would also leave any implied history (which is very interesting)as a separate subject, or associated with the individual database managers. I would make the change myself but I don't have the citation information to support it.OldBoar (talk) 15:43, 20 March 2009 (UTC)
replies: text: Yes Oracle was the first but do you have anything sating that anything other than DB2 was second? Sam Tomato (talk) 02:23, 18 March 2015 (UTC)
thread_title:  Introduction 

message: I added some info on two modelling issues I encountered, fan traps and chasm traps. Apparently they occur regularly enough to merit their own titles in the literature. Feel free to suggest a better place for them.RonaldKunenborg (talk) 22:14, 11 July 2009 (UTC)
thread_title: modelling issues

message: Should this article be in :Category:Mathematical logic?  I would lean against, but if books and/or articles in mathematical logic (as opposed to theoretical computer science) have comments on the topic, it might belong.  In any case, controversial categories should not be included, so a section of the article on the relationship is necessary.  — Arthur Rubin  (talk) 15:23, 21 May 2010 (UTC)
thread_title:  Mathematical logic? 

message: As I see it, the algorithm is not working for all sets of functional dependencies.
Take, for example, ({A, B, C}, {A -> B C, C -> A}). The algorithm returns {{B, C}, {A}} as candidate keys (as mentioned below).
Obviously {B, C} is not a candidate key since it is possible to derive A and following B via C.
If I have this right, this would imply that it is generally not possible to derive C only employing the algorithm with K' = (K - Y) ∪ X.
({A, B, C} - {B, C}) ∪ {A} results in {A}. We can't bring C back in as the new set wouldn't be a subset of {A}.
({A, B, C}) - {A}) ∪ {C} = {B, C}. Now we can't drop B. Or did I overlook any important detail?
 
 Q = 
 K = {A, B, C}; Q = {}
 (1. for each)
 1. fd: K' = ({A, B, C} - {B, C}) ∪ {A} = {A}; Q = 
 2. fd: K' = ({A, B, C} - {A}) ∪ {C} = {B, C}; Q = {{A}, {B, C}}
 K = {B, C}; Q = 
 (2. for each)
 1. fd: K' = ({B, C} - {B, C}) ∪ {A} = {A} (no proper subset)
 2. fd: K' = ({B, C} - {A}) ∪ {C} = {B, C}  (no proper subset)
 C = 
 (3. for each)
 K = {A}; Q = {{}}
 1. fd: K' = ({A} - {B, C}) ∪ {A} = {A} (no proper subset)
 2. fd: K' = ({A} - {A}) ∪ {C} = {C} (no proper subset)
 C = {{B, C}, {A}}
 
Manuel Rigger (talk) 10:14, 20 July 2010 (UTC)
thread_title:  algorithm returns superkeys in some cases 

message: In the diagram "Relational model concepts", "Tupple" should be "Tuple". If I knew how to correct it, I would.
MikeSy (talk) 11:21, 14 February 2011 (UTC)
thread_title:  A typo in a diagram 

message: I removed the Modelling issues section because it has nothing to do with the relational model.  The one supporting reference was to a broken link to an Oracle paper that referred to surprising results in aggregation, not anything about the database design per se.  The terms "fan trap" and "chasm trap" do not appear in Codd's papers or his book, or in the several of Date's books that I've read.  Perhaps, if they were better defined and more widely accepted, they might be appropriately included in an article on logical database design.  One Oracle whitepaper doesn't meet those criteria, though. Jklowden (talk) 21:38, 6 November 2011 (UTC)
thread_title:  Removed section: Modelling Issues 

message: The example contains the following relvar:
* Invoice Line (Invoice No, Invoice Line No, Product Code, Qty Shipped)
and the following statement:
:Usually one candidate key is arbitrarily chosen to be called the primary key and used in preference over the other candidate keys, which are then called alternate keys.
This statement is wrong because the primary key for the "Invoice Line" relvar is not one arbitrarily chosen candidate key of the two available candidate keys but the combination of the two candidate keys. An "Invoice Line" can not be uniquely identified by the "Invoice No" or the "Invoice Line No" but only by the "Invoice No" and the "Invoice Line No".
Ceving (talk) 17:44, 17 April 2012 (UTC)
replies: text: The statement is not wrong for that reason - if it's wrong it's because there are other relevant considerations for the choice of primary key. What you really mean to say here is that in the example, neither {Invoice Line} or {Invoice No} are candidate keys, only {Invoice Line, Invoice No}. However I do believe that whoever came up with this example really meant to state that both the Invoice Line values and the Invoice No values contain no duplicates. Whether this is a realistic or recommendable model is another matter. Rp (talk) 16:48, 19 April 2012 (UTC)
thread_title:  Example probably wrong 

message: I know this is in another section in the talk page, but I don't like bumping, and it's not 100% to what I suggest.
"A tuple is an ordered set of attribute values."
I suggest that we point out that the above statement is true for SQL systems, but Codd's relational model explicitly states that there shall be no ordering. So I suggest:
"In SQL, a tuple is an ordered set of attribute values. However, in Codd's original relational model, a tuple is not ordered." And then go on to explain how the attribute is referenced.
"An attribute is an ordered pair of attribute name and type name."
Yeah... Codd didn't think of that...
101.165.22.246 (talk) 10:28, 27 May 2012 (UTC)
thread_title:  Attribute order 

message: Can anyone explain the diagram in the lead?  Two of the three tables have identical columns: 'Activity Code', 'Date', and 'Route No.'.  Yet the diagram seems to imply one of these has a join dependency on the other.  If the diagram doesn't have clear interpretation it should be removed. - Crosbie 21:47, 16 September 2012 (UTC)
thread_title: Lead diagram

message: Hello!
The words relational attribute redirection to this article. I couldn't find a definition in a serious publication what a relational attribute is, although I know that it is something like a secondary key. Do you know a source that defines this notion? --Sae1962 (talk) 07:10, 24 April 2013 (UTC)
replies: text: I'm not quite sure what you're looking for. The term attribute is explained in this article (although some of the text is clearly Dated). Rp (talk) 21:10, 25 April 2013 (UTC)
thread_title:  What is a relational attribute? 

message: "Relational Model.svg" does not describe a relational model but relationship. It seems unsuitable. Kkddkkdd (talk) 17:40, 23 December 2016 (UTC)
replies: text: How do you mean? It's a fine example of an instance of the relational model, with three relations and two foreign keys. There is nothing un-relational about foreign keys. Rp (talk) 19:44, 29 December 2016 (UTC)

text: "Relational Model.svg" should be titled "relationship between three relations." Kkddkkdd (talk) 03:43, 21 January 2017 (UTC)
thread_title:  Relationship