List view
## Deliverables As a group, submit a 3-5 paragraph reflection on your progress. Possible questions to answer might be: • How well did the group communicate? • Was the work divided evenly among team members? • Did everyone complete their assigned work on time? • Were you able to implement the vision that you had for your project earlier in the term? What adjustments were made to the project scope? Individually, submit a 3-5 paragraph reflection. Possible questions to answer might be: • Did you complete the tasks you were assigned? Were those tasks completed on time? • Did you provide support to your teammates? How and when? • Did you ask for help from your teammates when necessary? • The next time you work on a team, is there anything you will do differently? ## Rubric Reflection #3 will be graded on: • Quality of group reflection • Quality of individual reflection
Overdue by 4 month(s)•Due by December 5, 2025•0/3 issues closed## Deliverables For this last part, you will write a report (3-5 pages) detailing your progress through the project. If you took good notes during development, this should be relatively quick and easy to put together. The report should at least include the following information, but consider adding anything else that you find interesting or that might help someone reading your report understand what you did. • A cover page with the names and userids of all group members • A 1 paragraph introduction to your project • A summary of the data: Why was it chosen? What does it consist of (attributes)? How large is it (number of records)? Was any cleaning/pre-processing required? Don’t forget to acknowledge your sources! Include an ER diagram. • A discussion of the data model: o Why was it broken down into those tables? o Did you face any difficult choices when designing the model (e.g., tricky participation/cardinality ratio decisions)? o Did the data model cleanly fit into the relational database? o Do you regret any decisions you made in your model? Did you change the model you initially designed when it came time to implement? What changes, and why? o Could the data be modelled in a different way, why or why not? Given the work completed, would you choose this model? • A discussion of the database (flavour of SQL, etc.) • A description of your interface, including a brief description of platform/language used, and screenshots of the interface in action. • A list of interesting queries you can run using the interface. Explain what the queries return, you don’t have to include the SQL code. Explain why these queries would be interesting to an analyst. • Concluding remarks: o Does this dataset require a relational database? Would other database systems be a better choice in modelling this data? Why or why not? Would the “interesting queries” you wrote be easier or harder to re-create if you were using an alternative database? Would other database systems allow for different or more interesting queries? o Would this database be a good teaching tool for COMP 3380? Are there good problems for future students to solve in this database? o A final summary paragraph • Appendix: A summary of each group member’s contributions to the project (from Stage 1 to the end). For the final project report, submit one pdf file (one submission per group). ## Rubric The final project submission will be graded on: • Summary of data • Discussion of data model • Summary of the database • Summary of the interface • List of interesting queries • Other interesting discussions or summaries • Writing quality
Overdue by 4 month(s)•Due by December 5, 2025•0/1 issues closed## Deliverables For the final project submission, submit one .zip file (one submission per group) containing: • Everything required to create database tables, relationships, populate the tables, and the program you wrote for interacting with your database. • Include a readme.md file with instructions on how to create and populate the database and run your program. • For authentication, provide the userid and password for your fully-populated database. Normally this will be the userid for one of your group members. ## Rubric The final project submission will be graded on: • Code to populate database • Quality of instructions on how to run your project • Project robustness against invalid input & SQL injection • Quality of code to interact with the database (interface) • Queries – correctness • Queries – complexity and interestingness • Interface functionality & ease-of use
Overdue by 4 month(s)•Due by December 5, 2025## Description ### Database Creation and Population You will implement the database you designed in Stage 3. Incorporate feedback received in your final implementation. This may require revisiting your design before moving on. You will be given some instructions in UM Learn on how to connect to a department-hosted server. Your database must be located on the server (i.e. on uranium.cs.umanitoba.ca, not local). Once your database is created, you will populate it with your data. You must use a code-based method to add records and submit that code as part of your final submission. ### Implementing an Interface You will create a front-end interface which allows a person (say, an analyst) to access and use your database. It can be as simple (e.g., command-line interface) or as feature-rich (e.g., complete GUI) as you want. However, a command-line interface is recommended, as your focus in this project should be on the database and querying. If your group wants to implement a GUI, you must first obtain approval from your instructor. Your application should be implemented using Java, Python or as a website (i.e. index.html that is submitted as part of your project, not hosted somewhere). Your application must run on aviary without any installs. When building your application, you must consider the following requirements: • When using the interface, the database should be relatively secure according to what was discussed in class (e.g., can’t allow freely entering SQL commands to prevent SQL injection). • Your interface should support an analyst trying to answer interesting questions they might have of the data, which are not easily answerable. You might consider taking some time to come up with interesting questions an analyst might have and allow your interface to execute the relevant queries. You should support at least one query which includes GROUP BY, one that includes ORDER BY, and one that includes an aggregate function. Note that your interface does not necessarily have to make these components explicit, at a minimum, it should simply allow someone to run those queries. Some tips: o GROUP BY and aggregate functions are hard for humans to do on the fly, so are an easy way to create interesting queries. o Queries should be relevant and potentially useful to an analyst. Complex queries that are hundreds of words long, nested four layers deep could be interesting for you to implement, but might be too convoluted for an analyst to ever reasonably run. o Don’t worry too much about optimizing your queries, as long as they run in a reasonable amount of time. However, consider informing the user with a message of some kind if a query is currently being executed (so that they don’t think your interface has crashed). o Consider letting the user enter parameters for your queries. • Content from all tables should be accessible one way or another. This might mean you have some simple queries in addition to the queries above. • Results from queries should be easy for an analyst to parse. Results should have a logical ordering, be neatly organized into columns, be labelled with column headings, and have a limited number of tuples (or use paging) to prevent results from scrolling out of view. • The interface should provide a way to delete all data from your database, and a way to repopulate it. ## Deliverables Each group will prepare a 5-8 minute demonstration, in which you will give a brief summary of your project, and show that your project runs on aviary, connects to a populated database on uranium, executes queries, and presents results to the user. You will show that your project is robust against invalid input and SQL injection. Your group can choose to offer the demonstration in one of two ways: 1) Schedule a time with your instructor to show them your project. These will be scheduled on Week 13 of the course (December 1-December 5). If you use this option, you need to schedule the time with your instructor by November 28. The advantage of this method is that if your instructor has questions or doubts, you will have the opportunity to respond. 2) If you do not schedule a time with your instructor, you should prepare a video recording of the demonstration. The quality of the video is not graded, feel free to record with tools you already have access to, e.g., your smartphone, as long as what is on the screen can clearly be seen. ## Rubric The project demonstration will be graded on: • Quality of project summary • Demonstration that interface runs on aviary and connects to uranium • Interface functionality & ease-of-use • Handling of invalid input
Overdue by 4 month(s)•Due by November 28, 2025•0/2 issues closed## Deliverables As a group, submit a 3-5 paragraph reflection on your progress. Possible questions to answer might be: • How well is the group communicating? How can communication be improved? • Has the work been divided evenly among team members? • Is everyone completing their assigned work on time? If not, what adjustments will be made moving forward to make the project successful? Individually, submit a 3-5 paragraph reflection. Possible questions to answer might be: • Did you complete the tasks you were assigned? Were those tasks completed on time? • Will you change anything in the way you approach the project moving forward? • Have you asked for help from your teammates when necessary? • Is there anything you can do to support your teammates moving forward? As a group, submit an updated timeline. At this point, you should make a more detailed plan for the remainder of the project. ## Rubric Reflection #2 will be graded on: • Quality of group reflection • Quality of individual reflection • Quality of updated timeline
Overdue by 5 month(s)•Due by November 21, 2025•0/3 issues closed## Description Look ahead to Part C, to see the expectations for your final project. Note that your code must be either Java or Python, and that your interface must run on aviary without any installs. A command-line interface is recommended as a starting point (the focus of this class is, after all, on the database) but a GUI/webpage can be implemented with instructor approval. ## Deliverables For Stage 6, submit one pdf (one submission per group) containing: • Your ER diagram, to remind the instructors/graders of your project • A 2-4 paragraph description of your interface. Include a brief description of how it will look, but also include your plan for implementation (language, command-line interface vs. GUI, etc.). • 2-4 diagrams showing how your interface will look. Of these diagrams, 1 diagram should show your help menu/instructions for use and 1-2 diagrams should show how query results will be presented to the user. ## Rubric Stage 6 will be graded on: • Interface design/ease of use • Feasibility of implementation
Overdue by 5 month(s)•Due by November 21, 2025•0/6 issues closed## Deliverables For Stage 5, submit one pdf (one submission per group) containing: • Your ER diagram, to remind the instructors/graders of your project • A list of queries you intend to implement. For each query, give a 1 sentence (English) explanation of the query, the SQL/code, and explain why the results would be interesting to an analyst. If a query contains variables, explain what the user will be inputting. ## Rubric Stage 5 will be graded on: • Complexity of queries (at least one query which includes GROUP BY, one that includes ORDER BY, and one that includes an aggregate function) • Interestingness of queries (would an analyst care about these results?) • Coverage of data (is all data accessible?)
Overdue by 5 month(s)•Due by November 7, 2025•2/10 issues closed## Description Look ahead to Stage 5 to see what is required in your query design submission. The stage 4 submission is an opportunity for early feedback on your design. Feedback will focus on whether the complexity and interestingness of queries is reasonable for later steps of the project (not on the correctness of SQL/code). ## Deliverables For Stage 4, submit one pdf (one submission per group) containing: • Your ER diagram, to remind the instructors/graders of your project • A list of queries you intend to implement. For each query, give a 1 sentence (English) explanation of the query. Optionally, also include SQL and/or code that may or may not contain variables. If the latter, make sure that the variables are easily understood and/or you include comments explaining them.
Overdue by 6 month(s)•Due by October 24, 2025•4/6 issues closed## Deliverables As a group, submit a 3-5 paragraph reflection on your progress. Possible questions to answer might be: • How well is the group communicating? How can communication be improved? • Has the work been divided evenly among team members? • Is everyone completing their assigned work on time? If not, what adjustments will be made moving forward to make the project successful? Individually, submit a 3-5 paragraph reflection. Possible questions to answer might be: • Did you complete the tasks you were assigned? Were those tasks completed on time? • Will you change anything in the way you approach the project moving forward? • Have you asked for help from your teammates when necessary? • Is there anything you can do to support your teammates moving forward? As a group, submit an updated timeline. At this point, you may want to make a more detailed plan for stages 4-6, and a tentative plan for the rest of the project. ## Rubric Reflection #1 will be graded on: • Quality of group reflection • Quality of individual reflection • Quality of updated timeline
Overdue by 6 month(s)•Due by October 10, 2025•3/3 issues closed## Description You will draw an ER model (including EER components, if appropriate) which represents the database you have chosen to create. The model must include participation and cardinality constraints, as well as a brief justification for each constraint. Justifications should explain the “why” of constraints, not merely putting them into words (e.g., “not every Song is written by an Artist” = bad, “some Songs are written by unknown Artists, and so aren’t in the Wrote table” = better). You will then convert your ER model to a relational model and normalize it as much as possible using the rules and standards discussed in class and in the lectures. ## Deliverables For Stage 3, submit one pdf (one submission per group) containing: • A 3-5 paragraph summary of your data (e.g., a short description of what it is, how much data), updated from Stage 1 as appropriate. • An ER/EER diagram, including participation and cardinality constraints, with text justifying your design choices. • The final relational model (post-merge and post-normalization). Include a description of the steps you took to translate your ER model to your final relational model (i.e. steps for merging and normalizing). ## Rubric Stage 3 will be graded on: • Quality of dataset (e.g., size, connectedness) • Ratio of support tables to main tables • ER/EER diagram • Justification of participation and cardinality constraints • Translating and merging ER/EER diagram to relational model • Normalization
Overdue by 6 month(s)•Due by October 10, 2025•8/8 issues closed