I`d say no you are not wrong, but the teacher is not necessarily wrong either. A class can be almost anything in C++. - Can be an interface - Can be a functor - Can be just data - Whatever... so, depending on how the teacher wants the thing to evolve he might direct his students. with very little or no context it is hard to decide who's right. If you are using class to model things, they can be names. If they model actions, they can be verbs. If they model attributes, they can be adjectives. classes are one of the mechanisms for encapsulation & data hiding after that, when I do code review, I usually check the coupling between the class and the client, this usually tells me if the data hiding or encapsulation is at a proper level or done right.

I work for a finance institution, and our tables are highly un-normalized with all the problems this incurs. we have many tables with hundreds of columns. But people in finance are used to excel like spreadsheet and they want to see everything at one place. I came to that place with a background in databases and I was horrified and still am. But it is hard to change legacy code AND mentalities. So for better or worse I'm stuck with it. The best advice I can give you: find the queries people/programs make the most often, this often reveal the «subtables» within the big one. Also if you have self join that often indicate two tables (or more) sharing the same table data. Once you have that draw a diagram as if those tables really exist. If you can create views that represent those tables. This way you will better understand the «schema»

Quote:

«Il faut imaginer Sisyphe heureux» Albert Camus

the same way as one could say any data in a file is a database: a huge stretch of the imagination! :-D