Online clubbing /party service

Tweet

Your company has been commissioned to provide an on-line clubbing/party service for dedicated impromptu party goers called Quorum. Quorum parties can take place in established named venues (pubs and clubs), in peoples homes, even fields. It is a business rule that all parties must take place at a location with a postcode. The service will have a web presence, but will primarily be delivered via small mobile devices (e.g. Mobile Phones and PDA’s). Here’s how it will work. When three or more persons (a quorum) who are signed up to the service (Quorum member) are gathered in a single place, text alerts start appearing on any signed up member within a given radius, indicating they should head on down to the party. As parties become more populated, the radius of text messaging will expand. When parties reach a certain critical mass (indicated by people leaving as soon as they arrive), the text messages will begin to describe way-station locations (nearby locations where parties have emerged in the past) and redirect crowds to those locations, effectively forming satellite parties to the original event. The service will be free to standard members, but commercial subscribers (drinks /food providers, bands, freelance bouncers) will also sign up to find out where the next party is. Commercial subscribers may promote venues and may send messages to participants offer incentives to come to their club to get a quorum established – although the present system will only allow them to issue invitations in three categories – discount, offer (such as free drink), information only (where no special offer takes place). Commercial subscribers may be associated with a number of venues and some may own other commercial subscribers. Standard Quorum members receive alerts telling them only the location of the party and need only provide their basic contact details. Quorum members who regularly attend large parties automatically become full members. Full members must submit some detailed biographical information (including their date of birth, contact address). Furthermore, full members who regularly start big parties are called “Party Animals”. Party animals may also list their musical and food preferences. Occasionally party animals get discounted (even free) subscription charges, but you should note that whether a person is a “party animal” or not is determined by the system, not the customer. You should keep track of when a full member became a party animal. Full members can also become gold members. This is based on one condition and a number of business factors. The condition is that they should regularly bring more than two people to parties they attend. The business factors are the duration of membership and number of parties attended. Gold members are rated as one star, two stars or three stars depending on the above business factors. Full members can be a party animals and gold members at the same time. Members will interact with the system online. You are to design and build a database system to support this service and a prototype web front end for certain specific operations. Devices will receive and store local configuration information about the member in an XML document. For example, a user can request information from the DB on his/her profile such as personal information, parties attended, etc. The system will send an XML message to configure the user device. You are to develop a DTD schema and exemplar document of the configuration file. Please note: The system providing geographical information and calculating when parties are occurring will be provided by others (i.e. outside the scope of the system). They will update your system when parties occur and who is attending – you must simply provide relations for them to update (however you may need to fill in some dummy data to test your system). Deliverables D1. One A4 page containing the conceptual data model diagram (i.e. an Entity Relationship Diagram using consistently either Chen or UML notation showing: Relevant entity type, The primary key for each entity, Relationship Type with role name (plus any relationship attributes if any) Structural constraints on 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. D2. For the above model, produce the logical data model (the relational schema) (one A4 page). The model represents your mapping from the conceptual model into a relational schema and 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. D3. One A4 page containing a normalised set of relations with all attributes listed. On the same page, state clearly any assumptions 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: D4. Create a database for the above schema in Oracle DBMS using SQL and populate each table with typical records to clearly demonstrate the application results. D5. The SQL code for the creation scripts and population scripts used in D4. The SQL queries used to fulfil applications A1-A6. Note: you should populate your database sufficient to clearly and unambiguously demonstrate the applications A1-A6 mentioned above. D6. For application A6 above, create a Master/Detail form to run the application. D7. DTD and XML instance document as described in A7. D8. Using Oracle Form Developer create a simple form to enable new users to register. A new user will register their email address and telephone number. Duplicate email, telephone number combinations will be rejected. The form should have two buttons on it – one to commit a new user to the database and one to exit the form/move to a different form.