ADS Document

Assignment Title:

Group Assignment

Module Code and Title:

Advanced Database Systems (CE00332-3)

Intake Code:

GF1131COM / GF1171COM

Submitted To:

Mr. Thangavel Saravanan

Submitted By:

Prasanga Wadanambi (CB003340)

Nilushi Silva (CB003423)

Eeshwaren Veerabahu (CB003120)

Date Assigned:

22nd August 2011

Date Due:

7th October 2011

Advance Database Systems - Group Project GF1131COM / GF1171COM

Acknowledgment

It would be most appropriate first to have this opportunity to express our sincere thanks

for the people who guide and encourage throughout this project.

We sincerely thank our lecturer Mr. Thangavel Saravanan for all his support and passion

towards guiding us and providing assistance to clarify our doubts.

Next we sincerely thank our friends who had always been around to support us. Finally

would like to express or sincere gratitude for all people who gave their massive support

to make this project a success.

ii


Table of ContentsAcknowledgment...............................................................................................................ii

List of Figures...................................................................................................................vi

1 Introduction.....................................................................................................................1

1.1 Project Scenario........................................................................................................1

1.2 Assumptions.............................................................................................................2

2 Conceptual Modeling......................................................................................................3

2.1 Entity Relationship Diagram....................................................................................3

2.1 Relational Mode.......................................................................................................4

3 Normalization..................................................................................................................6

3.1 First Normal Form (1NF).........................................................................................6

3.2 Second Normal Form (2NF)....................................................................................6

3.3 Third Normal Form (3NF).......................................................................................7

4 Database Administration Strategies................................................................................8

4.1 Backup and Recovery Strategies..............................................................................8

4.2 Security Strategies....................................................................................................9

5 Database Features and Implementation.........................................................................10

5.1 Constraints..............................................................................................................10

5.2 Views......................................................................................................................14

5.3 Triggers..................................................................................................................14

5.4 Stored Procedures...................................................................................................15

5.5 Functions................................................................................................................17

5.5.1 User Defined Functions...................................................................................17

5.5.2 System Functions............................................................................................18

5.6 Transaction.............................................................................................................19

iii


6 Optimization Strategies.................................................................................................23

6.1 General Strategies..................................................................................................23

6.1.1 Containment of the result set of a query by only returning columns that are

necessary for the client rather than returning all the columns in a table..................23

6.1.2 Minimalize the usage of DISTINCT clause....................................................23

6.1.3 Include SET NOCOUNT ON statement in the Stored Procedures.................23

6.1.4 Usage of Cursors efficiently............................................................................24

6.1.5 The use of User Defined Function.............................................................24

6.1.6 Call objects using its fully qualified name......................................................24

6.1.7 Use stored procedures instead of heavy-duty queries.....................................24

6.2 Strategies Implemented By Means of Indexing.....................................................25

6.2.1 Clustered Index...............................................................................................25

6.2.2 Non-clustered Index...................................................................................25

6.3 Strategies Implemented When Designing Tables..................................................25

6.3.1 Importance on the usage of constraints rather than triggers, rules and defaults.

..................................................................................................................................25

6.3.2 Use of char or varchar in column instead of nchar or nvarchar......................26

6.3.3 Definition of Primary Key and Foreign Key relationships.............................26

6.3.4 Avoid using prefix “sp_” in the stored procedure name, where the stored

procedure is only intended to run in the master database........................................26

7 Strengths and Limitations..............................................................................................27

7.1 Strengths.................................................................................................................27

7.2 Limitations.............................................................................................................28

8 Queries..........................................................................................................................29

8.1 Query No.1.............................................................................................................29

8.2 Query No.2.............................................................................................................30

iv


8.3 Query No.3.............................................................................................................31

8.4 Query No.4.............................................................................................................32

8.5 Query No.5.............................................................................................................32

8.6 Query No.6.............................................................................................................33

8.7 Query No.7.............................................................................................................34

9 Validations....................................................................................................................36

10 Test Plan......................................................................................................................38

11 Conclusion...................................................................................................................42

12 Reference.....................................................................................................................43

13 Appendix.....................................................................................................................45

13.1 Workload Matrix..................................................................................................45

v


List of Figures

Figure 1: Entity Relationship Diagram..............................................................................3

vi

1 Introduction

1.1 Project Scenario

The solution developed is for a Malaysian company which revolves around important IT

related functions. The objective of the solution is to assist with the functions relating to

an IT Helpdesk, which would handle problems that might occur related to Computer

Hardware and Software within the company, which might cause a threat that will

interrupt the flow of IT systems functionality.

The most important task of the IT Helpdesk solution is to log and track the queries that

are directed at the IT Helpdesk. This information collected via this task will then be used

to as a reference for analysts to identify the overall performance and the efficiency of

both the equipments as well as the IT staff. The system would also provide the analysts

with information, which would allow them to determine whether the Helpdesk

specialists have sufficient resources to provide solution for problems in a given time

frame. A solution look up should be implemented by the system that would store

solutions for common problems, this solution look up will be used by the Helpdesk

Specialist as the main source of reference for arriving at solutions for problem, if a

problem pertains that has no solution in the solution look up ,the system is expected to

transfer, problem that could not be answered by the Helpdesk Specialist to an IT

Specialist, who then will analyze and solve the problem, while providing the Helpdesk

Specialist with an updated solution look up.


1.2 Assumptions

Discussed below are the assumptions that were made on the proposed database solution.

Operators are part of the organization as employees.

Equipment’s and Software within the organization is organized based o the

department they belong to.

Solution look up is only updated by the specialist one the problem had been

solved.

If a new solution is found to a peculiar problem, that problem type, sub problem

and problem that is under that sub problem is identified according to the

diagnosis of only the specialist assigned for the job.

Specialist are for a particular specialist defined as per the specialist reques .

2


2 Conceptual Modeling

2.1 Entity Relationship Diagram

3


Figure 1: Entity Relationship Diagram

The entities in the proposed ERD are Department, Employee, Caller, Specialist,

Operator, Specialist_Area, Software, Equipment, Call_Log, Problem, Solution,

Solution_Lookup, Problem_Type, Problem_ Assign, Reference_Problem. In the

proposed ERD, Employee entity is a generalized entity and Operator, Caller and

Specialist entities are derived and specialized entities of employee entity. And since each

employee belongs to one department there is 1-to-many relationship between Employee

entity and Department entity. There is 1-to-many relationship between Operator and

Call_Log entity, where one operator can create 1 or more call logs. And also there is a

many-to-many relationship between Specialist and Specialist_Area entities where one

specialist may belong to one or more specialist areas while one specialist area having

one or more specialists. Each unsolved problems in Problem entity have 1-to-1

relationship with Problem_Assign table while each problem problems in Problem entity

have 1-to-1 relationship with Equipment entity. Software and Equipment entities have

many-to-many relationship, since one software can be installed in many equipment’s

while one equipment may include one or more software in it.

2.1 Relational Mode

Department ( Dept_id , Dept_name)

Employee (Emp_id, Emp_name, Status, Emp_phone, Emp_mobile,

Emp_designation,Dept_id)

Caller (Caller_id , Emp_id)

Operator (Ope_id , Emp_id)

Specialist (Spe_id , Emp_id)

Specialist Area (Spe_area_id,Spe_area)

Specialist_Specialist Area (Specialist_area_id, Spe_id, Spe_area_id)

Call Log (Call_log_id, Call_type, Call_log_note, Count, Ope_id, Caller_id, Prob_id)

4


Problem (Prob_id, Prob_type, Prob_note, Prior_level, Prob_Status, Caller_id, Eqp_id,

Ope_id, Prob_type_id)

Equipment (Eqp_id, Eqptype, Eqp_made, Eqp_serial_number, Dept_id)

Equipment_Software (Sw_Eqp_id, Sw_id, Eqp_id)

Software (Sq_id, Sw_name, Sw_license)

Refference_Problem (Ref_id, Pre_Prob_id, Prob_id)

Problem Type (Prob_type_id, Prob_category, Sub_prob_type, Sub_sub_prob_type, Sub_sub_prob_prior_level, Default_duration, Spe_area_id)

Problem Assign (Assign_id, Assign_time, Spe_id, Prob_id)

Solution Lookup (Lookup_id, Prob_type, Sol_note, Duration, Prob_type_id)

Solution (Sol_id, Sol_note, Prob_id, Spe_id, Ope_id)

Solution Looup_Solution (Sol_lookup_id, Lookup_id, Sol_id)

5


3 Normalization

According to Coronel et. al (2010, p.175) normalization is a process of correcting the

table design, to minimize the data duplications and data redundancy which leads to

increase efficiency and flexibility of the data in a database.

3.1 First Normal Form (1NF)

The relations are in 1NF, when relations contain atomic values (one and only one value)

at each row and column.

In this scenario, Call_Log entity may contain multiple values the prob_id field when one

Call log refer to one or more problems. Therefore Call_Log_Problem table created.

Call_Log_Problem (Call_log_id, Prob_id, Count)

3.2 Second Normal Form (2NF)

A relation is in 2NF when;

It is in INF

Every non key attributes are fully functional dependent on the key

attributes (primary key).

(Stephens, 2008)

This ER design is already in first normal form (1NF) and all the non key attributes in

fully dependent on primary keys defined in each table. Therefore second normal form

(2NF) can be skipped.

Functional Dependencies

Functional dependencies of the tables are shown below;

FD1: Dept_id - > Dept_name

FD2: Emp_id - > Emp_name, Status, Emp_phone, Emp_mobile,

Emp_designation, Dept_id

6


FD3: Spe_area_id - >Spe_area

FD4: Call_log_id - > Call_type, Call_log_note, Ope_id, Caller_id, Prob_id

FD5: Prob_id - > Prob_type, Prob_note, Prior_level, Prob_Status, Caller_id,

Eqp_id, Ope_id, Prob_type_id

FD6: Eqp_id - > Eqptype, Eqp_made, Eqp_serial_number, Dept_id

FD7: Sq_id - > Sw_name, Sw_license

FD8: Ref_id - >Pre_Prob_id, Prob_id

FD9: Prob_type_id - >Prob_category, Sub_prob_type, Sub_sub_prob_type,

Sub_sub_prob_prior_level, Default_duration, Spe_area_id

FD10: Assign_id - > Assign_time, Spe_id, Prob_id

FD11: Lookup_id - > Prob_type, Sol_note, Duration, Prob_type_id

FD12: Sol_id - > Sol_note, Prob_id, Spe_id, Ope_id

3.3 Third Normal Form (3NF)

According to Elmasiri & Navathe (2011, p.366) a relation in Third Normal Form should

follow 2NF and it should not have transitive dependencies between non key attributes,

which simply means non key attributes should not functionally depend on another non

key attribute or set of attributes.

In-order to adhere to 3NF, the table structure should avoid transitive dependencies.

According to this table structure all the non key attributes are full functionally dependent

on key attributes (primary key) of each table and there no transitive dependencies

between non key attributes in each table. Therefore all the tables are in Third Normal

Form.

7


4 Database Administration Strategies

4.1 Backup and Recovery Strategies

It is important to have a backup and recovery strategy for each individual or business to

protect their data from data deletions, data corruption, device failures and natural

disasters. Therefore the database management system itself provides users to have their

own backup strategy by scheduling different types of backups as they required.

The strategy which we propose to take backups of the database can be shown as follows.

Task Backup Type Schedule

Partial Backup Differential backup Every week - Thursday

Full Backup Database backup Every week - Friday

Report Generation Reports Every Month

SQL Server Agent is the tool which we propose to schedule the backup strategy of this

system.

We have selected Full backup with Differential backup as our main strategy because,

“It is also good when the conditions are intermediate.

Each differential backup includes all the project files changed since the last full

backup.

It takes less time and space than "Always Full", but more than

"Full+Incremental”

Restoring is simpler than differential backup. “ (OrionSoftLab, 1999-2011)

8


4.2 Security Strategies

9


5 Database Features and Implementation

5.1 Constraints

Constraints are implemented to limit the data which is entered to the fields in a table. It

also ensures that consistency of data protected via primary key constraints and foreign

key constraints. These constraints can be assigned either with the table creation or either

as alteration to a created table.

(W3schools, 2011)

The constraints which are implemented in this proposed dataset are Primary Key,

Foreign Key, Not Null and Default.

PRIMARY KEY constraint

Primary key constraint offer uniquely identification of a record in a table. In the

proposed database every table in the database constraints with a primary key/ composite

keys to uniquely identify each record.

Following are some implementation of Primary Key constraint which is applied in the

proposed database.

//Creating table DepartmentCREATE TABLE Department( Dept_id int PRIMARY KEY IDENTITY(100,1),Dept_name varchar(100) Not Null);

//Creating table DepartmentCREATE TABLE Software(Sw_id varchar(50) PRIMARY KEY,Sw_name varchar(100) Not Null,Sw_license varchar(20) CHECK(Sw_license in('Yes','No')));

FOREIGN KEY constraint

The Foreign Key constraint is used to ensure referential integrity which means that the

relationship among each table remains consistent. Foreign Key is a field or set of fields

in the table which points out to a Primary Key field in another table.

10


Following are some implementation of Foreign Key constraint which is applied in the

proposed database.

//Primary key of Department table is the Foreign key of Equipment table CREATE TABLE Equipment(Eqp_id varchar(50) PRIMARY KEY,Dept_id int Not Null,Eqp_type varchar(100) Not Null,Eqp_made varchar(100),Eqp_serial_number varchar(100) Not Null,FOREIGN KEY(Dept_id) REFERENCES Department(Dept_id));

//Primary key of Employee table is the Foreign key of Specialist table CREATE TABLE Specialist(Spe_id int PRIMARY KEY IDENTITY,Emp_id varchar(20) Not Null,FOREIGN KEY(Emp_id) REFERENCES Employee(Emp_id));

NOT NULL constraint

NOT NULL constraint is basically used when field should require containing a value.

(enforces not to accept Null values). NOT NULL constraint is used is several fields in

the proposed database according to their necessity. Some implementation NOT NULL

constraints in the database are as follow:

//Equiment table CREATE TABLE Equipment(Eqp_id varchar(50) PRIMARY KEY,Dept_id int Not Null,Eqp_type varchar(100) Not Null,Eqp_made varchar(100),Eqp_serial_number varchar(100) Not Null,FOREIGN KEY(Dept_id) REFERENCES Department(Dept_id));

//Problem Assign table CREATE TABLE Problem_Assign(Assign_id int PRIMARY KEY IDENTITY,Prob_id varchar(50) Not Null,Spe_id int,Assign_time datetime,Assign_note nvarchar(225) ,FOREIGN KEY(Prob_id) REFERENCES Problem(Prob_id),FOREIGN KEY(Spe_id ) REFERENCES Specialist(Spe_id ));

11


DEFAULT constraint

DEFAULT constraint allows to populate an default value from the database when the

input source is null. Therefore the default value specified will be populated to all the

new insertions which a specific value is not specified. (W3schools, 2011)

DEFAULT constraint is used in several places is the database. The tables which have

used DEFAULT constraint are shown as follow:

//By default when a login account is created password is set to ‘123’ and later user will be able change as needed.

CREATE TABLE Login(User_name varchar(20) PRIMARY KEY,Emp_id varchar(20) ,User_type varchar(10) Not Null CHECK(User_type in('Specialist','Caller','Operator')),Pwd varchar(30) DEFAULT '123',FOREIGN KEY(Emp_id) REFERENCES Employee (Emp_id));

//For each for a specific problem by default at 1st call count is set to 0 and when a follow up call receives from a problem ID which is created earlir the count will be incremented.

CREATE TABLE Call_Log_Problem(Call_log_id varchar(30) ,Prob_id varchar(50) ,Count_occur int DEFAULT '0',PRIMARY KEY (Call_log_id,Prob_id),FOREIGN KEY(Prob_id)REFERENCES Problem(Prob_id));

CHECK constraint

CHECK constraint enforces limit the values which are inserted to a field in the database.

CHECK constraints offers validity of a value can be measured through a logical

expression.

The proposed database uses check constraints for validate mobile number filed, to

validate the status fields, to validate user types filed, to validate call type field and etc.

Following are some implementation of CHECK constraints which is applied in the

proposed database.

12


//Call type field is only required 3 types of values as mentioned belowCREATE TABLE Call_Log(Call_log_id varchar(30) PRIMARY KEY,Ope_id int Not Null,Caller_id int Not Null,Call_log_time datetime,Call_type varchar(15) CHECK(Call_type in('Follow-Up','New','Reference')),Call_log_note varchar(225),FOREIGN KEY(Caller_id) REFERENCES Caller(Caller_id),FOREIGN KEY(Ope_id ) REFERENCES Operator(Ope_id ));

//Software license field is only allows to 2 types of values as mentioned belowCREATE TABLE Software(Sw_id varchar(50) PRIMARY KEY,Sw_name varchar(100) Not Null,Sw_license varchar(20) CHECK(Sw_license in('Yes','No')));

//Mobile number field and the staus field have check constraints which will only allow specified values.CREATE TABLE Employee(Emp_id varchar(20) PRIMARY KEY ,Emp_name varchar(50),Status varchar(10) Not Null CHECK(Status in ('Yes', 'No')),Emp_phone nvarchar(20) ,Emp_mobile nvarchar(20) CHECK(Emp_mobile like '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'),Emp_designation varchar(50) Not Null,Dept_id int,FOREIGN KEY (Dept_id) REFERENCES Department(Dept_id));

13


5.2 Views

A virtual table which consists with columns from one or more tables is known as a view.

It stored in the database though the query of the table consists in an object in the same

database and derives it data from one or more tables.

As an example, below view query list all the equipments along with the department

name it belongs to.

ALTER VIEW EQPDEPT AS SELECT Dept_name, Eqp_type, Eqp_made FROM Department JOIN Equipment ON Department.Dept_id=Equipment.Dept_idGROUP BY Dept_name, Eqp_type, Eqp_made

SELECT * FROM EQPDEPT

5.3 Triggers

According to mysqltutorial.org (2008), trigger is a “statement or a set of SQL statements

which is stored to be activated or fired when an event associating with a database table

occurs”. The trigger can be fired for any event which could be for an Insert, Update, or

Delete. According to msdn.microsoft (2011) trigger also can be referred as stored

procedure due to the procedural format of the code. But the main difference of a trigger

compared to a stored procedure is that trigger is activated implicitly when event

performed in the specified table and stored procedure is explicitly to perform an activity.

According to msdn.microsoft (2011) triggers are mainly useful when implementing

business rules etc.

Check Solution

This trigger is implement for solution table in the database. When a solution is

inserted to the Solution table the trigger will get fired and it will update the problem

status in Problem table as 'yes'.

ALTER TRIGGER trig_SolutionON Solution FOR INSERTASDECLARE @probID varchar(50)SELECT @probID=Prob_id from inserted

14


UPDATE Problem SET Prob_status='Yes' WHERE Prob_id=@probID

Acknowledgment message

CREATE TRIGGER trig_I_SoftON Software FOR INSERTASBEGINPRINT 'New Software details has been updated'END

CREATE TRIGGER trig_I_EquipmentON Equipment FOR INSERTASBEGIN

PRINT 'New Equipment details has been updated'END

5.4 Stored Procedures

According to TechTarget (2000), stored procedure “is a set of structured query language

statements with an assigned name that's stored in the database in compiled form so that it

can be shared by a number of programs”. It is widely used structure because it can

control accessibility to data, improves productivity of the query and protects data

integrity.

Some of stored procedures which we have implemented in this system can be shown as

below.

Insert values to Software table

The given stored procedure gets values from user and inserts into the Software table.

ALTER PROCEDURE proc_Software (@softName varchar(100),@softLicence varchar(20))AS

DECLARE @sftID varchar(50)DECLARE @temp int

SELECT @temp=Convert(int,substring(Max(Sw_id), 3,10)) FROM SoftwareSET @temp = @temp+ 1;SET @sftID = 'SW' + Convert(varchar(20), @temp);

INSERT INTO Software VALUES (@sftID,@softName,@softLicence)

15


Example of Stored Procedure Execute query

EXEC proc_Software 'Micsdrosoft Office','No'

Add a new problem to Problem Table

This query takes values from user to validate the user entered data with other tables

before insert a new set of data to the Problem table.

ALTER PROCEDURE proc_NewProblem(@logID varchar(50),@callerID int,@eqID varchar(50),@opeID int,@probTypeID varchar(50), @note varchar(225),@level int,@refStatus varchar(10),@probStatus varchar(10),@callType varchar(50),@refProbID varchar(50),

@probID varchar(50) output)AS

DECLARE @temp int,@eqpNewID varchar(50)SELECT @temp=Convert(int,substring(Max(Prob_id), 3,10)) FROM ProblemSET @temp = @temp+ 1;SET @probID = 'PR' + Convert(varchar(20), @temp);

IF(@callType='New')BEGIN

INSERT INTO Problem VALUES (@probID ,@callerID,@eqID,@opeID,@probTypeID,@note,@level,@refStatus,@probStatus)

ENDELSE if (@callType='Reference')BEGIN

SELECT @eqpNewID=Eqp_id from Problem where Prob_id=@refProbIDINSERT INTO Problem VALUES (@probID

,@callerID,@eqpNewID,@opeID,@probTypeID,@note,@level,@refStatus,@probStatus)INSERT INTO Reference_Problem VALUES (@probID ,@refProbID)

ENDINSERT INTO Call_Log_Problem (Call_log_id,Prob_id) VALUES(@logID,@probID)PRINT 'New Prroblem created successfully !';

16


5.5 Functions

Functions are mostly used to run frequently used logics. According to msdn.microsoft

(2011) there are mainly two types of functions as built-in functions and as user defined

functions. System functions are sub part of built-in functions in SQL server. The

function. The functions which have implemented in the proposed database are

mentioned as follow:

5.5.1 User Defined Functions

User defined functions are defined by the user and in-order to create functions user need

to get granted appropriate permissions.

Selected function which has implemented in the proposed database are as follow:

//This function is used to returns the problem resolved date and time if the problem is

resolved.

CREATE FUNCTION dbo.function_Resolve(@probID varchar(30))RETURNS datetimeAS BEGINDECLARE @time datetimeIF Exists (SELECT * FROM Problem WHERE Prob_status='Yes' AND Prob_id=@probID)SELECT @time=Resolve_time FROM Solution WHERE Prob_id=@probIDELSE SET @time='-'RETURN @timeEND

//This function is used in-order calculate the average resolve time of a specific problem

CREATE FUNCTION dbo.function_Duration(@typeID AS varchar(100)) RETURNS floatAS BEGINDECLARE @avgTime floatIF exists (SELECT Duration FROM Solution_Lookup WHERE Prob_type_id=@typeID)SELECT @avgTime=AVG(Duration) FROM Solution_Lookup WHERE Prob_type_id=@typeIDELSESELECT @avgTime=Default_duration FROM Problem_Type WHERE Prob_type_id=@typeID

RETURN @avgTimeEND

17


5.5.2 System Functions

System functions are functions which is pre-defined functions that are offered by the

SQL Server.

Function Purpose

GetDate () Get the current date time

Dateadd Add two dates

DatepartReturns the specified partpart of the

specified date.

18


5.6 Transaction

In the system, transactions are used in most queries where it required a rollback process

to restore the database into previous state. It is required to overcome issues occur due to

execution of invalid queries.

As an example, adding an employee is a task which requires the data insertion for

multiple tables. When an employee registers with the system, the data also need to insert

into Employee, Login and Caller/Specialist/Operator. If the process fails within that

duration, the database needs to rollback to its previous state. Therefore transaction

required in order to overcome such scenarios.

Given below are examples of transactions which we used in this system.

Add new Employee

This query inserts a new employee into the employee table as well as creates a login in

the Login table and adds the employee into table according to the user type.

ALTER PROCEDURE proc_NewEmployee (@empName varchar(50),@depName varchar(100), @empPhone nvarchar(20),@empMobile nvarchar(20),@empDesignation varchar(50),@userType varchar(10))AS

DECLARE @empID varchar(20)DECLARE @temp intDECLARE @depID int

BEGIN TRANSACTIONBEGIN TRY

SELECT @temp=Convert(int,substring(Max(Emp_id), 2,10)) FROM Employee

SET @temp = @temp+ 1;SET @empID = 'E' + Convert(varchar(20), @temp);

SELECT @depID=Dept_id FROM Department WHERE Dept_name=@depName

INSERT INTO Employee VALUES (@empID,@empName,'Yes',@empPhone,@empMobile,@empDesignation,@depID)

INSERT INTO Login (User_name,Emp_id,User_type) VALUES(@empID,@empID,@userType)

IF (@userType='Caller')INSERT INTO Caller (Emp_id) values(@empID)

ELSE IF (@userType='Specialist')INSERT INTO Specialist (Emp_id) VALUES(@empID)

ELSE

19


INSERT INTO Operator (Emp_id) VALUES(@empID)

PRINT 'New Employee created successfully !';COMMIT

END TRY

BEGIN CATCHRAISERROR ('Error adding the data values.Please check your inputs', 16,1 );

ROLLBACKEND CATCH

Add a New Call

This query creates a call log in the Call log table and creates a problem in Call Log

Problem table with using the id of call log table to make the connection between Call log

and Problem tables.

ALTER PROCEDURE proc_NewCall(@empID_Operator varchar(50),@empID_Caller varchar(50),@callType varchar(50), @callLogNote nvarchar(20),@eqpID varchar(100),@probTypeID varchar(20),@note varchar(225),@level int,@followProbID varchar(50),@refID varchar(50))AS


DECLARE @temp int,@opeID int, @callerID int,@count int,@logDate_Time datetime,@logID varchar(50),@probID varchar(50),@refStatus

varchar(10),@probStatus varchar(10)

SELECT @temp=Convert(int,substring(Max(Call_log_id), 4,10)) FROM Call_Log

SET @temp = @temp+ 1SET @logID = 'LOG' + Convert(varchar(20), @temp)

SELECT @logDate_Time=GETDATE()SELECT @callerID=Caller.Caller_id FROM Caller,Employee WHERE

Caller.Emp_id=Employee.Emp_id AND Employee.Status='Yes' AND Caller.Emp_id=@empID_CallerSELECT @opeID=Ope_id FROM Operator WHERE

Emp_id=@empID_Operator

INSERT INTO Call_Log VALUES (@logID ,@opeID,@callerID,@logDate_Time,@callType,@callLogNote)

PRINT 'Log created successfully !';

IF(@callType='New')BEGIN

SET @refStatus ='No'SET @probStatus='No'

20


EXEC proc_NewProblem @logID,@callerID,@eqpID,@opeID,@probTypeID,@note,@level,@refStatus,@probStatus,@callType ,@refID, @probID OUTPUT

ENDELSE IF (@callType='Follow-Up')BEGIN

SELECT @count=MAX(Count_occur) from Call_Log_Problem where Prob_id=@followProbID

SET @count = @count+ 1;

INSERT INTO Call_Log_Problem VALUES(@logID,@followProbID,@count)

ENDELSEBEGIN

SET @refStatus ='Yes'SET @probStatus='No'EXEC proc_NewProblem

@logID,@callerID,@eqpID,@opeID,@probTypeID,@note,@level,@refStatus,@probStatus,@callType ,@refID, @probID OUTPUT

ENDPRINT 'Call successfully created !'COMMIT

END TRY

BEGIN CATCHRAISERROR ('Error adding the data values.Please check your inputs', 16,1 );ROLLBACK

END CATCH

Add a New Solution

This query inserts a set of data into solution table as well as to

Solution_Lookup_Solution table while using sol_id as the foreign key.

CREATE PROCEDURE proc_NewSolution (@empID_Updater varchar(50),@probID varchar(50),@lookupID varchar(50),@solNote varchar(225))AS


DECLARE @speID intDECLARE @opeID intDECLARE @solID intDECLARE @empType varchar(50)DECLARE @resolveTime datetime

SELECT @empType=User_type FROM Login WHERE Emp_id=@empID_Updater

21


IF (@empType='Specialist')BEGINSELECT @speID=Spe_id FROM Specialist where Emp_id=@empID_UpdaterENDELSE IF (@empType='Operator')BEGINSELECT @opeID =Ope_id FROM Operator where

Emp_id=@empID_UpdaterENDELSEBEGIN PRINT 'Operator ID or Specialist ID Not Found !' END

INSERT INTO Solution(Prob_id,Ope_id,Spe_id,Sol_note,Resolve_time) VALUES (@probID,@opeID,@speID,@solNote,GETDATE())

SELECT @solID=Sol_id from Solution where Prob_id=@probIDINSERT INTO Solution_Lookup_Solution (Lookup_id,Sol_id) VALUES

(@lookupID,@solID)

END TRY

BEGIN CATCHRAISERROR ('Error adding the data values.Please check your inputs', 16,1 );ROLLBACK

END CATCH

22


6 Optimization Strategies

As the name suggests Optimization Strategies are advanced techniques for efficient

server or database management. It is important that efficient management of the

database or server is addressed since; adopting these management techniques to optimize

a database will greatly satisfy the ever evolving IT infrastructure and network traffic.

Hence the following part of this report will discuss the Optimization strategies that are

very important for database optimization as well as the optimization strategies that we

implemented in developing this database.

6.1 General Strategies

6.1.1 Containment of the result set of a query by only returning columns that are

necessary for the client rather than returning all the columns in a table.

This strategy benefits by resulting in better performance of the server since, the server

needs to only return particular columns to the client. This strategy effectively reduces

the network traffic and also boosts the performance of the query. The proposed solution

implements this strategy to a considerable extent where most queries designed by us

return only columns that are crucial for the requirements of the client.

6.1.2 Minimalize the usage of DISTINCT clause.

Usage of DISTINCT clauses have been known to degrade the performance, hence the

usage of DISTINCT clauses have been minimalized in the provided salutation. Although

in some scenarios DISTINCT clauses were used to contain the unwanted retrieval of

columns when using the COUNT(*) function.

6.1.3 Include SET NOCOUNT ON statement in the Stored Procedures.

Adopting this statement in stored procedure can reduce the network traffic, since it stops

the constant acknowledgment message that the server out puts, every time a row gets

affected by a T-SQL statement. This strategy was taken into consideration when

building the stored procedures for the given solution.

23


6.1.4 Usage of Cursors efficiently.

Cursors degrade the server’s performance, compared to select statement. They cause

massive over heads, since they make people apply a procedural mindset to a set based

environment. The proposed solution does not completely avoid cursors since cursors are

able to fetch any row of data from a result set without fetching the entire row of data

from the result set. Due to this one cannot completely write off cursors as inefficient, by

applying cursors in only required places in the solution give, we have understood, that

cursors are very efficient if used properly.

6.1.5 The use of User Defined Function

User Defined Function’s (UDFs) encapsulate a number of T-SQL statements, which can

be used again. This allows for reduced network traffic and code reusability. The

proposed solution uses UDFs to encapsulate T-SQL that helps to filter the result set in a

custom way.

6.1.6 Call objects using its fully qualified name.

This Optimization technique makes a significant contribution to Database Optimization.

When called by its full name which has four identifiers (server name, database name,

owner name and object name) an object in the server can react faster, in a situation

where there are multiple databases and owners, because calling an object by its full

name eliminates any confusion. Since when developing this solution, there were not

many databases in the server, hence it was identified that this optimization technique

will not make a significant difference.

6.1.7 Use stored procedures instead of heavy-duty queries.

Using stored procedure allows for reduced network traffic, because by implementing

stored procedure in the proposed solution we believe that the user; now needs to only

relay the stored procedure he wants to execute along with the parameters for that given

stored procedure hence this strategy allows for users to avoid using, complicated and

heavy resource consuming queries.

o Security aspect of using stored procedure

Stored Procedures can also be used to apply security measures by means

of designating users with the permission to use certain stored procedures

24


that deal with restricted data. Even though we haven’t implemented this

feature being that we have a number of important stored procedures, it is

very important this was highlighted under this topic.

6.2 Strategies Implemented By Means of Indexing

Indexing allows for data to be retrieved from the database, far quickly than when data in

the database is not indexed. Considering a situation where there are thousands of data in

a table, indexing will allow for the server to obtain information based on a particular

order. This allows us to obtain results faster. Indexes are of two types

6.2.1 Clustered Index

Clustered index makes sure that all the data in a particular table where indexing is

applied is ordered in that particular order, which enables the retrieval and grouping of

data efficient and fast. The use of Clustered index in the proposed solution was ensured

by the use of defining a primary key column in all tables. This helped to retrieve data

fairly quickly when using queries that incorporate data from multiple tables.

6.2.2 Non-clustered Index

Non - Clustered Index allows for ordering the records in a logical manner.

6.3 Strategies Implemented When Designing Tables

When designing tables for the proposed database the following optimization strategies

were used.

6.3.1 Importance on the usage of constraints rather than triggers, rules and

defaults.

Constraints were used when designing tables for the proposed database, since constraints

prove to be more efficient that triggers. Also constraints are more consistent and reliable

compared to triggers, rules and defaults; since hand coding errors can be made when

25


trying to replicate those actions of constraints by using above mentioned alternative

methods. Constraints also boost performances to better levels.

6.3.2 Use of char or varchar in column instead of nchar or nvarchar.

This strategy directly evaluates the optimization of the storage of the database. When

designing tables for the proposed database, we concluded that it was best to use char or

varchar columns and only use nchar or nvarchar columns when there’s a need for storing

Unicode data. This decision was taken, since char or varchar values only uses one byte

to store a character, whereas nvarchar and nchar uses two bytes to store a single

character. By applying this strategy we were able to design tables with columns that

would use two times less storage.

6.3.3 Definition of Primary Key and Foreign Key relationships.

Primary keys and foreign keys were added to the table to uniquely identify each row of

the table. Defining the primary key of a table allows for the creation of a clustered index,

which is unique to that table, this essentially makes the queries execute faster. Defining

the foreign key, allows for faster execution of queries which make use of the

participation of multiple tables.

6.3.4 Avoid using prefix “sp_” in the stored procedure name, where the stored

procedure is only intended to run in the master database.

It is advised that the prefix “sp_” needs to be only used for when the stored procedure is

meant to run in databases other than the master data base, because using this prefix can

result in the server searching for a stored procedure beginning with “sp_”. This can

affect the execution time of the stored procedure negatively. This technique was used by

us, since we completely refrained from using this prefix, since the need to use this prefix

didn’t present itself, since there were no situations where a stored procedure needed to

be executed out of the master database.

26


7 Strengths and Limitations

The database solution provided, has Strengths that enhance the overall efficiency of the

database in the contrary, it also has limitations which if it had been addressed, could

have enhanced the database solution even further. Below is a list of key strengths and

limitations of this database solution.

7.1 Strengths

The database solution provided, has been developed in such a manner that,

measures with regard to assuring the relationships between tables are generalized

as well as specialized to obtain consistent and redundant free data.

Data has been Normalized up to 3rd normal form to support the strength

discussed above as well as achieve a clear view of the business logic from the

perspective of the system.

Accuracy level is high with the information entered into the system, since

validity of information has been achieved via the use of strict constraints

implemented within tables.

User Friendliness has been give great importance in the system by means of

requiring very little effort from the users to invoke functions. This is done by

automating the invoking of the function by methods such as stored procedure,

Triggers and user defined functions.

Views and reports were used to allow the user to obtain information in an

organized manner.

27


7.2 Limitations

Non-Clustered indexes which could have proven to be very useful in increasing

the efficiencies of queries was not used,

Problem types are not addressed In-depth; this could prove to reduce the

exclusivity of a problem.

Problem is solved by problem level rather than first come first serve basis, which

would be the ideal when considering a large IT company.

28


8 Queries

8.1 Query No.1

Create a query to show which users have called more than twice within a week’s time at

any time during the last year, along with the specialist name assigned for the job.

--Call_log_time

CREATE FUNCTION dbo.ufnweekyearcheck(@date datetime) RETURNS bitAS BEGIN

DECLARE @handles bitDECLARE @vardate datetimeDECLARE @weeknum datetimeDECLARE @currentyear datetimeDECLARE @lastyear datetime

SET @weeknum = datepart(wk,@date) SET @currentyear = datepart(dy,@date)SET @lastyear = @currentyear -(@currentyear+364)

-- Identifies any calls made within the date criteria and pattern IF exists (SELECT * FROM Call_Log WHERE @date = convert(varchar(10),datepart(wk,@date))AND @date BETWEEN convert(varchar(10),@lastyear) AND convert(varchar(10),@currentyear))

SET @handles= 1

ELSE

SET @handles= 0

RETURN @handles

END

--Caller_id CounterCREATE FUNCTION dbo.ufncountcheck(@callid int) RETURNS bit ASBEGIN

DECLARE @cnthandles bit

--Counts Number of times a caller has called and compares whether the number is greater than 1IF exists (SELECT COUNT(*)cnt FROM Call_Log WHERE Caller_id = @callid Group by Call_log.Caller_id Having COUNT (*) >1)

SET @cnthandles = 1

29


ELSE

SET @cnthandles = 0

RETURN @cnthandles

END

SELECT Call_Log.Caller_id AS 'Caller ID', Call_Log.Call_log_time Group by Call_Log.Caller_id AS 'Dates on Which Calls were Made', Call_Log_Problem.Prob_id +' | '+ Problem_Assign.Assign_id AS 'Problem ID & Assign ID', Specialist.Emp_id +' | '+ Employee.Emp_name AS 'Specialist Emp ID & Name' FROM Call_Log,Call_Log_Problem,Problem_Assign,Specialist,EmployeeWHERE Call_Log.Call_log_id = Call_Log_Problem.Call_log_id AND Call_Log_Problem.Prob_id = Problem_Assign.Prob_id AND Problem_Assign.Spe_id = Specialist.Spe_id AND Specialist.Emp_id = Employee.Emp_id AND dbo.ufnweekyearcheck(Call_Log.Call_log_time)='1' AND dbo.ufncountcheck(Call_Log.Caller_id)

8.2 Query No.2

Create a query to display a list of problem types along with the number of specialists available for each type.

Select Problem_type.Prob_type_id AS 'Problem Type ID', 'Error or Breakdown in' +' '+ Problem_type.Prob_category +' '+ Problem_Type.Sub_prob_type +' '+ Problem_Type.Sub_sub_prob_type AS 'Problem Category', Problem_type.Spe_area_id AS 'Specialist Area ID',Specialist_Area_Specialist.Spe_id AS 'Specialist ID'FROM Problem_Type,Specialist_Area_Specialist,SpecialistWHERE Problem_Type.Spe_area_id=Specialist_Area_Specialist.Spe_area_id AND Specialist_Area_Specialist.Spe_id=Specialist.Spe_id

30


8.3 Query No.3

Create a query which shows, the status of each call, received during the last week. The

date and the time of resolving the issue should be displayed for resolved issues.

--returns the last durationCREATE FUNCTION dbo.function_Time(@logID varchar(30),@date datetime) RETURNS bitAS BEGINDECLARE @status bitDECLARE @TodayDayOfWeek intDECLARE @EndOfPrevWeek datetimeDECLARE @StartOfPrevWeek datetime --get number of a current day (1-Monday, 2-Tuesday... 7-Sunday)SET @TodayDayOfWeek = datepart(dw, GetDate())--get the last day of the previous week (last Sunday)SET @EndOfPrevWeek = dateadd(dd, -@TodayDayOfWeek, GetDate())--get the first day of the previous week (the Monday before last)SET @StartOfPrevWeek = dateadd(dd, -(@TodayDayOfWeek+6), GetDate())

IF exists (SELECT * FROM Call_Log WHERE @date BETWEEN CONVERT(varchar, @StartOfPrevWeek,7) AND CONVERT(varchar, @EndOfPrevWeek+1,7) AND Call_log_id=@logID)SET @status= 1ELSE SET @status= 0RETURN @statusEND

--returns the problem resolved date and time if the problem is resolvedCREATE FUNCTION dbo.function_Resolve(@probID varchar(30))RETURNS datetimeAS BEGINDECLARE @time datetimeIF Exists (SELECT * FROM Problem WHERE Prob_status='Yes' AND Prob_id=@probID)SELECT @time=Resolve_time FROM Solution WHERE Prob_id=@probIDELSE SET @time='-'RETURN @timeEND

SELECT Call_Log.Call_log_id AS 'Call Log ID',Call_Log.Call_log_time AS 'Call Log Date and Time' ,Problem.Prob_id AS 'Problem ID',Problem.Prob_status as 'Problem Status',dbo.function_Resolve( Problem.Prob_id) AS 'Problem Resolved Date and Time' FROM Call_Log,Problem,Solution,Call_Log_Problem WHERE Solution.Prob_id=Problem.Prob_id AND Call_Log.Call_log_id=Call_Log_Problem.Call_log_id AND Call_Log_Problem.Prob_id=Problem.Prob_id AND dbo.function_Time(Call_Log.Call_log_id,Call_Log.Call_log_time)='1' AND Call_Log.Call_type='New'

31


8.4 Query No.4

Create a query which lists the problem types n order of increasing average time to

resolve.

CREATE FUNCTION dbo.function_Duration(@typeID AS varchar(100)) RETURNS floatAS BEGINDECLARE @avgTime floatIF exists (SELECT Duration FROM Solution_Lookup WHERE Prob_type_id=@typeID)SELECT @avgTime=AVG(Duration) FROM Solution_Lookup WHERE Prob_type_id=@typeIDELSESELECT @avgTime=Default_duration FROM Problem_Type WHERE Prob_type_id=@typeID

RETURN @avgTimeEND

SELECT Prob_type_id AS 'Problem Type ID',Prob_category AS 'Main Catergory',Sub_prob_type AS 'Problem Category',Sub_sub_prob_type AS 'Sub Problem Category', dbo.function_Duration(Prob_type_id) AS 'Average Resolve Time' FROM Problem_Type

8.5 Query No.5

Create a query which provides, for each call received during the last month, the total

number of calls/follow up calls received, the problem type, and assigned specialist.

CREATE FUNCTION [dbo].[ufnTimePeriod] ( ) RETURNS INTASBEGIN

-- Declaration of the return variableDECLARE @handlecount intDECLARE @currentdate datetimeDECLARE @date4weeksprior datetime

SET @currentdate = GETDATE()-- Identifies the date 4 weeks prior to current date by

substracting 28 days from current date SET @date4weeksprior = @currentdate-28

-- Checking if their are record that exist that meet the criteria "calls handled by operators within current date and 4 weeks prior to current date"

IF exists (SELECT * FROM Call_Log WHERE Call_log_time BETWEEN @date4weeksprior AND @currentdate)

SET @handlecount = 1 ELSE

32


SET @handlecount = 0RETURN @handlecount

END

SELECT Call_Log_Problem.Prob_id as 'Problem ID',Call_Log_Problem.Call_log_id as 'Call Log ID',Employee.Emp_id as 'Specialist ID' ,Employee.Emp_name as 'Specialist Name' ,Call_Log_Problem.Count_occur as 'Occurance of the Call'

from Call_Log, Call_Log_Problem,Problem,Problem_Assign,Specialist,Employee

where Call_Log_Problem.Call_log_id=Call_Log.Call_log_id AND Call_Log_Problem.Prob_id=Problem.Prob_id AND Problem.Prob_id=Problem_Assign.Prob_id AND Problem_Assign.Spe_id=Specialist.Spe_id AND Specialist.Emp_id=Employee.Emp_id

ANDdbo.ufnTimePeriod()='1'

8.6 Query No.6

Create a query which shows the number of calls handled by each operator during the last 4 weeks.

CREATE FUNCTION [dbo].[ufnTimePeriod] () RETURNS INTASBEGIN

-- Declaration of the return variableDECLARE @handlecount intDECLARE @currentdate datetimeDECLARE @date4weeksprior datetime

SET @currentdate = GETDATE()SET @date4weeksprior = @currentdate-28

IF exists (SELECT * FROM Call_Log WHERE Call_log_time BETWEEN @date4weeksprior AND @currentdate)

SET @handlecount = 1 ELSESET @handlecount = 0

RETURN @handlecount

END

SELECT Ope_id as 'Operator ID',COUNT(*) as 'No of calls Recieved' from Call_Log where dbo.ufnTimePeriod()=1 group by Ope_id

33


8.7 Query No.7

Develop one additional query which provides information that would be useful for the business.

The reports are implemented under this section. The reports are as follow:

Identifying the specialist areas which problems belongs most

This report displays the specialist areas which problems are made most. With the

use of this report, authorized users of the company will be able to allocate more

specialists for those specialist areas to increase the efficiency.

SELECT Specialist_Area.Spe_area AS 'Speccialist Area',COUNT(*) AS 'No total Problems'

FROM Problem,Problem_Type,Specialist_Area WHERE Problem.Prob_type_id=Problem_Type.Prob_type_id

AND Problem_Type.Spe_area_id=Specialist_Area.Spe_area_id GROUP BY Specialist_Area.Spe_area ORDER BY 'No

total Problems' DESC

The departments which creates problems most

This report displays the departments which creates problems in the Help Desk.

Through is report authorized users of the company will be able to give more

consideration to those departments in-order to solve problems which arries most

in those departments.

SELECT Department.Dept_name AS 'Deparment Name', COUNT (*) as 'No of Problems'

FROM Department,Employee,Caller,Problem WHERE Department.Dept_id = Employee.Dept_id AND

Employee.Emp_id = Caller.Emp_id AND Caller.Caller_id=Problem.Caller_id

GROUP BY Department.Dept_name ORDER BY 'No total Problems' DESC

The Equipment’s which generates problems most

This report reffered to equipments which creates problems in the Help Desk.

With use of this report authorized users of the company will be able to give more

consideration to track those equipments.

34


SELECT Equipment.Eqp_type AS 'Equipment Type', COUNT (*) AS 'No of Problems'

FROM Equipment,Department,Employee,Caller,Problem WHERE Equipment.Dept_id = Department.Dept_id AND

Department.Dept_id = Employee.Dept_id AND Employee.Emp_id = Caller.Emp_id AND Caller.Caller_id=Problem.Caller_id

GROUP BY Equipment.Eqp_type

35


9 Validations

Employee status can only be set as ‘Yes’ or ‘No’

Status varchar(10) Not Null CHECK(Status in ('Yes', 'No')),

Employee mobile number only can have numbers in a length of 11digits

Emp_mobile nvarchar(20) CHECK(Emp_mobile like '[0-9][0-9][0-9][0-9][0-9][0-9][0-

9][0-9][0-9][0-9][0-9]'),

'Specialist','Caller' and 'Operator' are only User types that can have on Login

table

User_type varchar(10) Not Null CHECK(User_type in('Specialist','Caller','Operator')),

Call type of the call log table can only have type 'Follow-Up’ or 'New' or

'Reference'

Call_type varchar(15) CHECK(Call_type in('Follow-Up','New','Reference')),

Software license in Software table can only have values ‘Yes’ or ‘No’

Sw_license varchar(20) CHECK(Sw_license in('Yes','No'))

Reference status in problem table can only have values ‘Yes’ or ‘No’

Ref_status varchar(10) CHECK(Ref_status in('Yes','No')),

Problem status in problem table can only have values ‘Yes’ or ‘No’

Prob_status varchar(10) Not Null CHECK(Prob_status in('Yes','No')),

Exception Handling

Ex: ALTER PROCEDURE proc_AssignProblem(@probID varchar(50),@empID_Specialist

varchar(30),@assignNote varchar(225))

AS

BEGIN TRY

DECLARE @speID int,@speName varchar(100)

SELECT @speID=Spe_id FROM Specialist WHERE Emp_id=@empID_Specialist

SELECT @speName=Emp_name FROM Employee WHERE

Emp_id=@empID_Specialist

INSERT INTO Problem_Assign VALUES

(@probID,@speID,GETDATE(),@assignNote)

36


PRINT 'Problem successfully assigned to Specialist '+ @speName

END TRY

BEGIN CATCH

RAISERROR ('Error adding the data values.Please check your inputs', 16,1 );

END CATCH

37


10 Test Plan

Employee Registration

Table 1: Test plan for Employee Registration

Test Case Expected Result Actual Output

1 Possibility of inserting

numeric values to Employee

name, Department name

and etc. fields.

Should display message

“Numeric Values Cannot be

Added”

Message displayed “Numeric

Values Cannot be Added”

2 Inserting different data to

Department name field


“Invalid data”

Message displayed “Invalid

data”

3 Inserting 11 or more digits

to the Phone number


“Invalid Phone Number”


Phone Number”

4 Inserting different

designation type


“Invalid input.”


input.”

5 Successfully register a

employee

Should display message “ New

Employee created

successfully”

Message displayed “ New

Employee created

successfully”

6 Occurrence of any other

error

Should display message “

Error adding the data

values.Please check your

inputs”

Message displayed “ Error

adding the data values.Please

check your inputs”

38


Add a Problem

Table 2: Test plan for Add a Problem


1 Inserting different data for

the Call type field




inputs ”



check your inputs ”

2 Switching tables by

selecting Call type as new.

If it is a new call it should

allow adding problem details.

Allows the user to add new

problem details.

3 Switching tables by

selecting Call type as

follow-up or reference.

Should allow searching

previous problems

Allows the user to check

previous problem details

4 Leaving empty or inserting

different value to problem

status field




inputs ”




5 Inserting character to

priority level field




inputs ”




6 Successfully adds a problem Should display message “

New Problem created

successfully”


Prroblem created

successfully”

39


Add a Solution

Table 3: Test Plan for Add a Solution



Operator id, Problem id

fields.




inputs ”




2 Inserting values from

different format to the

Resolve time field.

Should display message “Enter

values in following format

hr:mn:s yy/mm/dd”

Message displayed “Enter

values in following format

hr:mn:s yy/mm/dd”

3 Successfully add a solution Should display message “

New Solution added

successfully”


Solution added successfully”

Add a Solution Lookup

Table 4: Test plan for Add a Solution Lookup



Problem type fields.

(Type that are not available

in the Problem Type table)




inputs ”





Specialist id fields.

(Type that are not available

in the Specialist table).




inputs ”




3 Inserting character value for

the float value


“Insert a float value”

Message displayed “Insert a

float value”

4 Successfully add a Problem

Lookup


New Problem Lookup added


Problem Lookup added

40


successfully” successfully”

41


11 Conclusion

This project takes consideration of database functionalities of an automated helpdesk

system. The system database and related features of the database has created with use of

Microsoft SQL Server 2005. The proposed database design has addressed all the key

areas which could be able to cause data duplications and efficiency problems.

In-order to maintain the consistency of proposed Help desk database, the Entity

Relationship Diagram (ERD) which creates at the initial stage was normalized. The

normalized table structure ensures the logical relationships are in correct. Therefore the

table structure is mainly developed based on the ER diagram. Considering possibilities

of user inputs, the fields in the table structure of the database are validated with use of

constraints. These constraints will make sure that no invalid data is been entered to any

table.

Optimization of a database is an essential factor when considering of databases. It is

more required when large dataset is available. Therefore in this project optimization

strategies of a database is considered and several strategies are implemented in-order to

increase the efficiency and performance of the query retrieval.

The other main features which are implemented in this project are transactions, triggers,

views and stored procedures. If these features applied according to their necessity, these

features may enhance the performance of the database transactions. In this project

considering all the necessity, the key features are implemented. And finally the proposed

database solution for Help desk system is tested in-order to ensure that all the required

requirements met.

42


12 Reference

Coronel, C., Morris, S. & Rob, P. (2010). Database systems: design,

implementation, and management. [Online] USA: Cengage Learning, Available

from:http://books.google.lk/books?

id=vX_KShZ95L8C&pg=PA175&dq=what+is+normalization:

+pdf&hl=en&ei=hM6NTrGbD8r4rQeux4ifAQ&sa=X&oi=book_result&ct=resu

lt&resnum=10&ved=0CF8Q6AEwCQ#v=onepage&q=what%20is

%20normalization%3A%20pdf&f=false [Accessed: 3rd October 2011]

Elmasiri, R. & Navathe, S.B. (2011), Fundamentals of Database Systems,

[Online] India: Dorling Kindersley, Available from:

http://books.google.lk/books?id=uq-

FjVEBxtgC&pg=PA366&dq=what+is+3NF+normalization&hl=en&ei=BgKOT

uDyA4HwrQeHpNmHAQ&sa=X&oi=book_result&ct=result&resnum=10&ved

=0CF8Q6AEwCQ#v=onepage&q=what%20is%203NF

%20normalization&f=false [Accessed: 6th October 2011]

Mysqltutorial.org (2008), Introduction to SQL Triggers [Online]. Available

from: http://www.mysqltutorial.org/sql-triggers.aspx [Accessed: 1st October

2011]

OrionSoftLab. (2009-2011). Which backup mode to use [Online] Available

from: http://www.orionsoftlab.com/backup/incremental%20backup.htm

[Accessed: 1st October 2011]

Stephens, R. (2008). Beginning Database Design Solutions , [Online] USA:

John Wiley and Sons , Available from: http://books.google.lk/books?

id=qGgpYBighBcC&pg=PA137&dq=what+is+normalization&hl=en&ei=Hs-

NTp2bE4qyrAeM-

5GeAQ&sa=X&oi=book_result&ct=result&resnum=2&ved=0CDQQ6AEwAQ#

v=onepage&q=what%20is%20normalization&f=false [Accessed: 5th October

2011]

43

http://books.google.lk/books?id=qGgpYBighBcC&pg=PA137&dq=what+is+normalization&hl=en&ei=Hs-NTp2bE4qyrAeM-5GeAQ&sa=X&oi=book_result&ct=result&resnum=2&ved=0CDQQ6AEwAQ#v=onepage&q=what%20is%20normalization&f=false



http://www.orionsoftlab.com/backup/incremental%20backup.htm

http://www.mysqltutorial.org/sql-triggers.aspx

http://books.google.lk/books?id=uq-FjVEBxtgC&pg=PA366&dq=what+is+3NF+normalization&hl=en&ei=BgKOTuDyA4HwrQeHpNmHAQ&sa=X&oi=book_result&ct=result&resnum=10&ved=0CF8Q6AEwCQ#v=onepage&q=what%20is%203NF%20normalization&f=false



http://books.google.lk/books?id=vX_KShZ95L8C&pg=PA175&dq=what+is+normalization:+pdf&hl=en&ei=hM6NTrGbD8r4rQeux4ifAQ&sa=X&oi=book_result&ct=result&resnum=10&ved=0CF8Q6AEwCQ#v=onepage&q=what%20is%20normalization%3A%20pdf&f=false




TechTarget. (2009-2011). Stored Procedure [Online] Available from:

http://searchoracle.techtarget.com/definition/stored-procedure [Accessed: 2nd

October 2011]

W3school (2011) Constraints [Online]. Available from:

http://www.w3schools.com/sql/sql_constraints.asp [Accessed: 5th October 2011]

44

http://www.w3schools.com/sql/sql_constraints.asp

http://searchoracle.techtarget.com/definition/stored-procedure


13 Appendix

13.1 Workload Matrix

Task Prasanga Nilushi Eshwaran

Planning and Analysis

Analyze the problem

requirements33.3% 33.3% 33.3%

Identify the main processes 33.3% 33.3% 33.3%

Workload Matrix 33.3% 33.3% 33.3%

Logical Design

Develop ERD 40% 30% 30%

Finalize Entities, Relationships

and attributes35% 30% 35%

Normalize the ERD 30% 40% 30%

Finalize the database 33.3% 33.3% 33.3%

Physical Design

Create Tables and Relationships 30% 40% 30%

Constraints 33.3% 33.3% 33.3%

Queries 33.3% 33.3% 33.3%

Triggers 30% 30% 40%

Stored Procedures 35% 35% 30%

Optimization Strategies 30% 30% 40%

Transactions 35% 35% 30%

Testing 33.3% 33.3% 33.3%

Documentation 33.3% 33.3% 33.3%

Signature

45

Documents

ADS Document