Changes that have been made since initial publication, most recent first:
October 2, 2014
In this project, you will work in groups of 3–4 to design and prototype a database-driven web application for reviewing books and recording reading activity. GoodReads and LibraryThing are good examples of this kind of application in the wild.
Users need to be able to create accounts and to log in with a username and password.1
Users need to be able to view details about a book. These details should include:
The book details should also include summary statistics (average rating, number of users who have read it, etc.)
Users can write textual reviews of a book, and browse the reviews for a book.
Users can rate books with a 1—5-star rating.
Users can browse books by different aspects of the book:
and sort by various fields (title, publication date, average rating, number of readers).
Users can search for books by title.2
Users have named lists to which they can add books, and any book can be on more than one list for any given user. For example, user Alice might add Concepts of Database Systems to her lists ‘Textbooks’ and ‘Computing’. Users can browse the books on their lists and other users’ lists, and see what users have put a particular book on what lists. All lists are visible to all users.
Users can record that they have read a book, optionally recording that they finished it in a particular date (you could include an optional start date if you wish as well). Crucially, users must be able to create multiple reading log entries for a given book — they may really like a book!3
Each user has a profile page that displays some information about them:
Users can add new books to the system, and edit the details of existing books.
Users need to be able to follow other users, and see a news feed containing the new reviews, reads, etc. by the users they follow.
In addition to the above, you must design and provide at least one additional feature for users. Here are few ideas for potential features:
In Lecture 4, we discussed user views: different perspectives on the system that meet the needs of different kinds of users. Think of your project as having at least two user views:
Adding a new user view is also a good starting point for an ambitious extra feature. For example, you could add a Publisher view so publishers can see things about how widely their books are read.
Modeling books can be complicated. There are multiple printings, multiple editions, etc. A user reads some particular edition, but that edition may be equivalent to some other edition (e.g. an earlier printing, hardcover vs. softcover, etc.).
There are also more substantial different editions, such as new editions of textbooks or technical books. New editions may even add or remove authors.
You will need to decide how to model the relationships between different editions, printings, formats, etc. Your guiding principle should be making the system valuable for the user to record their reading and talk about books.
The following table summarizes the project deliverables; see below for more details on each deliverable.
| Deliverable | Grade Pct | Due |
|---|---|---|
| Initial Data Model | 5% | Oct. 9 |
| Peer Review | 10% | Oct. 10/11 |
| Revised Data Model | 25% | Oct. 20 |
| Development Midterm Report | 10% | Nov. 13 |
| Final Presentation | 20% | Dec. 4 |
| Final Code and Report | 30% | Dec. 6 |
All deadlines are at 6:30 PM.
By Oct. 9, you must submit a draft data model. This draft must consist of:
Diagram of your complete data model, using our crows’ feet notation (simplified E-R diagram)
Data types for each column
Primary keys for each column
3 example queries to retrieve data for display to the user. These queries should be non-trivial, involving multiple tables. At least one must have an aggregate function.
A brief description of your custom feature.
On Oct. 9, each group will give a short presentation to the class about their data model to get feedback.
By Oct. 11, you must submit a written version of your peer feedback. Send your feedback to each group using the TRACS e-mail tool by Oct. 10 at midnight, and submit a compiled document for grading consisting of:
Submit a revised data model by Oct. 20, consisting of the same materials you submitted in the Initial Data Model, updated and revised based on the feedback you received from your peers and me.
On Nov. 13, submit a midterm report on your development status. This report must include:
Updated data model diagram, if you have changed anything since the Revised Model.
A list of indexes that you are creating.
The SQL DDL (CREATE TABLE, etc.) statements to set up your database.
A list of the different pages that your application will have (e.g. book details, edit review, user profile). Each page needs:
A description of your custom feature
Submit your report as 2 files: a PDF containing the text and diagrams, and an SQL script file with the DDL.
On Dec. 4, each group will give a short presentation to the rest of the class demonstrating their application. This presentation should contain:
By Dec. 6, submit your final project. This should be a zip archive containing:
The final data model diagram.
Your source code, including all Python files, SQL scripts, HTML templates, and images (everything that I will need to run the project inside the Vagrant image)
A list of the different pages. For each page, provide:
This list should be a single PDF file.
Instructions to run it
On Dec. 6 (the same day as the final project is due), each group member must individual submit a short report (can be less than a page) assessing their own contribution and that of their group members. This report will not be directly graded, but may influence the grading of the group.
If your group has great dynamics and everyone pulls their weight, shows up for meetings, etc., this can even be a single sentence.