Strategy Pattern for Oracle Database?
There are several issues that could be improved:


First of all, having concrete classes which are all tied to a specific database (in this case Oracle), is usually completely opposite of what a Data Layer's responsibility should be. Consider changing the classes' names as follows:


OracleConnection --> DbConnection
OracleCommand --> DbCommand
OracleParameter --> DbParameter.


To instantiate a new command, don't use a specific constructor, but rather use the DbConnection.CreateCommand() method (and, likewise, DbCommand.CreateParameter() to create its parameters). That means you only need to change the actual connection instance, if you decide to switch from Oracle to a different db provider one day.
Next, strategy pattern is usually used to abstract a functionality which several different algorithms can execute, while exposing a single (common) interface. Creating a different strategy for different table queries is not appropriate, because the calling code already knows which table it is querying (there are no additional strategical choices your code can do).
I am not sure if the NotImplementedExceptions are thrown deliberately, or you really haven't yet implemented those methods. If you are throwing to indicate that a certain implementation doesn't support that functionality, that is another alarm that these two implementations are not really different strategies for the same task.