1.  The first thing you need to do is modify the interface Scan to have the two additional methods.  You then need to add code for these methods to the Scan classes for each operator, namely TableScan, ProjectScan, SelectScan, and ProductScan.  The code is trivial for the first two of these classes.  In SelectScan, the code for previous is similar to that of next.  In ProductScan, the simple solution is to model the method afterLast after beforeFirst, and previous after next.

2.  Revising the code for SQLInterpreter was fairly easy.  All you had to do was change doQuery so that it called afterLast and previous instead of next.

3.  Consider first the rename operator.  The RenameScan class is similar to ProjectScan, in that all it does is forward most of its methods to the underlying scan.  The only methods that are interesting are getInt, getString, and hasField.  In each case, the method has to check the specified fieldname.  The old field name should not be accepted, the renamed field name should map to the old name, and the other fields should be handled normally.  The RenamePlan class takes its cost estimates directly from the underlying plan.

Now consider the union operator.  The UnionScan class is similar to ProductScan in that it takes two input scans.  The difference is that the scans are handled sequentially instead of simultaneously.  That is, there is the notion of a "current scan".  The current scan starts out as the first one; when that scan has no more records, then the second scan becomes current.  The method afterLast does just the opposite, making the second scan current, and moving to the first scan when the second scan completes.  The cost estimates in UnionPlan are just the sum of the estimates of the underlying plans.