Can anyone please explain Normalization?

I know this is basic, but normalization always confuses me.
I know the definitions for normalization.
Let me say I have a
Company and Employee details like COMPANYNAME, COMPANYLOCATION,EMPLOYEEID,EMPLOYEEFIRSTNAME,EMPLOYEELASTNAME,DEPT,EMPLOYEEDEPT,EMPLOYEEID ........something like this.
Can any one please explain me how I can divide this in 1NF,2NF,3NF and 4NF.

It appears you know the theoretical definition but are seeking practical guidance. With that in mind, think of normalization as the simplification of data. The goal is to remove redundancy. Do not store anything you can calculate from other data items. For example, age is a function of birth date. Volume, area, perimeter, et cetera are functions of length, width, and height. Similarly, normalization seeks to reduce unnecessary repetition of lengthy data. Instead of storing the same address for the 80 people in a company, you can save the address of the company once and reference the ID of the company/location on each employee or in an associative table.

Therefore, I would not get caught up in the normal forms. In some practice, it may make sense to have some denormalization — or at least normalization at a lower normal form. The key is to normalize data, so it fits business needs efficiently as well as effectively.

Hence, start with the entities. In your case, you have companies, employees, departments, locations, et cetera. Once you know the entities, think of the relationships. If you put each entity in a table and carefully build relationships through associative tables or foreign keys, you will achieve sufficient normalization.

It also will force you to think through things like multiple locations per company, and other less obvious details about the entity relationships.

The idea of normalization is to remove redundancy in your data and make all of your data accessible via queries:
1NF: Ensure that all data items contain only one value (no lists inside of columns). Pull those items into their own table linked by the parent ID
2NF/3NF: Ensure that all data in the table depends on the whole key. In your example, the Employee information(depends on EmployeeID), Department information( on DeptID), and Company information are relatively independent and should be separated into distinct tables. The difference between 2NF and 3NF is very subtle and has do with with whether the data is directly dependent or transitively dependent on the Candidate key. The joke is that 2NF depends on "the whole key" and 3NF depends on "Nothing but the key"

Beyond 3NF is technical and often either trivial or not necessary. One of them (I don't recall which one right now) requires that there be no NULL values. Any column that could be null is extracted out into its own relation. For practical purposes going beyond 3NF will either be unnecessary or will happen automatically as you need whatever feature you gain from it.

For your example, Extracting your data into tables for Company, Department, Employee and possibly location would easily put it into 3NF.

Introduction
SQL Server Integration Services can read XML files, that’s known by every BI developer. (If you didn’t, don’t worry, I’m aiming this article at newcomers as well.)
But how far can you go? When does the XML Source component become …

Using examples as well as descriptions, and references to Books Online, show the documentation available for datatypes, explain the available data types and show how data can be passed into and out of variables.