Instant Recruitmentis 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 the position 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 employed to do 4 hours each week for the in-class tutoring during the semester, and this type of recruitment is considered 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.

Express Recruitment: A casual staff may, for instance, also 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). 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, 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 particular, 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.

 

1. The ER diagram should include, among others, representative attributes for all entity types, proper subclassing, and correct participation multiplicities for the relationship types. It should be meaningfully and well designed, and should also include all relevant and necessary aspects, and indicate any supplementary business rules if you decide to introduce. 
3. Among all the weak entity types, explain for one of them why it is a weak entity type. If your current design doesn't have any weak entities, then explain which one of your current entities may be made a weak entity and why. 
5. Among all the generalisation/specialisation cases in the ER diagram, find a relatively nontrivial one in terms of the subclassing complexity, and explain the meaning of the actual subclassing in this case and the mearning of the associated participation and disjoint constraints. 

You are asked to develop a detailed Entity-Relationship model for this mini case. Your ER model should consist of a detailed ER diagram integrated with itemised discussions on the features of the entities and relationships and all the assumptions you made. The ER diagram and the accompanying document should identify keys, constraints, entity types, relationship types, specialisation/generalisation, etc. The ER diagram should in general have more than 5 entity or relationship types and no more than 15. This means that students will have to selectively identify those most important entity types and relationship types for their work and for the fulfilment of the key business functionalities. More concretely, your deliverables should include a detailed ER diagram for the model, highlighting primary keys, multiplicity constraints, generalisation/specialisation, important attributes, and other pertinent details.

We note that, the design of this database can be much simpler or clearer if the "express recruitment" in the mini case is not considered, i.e. all casual recruitments are considered "regular". Hence students may initially design their database under this assumption, if they wish, before attempting the final complete design.