I have two tables, data/model is fake for simplicity purposes:
Table A:
Order ID Delivered
1 Y
2 N
3 Y
And
Table B:
Order ID Customer ID
1 123
1 234
1 455
2 789
Order ID is a primary key on Table A, and I want to use it as a Foreign Key on Table B.
Is this acceptable, given that Order ID on Table B is not unique?
Please ignore any normalisation/structural issues, my question is simply whether you can have a non-unique foreign key, I just thought the illustration would help..
Thanks,
Dearg
Is this acceptable, given that Order ID on Table B is not unique?
Yes, absolutely. This is the standard way of modeling a 1:many relationship
You should nevertheless find a primary key for TableB. If a customer cannot be assigned to more than one order, then using (order_id, customer_id) as the PK would make sense.
Related
How do I add constraint to guard that a primary key could only be referenced once?(It could be referenced in two tables)
Each reference should have a unique value out of the primary key.
Table A
----------------------
id
1
2
3
4
Table B
----------------------
id a_id (foreign key to table A.id)
1 2
2 3
Table C
----------------------
id a_id (foreign key to table A.id)
1 1
I want something to happen to give error when try to insert a_id = 2 into table C as its used in table B already.
You can use an INSERT, UPDATE trigger on each of the child tables to ensure that the PK of the parent table that is about to be inserted or updated does not already exist in the other child table.
What you are trying to do requires another table D, that will help unify the references to A.
Table D will contain its own primary key ( Id ), a reference to table A with a UNIQUE constraint on it (call it AId ), and a third column (called "RowType") to indicate to which of the child tables (B or C) the row corresponds. You can make this column to be of type int, and assign value "0" for B and "1" for C, for example.
Then in table B you add a foreign key to D.Id, AND another column "BRowType" as foreign key to D.RowType; then you define a constraint on this column, so it can only have the value '0' ( or whatever value you have decided to correspond to this table).
For table C your constraint will limit the values to '1'.
Or course, in order to insert a record into B or C you first need to create a record in D. But once you have a record in B that references a record in D, which in turn links to a record in A, you will no longer be able to create a record in C for the same line in A - because of the UNIQUE constraint on D.AId AND the constraint on C.BRowType.
If I understand the question correctly, it sounds like you need to add a unique constraint on the column of each table that references your primary key.
For example:
Table A
----------------------
id (primary key)
1
2
3
Table B
----------------------
id a_id (foreign key to table A.id)
1 2
2 3
Set the a_id column to be UNIQUE and that way you can ensure that the primary key from Table A is not used twice. You would do that in each table which references A.id
If you want to avoid using triggers, you could create a table X with id and a unique constraint on it.
In each transaction in which you insert a record into B or C you have to insert into X as well. Both insertions will only be possible if not yet in the other table.
I have to answer this question about UNIQUE statements. In particolar, the question ask me to indicate which is the maximum number of unique statements someone can define on a relation of 5 columns. I suppose that this number should be 5^5. Is this right?
And another question about Foreign Keys ask me whether attribute A for a relation R can be Foreign Key referencing B in relation S, even if A is not primary key for R. I think that because a FK constraint can also include NULL values, an attribute specified as FK referencing a PK on another table shouldn't be a primary key itself. Is it right?
Thank you in advance!
The maximum number of distinct unique relationships you can define is 2^n - 1. Basically, any given column can be in or out of the relationship. The "- 1" is because you cannot define a unique relationship with no columns.
For instance, with three columns, you can have:
A
B
C
A, B
A, C
B, C
A, B, C
If you think of these as binary numbers, you will see the pattern:
100
010
001
110
101
011
111
In a relational database. Two tables can be related in a many to many fashion with a mapping table that has foreign keys to the other two tables primary keys, while both still being related to another table.
For example.
Table A
AId -PK
CId -FK
Table B
BId -PK
CId -FK
Mapping Table m
AId -FK
BId -FK
(composite PK of the above)
Table C
CId -PK
How would I modify this so both the tables in the many to many relationship setup in such a way that a row from Table A and a row from Table B can only be related to each other through mapping table m if the row in A and B are also related to the same row in Table C?
1. Make TableA.CId and TableB.CId both FKs to Table C.ID.
2. Add a unique index in TableA on columns AId and CId.
3. Add a unique index in TableB on columns BId and CId.
4. Add a CId column to TableM.
5. Then Add two FKs in Table M,
a. One using columns (AId, CId) pointing to Unique composite Index in Table A, and
b. the other using columns (BId, CId) pointing to Unique composite Index in Table B.
I have a table which has these columns:
Id (Primary Key): the id.
OwnerId (Foreign Key): the id of the owner, which resides in another table.
TypeId (Foreign Key): the type of thing this record represents. There are a finite number of types, which are represented in another table. This links to that table.
TypeCreatorId (ForeignKey): the owner of the type represented by TypeId.
SourceId (Foreign Key): this isn't important to this question.
I need to constrain this table such that for each Id, there can be only one of each TypeCreatorId. I hope that makes sense!
For SQL Server, you have two options:
create a UNIQUE CONSTRAINT
ALTER TABLE dbo.YourTable
ADD CONSTRAINT UNIQ_Id_TypeCreator UNIQUE(Id, TypeCreatorId)
create a UNIQUE INDEX:
CREATE UNIQUE INDEX UIX_YourTable_ID_TypeCreator
ON dbo.YourTable(Id, TypeCreatorId)
Basically, both things achieve the same thing - you cannot have two rows with the same (Id, TypeCreatorId) values.
Simply create a unique index on OwnerId and TypeCreatorId.
An example using MySQL (sorry, I don't use SQL Server):
alter table yourTable
add unique index idx_newIndex(OwnerId, TypeCreatorId);
Example. I'll just put here what would happen with this new unique index:
OwnerId | TypeCreatorId
--------+--------------
1 | 1
1 | 2 -- This is Ok
2 | 1 -- Ok too
2 | 2 -- Ok again
1 | 2 -- THIS WON'T BE ALLOWED because it would be a duplicate
i have table A and table B. I have a bridge table called tableC
in table C i have:
ID
tableA_ID
tableB_ID
ID is the primary key.
i also want to enforce the combination of tableA_ID and tableB_ID to be unique so there are no duplicate records.
how do i enforce this?
create unique index myIdx on tableC(tableA_ID, tableB_ID)
or whatever the syntax for your particular database system is.
Make the PRIMARY KEY tableA_ID and tableB_ID, EXCLUDING ID
lets say we have a table TABLEA with values
tableAID
1
2
3
and table TABLEB with values
tableBID
4
5
6
making the primary key (ID, tableA_ID, tableB_ID) will not work eg.
ID | tableAID | tableBID
1 | 1 | 4
2 | 1 | 4
will work fine with the above pk, but you need PRIMARY KEY (tableA_ID, tableB_ID)
Drop the ID column then make the other two columns the primary key and their uniqueness will be enforced by the database server.
It's not really necessary to have the ID column - even though it serves as a handy way of referencing a particular record - as the uniqueness of the other two columns will mean that they are sufficient to reference a particular record.
You may also want to put an index on this table, that includes bothe columns, to make access faster.