Course: COMP1302 Coursework Number: Contribution:

Database Design and Implementation 1 of 1 50% of course

Greenwich Coordinator:
Due: Tuesday 9th November 2010
Dr Ala Al-Zobaidie
This coursework should take an average student who is up-to-date with tutorial work a
maximum of 50 hours
Learning Outcomes: B, D & E (as detailed on the course specification)

Plagiarism is presenting somebody else’s work as your own. It includes: copying

information directly from the Web or books without referencing the material; submitting
joint coursework as an individual effort; copying another student’s coursework; stealing or
buying coursework from someone else and submitting it as your own work. Suspected
plagiarism will be investigated and if found to have occurred will be dealt with according
to the procedures set down by the University.
All material copied or amended from any source (e.g. internet, books) must be placed
in quotation marks and in italics, with a full reference to the source directly
underneath the material.
Your work will be submitted for electronic plagiarism checking. Any attempt to
bypass our plagiarism detection systems will be treated as a severe Assessment
Offence.
 
Coursework Submission Requirements 
• An electronic copy of your work for this coursework should be fully uploaded by midnight (local 
time) on the Deadline Date.  
• The last version you upload will be the one that is marked.  
• For this coursework you must submit a single Acrobat PDF document. In general, any text in the 
document must not be an image (ie must not scanned) and would normally be generated from 
other documents (eg MS Office 2007 using "Save As .. PDF").  
• For this coursework you must also upload a single ZIP file containing supporting evidence.  
• There are limits on the file size.  
• Make sure that any files you upload are virus‐free and not protected by a password otherwise they 
will be treated as null submissions.  
• Comments on your work will be available from the Coursework page on the Intranet. The grade will 
be made available in BannerWeb.  
• You must NOT submit a paper copy of this coursework.  
 
Coursework Regulations  
1. If no submissions were made before the deadline, coursework submitted up to two weeks late that 
meets the criteria for a pass will be treated as a referral. It will be subject to university regulations 
for referral work.  
2. Coursework submitted late without an Extenuating Circumstances claim will receive a ZERO grade.  
If you have extenuating circumstances you may submit your coursework up to two weeks after the 
published deadline without penalty but this is subject to acceptance of your claim by the School 
Extenuating Circumstances Panel. If your claim is rejected then you will receive a zero grade for 
your work.  
3. Coursework submitted more than two weeks late will be given feedback but a grade of non‐
submission will be awarded regardless of any extenuating circumstances. However, if your 
Extenuating Circumstances claim is accepted then the Extenuating Circumstances Panel will 
recommend to the Progression and Award Board that you be permitted to retake a different item 
of assessment at a future assessment point. 
4. All courseworks must be submitted as above.  
 

CW_COMP1302_180002_ver1_0910 Page 1 of 7 printed on 30-Jul-10

    
Briefing
The aim of this assignment is to undertake a range of tasks involved in analysis, design and build a
database structure and applications for a database system for a basketball team.
Where information is not available you should make reasonable assumptions. Make sure that you
include all business constraints that have been captured during the analysis part.

Specification
The aim of this assignment is to develop a database system to hold records for basketball teams and
their matches. The system will be used for analysing the players’ performance during the season as
well as to select players of the month based on the data entered into the system. The system also is
mainly used for producing statistical information for managers, coaches and clubs (where the team
plays) owners.

The system will maintain personal information of players such as: first and surnames, date of birth
(players must be above 16 years old), height and weight, position (each player can play in various
positions) and experience (measured by the number of national and international matches’ played).
Information on when the player has starting in a specific position is required. If he used to play in a
specific position before but not anymore, the date when he stopped playing in that position is
required.

A player can be associated with only one team at any time. However, records of previous
associations (i.e. teams previously played for) would be very useful but not essential. The team has
a fixed address which usually the address of the club where the basketball court is physically
located (Home court). A player is either a professional or an amateur but cannot be both.
Professional players get a high salary from the club. Information on their contracts should be kept
in the system such as salary, date of start and date when the contract finishes plus any additional
binding conditions.

Amateur players must be either in full time education or in full time employment. The occupation
must be recorded in the system (e.g. education or employment) plus the name of the institute (e.g.
company or university name). We also keep information about other hobbies for amateurs. An
amateur player does not get any payments when playing in matched but all expenses incurred for
playing away from home club will be covered by the team.

Each season, a record of matched that each team plays is kept. A game is between two teams of
which one of them must win (i.e. no draw results in basketball games). The date and place of the

CW_COMP1302_180002_ver1_0910 Page 2 of 7 printed on 30-Jul-10

match are kept in the system. A record of the scored points by each team is used to determine
which team is the winner.

For each match we need to keep information of the performance of each player. This include the
number of: 2 points attempts, 2 points made, 3 points attempts, 3 points made, free throws attempts,
free throws made, minutes played, fouls made, rebounds (i.e. A rebound in basketball is the act of
successfully gaining possession of the basketball after a missed field goal or free throw).

Although the match is between two teams, it is common that many players are named in the team
but they do not actually participate in that match when it takes place. These are reserved players
sitting on the bench ready to be called any minute by the coach to join the match. The team consists
of 10 named players but only 5 players can play at any one time. The team consists of professional
and amateur players. The coach can exchange players at any time, unlimited number of times.
Quite often players do not actually play in the match despite they are named in the team initially for
that match. Therefore, information as to which player actively played in a specific match is
important.

The developed system should be capable of keeping track of players and allow the user to interact
flexibly and efficiently with the database. Although users are accessing the DB via a web page, it is
not part of the requirements for this cswk.

CW_COMP1302_180002_ver1_0910 Page 3 of 7 printed on 30-Jul-10

Sample Applications
Initially, the following applications for the system are planned, but please note the
list given below is only a sample:

A1. A list of all players who played more than 20 games (national or international).
The user should be prompted to enter the borrower number at run-time.
Produce the SQL code only (i.e. no form or report).

A2. For a given match, produce the total number of fouls made by all players (from
both teams who actually played) in that match. Produce the SQL code only (i.e.
no form or report).

A3. For any given player, give the number of all matched that he did not actually
play but listed in the team. The player full name or ID should be input at run
time from the SQL prompt. Produce the SQL code only (i.e. no form or report).

A4. Choose a player of the match (i.e. the player who scored highest points in one
match). Produce the SQL code only (i.e. no form or report).

A5. For any given match, produce the names of all named players in the two teams,
the name of the winning team, the court postcode where the match took place
and the date of the match. The user should be prompted to pick the target
match from a pull down menu that shows (the pull down menu) the date of the
match and names of the two teams. Produce the output on a report.

A6. Produce a list of statistics for any given professional player. The name of the
player should be captured at run-time from a drop-down list (of all available
professional players) by the user. For each player, and for each match he
played, list the match date, the team he is paying for, the total points scored
(i.e. 2 & 3 points goals) in that match and the number of fouls he made. The
output is to be produced in a master/detail form.

CW_COMP1302_180002_ver1_0910 Page 4 of 7 printed on 30-Jul-10

Deliverables:

D1. One A4 page, state clearly any assumptions (i.e. Enterprise or Business rules) that you make
about the data; in particular, noting any information that you believe should be included, but
is not mentioned in the outline specification.

D2. One A4 page containing the conceptual data model diagram (i.e. an Entity Relationship
Diagram, using the Chen notation) for the system. Your diagram should show:
• Relevant Entity Type,
• You only need to show the following attributes in the conceptual model: a Primary Key for
each entity; any multi-valued or derived attributes; Derived attributes & Relationships
attributes1.
• Relationship Type with a role name (plus relationship attributes if any),
• Structural constraints for each relationship (both cardinality and participation).
Note: if you show attributes other than the Primary Keys (e.g. Foreign Keys) then you will be penalised.

D3. For the above model, produce a relational schema2 (i.e. transforming the conceptual data
model into a logical relational schema) on one A4 page – DO NOT show the mapping steps.
Your Relational Schema should show:
• All entity and relationship types that are potential for a relational table.
• For each potential table identify the primary key and any necessary foreign keys and all
other attributes.
• Show the links between the tables3 (e.g. a table-relationship diagram produced by MS
Access) or, for each table, describe any links to other tables in SQL statement(s).

D4. Normalisation check: You need to check your produced Relational Schema above for 3rd NF.
If it satisfies 3NF criteria then you ONLY need to include the statement “The Relational
Schema satisfies 3NF criteria”. If your schema does not satisfy the criteria of 3NF then you
need to reproduce your schema in 3NF. You DO NOT need to show the steps (i.e. process) of
Normalisation.

D5. Create a DB for the above schema in an appropriate relational DBMS and populate each table
with typical records to clearly demonstrate the application results. You DO NOT need to
produce a snapshot of the tables. Please note that all students within a cohort must use the
same DBMS as directed by your tutor.
1
To avoid cluttering the Conceptual Data Model with many attributes and to improve clarity, other attributes can be
shown in the logical model (i.e. or listed in the relational schema). Any extra attributes which are not required to be
shown on the CDM (as indicated above) will be ignored. Please note that presenting Foreign Keys at the CDM
diagram is wrong and students will be panelised if they do so.
2
Please note that the choice of the DBMS is to be decided by your tutor. However, all students within the same
cohort MUST use the same DBMS. No additional software (e.g. VB, Java, etc.) should be used to develop any of
the applications. Instead, the tools (i.e. forms and report tools) provided by the chosen DBMS should be used.

3
You can show the links between Primary and Foreign keys on your relational schema as arrows starting from the
FK and ending at the PK, as shown in the example below.
Doctor (DocNo, DocName, BirthDate, Address, City, PostCode, Tel_H);

Doctor_Qualification (DocNo, QualName, QualDesc, DateAwarded); /*DocNo referencing Doctor.DocNo */

CW_COMP1302_180002_ver1_0910 Page 5 of 7 printed on 30-Jul-10
D6. Write the SQL code only (i.e. no form or report) for applications A1-A4 above. —DO NOT
USE the QUERY BUILDER tool available with your DBMS. Code produced automatically
by the wizard (i.e. tools) will be awarded ZERO.

D7. Using the appropriate tool from the chosen DBMS, create a form for registering a player and
assigning him to a team. This should have two buttons on it— one to commit a new
borrower to the Database and one to exit the form. A screen dump of this application at run-
time is required.

For D8-D10, No additional software (e.g. VB, Java, etc.) should be used to develop any of the
applications, but the tools provided by the chosen DBMS.
D8. Using the appropriate tool from the chosen DBMS, produce a report for application A5
above.

D9. This is for application A6 above. Using the appropriate tool from the chosen DBMS create a
master/detail form to perform this application.

D10. You are required to implement all above applications as well as submitting a one A4 page
containing the SQL statements only required by the sample applications above. You need to
test all your queries, forms and reports with sample data and make sure that all your
applications produce some answers. You will be asked by your tutor, during your demo, to
run some/all of the applications.

Your electronic submission should be in two files:

ONE PDF document consists of followings:

1. One A4 page for any assumptions and business rules. Ref. D1
2. One A4 page for Conceptual Model. Ref. D2
3. One A4 page for the mapped Relational Schema (i.e. Logical Data Model) showing
links between Foreign Keys & Primary Keys. Ref. D3
4. One A4 page for Normalisation declaration (or a reproduction of the relational schema
in Third Normal Form). Ref . D4
5. One A4 page for presenting SQL code for the required applications. Ref. D6 & D10
6. Screen dumps for all required applications in D6 and One Screen dump for each of
deliverables D7-D9.
ONE Zip file containing all DB files (e.g. Microsoft Access DBMS or any appropriate relational
DBMS4, SQL servers files, Visual studio source file, etc.). Ref. D5

4
Using Oracle, Access or SQL server, etc. makes no difference for achieving the aims of the coursework. Oracle
users should submit the following: a file containing all SQL scripts that are used in creating and/or populating the
database objects; a file containing the SQL scripts used to answer the sample applications, all oracle forms and
reports files (i.e. …… .fmb and .rdf files).
CW_COMP1302_180002_ver1_0910 Page 6 of 7 printed on 30-Jul-10
Grading Criteria
Note: Students Will Fail the Coursework If:
1. Failure to attempt an implementation regardless of the quality of the design,
2. Do not demonstrate the work to their tutor, or
3. Having very poor implementation. The marks will be capped as explained below.
• If the student is unable to produce a single fully operational application correctly, then the
maximum awarded mark is 20%.
• If the student completes only one fully operational application correctly and attempted most of
the others then the maximum awarded mark is 40%.
• If the student completes two or more fully operational applications correctly then cswk is
marked according to the marking schema below with no capping.

Conceptual Model 40%

Many possible models, but the model should identity major entities and relationships.
• Identifying Entities with a proper unique identifier: 15%
• Reasonable Assumptions: 5%
Assumptions are to clarify unclear business rules or procedures. Assumptions are to reflect
common-sense and student’s ability to make the right judgement when information is
missing. Any unreasonable assumption that aims to make the design simpler and
compromise or ignore business rules gains no marks.
• Identifying Relationships, Generalisation/Specialisation hierarchies 10%
• Cardinality and Participation Constraints of relationships 10%
Relational Schema (i.e. Logical Model) 20%
• A list of candidate attributes for each table as specified in the requirements. 5%
A PK may be identified by an underline (a common practice) and a FK by any other
means as described by the candidate (e.g. double underline, italic style, different colour
font, etc.).
• Produced Relational Schema (mapping): 10%
The focus here is on the link between Primary keys (PKs) and Foreign Keys (FKs). Use
the standard notation for the relational schema and draw arrows to show the links between
the tables. The arrows should originate from the FK attribute and end at the referencing
attribute as shown below:
<table1Name> (PK Identifier, attribute1, attribute2, FK_attribute, etc.);

<table21Name> (PK Identifier, attribute1, …, FK_attribute, etc.);

Points to check: placements of FKs in correct target table(s), need to create new
tables, and correct handling for any superclass/subclass constructs.
• Normalisation Check 5%
The produce logical schema is expected to be in 3rdNF. A candidate may normalise their
tables to produce the 3rdNF version, or (if the schema in 3rd NF, an assurance statement
that the produced relational schema is in 3rdNF is essential).
Implementation and SQL Applications 35%
• A candidate should implement the Database on the target DBMS and populate the
each table with sample data (3-5 records each). 5%
• Implementing the correct constraints (PK/FK links, Null allowed or not, etc.)
• Implementing the above applications as specified (e.g. producing SQL code, passing
parameters, etc.). 30%

Quality of presentation/demonstration 5%
• Presentation of your screens (i.e. navigation) and reports; quality of your
deliverables (Conceptual and logical relational model, assumptions, SQL code, etc.). This
will be awarded during the demo.
Total 100%

CW_COMP1302_180002_ver1_0910 Page 7 of 7 printed on 30-Jul-10