google vb.net and uml, you'll get some examples.
As for putting your database stuff in the entity class. I've done it and seen it done and it can work, but there's a cost depending on what access to the db you need.
If you are 1 to 1, ie customers class is the only one to access the customer table and you are unlikely to want to change which database you are sourcing from, say you want to use both sql server and Mysql as backends, then it's a goer.
Personally I prefer to have a class that does all dealing with the Db, and implement it through an interface.
So the you can have an interface method called getCustomers which takes some parameter and returns an aggregate of customer instances and implement it in SQLDBClass.
That way all your sql is one place, you can keep all your connection stuff in there as well. Then if you make it part of a library you can swap in another backend simply by swapping the dll.
It also gives you the oportunity to say , go for file based xml system etc.
Something as superficially simple as renaming a table, if that table name is 'all over the place' can become a very comple task. It will happen, pepare for it.
I recommend you look up the MVC pattern, it tends to fit very well with straight client server database applications.
There's no rocket science to implementing UMlL diagram as a .net class by the way. It's just a class, nothing special about it at all. Whether you can or not depends on your knowledge of the language and the quality of the UML. Whether you should... well, that is scenario specific. Just because it's described by UML, doesn't mean it's correct or practical.