Is a table without a primary key normalized?
In a lecture, my lecturer showed us a table without a primary key. Upon questioning, he said that in 3NF when you remove transitive dependencies it's ok to then have a table without a primary key.
However, no primary key implies there's no functional dependencies - but 3NF is the removal of transitive dependencies, and I was taught that each table needs to have a primary key for normalization as it's all about functional dependencies.
I know it's fully possible to create a table without a primary key, but is that database considered normalized if that table exists?
I should add, the table doesn't have any “unique key”, no primary, no composite, no foreign.
The table shown has three attributes with none of them labeled as primary or unique. I asked if it was a mistake and he said it's fine to not have one. I questioned the remark as none of the information in the table can be uniquely identified and he claimed it's ok to be like this. This goes against what I was taught about normalisation.
database-design normalization relational-theory
add a comment |
In a lecture, my lecturer showed us a table without a primary key. Upon questioning, he said that in 3NF when you remove transitive dependencies it's ok to then have a table without a primary key.
However, no primary key implies there's no functional dependencies - but 3NF is the removal of transitive dependencies, and I was taught that each table needs to have a primary key for normalization as it's all about functional dependencies.
I know it's fully possible to create a table without a primary key, but is that database considered normalized if that table exists?
I should add, the table doesn't have any “unique key”, no primary, no composite, no foreign.
The table shown has three attributes with none of them labeled as primary or unique. I asked if it was a mistake and he said it's fine to not have one. I questioned the remark as none of the information in the table can be uniquely identified and he claimed it's ok to be like this. This goes against what I was taught about normalisation.
database-design normalization relational-theory
Primary key is common unique key with one additional restriction - it cannot contain any part (field, field's prefix, or expression) which is NULLable. Delete PK and re-create it as UK - this will not kill 3NF. And it can be referenced to. Moreover, the normalizing integrity can be provided without indices at all - using trigger logic, for example.
– Akina
Feb 8 at 10:18
So the table still needs a unique key of some form to be normalized? The table presented doesn't even have a unique key.
– Alex
Feb 8 at 10:23
NF needs in relations existence, not in relations integrity checks.
– Akina
Feb 8 at 10:26
1
What definition of 3NF does your lecturer use? The original one proposed by Codd says something like:R is in 2NF and Every non-prime attribute of R is non-transitively dependent on every key of R.
But, what does that mean if there are no keys in R, every relation in 2NF that does not have a key is automatically in 3NF?
– Lennart
Feb 8 at 11:44
16
Fascinating discussion everyone. Check out the 'add an answer' option too.
– Paul White♦
Feb 8 at 12:36
add a comment |
In a lecture, my lecturer showed us a table without a primary key. Upon questioning, he said that in 3NF when you remove transitive dependencies it's ok to then have a table without a primary key.
However, no primary key implies there's no functional dependencies - but 3NF is the removal of transitive dependencies, and I was taught that each table needs to have a primary key for normalization as it's all about functional dependencies.
I know it's fully possible to create a table without a primary key, but is that database considered normalized if that table exists?
I should add, the table doesn't have any “unique key”, no primary, no composite, no foreign.
The table shown has three attributes with none of them labeled as primary or unique. I asked if it was a mistake and he said it's fine to not have one. I questioned the remark as none of the information in the table can be uniquely identified and he claimed it's ok to be like this. This goes against what I was taught about normalisation.
database-design normalization relational-theory
In a lecture, my lecturer showed us a table without a primary key. Upon questioning, he said that in 3NF when you remove transitive dependencies it's ok to then have a table without a primary key.
However, no primary key implies there's no functional dependencies - but 3NF is the removal of transitive dependencies, and I was taught that each table needs to have a primary key for normalization as it's all about functional dependencies.
I know it's fully possible to create a table without a primary key, but is that database considered normalized if that table exists?
I should add, the table doesn't have any “unique key”, no primary, no composite, no foreign.
The table shown has three attributes with none of them labeled as primary or unique. I asked if it was a mistake and he said it's fine to not have one. I questioned the remark as none of the information in the table can be uniquely identified and he claimed it's ok to be like this. This goes against what I was taught about normalisation.
database-design normalization relational-theory
database-design normalization relational-theory
edited Feb 9 at 22:26
MDCCL
6,75731745
6,75731745
asked Feb 8 at 10:13
AlexAlex
434
434
Primary key is common unique key with one additional restriction - it cannot contain any part (field, field's prefix, or expression) which is NULLable. Delete PK and re-create it as UK - this will not kill 3NF. And it can be referenced to. Moreover, the normalizing integrity can be provided without indices at all - using trigger logic, for example.
– Akina
Feb 8 at 10:18
So the table still needs a unique key of some form to be normalized? The table presented doesn't even have a unique key.
– Alex
Feb 8 at 10:23
NF needs in relations existence, not in relations integrity checks.
– Akina
Feb 8 at 10:26
1
What definition of 3NF does your lecturer use? The original one proposed by Codd says something like:R is in 2NF and Every non-prime attribute of R is non-transitively dependent on every key of R.
But, what does that mean if there are no keys in R, every relation in 2NF that does not have a key is automatically in 3NF?
– Lennart
Feb 8 at 11:44
16
Fascinating discussion everyone. Check out the 'add an answer' option too.
– Paul White♦
Feb 8 at 12:36
add a comment |
Primary key is common unique key with one additional restriction - it cannot contain any part (field, field's prefix, or expression) which is NULLable. Delete PK and re-create it as UK - this will not kill 3NF. And it can be referenced to. Moreover, the normalizing integrity can be provided without indices at all - using trigger logic, for example.
– Akina
Feb 8 at 10:18
So the table still needs a unique key of some form to be normalized? The table presented doesn't even have a unique key.
– Alex
Feb 8 at 10:23
NF needs in relations existence, not in relations integrity checks.
– Akina
Feb 8 at 10:26
1
What definition of 3NF does your lecturer use? The original one proposed by Codd says something like:R is in 2NF and Every non-prime attribute of R is non-transitively dependent on every key of R.
But, what does that mean if there are no keys in R, every relation in 2NF that does not have a key is automatically in 3NF?
– Lennart
Feb 8 at 11:44
16
Fascinating discussion everyone. Check out the 'add an answer' option too.
– Paul White♦
Feb 8 at 12:36
Primary key is common unique key with one additional restriction - it cannot contain any part (field, field's prefix, or expression) which is NULLable. Delete PK and re-create it as UK - this will not kill 3NF. And it can be referenced to. Moreover, the normalizing integrity can be provided without indices at all - using trigger logic, for example.
– Akina
Feb 8 at 10:18
Primary key is common unique key with one additional restriction - it cannot contain any part (field, field's prefix, or expression) which is NULLable. Delete PK and re-create it as UK - this will not kill 3NF. And it can be referenced to. Moreover, the normalizing integrity can be provided without indices at all - using trigger logic, for example.
– Akina
Feb 8 at 10:18
So the table still needs a unique key of some form to be normalized? The table presented doesn't even have a unique key.
– Alex
Feb 8 at 10:23
So the table still needs a unique key of some form to be normalized? The table presented doesn't even have a unique key.
– Alex
Feb 8 at 10:23
NF needs in relations existence, not in relations integrity checks.
– Akina
Feb 8 at 10:26
NF needs in relations existence, not in relations integrity checks.
– Akina
Feb 8 at 10:26
1
1
What definition of 3NF does your lecturer use? The original one proposed by Codd says something like:
R is in 2NF and Every non-prime attribute of R is non-transitively dependent on every key of R.
But, what does that mean if there are no keys in R, every relation in 2NF that does not have a key is automatically in 3NF?– Lennart
Feb 8 at 11:44
What definition of 3NF does your lecturer use? The original one proposed by Codd says something like:
R is in 2NF and Every non-prime attribute of R is non-transitively dependent on every key of R.
But, what does that mean if there are no keys in R, every relation in 2NF that does not have a key is automatically in 3NF?– Lennart
Feb 8 at 11:44
16
16
Fascinating discussion everyone. Check out the 'add an answer' option too.
– Paul White♦
Feb 8 at 12:36
Fascinating discussion everyone. Check out the 'add an answer' option too.
– Paul White♦
Feb 8 at 12:36
add a comment |
2 Answers
2
active
oldest
votes
If a relation does not have any candidate key (and the primary key is just one of the candidate keys), then it can have duplicate rows, so in fact it is not a relation! (since relations are always sets).
In that case, it is more correct to call it a table, not a relation, as you did in your question, and note that several RDBMS in effect can manage not-relations, allowing tables without any constraint of uniqueness, even if this case is very uncommon, and produces problem (anomalies) when operating on the data.
But in this case talking about normal forms is not appropriate: all the normalization theory is based on the fundamental assumption that the objects of interest are relations, not multisets. In fact this theory is based on the (somewhat discussed) Universal Relation Assumption, that assumes that all the relations of a database are a subset of a projection of such relation, that contains all the attributes in every relation. And that object is in fact a relation (i.e. a set), not a multiset.
The fact that, when talking about data of the Relational Data Model, sometimes we exchange the two terms, tables and relations, does not means that they are actually synonym, and this difference is fundamental when we talk about normalization theory. Remember that in the books, when some normal form is introduced, it is always said something like:
A relation is in xxx normal form if...
Isn't a multiset isomorphic to a set where you add an additionalcount
attribute to the elements?
– Barmar
Feb 8 at 16:25
3
@Barmar yes, but then you add a candidate key and all the relevant functional dependencies, so from the normalization theory point of view you are in a completely different case.
– Renzo
Feb 8 at 16:59
Thanks for the detailed answer. I thought this was the case but as I'm only a student and he's a lecturer I felt that I need answers from people who knew more than me. Thanks alot.
– Alex
Feb 11 at 12:31
When people carry out relational operations on non-relational tables, they expect relational results. When they don't get them, these appear anomalous.
– Walter Mitty
Feb 11 at 15:31
add a comment |
3NF refers to a table compliant with the first 3 Rules of Data Normalization.
- Elimination of repeating groups
- Elimination of redundant data
- Elimination of columns not dependent on key
The third rule requires a key. You are right, the lecturer's table was not 3NF.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "182"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f229232%2fis-a-table-without-a-primary-key-normalized%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
If a relation does not have any candidate key (and the primary key is just one of the candidate keys), then it can have duplicate rows, so in fact it is not a relation! (since relations are always sets).
In that case, it is more correct to call it a table, not a relation, as you did in your question, and note that several RDBMS in effect can manage not-relations, allowing tables without any constraint of uniqueness, even if this case is very uncommon, and produces problem (anomalies) when operating on the data.
But in this case talking about normal forms is not appropriate: all the normalization theory is based on the fundamental assumption that the objects of interest are relations, not multisets. In fact this theory is based on the (somewhat discussed) Universal Relation Assumption, that assumes that all the relations of a database are a subset of a projection of such relation, that contains all the attributes in every relation. And that object is in fact a relation (i.e. a set), not a multiset.
The fact that, when talking about data of the Relational Data Model, sometimes we exchange the two terms, tables and relations, does not means that they are actually synonym, and this difference is fundamental when we talk about normalization theory. Remember that in the books, when some normal form is introduced, it is always said something like:
A relation is in xxx normal form if...
Isn't a multiset isomorphic to a set where you add an additionalcount
attribute to the elements?
– Barmar
Feb 8 at 16:25
3
@Barmar yes, but then you add a candidate key and all the relevant functional dependencies, so from the normalization theory point of view you are in a completely different case.
– Renzo
Feb 8 at 16:59
Thanks for the detailed answer. I thought this was the case but as I'm only a student and he's a lecturer I felt that I need answers from people who knew more than me. Thanks alot.
– Alex
Feb 11 at 12:31
When people carry out relational operations on non-relational tables, they expect relational results. When they don't get them, these appear anomalous.
– Walter Mitty
Feb 11 at 15:31
add a comment |
If a relation does not have any candidate key (and the primary key is just one of the candidate keys), then it can have duplicate rows, so in fact it is not a relation! (since relations are always sets).
In that case, it is more correct to call it a table, not a relation, as you did in your question, and note that several RDBMS in effect can manage not-relations, allowing tables without any constraint of uniqueness, even if this case is very uncommon, and produces problem (anomalies) when operating on the data.
But in this case talking about normal forms is not appropriate: all the normalization theory is based on the fundamental assumption that the objects of interest are relations, not multisets. In fact this theory is based on the (somewhat discussed) Universal Relation Assumption, that assumes that all the relations of a database are a subset of a projection of such relation, that contains all the attributes in every relation. And that object is in fact a relation (i.e. a set), not a multiset.
The fact that, when talking about data of the Relational Data Model, sometimes we exchange the two terms, tables and relations, does not means that they are actually synonym, and this difference is fundamental when we talk about normalization theory. Remember that in the books, when some normal form is introduced, it is always said something like:
A relation is in xxx normal form if...
Isn't a multiset isomorphic to a set where you add an additionalcount
attribute to the elements?
– Barmar
Feb 8 at 16:25
3
@Barmar yes, but then you add a candidate key and all the relevant functional dependencies, so from the normalization theory point of view you are in a completely different case.
– Renzo
Feb 8 at 16:59
Thanks for the detailed answer. I thought this was the case but as I'm only a student and he's a lecturer I felt that I need answers from people who knew more than me. Thanks alot.
– Alex
Feb 11 at 12:31
When people carry out relational operations on non-relational tables, they expect relational results. When they don't get them, these appear anomalous.
– Walter Mitty
Feb 11 at 15:31
add a comment |
If a relation does not have any candidate key (and the primary key is just one of the candidate keys), then it can have duplicate rows, so in fact it is not a relation! (since relations are always sets).
In that case, it is more correct to call it a table, not a relation, as you did in your question, and note that several RDBMS in effect can manage not-relations, allowing tables without any constraint of uniqueness, even if this case is very uncommon, and produces problem (anomalies) when operating on the data.
But in this case talking about normal forms is not appropriate: all the normalization theory is based on the fundamental assumption that the objects of interest are relations, not multisets. In fact this theory is based on the (somewhat discussed) Universal Relation Assumption, that assumes that all the relations of a database are a subset of a projection of such relation, that contains all the attributes in every relation. And that object is in fact a relation (i.e. a set), not a multiset.
The fact that, when talking about data of the Relational Data Model, sometimes we exchange the two terms, tables and relations, does not means that they are actually synonym, and this difference is fundamental when we talk about normalization theory. Remember that in the books, when some normal form is introduced, it is always said something like:
A relation is in xxx normal form if...
If a relation does not have any candidate key (and the primary key is just one of the candidate keys), then it can have duplicate rows, so in fact it is not a relation! (since relations are always sets).
In that case, it is more correct to call it a table, not a relation, as you did in your question, and note that several RDBMS in effect can manage not-relations, allowing tables without any constraint of uniqueness, even if this case is very uncommon, and produces problem (anomalies) when operating on the data.
But in this case talking about normal forms is not appropriate: all the normalization theory is based on the fundamental assumption that the objects of interest are relations, not multisets. In fact this theory is based on the (somewhat discussed) Universal Relation Assumption, that assumes that all the relations of a database are a subset of a projection of such relation, that contains all the attributes in every relation. And that object is in fact a relation (i.e. a set), not a multiset.
The fact that, when talking about data of the Relational Data Model, sometimes we exchange the two terms, tables and relations, does not means that they are actually synonym, and this difference is fundamental when we talk about normalization theory. Remember that in the books, when some normal form is introduced, it is always said something like:
A relation is in xxx normal form if...
edited Feb 8 at 14:39
Paul White♦
52k14278450
52k14278450
answered Feb 8 at 14:06
RenzoRenzo
3,150515
3,150515
Isn't a multiset isomorphic to a set where you add an additionalcount
attribute to the elements?
– Barmar
Feb 8 at 16:25
3
@Barmar yes, but then you add a candidate key and all the relevant functional dependencies, so from the normalization theory point of view you are in a completely different case.
– Renzo
Feb 8 at 16:59
Thanks for the detailed answer. I thought this was the case but as I'm only a student and he's a lecturer I felt that I need answers from people who knew more than me. Thanks alot.
– Alex
Feb 11 at 12:31
When people carry out relational operations on non-relational tables, they expect relational results. When they don't get them, these appear anomalous.
– Walter Mitty
Feb 11 at 15:31
add a comment |
Isn't a multiset isomorphic to a set where you add an additionalcount
attribute to the elements?
– Barmar
Feb 8 at 16:25
3
@Barmar yes, but then you add a candidate key and all the relevant functional dependencies, so from the normalization theory point of view you are in a completely different case.
– Renzo
Feb 8 at 16:59
Thanks for the detailed answer. I thought this was the case but as I'm only a student and he's a lecturer I felt that I need answers from people who knew more than me. Thanks alot.
– Alex
Feb 11 at 12:31
When people carry out relational operations on non-relational tables, they expect relational results. When they don't get them, these appear anomalous.
– Walter Mitty
Feb 11 at 15:31
Isn't a multiset isomorphic to a set where you add an additional
count
attribute to the elements?– Barmar
Feb 8 at 16:25
Isn't a multiset isomorphic to a set where you add an additional
count
attribute to the elements?– Barmar
Feb 8 at 16:25
3
3
@Barmar yes, but then you add a candidate key and all the relevant functional dependencies, so from the normalization theory point of view you are in a completely different case.
– Renzo
Feb 8 at 16:59
@Barmar yes, but then you add a candidate key and all the relevant functional dependencies, so from the normalization theory point of view you are in a completely different case.
– Renzo
Feb 8 at 16:59
Thanks for the detailed answer. I thought this was the case but as I'm only a student and he's a lecturer I felt that I need answers from people who knew more than me. Thanks alot.
– Alex
Feb 11 at 12:31
Thanks for the detailed answer. I thought this was the case but as I'm only a student and he's a lecturer I felt that I need answers from people who knew more than me. Thanks alot.
– Alex
Feb 11 at 12:31
When people carry out relational operations on non-relational tables, they expect relational results. When they don't get them, these appear anomalous.
– Walter Mitty
Feb 11 at 15:31
When people carry out relational operations on non-relational tables, they expect relational results. When they don't get them, these appear anomalous.
– Walter Mitty
Feb 11 at 15:31
add a comment |
3NF refers to a table compliant with the first 3 Rules of Data Normalization.
- Elimination of repeating groups
- Elimination of redundant data
- Elimination of columns not dependent on key
The third rule requires a key. You are right, the lecturer's table was not 3NF.
add a comment |
3NF refers to a table compliant with the first 3 Rules of Data Normalization.
- Elimination of repeating groups
- Elimination of redundant data
- Elimination of columns not dependent on key
The third rule requires a key. You are right, the lecturer's table was not 3NF.
add a comment |
3NF refers to a table compliant with the first 3 Rules of Data Normalization.
- Elimination of repeating groups
- Elimination of redundant data
- Elimination of columns not dependent on key
The third rule requires a key. You are right, the lecturer's table was not 3NF.
3NF refers to a table compliant with the first 3 Rules of Data Normalization.
- Elimination of repeating groups
- Elimination of redundant data
- Elimination of columns not dependent on key
The third rule requires a key. You are right, the lecturer's table was not 3NF.
answered Feb 12 at 19:15
MetaphorMetaphor
3611421
3611421
add a comment |
add a comment |
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f229232%2fis-a-table-without-a-primary-key-normalized%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Primary key is common unique key with one additional restriction - it cannot contain any part (field, field's prefix, or expression) which is NULLable. Delete PK and re-create it as UK - this will not kill 3NF. And it can be referenced to. Moreover, the normalizing integrity can be provided without indices at all - using trigger logic, for example.
– Akina
Feb 8 at 10:18
So the table still needs a unique key of some form to be normalized? The table presented doesn't even have a unique key.
– Alex
Feb 8 at 10:23
NF needs in relations existence, not in relations integrity checks.
– Akina
Feb 8 at 10:26
1
What definition of 3NF does your lecturer use? The original one proposed by Codd says something like:
R is in 2NF and Every non-prime attribute of R is non-transitively dependent on every key of R.
But, what does that mean if there are no keys in R, every relation in 2NF that does not have a key is automatically in 3NF?– Lennart
Feb 8 at 11:44
16
Fascinating discussion everyone. Check out the 'add an answer' option too.
– Paul White♦
Feb 8 at 12:36