COMP421_764 -  Database Systems - Project 3 - Application - Solved

The Assignment
Some of the solutions to the below questions have to be provided in a document project3.pdf whereas others would be independent files of their own (described next to each question).

1.    (0 Points) Include the relational model that you are using for this phase of the project - even if you have

 

not made any changes from project 1 and 2. Include this in the document project3.pdf under the section “Relational Model”. You need not include any restriction/assumption information along with this.

2.    (20 Points) write a java program VaccineApp.java - you can base this on the example JDBC program that is given in mycourses as part of the JDBC tutorial. This a simple console (command line) based program with a menu through which you can “loop”. User selects the menu option based on what they would like to do, program performs that action and goes back to displaying the menu.

Below is an example of what this menu would look like, but you are free to format/phrase it in sensible ways that do not deviate from the intent of the menu.

VaccineApp Main Menu

1.           Add a Person

2.           Assign a slot to a Person

3.           Enter Vaccination information

4.           Exit ApplicationPlease Enter Your Option:
Functionality Specs • Add a Person

This is the instance where a (new) person is registering with the system. When this option is selected, your application should allow the user to enter (type) the relevant information. If the user’s health insurance number is already associated with someone else, the application should stop adding the new person and instead respond with an appropriate message to the user. At this point the system should prompt the user whether they wish to update the existing Person information associated with that insurance number with the newly entered details. If the user chooses to do so, then the existing information is updated. Otherwise, no action is taken. • Assign a slot to Person

This is used when a Person has to be assigned a slot (whether it is their first dose or later doses). Prompt the user for any necessary input and update the slot allocation information in the database. The application should not allow the user to assign a slot to this Person, if the said Person has already taken the required number of shots for that particular brand of vaccine (if it is not their first shot). You can assume that a person is never vaccinated by two different brands. Do not assign a slot if that is already given to someone else or is in the “past” (for simplicity, you may interpret this as a slot from a day that is before “current date”, if you do not want to get into the time level granularity - but you are free to do that.)

•   Enter Vaccination information

This is where we “record” in the system that a certain Person was vaccinated. Again, you need to record appropriate information for this (i.e., the nurse, vial info, slot, etc. - complete details depends on your model). Stop the entry from being made if the vial is from a vaccine brand that is different from previously applied vaccine brand for that Person (if the Person had received a vaccine shot before).

•   Exit Application

The application terminates. Make sure it closes any active database connections, etc., before terminating. Design Details

•   When implementing the “details” of each functionality, you are free to follow a programming approach that intuitively works with the intent of each functionality in how the user is asked to enter any additional information. However, the application should not probe the user for any information that it can already compute from the data stored in the database. For example, the application should not ask the user to enter the number of previously applied doses for a Person or the brand of vaccine that was used. This can be easily retrieved from the stored data once you received a Person’s basic information from the user (such as the health insurance number).

•   You need not have to handle errors related to data formatting (i.e. user entered date where number was expected, etc.) or worry about a user deliberately trying to break your system. You can assume that once a user selects an option they will provide all the necessary information required for the application to act up on that option if the application prompts the user to do so.

•   In any instance where the system “refuses” to do a task (as in for example the insurance number is already assigned to someone else) it should give a proper message to the user. You need not produce any messages for successful execution of actions but is free to do so, it might help debugging your application easier. • Make sure the application loops back to the main menu once it is done taking care of an action request. No errors should result in the application crashing and terminating.

•   Please keep in mind that for a given option you might have to write data to multiple tables or read from multiple tables or may need a combination of reads and writes. You need to handle this in your application according to your model and schema implementation.

•   You are graded primarily by the functionality and not how “pretty” the application looks. Do not spent time on cosmetics before you get the functionality under control.

•   It is assumed that any additional information/data that you need to support the application (eg. vaccine batches, hospital info, nurses, etc.) are already present in the database. They need not be added/maintained through your java application. You can insert them separately (reuse the template scripts from project 2 to make it easy).

•   You are not obliged do any “checks” and “error handling” besides the ones required for the successful execution of the application flow that is given below.