 | |
Must we also create separate tables?
comp.databases.theory comp.databases.theory
 |
| | Thread Tools | Display Modes |
#31
 
| |||
| |||
|
Re: Must we also create separate tables? -
10-27-2008
, 01:14 PM
|
Srubys (AT) gmail (DOT) com wrote: ... Say we have non-normalized table STUDENT: STUDENT ( STUDENT#, STUDENT_NAME, SUBJECT1#, SUBJECT2#, SUBJECT1_NAME, SUBJECT2_NAME, TEACHER1_NAME, TEACHER2_NAME ) I realize best thing to do would be to create two tables: STUDENT-SUBJECT ( STUDENT#, SUBJECT#, SUBJECT_NAME, TEACHER_NAME ) STUDENT ( STUDENT#, STUDENT_NAME) ... Heh, just to muddy the waters a little or even a lot, the conventional normalization discipline is really just a way to help determine a simple structure that avoids a lot of constraint verbiage. From what I gather of the typical SQL product it is effectively a sop that allows them to cop-out and not give very full constraint support. |
#32
| |||
| |||
|
|
Srubys (AT) gmail (DOT) com wrote: ... Say we have non-normalized table STUDENT: STUDENT ( STUDENT#, STUDENT_NAME, SUBJECT1#, SUBJECT2#, SUBJECT1_NAME, SUBJECT2_NAME, TEACHER1_NAME, TEACHER2_NAME ) I realize best thing to do would be to create two tables: STUDENT-SUBJECT ( STUDENT#, SUBJECT#, SUBJECT_NAME, TEACHER_NAME ) STUDENT ( STUDENT#, STUDENT_NAME) ... Heh, just to muddy the waters a little or even a lot, the conventional normalization discipline is really just a way to help determine a simple structure that avoids a lot of constraint verbiage. From what I gather of the typical SQL product it is effectively a sop that allows them to cop-out and not give very full constraint support. |
#33
| |||
| |||
|
|
Srubys (AT) gmail (DOT) com wrote: ... Say we have non-normalized table STUDENT: STUDENT ( STUDENT#, STUDENT_NAME, SUBJECT1#, SUBJECT2#, SUBJECT1_NAME, SUBJECT2_NAME, TEACHER1_NAME, TEACHER2_NAME ) I realize best thing to do would be to create two tables: STUDENT-SUBJECT ( STUDENT#, SUBJECT#, SUBJECT_NAME, TEACHER_NAME ) STUDENT ( STUDENT#, STUDENT_NAME) ... Heh, just to muddy the waters a little or even a lot, the conventional normalization discipline is really just a way to help determine a simple structure that avoids a lot of constraint verbiage. From what I gather of the typical SQL product it is effectively a sop that allows them to cop-out and not give very full constraint support. |
#34
| |||
| |||
|
|
Srubys (AT) gmail (DOT) com wrote: ... Say we have non-normalized table STUDENT: STUDENT ( STUDENT#, STUDENT_NAME, SUBJECT1#, SUBJECT2#, SUBJECT1_NAME, SUBJECT2_NAME, TEACHER1_NAME, TEACHER2_NAME ) I realize best thing to do would be to create two tables: STUDENT-SUBJECT ( STUDENT#, SUBJECT#, SUBJECT_NAME, TEACHER_NAME ) STUDENT ( STUDENT#, STUDENT_NAME) ... Heh, just to muddy the waters a little or even a lot, the conventional normalization discipline is really just a way to help determine a simple structure that avoids a lot of constraint verbiage. From what I gather of the typical SQL product it is effectively a sop that allows them to cop-out and not give very full constraint support. |
#35
| |||
| |||
|
|
Srubys (AT) gmail (DOT) com wrote: ... Say we have non-normalized table STUDENT: STUDENT ( STUDENT#, STUDENT_NAME, SUBJECT1#, SUBJECT2#, SUBJECT1_NAME, SUBJECT2_NAME, TEACHER1_NAME, TEACHER2_NAME ) I realize best thing to do would be to create two tables: STUDENT-SUBJECT ( STUDENT#, SUBJECT#, SUBJECT_NAME, TEACHER_NAME ) STUDENT ( STUDENT#, STUDENT_NAME) ... Heh, just to muddy the waters a little or even a lot, the conventional normalization discipline is really just a way to help determine a simple structure that avoids a lot of constraint verbiage. From what I gather of the typical SQL product it is effectively a sop that allows them to cop-out and not give very full constraint support. |
#36
| |||
| |||
|
|
Srubys (AT) gmail (DOT) com wrote: ... Say we have non-normalized table STUDENT: STUDENT ( STUDENT#, STUDENT_NAME, SUBJECT1#, SUBJECT2#, SUBJECT1_NAME, SUBJECT2_NAME, TEACHER1_NAME, TEACHER2_NAME ) I realize best thing to do would be to create two tables: STUDENT-SUBJECT ( STUDENT#, SUBJECT#, SUBJECT_NAME, TEACHER_NAME ) STUDENT ( STUDENT#, STUDENT_NAME) ... Heh, just to muddy the waters a little or even a lot, the conventional normalization discipline is really just a way to help determine a simple structure that avoids a lot of constraint verbiage. From what I gather of the typical SQL product it is effectively a sop that allows them to cop-out and not give very full constraint support. |
#37
| |||
| |||
|
|
Srubys (AT) gmail (DOT) com wrote: ... Say we have non-normalized table STUDENT: STUDENT ( STUDENT#, STUDENT_NAME, SUBJECT1#, SUBJECT2#, SUBJECT1_NAME, SUBJECT2_NAME, TEACHER1_NAME, TEACHER2_NAME ) I realize best thing to do would be to create two tables: STUDENT-SUBJECT ( STUDENT#, SUBJECT#, SUBJECT_NAME, TEACHER_NAME ) STUDENT ( STUDENT#, STUDENT_NAME) ... Heh, just to muddy the waters a little or even a lot, the conventional normalization discipline is really just a way to help determine a simple structure that avoids a lot of constraint verbiage. From what I gather of the typical SQL product it is effectively a sop that allows them to cop-out and not give very full constraint support. |
#38
| |||
| |||
|
|
greetings My book claims that for table to be in 1NF, we must: * Eliminate remove repeating groups of data * Create separate tables for each group of related data and identify each row with a unique column ( the primary key ) I know that for table to be in 1NF, we must remove repeating groups of data. But is it ( for relation to be in 1NF ) also required to create separate tables for each group of related data or is that just recommended and thus optional? |
The short answer is that your book is wrong.
The slightly longer answer is that the author probably expects you to be
able to "see" (in some magical way) what data belongs logically
together. If you do that, and if you're good at it, you might find your
data already in 3NF after this step. But on the other hand, if you mess
up you might never notice...
I dislike the advice. The reason is simply that, of all the steps taken
in database design, normalization is the one step where there are
actually clear rules on what's correct and what's not. Given the
functional dependencies, everyone who knows the rules can check your
design and explain exactly why it is or is not properly normalised (in
whatever normal form you're shooting for). This advice throws that huge
advantage of the normalization process out of the window.
Don't worry. As you normalize more often, you will get experienced, and
you will get to the point where you "see" the proper design and jot it
down immediately - and where you can still always fall back on the
individual steps for hard problems or if you feel a need to doublecheck.
Skipping this part now is like skipping the long division practice in
primary school because the questions are so simple that you can write
down the answer straight away - you'll regret missing the practice once
you run into the harder problems in high school.
Quote:
|
Say we have non-normalized table STUDENT: STUDENT ( STUDENT#, STUDENT_NAME, SUBJECT1#, SUBJECT2#, SUBJECT1_NAME, SUBJECT2_NAME, TEACHER1_NAME, TEACHER2_NAME ) I realize best thing to do would be to create two tables: STUDENT-SUBJECT ( STUDENT#, SUBJECT#, SUBJECT_NAME, TEACHER_NAME ) STUDENT ( STUDENT#, STUDENT_NAME) But would the following table also be considered in 1NF: STUDENT ( STUDENT#, STUDENT_NAME, SUBJECT, SUBJECT_NAME, TEACHER ) |
you're already aware of that).
Best, Hugo
#39
| |||
| |||
|
|
greetings My book claims that for table to be in 1NF, we must: * Eliminate remove repeating groups of data * Create separate tables for each group of related data and identify each row with a unique column ( the primary key ) I know that for table to be in 1NF, we must remove repeating groups of data. But is it ( for relation to be in 1NF ) also required to create separate tables for each group of related data or is that just recommended and thus optional? |
The short answer is that your book is wrong.
The slightly longer answer is that the author probably expects you to be
able to "see" (in some magical way) what data belongs logically
together. If you do that, and if you're good at it, you might find your
data already in 3NF after this step. But on the other hand, if you mess
up you might never notice...
I dislike the advice. The reason is simply that, of all the steps taken
in database design, normalization is the one step where there are
actually clear rules on what's correct and what's not. Given the
functional dependencies, everyone who knows the rules can check your
design and explain exactly why it is or is not properly normalised (in
whatever normal form you're shooting for). This advice throws that huge
advantage of the normalization process out of the window.
Don't worry. As you normalize more often, you will get experienced, and
you will get to the point where you "see" the proper design and jot it
down immediately - and where you can still always fall back on the
individual steps for hard problems or if you feel a need to doublecheck.
Skipping this part now is like skipping the long division practice in
primary school because the questions are so simple that you can write
down the answer straight away - you'll regret missing the practice once
you run into the harder problems in high school.
Quote:
|
Say we have non-normalized table STUDENT: STUDENT ( STUDENT#, STUDENT_NAME, SUBJECT1#, SUBJECT2#, SUBJECT1_NAME, SUBJECT2_NAME, TEACHER1_NAME, TEACHER2_NAME ) I realize best thing to do would be to create two tables: STUDENT-SUBJECT ( STUDENT#, SUBJECT#, SUBJECT_NAME, TEACHER_NAME ) STUDENT ( STUDENT#, STUDENT_NAME) But would the following table also be considered in 1NF: STUDENT ( STUDENT#, STUDENT_NAME, SUBJECT, SUBJECT_NAME, TEACHER ) |
you're already aware of that).
Best, Hugo
#40
| |||
| |||
|
|
greetings My book claims that for table to be in 1NF, we must: * Eliminate remove repeating groups of data * Create separate tables for each group of related data and identify each row with a unique column ( the primary key ) I know that for table to be in 1NF, we must remove repeating groups of data. But is it ( for relation to be in 1NF ) also required to create separate tables for each group of related data or is that just recommended and thus optional? |
The short answer is that your book is wrong.
The slightly longer answer is that the author probably expects you to be
able to "see" (in some magical way) what data belongs logically
together. If you do that, and if you're good at it, you might find your
data already in 3NF after this step. But on the other hand, if you mess
up you might never notice...
I dislike the advice. The reason is simply that, of all the steps taken
in database design, normalization is the one step where there are
actually clear rules on what's correct and what's not. Given the
functional dependencies, everyone who knows the rules can check your
design and explain exactly why it is or is not properly normalised (in
whatever normal form you're shooting for). This advice throws that huge
advantage of the normalization process out of the window.
Don't worry. As you normalize more often, you will get experienced, and
you will get to the point where you "see" the proper design and jot it
down immediately - and where you can still always fall back on the
individual steps for hard problems or if you feel a need to doublecheck.
Skipping this part now is like skipping the long division practice in
primary school because the questions are so simple that you can write
down the answer straight away - you'll regret missing the practice once
you run into the harder problems in high school.
Quote:
|
Say we have non-normalized table STUDENT: STUDENT ( STUDENT#, STUDENT_NAME, SUBJECT1#, SUBJECT2#, SUBJECT1_NAME, SUBJECT2_NAME, TEACHER1_NAME, TEACHER2_NAME ) I realize best thing to do would be to create two tables: STUDENT-SUBJECT ( STUDENT#, SUBJECT#, SUBJECT_NAME, TEACHER_NAME ) STUDENT ( STUDENT#, STUDENT_NAME) But would the following table also be considered in 1NF: STUDENT ( STUDENT#, STUDENT_NAME, SUBJECT, SUBJECT_NAME, TEACHER ) |
you're already aware of that).
Best, Hugo
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.