Main idea of a view serializable schedule is that each read operation of a transaction should read the result of the same write operation in all schedules, thereby having the same "view" of the database.
This would mean that each (deterministic) write operation of each transaction should produce the same result in all schedules.
Example:
Consider below schedule S1:
T1 |
T2 |
T3 |
Read(A) |
|
|
|
Write(A) |
|
Write(A) |
|
|
|
|
Write(A) |
Note that T2 and T3 are performing blind writes, perhaps writing some garbage value or even nothing to the database. Also, the above schedule is not conflict serializable as there is a cylce between T1 and T2.
Now consider below schedule S2:
T1 |
T2 |
T3 |
Read(A) |
|
|
Write(A) |
|
|
|
Write(A) |
|
|
|
Write(A) |
Note that S1 and S2 maintain same "view" of DB, i.e the same value of A is read in T1 for both S1 and S2. T2 and T3 also are performing blind writes here, perhaps writing the same garbage value or nothing to the database. Both S1 and S2 leave the DB in the same state, and all writes result in the same state. Thus S1 and S2 are view serializable.
For a schedule that is not conflict serializable but is view serializable, there exists a conflict in the schedules but the "view" of the DB is maintained, like in the example as above. This is possible only with blind writes.