Usually, it helps me to draw out my code, using something like UML, or just a pen and paper.

In most circumstances, I use a wrapper class to do all of the talking to my database. That way, all of the calling classes/methods don't have to know anything about what type of database I'm connecting to.

Encapsulation is the word of the day in this matter-- the thing to focus on is this question:

"If I change something in class A, will I have to change anything in Class B to keep using Class A with it?"

If your answer is yes, then you probably need to change something in your design. The whole idea with object orientation is to have the object you've created be almost entirely responsible for doing stuff to itself. At least, that's how I understand it.

Can you post some code snippets of some parts that make you uneasy about your design? I'll admit I'm somewhat of a noob still at this game, but after reading the book Object Oriented Thought Process (disclaimer:informational link, no referrals, or anything), I really feel stronger in what exactly you're supposed to accomplish with OO design. I'm not through with the book yet, but they really reinforce the idea of encapsulation in EVERYTHING they do.

Basically, make a method that describes what you want to do. Then, the class that instantiated your object can call it, without knowing anything about what the method actually does. If done right, you can completely change the way your method works, but if you return the same types of values, and accept the same parameters as before, then the instantiating class will be none the wiser that you've changed anything