Note that for questions marked with “explain your answer”, bad explanations should be penalized.
2.1
Author -> Publisher

2.2
User, Book is the only candidate key.  Publisher depends on Author, violating BCNF and 3NF. Also, Author depends on Book, which is a 2NF violation. Thus, we are in 1NF.

2.3
The only candidate key is User, Book, Author. All three FDs violate BCNF. Going from the top, User, Book closure is User, Book, RevText, Rating. Replace Review with 
Review(User, Book, RevText, Rating) 
InterMediateTable(User, Book, Author, Publisher)
Now, the last FD still violates BNCF, since the candidate key for InterMediateTable is still User, Book, Author. So we replace IntermediateTable with 
Book(Book, Publisher)
NewTable(User, Book, Author)
I also think that {Book, Author} without User is acceptable for NewTable, since this is a natural assumption that the same book does not have different authors per user.

3.1
SELECT displayName, p1.id as PostID, score as highestScore FROM User u1 INNER JOIN Post p1 ON u1.id = p1.user WHERE karma > (SELECT AVG(karma) FROM user u2)  AND 
score >= ALL(SELECT score FROM Post p2 WHERE p2.user = p1.user);

3.2
CREATE VIEW selfReplies AS (SELECT c1.refPost, c1.user, c1.id FROM Comment c1 INNER JOIN Comment c2  ON c1.replyTo = c2.id  AND c1.user = c2.user);

SELECT title, sr.user, COUNT(sr.id) FROM Post p INNER JOIN selfReplies sr ON p.id = sr.refPost GROUP BY p.id, title, sr.user;

3.3
Here the precise format of the output is not specified, so what columns are printed is less of a concern.
WITH recursive Replies(id, replyTo) AS (SELECT id, replyTo  FROM Comment WHERE id = 3415    UNION SELECT c.id, c.replyTo  FROM Replies r, Comment c  WHERE r.id = c.replyTo)

SELECT * FROM replies r INNER JOIN Comment c on r.id = c.id;

4.1
Standard approach is to write an expression for violations of the constraint, then say that this should be the empty set. The problem is equivalent to demanding that {User, Book} is unique, i.e. a key. My idea would be a self-join (using a rename), followed by projecting to User, Book the selection with RevText1 != RevText2 or similar.
4.2
Again, a self-join problem. Theta-join on Book and Rating, with != on User.
5.1
If a transaction T1 has read data modified by some transaction T2, and T2 aborts, then T1 must also be aborted (it has used data that no longer exist). The aborting of T1 can in turn cause aborts for transactions that read data modified by T1, and so on, hence the cascading part.
5.2
I screwed up on this problem. The schedule is serial, and hence of course serializable.  Still, for those that do not catch it, here is the precedence: 
Precedence: 1 before 2, since 1 writes B before 2 reads it. Likewise, 2 before 3 on C. Hence also 1 before 3 (also, 1 reads A before 3 writes it). The graph is acyclic, and so the schedule is conflict serializable. 
5.3
We can assume that read locks do not matter, hence everyone gets to read. So:
2 asks and gets a lock on A
2 commits //Or later!
3 asks and gets a lock on B
1 asks for a lock on B and has to wait
3 asks for a lock on A, has to wait
2 commits //doesn't matter where
3 has to abort due to FUW
1 can now get lock on B, since 3 aborted and released the locks
1 commits

6.1
No, neither can commit nor abort. They both do not know what decision the TC made, and have to wait. If the wait becomes too long, they can time out and elect a new TC.
6.2
TC sent commit messages to both nodes, A received it and committed. The network lost the message to B, then TC and A crash or become unreachable.

7.1
A join B has F = T(A) * T(B) / min(V(A, ab), V(B, ab)) estimated tuples.
(A join B) join(v<w) C has G =  F * T(C) / 3 estimated tuples (selectivity for interval)
Finally, the whole thing has G / V(R, x) tuples, where R is the number of distinct values in (A join B) join(v<w) C. For extra credit, someone might say something about the estimate of the number of distinct values for x here.
7.2
The second, since the selection is inside the join, thus cutting the join size by approximately T(A)/V(A, x).