Comments on: Foreign Keys

By: Null – again « Oracle Scratchpad

Null – again « Oracle Scratchpad — Thu, 06 Sep 2012 17:42:16 +0000

[...] as the cause of unexpected behaviour. Remember that a constraint accepts a value if the constraint does not evaluate to false. If you put ‘B’ into the constraint definition above, we [...]

By: Foreign Keys « Oracle Scratchpad

Foreign Keys « Oracle Scratchpad — Thu, 05 Nov 2009 21:31:15 +0000

[...] 5th Nov 2009: and here’s another common issue about foreign keys that I also addressed by a link to OTN some time [...]

By: Statistique

Statistique — Tue, 05 May 2009 18:56:55 +0000

Joel and Jonathan,

Do you guys have any idea why Oracle Applications (Oracle ERP) doesn’t have any primary key and foreign key constraints (for version 11.5.9, I don’t know about later version).

For me it doesn’t make sense that Oracle Applications doesn’t fully use the power offered by Oracle database. I’m missing something ???

By: Jonathan Lewis

Jonathan Lewis — Tue, 05 May 2009 17:48:59 +0000

Brian,

If you want to say that a foreign key checks for existence in a set then it should be clear that the element (‘Smith’,null) is not a member of the set {(‘Smith’,'John’)}.

Val is correct, by the way, I am aware of the difference between relational and hierarchical databases. The parent/child example was perhaps not the best choice.

By: joel garry

joel garry — Tue, 05 May 2009 00:35:28 +0000

Oh, I thought you didn’t specify the primary key because I work on an ERP system with thousands of tables… and no primary keys! :-)

(db blind, integrity in app, blablabla. Does have optional not null in db columns, though.)

(And the OTN post does say “compost with two columns”, quite an appropriate visualization there. Explanation for our English as a second language friends, that means making fertile soil additive.)

By: Brian Tkatch

Brian Tkatch — Mon, 04 May 2009 15:52:58 +0000

Val, good point. Perhaps we can reword the comment though to the SQL of the standard is inconsistent. The meaning, however, is not. An FK checks for existence in a set, regardless of the SQL definition of IN() which treats NULL specially.

By: Val

Val — Mon, 04 May 2009 15:28:28 +0000

Brian,

I am pretty sure that Jonathan is aware of the fact that the foreign constraint is a set membership predicate rather than a hierarchical construct. The parent-child mental image is just a convenient point of view, nothing more.

Further, Jonathan is correct in saying that the standard is inconsistent. Consider:

1. S = {1,2,3} and x= null;

2. S = {1,2,3, null} and x = 7;

where S is a set of values against which the foreign constraint is checked and x is the value being checked.

In both cases the ‘x in S’ predicate evaluates to NULL and yet only the first case passes the constraint. I cannot speculate on why the standard is inconsistent since I did not see any published rationale for such behavior.

By: Brian Tkatch

Brian Tkatch — Mon, 04 May 2009 12:12:34 +0000

Relational databases are not hierarchical, as such FKs do not implement a hierarchy. We may use it for hierarchy, created “parent” and “child”, but that is not what is actually created. An FK is Relational Integrity, it makes sure that the referencing COLUMN specifies what is already there, or nothing at all (perhaps the major use of NULL).

So, to me, FK aren’t evaluating A=B, but A IN(B). ADD a NOT NULL CONSTRAINT, and then we do have a child which is evaluated as you explain.