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
Related
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.
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 Country table which includes the columns ID, Name and Code. All three of these columns should contain unique values and cannot be NULL.
My question is, would I be better to create a primary key on the ID column and a unique constraint for the Name and Code columns (in one index, I guess), or would it be better to just include the Name and Code columns in the primary key with the ID? And why? Are there potential downsides or complexities that will result from having a multiple-column primary key?
First of all - yes, a compound primary key made up of three columns makes it more annoying to join to this table - any other table wanting to join to the Country table will also have to have all three columns to establish the join.
And more importantly - it's NOT the same restriction!
If you have the PK on ID and a unique constraint on both Code and Name separately, then this is NOT valid:
ID Code Name
--------------------------
41 CH Switzerland
341 CH Liechtenstein
555 LIE Liechtenstein
because the Code of CH and the Name of Liechtenstein both appear twice.
But if you have a single PK on all three columns together - then this is valid because each row has a different tuple of data - (41, CH, Switzerland) is not the same as (341, CH, Liechtenstein) and therefore, those two rows are admissible.
If you put the PK on all three columns at once, then the uniqueness only extends to the whole tuple (all three columns) - each column separately can have "duplicates".
So it really boils down to
what you really need (which uniqueness)
how easy you want to make it to join to this table
The question is that if I have relation R(A,B,C,D) where A is PK and C if Alternate key for that relation, would I, while creating table based on that relation, need to indicate that C is an unique key? What I mean is:
create table R (
A A's domain,
B B's domain,
C C's domain,
D D's domain,
primary key A,
unique C
)
Do I have to specify that C is an unique key for that table even though this key isn't posted from any other table (it is just a canditate key which hasn't been selected to be a primary key?
Unique Key is a constraint, which means if you declare C as unique , then no duplicates values will be allowed for that column. If you do not specify it , it can have duplicate values, thus failed as a candidate key
If specifying it will prevent incorrect data from being inserted into the table (such that there are two rows with the same value in C), then the only reason not to do so is if it has proven to be a performance issue, and if you've demonstrated that incorrect data is prevented through some other mechanism.
I've just gone blank. I have a many to many relationship with three tables. Lets call them A, B and C. C stores the primary keys of the other two tables.
Now, I would like to insert all primary keys from table A, and lets say primary key 1 from B into table C. I just don't get it. All I came up with was some stored procedure that runs with a cursor through all primary keys of A and insert them with 1 into C. Guess, there is a much easier way to do this.
Any help appreciated!
I would say:
INSERT INTO C
SELECT A_Id, 1
FROM A
where 1 is the single primary key from B.
Check here for more info on the INSERT statement.