 | |
Need some help on Normalization
comp.databases.sybase comp.databases.sybase
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
Need some help on Normalization -
10-10-2008
, 08:03 AM
#2
| |||||
| |||||
|
|
You identify the following attributes, in part, for the Employee entity: Employee number (Primary key) Full name Phone number Supervisor number What change should you make to ensure that the entity is normalized to the 1st normal form (1NF)? A) Separate the full name into first, middle (optional), and last names. |
Quote:
|
B) Use a different primary key value. |
value, so it's independent of any of the employee's stored data.
Quote:
|
C) Move the supervisor to a different table. |
are still employees, and should be stored in the same table.
Quote:
|
D) Separate the phone number into separate fields. |
numbers in a separate table, with the area code being a key field (which
is going way overboard, IMO). Also not if you want to be able to handle
different countries (because every country has their own style for
writing a phone number), though you might want to store the country code
as a separate field. If a user may have several different phone numbers
(home, office, mobile, pager, etc), you will sometimes see them stored
in a separate table, with foreign keys pointing to the employee's
record, and to indicate the "type" of number.
Quote:
|
I see the table as looking like this: *Emp # (PK) Full name Phone# Supervisor#* 123 Joe Smith 123-4567 1 888 John Doe 555-1212 2 316 Jack Pi 888-8080 1 451 Suzy Q 457-7410 3 Anybody have any comments? Thanks is advance - is there an answer |
proven to work well in real-life applications, which I'm assuming you
are working toward. "Full" normalization in a database theory situation
is a completely different world which has little to do with real-world
usage.
--
/~\ The ASCII
\ / Ribbon Campaign
X Against HTML
/ \ Email!
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).
#3
| |||||
| |||||
|
|
You identify the following attributes, in part, for the Employee entity: Employee number (Primary key) Full name Phone number Supervisor number What change should you make to ensure that the entity is normalized to the 1st normal form (1NF)? A) Separate the full name into first, middle (optional), and last names. |
Quote:
|
B) Use a different primary key value. |
value, so it's independent of any of the employee's stored data.
Quote:
|
C) Move the supervisor to a different table. |
are still employees, and should be stored in the same table.
Quote:
|
D) Separate the phone number into separate fields. |
numbers in a separate table, with the area code being a key field (which
is going way overboard, IMO). Also not if you want to be able to handle
different countries (because every country has their own style for
writing a phone number), though you might want to store the country code
as a separate field. If a user may have several different phone numbers
(home, office, mobile, pager, etc), you will sometimes see them stored
in a separate table, with foreign keys pointing to the employee's
record, and to indicate the "type" of number.
Quote:
|
I see the table as looking like this: *Emp # (PK) Full name Phone# Supervisor#* 123 Joe Smith 123-4567 1 888 John Doe 555-1212 2 316 Jack Pi 888-8080 1 451 Suzy Q 457-7410 3 Anybody have any comments? Thanks is advance - is there an answer |
proven to work well in real-life applications, which I'm assuming you
are working toward. "Full" normalization in a database theory situation
is a completely different world which has little to do with real-world
usage.
--
/~\ The ASCII
\ / Ribbon Campaign
X Against HTML
/ \ Email!
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).
#4
| |||||
| |||||
|
|
You identify the following attributes, in part, for the Employee entity: Employee number (Primary key) Full name Phone number Supervisor number What change should you make to ensure that the entity is normalized to the 1st normal form (1NF)? A) Separate the full name into first, middle (optional), and last names. |
Quote:
|
B) Use a different primary key value. |
value, so it's independent of any of the employee's stored data.
Quote:
|
C) Move the supervisor to a different table. |
are still employees, and should be stored in the same table.
Quote:
|
D) Separate the phone number into separate fields. |
numbers in a separate table, with the area code being a key field (which
is going way overboard, IMO). Also not if you want to be able to handle
different countries (because every country has their own style for
writing a phone number), though you might want to store the country code
as a separate field. If a user may have several different phone numbers
(home, office, mobile, pager, etc), you will sometimes see them stored
in a separate table, with foreign keys pointing to the employee's
record, and to indicate the "type" of number.
Quote:
|
I see the table as looking like this: *Emp # (PK) Full name Phone# Supervisor#* 123 Joe Smith 123-4567 1 888 John Doe 555-1212 2 316 Jack Pi 888-8080 1 451 Suzy Q 457-7410 3 Anybody have any comments? Thanks is advance - is there an answer |
proven to work well in real-life applications, which I'm assuming you
are working toward. "Full" normalization in a database theory situation
is a completely different world which has little to do with real-world
usage.
--
/~\ The ASCII
\ / Ribbon Campaign
X Against HTML
/ \ Email!
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).
#5
| |||||
| |||||
|
|
You identify the following attributes, in part, for the Employee entity: Employee number (Primary key) Full name Phone number Supervisor number What change should you make to ensure that the entity is normalized to the 1st normal form (1NF)? A) Separate the full name into first, middle (optional), and last names. |
Quote:
|
B) Use a different primary key value. |
value, so it's independent of any of the employee's stored data.
Quote:
|
C) Move the supervisor to a different table. |
are still employees, and should be stored in the same table.
Quote:
|
D) Separate the phone number into separate fields. |
numbers in a separate table, with the area code being a key field (which
is going way overboard, IMO). Also not if you want to be able to handle
different countries (because every country has their own style for
writing a phone number), though you might want to store the country code
as a separate field. If a user may have several different phone numbers
(home, office, mobile, pager, etc), you will sometimes see them stored
in a separate table, with foreign keys pointing to the employee's
record, and to indicate the "type" of number.
Quote:
|
I see the table as looking like this: *Emp # (PK) Full name Phone# Supervisor#* 123 Joe Smith 123-4567 1 888 John Doe 555-1212 2 316 Jack Pi 888-8080 1 451 Suzy Q 457-7410 3 Anybody have any comments? Thanks is advance - is there an answer |
proven to work well in real-life applications, which I'm assuming you
are working toward. "Full" normalization in a database theory situation
is a completely different world which has little to do with real-world
usage.
--
/~\ The ASCII
\ / Ribbon Campaign
X Against HTML
/ \ Email!
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).
#6
| |||||
| |||||
|
|
You identify the following attributes, in part, for the Employee entity: Employee number (Primary key) Full name Phone number Supervisor number What change should you make to ensure that the entity is normalized to the 1st normal form (1NF)? A) Separate the full name into first, middle (optional), and last names. |
Quote:
|
B) Use a different primary key value. |
value, so it's independent of any of the employee's stored data.
Quote:
|
C) Move the supervisor to a different table. |
are still employees, and should be stored in the same table.
Quote:
|
D) Separate the phone number into separate fields. |
numbers in a separate table, with the area code being a key field (which
is going way overboard, IMO). Also not if you want to be able to handle
different countries (because every country has their own style for
writing a phone number), though you might want to store the country code
as a separate field. If a user may have several different phone numbers
(home, office, mobile, pager, etc), you will sometimes see them stored
in a separate table, with foreign keys pointing to the employee's
record, and to indicate the "type" of number.
Quote:
|
I see the table as looking like this: *Emp # (PK) Full name Phone# Supervisor#* 123 Joe Smith 123-4567 1 888 John Doe 555-1212 2 316 Jack Pi 888-8080 1 451 Suzy Q 457-7410 3 Anybody have any comments? Thanks is advance - is there an answer |
proven to work well in real-life applications, which I'm assuming you
are working toward. "Full" normalization in a database theory situation
is a completely different world which has little to do with real-world
usage.
--
/~\ The ASCII
\ / Ribbon Campaign
X Against HTML
/ \ Email!
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).
#7
| |||||
| |||||
|
|
You identify the following attributes, in part, for the Employee entity: Employee number (Primary key) Full name Phone number Supervisor number What change should you make to ensure that the entity is normalized to the 1st normal form (1NF)? A) Separate the full name into first, middle (optional), and last names. |
Quote:
|
B) Use a different primary key value. |
value, so it's independent of any of the employee's stored data.
Quote:
|
C) Move the supervisor to a different table. |
are still employees, and should be stored in the same table.
Quote:
|
D) Separate the phone number into separate fields. |
numbers in a separate table, with the area code being a key field (which
is going way overboard, IMO). Also not if you want to be able to handle
different countries (because every country has their own style for
writing a phone number), though you might want to store the country code
as a separate field. If a user may have several different phone numbers
(home, office, mobile, pager, etc), you will sometimes see them stored
in a separate table, with foreign keys pointing to the employee's
record, and to indicate the "type" of number.
Quote:
|
I see the table as looking like this: *Emp # (PK) Full name Phone# Supervisor#* 123 Joe Smith 123-4567 1 888 John Doe 555-1212 2 316 Jack Pi 888-8080 1 451 Suzy Q 457-7410 3 Anybody have any comments? Thanks is advance - is there an answer |
proven to work well in real-life applications, which I'm assuming you
are working toward. "Full" normalization in a database theory situation
is a completely different world which has little to do with real-world
usage.
--
/~\ The ASCII
\ / Ribbon Campaign
X Against HTML
/ \ Email!
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).
#8
| |||||
| |||||
|
|
You identify the following attributes, in part, for the Employee entity: Employee number (Primary key) Full name Phone number Supervisor number What change should you make to ensure that the entity is normalized to the 1st normal form (1NF)? A) Separate the full name into first, middle (optional), and last names. |
Quote:
|
B) Use a different primary key value. |
value, so it's independent of any of the employee's stored data.
Quote:
|
C) Move the supervisor to a different table. |
are still employees, and should be stored in the same table.
Quote:
|
D) Separate the phone number into separate fields. |
numbers in a separate table, with the area code being a key field (which
is going way overboard, IMO). Also not if you want to be able to handle
different countries (because every country has their own style for
writing a phone number), though you might want to store the country code
as a separate field. If a user may have several different phone numbers
(home, office, mobile, pager, etc), you will sometimes see them stored
in a separate table, with foreign keys pointing to the employee's
record, and to indicate the "type" of number.
Quote:
|
I see the table as looking like this: *Emp # (PK) Full name Phone# Supervisor#* 123 Joe Smith 123-4567 1 888 John Doe 555-1212 2 316 Jack Pi 888-8080 1 451 Suzy Q 457-7410 3 Anybody have any comments? Thanks is advance - is there an answer |
proven to work well in real-life applications, which I'm assuming you
are working toward. "Full" normalization in a database theory situation
is a completely different world which has little to do with real-world
usage.
--
/~\ The ASCII
\ / Ribbon Campaign
X Against HTML
/ \ Email!
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).
#9
| |||||
| |||||
|
|
You identify the following attributes, in part, for the Employee entity: Employee number (Primary key) Full name Phone number Supervisor number What change should you make to ensure that the entity is normalized to the 1st normal form (1NF)? A) Separate the full name into first, middle (optional), and last names. |
Quote:
|
B) Use a different primary key value. |
value, so it's independent of any of the employee's stored data.
Quote:
|
C) Move the supervisor to a different table. |
are still employees, and should be stored in the same table.
Quote:
|
D) Separate the phone number into separate fields. |
numbers in a separate table, with the area code being a key field (which
is going way overboard, IMO). Also not if you want to be able to handle
different countries (because every country has their own style for
writing a phone number), though you might want to store the country code
as a separate field. If a user may have several different phone numbers
(home, office, mobile, pager, etc), you will sometimes see them stored
in a separate table, with foreign keys pointing to the employee's
record, and to indicate the "type" of number.
Quote:
|
I see the table as looking like this: *Emp # (PK) Full name Phone# Supervisor#* 123 Joe Smith 123-4567 1 888 John Doe 555-1212 2 316 Jack Pi 888-8080 1 451 Suzy Q 457-7410 3 Anybody have any comments? Thanks is advance - is there an answer |
proven to work well in real-life applications, which I'm assuming you
are working toward. "Full" normalization in a database theory situation
is a completely different world which has little to do with real-world
usage.
--
/~\ The ASCII
\ / Ribbon Campaign
X Against HTML
/ \ Email!
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).
#10
| |||
| |||
|
|
In article <62ed393e-9794-4c4f-a34a-b0eca18ecf10 @i76g2000hsf.googlegroups.com>, techtechx... (AT) gmail (DOT) com says... D) Separate the phone number into separate fields. That has nothing to do with normalization, unless you are going to store numbers in a separate table, with the area code being a key field (which is going way overboard, IMO). Also not if you want to be able to handle different countries (because every country has their own style for writing a phone number), though you might want to store the country code as a separate field. |
the country code from the rest of the number, because we send messages
to people's cell phones using an SMS service provider. Their rules
mandate that we have to send them the country code in a separate
field.
Other than that, there are absolutely no consistent rules for
formatting a phone number, especially between different countries, and
very often even within the same country. I'm tempted to carry two
versions of the phone number, one with punctuation and formatting
stripped out. It would be easier to search, because you could do { and
phone like '%1234%' } and not worry about where or whether the person
put dashes or spaces or pluses or parentheses, etc. etc. etc.
:-)
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.