TEESSIDE UNIVERSITY  

MODULE TITLE 

DATABASES AND SQL 

 

ASSIGNMENT TITLE 

CASE STUDY: SERVER DATABASE EXAMPLE 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

MATTHEW COLLINS 

H8851143 

Contents 1  CASE STUDY ..................................................................................................................................... 4 

1.1  SCENARIO ................................................................................................................................ 4 

1.2  ADDITIONAL CONSIDERATIONS .............................................................................................. 4 

1.3  deliverables ............................................................................................................................. 4 

2  study plan ........................................................................................................................................ 5 

3  SQL server database ........................................................................................................................ 6 

3.1  database diagram .................................................................................................................... 6 

3.1.1  Full ERD diagram ............................................................................................................. 6 

3.1.2  Partial ERD ....................................................................................................................... 7 

4  database design .............................................................................................................................. 9 

4.1  table design ............................................................................................................................. 9 

4.2  logical views .......................................................................................................................... 10 

4.2.1  Example ......................................................................................................................... 10 

4.2.2  using aliases in views .................................................................................................... 11 

4.3  functions ............................................................................................................................... 13 

4.4  stored procedures ................................................................................................................. 16 

4.4.1  getfixtures ..................................................................................................................... 16 

4.4.2   squadlist ........................................................................................................................ 17 

4.4.3  showleague ................................................................................................................... 18 

5  data definition language ............................................................................................................... 20 

5.1   data definition language ....................................................................................................... 20 

5.1.1  create table ................................................................................................................... 20 

5.1.2  drop table ...................................................................................................................... 20 

5.1.3  creating constraints ...................................................................................................... 20 

5.2  data manipulation language ................................................................................................. 20 

5.2.1  SELECT ........................................................................................................................... 20 

5.2.2  WHERE .......................................................................................................................... 21 

5.2.3  ORDER BY ...................................................................................................................... 21 

5.2.4  BETWEEN ...................................................................................................................... 21 

5.2.5  LIKE ................................................................................................................................ 22 

5.2.6  'IN' AND 'NOT IN' ........................................................................................................... 22 

5.2.7  INSERT ........................................................................................................................... 23 

5.2.8  UPDATE ......................................................................................................................... 23 

5.2.9  DELETE ........................................................................................................................... 23 

6  Advanced Features........................................................................................................................ 24 

7  CRITICAL REVIEW .......................................................................................................................... 25 

7.1  CONCLUSION ......................................................................................................................... 25 

7.2  CRITICAL REVIEW OF ICA ....................................................................................................... 25 

7.3  PERSONAL DEVELOPMENT .................................................................................................... 25 

8  REFERENCES .................................................................................................................................. 26 

9  APPENDIX ...................................................................................................................................... 27 

9.1  APPENDIX 1 ........................................................................................................................... 27 

 

 

   

1  CASE STUDY  

1.1  SCENARIO This database has been created to help facilitate the running and organisation of a local 5‐a‐side 

football league compromising any number of teams. A league table will be updated based on fixture 

results and fixture details will show who is playing, who the referee is and which colour strip each 

team should wear. Statistics such as leading goalscorers will also be available. 

1.2  ADDITIONAL CONSIDERATIONS It may be necessary to include a mechanism for controlling user access rights should this database 

be used in a publicly accessible way; such as a web interface. 

There is no personal or confidential data being stored in the database. 

1.3  DELIVERABLES On completion I hope to have shown my proficiency in the following areas: 

Building a complex ERD and a partial, at minimum, implementation of the corresponding 

SQL 

Have a functional and error free database 

Knowledge of SQL stored procedures and functions to aid in data manipulation and 

presentation 

Knowledge of methods of connectivity to best use this database, such as via a website 

   

2  STUDY PLAN STUDY PLAN 

1. DESIGN    

Case Study & Deliverables  x 

ERD Full & Partial  x  x 

Tables     x  x 

2 IMPLEMENTATION    

TABLES     x  x  x 

CONSTRAINTS     x  x 

INSERTS     x  x  x 

DROPS     x  x  x 

3 FUNCTIONALITY    

SQL‐functions     x  x  x 

SQL‐stored procedures     x  x  x 

SQL Import Export Database     x  x 

SQL‐Web integration     x  x  x 

4 REPORT           x  x  x  x  x 

Dates  26.11  3.12  10.12  17.12  24.12  31.12  7.01  14.01 

Week  1  2  3  4  5  6  7  8 

 

   

3  SQL SERVER DATABASE  

3.1  DATABASE DIAGRAM  

3.1.1  FULL ERD DIAGRAM 

 

 

   

3.1.2  PARTIAL ERD 

A. This shows the relationship between the tables 'players', 'teams' and 'managers'. These tables are 

used to display the team name, the players that belong to this team and the team manager. 

 

B. This shows the relationship between the tables 'teams' and 'leaguetable'. These tables are used to 

display the team name in the league table along with all corresponding information such as games 

played and points scored. 

 

C. This shows the relationships between the tables 'teams' and 'strips'. These tables are used to 

show the strips assigned to each team. 

 

D. This shows the relationship between the tables 'teams', 'fixtures' and 'referees'. These tables are 

used to generate fixture lists and show which referee is in charge of which game. 

 

E. This shows the relationship between the tables 'players', 'goals' and 'fixtures'. This can show us 

who scored in which game and how many goals an individual player has scored. 

Because of the relationship between the tables 'players' and 'teams' (as shown in Diagram A) it is 

also possible to show which team has scored the most goals. 

   

4  DATABASE DESIGN  

4.1  TABLE DESIGN Below are the physical views of all the tables in my database. 

I have added a prefix to every field name in a table to help avoid ambiguous field names in queries. If 

this field is used as a foreign key in another table I will also include this prefix there.  

For example, teams.TM_id is the primary key for the table 'teams' and is linked to the foreign key 

players.PL_TM_id.  This is particularly helpful when joining tables that have similar field names, such 

as the 'players' and 'teams' tables. 

The SQL that demonstrates this is as below: 

 

fixtures 

goals 

leaguetable 

managers 

players 

referees 

strips 

teams 

 

4.2  LOGICAL VIEWS  

4.2.1  EXAMPLE 

Below is a view that shows all teams in the league table, ordered by points gained. 

 

The above shows the relationship between the 'leaguetable' and 'teams' tables along with the 

required fields and any sorting options. It also shows the SQL code required to display this view and 

the results that are output once the view is executed. The view is saved as 'table'. 

The SQL to manually execute this view is: 

SELECT * FROM [table] 

4.2.2  USING ALIASES IN VIEWS 

Below is an example of a problem I encountered when using views in Microsoft SQL Management 

Studio. 

As shown in the Partial ERD below, there are three required tables when generating fixture lists. 

 

This ERD shows that the 'fixtures' table has two separate relationships with the 'teams' table, 

however both of these relationships refer to the primary key of the 'teams' table ‐ TM_id. 

When using SQL Server Management Studio to create this view, this is the SQL that it generated for 

me: 

SELECT     dbo.teams.TM_name FROM         dbo.fixtures  INNER JOIN dbo.teams ON dbo.fixtures.FXT_home = dbo.teams.TM_id    AND    dbo.fixtures.FXT_away = dbo.teams.TM_id  INNER JOIN  dbo.referees ON dbo.fixtures.FXT_REF_id = dbo.referees.REF_id  The above SQL requires that both the home team ID (FXT_home) and the away team ID (FXT_away) are the same as the team ID (TM_id) which would mean that only fixtures where the same team was playing home and away would be selected. This would result in no results returned. 

To get around this problem I would use an alias when joining the 'teams' table, as shown in the SQL below: 

SELECT     home_team.TM_name FROM       dbo.fixtures  INNER JOIN  dbo.teams AS home_team ON dbo.fixtures.FXT_home = home_team.TM_id INNER JOIN  dbo.teams AS away_team ON dbo.fixtures.FXT_away = away_team.TM_id  INNER JOIN dbo.referees ON dbo.fixtures.FXT_REF_id = dbo.referees.REF_id  The image below shows how this changes the tables in the view; it now includes the 'teams' table twice, each with a different alias (home_team and away_team). It also shows the fields selected and the results output when this view is executed. This view is saved as 'vFixtures'. 

 

The SQL to execute this view is: 

SELECT * FROM [vFixtures] 

4.3  FUNCTIONS I have created a function used when updating any given league table column for any given team in 

the database.  

The SQL used in this function is shown below. 

CREATE FUNCTION updateTable (@team int, @col char) RETURNS int AS BEGIN DECLARE @points int DECLARE @temp int DECLARE @played int DECLARE @won int

DECLARE @draw int DECLARE @lost int DECLARE @output int SET @points = 0 SET @temp = 0 SET @played = 0 SET @won = 0 SET @draw = 0 SET @lost = 0 SET @output = 0 DECLARE @week int SET @week = 1 WHILE (@week <= 10) BEGIN SET @temp = (SELECT CASE WHEN FXT_homescore > FXT_awayscore THEN 3 WHEN FXT_homescore = FXT_awayscore THEN 1 ELSE 0 END AS points FROM fixtures WHERE FXT_home = @team AND FXT_week = @week AND (FXT_homescore IS NOT NULL AND FXT_awayscore IS NOT NULL) ) IF (@temp >= 0) BEGIN SET @points = @points + @temp SET @played = @played + 1 IF (@temp = 3) BEGIN SET @won = @won+1 END IF (@temp = 1) BEGIN SET @draw = @draw+1 END IF (@temp = 0) BEGIN SET @lost = @lost+1 END END SET @temp = (SELECT CASE WHEN FXT_awayscore > FXT_homescore THEN 3 WHEN FXT_awayscore = FXT_homescore THEN 1 ELSE 0 END AS points FROM fixtures

WHERE FXT_away = @team AND FXT_week = @week AND (FXT_homescore IS NOT NULL AND FXT_awayscore IS NOT NULL) ) IF (@temp >= 0) BEGIN SET @points = @points + @temp SET @played = @played + 1 IF (@temp = 3) BEGIN SET @won = @won+1 END IF (@temp = 1) BEGIN SET @draw = @draw+1 END IF (@temp = 0) BEGIN SET @lost = @lost+1 END END SET @week = @week + 1 IF (@week > 10) BREAK ELSE CONTINUE END IF (@col = 'W') BEGIN SET @output = @won END IF (@col = 'D') BEGIN SET @output = @draw END IF (@col = 'L') BEGIN SET @output = @lost END IF (@col = 'P') BEGIN SET @output = @played END IF (@col = 'S') BEGIN SET @output = @points END RETURN(@output)

END  

The function is called with the following parameters 

@team ‐ this is the unique ID (TM_id) of the team you wish to update 

@col ‐ this is the column within the league table you wish to update 

The values and their meanings for @col are as follows: 

'P' ‐ Played 

'W' ‐ Won 

'D' ‐ Drawn 

'L' ‐ Lost 

'S' ‐ Scored (updates the Points column) 

When two correct values are passed to this function, it will return the correct value to SQL. This can 

be used to update all of these columns for all of these teams with a simple SQL statement, as shown 

below: 

UPDATE leaguetable SET TBL_played=dbo.updateTable(TBL_TM_id, 'P'), TBL_won=dbo.updateTable(TBL_TM_id, 'W'), TBL_draw=dbo.updateTable(TBL_TM_id, 'D'), TBL_loss=dbo.updateTable(TBL_TM_id, 'L'), TBL_points=dbo.updateTable(TBL_TM_id, 'S')

4.4  STORED PROCEDURES I have created a number of stored procedures to help display data in a useful and relevant format.  

 I have used stored procedures instead of logical views as a stored procedure gives me more 

flexibility to manipulate the data returned via parameters. 

4.4.1  GETFIXTURES 

 

This stored procedure has one parameter (@week, integer) and returns a list of fixtures for a 

particular game week, as defined by this parameter. The stored procedure will also check the shirt 

colour of each team (STP_shirt) and if both teams have matching shirts, the away team will use an 

alternate option as defined in the 'strips' table (STP_alt_shirt). 

The SQL used to create this stored procedure is shown below. 

 

And the SQL used to generate results for game week 3 is shown below. 

 

 

4.4.2   SQUADLIST 

 

This stored procedure has one parameter (@team, integer) and returns a squad list, team name and 

manager name, as defined by this parameter. 

The SQL used to create this stored procedure is shown below: 

 

The SQL used to generate results for team 3 (teams.TM_id = 3) is shown below: 

 

4.4.3  SHOWLEAGUE 

 

This stored procedure contains the SQL shown above in the functions chapter along with some extra 

SQL to update the league table and then display the results. 

 

It takes no parameters and calls the updateTable function five separate times, one for each column 

that needs to be updated, after updating the table it then displays the league table. 

   

5  DATA DEFINITION LANGUAGE  

5.1   DATA DEFINITION LANGUAGE 

5.1.1  CREATE TABLE 

The following code is an example of how to create a table using SQL: 

CREATE TABLE [dbo].[teams]( [TM_id] [int] IDENTITY(1,1) NOT NULL, [TM_name] [nchar](20) NULL, [TM_STP_id] [int] NULL, CONSTRAINT [PK_teams] PRIMARY KEY CLUSTERED

The table is called 'teams' 

There are three different columns: TM_id, TM_name, TM_STP_id 

There are two different column types:  

o int ‐ integer value 

o nchar ‐ numbers and other characters, in this instance with a limit of 20 characters 

The TM_id field is an IDENTITY field, this field will increment by 1 for every new row, starting 

with the value 1. 

5.1.2  DROP TABLE 

The following code shows how to drop a table from the database using SQL: 

DROP TABLE fixtures

5.1.3  CREATING CONSTRAINTS 

The underlined code shows how a constraint is added to a table: 

CREATE TABLE [dbo].[teams]( [TM_id] [int] IDENTITY(1,1) NOT NULL, [TM_name] [nchar](20) NULL, [TM_STP_id] [int] NULL, CONSTRAINT [PK_teams] PRIMARY KEY CLUSTERED

 

5.2  DATA MANIPULATION LANGUAGE 

5.2.1  SELECT 

The SELECT statement is used to define the fields we select and from which table(s). The query 

below shows how to select all fields from the 'teams' table. 

 

5.2.2  WHERE 

The WHERE statement allows conditions to be added to the SELECT statement, allowing certain data 

to be selected. The query below shows how to select 'Stockton Town' from the 'teams' table. 

 

5.2.3  ORDER BY 

The ORDER BY statement is used to order output from a query in a particular way. It is possible to 

order by any field, ascending or descending. The following query shows all teams, ordered by their 

team name in ascending order. 

 

5.2.4  BETWEEN 

The BETWEEN statement is used to compare either numerical values or dates. The condition is 

inclusive, meaning that the following query would show all fixtures in weeks 1, 2 and 3. 

 

5.2.5  LIKE 

The LIKE statement is used to find a partial text match when searching on a particular field. This is 

used in conjunction with the WHERE statement. The wildcard character (%) can be used to search for 

the beginning or end of strings. The following query will search for all player names beginning with 

A. 

 

5.2.6  'IN' AND 'NOT IN' 

The IN and NOT IN statements can be used to search for values compared to a list of predefined 

values. The query below will search for all players who are in team 3 or 4: 

 

Whereas the following query will do the opposite; showing all players that are NOT IN teams 3 or 4: 

 

5.2.7  INSERT 

The following query will add a player to team 1. 

INSERT INTO players (PL_TM_id, PL_name) VALUES (1, 'Mark Wildon')

5.2.8  UPDATE 

The following query will update the team name of team 1. 

UPDATE teams SET TM_name = 'Redcar Town' WHERE TM_id = 1

5.2.9  DELETE 

The following query will delete a player from the 'players' table. 

DELETE FROM players WHERE PL_name = 'Mark Wildon' 

6  ADVANCED FEATURES It is possible to link SQL Server to other applications, one example of this is to a website application 

using a scripting language such as .NET or PHP. 

The following code shows how to connect to the database and perform a simple query using PHP. 

 

   

7  CRITICAL REVIEW 

7.1  CONCLUSION The original aim was to create a fully functioning database system, driven by a web front‐end to help 

organise and run a local 5‐a‐side league. Due to time restraints only the database system was 

designed and created. If more time was allowed then a complete system could have been presented. 

The database is fully functional and can be used in its current state to manage a 5‐a‐side league but 

it is not very user friendly and a web front‐end would improve the user experience massively. 

7.2  CRITICAL REVIEW OF ICA There were many other possible features that could have been added to this system and I feel that 

this would have led to more tables being added to the model, and as such a more complex ERD with 

more complex queries. 

I do believe that my current database and table structure, as shown in the ERD, is of an acceptable 

standard to demonstrate proper usage of SQL Server. 

7.3  PERSONAL DEVELOPMENT I have had previous knowledge of using mySQL and I felt that this put me in a good position to create 

a solid database. 

I used this ICA as an opportunity to use advanced features such as Stored Procedures and User 

Defined Function to help improve the functionality of my database. I had very limited knowledge of 

this beforehand and had to refer to online tutorials to help me with this. 

I feel confident that I could now use these features in future projects with minimal help. 

   

8  REFERENCES 1. Mansha Nawaz  Sample Reports and Examples posted on his website 

http://scm‐intranet/users/u0000706/ 

 

2. MSDN    Online documentation from Microsoft MSDN 

http://msdn.microsoft.com/en‐us/library/bb545450.aspx 

 

3. PHP.net    Online Documentation from PHP.net 

http://www.php.net/manual/en/function.mssql‐query.php 

   

9  APPENDIX 

9.1  APPENDIX 1 The following are links to the create script files for the tables used in the database. 

Teams 

Strips 

Referees 

Players 

Managers 

Leaguetable 

Goals 

Fixtures 

The following is a link to the create script files for the functions and stored procedures I have created 

in the database. 

Functions and Stored Procedures