Kudose, principles are just starting points, not unbreakable rules. The principle you refer to concerns itself with Object Persistence and Object-Relational Mapping. From that perspective, the database exists just to persist objects and their data from call to call. So each class has it's own table and the outcome is not a normalised database.
Now, it is silly to suppose that objects do not subsume other objects: an account has multiple invoices that only make sense within the context of that account. So invoice objects make no sense unless they are couple to both account objects and the person or customer objects that the accounts belongs to. Invoice objects also require a collection of invoice lines and we would never keep the invoice header in the same table as the invoice lines.
So, don't worry about trying to restrict your classes to one table, though do use Martin Fowler's points about using views and stored procedures to manage the interactions.
