Normalization Explained in simple terms

Normalization is the process of efficiently organizing data in a database. There are two goals of the normalization process: eliminating redundant data (for example, storing the same data in more than one table) and ensuring data dependencies make sense (only storing related data in a table). Both of these are worthy goals as they reduce the amount of space a database consumes and ensure that data is logically stored.
The Normal Forms

The database community has developed a series of guidelines for ensuring that databases are normalized. These are referred to as normal forms and are numbered from one (the lowest form of normalization, referred to as first normal form or 1NF) through five (fifth normal form or 5NF). In practical applications, you'll often see 1NF, 2NF, and 3NF along with the occasional 4NF. Fifth normal form is very rarely seen and won't be discussed in this article.
First Normal Form (1NF) sets the very basic rules for an organized database:
Eliminate duplicative columns from the same table.
Create separate tables for each group of related data and identify each row with a unique column (the primary key).
What do these rules mean when contemplating the practical design of a database? It's actually quite simple.
The first rule dictates that we must not duplicate data within the same row of a table. Within the database community, this concept is referred to as the atomicity of a table. Tables that comply with this rule are said to be atomic. Let's explore this principle with a classic example - a table within a human resources database that stores the manager-subordinate relationship. For the purposes of our example, we'll impose the business rule that each manager may have one or more subordinates while each subordinate may have only one manager.
Intuitively, when creating a list or spreadsheet to track this information, we might create a table with the following fields:
Manager
Subordinate1
Subordinate2
Subordinate3
Subordinate4
However, recall the first rule imposed by 1NF: eliminate duplicative columns from the same table. Clearly, the Subordinate1-Subordinate4 columns are duplicative. Take a moment and ponder the problems raised by this scenario. If a manager only has one subordinate - the Subordinate2-Subordinate4 columns are simply wasted storage space (a precious database commodity). Furthermore, imagine the case where a manager already has 4 subordinates - what happens if she takes on another employee? The whole table structure would require modification.
At this point, a second bright idea usually occurs to database novices: We don't want to have more than one column and we want to allow for a flexible amount of data storage. Let's try something like this:
Manager
Subordinates
Where the Subordinates field contains multiple entries in the form "Mary, Bill, Joe"
This solution is closer, but it also falls short of the mark. The subordinates column is still duplicative and non-atomic. What happens when we need to add or remove a subordinate? We need to read and write the entire contents of the table. That's not a big deal in this situation, but what if one manager had one hundred employees? Also, it complicates the process of selecting data from the database in future queries.
Here's a table that satisfies the first rule of 1NF:
Manager
Subordinate
In this case, each subordinate has a single entry, but managers may have multiple entries.
Now, what about the second rule: identify each row with a unique column or set of columns (the primary key)? You might take a look at the table above and suggest the use of the subordinate column as a primary key. In fact, the subordinate column is a good candidate for a primary key due to the fact that our business rules specified that each subordinate may have only one manager. However, the data that we've chosen to store in our table makes this a less than ideal solution. What happens if we hire another employee named Jim? How do we store his manager-subordinate relationship in the database?
It's best to use a truly unique identifier (such as an employee ID) as a primary key. Our final table would look like this:
Manager ID
Subordinate ID
2ND Normal Form
Over the past month, we've looked at several aspects of normalizing a database table. First, we discussed the basic principles of database normalization. Last time, we explored the basic requirements laid down by the first normal form (1NF). Now, let's continue our journey and cover the principles of second normal form (2NF).

Recall the general requirements of 2NF:
Remove subsets of data that apply to multiple rows of a table and place them in separate tables.
Create relationships between these new tables and their predecessors through the use of foreign keys.
These rules can be summarized in a simple statement: 2NF attempts to reduce the amount of redundant data in a table by extracting it, placing it in new table(s) and creating relationships between those tables.

Let's look at an example. Imagine an online store that maintains customer information in a database. They might have a single table called Customers with the following elements:
CustNum
FirstName
LastName
Address
City
State
ZIP
A brief look at this table reveals a small amount of redundant data. We're storing the "Sea Cliff, NY 11579" and "Miami, FL 33157" entries twice each. Now, that might not seem like too much added storage in our simple example, but imagine the wasted space if we had thousands of rows in our table. Additionally, if the ZIP code for Sea Cliff were to change, we'd need to make that change in many places throughout the database.

In a 2NF-compliant database structure, this redundant information is extracted and stored in a separate table. Our new table (let's call it ZIPs) might have the following fields:
ZIP
City
State
If we want to be super-efficient, we can even fill this table in advance -- the post office provides a directory of all valid ZIP codes and their city/state relationships. Surely, you've encountered a situation where this type of database was utilized. Someone taking an order might have asked you for your ZIP code first and then knew the city and state you were calling from. This type of arrangement reduces operator error and increases efficiency.

Now that we've removed the duplicative data from the Customers table, we've satisfied the first rule of second normal form. We still need to use a foreign key to tie the two tables together. We'll use the ZIP code (the primary key from the ZIPs table) to create that relationship. Here's our new Customers table:
CustNum
FirstName
LastName
Address
ZIP
We've now minimized the amount of redundant information stored within the database and our structure is in second normal form!
3RD Normal Form
There are two basic requirements for a database to be in third normal form:
Already meet the requirements of both 1NF and 2NF
Remove columns that are not fully dependent upon the primary key.
Imagine that we have a table of widget orders that contains the following attributes:
Order Number
Customer Number
Unit Price
Quantity
Total
Remember, our first requirement is that the table must satisfy the requirements of 1NF and 2NF. Are there any duplicative columns? No. Do we have a primary key? Yes, the order number. Therefore, we satisfy the requirements of 1NF. Are there any subsets of data that apply to multiple rows? No, so we also satisfy the requirements of 2NF.
Now, are all of the columns fully dependent upon the primary key? The customer number varies with the order number and it doesn't appear to depend upon any of the other fields. What about the unit price? This field could be dependent upon the customer number in a situation where we charged each customer a set price. However, looking at the data above, it appears we sometimes charge the same customer different prices. Therefore, the unit price is fully dependent upon the order number. The quantity of items also varies from order to order, so we're OK there.
What about the total? It looks like we might be in trouble here. The total can be derived by multiplying the unit price by the quantity, therefore it's not fully dependent upon the primary key. We must remove it from the table to comply with the third normal form. Perhaps we use the following attributes:
Order Number
Customer Number
Unit Price
Quantity
Now our table is in 3NF. But, you might ask, what about the total? This is a derived field and it's best not to store it in the database at all. We can simply compute it "on the fly" when performing database queries. For example, we might have previously used this query to retrieve order numbers and totals:
SELECT OrderNumber, Total
FROM WidgetOrders
We can now use the following query:
SELECT OrderNumber, UnitPrice * Quantity AS Total
FROM WidgetOrders
to achieve the same results without violating normalization rules.

Before we begin our discussion of the normal forms, it's important to point out that they are guidelines and guidelines only. Occasionally, it becomes necessary to stray from them to meet practical business requirements. However, when variations take place, it's extremely important to evaluate any possible ramifications they could have on your system and account for possible inconsistencies

How the Object/Classes are compiled?

How the Object/Classes are compiled?

To be specific, how are classes represented in binary code?
This is a very interesting question. In c++ an object or a structure is simply a block of memory that is equal to the sum of sizes of itsmembers in the simple case.
So
class CTest
{
public: int a;
void set(int v){a=v}
}


Could be boken down to an amlost equivalent c representation :
Struct CTest
{
int a;
}

void set(int v, Ctest * this)
{ this->a = v }

Don't take it at face value as such but this is almost what it means.

Why i++ ++ won't work in C?

Why i++ ++ won't work in C? [Also ++i++ etc. will not work]

i++ yeilds a value, and operators don't work on values, they work on objects.
So the second ++ fails, with the error 'lvalue required' ie,address required.
Same is the case with ++i++.
To enumerate i++ is equivalent of(i = i + 1)
Correct ?
So an i++ ++ would be (i = i + 1) = ???That is the expression returns a value and not a variable and so thesecond operand can work on a value type for the simple reason thatsaying 5++ or 10++ is invalid.

64 bit OS and 32 bit OS. diff?

What is the difference between 64 bit OS and 32 bit OS.
64 bit OS may use inverted page tables, What else?

A 64-bit OS needs to have full support for 64-bit hardware plus support for 32-bit legacy programs.

A 64 bit OS is one that takes advantage of an underlying 64 bit hardware architecture. That means that typically the registers would be 64bitswide and integer operations would occur on 64 bit values. Also typically hardware architectures don't have such simple changes as simply lengething the registers - so a typical OS would utilise the newfeatures of the hardware.

I don't know what inverted page tables are, can you tell me ?You can read a little about the new IA64 acrhuecture here: (veryinteresting)http://msdn.microsoft.com/msdnmag/issues/01/06/hood/
http://msdn.microsoft.com/msdnmag/issues/01/07/hood/Win 2003 server has a 64 bit version along with a host of other coolthings.

Compiled program fasteer why?

it is obvious that it is convinient to develop a NEW program using an interpreter(C) rather than a compiler.But once an error free pgm has been developed, a compiled version will normally EXECUTE FASTER than an interpreter..WHY?


a compiler program is one that is convertedt into a sequence ofbytes that denotes the opcodes that the processor of your computer willunderstand. So when a compiled program runs all it actually does is thatthe bytes of program are sent to the procress one by one and this causesthe processer to do the things that you wanted the program to do.

When you interpret a program the 'interpreter' program is the one thatis executed by your processor and it executes sequences ofcommands/intructions that in effect will simulate the commands in yourprogram. So since at every point there is mediator between your programand the computer hardware, the interpreted program runs slower.Do you understand ?