Page |

Oregon Senate – Executive Appointments

BA 371 Case study, Professor Reitsma

Students 1, 2 and 3FEBRUARY 15, 2014

TABLE OF CONTENTSChapter 1 – Introduction............................................................................................................................1

Chapter 2 – IS impact assessment..............................................................................................................3

Measures of Success................................................................................................................................3

Model of Change.....................................................................................................................................5

Figure 1 – Model of Change.................................................................................................................5

Operationalization...................................................................................................................................7

Research Design......................................................................................................................................9

Chapter 3: Business Process Models........................................................................................................11

Existing Business Processes...................................................................................................................11

Figure 2 – Current Executive Appointments Process.........................................................................14

Suggested Business Process Changes....................................................................................................14

Figure 3 – Proposed New Process......................................................................................................19

Chapter 4: Database Design......................................................................................................................21

Figure 4 – Entity Relationship Diagram..............................................................................................21

Descriptions of Tables...........................................................................................................................22

SQL Scripts.............................................................................................................................................26

Revisions Log.............................................................................................................................................30

Page | i

CHAPTER 1 – INTRODUCTION

The Seventy-Seventh Oregon Legislative Assembly follows official rules and procedures

concerning over 100 Executive Appointments subject to Senate Confirmation. This process currently

runs through two systems, Desk and CASS, which were designed to handle bills and measures. Sending

these executive appointments through this system creates a number of problems, as well as a lot of

confusion and frustration in the process. The current process proceeds as follows:

1. The Governor’s office prepares a spreadsheet with the list of proposed appointee names, the board

and the term to which each appointee is being considered.

2. The generated spreadsheet of appointees saved to a USB drive and manually given to the Senate

3. The senate desk staff saves it to a specific Legislative network drive location

4. The senate desk staff imports the list to the Desk’s system database

5. The senate President’s Office and the Senate desk staff then assign the proposed appointees to a

committee

6. Once in committee, committee staff schedules the appointees for a committee meeting in the CASS

system. Each appointee is added individually to the agenda for their executive appointment.

The systems supporting this process are there to aid the functions of the process, as depicted

above with all operations running correctly. However, there are several problems caused by human

error and inefficient system components; which result in crashes, delays, and missed deadlines. Some of

the main issues with the system are as follows:

1. While manually importing Executive Appointee information, the Governor’s Office occasionally

changes the file format (or delivers information in an unusable format) which causes the entire import

to fail, and an IS specialist is needed to accommodate changes.

Page | ii

2. There is a lack of consistent naming and sorting for ‘boards’, and appointees do not always match up

in the different systems.

3. There is no public- accessible/ searchable way to find appointee information on the website.

4. There is a lack of coordination around the overall Executive appointment process between the

different parties involved.

5. There is no function that allows for large groups of appointees to be handled in the CASS system, and

the reports generated in CASS do not meet the specific needs of Executive Appointments.

6. Manual intervention is often needed to transfer information between the CASS/ Desk system, which

leads to a large margin of human error and other secondary issues.

The goal of analyzing the current process and creating a new system to improve its efficiency is

to reduce the number of problems that occur and eliminate any factors that cause the process to run

both efficiently and effectively.

Page | iii

CHAPTER 2 – IS IMPACT ASSESSMENT

MEASURES OF SUCCESS

There are many measures of success that are imperative to achieve through analyzing and

improving the process of Executive Appointments. These measures are used as a guide of how the new

system should minimize the problems caused by the current way of operating this process. These

measures are as follows:

Reduce cycle time

Reduce occurrence of system crashes

Prevent and/or catch non-human errors

Information of Executive Appointments transfer consistently between parties and systems

Information uploaded and transfers to Desk and CASS with ease

Information in files are sorted and organized appropriately for each party

One of the most important of these measures is to reduce cycle time. Reducing the time needed

for each step in the process will relieve frustration from each party and make the necessary interactions

with the process more efficient. The cycle time of this process’s current state is much longer than

necessary due to inconsistent data transferring and the systems crashing when mistakes in the data

occur.

Another measure is to reduce the number of times the system crashes. These crashes delay the

process and thus affect cycle time. Crashing occurs when an error is present in the system or the data,

but currently instead of prompting the user the system just shuts down. To reduce these events, there

Page | iv

must be automation in the systems used. This will prevent errors from occurring in the first place

because less human interaction will be necessary. Another benefit to reducing these crashes is less

reliance on the IT department. Currently, when these crashes occur it not only increases the cycle time

of the Executive Appointments process, but it also interrupts the IT department’s work and requires

them to increase cycle time in their tasks. By reducing and potentially eliminating these crashes it can be

ensured that the new system will be reliable and information can be quickly uploaded to the databases.

To reduce these crashes is to focus on the third measure of success, preventing and catching errors.

These errors include the same data being entered twice, differences in ordering the data, and fields

being left blank. Other errors are those that are caused by normal, human mistakes, such as misspelling

of a name. These human errors are separate and aimed to be reduced as cycle time is reduced, as there

will be less frustration with the process and less rushing through the data. The errors that can be

prevented and caught will help to reduce the Desk and CASS from crashing, thus this measure is tied to

reduction of crashes and cycle time.

Another measure of success that will ensure the systems to work properly is to make certain

that the information of Executive Appointments transfer consistently between parties and correspond

correctly with the Desk and CASS. This measure is important because it guarantees protection of the

information and validity to its accuracy. All the data need to be in the same formatting type so it can be

transferred efficiently. By succeeding with this measure, both cycle time and the number of errors will

decrease.

A fourth measure of success is to be certain that the transfer of those data is consistent and

efficient, thus eliminating stress and providing simple operations in the process. The information holding

Executive Appointments should be able to easily transfer between parties and upload to the Desk and

CASS without errors.

Page | v

This leads into the last measure, that information is sorted and organized appropriately for each

party. The goal here is to decrease the amount of confusion between transfers concerning the names of

boards and committees. This can be accomplished through automation and an organizational system

that allows each party to view the data in the order they want. Creating a system with this feature

allows each party to reduce the cycle time they currently use for re-formatting and organizing the data

to their specific needs. This way of organization calls for each board name to be referred to in only one

way, instead of duplicate names listed different ways within one file.

MODEL OF CHANGE

Page | vi

FIGURE 1 – MODEL OF CHANGEThis Diagram is a description of the causal model between the measures of success. The first step is implementing a centralized system, then the arrows demonstrate how each variable causes the next.

By taking the measures of success and forming them into a causal relationship, a model of

change can be created to assist with the flow of how each change in the current process encourages

other changes to occur, as displayed in Figure 1 – Model of Change. The first step in the model of change

is to implement a centralized system that holds all the information of Executive Appointments in one

place, which each party can access and use. To achieve this, there needs to be a template for entering,

organizing, and viewing the information. This template will organize data by “order by” preference,

specified individually for each party, which will in turn help data stay consistent when transferring

between parties. By using automation to keep consistent data throughout the system, a large portion of

crashes can be avoided, resulting in less need for help from the IT department. To aid avoiding errors

within the data, the template will catch non-human errors inputted, reducing time spent on re-

formatting and organizing the data. This template makes the system able to correctly identify any errors

that do occur and then prompt the user of their origin. Catching errors and notifying the users reduces

the number of errors that are overlooked and then result in future problems. As well, by reducing both

the number of errors in the data, as well as the need for IT help, the cycle time becomes significantly

shorter. Less time is wasted inefficiently on rebooting the system due to an error caused crash. This

template also has organizational qualities that can order the data in whatever way each party prefers;

leading to less need for human interaction with the information, in re-formatting, and keeps the data

consistent. This automation reduces cycle time and the errors that could occur in the data when there is

manual interference. This specific causal relationship flow in of the model of change eliminates the

unreliability of using a flash drive to transfer data and the inconsistency in the data itself. Another

benefit by implementing a centralized system is that the system can keep consistent running time logs of

interactions with the data, in one easily accessible place. These time logs keep track of who views and

Page | vii

changes the data, and also when each user’s deadline is. Through having an internal measure of time, it

can be guaranteed that the measures are always accurate and specific. Reminders can then be sent out

to each party during the cycle, for check points and help in enforcing these deadlines. This keeps

everyone aware of where the current state of the process stands, to increases the use of good time

management planning and to help avoid unprofessionalism. The main goal in implementing this causal

relationship is to result in a decrease of procrastination and frustration from all parties.

OPERATIONALIZATION

The measures of success to reduce the specified problems can be broken down into

components that are definable and measurable. This way of assessing data allows one to measure

theoretical variables, a term called “Operationalization.” This allows each part of the model of change to

be measured and assess the impact it will have on the process of Executive Appointments. The

measures to be assessed are as follows:

Reduction in cycle time

Reduction of System Crashes

Reduction in errors

The first measure to be assessed is a reduction in the cycle time of the process, from when the

Executive Appointments are received by the Governor’s office, to when the Rules Committee votes on

the appointments and approved position are sent back up to the Senate. A main component of the

current process that requires excessive time is after the initial transfer of the list of Executive

Appointments on the USB drive, when the Senate’s office uploads the file to the Desk system and has to

re-format the document and re-organize the information it carries. To evaluate this inefficient use of

Page | viii

time that the new system will reduce, a log of time spent transferring the data will need to be kept. A

log of time also will need to be kept by the Rules Committee in order to measure the time spent on

transferring the data received by the Desk system into their CASS system, and re-formatting it so that it

meets the needs of the committee when making decisions on the appointees. These are important uses

of time to evaluate, both before and after the new system, because the new system should greatly

reduce them; done through the creation of a centralized system which can be easily modified for each

party to fit their specific needs and tasks. Much of the other cycle time used in this process requires

human interaction and cannot be eliminated because the need for reasoning, discussions, and decision

making on the Executive Appointments.

Another component that must be measured and assessed is the reduction of system crashes,

both for the Desk and CASS. In the model of change, the new proposed system would reduce these

crashes that are caused by errors in the data, whether they occur due to inconsistency or merging

different data types. These crashes can be measured in number and by cause. Currently, when each

crash occurs it causes the person interacting with the system to notify IT support and wait for assistance

to fix the problem. This is again an inefficient use of time and can result in data inconsistency or loss. A

way to measure this problem is to record each time a crash occurs, the amount of time wasted on fixing

a crash, and the initial cause of the crash; this assuming that the error is identifiable.

Through measuring system crashes by the number of times IT assistance is needed, it is also

essential to measure any errors in the system and the data. Errors that cause system crashes can be

measured by specifying the type of error when recording a crash occurrence. Errors that occur without

causing a crash can be measured by recording an error that is discovered by people interacting with the

data. To compare the current system and the proposed new system, these records taken previous to the

new system will be assessed against the number of times that the new system prompts users when an

Page | ix

error occurs. Prompting the current user of an error is a benefit that comes from creating a customizable

template for the information; because the template has certain requirements for each field. These

errors that are measured, and in the new system notify the user, are not subject to human error. It is

inevitable that human mistakes will exist, but by creating a centralized system and template that is a

more efficient way of organizing data, these human errors can be reduced. As well, the reduction in

cycle time will allow each part in the process a more flexible use of time to carefully interact with the

data.

RESEARCH DESIGN

In a process such as Executive Appointments, there can be a lot of factors that affect the

outcome of a measurement. For example, sometimes during the process a large amount of errors will

occur, thus causing an increase in cycle time and number of crashes, and then sometimes only a small

amount of error could occur. Due to this, the best approach to a research design for collecting the data

to analyze is an interrupted time series. This type of design is a collection of data over a period of time

with the current system and then again after the new system is in place another collection of data is

done over a period of time. In this case, the data being collected on the old system centers around time

and errors that occur, with details included for each so that these problems can be assessed. The data

collected when the new system is in place will be focused the same, but will mostly be done through the

automation of the system itself and then can be extracted to analyze.

The measurements of before and after can be compared to assist in assessing how IT impacted

the process; and because of this they have to be recorded in very similar ways to reduce outside

variables affecting the results. As well, these measurements need to be done efficiently in that they do

Page | x

not interrupt the process or that the time taken to gather them does not increase the cycle time, thus

jeopardizing the validity of the measurement. To ensure that these are avoided, an outline of a log will

be provided for a resourceful and simple way to record measurements as the process moves along. This

outline will be used for three separate, consecutive times running through the entire process using the

old system approach, and then again three separate, consecutive times running on the new system.

Between the collections of these measurements is the installation of the new system and trials with it

for three months, to ensure that any bug and defects that occur at first are fixed, thus they have no

influence on the measurement results collected. This outlined log will serve as a work driver, to

encourage each party to use time efficiently and, after a comparison of before and after measurements,

be aware of the time allotted to each step in the process. To keep recording patterns consistent, the log

will divide the process into individual steps, which each include the measurements to be taken for the

step. For measures of time, it can be utilized as a time management planning tool on how to work within

a specific time frame and put each task into context for the whole process.

Page | xi

CHAPTER 3: BUSINESS PROCESS MODELS

This chapter is a review of the existing process used for scheduling Executive Appointments, a

summary of suggestions for the process, as well as a model for the new proposed process. The point in

stating the existing process is to show understanding of each step in the process, both how it works and

why it is a step. To effectively analyze this process and propose new ideas for improvement, there has to

be a clear recognition of each of its important actions and what is needed to support them. This is

displayed in our 3-column quasi formatted summary of the existing process. Each column is labeled for

its content, Actor & Action, Medium or Tool, and Required Information. The existing business process is

also displayed in a visual format through Figure 2 – Current Executive Appointments Process. This figure

shows the actors in each step and the flow of the current process from start to end. The suggested

business process describe the changes proposed and how they would benefit the process. This process

is also supported by a visual format in Figure 3 – Proposed New Process.

EXISTING BUSINESS PROCESSES

The current business process of Executive Appointments is as follows:

Actor & Action Medium or Tool Required Information

People apply to be appointed on a board or commission for the Oregon Senate.

Executive Appointments Interest Form document/mailed or faxed to Office of the Governor

Board/commission appointment and position desired

Name Address Demographics Education Employment/Experience Explanation of interest in

appointmentThe Governor’s staff collects all Governor’s office’s .Net App Interest forms that contain

Page | xii

appointment interest forms and inputs their information into their .Net app. The hard copies of the interest forms and the resumes attached are scanned into the computer, to be saved to the filing system, then compiled into binders and placed in the archives.

appointment’s information

Governor accesses .Net app information and chooses which appointment applications to approve.

.Net app Executive appointments general information

A list of the appointments is generated on an Excel spreadsheet. The Governor’s secretary saves the file onto a USB drive and manually hands it over to the Senate’s office.

.Net app (generates file) Excel (.csv file, holds data) USB (transports data file)

Executive appointments general information

Only if in session, list of appointments goes to Senate’s President’s office for approval.

Excel spreadsheet Executive appointments general information

Cindy uploads spreadsheet to the Desk system.

Excel spreadsheet USB Desk system

Executive appointments general information

Re-format and organize information for Desk system to properly integrate all of the spreadsheets contents.

Desk system (manually re-format and organize)

Executive appointments general information

Rules committee receives appointment information through the CASS view of the system. The corresponding interest forms can be viewed on the computer filing system.

CASS Computer filing system (:G

drive)

Executive appointments general information

Interest forms Applicants’ resumes

Rules Committee puts together an agenda with all the names of applicants to be sent out to the public for viewing. Names appear on a drop down list.

CASS system’s agenda scheduling

Date/time of appointments’ hearings

Executive appointments general information

Rules Committee holds hearings for appointees to come explain why they want and deserve the position they applied for.

Interest boards Executive appointments general information

Applicants’ testimony Public’s input (if someone

comes to speak for or

Page | xiii

against an applicant) Rules Committee votes on appointments.

Rules Committee Meeting Executive appointments’ general information

Collected data on applicants (interest forms, resumes, testimonies)

Rules Committee enters votes in CASS individually for each appointment, even if whole group was voted on an approved.

CASS system Vote decisions

Approved appointments sent back up to Desk through CASS, where the Senate gets the final vote/approval on all appointments.

CASS system Desk system

Rules committee’s vote on the appointments

Final list of approved appointments sent back to Governor’s office.

List of names List of executive appointments approved by both Rules Committee and the Senate’s office

Page | xiv

FIGURE 2 – CURRENT EXECUTIVE APPOINTMENTS PROCESSThe flow chart describes the flow of the current Executive Appointments process. Pay close attention to the use of spreadsheets and the transfers of data between parties. Also, note the loop that occurs when assessing if the upload to Desk was successful or not. (E.A. stands for Executive Appointments)

SUGGESTED BUSINESS PROCESS CHANGES

The current process for scheduling Executive Appointments has room for improvements. By

narrowing down these problem areas and finding new, more efficient ways of getting the same end

result, the process time can be decreased and effectiveness increased. Here are some variables in the

process that need to be changed:

The file format used to store the appointments’ data is an Excel .csv file.Page | xv

From the Governor’s office to the Senate, the Executive Appointments information is

transferred manually on a USB drive.

The data are manually integrated with both Desk and CASS.

The Rules Committee has to individually input their final vote for each appointee, even if there is

a group vote with the same decision for all.

The goal in proposing changes to these areas is to improve efficiency in the process. The

Majority of these changes can be made through the implementation of a centralized system. Then, the

automation of this system will influence other areas of the process to change and become more

efficient. The first area to be improved is the use of Excel to store the appointments data. This is not an

efficient way to transfer data because it is too simple of a program to handle the important data

involved in this process. The .Net app organizes the data and then generates the Excel spreadsheet, but

in Excel there is no way to ensure consistency in the transfer due to the lack of function for specifying

rules and requirements for the data types that are in each column. This leaves a lot of room for error,

especially when there is human interaction with the spreadsheet. In implementing a centralized system

that can act as a common data repository for all three parties, the use of Excel file spreadsheets can be

eliminated. Currently, the .Net app of the Governor’s office generates the spreadsheet to be transferred

to the Senate. The centralized system will be able to interact with their system and accept any file type

that it generates. The template that this system is built with will have ordering preferences and other

requirements for each column of data that will ensure all the information is correct.

The second area where improvement is needed is how the information is transferred from the

Governor’s office to the Senate’s office. In the current process, this transfer is done by saving the

spreadsheet to a USB drive and physically being transported to the Senate’s office. This transfer is an

inefficient use of time because it requires human transport and it is unreliable. If the USB drive was

Page | xvi

misplaced or improperly delivered, then this would cause only more cycle time to be wasted. This

inefficiency can also be solved by implementing a centralized system. This system would give the

Governor’s office a connection to the Senate’s office through their .Net App. The list of executive

appointments the .Net App generated could be saved directly to the centralized system and then could

be viewed by the Senate’s office to be uploaded to the Desk system. Also, because this system has

automation in ordering and sorting the data differently for each party’s needs, there would be no

inconsistencies the file types used. This would reduce the errors caused by the Desk and CASS not

accepting certain parts of the information.

Another area in the process to be adjusted is the manual integration of data with Desk and

CASS. The current way to upload information to Desk and CASS is to do so automatically as much as the

systems can handle, then manually input missing data and re-organize it to fit the needs of the system.

Instead, there should be little to no need for human interaction with the data when just uploading

information. This part of the process should go smoothly and take up little amount of time. This is one

more thing that can be eliminated by having a centralized system. As said previously in the Model of

Change description, the centralized system will have an automated template that guides users in

inputting or uploading data to it. The information can then be transferred from system to system in an

organized manner, which complies with each different system’s specific needs.

One more area that needs to be made more efficient is the scheduling of appointments

by the Rules Committee. Currently the appointments and scheduled to be reviewed individually by

person, which takes up more space in the systems and more time in the process. Then if the

appointments are clumped together in a group vote, the person from the Committee that inputs the

votes into CASS still has to do it for each individual appointee. Instead, these should be separated by

board and then within each board the appointees can be reviewed. This would reduce the amount of

Page | xvii

scheduling to be done by the Rules Committee. Combined with this new way of scheduling, is the

implementation of the centralized system. By making both of these changes, there is the opportunity to

fix the redundancy of going through every single appointment and putting the same vote. Separating the

appointments by board will allow CASS the ability to input votes differently, and this can be done

through the automation of the centralized system’s template.

Page | xviii

Page | xix

FIGURE 3 – PROPOSED NEW PROCESSThis flowchart describes the new proposed process for Executive Appointments. Note how the centralized system has many automated actions.

Page | xx

Page | xxi

CHAPTER 4: DATABASE DESIGN

This chapter includes the design for the database that will hold all of the data for Executive

Appointments in the new process. First, Figure 4 – Entity Relationship Diagram displays each table in the

database and the data that it holds. The description of tables is below Figure 4 – Entity Relationship

Diagram, which goes into more depth of what the purpose of each table is. Primary keys for each table

are identified and foreign keys are identified. The SQL scripts for each table show how these data are

converted to a database; both create and drop scripts are provided.

FIGURE 4 – ENTITY RELATIONSHIP DIAGRAMThis figure displays the eight tables included in the database for Executive Appointments. Note that the primary key in each table and how it is referenced in other tables. Also, note the relationships these references create between the different tables.

Page | xxii

DESCRIPTIONS OF TABLES

Appointees is a table holding all the contact information of the people applying for appointment

to a board. The different columns are Name_ID, First_Name, Last_Name, Phone_Number, Email,

Address1, Address2, City, State, and Zip.

Primary Key: Name_ID assigns an integer representation, ID number, for each appointee.

Classifying appointees this way eliminates confusion of which appointee is being referenced if

there are duplicate names in the system.

Board is an object table that holds the data about all of the Boards. The columns include

ORS_ID, Gov_Name, Sen_Name, Term_Length_M, Num_Members, and Date_Origin. The Gov_Name

and Sen_Name columns are significant because the Governor’s and Senate’s offices often differ in the

way they name a board, which causes errors in the data with the current process. The Term_Length_M

specifies how long the board is made to last for, in months. Num_Members holds the number of

members on the board currently and Date_Origin is the data the board was established.

Primary Key: ORS_ID is the ID number of each board based on their ORS number. This key

separates each board by its individual ORS number to avoid confusion between how different

parties prefer to name the board.

Status is a category table that holds the different statuses an appointment can have. As it is a

category table its purpose is to classify and limit the types of statuses that can occur, so that other tables

can refer to them. The columns are Status_ID and Status_Type. Status_ID is the integer representation

of the status and Status_Type is the description of the type of status.

Page | xxiii

Primary Key: Status_ID is the ID number that refers to a specific status the appointment is in. It

is listed in a category table and referenced in other tables so that the status can be classified and

described.

Action_Category is a category table that holds the different actions that can be taken on an

appointment. The table’s purpose is to classify and limit the types of actions that exist, so that other

tables can refer to them. The columns are Action_ID and Action_Type. Action_ID is the integer

representation of the action and Action_Type is the description of the type of action.

Primary Key: Action_ID is the ID number that refers to an action taken on the data of an

appointment. This ID makes each action specific and able to be referenced by other tables.

Document_Type is a category table that holds the different documents that can be used to

support appointments. The table’s purpose is to classify and limit the types of documents that can be

used. The columns are Doc_Type and Doc_Name. Doc_Type is the representation of a document

through a short text and Doc_Name is the description of the document.

Primary Key: Doc_Type is the shortened name of documents that are described in the other

column of the table. This type can be referenced by other tables in declaring which kind of

document is used for support.

Nominations is an intersection table that holds the specific appointments. This table is a

connection between each appointee and the board they are being appointed to. The many to many

relationship is that many appointees can be appointed to the same board, as well as one appointee can

be appointed to many different boards. The columns are Appt_ID, ORS_ID, Name_ID, Status_ID,

Gov_Start_Date, Gov_End_Date, Actual_Start_Date, and Actual_End_Date. Appt_ID is the integer

representation of the specific appointment. The ORS_ID is the board the appointee is being appointed to

Page | xxiv

and the Name_ID is the appointee. Status_ID holds the status the employee has in the process. The

Gov_Start_Date and Gov_End_Date are the dates that the appointment starts and ends as specified by

the governor; they are the only start and end date columns in this table that are required to be not null.

The Actual_Start_Date and Actual_End_Date are the actual dates the appointment starts and ends if

they are approved, thus these columns remain empty until/if the appointment is voted approved.

Primary Key: Appt_ID is the individual ID of a specific appointment. This identification connects a

certain appointee with a certain board. More than one appointee can be appointed to one

board and one appointee can be appointed to more than one board. This many to many

relationship creates the need for this primary key because it is a unique identifier of each

individual appointment that is in the system.

Foreign Keys: ORS_ID, Name_ID, Status_ID

o ORS_ID is a primary key in the Board table. It is referenced as a foreign key in this table

to connect the specific board that the appointment is for.

o Name_ID is a primary key in the Appointees table. It is referenced as a foreign key in this

table to connect the specific appointee that the appointment is for.

o Status_ID is a primary key in the Status table. It is referenced as a foreign key in this

table to specify what status the appointment is at.

***Note: ORS_ID and Name_ID are composite primary keys of this table. They are listed here as

foreign keys, as they reference the primary keys of other tables, though they have primary key

qualities. Access limits each table to one primary key, but outside of access these keys would be

composite primary keys because they connect all different aspects of a nomination.

Document is an object table that holds the specific documents for each appointment. The

columns are Doc_ID, Appt_ID, Doc_Type, and Doc_Ref. Doc_ID is a specific reference to the individual

Page | xxv

document. Appt_ID is the specific appointment that the document refers to and Doc_Type is the type of

document included. Doc_Reference is an attachment to the actual document itself.

Primary Key: Doc_ID is the individual ID of a specific document. This key refers to an exact

document that is in the system so that it can be tracked by ID instead of name, eliminating

confusion among many documents with the same name. Appointments can have many different

documents to support them.

Foreign Keys: Appt_ID, Doc_Type

o Appt_ID is a primary key in the Nominations table. It is referenced as a foreign key in

this table to connect a specific document to an appointment.

o Doc_Type is a primary key in the Document_Type table. It is referenced as a foreign key

in this table to name the kind of document being included.

Action_Log is a transaction table that holds every action that occurs with the appointment data.

This table tracks where the data is at in the process and who has interacted with it. The columns are

ID_Log, Action_ID, Action_Date, Actor_ID, Appt_ID, and Status_ID. ID_Log is the integer representation

of each specific interaction with the data. Action_ID is the action that occurred, Action_Date is the when

it occurred, and Actor_ID is who executed it. The Appt_ID is the appointment the action effected and

the Status_ID is the new status the appointment is because of the action.

Primary Key: ID_Log is an ID number that represents a specific interaction with the appointment

data. It refers to a specific action, as there are many actions that can occur with each

appointment.

Foreign Keys: Action_ID, Appt_ID, Status_ID

o Action_ID is a primary key in the Action_Category table. It is referenced as a foreign key

in this table to state the type of action taking place on the appointment.

Page | xxvi

o Appt_ID is a primary key in the Nominations table. It is referenced as a foreign key in

this table to connect a specific appointment to each action.

o Status ID is a primary key in the Status table. It is referenced as a foreign key in this table

to specify what status the action leaves the appointment at.

SQL SCRIPTS

CREATE:create table Appointees(Name_ID int not null,First_Name varchar(30) not null,Last_Name varchar(30) not null,Phone_Num int,Email varchar(20), Address1 varchar(40),Address2 varchar(40),City varchar(25),State varchar(3),Zip varchar(9));

create table Board(ORS_ID smallint not null,Gov_Name varchar(50) not null,Sen_Name varchar(50) not null,Term_Length_M smallint not null,Num_Members smallint not null,Date_Origin date);

create table Status(Status_ID smallint not null,Status_Type varchar(100) not null);

create table Action_Category(Action_ID smallint not null,Action_Type varchar(20) not null);

create table Document_Type(Doc_Type varchar(20) not null,Doc_Name varchar(20) not null);

create table Document

Page | xxvii

(Doc_ID smallint not null,Appt_ID int not null,Doc_Type varchar(20) not null,Doc_Ref longtext);

create table Nominations(Appt_ID int not null,ORS_ID smallint not null,Name_ID int not null,Status_ID smallint not null,Gov_Start_Date date not null,Gov_End_Date date not null,Date_Began date,Date_Ended date);

create table Action_Log(ID_Log int not null,Action_ID smallint not null,Action_Date date not null,Actor_ID int,Appt_ID int not null,Status_ID smallint not null);

alter table Appointees add constraint pk_Appointees primary key (Name_ID);

alter table Board add constraint pk_Board primary key (ORS_ID);

alter table Status add constraint pk_Status primary key (Status_ID);

alter table Action_Category add constraint pk_ActionCategory primary key (Action_ID);

alter table Document_Type add constraint pk_DocumentType primary key (Doc_Type);

alter table Document add constraint pk_Document primary key (Doc_ID);

alter table Nominations add constraint pk_Nominations primary key (Appt_ID);

alter table Action_Log add constraint pk_ActionLog primary key (ID_Log);

alter table Document add constraint fk1_Document foreign key (Appt_ID) references Nominations (Appt_ID);

alter table Document add constraint fk2_Document foreign key (Doc_Type)references Document_Type (Doc_Type);

Page | xxviii

alter table Nominations add constraint fk1_Nominations foreign key (ORS_ID)references Board (ORS_ID);

alter table Nominations add constraint fk2_Nominations foreign key (Name_ID)references Appointees (Name_ID);

alter table Nominations add constraint fk3_Nominations foreign key (Status_ID)references Status (Status_ID);

alter table Action_Log add constraint fk1_ActionLog foreign key (Action_ID)references Action_Category (Action_ID);

alter table Action_Log add constraint fk2_ActionLog foreign key (Appt_ID)references Nominations (Appt_ID);

alter table Action_Log add constraint fk3_ActionLog foreign key (Status_ID)references Status (Status_ID);

DROP:alter table Appointees drop constraint pk_Appointees;drop table Appointees;

alter table Board drop constraint pk_Board;drop table Board;

alter table Status drop constraint pk_Status;drop table Status;

alter table Action_Category drop constraint pk_ActionCategory;drop table Action_Category;

alter table Document_Type drop constraint pk_DocumentType;drop table Document_Types;

alter table Document drop constraint fk1_Document;alter table Document drop constraint fk2_Document;alter table Document drop constraint pk_Document;drop table Document;

alter table Nominations drop constraint fk1_Nominations;alter table Nominations drop constraint fk2_Nominations;alter table Nominations drop constraint fk3_Nominations;alter table Nominations drop constraint pk_Nominations;drop table Nominations;

alter table Action_Log drop constraint fk1_ActionLog;

Page | xxix

alter table Action_Log drop constraint fk2_ActionLog;alter table Action_Log drop constraint fk3_ActionLog;alter table Action_Log drop constraint pk_ActionLog;drop table Action_Log;

Page | xxx

REVISIONS LOG

Chapter 1 – Minor grammar editing Chapter 2 – Minor grammar editing

o Page 4, re-formatted and separated measures of success paragraphso Page 5, added Model of change diagram

Chapter 3 – Minor grammar editingo Page 11, added introduction for the chaptero Page 12, added President’s Office to 3 column quasi diagram description of the existing

processo Page 13, corrected errors in Figure 2 – Current Executive Appointments Process

Chapter 4 – Minor grammar editing in chapter introductiono Page 21 & 27, edited database design (took out Senate end and start date from

Nominations table)o Page 26 & 27, fixed few nullability errors

Page | xxxi