When we declare a composite key (two columns for the primary key in table1) and link one of the columns of the primary key to another table2. Why we declare these primary key in general section indexed --> yes (Duplicate ok). I am confuse for what reason Duplicate data entry is ok while it is a primary key.
When you say
primary key to another table
it is a foriegn key. That key maybe duplicate but not main primary key be repeated.A foreign key is a field in one table that is a primary key in another table.
Related
As far as I'm aware, you can only assign primary keys and unique columns to foreign keys... yet I have a table that has a primary key between two columns:
alter table NAME add constraint PK primary key(VALUE1, VALUE2)
I'm trying to make Value1 a foreign key in another table, but it's not recognizing it as a primary key or unique - obviously because the primary key is shared between two values... So what do I do from here? I'm pretty new to SQL syntax...
You are correct that you can only assign primary keys and unique columns to foreign keys. I am not much aware of the business requirement here but ideally, you should be having a third table which has the VALUE1 as a primary key. If not you should create one.
The main idea is that you can't link a foreign key to a value that can hold duplicates on the referenced table. So if your main table has a compound key (more than 1 column), linking the foreign key to one (or many but not all) of it's columns would be linking the table to more than one row (since that column might have duplicates by itself).
If you really need to establish the link between the two then you have a problem, either:
Your primary key isn't really 2 or more columns. You can read about normalizing your database (in standard normal forms) to solve this.
Your relationship between the tables isn't 1 to N (it's N to M). You can't add a foreign key, you will have to create a 3rd table with both primary keys to link them.
Let's say table B is dependent on table A.
Table B has a unique primary key B.B_ID and a foreign key B.A_ID
which references the parent table A's primary key.
Since B has a unique key, is B.A_ID, the foreign key, a non key (non-key)
in B?
Thank you.
In the context of discussing the 2nd normal form, "non-key columns" are all the columns that are not part of a candidate key.
You may certainly have foreign key columns in a table that are not part of that table's primary key.
Suppose you have a table Person that has a primary key PersonName because that is the column you use to identify each person uniquely.
You can also have a column in that table such as CountryOfCitizenship that is a foreign key referencing another table Country. This foreign key column is not part of the primary key in the Person table; it is not the way we identify each row in that table.
Re your comment:
The second normal form requires that non-key columns have a functional dependency on the whole primary key. This is different from first normal form only if your primary key has multiple columns.
Functional dependency means that the attribute column unambiguously relates to the primary key, and therefore the value in the attribute column belongs on the same row with that primary key.
So if a column like CountryOfCitizenship always contains the country name that is the country of citizenship for the person who is named in that same row's primary key, then the attribute satisfies 1NF and since the table has a single-column primary key, it's automatically in 2NF as well.
In MySQL terminology, "key" usually refers to an explicit key which has an index on it. If you use this definition, then a primary key is a key. And a unique key is a key. And an index key is a key. But a foreign key is not necessarily a key.
When you declare a foreign key constraint, MySQL does not necessarily build an index on the referring table (it does in innodb). Of course, you can declare the foreign key to also be a key and guarantee that an index is built.
A FOREIGN KEY constraint does not have to be linked only to a PRIMARY KEY constraint in another table; it can also be defined to reference the columns of a UNIQUE constraint in another table.
You can find more information here https://stackoverflow.com/a/18435114/7667467
I've first table name "mustahik_perorangan" and the second name "data_mustahik"
mustahik perorangan have 4 primary key and foreign key in another table
like this condition
PRIMARY KEY (`mustahik_nik`,`ins_provinces_code`,`ins_cities_code`,`ins_institution_types_code`,`ins_institution_serial_no`),
KEY `fk_reference_6` (`ins_provinces_code`,`ins_cities_code`,`ins_institution_types_code`,`ins_institution_serial_no`),
CONSTRAINT `FK_ins_musper` FOREIGN KEY (`ins_provinces_code`, `ins_cities_code`, `ins_institution_types_code`, `ins_institution_serial_no`) REFERENCES `baznasgo_s_organization`.`institutions` (`provinces_code`, `cities_code`, `institution_types_code`, `institution_serial_no`) ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1
and i want to add primary to table mustahik_perorangan, so mustahik perorangan have 5 primary key ?
but i can't do it because it condition..
ALTER TABLE mustahik_perorangan ADD idc INT UNSIGNED NOT NULL AUTO_INCREMENT,ADD PRIMARY KEY (`idc`);
May you know to do it ?
A table can have at most one primary key constraint.
The primary key constraint can contain multiple columns. We refer to that as a composite key.
It is possible to add a new column.
It's also possible to add a UNIQUE constraint on the column and specify AUTO_INCREMENT attribute on the column.
As an example:
ALTER TABLE mustahik_perorangan
ADD idc INT UNSIGNED NOT NULL AUTO_INCREMENT
, ADD UNIQUE KEY (`idc`)
It's also possible to a sixth column to the existing composite primary key. But I don't think this is what you really want.
As a demonstration of how to add a column to an existing composite primary key, I'll provide an example.
Note that the primary key must be dropped and re-added. And a UNIQUE key must be added for the AUTO_INCREMENT column.
Assuming there are no foreign keys referencing the primary key of this table.
ALTER TABLE mustahik_perorangan
DROP PRIMARY KEY
, ADD idc INT UNSIGNED NOT NULL AUTO_INCREMENT
, ADD UNIQUE KEY (`idc`)
, ADD PRIMARY KEY
(`mustahik_nik`
,`ins_provinces_code`
,`ins_cities_code`
,`ins_institution_types_code`
,`ins_institution_serial_no`
,`idc`
)
If there are foreign keys referencing the table, the change is a little more involved. (Did you want an additional column added to the foreign keys in the referencing tables?)
It's not entirely clear what you are attempting to achieve.
Yes, you can add the primary key, but in your case, you need to drop pk and then add new pk, otherwise the engine interpretes as you are trying to add multiple pks, the multiple pks are different from composite pk, you can add composite pk, but you can't add multiple pks
alter table xx drop primary key, add primary key(k1, k2, k3);
I found some legacy code, which sets two almost identical constraints (UNIQUE and PRIMARY KEY) for the primary key field.
Here is the code sample:
CREATE TABLE foofoo (
id NUMERIC(9) NOT NULL ,
bar VARCHAR(40) NOT NULL,
CONSTRAINT PK_foofoo PRIMARY KEY (id),
CONSTRAINT UNIQUE_foofoo UNIQUE(id)
)
I think it's redundant to have these two set and PRIMARY KEY would do the job.
Of course, I read what's the difference between these two constraints, but
what's the point of setting these two constraints for the same field?
There is no point in doing so. A primary key is always unique by nature. I would advise against making both indexes, as indexes comes with a cost (mainly disk space). Just create the PK and you'll be good!
There is no point on setting the exact same constraint as the PK.
A Primary Key is already making sure that this column is unique and indexed.
I think it's redundant ...
Yes indeed it's redundant; since having primary key constraint on the column anyways will make sure that the column has only unique value. There is no point in defining an extra UNIQUE constraint on the same column.
when you declare primary then:
*PRIMARY KEY constraint uniquely identifies each record in a database table
*Primary keys must contain UNIQUE values
so their is no need to declare primary key unique because whenever u declare anything primary key then UNIQUE value is already attached with them.
For unique key:
*The UNIQUE constraint uniquely identifies each record in a database table.
*The UNIQUE and PRIMARY KEY constraints both provide a guarantee for uniqueness for a column or set of columns.
*A PRIMARY KEY constraint automatically has a UNIQUE constraint defined on it.
The most important point is that
*Note that you can have many UNIQUE constraints per table, but only one PRIMARY KEY constraint per table.
In mysql when i take same as primary key and Unique then it gave me error
I'm attempting to setup a foreign key in table cell_lines that will reference the topographic_region column of the composite primary key in table topographic_regions.
Each time I run the last three lines of code trying to add the foreign key, I receive Error Code 1215: cannot add foreign key constraint.
Now, the foreign key column name (topographic_region) in cell_lines only matches one of the composite primary key column names in topographic_regions, the other composite primary key column name being topographic_region_id. Do I usually need to address both components of a composite primary key when creating a foreign key?
A follow up problem is that I've actually already tried addressing both components of a composite primary key using a composite foreign key constraint, and I was still presented with an Error Code 1215: cannot add foreign key constraint.
What can I do to solve this problem, and is there anymore information you would like me to provide in order to do so? I'm happy to respond.
Thanks for reading. I'm very new to mySQL.
create table topographic_regions(
topographic_regions_id int not null auto_increment,
topographic_region int(10),
karyotypes varchar(255),
constraint pk_topographicID primary key (topographic_regions_id, topographic_region)
);
create table cell_lines(
cell_lines_id int not null auto_increment,
cell_line varchar(50),
topographic_region int(10),
constraint pk_cellID primary key (cell_lines_id, cell_line)
);
alter table cell_lines
add foreign key (topographic_region)
references topographic_regions(topographic_region);
This is the problem with composite PKs. In fact, your autonumber topographic_region_id will be unique and you should use that for the PK, and the FK. topographic_region sounds like it is also unique so you should add a unique index to it.
A foreign key is some columns whose subrow values have to appear as subrow values in another table where they are a candidate key. If you really had a foreign key from cell_lines to topographic_regions then cell_lines would have a topographic_region_name column and you would need:
alter table cell_lines
add foreign key (topographic_regions_id, topographic_region)
references topographic_regions(topographic_regions_id, topographic_region);
I suspect that (topographic_regions_id, topographic_region) is not a candidate key of topographic_regions and that topographic_regions_id is enough to identify a region just because you decided cell_lines doesn't have a topographic_region column. Although it may be that a cell line doesn't identify a particular topographic region. But then topographic_regions_id is not a foreign key in cell_lines, since it isn't a key in topographic_regions. (There is no easy way in SQL to constrain that some columns' subrow values have to appear as subrow values in another table where they are not a superset of a candidate key.)
If topographic_regions_id is unique in topographic_regions then it is a candidate key and should be declared UNIQUE NOT NULL. If topographic_region_name is unique in topographic_regions then it is a candidate key and should be declared UNIQUE NOT NULL. If either is a candidate key then (topographic_regions_id, topographic_region) is not a candidate key. You can pick one candidate key to be declared PRIMARY KEY which just means UNIQUE NOT NULL. Ditto for cell_line. Since your _id columns are auto_increment, I suspect they are unique, in which case neither table has a composite candidate key.
(All this assuming none of your columns can be NULL.)