Wines Elementary School

Event Volunteer and Proposal

Management System
 

Final Project Write-up

SI 572 Database Application Design Final Project

Tze-Hsiang Lin, Lei Shi, Weihua Wang, Peggy Wong

Introduction

Our Client Organization

Wines Elementary School is a local elementary school in Ann Arbor. The mission of the Wines
School community is to create for every student a joyful environment that stimulates lifelong
learning and inspires respect for individual differences. The main project proposal was made
by the Wines Elementary School PTO, a school organization where parents, teachers, and staff
provides services and activities that can enhance student education. Parents can volunteer to
help out while enjoying time interacting with kids, working with other parents and staff while
accomplishing things that truly makes a difference to the school education.

Our Client Needs

The main goal of our client is to move from paper to a paperless system to interact with
parents. Their foremost requirement is to enable parents’ access to an online system and sign-
up to volunteer in projects and events that they can help out. They would like to have an easy-
to-use straightforward interface that enables parents to quickly choose the events they want
to volunteer without needing to fill in contact information each time they sign-up. They also
would like the system to automatically pull information that are more relevant to their
children and select events according to different levels of participation. For example, the
default selection would only show events that are relevant to their own child for both in-class
and school-wide events. However, if the parent simply wants to help the school by
volunteering in classes other than their children’s class, we provide them with the option to
view all happening events with a simple click of the button. Finally, they also would like to
have a proposal submission system that gathers proposal information seamlessly and help
track all documents under different review statuses.
System Users

Target Users
The main target users of the Wines Elementary School Event Volunteer and Proposal
Management System are:

● Parents – Parents are the main resource for volunteers of events and projects. They
will be the main users of that interact with the system.
● Students – Students are the event attendants. Parents rely on student enrollment
presence to have an account created for event volunteering.
● Staff – The schools’ working staff that are not classroom teachers.
● Teachers – Classroom teachers from kindergarten to 5th grade.
● PTO (Parents-teachers Organization) – Executive PTO members are responsible for
site administration, event creation (not in current scope) and assigning event
coordinator and volunteers.

Target Population
● 50 School staff and teachers (Hand counted from the staff list on the Wines website as of
November 2010)
● 40*6 students (Student from kindergarten to 5th grade, estimating 40 students per grade
year)
● 40*6*2 parents (We assume at least to parent/guardian will have user information stored
in the system)

Above is our estimated population for Wines Elementary School. There would be about 500-
600 in each regular year. As time goes on, legacy records will increase gradually because of the
graduation of 5th grade students.
Accounts
The normal user accounts will be created based on student enrollment basis. Parents who
want to sign up to volunteer need to use their children’s student account to log in. After
parent log in using their children’s student account, they are asked to select their parent
identity. Then they are able to sign up to volunteer for events as the parent identity they
select.

Staff and teachers have their own accounts too. As this point, their accounts are merely used
to check the events and volunteers information.

In this system, the system administrator will be assigned a special ‘admin’ account with full
permission to manage the database system. This permission would include create account,
create user information, and create the relationship among ‘users’ and ‘event management’.

As mentioned above, parents will not be assigned accounts to log in the system. They need to
log in with their children’s student account. The reasons for this design decision are as follows:

1. Straightforward user relationship:

In user relationship, we determine the student as the main connection

between parents and teachers, which is how it actually works in real life. In our
system, if two or more students from the same family are enrolled, each
student will own an individual account. Here we assume that only parents who
have children studying in wines are interested in being a volunteer for events.
Once their children leave the school, we will move the graduated students
account into legacy pool. At the same time, parent information associated to
these graduated students will be inactivated and synchronized automatically.
Moreover, because parent information is connected to their child’s student
account, we can trace any parent information via student accounts even if
students have graduated already. This the main reason we decide to create
the account based on student enrollment basis.

2. The existence of parent information is based on student enrollment

The existence of students will be the main connection to other related

information like parent information. As guardian of the student, all parent
 information will be associated to a student account. Through this relationship,
the information related to different students will not interfere with each other.
For example, a tricky problem will happen while a family has more than one
children studying in Wines. These children are in different grades and might
have different events to attend. However, since they have the same parents, it
is sometimes confusing to deal with each student with the same parent
account. There are also cases when more than one guardian want to register
an account to participate in volunteering. Creating accounts upon student
enrollment can relieve the confusion of multiple accounts obtained within the
same family and the creation of redundant user accounts. This makes it easy to
more guardians to the database without having to manage complicated
relationships.

3. One account per student is sufficient and more manageable

For the use of this system, we suggest that there is no need to give both
student and parent accounts. Since parents are the people who take action to
sign-up for volunteers while students are the attendants of the event (we
assume that student attendance is mandatory and there is no need to sign-
up), we decided to assign just one account to get this thing done. However,
according to the two reasons mentioned above, it’s better to create accounts
based on student enrollment basis. Therefore we present the final design that,
parents use student account to log in and select their parent identity
when they interact with the system.

Example User Scenarios

User scenario#1: Parent signing up for event volunteer.

Kelly wants to volunteer in her 1st grade son – Mikey’s class year-end Christmas Party. Her son
told about the party and told her that their teacher would like some parents to volunteer and
help out to decorate the classroom or provide snacks and drinks. However, Mikey forgot the
exact date of the party and Kelly isn’t sure whether she would have time to help during the
afternoon of that day. To make sure, she goes to the website and logs in. She clicks on the
Wine Volunteers – Event Calendar tab and checks the month of December. She easily finds the
date because the system default only shows events that are directly related to her son. She
clicks into the event and reads the event description. She clicks on the “I want to volunteer for
‘2010 Xmas Party’” checkbox and clicks on the [Submit] button. Before closing the website, she
goes to her “My Account” profile page to check the upcoming events that she had signed up.

User scenario#2: Event coordinator checking newest updates of upcoming event.

Stacy is the IT manager of the Wine Elementary PTO and she is the main administrator of the
Wines Elementary School Volunteer and Proposal Registration System. She is also the main
event coordinator of the Annual Science Fair that will be happen next week. Since the day she
opened the volunteer sign-up, more parents than expected has registered to volunteer for the
event. Since she has to notify the volunteers a week before the happening event, she has to
decide which parents will be able to volunteer in the event today. She logs in to her account
and clicks on the Wine Volunteers – Event Calendar tab to check out the event that she
coordinates. She clicks on the Annual Science Fair Event and views the list of volunteers that
signed up.

Database Design

Database Schema (E-R Models)

Based on the system configuration and functionality we designed, we started to draft
the database schema from three major parts: user related, event related and proposal related.
The detailed descriptions of each part are listed as follows:

(1) User related tables:

Instead of putting all types of users’ information into one “user” table, we separated
the information that is used to represent system roles and relationship from the basic contact
information. Under this design pattern, the central “user” table is only used to store the
contact information (including name, email and phone), while other information will be
recorded in different tables for different purpose. For example, the information about user
type (such as teachers, staff, students, parents and system administrators) is stored in
“user_type” table; the information about the relationship of parents and students is kept in
“parent_student” table.

The table “account” is used to store all the account information (account id and
password) for those users who are authorized to log into the system. The reason of separating
account information from “user” table is that based on our design, parents will be assigned to
their children’s identities within the system, which means they don’t have their own accounts
to login the system for viewing and volunteering. Instead, they can use their children’s
accounts.

The attribute “user id” from “user” table is used as foreign key in other tables to make
them connected to “user” table, ensuring data consistency.

(2) Event related tables

In the database, every event will be stored in “event” table as one record, with the
information about title, description, event type (special event or regular event), current status
(pending, ongoing or past), assigned grade (if is a grade event), the coordinator (could be
teacher, staff or parent), and the proposal id (foreign key from “proposal” table, non-zero if is
an event created from a proposal).

The table “event_volunteer” is used to store the information about registration for
volunteering, with each record representing one application from parents. The stored
information includes event id (foreign key from “event” table), applicant’s id (linked to his user
id in “user” tables), volunteer time period, application status (approved or unapproved), and
application notes.
(3) Proposal related tables

In our system design, we included the process of proposal application. In this process,
students or their parent and submit their proposal of events through the system, instead of
writing on the paper. To implementing this submission process, two major tables are
designed: “proposal” table and “content” table.

The “proposal” table is used to store the general information of proposal, including title,
applicant’s id (foreign key from “user” table), type (from students or parents), current status
(approved or unapproved), and submission date. The detailed contents of each proposal are
stored in the “content” table, with one record representing one question within the proposal.
All these contents of the proposal can be retrieved based on their question id and formed a
complete paper-based proposal.

After getting into the implementing phase, according to the development

requirements, we refined the database schema. Several modifications are listed below:

(1) Use the surrogate key to replace all the combined primary keys, making them
easier to be integrated by the framework we chose.

(2) Add a new table “admin” to store information about who has the admin permission
of the system, separated from “user_type” table.

(3) Add a new table “account_token” to support the function of automatic login.

(4) Add the missing attributes “start_date” and “end_date” in “event” table.

(5) Add the attribute “accountname” in “account” table to support the function of
using customized username to login the system.

(6) Cancel the foreign key relationship between “proposal” table and “event” table to
solve the problem of storing one event that is not from certain proposal.
Database Tables

User Related
ACCOUNT
Field Type Null Default Extra

AccountID int(11) No None auto_increment

AccountNumber varchar(11) No None

AccountName varchar(45) Yes NULL

Password varchar(45) No None

AssignedID int(11) No None

IsValid enum('Yes','No') No Yes

ACCOUNT_TOKEN
Field Type Null Default Extra

AccountTokenID int(11) No None auto_increment

AccountID int(11) No None

AccountAgent varchar(45) No None

Token varchar(45) No None

Created int(10) No None

Expires int(10) No None

ADMIN
Field Type Null Default Extra

UserID int(11) No None

IsValid enum('Yes','No') No Yes

PARENT_STUDENT
Field Type Null Default Extra

ParentStudentID int(11) No None auto_increment

ParentID int(11) No None

StudentID int(11) No None

IsValid enum('Yes','No') No Yes

STUDENT_GRADE
Field Type Null Default Extra

StudentGradeID int(11) No None auto_increment

StudentID int(11) No None

Grade smallint(6) No 0

IsValid enum('Yes','No') No Yes

TEACHER_GRADE
Field Type Null Default Extra

TeacherGradeID int(11) No None auto_increment

TeacherID int(11) No None

Grade smallint(6) No 0

IsValid enum('Yes','No') No Yes

USER
Field Type Null Default Extra

UserID int(11) No None auto_increment

FirstName varchar(45) No None

LastName varchar(45) No None

Email varchar(45) Yes NULL

Phone varchar(45) Yes NULL

USER_TYPE
Field Type Null Default Extra

UserTypeID int(11) No None auto_increment

UserID int(11) No None

Type enum('Staff','Teacher','Par No None

ent','Student')

IsValid enum('Yes','No') No Yes

Event Related
EVENT_VOLUNTEER

Field Type Null Default Extra

EventVolunteerI int(11) No None auto_increment

D

EventID int(11) No None

StartDate date No None

EndDate date No None

VolunteerID int(11) No 0

Status enum('Selected','Unselected') No Unselected

Note text Yes NULL

IsValid enum('Yes','No') Yes Yes

EVENT

Field Type Null Default Extra

EventID int(11) No None auto_increment

CoordinatorID int(11) No 0

StartDate date No None

EndDate date No None

Grade smallint(6) No 0

Title varchar(100) No None

Description text Yes NULL

EventType enum('regular','special') No regular

Status varchar(45) No None

ProposalID int(11) No 0

Proposal related
PROPOSAL

Field Type Null Default Extra

ProposalID int(11) No None auto_increment

Title varchar(100) Yes NULL

ApplicantID int(11) No None

Type enum('kid','parent') No None

Status enum('proved','unproved') No 0

Date datetime No None

CONTENT

Field Type Null Default Extra

ContentID int(11) No None auto_increment

ProposalID int(11) No None

QuestionNumber int(11) No None

QuestionType varchar(45) No None

Answer varchar(45) Yes NULL

E-R Diagrams
 

 
Figure 1 - User related tables
 Figure 2 - Event related

Figure 3 - Proposal related

 Figure 4 - First version of E-R diagram

System Implementation

Queries, Forms and Reports

Currently, we have started to work on two major parts: user management and event
management. The related queries, forms and reports related to these two parts are listed
below:

(1) User management

The main functions related to user management include user login, user profile, user
related managements from administrator’s perspective.

a) User Login

Form – the forms related to this part include:

• The login form for user to login the system with their account id (or account name)
and password.
 Queries – all the existing queries are related to “account”, “account_token” tables, with the
purpose to:

• Check if an account id or an account name exists in the “account” table

• Check if the password is correct
• Create or update a “auto-login” token in “account_token” table

b) User Profile

Form – the forms related to this part include:

• the parent selection form only for parent to select their identity after they use their
children’s accounts to login
• the profile update form to update the user and other people’s (parents for student
user) contact information
Queries – all the existing queries are related to “user”, “account”, “user_type”,
“parent_student”, “teacher_grade”, “student_grade” tables, with the purpose to:

• load all related use info, including user's name, role(student, staff, teacher), user’s
permission(if is an admin), user’s contact info
• load all available parent choices for a specific student user
• load all related events (coordinated events, or volunteered events)
Reports – the reports related to this part include:

• user profile – display user’s contact info, and other related people’s contact info
(student only).
• related events list – display all events user coordinated or volunteered.

c) User Management (admin perspective)

Form – the forms related to this part include:

• the account creation form to create the account for users who have the authority
to possess an account (students, teachers or staff).
• The user creation form to create a new user for the system.
 Queries – all the existing queries are related to “user”, “account”, “user_type”,
“parent_student”, “teacher_grade”, “student_grade” tables, with the purpose to:

• check who in the “user” table have the permission to register an account
• create an account for selected user to “account” table
• create a user to “user” table, and store his user type into “user_type” table
• store the related relationship into different relationship tables (such
as“parent_student”, “teacher_grade”, “student_grade” tables)

(2) Event management

The main functions related to event management include event related management
from administrator’s perspective, event volunteering, and public event list.

a) Event Management (admin perspective)

Form – the forms related to this part include:

• the event creation form to create a new event.

Queries – all the existing queries are related to “user”, “user_type”, “event”, “proposal”
tables, with the purpose to:

• load all available users who can be the coordinators

• load all available (approved) proposals
• create an event (could choose to create from a proposal)
• load all valid events
Reports – the reports related to this part include:

• event list – display all valid events with detailed information.

b) Event volunteering

Form – the forms related to this part include:

• the volunteering submission form for users to apply volunteering for certain event.
 Queries – all the existing queries are related to “user”, “user_type”, “event”,
“event_volunteer” tables, with the purpose to:

• load all valid events

• store the new volunteering info into “event_volunteer” table
Reports – the reports related to this part include:

• event list – display all valid events in calendar view

• event detail – display the detailed info. for one specific event

c) Public event list

Queries – all the existing queries are related to “user”, “user_type”, “event”,
“event_volunteer” tables, with the purpose to:

• load all valid events

• load all applied volunteers for one specific event
Reports – the reports related to this part include:

• event list – display all valid events in table view

• event detail – display the detailed info. for one specific event including the
volunteers

Sustainability

In order to make the system easy to develop and maintain, either for us to develop, or for
others to take over our work, we have deployed several approaches to enhance the
sustainability of the system.

(1) Database design

We have deployed several techniques in the database design phase.

• Use “validation check” to eliminate/replace “real” deletion

 Instead of performing real deletion to erase data records from database tables, we
deploy “validation check” to prevent the loss of meaningful data. It can benefit the
process of database management (such as database backup, database restore) as well
as database manipulation (such as database analysis, database re-design)
• Separate “relationship information” from “native” data
By putting the “Native” data and corresponding “relationship info” into different
relation schemes, it can make the database structure easy to identify, and also
facilitate several database operations (such as relationship manipulation). Also, a
separate database structure can be easily used for the re-design process.

(2) Kohana development framework

In order to better facilitate our development in using PHP, we have chosen a lightweight
PHP MVC framework to support our development. Kohana is a PHP5 framework that uses the
Model View Controller architectural pattern. It is secure, lightweight, and easy to use.

(3) Version control of code

When programming within the group, it is better to perform version control of the code.
We used Google code Project Hosting to help control code versions while revisions are being
made by each contributor. Revision control is any practice that tracks and provides control
over changes to source code. This allows software to be returned to an earlier stage of design
when needed (e.g. Rollback to a more stable version when critical problems occur in newer
version). By using version control we can ensure system sustainability because all revisions can
be compared and restored during future development.
Future Development

Currently we only have User Login, User Account Page, Event Calendar/Lists and Administrator
pages implemented. For future work, we hope that we can fully implement the site including
the functions that we had planned in our earlier project scope. The functions and pages that
we expect to implement for the system to function fully include the following:

● Implement Great Idea Proposal submission and management

functionality
When our group defined the project scope, we had already sketched out the Great
Idea Proposal forms and The Great Ideas Proposal Management pages. In the current
phase, due our planned schedule, we moved this part to the next development phase.
The following are the sketches of the layouts for both functions:

Figure 5 - Kids Great Idea Proposal Form  Figure 6 - Parent Great Idea Proposal Form 
 Figure 7 - Great Idea Proposal Management Page

● Report generation:
Report generating is a function that should be implemented when we have a database
system that collects data. It would be interesting to see things like, “Which parent
volunteered the most?” or “In which month did the school have the most parents
volunteering in event”, and so on. Our team thought about designing report layouts
for different types of reports and write queries that output data for simple analysis.
However, to make report useful for Wines Elementary School, we think that further
communication with the school would be needed before we start to design this part
of the system

● Event Email Notification:

Currently we only have one email notification type, which is the account creation
notification email that is send when new accounts are successfully created. We vision
that it would be nice to have email notifications sent during certain trigger events like:
○ Volunteer Sign-up: When a volunteer signs up, an notification email will be
automatically be sent to the event coordinator.
 ○ Event Volunteer Reminder: A few rules can be applied to this type of email
notification.
‐ The event coordinator can set up a few reminders before hand so that
the system can automatically send the reminder to volunteers during
each setup time.
‐ The event coordinator can manually send reminders to volunteers by
clicking on the [Send Reminder] button.
 

Team Member Contributions

Tze-Hsiang (Stan) Lin

Work:

● Scripted the font-end layout structure of whole site.

● Implemented the Event Calendar page including the calendar widget and volunteer
sign-up forms
● Implemented the volunteer sign-up functionality in back-end using the calendar
widget
● Write-up in System Users Section
Learn:

● Kohana MVC framework in PHP

● jQuery scripting

Lei Shi

● Set up the environment for website development, including creating the Google
project for version control, configuring the Kohana framework for development.
● Converted the E-R diagram into SQL script, and created the database tables in MySQL.
● Implemented the user login function of the website.
● Implemented several functions under administrator’s page, including account creation,
user creation, event creation and event listing in administrator’s perspective.
Weihua Wang

● Implemented the “myevent” page under “My Account” menu. Also implemented the
back-end of the “myprofile” page under “My Account” menu (Lei helped the front-end
style for this page).
● Implemented the “description” page, “eventlist” page, and single “event” page under
“Wines Volunteers” menu to display details of each event, including event time, title,
and description, signed-up volunteer information, etc.
● Installation guide

Peggy Wong

● Designed Website layout, graphics and theming

● Sketched wireframes and brainstormed design ideas
● Structured, edited, and formatted project write-ups
● Wrote the Introduction, System Users, User Scenarios, User Manual, etc…
● Created presentation slides
● Learned about database design, Kohana MVC framework and Google code SVN
Documentation

UI Design (Phase I)

 
Figure 8 – UI Design Phase I (logged out)

Figure 9 – UI Design Phase I (logged in)

UI Design (Phase II)

Figure 10 – UI Design Phase II (logged out)

Figure 11 – UI Design Phase II (logged in with accordion expanded)

 Figure 12 – UI Design Phase II (My Profile with setup username area)

Figure 13 – UI Design Phase II (My Profile with multiple user information)

Figure 14 – UI Design Phase II (Edit My Profile)

Figure 15 – UI Design Phase II (My Events)

 Figure 16 – UI Design Phase II (Volunteer sign-up description page)

Figure 17 – UI Design Phase II (Volunteer sign-up Event Calendar page)

Figure 18 – UI Design Phase II (Volunteer sign-up Event List page)
Figure 19 – UI Design Phase II (User Management)
Figure 20 – UI Design Phase II (Event Management)