TM422 The M358 Project
Project title: Relational database development: solving a real
problem, meeting a real need
Sample project description
Specific title
Recreational database for an ice-hockey
club
Description
[627 words excluding diagram]
I play for a local recreational
ice-hockey club. The club has a membership of around 40 people with regular
training sessions (weekly) plus occasional additional training when the rink
informs us that ice is available. Matches are organized individually (no league
structure, no regular match commitments) against other recreational teams. The
usual club record keeping is required, membership, fees, mailing lists,
financial records etc. plus additional requirements to record results of past
matches and future club events. Financially the club has a turn over of around
£14 000 per year. Club officials have been keeping records manually,
or in simple spreadsheets, since the club was founded six years ago.
At a recent club meeting it was
recognized that the club policy of not picking an ‘elite’ squad of
players for matches but that every eligible player should have an equal chance
of being picked to play was becoming hard to enforce. The club takes a maximum
squad of 15 players, plus netminders, to matches. However with
40 members there are frequently more players indicating their availability
for specific games resulting in some players missing games they would like to
have played in. In addition the club requires that a player picked for a
specific match will have (ideally) attended 5 of the 8 regular training
sessions preceding the match to be eligible for selection. There are some
additional requirements related to selection for specific matches. Part of the
application of this database system will be to keep records of training
attendance, and availability for matches and past selection for matches, among
other things. This information can be used to identify – and possibly rank
– players available for a match to ensure the club policy is being
enforced and all players have an equal chance of being selected over a long
time interval.
Data requirements
The requirements will include, but are
not limited to:
·
Membership list used for match eligibility, mailing list,
national association records, subscription records, additional skills such as
first aid training, coaching qualifications, trained as referee.
·
Training attendance list used to record attendance and regular
fee payment.
·
Match list to record commitment to matches, teams played,
results, etc.
·
Squad lists to record who played in which matches, match fee
payments.
·
Contact lists for other team representative, rink addresses,
officials, web pages, etc.
·
Financial records – including ice booking/payment, travel,
national association fees, etc.
Additional data requirements and a
detailed description of the processing requirements will form part of the
requirements-gathering stage of this project.
Project scope
·
It is intended to produce a database that will support the club
committee in the management of the day-to-day running of the club, and the
requirements for team selection should be supported by the database. The
database will be developed for this single club using the club committee and
club members as clients and intended end-users.
·
SQLAnywhere will be used to develop and implement the database,
including the development of appropriate SQL procedures and functions to
support the automation of several activities.
A particular aspect of the club database
that I would like to consider in depth is that of the historic data
requirements for the team selection process. This will involve investigation of
the data modelling and data maintenance requirements of what is, in effect, a
simple data warehouse.
Although I have not yet completed my
requirements analysis, the following sketch of part of the entity
relationship model shows my first draft for the subset of data associated with
team selection. I expect the complete model to be at least three times as
large, but I have yet to finalise the detailed requirements for the remaining
areas. I am also reviewing the possibility of introducing entity sub-types to
cater for different classes of club member.
Figure 1 Partial entity
relationship model for ice hockey club
Clearly, the entity relationship model
of the complete data requirements for the ice hockey club database will be
significantly larger and more complex than the fragment shown here.
Client availability
The club committee members have agreed
to help me in specifying requirements and evaluating the implementation I
produce. The club has existed for over six years and is unlikely to be
dissolved during the lifetime of this project.
Project schedule
Start date: February
200x End date: December
200x
Total time allocation: 260 hours
Fixed intermediate and final
deadlines and approximate time allocation
|
TMA 01 |
[the cut-off date] |
48 hours |
|
TMA 02 |
[the cut-off date] |
48 hours |
|
TMA 03 |
[the cut-off date] |
60 hours |
|
Report submission |
[the cut-off date] |
84 hours |
|
TMA 04 |
[the cut-off date] |
20 hours |
|
Month |
Planned activity |
|
February |
Read project briefing
notes.
Identify requirements for
project lifecycle, deadlines, deliverables etc.
Discuss possible project ideas
with potential clients. |
|
March |
Review M358 material.
Identify initial background
reading.
Initial discussion for
requirements gathering with client.
Produce TMA 01. |
|
April |
Rework proposal following
comments from tutor.
Identify skills weaknesses.
Plan detailed project
schedule.
Discuss detailed data modelling
with client. |
|
May |
Ensure weak skills areas are
supported.
Summarize background reading so
far.
Finalize project plan.
Produce TMA 02.
Further data modelling with
client – paper walkthrough to ensure specified requirements can be
met. |
|
June |
Finalize conceptual data model
(at least to first cut implementation) (expected slippage).
Ensure familiarity with
features/facilities of SQLAnywhere. |
|
July |
Initial design work (expected
slippage).
Produce TMA 03.
Examine first draft, first cut
design with client.
Check draft relations are in
BCNF. |
|
August |
Review conceptual data
modelling following client review.
Update and extend first draft
design. |
|
September |
Implementation, review and
testing of product should now be on-going (expected slippage point).
Start collecting (test)
evidence that the implemented system meets the information requirements.
Start work on project report
– plan content and structure, and document background reading. |
|
October |
Decide on what is implementable
in remaining time.
Consolidate existing work
– design freeze, implementation should focus on essential incomplete
features and prioritize remaining activities.
Assemble and organize
appendixes – ER model, SQL code, test output etc.
Evaluation of product, process
and project.
Ongoing project report work
– should be almost complete for last week of October.
Proofreading. |
|
November |
Complete remaining
implementation and documentation.
Revise project report
entirely.
Submit project report.
|
|
December |
Produce TMA 04.
End. |
Bibliography
Veryard, R. (1992)
Information Modelling – Practical Guidance,
BCS Practitioner Series, ed. R. Welland, Prentice Hall, ISBN 0134541820.
British Computer Society (1998)
Data Protection – Everybody’s
Business: A Practical Guide for Professionals and Business Managers,
British Computer Society, ISBN 1902505042.
Poe, V., Lauer, P. and Brobst, S. (1997)
Building a Data Warehouse for Decision Support,
2nd edn, Prentice Hall, ISBN 0137696396.
The text Information Modelling – Practical Guidance takes
a pragmatic approach to the processes and activities involved in the production
of an information model. As well as reviewing the purpose for, and
representation of, data models it also discusses practical approaches to
information gathering, presentation of models to clients, quality reviews and
how best to utilize the skills and involvement of the client. It includes
several case studies and highlights problems and risks faced by the data
analyst in the production of models to satisfy real-world applications.
This has been helpful in highlighting
the need for careful analysis of the requirements of the problem and the
client’s expectations, as well as making me review the amount of time to
be allocated for requirements analysis and the evaluation and finalization of
the data model at the design stage. As the project progresses, I expect to use
this text to supplement the (mainly technical) approach to data modelling
covered in the course material for M358 with the more practical considerations
this book highlights.
Equipment or software
No additional software or hardware will
be used beyond the standard course hardware and software packages. The project
involves the development of a standard database which can be implemented using
the features and facilities found in the SQLAnywhere package. The extended
research will include the consideration of data warehousing; however, it is not
my intention to construct a data warehouse, so no specialist software will be
required.
