Finding entities and normalizing-HELP

Can anyone help me make the entieis for my business and help me normalize the data by using the steps of normalisation- meaning first normal form, second normal form and third normal form.
Well my business would like to make a database for saving customers details, product details, and be able to send orders to customers including shipping information. So please help.

OR

You could look at the diagram given and show my how the information was normalized and how the entites were found by doing it in steps- first normal form, second normal form and third normal form.

Please help

I do'nt understand your questions...

Your diagram looks normalized; I can't see where any redundant data would slip in.

Where did this diagram and table-set come from?
Assuming you created it, wouldn't you know the steps you took to complete it?

Otherwise, why would you want to see a poorly normalized database and take a step back in the process?

I think they are after either a run down on how to normalise their database and that the picture is one they have found and would like to know how it got to this stage from one table.

MySQL's site has a quick rundown of normalization here. You can also find a bunch of tutorials and such with a quick google of 'database normalization' -- these tutorials will probably serve you better than anything we could give you in a necessarily abbreviated forum post, at least for an overview. If you hit a specific sticking point you want to discuss, don't hesitate to post it.

1. By definition, all tables are in 1NF, if you data model is the Relational Data Model. Btw, in your data model there are address, city, postal code etc, why?
   
2. All tables are in 2NF because each primary key consist of only one attribute, that is all non-key attributes fully functionally dependent on their appropriate surrogate key. Apart from order details: because unitprice only dependents on productid 2NF is formally violated --> drop unitprice, it's already in products. BUT BUT BUT: if unitprice changes in the future, contracted unit price has to be stored in order details. So normal forms often depend on your proper arguments at hand on time.
   
3. All tables seems to be in 3NF. One can construe nice „academic“ transitive dependencies, for example postalcode --> city --> customerid etc. But decomposition of such stuff into smaller tables is really far-fetched. (BCNF isn't fulfilled)
   
   
4. Is your design complete?
   
   

Shipperid is not foreign key in orders.

Contactname: couldn't there be more than one such person per company per contract?

Products: what about more than one order at a time?

Suppliers ---< Products: if there is more than one supplier a product, cardinality must be many-to-many (>---<).

As shippers may assume, wouldn't it be more convenient also to manage invoices?

There is a good article on database design and transformation in relationnal scheme here:
* Database Modelling in UML
http://www.methodsandtools.com/archive/archive.php?id=9