ASSIGNMENT TWO 15 marks

Due Friday 31/10/2014 at 5pm

This assignment should be done in a group of no more than 2 students.
This assignment needs to be completed in a group of no more than 2 student members. If such a group is
formed, both members must come from the same campus, and also within the tutorial classes of the same
tutor whenever possible. While lecturers and tutors will help as much as they can, it is essentially each
student's own motivation and responsibility to form a group for this assignment. By default, each student is
working in a group containing a single member of himself.
Students enrolled in 300941 - Database Design and Development (Advanced) must also complete the
advanced part 2 by the same due date.
For all database queries in this assignment, students need to construct their SQL
statements directly, not through the use of GUI.
Database Design and SQL Queries
In assignment 1, you have already
started the process of designing a
database for the Instant Recruitment
mini-case (enclosed again below),
mainly in the phase of conceptual
database design, and a draft ER
diagram has been created for this
purpose. Here you will further refine
your database design for the other
design phases.
In this assignment, you will in
particular complete the logical design
through the normalisation process,
have it physically implemented,
perform a few important queries in
SQL, and evaluate or verify the
database integrity. Your design of
relational model should be done in
such a way that business rules and
data integrity are ensured by the intrinsic design of the database as much as possible.
Logical Database Design (5 marks)
1. For the ER diagram you created in assignment 1, the artefact of the conceptual database design, map
the ER model into the relational model according to how it was designed in the ER diagram. You may
however first refine or completely re-do your ER diagram if necessary, and you are allowed to make
use of any part of our above displayed ER diagram skeleton to incorporate into your design in any way
you like if you feel your original design is not in a state to be implemented later. The actual
assessment of this part is in the point 4 below. While there can be a variety of acceptable designs, we
here attach one simplistic rough sketch for the comparison purpose.
2. Consider a greatly simplified core recruitment system whose ER diagram is shown on the right.
Draw the corresponding
GRD, exhibiting all the
primary keys and foreign
keys. For simplicity, no
other attributes nor
multiplicity constraints
are required.
Are the tables in the GRD
all in 3NF?
For a particular casual
job, if none of the
(registered) casual staff
meet the requirements on
the corresponding
expertise, will the primary key or foreign key constraints in your GRD prevent the database
system from assigning an unqualified casual to the job? Briefly explain why.
(1 mark)
3. For all the relations that arise from the ("first-cut") full ER diagram (which could be your original
design, or a design modified from your original or from the above given "simplistic design"), list all
those (in schemas) that are already in 3NF. If there are some relations that are not in 3NF yet, list them
as well. (1 mark)
4. Draw the global relation diagram for your final, revised, and normalised database design, and keep all
the relevant details there. It should be in a form similar to Figure 17.9 (page 516) of the textbook, but
all the attributes should be kept there too. Include in the diagram all the primary keys, foreign keys,
and the multiplicity constraints. Identify and discuss the potential data redundancies or anomalies that
may still exist in your design, if any. (3 marks)
Note: On the top right of this whole document is one possible simplistic ER diagram for the mini-case
for the implementation. If your original ER diagram has a very poor design, then you may simply take
this ER diagram on the top right as if it were your own ER diagram and then proceed from there.
Physical Database Design and SQL Queries (7 marks)
For the physical implementation of the database, students are allowed to implement the following
simplifications in their table and data design.
Availability for the
casual staff doesn't have
to be considered. That is,
you don't have to worry
about whether a casual
staff works only on
Mondays, or if he or she
is going away for a whole
month, or anything like
these. Hence the casual
staff can be assumed to
be available all the time
other than those time
slots already booked by
this same recruitment
system for another casual
work.
The job offer/acceptance
tracking, or the
negotiation between the School and the casuals, doesn't have to be considered. In other words,
the ERD given at the top of this document would reduce to "a more simplistic design", the one
on the right.
5. Create the database tables in SQL (runnable on
the School's Microsoft SQL Server) for all the
relations in your relation diagram, and enforce
there all the relevant constraints including
primary keys and foreign keys. Fill the tables
with sufficient data - generally around 4 tuples
or more per table, but should be sufficient to
illustrate meaningfully the working of the
general queries to be completed below. List the
content of your tables with screenshots.
Screenshots of active windows (under
Microsoft Windows) can be obtained by
pressing CTRL-ALT-PRTSC keys together,
see the example on the right. Your screenshots
must be readable and contain your username as
in the above example, and you may list several
tables on a single screenshot as is the example
on the right. (2.5 marks)
6. Write in SQL the commands to complete the
following queries, and show your results in
screenshots. (4.5 marks)
(a) Write a drop table statement so that
its execution will delete all the tables you
have created for this assignment. No
partial mark will be given for this part, if
the statement doesn't do the complete job.
(0.5 marks)
WARNING: Before you test this, you
must first make sure that you have saved
all the statements for the table creation
and the record insertion etc in a separate
SQL file saved outside the SQL Server.
This is to ensure that after the drop table
statement deletes everything, you can re-
create everything by running your saved
SQL script. If you are not sure, don't
to this part.
(b) For all the casual staff, list their names and the corresponding mobile phone numbers. (0.6
marks)
(c) For all the casual staff who hold one or more qualifications, list their names and the
corresponding qualifications. (0.6 marks)
(d) List who supervise which casual staff. (0.6 marks)
(e) For all casual staff, list their expertise (i.e. the subjects each staff is familiar with), the
corresponding years of experience, and their self-rating on their competetiveness. Order the
output in terms of the staff name, self rating and experience. (0.6 marks)
(f) For a given date, say 1 Oct 2014, list all the casual positions for that day that are still
available, i.e. still under recruitment. (0.6 marks)
(g) For a given date, say 1 Oct 2014, list all the casual positions for that day, which of those
positions is staffed by whom, which are yet to be staffed, the teaching timeslot and the venue.
The output should be properly sorted. (0.5 marks)
(h) For all casual staff who have been recruited for a casual duty (of regular type), calculate the
total number of hours worked or to be worked each week for each category of the positions, and
the total number of weeks. (0.5 marks)
Sophisticated Queries (3 marks)
7. For each casual job, list all those casual staff who are suitable for the job, ignoring their availability for
the timeslots. In other words, the suitability will not be affected by whether a casual can only work on
certain days or he has already got a commitment for another casual job in the School. (1 mark)
8. For your final designed database, find a scenario in which a relatively prominent business data
integrity can not be ensured by your current primary keys and foreign keys, nor by adding directly
more of such keys or check clauses in the created tables. In other words, the data integrity ensured by
the keys within the database may not be enough to ensure all the data integrity within the business
context. Write SQL statement/s that will determine if such a problem exists or not for any given state
of the database. (2 marks)
9. A single plain-text file containing SQL statements for creating all the tables and making all the
queries. The script should be executable on the School's Microsoft SQL Server, otherwise the
corresponding marks in the above listed items will be deducted accordingly. Marks will be
deducted for the corresponding questions if this SQL script in plain-text file is not submitted.
10. Each student must state explicitly who he or she once teamed up with if that person is not currently the
group member for the submission, unless no shared work is involved. Students are not permitted to
have shared work for this assignment with more than one person (the team member) including
potential former team member, unless approved by the unit coordinator in writing.
Mini Case: Instant Recruitment
Instant Recruitment is a system to be designed to recruit casual staff under a very short notice, as well as
on a more regular basis. For simplicity, this system will be limited to serving a large school at a university
where casual staff need to be recruited for lecturing, tutoring, and marking etc.
Casual staff: Within the school's recruitment database, each candidate for
casual staff must provide their contact details in terms of home address,
email address and mobile phone number, and must provide an estimated
travel time to reach the school from home. These will be utilized or taken
into consideration when the Instant Recruitment system suggests who to send
first the request to stand in for a regular staff who can't make it due to for
instance a sudden sickness. Each candidate has to specify a list of subjects
they can teach, their relevant years of experience there, and their self-rated
competitiveness or preference with the subject in the range of 0 to 10. Each candidate also needs to enlist
their qualifications and the positions they are interested for the casual work.
Positions: There can be different type of positions made available to the casuals, according to whether a
position is for lecturing, tutoring or marking etc. The casuals are paid on hourly basis according to their
positions.
Staff Request: When a casual staff is being requested or sought, it will be associated with a particular
position for the payment rate, and will specify certain expertise or subjects the casual staff should be familiar
with.
Recruitment: Each casual staff is recruited to a specific academic position for a period of time to conduct
the teaching activity at a given venue, and will be assigned to a relevant academic supervisor for the
academic liaison. For example, a casual staff may be urgently recruited to conduct a 2 hour lecture at a
certain time on the day under a very short notice (hence an express recruitment), or may be employed to do 4
hours at class tutoring each week during the semester (hence a regular recruitment). For a regular
recruitment, a casual staff will be assigned a specific class venue and the number of hours to work there
starting from an allocated beginning time. The recruitment will also specify the number of weeks the
appointed casual is to conduct the same activity at the same weekly time and venue. For an express
recruitment, the system will first search the available casual staff and rank them according to their past
response time and their estimated travel time to reach the school. A school's administrative staff will usually
select one of the top recommendations to contact via phone or SMS or email. A staff request (i.e. a job offer)
sent via an email or SMS to a casual staff will expire after a pre-selected amount of response time associated
with this particular job, so that the admin can select the next candidate to contact for the casual position. For
any express recruitment, all the relevant communications between the school and the casual staff will be
recorded and will be later analysed to calculate his or her average response time. In other words, the
recruitment system needs to be able to track when a casual job is sent to whom, whether it is accepted or
rejected, and at what time etc.
Availability: Each casual staff may be available only on certain days of the week, and may also be
unavailable for certain specific periods of days.
Note on Submission
This assignment must be submitted electronically via vUWS before the due date. No email
submissions will be accepted.
It is the students' responsibility to retrieve and keep all their submission receipts. If in doubt, consult
your tutors well before the submission due date.
Submitted files may be zipped together as a single zip file (but not as a zipx file), if a student wishes
to do so. However, no other file compression or file archiving formats will be accepted for the
submission.
The electronic submission should contain the paper work in Microsoft Word, and the pertinent SQL
source code (say, named IR.sql) should be in a separate file and should be in the plain text format.
Otherwise 1 mark may be deducted for the missing separate SQL source file even if the code is
already contained in the main Word document.
Please note that if your SQL source code gets rejected by the SQL Server at the School, you
automatically lose 50% of the marks allocated to that coding part.
Each group must submit exactly one copy of their assignment solution electronically by one of the
team members. If the other group member really wants to submit it as well due to whatever reasons,
then the name of the submitted files must start with "please_ignore_" (such files will not be treated
as regular submissions and will be ignored during the marking). Otherwise 1 mark may be deducted
for the duplicated electronic submission.
Each submission must be accompanied by a declaration of the ownership of the submitted work as
described in the unit outline and learning guide. No signature is however required for the electronic
submissions. Please note that an examiner or lecturer/tutor has the right not to mark this assignment if
a pertinent declaration is not present in your submission.
Late submissions will attract a daily incremented late penalty of 10% per day.
Electronic submission on the due date after 5pm before 12 midnight will still be accepted without
penalty. However, any submission failure in that period due to either the student faults or the fault or
malfunction of the School's or UWS' servers will not be accepted as the legitimate reasons for a late
submission. Beware that School's servers often need to be shut down for maintenance from late
Fridays or just before public holidays.
A statement on the work distribution in percentage (e.g. 50% for David and 50% for Louise) agreed
among all the group members. If this statement is absent, then it will be assumed that all group
members have made equal amount of contribution to the assignment solution. Achieving a 50%/50%
work distribution is also the goal of this team work; the person who contributes less than 50% may
result in having less mark than the other team member.
Assignment group members should each maintain a constant, effective, and productive communication
with their respective assignment partner, and should always have a contingency plan, the Plan B, for
the potential failure of the partnership no matter how impossible it may appear at the time. While
partners will typically all do their best to contribute to the better understanding of the assignment,
there can be unforseeable circumstances or misadventures that could result in an abortive termination
of the partnership. Hence it is each student's own responsibility to ensure that his or her partnership is
working, and he or she has a plan B for any potential partnership breakdown. This is a trade-off for all
the advantages of having an assignment partner. Hence please always keep a copy of everything about
your assignment yourself. Failure of a partnership at any time will not be accepted as an execuse for
the failure to submit the assignment in time.
Students are welcome to leave a hardcopy of their assignment 2 with their marking tutors directly, on
any agreed terms between the students and the tutors, prior to their work being already marked, so that
on top of the regular feedback in the form of marking sheets additional and more concrete comments
or suggestions may be written back to the assignment work on the relevant spots. However, please
bear in mind that the electronic submission is the official submission, submitting a hardcopy without
submitting the electronic copy within the due date will be deemed NOT having submitted the
assignment.
Any student submitting the assignment on his own must state explicitly whether he was once in a
group with another student, and what part of the submitted work actually inherited from a previous
joint team work. Failure to make this statement may result in this submission not being marked or a
plagiarism case lodged if the work is similar to another student's, and a late addition of such a
statement may lead to the assignment being considered as a late submission.
The main purpose of having an assignment team is to enable students to discuss the database design
with another student so as to better understand everything there, rather than splitting the actual work.
Hence, regardless of whether a team member contributed 100% or just 50%, the mark remains the
same. However, a team member may receive less marks if he contributes less than 50%.
Students are expected to continue with their existing assignment group or form a new group if they
haven't formed a group for Assignment 1. If any student is making a new assignment group, thus
leaving a previous assignment group, he must first obtain a written approval from his tutor or the unit
coordinator, unless he will not make use of any work jointly done in the previous team work.