Problem 1 seems to expect the transactions to know things that are not
in the database.
Answer: Yes; there is some funny business going on. But we're talking about what transactions can see, and you don't have to write the queries. Thus, you may assume, for example, that the total number of seats for a flight can be determined by knowing the aircraft and some side information about how many seats each aircraft has.
In the book it says that REPEATABLE READ is stronger
than READ COMMITTED, but this doesn't seem to be the case as
described in slides13.
Answer: Slides13 erred in not stressing this point, and they have been changed in the on-line version. That is, a transaction operating under repeatable-read not only must see on a later read all the tuples it saw on an earlier read (and these tuples must be unchanged, not updated!), but all the tuples it ever sees must be committed when it sees them.