I'm trying to answer the following question...
"Explain the issues that arise when NULLs are present in columns that make up foreign keys. Discuss how ANSI have attempted to resolve this issue with the three 'matching rules' that can be adopted when using concatenated foreign keys."
Can anyone point me in the right direction as to what these 'matching rules' are? I initially thought they were referring to OUTER JOINS, but I'm not sure anymore.
Any advice would be appreciated.
Thanks.
If I remember right, these rules are about composite foreign keys. For example, consider an address table defined like:
deliveryaddressid - order - orderline - street - ...
Where (order,orderline) is a foreign key to the orderline table. The matching rules decide how joins behave when one part of the foreign key is NULL. For example, a row like:
32 - null - 1123 - 'Main Street 1' - ...
Here's an article about partial foreign keys (PDF download, 6 pages) The relevant part seems to be:
ANSI SQL 92 permits and databases such
as Oracle support alternative matching
rules for composite foreign keys,
including:
• Match Full –Partially null foreign
keys are not permitted. Either all
components of the foreign key must be
null, or the combination of values
contained in the foreign key must
appear as the primary or unique key
value of a single row of the
referenced table. [Default]
• Match Partial
– Partially null composite
foreign keys are permitted. Either all
components of the foreign key must be
null, or the combination of non-null
values contained in the foreign key
must appear in the corresponding
portion of the primary or unique key
value of a single row in the
referenced table.
• Match None –
Partially null composite foreign keys
are permitted. If any column of a
composite foreign key is null, then
the non-null portions of the key do
not have to match any corresponding
portion of a parent key.
Related
I get the following error when I try to add a foreign key to my purchaseorderheader table :
ORA-02270: "no matching unique or primary key for this column-list"
I made sure the table and column names are the same but I still get the error, any ideas?
You have a composite primary key that is composed of two columns but, in your foreign key, you are only referencing one of the columns of the composite primary key and not the entire primary key.
You either need to:
change the primary key to be only on the single column purchaseorderid;
keep the existing primary key and additionally create a UNIQUE key on only the purchaseorderid column of the first table; or
include both columns of the primary key in the foreign key.
Whichever option you choose, you should make sure that it implements the business logic that you are trying to capture in the table; if it does not then you should revisit the database-design and find a design that does capture your business logic.
I'm a bit confused about this. Must a foreign key always reference a primaryy key? What if there's two foreign key on the same table that refer to the same primary key?
Thanks
"What if there's two foreign key on the same table that refer to the same primary key?
"
Any number of child tables can reference a parent table. There are certain situations in which it is possible for a child table to have more than one foreign key on the same parent.
For instance, any form of sporting contest has opponents of the same type - player, team, etc. So a match will have two instances of that entity, hance the child table will have two columns with foreign keys referencing the same primary key.
create table player (
player_id number not null primary key
, name varchar2(30) not null unique
);
create table match (
match_id number not null primary key
, player_1 number not null
, player_2 number not null
, match_played date not null
, result varchar2(10)
, constraint match_player1_fk foreign key (player_1) references player
, constraint match_player2_fk foreign key (player_2) references player
);
A foreign key can reference a unique constraint rather than a primary key. However this is not standard practice. It is the convention to use unique keys to enforce candidate keys - business keys - and these are not always suitable for use as foreign keys.
For instance in my example, PLAYER.NAME is a unique key: every player must have a distinct name. However, it would not be appropriate to use NAME as the foreign key on MATCH because people can change their name. It is more convenient to use the synthetic primary key, PLAYER_ID because that will not change over the lifetime of the PLAYER record.
A set of columns comprising a foreign key in one table must refer to an equivalent set of columns in a table with either a Primary Key or Unique Key constraint.
You certainly can have 2 or more FKs in the same table that refer to the same PK or UK. This models a relationship where a child record is related to more than one parent record - e.g. a record representing a biological child might have a FK to the record for their father as well as for their mother.
Note that a unique index is not sufficient for this purpose; a unique constraint is required, otherwise you will get "ORA-02270: no matching unique or primary key for this column-list".
table1:
tid(primary key) // no foreign keys here
table2:
sid(primary key) // no foreign keys here too
table3:
Tid
Sid
iid(primary key)
foreign key(Tid,Sid) references table1(tid).table2(sid)
In table3 i want to make a composite foreign key or composite foreign key constraint but failed . there are many questions related to this .But none of them seems helpful to me . How can i do that ? Is it valid ? Then what is the syntax of making composite foreign key from two different tables primary key
It's not possible to have a single foreign key referencing fields on different tables, and it makes no sense at all. A foreign key of two or more fields implies that the combination of values of the fields must be match on a single record of the referenced table, and this can't be done if the referenced fields are on different tables.
What you can do is to create two distinct foreing keys to the two tables, as following:
CREATE TABLE table3(
iid NUMBER,
Tid NUMBER,
Sid NUMBER,
CONSTRAINT pk PRIMARY KEY (iid) USING INDEX TABLESPACE idx,
CONSTRAINT fk001 FOREIGN KEY (tid) REFERENCES table1(tid),
CONSTRAINT fk002 FOREIGN KEY (sid) REFERENCES table2(sid)
);
Not able to create /find the logic to apply FK on a column in child table referencing a column from composite PK of parent table.
create table product(prod_id number,
prod_name varchar2(20),
price number,
constraint PK12 primary key(prod_id,prod_name));
Table created.
create table purchase(prod_id number,
purchase_price number,
constraint FK12 foreign key(prod_id) references product(prod_id));
create table purchase(prod_id number,
purchase_price number,
constraint FK12 foreign key(prod_id) references product(prod_id))
ERROR at line 1:
ORA-02270: no matching unique or primary key for this column-list
Kinldy suggest how i can incorporate this logic.
Thanks.
You can't.
As the error says there's no matching primary key for that column list; you must have one. You have three options:
Remove PROD_NAME from the primary key of PRODUCT. On the face of it this seems like the logical solution, if this is not required in order to make the primary key unique.
Add PROD_NAME to the PURCHASE table.
Create a unique index on PURCHASE.PROD_ID. This seems excessive if it would be a primary key candidate anyway.
I suspect that this is not unique to Oracle. Considering you have a composite primary key in the referenced table, that implies that only one of the columns comprising the composite key is not enough to uniquely identify the record in that table. Therefore, it's impossible to reference only a single column of the primary key in a foreign key relationship that's one-to-many (e.g. one record in the referenced table can have many records in the referencing table--the one with the FK). However, if the relationship to be established is many-to-many, this may be possible.
HTH.
I've recently stopped to think that Primary Keys are not indexes, they're a combination of Unique and Null constraints. And till now, I've never created index for PK columns. My question is if I should create index for PK columns if this column is going to be used in the WHERE part of many queries.
Oracle will create an index for you, or can use an existing one. Whether a unique or non-unique index is used is up to you.
http://docs.oracle.com/cd/B28359_01/server.111/b28310/indexes003.htm#i1006566
A primary key itself is not an index, and nor is a unique constraint -- they are both constraints. However an index is used to support them.
A unique index is rather different as it can exist in the absence of a unique or primary key constraint, and neither constraint type require that the index supporting it be unique.