Is it that a primary key is the selected candidate key chosen for a given table?
Candidate Key – A Candidate Key can be any column or a combination of columns that can qualify as unique key in database. There can be multiple Candidate Keys in one table. Each Candidate Key can qualify as Primary Key.
Primary Key – A Primary Key is a column or a combination of columns that uniquely identify a record. Only one Candidate Key can be Primary Key.
More on this link with example
John Woo's answer is correct, as far as it goes. Here are a few additional points.
A primary key is always one of the candidate keys. Fairly often, it's the only candidate.
A table with no candidate keys does not represent a relation. If you're using the relational model to help you build a good database, then every table you design will have at least one candidate key.
The relational model would be complete without the concept of primary key. It wasn't in the original presentation of the relational model. As a practical matter, the use of foreign key references without a declared primary key leads to a mess. It could be a logically correct mess, but it's a mess nonetheless. Declaring a primary key lets the DBMS help you enforce the data rules. Most of the time, having the DBMS help you enforce the data rules is a good thing, and well worth the cost.
Some database designers and some users have some mental confusion about whether the primary key identifies a row (record) in a table or an instance of an entity in the subject matter that the table represents. In an ideal world, it's supposed to do both, and there should be a one-for-one correspondence between rows in an entity table and instances of the corresponding entity.
In the real world, things get screwed up. Somebody enters the same new employee twice, and the employee ends up with two ids. Somebody gets hired, but the data entry slips through the cracks in some manual process, and the employee doesn't get an id, until the omission is corrected. A database that does not collapse the first time things get screwed up is more robust than one that does.
Primary key -> Any column or set of columns that can uniquely identify a record in the table is a primary key. (There can be only one Primary key in the table)
Candidate key -> Any column or set of columns that are candidate to become primary key are Candidate key. (There can be one or more candidate key(s) in the table, if there is only one candidate key, it can be chosen as Primary key)
A Primary key is a special kind of index in that:
there can be only one;
it cannot be nullable
it must be unique.
Candidate keys are selected from the set of super keys, the only thing we take care while selecting the candidate key is: It should not have any redundant attribute.
Example of an Employee table:
Employee (
Employee ID,
FullName,
SSN,
DeptID
)
Candidate Key: are individual columns in a table that qualifies for the uniqueness of all the rows. Here in Employee table EmployeeID & SSN are Candidate keys.
Primary Key: are the columns you choose to maintain uniqueness in a table. Here in Employee table, you can choose either EmployeeID or SSN columns, EmployeeID is a preferable choice, as SSN is a secure value.
Alternate Key: Candidate column other the Primary column, like if EmployeeID is PK then SSN would be the Alternate key.
Super Key: If you add any other column/attribute to a Primary Key then it becomes a super key, like EmployeeID + FullName, is a Super Key.
Composite Key: If a table does not have a single column that qualifies for a Candidate key, then you have to select 2 or more columns to make a row unique. Like if there is no EmployeeID or SSN columns, then you can make FullName + DateOfBirth as Composite primary Key. But still, there can be a narrow chance of duplicate row.
There is no difference. A primary key is a candidate key. By convention one candidate key in a relation is usually chosen to be the "primary" one but the choice is essentially arbitrary and a matter of convenience for database users/designers/developers. It doesn't make a "primary" key fundamentally any different to any other candidate key.
A table can have so many column which can uniquely identify a row. This columns are referred as candidate keys, but primary key should be one of them because one primary key is enough for a table. So selection of primary key is important among so many candidate key. Thats the main difference.
Think of a table of vehicles with an integer Primary Key.
The registration number would be a candidate key.
In the real world registration numbers are subject change so it depends somewhat on the circumstances what might qualify as a candidate key.
Primary key -> Any column or set of columns that can uniquely identify a record in the table is a primary key. (There can be only one Primary key in the table) and
the candidate key-> the same as Primary key but the Primary Key chosen by DB administrator's prospective for example(the primary key the least candidate key in size)
A primary key is a column (or columns) in a table that uniquely identifies the rows in that table.
CUSTOMERS
CustomerNo FirstName LastName
1 Sally Thompson
2 Sally Henderson
3 Harry Henderson
4 Sandra Wellington
For example, in the table above, CustomerNo is the primary key.
The values placed in primary key columns must be unique for each row: no duplicates can be tolerated. In addition, nulls are not allowed in primary key columns.
So, having told you that it is possible to use one or more columns as a primary key, how do you decide which columns (and how many) to choose?
Well there are times when it is advisable or essential to use multiple columns. However, if you cannot see an immediate reason to use multiple columns, then use one. This isn't an absolute rule, it is simply advice. However, primary keys made up of single columns are generally easier to maintain and faster in operation. This means that if you query the database, you will usually get the answer back faster if the tables have single column primary keys.
Next question — which column should you pick? The easiest way to choose a column as a primary key (and a method that is reasonably commonly employed) is to get the database itself to automatically allocate a unique number to each row.
In a table of employees, clearly any column like FirstName is a poor choice since you cannot control employee's first names. Often there is only one choice for the primary key, as in the case above. However, if there is more than one, these can be described as 'candidate keys' — the name reflects that they are candidates for the responsible job of primary key.
If superkey is a big set than candidate key is some smaller set inside big set and primary key any one element(one at a time or for a table) in candidate key set.
First you have to know what is a determinant?
the determinant is an attribute that used to determine another attribute in the same table.
SO the determinant must be a candidate key. And you can have more than one determinant.
But primary key is used to determine the whole record and you can have only one primary key.
Both primary and candidate key can consist of one or more attributes
Related
Sometimes, there are certain tables in an application with only one column in each of them. Data of records within the respective columns are unique. Examples are: a table for country names, a table for product names (up to 60 characters long, say), a table for company codes (3 characters long and determined by the user), a table for address types (say, billing, delivery), etc.
For tables like these, as the records are unique and not null, the only column can be used as the primary key, technically speaking.
So my question is, is it good enough to use that column as the primary key for the table? Or, is it still desirable to add another column (country_id, product_id, company_id, addresstype_id) as the primary key for the table? Why?
Thanks in advance for any advice.
there is always a debate between using surrogate keys and composite keys as primary key. using composite primary keys always introduces some complexity to your database design so to your application.
think that you have another table which is needed to have direct relationship between your resulting table (billing table). For the composite key scenario you need to have 4 columns in your related table in order to connect with the billing table. On the other hand, if you use surrogate keys, you will have one identity column (simplicity) and you can create unique constraint on (country_id, product_id, company_id, addresstype_id)
but it is hard to say this approach is better then the other one because they both have Pros and Cons.
You can check This for more information
I just need to understand the concept behind the composite primary key. I have googled about it, understood that it is a combination of more than one column of a table.But my questions is, what is the practical approach of this key over any data? when i should use this concept? can you show me any practical usage of this key on excel or SQL server?
It may be a weird type of question for any sql expert. I apologize for this kind of idiotic question. If anybody feels it is an idiot question, please forgive me.
A typical use-case for a composite primary key is a junction/association table. Consider orders and products. One order could have many products. One product could be in many orders. The orderProducts table could be defined as:
create table orderProducts (
orderId int not null references orders(orderId),
productId int not null references products(productId),
quantity int,
. . .
);
It makes sense to declare (orderId, productId) as a composite primary key. This would impose the constraint that any given order has any given product only once.
That said, I would normally use a synthetic key (orderProductId) and simply declare the combination as unique.
The benefit of a composite primary key as that it enforces the uniques (which could also be done with a uniqueness constraint). It also wastes no space that would be needed for an additional key.
There are downsides to composite primary keys as compared to identity keys:
Identity keys keep track of the order of inserts.
Identity keys are typically only 4 bytes.
Foreign key references consist of only one column.
By default, SQL Server clusters on primary keys. This imposes an ordering and can result in fragmentation (although that is doubtful for this example).
Let's say I have a table of cars. It includes the model and make of the cars. I do not want to insert the same exact car into my table, but there are cars that will have the same make and cars that will have the same model (assume both Ford and Toyota make a car called the 'BlergWagon').
I could enforce uniqueness of make/model with a composite key that includes both values. A unique key on just make would not allow me to add more than 1 Toyota and a unique key on just model would not allow me to enter more than 1 BlergWagon.
Another example would be grades, terms, years, students, and classes. I could enforce uniqueness for a student in a class and a specific semester in a specific year so that my table does not have 2 dupe records that show the same class in the same semester in the same year with the same student.
Another part of your post is about primary key, which I'll assume means you are talking about a clustered index. Clustered index enforces order of the table. So you could throw this onto an identity column to order the table and add a unique, nonclustered index to enforce uniqueness on your other columns.
This may seem like a simple question, but I am stumped:
I have created a database about cars (in Oracle SQL developer). I have amongst other tables a table called: Manufacturer and a table called Parentcompany.
Since some manufacturers are owned by bigger corporations, I will also show them in my database.
The parentcompany table is the "parent table" and the Manufacturer table the "child table".
for both I have created columns, each having their own Primary Key.
For some reason, when I inserted the values for my columns, I was able to use the same value for the primary key of Manufacturer and Parentcompany
The column: ManufacturerID is primary Key of Manufacturer. The value for this is: 'MBE'
The column: ParentcompanyID is primary key of Parentcompany. The value for this is 'MBE'
Both have the same value. Do I have a problem with the thinking logic?
Or do I just not understand how primary keys work?
Does a primary key only need to be unique in a table, and not the database?
I would appreciate it if someone shed light on the situation.
A primary key is unique for each table.
Have a look at this tutorial: SQL - Primary key
A primary key is a field in a table which uniquely identifies each
row/record in a database table. Primary keys must contain unique
values. A primary key column cannot have NULL values.
A table can have only one primary key, which may consist of single or
multiple fields. When multiple fields are used as a primary key, they
are called a composite key.
If a table has a primary key defined on any field(s), then you cannot
have two records having the same value of that field(s).
Primary key is table-unique. You can use same value of PI for every separate table in DB. Actually that often happens as PI often incremental number representing ID of a row: 1,2,3,4...
For your case more common implementation would be to have hierarchical table called Company, which would have fields: company_name and parent_company_name. In case company has a parent, in field parent_company_name it would have some value from field company_name.
There are several reasons why the same value in two different PKs might work out with no problems. In your case, it seems to flow naturally from the semantics of the data.
A row in the Manufacturers table and a row in the ParentCompany table both appear to refer to the same thing, namely a company. In that case, giving a company the same id in both tables is not only possible, but actually useful. It represents a 1 to 1 correspondence between manufacturers and parent companies without adding extra columns to serve as FKs.
Thanks for the quick answers!
I think I know what to do now. I will create a general company table, in which all companies will be stored. Then I will create, as I go along specific company tables like Manufacturer and parent company that reference a certain company in the company table.
To clarify, the only column I would put into the sub-company tables is a column with a foreign key referencing a column of the company table, yes?
For the primary key, I was just confused, because I hear so much about the key needing to be unique, and can't have the same value as another. So then this condition only goes for tables, not the whole database. Thanks for the clarification!
I need to understand the difference between super key and composite key. The examples I found made more confused. Can you please simply clarify what is the difference? Thanks
The accepted answer is not entirely accurate...
A superkey is any set of columns that, combined together, are unique. There are typically many superkeys per table and same column may be shared by many superkeys. They are not very useful by themselves, but are more of a mental tool for identifying candidate keys (see below).
A candidate key is a minimal superkey - if any column is removed it would no longer be unique. There are typically significantly fewer candidate keys than superkeys.
A key is just a synonym for a candidate key.
A composite1 key is a key that has more than one column. In other words, it's a minimal superkey that has multiple columns.
Few more points:
Every key is unique, so calling it "unique key" is redundant. Just "key" is enough.
At the DBMS level, a key is enforced through a PRIMARY KEY or UNIQUE2 constraint.
An index is usually present underneath the key (PRIMARY KEY or UNIQUE constraint), for performance reasons. But despite often going together, key and index are separate concepts: key is a logical concept (changes the meaning of data) and index is a physical concept (doesn't change the meaning of data, just performance).
1 Aka. compound, complex or concatenated.
2 On NOT NULL columns.
Yes, I agree with #Branko, the accepted answer is not the accurate and not clear.
I'll take example of an Employee table:
CREATE TABLE Employee (
Employee ID,
FullName,
SSN,
DeptID
);
And to know difference b/w Super & Candidate keys, let's check first what are other types of keys?
1. Candidate Key: are individual columns in a table that qualifies for uniqueness of all the rows. Here in Employee table EmployeeID & SSN are Candidate keys.
2. Primary Key: is the columns you choose to maintain uniqueness in a table. Here in Employee table you can choose either EmployeeID or SSN columns, EmployeeID is preferable choice, as SSN is a secure value.
3. Alternate Key: Candidate column other the Primary column, like if EmployeeID is PK then SSN would be the Alternate key.
4. Super Key: If you add any other column/attribute to a Primary Key then it become a super key, like EmployeeID + FullName is a Super Key.
5. Composite Key: If a table don't have any individual columns that qualifies for a Candidate key, then you have to select 2 or more columns to make a row unique. Like if there is no EmployeeID or SSN columns, then you can make FullName + DateOfBirth as Composite primary Key. But still there can be a narrow chance of duplicate row.
Reference
A superkey is a set of one or more attributes that, taken collectively, allow us to identify uniquely an entity in the entity set.
For example, the customer-id attribute of the
entity set customer is sufficient to distinguish one customer entity from another. Thus,customer-id is a superkey.
Composite Key is a combination of more than one fields/columns of a table. It can be a Candidate key, Primary key.
A super key uniquely identifies a row. It could be made up of one column or many. A composite key is a key made of more than one column.
If a Super Key is made of more than one column it is also a composite.
If a composite key uniquely identifies a row it is also a Super key.
I don't see the name 'Super key' used too much: it's usually just called a 'Unique key'.
I am reading about candidate keys and composite keys. I came to know that
a candidate key can qualify as a primary key and it can be a single column or combination of columns
and a composite key is also a combination of columns.
For composite key I have referred this link
how do I make a composite key with SQL Server Management Studio?
Thus when both the candidate key and composite key are a combination of columns, they can qualify as a primary key. Then what is the exact difference ? Can you please explain with examples ?
As I know candidate key is a unique key that can be used as a primary key. but not necessarily used as one.
Composite key is a key of two or more attributes that uniquely identifies the row.
A key is a set of columns that can be used to uniquely identify each row within a table.
Every table has at least one key. Let's say we've identified each possible key for the table. Each of these keys is a candidate key.
As we examine each of these keys, the key may consist of no columns (!), one column, or more than one column, which when considered together uniquely identify each row. The term composite key specifically refers to a key which consists of more than one column.
In SQL, it was decided that one key should be selected and treated "more equal" than the other keys of the table. This key is called the primary key. Other keys can also be declared on the table, these are usually referred to as Unique Contsraints.
(!) In SQL, you aren't allowed to declare a key with no columns - although it would occasionally be useful (think of a table that should only ever have a single row, where each column is representing configuration information)
As an example of a table which has multiple keys, all of which are composite. Imagine an appointment system, where a client and a counsellor meet in a room at a particular time:
CREATE TABLE Appointments (
ClientID int not null,
CounsellorID int not null,
RoomID int not null,
AppointmentTime datetime not null
)
The candidate keys for this table are {ClientID,AppointmentTime}, {CounsellorID,AppointmentTime} and {RoomID,AppointmentTime}. Any of those combinations of columns could be used to uniquely identify a row in the table, and all of them are composite keys.
Which one we choose to declare as primary key will depend (probably) on our own interpretation of the main "focus" of the system. Are we mainly concerned with Room usage, or Clients, or Counsellors? In any case, we'll select one and declare it the primary key. We'll also hopefully declare the other keys as unique constraints.
Or, we could decide to use a surrogate, and declare an AppointmentID column, using whatever auto-numbering facilities are available in the database. That could then be the (non-composite) primary key. But we should still declare the other keys for the table.
Candidate Key: A nominee for primary key field is known as candidate key.
Composite Key: Creating more than one primary key is jointly known as composite key.
Update :
A candidate key is a unique key that can be used as a primary key.
Composite key is a key of two or more attributes that uniquely identifies the row.
A key is a set of columns that can be used to uniquely identify each row within a table.
CANDIDATE KEY :- Candidate key is a unique key and is a "Candidate" for being a primary key.
COMPOSITE KEY :- "Composition" of two or more columns as primary key, is consider as Composite key.
A candidate key is just that: a column or combination of columns that could be used as the primary key, ie a candidate or potential primary key, A composite key is by definition two or more columns that could be used to identify a row. Most commonly when talking about composite keys the question is whether to have it as the primary key to have a surrogate key instead. On occassion you may hear people refer to a composite key that is not a primary key (ie not unique for all rows), in which case it is (hopefully) just a way to refer to a multi-colmn join on non-primary key fields (instead of doing cross join and filtering the rows in the where clause).
CANDIDATE KEY : Candidate key is the single column/multiple column(combined) which helps us to uniquely identify rows in a table.
We can have more than 1 candidate keys
<----- Now among all these candidate keys, one of them is made primary key(which depends upon the developer which one is suited for them) ------>
COMPOSITE KEY : Composite key is set of 2 or more columns (it can't be single column) which helps us to identify rows in a table.
So, yes composite keys are candidate key
In case Composite key is made as primary key, we call it composite primary key(primary key made up of more than 1 column combined).
-Hope this helps
Lets keep it simple.
Primary Key: Uniquely identifies each row using one column
Composite Key: Uniquely identifies each row using more than one columns
Candidate Key: Can be a Primary key or a Composite key, but is not being used as one. As the name suggests it is only a 'candidate'.