UML is the "tool" that most OO developers use to map their entities however it's not a tool for beginners
The main thing is to get to grips with the entities that your app needs and work out their relatioships with each other and nothing beats a pencil and paper for this.
An entity is a "thing" but when trying work out what entities you need to be represented as database tables you need to look at designing your database to at least 3rd normal form (This should give you a starting point http://en.wikipedia.org/wiki/Database_normalization)
The thing is that when starting out as a beginner it is difficult to understand what your entities really are.
For example if your app makes a cup of tea then your entities are going to be kettle, water, power source, cup, milk and sugar but what do you need to know about all those things?
Probably it is enough to know that a kettle has a fill_with_water method, a boil method and a pour method and these make up your models methods for a kettle object and you probably need very few properties (field columns) maybe even only just a name.
But if you're app is making kettles then you will have to know about things like which spout to use, what plug to use if electric what handle to use, fill level indicator, filter etc...
But most of the above properties will most likely be just foreign keys to a spouts table, a plugs table etc... the only property in the above scenario would be a boolean flag that may end up being an STI type field to decide if the kettle is electric or gas
Take heart, once you understand the principles of normalisation you will find that database design beomes very simple and you will only map out the very complex stuff like how to run an airline. I REALLY MUST qualify that "very simple" statement though.
Database design is EXTREMELY important and can be extremely complex, especially when working out indexes and when to flatten out (de-normalise) for performance but if you design your app well you will find that the main structure of tables and columns kinda just dictates itself to the poit that I don;t even think about the database design anymore it just happens but I DO recommend charting your database design and I find this tool really usefull for this purpose (Just my preference) http://sqldeveloper.solyp.com/screensho
Concentrate on good software desing, the database will follow, then concentrate on good indexing and optimisation (Essesntial)!
What you want and what you need are too often not the same thing!
When your head is hurting from trying to solve a problem, stop standing on it. When you are the right way up you will see the problem differently and you just might find the solution.
(Quote by me 15th July 2009)