The document describes the existing executive appointee process in Oregon and proposes improvements. The existing process involves transferring appointee data between the governor's office, senate desk office, and two separate IT systems. This is inefficient and error-prone. The proposed improvements include creating a central database to store all appointee data, adding a public interface to increase transparency, allowing the governor's office to directly enter data, and removing an unnecessary referral step. These changes aim to streamline the process, reduce errors, and increase efficiency and visibility.

1. P a g e
|
1
Executive
Appointee
Process
Resolution
BA
372
Prof.
Rene
F.
Reitsma,
Ph.D
Gregory C. Knapp
Kehui Zhou
Rayan A. AlRasheed
Ryan K. Masuno
Sultan S. AlMaghrabi
Sarah Awana

2. 2
|
P a g e
Contents
Chapter 1: .............................................................................................................................................3
Intro of Case Study.......................................................................................................................................3
Chapter 2: .............................................................................................................................................5
1. Measures of Success ...........................................................................................................................5
2. Model of change ...................................................................................................................................6
3. Operationalization.................................................................................................................................7
4. Research design...................................................................................................................................8
Chapter 3: .............................................................................................................................................9
Existing Business Process............................................................................................................................9
(Activity Diagram) for Existing Process.......................................................................................................10
IT Sub-process of the Existing Process......................................................................................................11
Process Critique .........................................................................................................................................12
Modified Process Diagram..........................................................................................................................13
Chapter 4: ...........................................................................................................................................15
Tables of the Modified System and their Columns .....................................................................................15
Table Details, Primary & Foreign Keys.......................................................................................................17
Entity Relationship Diagram .......................................................................................................................18
SQL Database Creation and Drop Scripts..................................................................................................19
Executive Summary & Revision Log................................................................................................24
Executive Summary:...................................................................................................................................24
Revision Log...............................................................................................................................................26

3. P a g e
|
3
Chapter 1:
Intro of Case Study
The 77th Oregon legislative assembly in 2013-2014 has rules and procedures for setting up executive
appointments. Unfortunately, the process is rather brittle and inefficient at times. This goal of this process is to
list appointee’s, more than 100 executive appointments for the senate. There are four kinds of periods in the
senate system. Appointments can occur during the long session, the short session, and the long interim and
during the short interim. The executive appointment process uses two information systems, CASS (Committee
Agenda Scheduling System) and the DESK System. This process relies on transferring and exchanging
information, between the Governor's office and the Senate, along with both their approval of the appointment.
The first step of the process starts at the governor's office. The governor's office prepares an Excel
spreadsheet containing lists of the appointees’ names, proposed board and additional related information. After
completing the spreadsheet by the governor's office, they transfer the sheet to the Oregon senate desk office.
The senate desk then saves the received spreadsheet to the legislative network drive. The senate staff logs
into the Desk system and imports the file from the legislative network drive, to the Desk system database. The
appointees are assigned to committees, by the Senate President's office during the session period, and by the
Senate Desk staff during the interim period. After each appointee is referred to a committee, the committee
staff uses the CASS system. CASS schedules the appointments for the committee, but each appointment is
added individually to the agenda with the referred meeting type.
The executive appointment process has several problems that affect the functionality of the system; it
could cost the state money, time and frustration. The process is inefficient, brittle, unclear and not visible to the
public. Another problem is that the system doesn’t support the naming convention variation, and also doesn’t
allow the DESK and CASS system to cooperate. We think the core problem in this system is the unproductive
process of transferring data and information between the two information systems. Transferring data and
information between two different systems will always open the door for errors and risks to lose information or
time.

4. 4
|
P a g e

5. P a g e
|
5
Chapter 2:
In this chapter, we wrote down our analysis for assessing business processes and the improvement
opportunities. This chapter will include a table to measure the success of the processes, a description of the
model of change, the process operationalization and research design.
1. Measures of Success
Problems Measure of Success
The process breaks
easily
Decrease in brittleness results in:
Decrease in Frustration
Increase in Efficiency
Decrease in Downtime
Decrease in Late Submissions
Decrease in Errors
Decrease in Redundancy
Decrease in Overtime
Lack of transparency Decrease in Opaqueness results in:
Increase in Visibility to Public
The process takes a long
time
Increase in Efficiency results in:
Decrease in Frustration
Decrease in Downtime
Decrease in Late Submissions
Decrease in Errors
Decrease in Redundancy
Decrease in Overtime
Costly (Time, Money) Decrease in excess resources used
Time
Money
Doesn’t Facilitate
Cooperation
Increase in Ease of Use and Functionality could increase
cooperation between departments.
Case Report Useless Increase in Functionality could increase value of case
reports
Doesn’t support naming
convention variation
Improved naming convention would increase Ease of Use.
Table 1: Measure of Success

6. 6
|
P a g e
2. Model of change
Our primary goal is to increase the efficiency of the process and decrease employee frustration
resulting from the process, which are our main indicators of success. (See Figure.1) Decreasing data
redundancy is key for the system to reach its best functionality and ease of use. Essentially, cutting down the
number of similar data entries will reduce the number of errors per process. Decreasing the number of errors
will reduce the number of system crashes, which leads to decreased downtime per process. Reduced
downtime lowers the need for an employee to work overtime and lowers late submissions. Moreover, reducing
the number of errors lowers the probability of an employee repeating a step twice or more in a process.
Ultimately, decreased rework, decreased late submissions and decreased overtime lead to better system
efficiency and less employee frustration of the process, which leads back to better system functionality and
ease of use.
Figure 1: Model of change.

7. P a g e
|
7
3. Operationalization
Table 2 displays the operationalization for four problems of the executive appointee process. There are
several ways of measuring the success of the problems as listed in the table. For example, one could measure
the frustration levels of the employees through surveys. The surveys will capture the opinion and perspective
of the users (See table 2).
Frustration
Survey individuals involved in the executive appointment process. This survey would
discover how the frustrations levels occurred prior to the implementation. Then, several
surveys will be conducted to record the frustration levels at specific period’s pot
implementation.
Efficiency
n = number of appointees
------------------------------------------------------------------------------
Total Labor Costs Equation =
Te = Time
a
particular
worker
allocates
for
process
We = Wage
rage
of
a
particular
worker
Oe = Overtime
a
particular
worker
allocates
for
process
Identifies
how
efficient
process
is
by
evaluating
the
mean
cost
of
labor
per
appointee.
------------------------------------------------------------------------------
n = number of appointees
Identifies how efficient the process is by evaluating output per number of steps in
process.
------------------------------------------------------------------------------

8. 8
|
P a g e
Table 2: Operationalization.
4. Research design
Gathering the data necessary to demonstrate the success of our system will be a relatively
straightforward task that we will accomplish in three phases. The first phase will be a pre-implementation
interview with relevant users, i.e. committee members, members of the IT team and those responsible for data
entry. The second phase will happen at the time of implementation and include a short survey and simple
systems analysis by us. The third phase will happen at least six months after implementation and will consist of
follow-up interviews with the group from phase one. At the same time we’ll collect and examine the data
collected by users (error reports, user evaluations).
For information regarding user satisfaction we plan to use a longitudinal (time-series) study to
accommodate for novelty bias. If perceived usability spikes at the time of implementation but returns to
previous levels over the following year, we might conclude that we have not found success in that dimension.
For raw data such as error frequency, downtime and overtime we will use a simple pre/post treatment model.
This type of information should largely be resistant to trends and should not require a time-series study.
Much of the data we need will be infeasible for us to collect personally, therefore we will ask system users to
record as much of it as possible. To track items such as error quantity, we will create a simple form/journal for
the data to be recorded in. Instructions and materials for this methodology will be disseminated during phase
one.
(Continuing
Efficiency…)
n = number of appointees
Identifies how efficient the process is by evaluating output per the mean amount of
errors occur per input.
Downtime Journal and interviews will be conducted by phone and/or email to capture the time
spent during downtime, or the duration of the crash. Individuals involved in the
executive appointee process that are directly involved with the crash will record times.
Functionality Rubric for evaluation for pre and post implementation. Rubric will identify the
functionality by review conducted by those using the system

9. P a g e
|
9
Chapter 3:
Existing Business Process
Chapter 3 explains the current executive appointee process. It includes table 3 that contains every
action in the process, and the tools used to gather data and send them. This chapter also includes an activity
diagram (figure 2), which shows how the process works in its existing state.
ACTION TOOL DATA
Governor’s office inputs names Governor’s APP Appointee Names*
Governor’s office exports names to flash drive Flash drive Appointee Names*
Senate Staff imports names into the G: drive and DESK
Flash drive, G drive, and
DESK
Appointee Names*
Senate Staff sends names to President’s Office
for referral
Hard Copy Appointee Names*
With referral, President’s Office sends approved list to
Senate Rules
Hard Copy Referred Appointees*
Approved appointees are scheduled into CASS
CASS
Approved
Appointees*
Senate Rules votes on referred appointees Hard Copy
Approved
Appointees*
Senate Floor votes on approved appointees Hard copy
Committee Approved
Appointees*
Table 3: Table of the existing business process.
*Includes information such as race, gender, title, first name, last name, address one, address two, city, state, zip, desired
committee, term length, term beginning, term end, old first name, old last name, reason, ORS #, Re, home phone number,
work phone number, cell phone number, date sent, email, board, and position.

10. 10
|
P a g e
(Activity Diagram) for Existing Process
Figure 2: The process in its current state.
ExecutiveAppointeeProcess:OriginalProcess
Governor’sAppGovernor’sOfficeSenateStaffG:SenateRulesStaffPresident’sOfficeDESKCASSSenateFloor
Start
Input
Appointees
Appointee
Appointees
SendNames
toSenate
Staff
Exportto
FlashDrive
Appointees
Inportto
DESKand
G:
AppointeeAppointee
Refer
Appointee?
Error?
Yes
Sends
Referredto
SenateRules
Schedule
Hearing
Referred
Appointee
No
Approved?
Refersto
DESK
Yes
End
Release
Approved
Appointeesto
CASS
Approved
Appointee
No
Voteon
Referred
Appointees
Approved?
Yes
Yes
IT
Subproce
ss
Error?
ITSubprocess
Error?
IT
Subproce
ss
Yes
Yes
SymbolCountDescription
LegendSubtitle
Legend
9Process
6Decision
3Subprocess
5Data
2Start/End
2ExternalData
10CFF
Container
No

11. P a g e
|
11
IT Sub-process of the Existing Process
Figure 3: A sub-process of the existing process diagram, before modifying.
IT
Subprocess
ITStaff
Receive
request
for
assistance
Start
Assess
problem
described
by
staff
Error
occurs
in
Executive
Appointee
Process
Contact
IT
Fix
error
Resume
process
End

12. 12
|
P a g e
Process Critique
The biggest critique we had was that the current system simply wasn’t designed to handle individual
gubernatorial appointees. As a result of the system being stretched beyond its original design, it breaks
frequently, lacks basic functionality expected of an ideal system, and should be replaced. That being said, we
understand that the scope of our redesign is limited. Therefore, our suggestions for process improvements are
simple and achievable. The core of our changes stem from a central database redesign. By creating a system
of relationally linked tables, we will centralized data storage. This means information will be stored in one
location and when it is updated, these updates will be visible to everyone. By designing a database explicitly
for appointees, we eliminate problems of the current system such as data duplication, limited query flexibility,
and poor coordination between departments.
The second recommendation we have is to attach the new database to the senate web server to create
a public window into the process. One of the goals of this redesign requested by the client is to increased
transparency for the public into this process. By linking (most of) the information in our databases to this
window, we cleanly solve the black box issue. This new functionality will come as a result of increased
flexibility in the new design.
The third suggestion we’re bringing forward is to create a window into the database for the Governor’s
office. This would be done with the intention of shifting the responsibility of the initial data entry to the office of
the Governor. This means that instead of exporting a file from the Governor’s app, copying it to a thumb drive
and walking it to the office of the senate staff to be imported into Desk, the information could instead go directly
into the database from the app itself or straight from the exported file. This eliminates the whole transportation
of data by foot process. Alternatively, if this is not feasible, email could be a viable method for moving the
exported file from the governor’s office to that of the senate staff.
Our final suggestion is a bit of a pipe dream, but bears mentioning. We’ve found that the office of the
President of the senate is featured prominently in the process, but ultimately does nothing. All appointees are
always referred to the Senate Rules Committee, so the presidential referral process is completely needless. It
has been said that this remains in the process as a formality, but for the sake of reduced workload and
increased efficiency, it should be removed.

13. P a g e
|
13
Modified Process Diagram
Figure 4. The modified version of the activity diagram process
Executive
Appointee
Process:
Improved
Process
Governor’s
AppGovernor’s
OfficeDatabaseDESKPresident’s
OfficeSenate
Rules
CASSSenate
Floor
Phase
Start
Input
Appointees
Appointees
Appointees
Export
to
Database
Appointees
Access
Database
(Get
Appointee
names)
Refer
to
Rules
Committee
Update
Data
Notify
Rules
Committee
Update
Web
Server
Schedule
Hearings
Hearing
Vote
Access
Database
(Get
Appointee
names)
Progressed
Appointees
Vote
Hearing
Information
Out
In
End
Out
In
3Process
2Decision
2Start/End
4Data
4Data
SymbolCount
Descript
ion
Legend

14. 14
|
P a g e

15. P a g e
|
15
Chapter 4:
This chapter is specified for creating and explaining the relational data model for the newly modified
system. Table 4 contains all the specified tables and their columns like (names, data types, and nullability).
Followed by their explanation. Next, we will also specify all the primary and foreign keys, as well as the entities’
relationship diagram. At the end of the chapter, is a set of SQL database creation and drop scripts for the
modified system.
Tables of the Modified System and their Columns
TABLE
COLUMN NAME
DATA TYPE
NULLABILITY
KEY
Appointee
Appointee_ID
SMALLINT
NOTNULL
PK
Title
VARCHAR(4)
NOTNULL
First_Name
VARCHAR(30)
NOTNULL
Last_Name
VARCHAR(30)
NOTNULL
Gender
VARCHAR(2)
NOTNULL
Race
VARCHAR(20)
NOTNULL
Cell
VARCHAR(13)
Work_Cell
VARCHAR(13)
Home
VARCHAR(13)
Email
VARCHAR(40)
NOTNULL
Street_Address
VARCHAR(40)
NOTNULL
City
VARCHAR(25)
NOTNULL
State
VARCHAR(2)
NOTNULL
Zip_Code
VARCHAR(9)
NOTNULL
Appointment
Appointment_ID
SMALLINT
NOTNULL
PK
Reason
VARCHAR(10)
NOTNULL
Board_ID
SMALLINT
NOTNULL
FK
Appointee_ID
SMALLINT
NOTNULL
FK
Gov_Beg
DATETIME
NOTNULL
Gov_Ed
DATETIME
NOTNULL
Act_Beg
DATETIME
NOTNULL
Act_Ed
DATETIME
NULL
Term_Length
SMALLINT
NOTNULL
App_status_ID
SMALLINT
NOTNULL
FK
Seat_Number
SMALLINT
NOTNULL
S_Event
S_Event_ID
SMALLINT
NOTNULL
PK

16. 16
|
P a g e
Title
VARCHAR(40)
NOTNULL
Description
VARCHAR(250)
NOTNULL
Actor_ID
SMALLINT
NOTNULL
FK
S_Event_Record
Record_ID
SMALLINT
NOTNULL
PK
S_Event_ID
SMALLINT
NOTNULL
FK
Appointment_ID
SMALLINT
NOTNULL
FK
Curr_Date
DATETIME
NOTNULL
Senate_Session_ID
SMALLINT
NOTNULL
FK
Actors
Actor_ID
SMALLINT
NOTNULL
PK
Actor
VARCHAR(50)
NOTNULL
Description
VARCHAR(250)
NOTNULL
Senate_Session
Senate_Session_ID
SMALLINT
NOTNULL
PK
Stype_ID
SMALLINT
NOTNULL
FK
Start_Date
DATETIME
NOTNULL
End_Date
DATETIME
NOTNULL
S_Type
Stype_ID
SMALLINT
NOTNULL
PK
Title
VARCHAR(30)
NOTNULL
Description
VARCHAR(250)
NOTNULL
Length
SMALLINT
NOTNULL
App_Status
App_status_ID
SMALLINT
NOTNULL
PK
App_status_Name
VARCHAR(30)
NOTNULL
S_Event_ID
SMALLINT
NOTNULL
FK
Board
Board_ID
SMALLINT
NOTNULL
PK
ORS_Current
SMALLINT
NOTNULL
FK
Board_Name
VARCHAR(40)
NOTNULL
Description
VARCHAR(250)
NOTNULL
Chair_ID
SMALLINT
NOTNULL
FK
Founding_Date
DATETIME
NOTNULL
Number_Seats
SMALLINT
NOTNULL
Open_Seats
DATETIME
NOTNULL
ORS_Changelog
ORS_Instance_ID
SMALLINT
NOTNULL
PK
ORS
VARCHAR(15)
NOTNULL
Board_ID
SMALLINT
NOTNULL
FK
Date_Implemented
DATETIME
NOTNULL
Description
VARCHAR(250)

17. P a g e
|
17
Document
Document_ID
SMALLINT
NOTNULL
PK
Appointment_ID
SMALLINT
NOTNULL
FK
DateAdded
DATETIME
NOTNULL
Description
VARCHAR(250)
NOTNULL
Title
VARCHAR(40)
NOTNULL
File_Action
VARCHAR(30)
NOTNULL
Doc_Type_ID
SMALLINT
NOTNULL
FK
Doc_Type
Doc_Type_ID
SMALLINT
NOTNULL
PK
Doc_Type_NA
VARCHAR(10)
NOTNULL
Table
4:
The
table
of
the
modified
version
of
the
relational
database
model.
Table Details, Primary & Foreign Keys
• Appointee
Table
This table contains basic information about each appointee. Board appointment information is excluded because
individual appointees could be appointed to several boards in their lifetime, which would lead to data duplication if
included in the appointee table. The phone variables were left nullable, but in the final implementation it would be ideal to
include code which requires at least one phone number without specifying which one. Alternatively the work phone could
be made not nullable.
• Board
Due to the fact the ORS for a board is subject to change each time it is modified by statue, the Board_ID variable
serves as the primary key for this table. This prevents issues with referential integrity when an ORS changes.
The Chair_ID foreign key contains the appointee ID of the board's chair person, referenced from the appointee table.
• Appointment
Table
This
table
is
an
intersection
table
between
the
board
and
appointee
tables.
The
Appointment
Table
documents
the
specific
relationships
between
the
two
tables
and
contains
basic
information
each.
• S(Senate)_Event
Table
This
table
is
a
categorical
table
for
senate
actions.
Referenced
by
the
S_Event_Record
table,
the
S_Event
Table
prevents
data
redundancy.
• S(Senate)_Event_Record

18. 18
|
P a g e
This
intersection
table
between
the
S_Event
and
Appointee
tables.
It
creates
a
record
of
specific
events
that
happened
to
specific
appointees
and
information
about
those
relationships.
• Actors
Table
This
categorical
table
contains
IDs
for
the
different
actors
in
this
process.
• Senate_Session
This
table
contains
records
of
each
individual
senate
session
including
its
start
and
end
dates
and
session
type.
• S(Session)_Type
This
categorical
table
contains
each
of
the
types
of
senate
session
and
is
referred
to
by
a
foreign
key
in
the
S_Session
table.
• App(Appointee)_Status
This
categorical
table
contains
status
information
which
will
be
referenced
by
the
Appointment
Table.
This
identifies
at
which
step
in
the
process
each
appointment
is.
• ORS_Changelog
This table contains a record of the statutory changes to each board and of their shifting ORS identifiers. Each time
a board is modified, a record of the change is stored here.
• Document
This
table
contains
information
on
supporting
documents
which
are
referenced
by
the
appointment
table.
These
include
things
like
resumes,
letters
of
recommendation
and
appointee
portfolios.
• Doc(Document)_Type
This
categorical
table
contains
document
type
information
to
be
referenced
by
the
Document
Table.
Entity Relationship Diagram

19. P a g e
|
19
Figure 5. Entity Relationship Diagram of the modified system.
SQL Database Creation and Drop Scripts
CREATE TABLE Appointee

20. 20
|
P a g e
(
Appointee_ID SMALLINT NOT NULL,
Title VARCHAR(4) NOT NULL,
First_Name VARCHAR(30) NOT NULL,
Last_Name VARCHAR(30) NOT NULL,
Old_First_Name VARCHAR(30),
Old_Last_Name VARCHAR(30),
Gender VARCHAR(2) NOT NULL,
Race VARCHAR(20) NOT NULL,
Cell VARCHAR(13),
Work_Cell VARCHAR(13),
Home VARCHAR(13),
Email VARCHAR(40) NOT NULL,
Street_Address VARCHAR(40) NOT NULL,
City VARCHAR(25) NOT NULL,
State VARCHAR(2) NOT NULL,
Zip_Code VARCHAR(9) NOT NULL
);
CREATE TABLE Appointment
(
Appointment_ID SMALLINT NOT NULL,
Reason VARCHAR(10) NOT NULL,
Board_ID SMALLINT NOT NULL,
Appointee_ID SMALLINT NOT NULL,
Gov_Beg DATETIME NOT NULL,
Gov_Ed DATETIME NOT NULL,
Act_Beg DATETIME NOT NULL,
Act_Ed DATETIME NOT NULL,
Term_Length SMALLINT NULL,
App_status_ID SMALLINT NOT NULL,
Seat_Number SMALLINT NOT NULL
);
CREATE TABLE S_Event
(
S_Event_ID SMALLINT NOT NULL,
Title VARCHAR(40) NOT NULL,
Description VARCHAR(250) NOT NULL,
Actor_ID SMALLINT NOT NULL
);
CREATE TABLE S_Event_Record
(
Record_ID SMALLINT NOT NULL,
S_Event_ID SMALLINT NOT NULL,
Appointment_ID SMALLINT NOT NULL,
Curr_Date DATETIME NOT NULL,
Senate_Session_ID SMALLINT NOT NULL
);
CREATE TABLE Actors
(
Actor_ID SMALLINT NOT NULL,

21. P a g e
|
21
Actor VARCHAR(50) NOT NULL,
Description VARCHAR(250) NOT NULL
);
CREATE TABLE Senate_Session
(
Senate_Session_ID SMALLINT NOT NULL,
Stype_ID SMALLINT NOT NULL,
Start_Date DATETIME NOT NULL,
End_Date DATETIME NOT NULL
);
CREATE TABLE S_type
(
Stype_ID SMALLINT NOT NULL,
Title VARCHAR(30) NOT NULL,
Description VARCHAR(250) NOT NULL,
Length SMALLINT NOT NULL
);
CREATE TABLE App_status(
App_status_ID SMALLINT NOT NULL,
App_status_Name VARCHAR(30) NOT NULL,
S_Event_ID SMALLINT NOT NULL
);
CREATE TABLE Board (
Board_ID SMALLINT NOT NULL,
ORS_Current SMALLINT NOT NULL,
Board_Name VARCHAR(40) NOT NULL,
Description VARCHAR(250) NOT NULL,
Chair_ID SMALLINT NOT NULL,
Founding_Date DATETIME NOT NULL,
Number_Seats SMALLINT NOT NULL,
Open_Seats DATETIME NOT NULL);
CREATE TABLE ORS_Changelog (
ORS_Instance_ID SMALLINT NOT NULL,
ORS VARCHAR(15) NOT NULL,
Board_ID SMALLINT NOT NULL,
Date_Implemented DATETIME NOT NULL,
Description VARCHAR(250));
CREATE TABLE Document (
Document_ID SMALLINT NOT NULL,
Appointment_ID SMALLINT NOT NULL,
DateAdded DATETIME NOT NULL,
Description VARCHAR(250) Not NULL,
Title VARCHAR(40) Not NULL,
File_Action VARCHAR(30) NOT NULL,
Doc_Type_ID SMALLINT NOT NULL);
CREATE TABLE Doc_Type (

22. 22
|
P a g e
Doc_Type_ID SMALLINT NOT NULL,
Doc_Type_NA VARCHAR(10) NOT NULL);
ALTER TABLE Senate_Session
ADD CONSTRAINT PK_Senate_Session_ID
PRIMARY KEY (Senate_Session_ID);
ALTER TABLE S_Type
ADD CONSTRAINT PK_Stype_ID
PRIMARY KEY (Stype_ID);
ALTER TABLE App_status
ADD CONSTRAINT PK_App_status_ID
PRIMARY KEY (App_status_ID);
ALTER TABLE Appointee
ADD CONSTRAINT PK_Appointee
PRIMARY KEY (Appointee_ID);
ALTER TABLE Appointment
ADD CONSTRAINT PK_Appointment
PRIMARY KEY (Appointment_ID);
ALTER TABLE S_Event
ADD CONSTRAINT PK_S_Event_ID
PRIMARY KEY (S_Event_ID);
ALTER TABLE S_Event_Record
ADD CONSTRAINT PK_S_Event_Record
PRIMARY KEY(Record_ID);
ALTER TABLE Actors
ADD CONSTRAINT PK_Actor_ID
PRIMARY KEY (Actor_ID);
ALTER TABLE Board
ADD CONSTRAINT PK_Board_ID
PRIMARY KEY (Board_ID);
ALTER TABLE ORS_Changelog
ADD CONSTRAINT PK_ORS_Instance_ID
PRIMARY KEY (ORS_Instance_ID);
ALTER TABLE Document
ADD CONSTRAINT PK_Document_ID
PRIMARY KEY (Document_ID);
ALTER TABLE Doc_Type
ADD CONSTRAINT PK_Doc_Type_ID
PRIMARY KEY (Doc_Type_ID);
ALTER TABLE Appointment
ADD CONSTRAINT FK_Board

23. P a g e
|
23
FOREIGN KEY (Board_ID)
REFERENCES Board (Board_ID);
ALTER TABLE Appointment
ADD CONSTRAINT FK_Appointee
FOREIGN KEY (Appointee_ID)
REFERENCES Appointee (Appointee_ID);
ALTER TABLE Appointment
ADD CONSTRAINT FK_App_status
FOREIGN KEY (App_status_ID)
REFERENCES App_status (App_status_ID);
ALTER TABLE S_Event
ADD CONSTRAINT FK_Actor_ID
FOREIGN KEY (Actor_ID)
REFERENCES Actors (Actor_ID);
ALTER TABLE S_Event_Record
ADD CONSTRAINT FK_S_Event_ID
FOREIGN KEY (S_Event_ID)
REFERENCES S_Event (S_Event_ID);
ALTER TABLE S_Event_Record
ADD CONSTRAINT FK_Appointment_ID
FOREIGN KEY (Appointment_ID)
REFERENCES Appointment (Appointment_ID);
ALTER TABLE S_Event_Record
ADD CONSTRAINT FK_Senate_Session_ID
FOREIGN KEY (Senate_Session_ID)
REFERENCES Senate_Session (Senate_Session_ID);
ALTER TABLE Board
ADD CONSTRAINT FK_Chair_ID
FOREIGN KEY (Chair_ID)
REFERENCES Appointee (Appointee_ID);
ALTER TABLE Board
ADD CONSTRAINT FK_ORS_Current
FOREIGN KEY (ORS_Current)
REFERENCES ORS_Changelog (ORS_Instance_ID);
ALTER TABLE ORS_Changelog
ADD CONSTRAINT FK_Board_ID
FOREIGN KEY (Board_ID)
REFERENCES Board (Board_ID);
ALTER TABLE Senate_Session
ADD CONSTRAINT FK_Stype_ID
FOREIGN KEY (Stype_ID)
REFERENCES S_Type (Stype_ID));
ALTER TABLE Document

24. 24
|
P a g e
ADD CONSTRAINT FK_Doc_Appointment_ID
FOREIGN KEY (Appointment_ID)
REFERENCES Appointment (Appointment_ID) ;
ALTER TABLE Document
ADD CONSTRAINT FK_Doc_Type_ID
FOREIGN KEY (Doc_Type_ID)
REFERENCES Doc_Type(Doc_Type_ID) ;
ALTER TABLE Appointment
DROP CONSTRAINT FK_Board;
ALTER TABLE Appointment
DROP CONSTRAINT FK_Appointee;
ALTER TABLE Appointment
DROP CONSTRAINT FK_App_status;
ALTER TABLE S_Event
DROP CONSTRAINT FK_Actor_ID;
ALTER TABLE S_Event_Record
DROP CONSTRAINT FK_S_Event_ID;
ALTER TABLE S_Event_Record
DROP CONSTRAINT FK_Appointment_ID;
ALTER TABLE S_Event_Record
DROP CONSTRAINT FK_Senate_Session_ID;
ALTER TABLE Board
DROP CONSTRAINT FK_Chair_ID;
ALTER TABLE Board
DROP CONSTRAINT FK_ORS_Current;
ALTER TABLE ORS_Changelog
DROP CONSTRAINT FK_Board_ID;
ALTER TABLE Senate_Session
DROP CONSTRAINT FK_Stype_ID;
ALTER TABLE Document
DROP CONSTRAINT FK_Doc_Appointment_ID;
ALTER TABLE Document
DROP CONSTRAINT FK_Doc_Type_ID;
DROP TABLE Appointee;
DROP TABLE Appointment;
DROP TABLE S_Event;
DROP TABLE Senate_Session;
DROP TABLE App_Status;
DROP TABLE S_Type;
DROP TABLE S_Event_Record;
DROP TABLE Actors;
DROP TABLE Board;
DROP TABLE ORS_Changelog;
DROP TABLE Document;
DROP TABLE Doc_Type;
Executive Summary & Revision Log
Executive Summary:

25. P a g e
|
25
This report was commissioned to examine the Seventy-Seventh Oregon Legislative Assembly in 2013-
2014 Oregon Senate executive appointments process and to recommend ways of increasing the overall
efficiency of the process.
The report draws attention to the fact that the current process is rather brittle, inefficient, vague and not
visible to the public. Mainly, this report suggests that the core problem is in the main process, which utilizes a sub-
optimized process of transferring data and information between the two information systems, DESK and CASS. This
results in data redundancy, increased cycle time, lower cooperation and less than ideal case reports. Ultimately,
decreasing data redundancy is key for the system to reach its best functionality and ease of use. As a result of
the system being used beyond its original design, it breaks frequently, lacks basic functionality expected of an
ideal system, and should be repaired or perhaps replaced.
It is recommended that creating a system of relationally linked tables will improve and centralize data
storage. The second recommendation is to attach the new database to the senate web server to create a
public window into the process. The third recommendation is to create a window into the database for the
Governor’s office. However, if this suggestion is not manageable, email can be a viable method to transport
files from the governor’s office to that of the senate staff. Finally, this suggestion may not be feasible but it’s
worth mentioning; we found that the presidential referral is superfluous in the process as appointees are
always referred to the Senate Rules Committee.

26. 26
|
P a g e
Revision Log
DATE ORIGINAL ERROR
[Location (Chapter.Page.Paragraph), Error, Description]
REVISED
2/21
2/21
2/21
2/21
2/21
2/21
3/3
3/3
3/3
3/3
3/3
3/3
3/3
3/3
2.3.0. Needs to format the chapter titles
2.3.0. “Brittle.” Replace Problem words to short
descriptions.
2.4.1. “Mainly, our…” Take out “Mainly…”
2.4.1. “Moreover, cutting down the number…” Change
“cutting down” to “reducing.”
2.5.0. Need to correct equation to include proper
mathematical format.
2.6.0. “…will record times with a stopwatch.” Needs to
take out “stopwatch.”
3.9.0. Did not have an introductory paragraph for chapter
3.
3.10.0. Senate Rules does not equal Senate Rules Staff.
3.10.0. Activity Diagram for existing process needs to
change colors.
3.11.0. Activity Diagram for IT process needs to change
colors.
3.12.1. “...current system simply isn’t…” Change “isn’t.”
3.12.1. “Therefore our suggestions…” Missing a comma.
3.12.1. “By creating a system of relationally linked
databases…” Change “databases” to “Tables.”
3.13.0. Activity Diagram for improved process needs to
change colors.
Put chapter titles in correct
areas on the left side.
Changed to, “The process
breaks easily”
Changed to, “Our primary
goal…”
Changed to, “Moreover,
reducing downtime…”
Changed equation to include
!
!!!
Changed to, “…will record
times.”
“Table 2 displays the…”
Changed swim lane title to
“Senate Rules Staff.”
Changed blue color to black.
Changed blue color to black.
Changed to, “…current
system simply wasn’t…”
Changed to, “Therefore, our
suggestions…”
Changed to, “By creating a
system of relationally linked
tables…”
Changed blue color to black.
4/20
4.15.1 "The chapter includes a table that contains all the
specified tables and their names..." Take out "The
chapter includes a" change "that" to "4" and "names" to
Changed to "Table 4 contains
all the specified tables and
their columns..."

27. P a g e
|
27
"columns"
4/20
4.15.1 "After the following table (Table 4) is its
explanation, detailing the reason behind our choices."
Take out "After the" and "detailing the reason behind our
choices" Change "following table (Table 4) is its
explanation" to "Followed by their explanation".
Changed to "Followed by their
explanation."
4/20
4.15.1 "Later on in the chapter, we will also specify... as
well as the entities' new relationship diagram." Change
"Later on in the chapter," to "Next," and take out "new".
Changed to "Next, we will
also specify all the primary
and foreign keys, as well as
the entities’ relationship
diagram."
4/20
4.15.0 Tables of the Modified System and their Columns.
Take out two column names.
Removed Old_First_Name
and Old_Last_Name from the
column names
4/20
4.15.0 Tables of the Modified System and their Columns.
Change nullability of Act_Ed.
Changed nullability of Act_Ed
from "NOTNULL" to "NULL"