It doesn't really matter to you how it's encrypted in the database. Database encryption is "transparent", meaning that you don't see the encryption mechanisms when you access the data through an authorized connection. You don't get to see or specify which key is used for which table or row; that's all secured inside the engine.
So if you truly need each company's info to be encrypted its own unique key, you'll have to encrypt the data in your application before writing it to your database. That quickly gets you into complex key management issues.
Since you haven't mentioned "why" you would want this, I'm assuming it's to isolate queries so that only authorized users can view or edit the data for a particular company. It means you'll have to build a mechanism to hand out the proper keys to authenticated users, so that the salespeople can edit only their own accounts, view their region's accounts, etc. You'll have to securely store and retrieve those keys, and transmit them to the encryption service. You'll have to rotate those keys according to your company's key management policies. You'll need to have a way to edit key ownership so that when an employee leaves their accounts can be reassigned to other people. You may even need to build an audit reporting mechanism. It's a very complex task to build a usable key management system.
But all this seems like it could be avoided if you lay out your actual requirements. Are you really trying to restrict access to certain rows to certain users? Look at Oracle's existing Access Controls, which can already perform that level of control for you. You wouldn't need to use custom encryption at all if you can use their built-in functionality to restrict access.