Cascadia College MWC Tutor Reservation System

Cascadia College MWC Tutor
Reservation System
Software Requirements Specification
Iteration 3
06.06.16
Source for Image: http://www.cascadia.edu/
FujaMC
Cyrus Sarkosh
Fuli Lan
Jacob Parkinson
Michael Nissenson

MWC TUtor Reservation System
Table of Contents
S e c t i o n P a g e
Table of Contents 2
Project Proposal 6
Problem 6
Solution 6
User Description 6
Team Setup and Logistics 6
Work Distribution 7
Schedule 7
Scope and Schedule Revisions 7
Design 8
Requirements 8
Entity-Relationship Diagram 9
Relational Model 11
Normalization 12
Triggers 13
Stored Procedures 17
Database Usability Rules 19
General Rules for Inserting, Updating, and Deleting 19
Testing Methodology 21
Design Specification Document Page 2

Sample Test Data 21
Sample Test Cases 23
SQL Query Statements (More Examples) 27
Results 28
What we Accomplished 28
Mistakes Made 28
Plans for the Future 28
Change Log
R e v i s i o n D a t e W h a t W h y
Version 0.1
(Iteration 0)
13 April
2016
Created Initial Proposal
Formed Team and set Bylaws and
Schedules
Explain project idea
and set rules for
teams and meetings.
Version 0.2 25 April 2016 Initial Version of Specifications Added Create initial set of
specifications based on
meeting with client.
Version 0.3 2 May 2016 Revised Specifications Updated specifications
based on meeting with
the client.
Version 0.3.1 2 May 2016 Added Initial ER diagram Created initial ER
diagram based on
updated specifications.
Version 0.4 4 May 2016 Added Problem / Solution statement to
proposal
Added Schema
Updated ER Model
Provide insight into why
application is being
developed.
ER Model modified to
be simpler after creating
schema.
Version 0.5 8 May 2016 Updated ER Model ER Model modified
based on group
discussion to better

reflect requirements.
Version 0.5.1 8 May 2016 Added Description of ER Model Provide context for
diagram.
Version 1.0
(Iteration 1)
11 May 2016 Final Revision before Submission Design ER diagram
and Relational
Schema.
Version 1.1 18 May 2016 Added Triggers section Provide Context for the
Numerous Triggers and
their Intended Purpose
Version 1.1.1 18 May 2016 Updated ER Diagram Text To Reflect
how Tables are Actually Used
Keep Documentation
Current
Version 1.2 20 May 2016 Added Test Methodology Highlight Some Test
Cases with Code
Version 1.3 21 May 2016 Added Scope and Schedule Revision
Section
Add Rational Behind
Modification to Scope
Version 1.4 21 May 2016 Added Stored Procedure Section Provide Context for
Stored Procedures
Version 1.5 22 May 2016 Added Schedule Section Provide Estimate of
Schedule for Project
Version 1.6 23 May 2016 Added Database Usability Rules Section Provide instructions on
how to use and interact
with our database.
Version 1.7 24 May 2016 Added Test Data Section under Testing
Methodology Section
Describe How Test
Data was Generated
Version 2.0
(Iteration 2)
25 May 2016 Final Revision Before Submission
Version 2.1 04 June 2016 Update Testing Methodology Update Documentation
to be Current with DB
Version 2.2 04 June 2016 Update Trigger Section Update Documentation
Version 2.2.1 05 June 2016 Updated Stored Procedure Section Update Documentation

Version 2.3 05 June 2016 Added Project Results Section Clearly Lay out Results
of Project
Version 2.4 05 June 2016 Added Normalization Assessment
Section
Report on
Normalization of our DB
Version 2.5 05 June 2016 Added Sample SQL Query Statements Show Sample Queries
To Retrieve Information
Version 3.0
(Iteration 3)
06 June
2016
Final Revision Before Submission

Project Proposal
FujaMC seeks to create a one-on-one tutor scheduling application for Cascadia College’s Math
and Writing Center. Currently, students must speak with an office assistant (either through
email, phone, or in person) to schedule an appointment. FujaMC seeks to automate the process
to make the entire experience quicker and easier through a web based scheduling application.
Problem
Cascadia College’s Math and Writing Center (CCMWC) burdens Cascadia College’s (CC)
students when attempting to schedule one-on-one tutoring reservations. Students must either
email back and forth with an office assistant to have them check when a tutor is available, or go
to the CCMWC in person and see if/when tutors are available. The current process wastes a
large amount of time for both the office assistant and student when checking the availability of a
tutor; this can discourage students from using the service and is a significant time sink for office
assistants.
Solution
The Cascadia College Math and Writing Center Reservation System (CCMWCRS) is a web
application that provides students who want to know the availability of one-on-one tutors with an
easy-to-use GUI for searching and booking one-on-one tutoring times.
User Description
The application focuses on three types of users
1. Students (also refereed to as tutees) will be able to access tutor’s availability times and
reserve one-on-one appointments with tutors.
2. Tutors will be able to have their availability set for the week and confirm or deny a
one-on-one appointment request from a student.
3. Office staff will be able to view the availability of tutors, set CCMWC’s operating hours,
set the tutor’s availability of the week, and confirm or deny a one-on-one appointment
request from a student to a tutor.
Team Setup and Logistics
FujaMC consists of the following four members: Cyrus Sarkosh, Fuli Lan, Jacob Parkinson, and
Michael Nissenson.

Work Distribution
So far, our has work has been almost exclusively collaborative as we’re still primarily designing
how our database is to function and how we want the front end of the application to interact with
the backend. Once we move farther along in the project, we will start to delegate tasks out to
specific individuals.
Schedule
Below is a rough outline of when we have expect to have certain features complete.
D e l i v e r a b l e M i l e s t o n e S t a t u s
Initial Requirements
Gathering
Iteration 0 (4/13) Done, but still communicating with client
for clarifications and updates.
ER Diagram Creation Iteration 0 (4/13) Done
DB Schema Creation Iteration 0 (4/13) Done
Initial DB Creation Iteration 1 (05/09 ) Done
Console Application Design Meeting On
5/18/2016
Done
Test Data Iteration 2 (05/25) Done
Trigger Creation Iteration 2 (05/25) Done
Stored Procedures Iteration 3 (06/06) Done
Console Application
Implementation
Iteration 3 (06/06) Done
Test Cases Iteration 3 (06/06) Done
Web Application Late Summer In Progress
Scope and Schedule Revisions
The primary schedule revision is that we’re focusing on delivering a console application by the
project deadline instead of a web application. Our group is still commited to delivering a web
application, but we lack the required ASP.NET experience to put together a web application with

the level of quality that our group wants by the deadline. As a result, we will be aiming for late
summer as a realistic timeframe to complete the web app.
Design
Requirements
Requirements are broken down by the Writing Center and Math Center. Although both share
users, they have very different requirements for how appointments are scheduled. The writing
center’s requirements are more straightforward as tutors have set hours and are always
available during those hours. The math center requires making a confirmation with both the
office assistant and tutor before confirming the appointment, as the tutor may not be available
during their scheduled times. They also have slightly different time requirements.
All requirements have been discussed with and approved by CCMWC’s office administrator.
F1.0 Tutee (Student) Requirements For Writing Center
F1.1) A tutee can view and make an appointment with the system without making an account.
F1.2) A tutee will be able to view all available tutoring slots for a given day.
F1.3) A tutee cannot view the details of another individual’s appointments.
F1.3.1) A tutee can view that an appointment was made in that time slot, if it is taken by
someone else.
F1.4) A tutee can only book an appointment within a set time window.
F1.4.1) A tutee cannot book an appointment that is more than 3 weeks away from the current
date.
F1.4.2) A tutee cannot book an appointment within the next 12 “business day” hours from the
current time.
F1.5) To book an appointment, a tutee must enter their Name, Instructor, Course #, E-mail,
phone number, and enter in why they want to schedule an appointment in a description box.
F1.6) A tutee can book appointments in 45 minute time slots.
F1.7) A tutee will be tracked by their e-mail.
F1.8) If a tutee has missed 2 or more appointments, and the tutee attempts to make another
appointment, the office assistant’s e-mail account will be sent an alert letting them know that the
tutee is attempting to make another appointment and block the user from making that
appointment.
F1.9) If a tutee has had more than 10 appointments in one quarter, and the tutee attempts to
make another appointment, the office assistant’s e-mail account will be sent an alert letting them
know that the tutee is attempting to make another appointment, and the user will be blocked
from letting them make that appointment.

F1.10) If a tutee attempts to make more than 1 appointment per day, block the user from
making the appointment and e-mail the office assistant an alert.
F2.0 Office staff / Tutor Requirements for Writing Center
2.1) An office staff can view, modify, and delete appointments.
2.2) An office staff will receive an e-mail (mwc@cascadia.edu) when a new appointment is
made.
2.3) A tutor can view their own appointments.
2.4) If a tutee does not show up to an appointment, a tutor or office assistant can mark the tutee
as a no show.
2.5) An administrator or office staff can set days as being “closed” and no appointments can be
made on this days.
2.5.1) A tutee will see “closed” dates as being completely blocked out.
2.5.2) An administrator or office staff must be able to select repeating dates and times where
the MWC is “closed.”
2.6) The office staff will be able to view outstanding requests and approve or deny them.
F3.0 Math Center Specific Requirements
3.1) When a tutee makes a math center appointment, it must be confirmed by both the office
assistant AND tutor being scheduled before it becomes “official” and the time is blocked out on
the scheduling site.
3.1.1) As a tutor or office administrator, approving or rejecting an appointment is done by being
logging in and clicking approve / deny.
3.1.2) A tutor and office assistant must be notified by e-mail when an appointment is made, so
they know to accept or reject the appointment.
3.2) A tutee needs to sort by subject a tutor can tutor in (calc 2, chemistry, physics, etc).
3.2.1) An administrator or office assistant must be able to create new subjects that can be
tutored.
3.2.2) An administrator or office assistant must be able to associate tutors with subjects that
they can teach.
3.3) A tutee cannot book an appointment that is less than 48 “business day” hours away.
Entity-Relationship Diagram
The ER diagram below consists of the following entities:
1. Tutor lists the name and e-mail of each tutor.
a. Specialty holds all tutor’s “specialties,” which are the subjects a tutor can teach.
Each entry is a unique combination of a tutor and a specialty. A single tutor is
likely to have multiple entries on this table.

i. Valid Specialty consists of all valid specialties as defined by the office
staff. It serves as a way to store constraints for what would be a valid
class that a tutor can tutor, avoiding possible overlap.
b. Availability holds a tutor’s valid working hours. It contains an entry for each day
a tutor is working; a script is used to generate a range of dates to insert. It
handles when a tutor has multiple shifts in a day by also using the start time of
their shift as a part of the primary key.
i. Operating Hours provides a table to validate tutor availability. If a tutor’s
availability falls outside operating hours of the center, it will reject the
time. This provides easy management for the office staff to update any
changes to the normal opening and closing times on any day of the week.
ii. Special Event or Holiday (SEH) provides a way to create exceptions to
the scheduling system in place as described in 1.b and 1.b.i above. It
provides an easy way for the office staff to insert any non-routine changes
to the opening and closing hours.
2. Tutee lists the name, e-mail, phone number, and the number of appointments missed.
This table represents the student who is to be tutored (i.e tutee).
3. Appointments Made keeps track of appointments that have been made. It uses the
tutor, tutee, time, and date as a unique key. It also keeps track of if the request has been
approved or not with the is_outstanding attribute.
Design Diagram 1: Student Tutor ERD

Relational Model
Design Diagram 2: Student Tutor Relational Schema

Normalization
All of our tables are normalized to 3NF. We designed our tables from the start to have no
multivalued attributes, so they were already flat and in 1NF. All our attributes are fully
dependent on their primary key and no attribute is dependent.
● Tutor Table
Email → Fname
Email → Lname
The tutor table is in third normal form. All the tutor attributes are fully dependent on Email. And
there are not transient dependencies.
● Tutee Table
Tutee_email → Fname
Tutee_email → Lname
Tutee_email → Phone
Tutee_email → Appointment_missed
The tutee table is in the third normal form. All the tutee attributes are all depended on
Tutee_email. And there are not transient dependencies.
● Appointments_Made Table
(Appointment_date, Appointment_time) → Tutor_email
(Appointment_date, Appointment_time) → Tutee_email
(Appointment_date, Appointment_time) → isOutstandingOffice
(Appointment_date, Appointment_time) → isOutstandingTutor
(Appointment_date, Appointment_time) → Class
The Appointment _Made table is in the third normal form. All the tutee attributes are all
depended on Appointment_date and Appointment_time. And there are not transient
dependencies.
● Operating_Hours Table
OH_date → Open_time
OH_date → Close_time
The Operating_Hours table is in the third normal form. All the tutee attributes are all depended
on OH_date. And there are not transient dependencies.
● Holiday_Special_Event Table
HSE_date → HSE_open_hours
HSE_date → HSE_close_hours
HSE_date → isOpen

The Holiday_Special_Event table is in the third normal form. All the tutee attributes are all
depended on HSE_date. And there are not transient dependencies.
● Tutor_Avaliablity Table
(Tutor_email, TA_date, shift_start_time) → shift_end_time
The Tutor_Avaliablity table is in the third normal form. All the tutee attributes are all depended
on Tutor_email, TA_date and shift_start_time. And there are not transient dependencies.
● Tutor_Speciality Table
TS_email → TS_class_speciality
The Tutor_Speciality table is in the third normal form. All the tutee attributes are all depended
on TS_email. And there are not transient dependencies.
● Valid Speciality Table
Course_id → Name
The Valid Speciality table is in the third normal form. All the tutee attributes are all depended on
Course_id. And there are not transient dependencies.
Triggers
The program itself relies on numerous triggers to prevent conflicting updates on different tables.
The overarching idea is that office staff maintain the OPERATING_HOURS and
HOLIDAY_SPECIAL_EVENT tables; those two tables validate TUTOR_AVAILABILITY, which
define when a tutor is on the clock to take appointments. Lastly, APPOINTMENTS are only
inserted if the tutor does not already have a conflicting entry in the APPOINTMENTS table and if
the appointment falls inside their working hours defined in TUTOR_AVAILABILITY.
It is worth noting that a cursor is used to iterate in most of these triggers because it allows for
cleaner (to read) triggers and allows error messages to print with less effort via variables stored
when the cursor fetches the data. While it’s true that cursors are typically slower, our data sets
are small enough (and will remain small enough) that any performance penalty should not be
noticeable.
T1.1) InsertIntoHSE
The InsertIntoHSE trigger runs when an entry is inserted into the HOLIDAY_SPECIAL_EVENT
table. It is intended to remove entries in the TUTOR_AVAILABILITY table that conflict with the
holiday being inserted. The trigger will also print out a message of any tutor hours removed.
HOLIDAY_SPECIAL_EVENT can also set modified hours, at which point the trigger will check if
a tutor’s existing hours conflict with the modified hours.

The trigger works by iterating through TUTOR_AVAILABILITY (using a cursor) and finding all
availability that matches the date being inserted into HOLIDAY_SPECIAL_EVENT. If the hours
being set for the holiday conflict with TUTOR_AVAILABILITY, it will remove that entry from the
TUTOR_AVAILABILITY table and print a message of exactly which row was removed with all
relevant information. It is worth noting that if the @is_Open bit is set to false (meaning the MWC
is completely closed on that day), all entries corresponding to that day in TUTOR_AVAILABILTY
are considered conflicting and are removed.
Code Snippet T1.1 shows the two primary checks used to see if hours are conflicting or not
when inserting into HOLIDAY_SPECIAL_EVENT. The first if statement checks if the start time
being inserted into HSE is after the existing tutor’s shift, if so it removes the entry. The second if
statement checks if the end time being inserted into HSE is before the existing tutor’s starting
shift time, if so it removes that entry.
Code Snippet T1.1
1
2
3
4
5
6
7
8
9
10
IF @newStart > @tutor_start_shift --If new starting time > existing starting tutor time
BEGIN
print 'Error Code [...]'
DELETE FROM TUTOR_AVAILABILITY where current of @Cursor
END
ELSE IF @newEnd < @tutor_end_shift --@tutor_end_shift is existing tutor end time
BEGIN
print 'Error Code [...]'
DELETE FROM TUTOR_AVAILABILITY where current of @Cursor
END
T1.2) UpdateIntoHSE Trigger
UpdateIntoHSE is quite similar to InsertIntoHSE, but with some modifications made to make it
work with updating instead of Inserting.
The UpdateIntoHSE trigger runs when an entry is updated in the HOLIDAY_SPECIAL_EVENT
table. It is intended to remove entries in the TUTOR_AVAILABILITY table that conflict with the
holiday being updated. This is so if a holiday is updated with different hours, the tutor will not
appear to have any availability during that time if the time periods conflict. The trigger will also
print out a message of any tutor availability that has been removed.
The trigger works by iterating through TUTOR_AVAILABILITY (using a cursor) and finding all
availability that matches the date being updated in HOLIDAY_SPECIAL_EVENT. If the hours
being set for the holiday conflict with TUTOR_AVAILABILITY, it will remove that entry from the
TUTOR_AVAILABILITY table and print a message of exactly which row was removed with all
relevant information. It is worth noting that if the @is_Open bit is set to false on the holiday

being inserted, all entries corresponding to that day in TUTOR_AVAILABILTY are considered
conflicting and are thus removed.
T2.1) InsertIntoOP Trigger
The InsertIntoOP Trigger runs when an entry is inserted into the OPERATING_HOURS. It is
intended to remove entries from TUTOR_AVAILABILITY if they do not match the hours defined
in the new OPERATING_HOURS entry.
The trigger works by iterating through TUTOR_AVAILABILITY (using a cursor) and finds all
entries that match the date being inserted. If the hours associated a TUTOR_AVAILABILITY
conflicts with the hours being inserted into the OPERATING_HOURS table, we delete the
associated TUTOR_AVAILABILITY entry.
NOTE: Normally, an appointment cannot be inserted until there is a matching date in the
OPERATING_HOURS table (checked via the TrigAddAppt trigger (T3.1)), so this trigger should
theoretically almost never delete an entry in TUTOR_AVAILABILITY. It is here in case a couple
of edge cases occur. UpdateOPEntry (T2.2) is much more likely to cause deletions of entries
from TUTOR_AVAILABILITY.
T2.2) UpdateOPEntry Trigger
UpdateOPEntry is quite similar to InsertIntoOP, except written to work with Updating instead of
Inserting.
The UpdateOPEntry Trigger runs when an entry is updated in the OPERATING_HOURS table.
It is intended to remove entries from TUTOR_AVAILABILITY that conflict with the hours that are
updated.
The Trigger works by iterating through TUTOR_AVAILABILITY (using a cursor) and finds all
entries that match the date being updated. If they match, it removes the associated entry from
TUTOR_AVAILABILITY.
T3.1) TrigAddApptTrigger
The TrigAddApptTrigger runs when an entry is inserted into the APPOINTMENTS table. It is
intended to verify that an appointment being inserted is valid by checking that first the
appointment does not conflict with another appointment already made in the APPOINTMENTS
table and second That the appointment is made for a valid time based on entries in the
TUTOR_AVAILABILITY table.

This is an interesting trigger as APPOINTMENTS only stores the start time of an appointment,
not the end time of appointments. As a result, the trigger needs to check if if the appointment
being inserted falls between the start time and the derived end time of an already existing
appointment. This is done with two sets of checks. The first set checks if the new appointment’s
start time falls after the existing start time and before the existing end time. The second set
checks if the new appointment’s end time falls before the existing end time and then if the new
appointment’s end time falls before the existing appointments start time. If either set of checks
ends up as true, there’s a conflict, and we rollback the insertion.
After checking for existing appointment conflicts, the trigger then verifies the start and end time
of the new appointment exists in the specified tutor’s working schedule, and will reject the
insertion if it is not.
Code Snippet T3.1 shows the checks that the trigger performs when checking if there is a
conflicting appointment. The most interesting part of this is that TSQL does not have a trigger
that can check before an insertion takes place. Instead, when a trigger is called on insert, it will
actually insert the row first, then perform the trigger. This means our trigger had to be designed
so that we ignore the row that was just inserted when looking for conflicting appointments.
Code Snippet T3.1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
-- TSQL triggers on INSERT insert the row first, then perform the trigger, so the first
-- check we do is to make sure we’re not comparing the row we just inserted to itself
-- as that will return a false positive for a conflicting appointment.
IF (@SchedTime = @APP_Existing_Start) -- Check if row is the one just inserted
BEGIN
FETCH NEXT FROM [...] --Fetch next row; snipping code to save space
CONTINUE --Skip to next iteration of while loop
END
IF (@SchedTime >= @APP_Existing_Start) --If inserted start time >= existing appt start
BEGIN
IF (@SchedTime < @APP_Existing_End) --And if inserted start time < existing end
BEGIN
PRINT ‘Error Message with details of conflict [...]’
ROLLBACK -- Revert table to before last insert
RETURN -- No need to check further, exit trigger.
END
END
IF (@SchedTimeEnd <= @APP_Existing_End) --If inserted end time <= existing appt end
BEGIN
IF (@SchedTimeEnd > @APP_Existing_Start) --If inserted end time > existing start
BEGIN
PRINT ‘Error Message with details of conflict [...]’
ROLLBACK -- Revert table to before last insert
RETURN -- No need to check further, exit trigger.
END
END

T4.1) appointCheckMaxPerWeek Trigger
The purpose of this trigger is to verify that a tutee cannot make more than 1 appointment per
week, which is based on a requirement given to us by the Math and Writing Center staff. It is
triggered on insert of a new appointment into the APPOINTMENTS table.
It primarily uses a single IF EXISTS (SELECT …) statement found in Code Snippet T4.1 to
determine if there is a conflicting appointment. If the select statement returns something, that
means an appointment for that tutee already exists within a week in either direction, either
before or after. As a result, if an appointment exists in that time frame, do a ROLLBACK, throw
an assert, and print out an error message.
Code Snippet T4.1
1
2
3
4
5
6
7
8
9
10
11
12
--All variables (Preceded by @) are from the appointment being inserted
IF EXISTS (select * FROM APPOINTMENTS A
WHERE (A.APP_Tutee_email = @SchedTuteeEmail AND --Get matching appointments for tutee
( (A.app_date <= DATEADD(dd, 6, @SchedDate)
AND A.app_date >= @SchedDate) --Is appointment within a week AFTER existing appt?
OR (A.app_date <= @SchedDate --Is appointment within a week BEFORE existing appt?
AND A.app_date >= DATEADD(dd, -6, @SchedDate)))
AND ( (@TimeOfAPPT != A.APP_Time)
OR (@SchedDate != A.app_date)
OR (@TutorEmail != A.Tutor_email ))
) ) -- The final AND checks that we aren't pulling the appointment that was just
-- inserted (as TSQ triggers on inserts always happen AFTER an insert)
Stored Procedures
P1.1) insertOHForDateRange
The insertOHForDateRange allows for easy insertion of operating hours for a supplied range of
dates. The stored procedure can be invoked via Code Snippet P1.1.0. If the day passed in does
not match the day of the week specified, it will automatically advance to the next Monday after
the date. For example, if someone passes in Monday and 2016-06-05 (a Sunday), it will
automatically advance to the next monday, 2016-06-06, and start inserting there.
Code Snippet P1.1.0
1
2
3
4
--To insert operating hours from 14:00 - 15:00 for JUST Mondays between 05-14 to 05-28
EXEC insertOHForDateRange Monday, '2017-05-14', '2017-05-28', '14:00:00', '15:00:00';
--To insert operating hours from 09:00 to 15:00 for JUST Fridays between 04-14 to 05-28
EXEC insertOHForDateRange Friday, '2017-04-14', '2017-05-28', '09:00:00', '15:00:00';
It works by first checking if the day passed in matches the starting date passed in. If it doesn’t, it
advances the date forward to match it. It then iterates through each of the specified day, and

inserts on those days with the designated hours. Code Snippet P1.1.1 shows the main loop that
handles the inserts for the Stored Procedure. @Date_start is the only variable that is advanced,
and when @Date_start ends up later than @Date_end, we stop the loop.
Code Snippet P1.1.1
1
2
3
4
5
6
7
WHILE (@Date_start <= @Date_end) --This loop continues to insert until date_start
BEGIN --passes date_end.
INSERT INTO OPERATING_HOURS(OH_Day_of_week, Open_time, Close_time)
VALUES (@Date_start, @Time_start, @Time_end);
SET @Date_start = DATEADD(wk, 1, @Date_start); --Advance the start date one week
END
P1.2) insertAvailabilityForTutor
insertAvailabilityForTutor is quite similar to insertOHForDateRange above, with one small
change. When invoking the function, a tutor’s e-mail must be passed in as well. Code Snippet
P.1.2 shows how to invoke the stored procedure. Note the only difference is just the e-mail
being added.
Code Snippet P1.2
1
2
3
4
--To insert into Tutor_availability for Sarah@fakeemail.com on just Mondays between the
--dates 2017-05-14 and 2017-05-28 for the hours of 14:00 to 15:00
EXEC insertAvailabilityForTutor Monday, '2017-05-14', '2017-05-28', '14:00:00',
'15:00:00', 'Sarah@fakeemail.com';
The only major difference is that when an insert is done, it inserts the Tutor’s e-mail as well.
Everything else about the stored procedure is identical to insertOHForDateRange.
P2.1) pullTimeSlots
pullTimeSlots accepts just one parameter, a date value. While it is easy to select all
appointments that are booked for a given day, it is actually quite tricky to retrieve information on
what time slots are available to be booked. pullTimeSlots is intended to return all open time
slots that a student could book an appointment during. pullTimeSlots will change in subsequent
revisions and should be broken up into smaller stored procedures once we understand how best
to store and pass information to a front end. Code Snippet P2.1 shows how to invoke the script.
Code Snippet P2.1
1
2
--Show all open tutoring slots for 2016-05-16.
EXEC pullTimeSlots @Date_to_check = '2016-05-16'
For now, however, pullTimeSlots currently does two things:
1. It prints out all available and taken time slots to the console.

2. Stores all available time slots for a given day in a temporary table that can then be easily
accessed by other programs.
Database Usability Rules
Our database is set up with a very strict
set of rules enforced by triggers. This
section is to provide clarity on how to
interact with the database in a meaningful
way. The end user is never intended to
interact directly with the SQL database,
instead we will always provide a proxy
(through a console or web application) for
them to interact with it, thus eliminating
any confusion on their end.
The crux behind the complexity can be
seen in UR Diagram 1.1.
APPOINTMENTS rely on
TUTOR_AVAILABILITY to validate when
an appointment can or cannot made.
Similarly, TUTOR_AVAILABILITY relies
on OPERATING_HOURS and HOLIDAY_SPECIAL_EVENT to determine when a tutor’s shift
can be inserted. When a change is made in OPERATING_HOURS or
HOLIDAY_SPECIAL_EVENT, that change propagates down to TUTOR_AVAILABILITY, when
then propagates down to APPOINTMENTS. For example, if a holiday (such as Memorial Day) is
added to the HOLIDAY_SPECIAL_EVENT table, all tutor shifts on that same day will be
removed, and all appointments that were booked are also removed. All items that were removed
are output to the console to keep track of changes.
General Rules for Inserting, Updating, and Deleting
VALID_SPECIALTY, SPECIALTY, TUTOR, and TUTEE are all fairly flexible in the types of
updates they will accept. As long as domain and foreign key constraints are met, no further
triggers are used to validate them.
When INSERTING or UPDATING an entry in the APPOINTMENTS, TUTOR_AVAILABILITY,
OPERATING_HOURS, or HOLIDAY_SPECIAL_EVENT tables, all inserts and updates should
be done one at a time, or the corresponding trigger will throw an assertion. This will not be an
issue in the final application, as the end user will be using a console or web application to
interact with the database.

The primary rationale behind this design decision is that these updates (Inserting, Updating, or
Deleting) can cause a large cascade deletion or modification of many different items. For
outputting each item that is deleted or modified, we found it significantly easier to restrict
modification of tables to one row at a time.
See UR Diagram 2.1 for an example showing how to insert multiple items without causing an
insertion error.
UR Diagram 2.1: How to Insert
1
2
3
4
5
6
7
8
9
10
-- This is the proper way to insert multiple entries:
VALUES ('2000-03-30', '09:00:00', '19:00:00');
VALUES ('2000-03-31', '09:00:00', '19:00:00');
--This is an incorrect way to insert multiple entries and will result in an assert:
VALUES ('2000-03-30', '09:00:00', '19:00:00'),
('2000-03-31', '09:00:00', '19:00:00');
Specific Rules for Inserting and Updating an entry in the APPOINTMENT table
To INSERT or UPDATE an entry into the APPOINTMENTS (APPT) table, there must be an
entry in TUTOR_AVAILABILITY (TA) with a matching date. Further, the row being inserted into
APPT must start and end during that same TA entry’s start and end times. For example, if the
appointment being inserted is from 11:00 to 11:45, there must be a matching TA entry that
starts on or before 11:00 and ends on or after 11:45. Finally, there cannot already be another
entry in the APPT table that conflicts with the row being inserted. An appointment is considered
conflicting if it’s on the same day, with the same tutor, and their start or end times overlap. An
example of start and ending time’s overlapping is if one tutee has an existing appointment from
12:00 to 12:45, and another tutee tries to book an appointment from 12:30 to 13:15; there’s 15
minutes of overlap, so the trigger will reject the insertion.
Specific Rules for Inserting or Updating an entry in the TUTOR_AVAILABILITY table
To INSERT or UPDATE an entry into the TUTOR_AVAILABILITY (TA) table, there must be an
entry in OPERATING_HOURS(OH) or HOLIDAY_SPECIAL_EVENT (HSE) that matches the
date being inserted. Further, the hours set in the TA row being inserted, must correspond to
hours that already exist in HSE or OH for the corresponding date, or else the insertion will be
rejected.

Testing Methodology
Sample Test Data
The file SQLQuery1.sql contains insertion data for populating the database. It is listed directly
after the Triggers and before our test cases.
Nearly all of our sample data is based on actual data from Cascadia’s Math and Writing Center
for the Spring 2016 quarter. Some data has been modified to remove contact information
(primarily emails). Each section of the Sample Test Data part of the documen texplores how
each type of sample data was generated based on the table they’re from.
TUTOR Table Sample Data
Entries for the TUTOR table were generated based on the list of tutors provided by the
Cascadia College’s Math and Writing center coordinator. All e-mails have been modified to be in
the generic form of Fname@fakeemail.com. This list includes both tutors that take part in 1-on-1
tutoring and those that are just general drop-in center tutors. This was done to include as many
different types of tutors as possible.
VALID_SPECIALTY Table Sample Data
Entries for the VALID_SPECIALTY comes from the list of all courses that are tutored at the
Math and Writing Center, not just those that are part of the 1-on-1 tutoring center. Note that the
writing center does not have specialties as the math center does, and consequently it only
contains a “Writing” entry that best corresponds to ENGL&101. Data was pulled from both the
list found in the MWC and online on Cascadia’s course catalog.
TUTOR_SPECIALTY Table Sample Data
Entries for the TUTOR_SPECIALTY database comes from a list of tutors and their matching
specialties of what they can tutor. It includes all tutors and their associated specialties that do
1-on-1 tutoring and some tutors that just do drop in center tutoring to get some tutors that will be
active and some that will not.
OPERATING_HOURS Table Sample Data
The OPERATING_HOURS for the quarter are based on the actual operating hours for the Math
and Writing Center for the Spring 2016 quarter. A C# script was used to generate the entries,
and the full script to generate the entries can be found in the PrintSetOfDatesForInsert.cs file.
The script can also generate any range of dates that is inserted for either the
OPERATING_HOURS table or TUTOR_AVAILABILITY table.

The script is fairly straightforward. The user specifies an start and end time, then a starting and
end date, then the days of the week it applies to (so if we only want to generate operating_hours
for specific date with the matching times). This allows someone to quickly generate entries for
an entire quarter. Code Snippet Data 1 was included to show how the code formats the inserts
used for our test data. The snippet iterates through all generated dates that are stored in a list,
and prints out each entry based on the type of data the user wants.
Code Snippet Data 1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
foreach(var date in dates) //Output dates in proper insert format
{
string sqlFormattedDate = date.ToString("yyyy-MM-dd");
if (input == 1) //If User Picked Operating Hours
{
Console.WriteLine("INSERT INTO OPERATING_HOURS(OH_Day_of_week, Open_time,
Close_time)");
Console.WriteLine("VALUES '{0}', '{1}', '{2}');",sqlFormattedDate,
StartTime, EndTime);
}
if (input == 2) //If User Picked Tutor Availability
{
Console.WriteLine("INSERT INTO TUTOR_AVAILABILITY (Shift_start,
Shift_end, Day_of_week, Tutor)");
Console.Write("VALUES "('{1}', '{2}', '{0}', '{3}');",sqlFormattedDate,
StartTime, EndTime, email);
}
}
TUTOR_AVAILABILITY Table Sample Data
TUTOR_AVAILABILITY was made from actual shift schedules for 1-on-1 tutors from the Math
and Writing Center for Spring 2016. A C# script was used to generate the entries, and the full
script to generate the entries can be found in the PrintSetOfDatesForInsert.cs file. The script
can also generate any range of dates that is inserted for either the OPERATING_HOURS table
or TUTOR_AVAILABILITY table.
Code Snippet Data 1 shows how the actual inserts are formatted for the user. For additional
details on how the script works, see the OPERATING_HOURS Table Sample Data section. The
only major difference how the script works when generating data for TUTOR_AVAILABILITY is
that a tutor is specified for TUTOR_AVAILABILITY, and the actual inserts it generates are
different to match the type of insert being created.

TUTEE Table Sample Data
The TUTEE table contains the only data that is not based on actual data from the Math and
Writing Center. This is because we felt it would be inappropriate to use actual tutee names. The
names are either one of our team member’s names, random words chained together, or a
combination of our names and a number. Each type of data (IE phone numbers, names, and so
on) do have the correct type of data to be inserted, but the values themselves are made up.
APPOINTMENTS Table Sample Data
The APPOINTMENTS table contains real data, except for the tutee’s names. Everything else
contains a data from actual time slots that can exist for an appointment.
When creating data, we tried to create a couple different scenarios. We tried to fill up a tutor’s
schedule completely with appointments for one day. We also tried to insert appointments for
another tutor on that same data. We also added appointments for different days with the same
and different tutors.
HOLIDAY_SPECIAL_EVENT Table Sample Data
The HOLIDAY_SPECIAL_EVENT table contains the fewest number of sample inserts because
we tried to keep it as realistic as possible. The only days we were aware of this quarter when
the center would be closed would be for Memorial Day on May the 30th and for a
non-instructional day on April 29th. We added a made up holiday on May the 26th with reduced
hours to make sure we had proper coverage of all days that were closed.
One interesting thing to note is that because we are inserting three entries into
HOLIDAY_SPECIAL_EVENT, our sample data will actually go back and delete
TUTOR_AVAILABILITY that conflicts with these dates when we perform inserts for all our
sample data.
Sample Test Cases
See the bottom of the file CreateDBandTriggers.sql to see additional test cases we’ve
developed..
Most of our test cases revolve around testing the triggers used to maintain consistency in our
DB. If one of those has a major issue, then our entire DB breaks down and may generate data
that doesn’t make sense.

TC1.1) TUTOR_AVAILABILITY Trigger Test Cases
For testing our TUTOR_AVAILABILITY (the table that holds a tutor’s shifts) triggers, we test that
we can only insert an entry into TUTOR_AVAILIBILITY if it falls within the bounds of
OPERATING_HOURS (OH) or HOLIDAY_SPECIAL_EVENT (HSE). For example, code snippet
TC1.1 tests if we can insert a tutor’s shift if there is no corresponding entry in OH or HSE.
Code Snippet TC1.1
1
2
3
4
5
6
7
-- **test case: inserting tutor_availability that does not have a corresponding entry
-- in operating_hours or holiday_special_event
-- should fail (with exception thrown as it rolls back) as no hours are set for
-- 2016-01-01
insert into tutor_availability (shift_start, shift_end, day_of_week, tutor)
values ('06:00:00', '10:00:00', '2016-01-01', 'fujamctest@fakeemail.com');
GO
Similarly, Code Snippet TC1.2 tests if we can insert a tutor’s shift when OH exist for the day, but
the tutor’s hours fall outside of it. We have similar tests that check if just the start time does not
match, or if the end time does not match.
Code Snippet TC1.2
1
2
3
4
5
6
7
-- **test case: inserting tutor_availability when operating_hours exists, but there is
-- a start and end time mismatch.
-- should fail (with exception thrown as it rolls back) as some operating hours are set
--for 2016-5-20, but the end hours we're attempting to set are after the center closes.
GO
Code Snippet TC1.3 tests when a tutor’s shift matches an entry in OH, but do not match hours
in a corresponding HSE entry. This means that we’re trying to insert tutor hours into a day that
someone has specified as a closed holiday, meaning it will block all entries that someone tries
to make.
Code Snippet TC1.2
1
2
3
4
5
6
7
8
9
10
-- **test case: inserting tutor_availability when operating_hours exists, and start and
-- end times are within boundaries, but HSE has it closed
-- should fail (with exception thrown as it rolls back) as even though hours are valid
-- in OPERATING_HOURS, HSE has reduced hours.
-- This test checks if we're allowed to insert availability when availability hours
-- match OH, but do not match EITHER start or end times of HSE
-- It should fail because HSE hours take precedence of OH hours.
INSERT INTO OPERATING_HOURS(OH_Day_of_week, Open_time, Close_time) --Inserting new
-- operating_hours for the test.
VALUES ('2006-06-06', '09:00:00', '19:00:00');

11
12
13
14
15
16
17
18
19
20
21
INSERT INTO HOLIDAY_SPECIAL_EVENT (hse_date, isopen, hse_open_time, hse_close_time)
values ('2006-06-06', 1, '10:00:00', '11:00:00' ); --HSE from 10:00 to 11:00.
GO
DELETE FROM HOLIDAY_SPECIAL_EVENT --Cleaning up HSE and OS inserts by deleting inserts
WHERE HSE_Date = '2006-06-06';
GO
DELETE FROM OPERATING_HOURS
WHERE OH_Day_of_week = '2006-06-06';
GO
TC2.1) APPOINTMENT Test Cases
The appointment table is at the heart of our database, and thus requires fairly extensive testing.
The section will highlight some of the test cases used.
One of the requirements provided to us is that a tutee can only make one appointment per
week. Code Snippet TC2.1 show a couple ways this was tested. First a valid appointment is
inserted in a new time slot that was not occupied by the sample data that was created. Then,
check a day before and a day after the insert to make sure it fails.
Code Snippet TC2.1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
--Insert should succeed as no conflicts.
insert into appointments (app_date, app_time, isoutstandingoffice, isoutstandingtutor,
tutor_email, class, app_tutee_email)
values ('2016-04-19', '12:00:00', 0, 0, 'Daphne@fakeemail.com', 'Help with an essay on
something or other.', 'cyrustutee@fakeemail.com');
GO
--Try inserting a day BEFORE an appt (should fail w/ printed message)
GO
--Try inserting a day AFTER an appt (should fail w/ printed message)
Beyond the code snippet, we also checked exactly a week before and after the appointment
(should succeed), six days before and after the appointment (should fail), try to insert the same

day (should fail), and various combinations of different tutors, same tutee, and different lengths
of time.
Another (more basic case) is trying to make an appointment when a tutor is not working. Code
Snippet T2.2 shows some of the test cases we used. It shows two fairly basic examples of tests
we did ran. The first shows when we try to insert an appointment on a day when a tutor has no
hours for a day. The second test shows when we try to insert an appointment on a day when a
tutor does have hours, but the insert is outside those hours.
Code Snippet TC2.2
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
-- **test case: inserting an appointment when a tutor does not have hours on a day
-- should fail (with exception thrown w/ ROLL BACK) as daphne does not have any hours
-- on 2016-05-25
values ('2016-05-25', '09:00:00', 0, 0, 'daphne@fakeemail.com', 'This shouldn''t work,
English edition', 'jaketutee@fakeemail.com');
GO
-- **test case: inserting an appointment when a tutor does have hours on a day, but
-- appointment time is completely outside range. It should fail (with exception thrown
-- as it rolls back). John's hours on 2016-05-25 do not start until 10:00:00 and end at
-- 13:00:00 so both start and end of appointment are outside John's working hours.
values ('2016-05-25', '09:00:00', 0, 0, 'John@fakeemail.com', 'This shouldn''t work,
English edition', 'jaketutee@fakeemail.com');
GO
After those test cases, we also test for if the tutor’s hours fall within the start of the appointment,
but the appointment would run on past them, at which point we reject the appointment. We also
try the opposite case where if the appointment would start before a tutor’s starting hours, but
end during their working hours, we reject the appointment. There are many more test cases that
were used at the bottom of the SQLQuery1.sql text.

SQL Query Statements (More Examples)
Each table is used in at least one of the queries below.
S Q L S t a t e m e n t s P u r p o s e
SELECT T.Fname as 'TUTEE NAME'
FROM APPOINTMENTS A, TUTEE T
WHERE T.Tutee_email = A.APP_Tutee_email AND
A.APP_Date = GETDATE();
List all tutee names that have
appointments for the current Date.
This will help office staff to
determine which tutees have
appointments for a given day.
SELECT DISTINCT(TA.Tutor)
FROM TUTOR_AVAILABILITY TA
WHERE TA.Day_of_week > '2016-05-22' AND
TA.Day_of_week < '2016-05-28'
List all tutor’s who work between
the dates 2016-05-22 and
2016-05-28. This could let office
staff know which tutor’s are
available for a given date range.
SELECT *
FROM VALID_SPECIALTY VS
WHERE VS.Course_id LIKE '%MATH%'
List all valid specialties for math
courses. Could let office staff
know which math courses exist in
case they need to add more.
SELECT *
FROM TUTOR_SPECIALTY TS
WHERE TS.TS_email = 'Lily@fakeemail.com'
List all courses that Lily can tutor.
Good for filtering results to
potential tutees or office staff.
SELECT DISTINCT(TS.TS_course_specialty) AS
'Tutorable Courses'
FROM TUTOR_SPECIALTY TS, TUTOR_AVAILABILITY TA
WHERE TA.Day_of_week = GETDATE() AND
TS.TS_email = TA.Tutor
List all courses that can be tutored
today. Useful for tutors to know so
they can find out what’s available.
SELECT H.HSE_Date as 'Date',
H.Description as 'Event'
FROM HOLIDAY_SPECIAL_EVENT H
List all special holiday events and
their description. Useful to find out
when the center will be closed.
SELECT *
FROM OPERATING_HOURS OH
WHERE oh.OH_Day_of_week >= GETDATE() AND
oh.OH_Day_of_week <= DATEADD(wk,1,GETDATE())
List operating hours for the next
week. Useful to know when the
center would be open.

Results
What we Accomplished
We created a fully functional database for our tutoring center application. It verifies that all data
being inserted or updated makes logical sense through a complex web of triggers and stored
procedures. It also stores information in such a way that it can be easily retrieved.
We also created a console application that has all the basic functionality required of the
application, without the ease of use features that would be required of the web application.
As for personal skills gained, we learned a huge amount about database design. We learned a
lot about creating triggers and how they interact. We also learned a lot about TSQL and how to
use it to create triggers and stored procedures.
Mistakes Made
The largest mistake we made was vastly underestimating the amount of time it would take to
learn to create a web application with ASP.NET. It ended up being significantly more difficult
than we expected. As a result we ran out of time and transitioned to a console application
instead.
Beyond that, we also learned that we needed to design how our triggers were to interact
upfront. Because of how complex our triggers were, we ended up wasting some time creating
some unnecessary triggers because we didn’t plan far enough ahead.
Plans for the Future
We plan to continue meet over the summer to try and complete the web application that the
math and writing center would be able to use. We are still maintaining contact with the office
staff at the math and writing center and providing updates for them as to our progress.

Cascadia College MWC Tutor Reservation System

Recommended

Recommended

More Related Content

Similar to Cascadia College MWC Tutor Reservation System

Similar to Cascadia College MWC Tutor Reservation System (20)

Recently uploaded

Recently uploaded (20)

Cascadia College MWC Tutor Reservation System