So basically I suck when it comes to sorting (i hated bubble sorts from SD with a passion)
A database user has stored the following numbers exactly as they appear below:
- 0020
- 010
- 100.01
- 8.0
The numbers are then sorted into ascending order. What format would they be sorted in, and what order would they appear in after being sorted?
A. They would be stored as numbers, and when sorted the first number is 8.0.
B. They would be stored as text, and when sorted the first number is 010.
C. They would be stored as text, and when sorted the first number is 0020.
D. They would be stored as text, and when sorted the first number is 010.
Their suggestions suggest C (awks when B and D are the same answer) but I don't get how they can sort text data into an ascending/descending pattern, I thought the reason why we assign numeric data types was for easy manipulation of numbers.
This is playing off from what you would call a discriminator question from last years ITA MC section.
If it's stored as a numeric data type, then it'd be sorted like numbers e.g. in ascending order:
8.0, 010, 0020, 100.01 since you'd read them as 8, 10, 20, 100.01 respectively.
But if we stored them as a numeric data type, we would lose those zeroes at the start, and hence you wouldn't have the numbers exactly as entered. Hence we can rule out A.
Ascending order in terms of text is A to Z. Descending order in terms of text is Z to A.
Text data is sorted character by character and alphabetically e.g. A, B, C, D, E. If you have numbers, then it's always in the order 0, 1, 2, 3, 4, 5.It's character by character though, so place value of the numbers doesn't matter. If the values are the same, then you move onto the next character for comparing two pieces of text data. For example this is text data sorted ascending: 0, 1, 11, 20, 23
If it was stored as text, ascending, then they'd be sorted:
0020, 010, 100.01, 8.0
That's exactly the same as it was entered (answer C). Descending would be the other way around.
So the answer is C.
If a table doesn't satisfy the first normalisation form, it can still satisfy the proceeding normalisation forms, right?
Nope. You must satisfy the lower forms before preceding to the higher forms.
1NF: One piece of data per field. No duplicates.
2NF: A key is the set of fields that are used to identify single record completely (e.g. for an order, the key would be CustomerID and the ProductID). Any of the non-key fields in the record must relate to all of those key fields.
3NF: This is stricter than 2NF, mandating that every field must relate directly to the primary key with no exceptions.
You can't have valid 2NF, without having split up your data into 1NF first. You'd have some very crappy normalisation efforts if you didn't get rid of duplicate fields, or had more than one data per field.
For example, you could have an address, suburb and postcode in one field (invalid 1NF). Let's say you then tried to apply 2NF - which might involve shoving off the postcodes into their table. You're unable to do this as you don't have valid 1NF, and hence you're left with invalid 2NF.
You can't have valid 3NF if you have fields that don't relate to the keys at all (invalid 2NF), since that would also be invalid 3NF.
Home
Help
Search
Login
