| 1. Completeness and submission requirements | 10 | Answers all 7 questions with substantive paragraph-length responses; submits final .db, schema-generation Python code, and Ship It population code | Missing minor detail, short answer to one question, or one required file is missing | Several questions unanswered or major files missing | Strong: all parts submitted. Weak: answers only 3 questions; no .db file |
| 2. Evolution from ER diagram to final schema | 15 | Clearly explains how the design changed from ER diagram to final schema, including specific changes to tables, entities, attributes, relationships, or keys | Describes some changes but explanation is vague or mostly chronological | Says the design changed but does not explain how or why | Strong: “We split StudentClub into Student, Club, and Membership because students can join many clubs.” Weak: “Our database became more organized.” |
| 3. What the database represents well | 15 | Identifies 2–3 real-world aspects the schema captured well and connects each to concrete schema choices | Gives examples of what the database stores but does not fully explain why the schema handles them well | Makes broad claims without specifics | Strong: “The schema handles many-to-many relationships between books and authors using a join table.” Weak: “It captures books pretty well.” |
| 4. Modeling difficulty and tradeoffs | 15 | Identifies something genuinely hard to model and explains the database-design tradeoff or compromise | Identifies a difficulty but frames it mostly as coding/debugging rather than modeling | Only says the project was hard | Strong: “User preferences were hard because one user can have many overlapping interests, so we had to choose between a separate Preferences table and storing preferences as text.” Weak: “SQLite was confusing.” |
| 5. Assumptions, constraints, and simplifications | 15 | Identifies meaningful assumptions about uniqueness, required values, categories, cardinality, or real-world simplification, and explains consequences | Names assumptions but does not explain how they affect representation | Gives generic assumptions unrelated to schema design | Strong: “We assumed each event has exactly one location, which means we cannot represent hybrid or multi-room events.” Weak: “We assumed the data would be correct.” |
| 6. Data generation, insertion, and debugging reflection | 10 | Describes what broke or almost broke, explains why using database concepts, and connects it to expectations or fixes | Describes an error but gives limited explanation of the underlying cause | Mentions vague bugs without detail | Strong: “Ship It generated duplicate names, but we had used name as the primary key, so inserts failed. We should use an artificial ID.” Weak: “The code broke but then we fixed it.” |
| 7. Revision plan and future improvement | 10 | Proposes a specific first schema revision and explains why it should be prioritized | Suggests a plausible improvement but does not justify priority or connect to a known limitation | Says only that the database should be improved | Strong: “I would add a foreign key from Enrollment.student_id to Student.id so enrollments cannot refer to nonexistent students.” Weak: “I would make it more organized.” |
| 8. SQLite-specific reflection | 10 | Identifies a SQLite-specific limitation or behavior and explains how it affected this project’s data model | Mentions SQLite limitations but connection to project is thin or partly inaccurate | Complains about SQLite without identifying a concrete storage/type issue | Strong: “SQLite does not enforce strict column types by default, so we had to be careful that prices were inserted as numbers rather than text.” Weak: “SQLite is weird.” |