Thank you for your replies. I do agree that behaviors and responsibility are very important in OO design. By Larman's method, we identify all kinds of nouns, i.e. entities first. That's exactly what I do for database design. And in my OO design, I seldom has classes called "User", "Customer", "Company", etc, which tends to appear as tables in database. In constrcat, I have classes called "Processor", "Scheduler", "Examiner", which are neither Actor in in Use Cases nor tables in database.
I do have questions about how to make good designs that better fit for appliations with dtabase.
As the database gets more power, Database can do a lot of jobs as well. For example, I'm involved in a project for PC scheduling. We can either use program to do the scheduling, or let database decide how to schedule a particular session. Seems the second solution is better, because database has all the information for scheduling. So I passed the input to database, and let a stored procedure handle the rest of work. In this sense, database can acts like classes and objects.
Can anyone recommend some design principles? what kind of jobs are done by database, and what done by program? All advice is appreciated.