Given that each team has decided to use a web-based interface, it seems to me that a succinct way to describe the intended functionality would be to center this description around a set of provisional web-page designs, with just enough English text to allow a reader to make sense of the roles the different pages will play in the bigger picture and what actions they will cause to happen. These initial web-page designs can be crude hand-drawn sketches, though if you already have some HTML written, you could use a browser printout instead.
With regard to the database structure, I believe each team has chosen to focus on an E-R (or UML) design approach, as opposed to normalizing a universal table. Therefore, a sensible way to present your design would be to center it around a collection of E-R (or UML) diagrams, with enough English text to help a reader make sense of them and tie them to the system's functionality, and with a list of additional integrity constraints you have already identified. Finally, you should show what progress you have made towards translating the E-R design into actual relational tables, for example by giving the SQL "create table" statements.
If your team has a working system, it would be appropriate to include a demonstration in your oral report, and I will provide a projection system with which to do it. However, you will want to do more than just demonstrate: you will want to explain the system's purpose and briefly sketch the design that allows you to meet that need.
If your team does not have a working system, you will still want to convey what the general purpose of the system is, what more specific functionality it was planned to provide, and how your design attempted to support that functionality. To the extent time permits, you might also try to indicate how your team's actual achievements compared with your plans.
The written report should include again all the material from Stage One, but updated to reflect design changes that happened in the second week.
It should also include information on the SQL statements that are used to actually access and update the data, whether those statements are executed in an ad hoc fashion (directly with psql) or by your PHP3 web-based interface.
The PHP3 interface itself is also a suitable topic for your report, though it should not dominate: this is a relational database course.
Finally, it is important to include a list of what still needs to be done: lower priority features you didn't implement, special cases you don't properly handle, bugs you never did track down and eliminate, nice enhancements that occur to you now that the basic functionality is in place, etc. Is the system usable in its current state? Is it adequately robust, secure, tested, user friendly? If not, explain what areas still need work.