MATTHEW COLLINS H

Size: px

Start display at page:

Download "MATTHEW COLLINS H"

Griffin Flynn
6 years ago
Views:

1 TEESSIDE UNIVERSITY MODULE TITLE DATABASES AND SQL ASSIGNMENT TITLE CASE STUDY: SERVER DATABASE EXAMPLE MATTHEW COLLINS H

2 Contents 1 CASE STUDY SCENARIO ADDITIONAL CONSIDERATIONS deliverables study plan SQL server database database diagram Full ERD diagram Partial ERD database design table design logical views Example using aliases in views functions stored procedures getfixtures squadlist showleague data definition language data definition language create table drop table creating constraints data manipulation language SELECT WHERE ORDER BY BETWEEN LIKE 'IN' AND 'NOT IN' INSERT UPDATE... 23

3 5.2.9 DELETE Advanced Features CRITICAL REVIEW CONCLUSION CRITICAL REVIEW OF ICA PERSONAL DEVELOPMENT REFERENCES APPIX APPIX

4 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

5 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 Week

6 3 SQL SERVER DATABASE 3.1 DATABASE DIAGRAM FULL ERD DIAGRAM

3.1.2 PARTIAL ERD A. This shows the relationship between the tables 'players', 'teams' and 'managers'.

This shows the relationship between the tables 'teams' and 'leaguetable'.

played and points scored. C. This shows the relationships between the tables 'teams' and 'strips'.

7 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.

8 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.

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

tm_id is the primary key for the table 'teams' and is linked to the foreign key players.pl_tm_id.

9 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

10 managers players referees strips teams 4.2 LOGICAL VIEWS EXAMPLE Below is a view that shows all teams in the league table, ordered by points gained.

11 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] 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.

12 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.

13 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 char) RETURNS int AS int int int int

14 int int int = 0 = 0 = 0 = 0 = 0 = 0 = 0 int = 1 WHILE (@week <= 10) = (SELECT CASE WHEN FXT_homescore > FXT_awayscore THEN 3 WHEN FXT_homescore = FXT_awayscore THEN 1 ELSE 0 AS points FROM fixtures WHERE FXT_home AND FXT_week AND (FXT_homescore IS NOT NULL AND FXT_awayscore IS NOT NULL) ) IF (@temp >= 0) IF (@temp = 3) IF (@temp = 1) IF (@temp = 0) = (SELECT CASE WHEN FXT_awayscore > FXT_homescore THEN 3 WHEN FXT_awayscore = FXT_homescore THEN 1 ELSE 0 AS points FROM fixtures

15 WHERE ) FXT_away AND FXT_week AND (FXT_homescore IS NOT NULL AND FXT_awayscore IS NOT NULL) IF (@temp >= 0) IF (@temp = 3) IF (@temp = 1) IF (@temp = 0) IF (@week > 10) BREAK ELSE CONTINUE IF (@col = 'W') IF (@col = 'D') IF (@col = 'L') IF (@col = 'P') IF (@col = 'S') RETURN(@output)

16 The function is called with the following this is the unique ID (TM_id) of the team you wish to this is the column within the league table you wish to update The values and their meanings 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 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.

17 And the SQL used to generate results for game week 3 is shown below 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:

18 The SQL used to generate results for team 3 (teams.tm_id = 3) is shown below: 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.

19 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.

20 5 DATA DEFINITION LANGUAGE 5.1 DATA DEFINITION LANGUAGE 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 DROP TABLE The following code shows how to drop a table from the database using SQL: DROP TABLE fixtures 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 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

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

The following query shows all teams, ordered by their team name in ascending order. 5.2.

21 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 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 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.

The wildcard character (%) can be used to search for the beginning or end of strings.

22 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 '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.

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

23 Whereas the following query will do the opposite; showing all players that are NOT IN teams 3 or 4: INSERT The following query will add a player to team 1. INSERT INTO players (PL_TM_id, PL_name) VALUES (1, 'Mark Wildon') UPDATE The following query will update the team name of team 1. UPDATE teams SET TM_name = 'Redcar Town' WHERE TM_id = DELETE The following query will delete a player from the 'players' table. DELETE FROM players WHERE PL_name = 'Mark Wildon'

24 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.

25 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.

26 8 REFERENCES 1. Mansha Nawaz Sample Reports and Examples posted on his website intranet/users/u / 2. MSDN Online documentation from Microsoft MSDN us/library/bb aspx 3. PHP.net Online Documentation from PHP.net query.php

27 9 APPIX 9.1 APPIX 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

MARIA AMPARO FUENTES-OREA (F ) HSQ-DATABASES & SQL MANSHA NAWAZ. SERVER DATABASE EXAMPLE Generic Sales Order Processing System

MARIA AMPARO FUENTES-OREA (F ) HSQ-DATABASES & SQL MANSHA NAWAZ. SERVER DATABASE EXAMPLE Generic Sales Order Processing System MARIA AMPARO FUENTES-OREA (F-6102492) HSQ-DATABASES & SQL MANSHA NAWAZ SERVER DATABASE EXAMPLE Generic Sales Order Processing System Table of Contents 1. Case Study...3 1.1. Case study Scenario...3 1.2.