Reformat the Database.

[conzty01]

Database Tables should contain:
italics indicates primary key

1. hall
   1. id
   2. name
   3. g_cal <- This would contain the information we would need to connect to the Google Calendar for a respective hall.
2. ra
   1. id
   2. first_name
   3. last_name
   4. hall_id
   5. date_started <- This field essentially keeps track of whether an RA is a new hire so that they can be paired with returning RAs in the beginning of the year.
   6. points
3. conflicts
   1. id
   2. ra_id
   3. day_id
4. schedule
   1. id
   2. hall_id
   3. ra_id
   4. day_id
   5. created <- This contains the date that the entry was created.
5. day
   1. id
   2. month_id
   3. date
6. month
   1. id
   2. name
   3. year

[conzty01]

Here is a rough diagram of the structure of the database above.

[conzty01]

Also, if we would like to make a login system through the Luther G-Suite or locally through Flask, we might also want to have a database table that outline the level of authorization an RA, AHD, HD, or SuperUser might have. This way, we can say that RAs can have a specific view of of the application and can enter conflicts, but they would not be able to see the AHD interface nor would they be able to run the scheduling algorithm. Additionally, AHDs would also be able to enter conflicts, but could run the scheduler as well as make some other changes. HDs could add or remove RAs/AHDs but would not be able to enter conflicts and SuperUsers would have complete access to everything.

To supplement this, a field could be added to the ra table that could denote the level of authorization that a given user might have. Also, we might consider renaming the table to users if this we go this route.