1

2

3

Assumptions and Business Rules

In the coursework’s specification, only the overall situation is described and some important

information for data is missing. Thus, while implementing quorum party database system described in

coursework, we had to make appropriate assumptions in order to complete the whole system successfully.

Firstly, we had to consider which information must be kept. Since party goers, commercial

subscribers, parties, invitation messages and venues are the roots of the described system, we decided to

record the detailed facts of them. Moreover, we assumed the respective data for the activity between party

goers and party, party details about organizing party by commercial subscriber, which commercial

subscriber creates which invitation and does business with which venue, invitation details showing which

message goes to which members and the link between party and venue.

In analyzing this system, we realized that there are two kinds of party goers although there are

four categories under full member like party animals or gold members or both or none. Whoever registers

for party service must be a standard or a full party goer. For standard ones, we suppose that it is a good

idea to record the data concerned with their preferred party type and party day because it will be useful

for sending invitations if there is a party suitable with their preferences. In contrast, we assumed to save

some specific data of full members as they become our regular members. This data includes their

occupation, preferred food and music, DOB, address, full member type and subscription discount which

will be varied in accordance with full member type and gold member level (one or two or three stars).

Another significant thing to take account of is the type of data for party. To celebrate a party, it is

important to define start and end time, place, party type (cocktail party, disco party, etc) and party size to

let the system knows which members regularly attend large party so that it can decide whether a member

should be full member or not. In addition, we believe that serviced items provided by commercial

subscribers such as types of food and drink must be stored for party details. Member attendance is also

necessary for a party and we must save each member’s arrival time to a party and the party service

(standard or VIP) bought by him/her. Besides, we also have to think about the data for invitation because

it is the inspiration to all members for getting involved in a party. We found that the creator of a message,

its description which let everyone knows where, when and what type of party it is, dress code and

invitation category (offer or information only or discount) should be taken into consideration.

After imagining the type of data, some business rules as well as relationships between entities are

required to be identified. So, we assumed that a member may receive none or more than one messages

and he/she may attend none or more than one parties. Although a commercial subscriber may make none

or more than one invitation messages, an invitation message can only have one commercial subscriber.

Likewise, there is the same activity between venue and party. According to coursework’s scenario, we

can infer that an invitation message must send to at least three members. Consequently, a party would

have at least three attendances. But, in our opinion, having only three attendances is too few to throw a

party and we presumed that there should be at least 8 persons. There is also a possibility that a

commercial subscriber may have none or more than one venue which he/she promotes and vice versa.

Unlike other relationships, we observed that an invitation message must express about at least and at most

one party although a party can have one or more invitation messages. To sum up, we created this database

system based on our assumptions explained above and some facts from the context of coursework.

4

2. Conceptual Data Model of Quorum Party Database System

InvitationDetails partyGoerpartyGoer

Attendance

Standard Full

Party

AnimalGold

d

o

InvitingMessage

Commercial

SubscriberPartyDetails Party

VenueVenue

Management

receive participate

create

record

accept

haspromote

hold

consist ofdeal with

own

ow

ner

em

plo

yee

describe

1M 1

1

1

M

M

M

M 11

1

M

M M 1

1 M

1

1

1

M

M

M

partyGoerID partyGoerID partyID

partyID

venueIDCSubscriberID venueID

CSubscriberID

invitingMsgID

invitingMsgID partyGoerID

partyID CSubscriberID

age

total

Attendance

membership

Duration

(3,M) (0,M) (0,M) (3,M)

(3,M)

(1,M)

(1,1)

(1,M)

(1,1)

(0,M)

(0,M) (1,1) (1,1) (1,M)

(0,M)

(1,1)

(0,M)(1,1)

(0,M)

(1,1)

(0,M)

(1,1)

5

3. Relational Schema

PartyGoer (partyGoerID, registrationDate, fullName, title, maritalstatus, gender, email, contactPh,

userAlias, password, remark)

Standard (partyGoerID, preferedPartyType, preferredPartyDay)

Full (partyGoerID, F_partyGoerDate, occupation, DOB, age, address, membershipDuration,

F_partyGoerType, P_animalDate, foodChoice, musicChoice, subscriptionDiscount,

G_partyGoerDate, G_partyGoerLevel, drinkChoice)

PartyGoerAttendance (partyGoerID, partyID, arrivalTime, boughtPartyService, remark)

Party (partyID, partyType, partySize, totalAttendance, partyDate, startTime, endTime, partyRemark,

*venueID)

PartyDetails (CSID, partyID, servicedItemsByCS, remark)

Venue (venueID, registrationDate, venueType, venueName, contactPh, address, postcode, venueRemark)

CommercialSubscriber (CSID, registrationDate, CS_category, CS_name, email, contactPh, address,

userAlias, password, remark, *ownerID)

VenueManagement (venueID, CSID, managingStartDate, managementRemark)

InvitingMessage (invitingMsgID, msgCreatingDate, invitationCategory, dressCode, messageDescription,

*CSID, *partyID)

InvitationDetails (invitingMsgID, partyGoerID, msgSentDate, remark)

6

4. Normalization

Normalization of Party Goer Attendance Form

Party Goer Attendance FormParty Date:

Party ID:

Venue ID:

Party Type:

Party Size:

Total Attendance:

Start Time:

End Time:

Party Remark:

Party Goer ID Arrival Time Bought Party Service Remark

SEE APPENDIX (PG-21)

PartyID PartyDate VenueID PartyType PartySize TotalAttendance StartTime EndTime PartyRemark

VenueID RegistrationDate VenueType VenueName ContactPhone Address PostCode VenueRemark

PartyGoerIDRegistrationDateFullNameTitle MaritalStatus Gender Email ContactPh UserAlias Password Remark

PartyID PartyGoerID ArrivalTime BoughtPartyService Remark

7

SQL Code

A1. List of members for each gender

SELECT vn.venueName, pgo.gender, count(*) AS TotalPartyGoers

FROM Venue AS vn, Party AS p, PartyGoerAttendance AS pga, PartyGoer AS pgo

WHERE DatePart("yyyy",p.partyDate)=2011 And DatePart("m",p.partyDate)=1 And vn.address Like

"*London*" And vn.venueID=p.venueID And p.partyID=pga.partyID And

pga.partyGoerID=pgo.partyGoerID

GROUP BY vn.venueName, pgo.gender;

A2. List of venues having over two parties last year

SELECT vn.venueName, vn.postcode, count(*) AS TotalParties

FROM Venue AS vn, Party AS p

WHERE vn.venueID=p.venueID And DATEPART("yyyy",p.partyDate)=2011

GROUP BY vn.venueName, vn.postcode

HAVING COUNT(*)>2

ORDER BY COUNT(*) DESC , vn.venueName;

A3. List of members who are party animals but not gold members including date of becoming party

animal

SELECT pgo.partyGoerID, pgo.fullName, f.P_animalDate, Count(*) AS TotalAttendedParties

FROM PartyGoer AS pgo, [Full] AS f, PartyGoerAttendance AS pga, Party AS p

WHERE (((f.F_partyGoerType)='party animal') And DatePart("yyyy",f.P_animalDate)<2012 And

((f.partyGoerID)=pgo.partyGoerID) And ((pgo.partyGoerID)=pga.partyGoerID) And

((pga.partyID)=p.partyID))

GROUP BY pgo.partyGoerID, pgo.fullName, f.P_animalDate

ORDER BY Count(*) DESC;

A4. List of members who are party animals but not gold members plus day of becoming party

animal

SELECT pgo.partyGoerID, pgo.fullName, DatePart("d",f.P_animalDate) AS P_AnimalDate, Count(*)

AS TotalAttendedParties

FROM PartyGoer AS pgo, [Full] AS f, PartyGoerAttendance AS pga, Party AS p

WHERE (((f.F_partyGoerType)='party animal') And ((DatePart("yyyy",f.P_animalDate))<2012) And

((f.partyGoerID)=pgo.partyGoerID) And ((pgo.partyGoerID)=pga.partyGoerID) And

((pga.partyID)=p.partyID))

GROUP BY pgo.partyGoerID, pgo.fullName, f.P_animalDate

ORDER BY Count(*) DESC;

8

Screen Dumps both for running all Applications in D6 and for testing (D10)

9

10

11

Screen Dumps both for (D7-D9) and for testing (D10)

Screen Dumps for D7 and D10

We assume that there are two types of new user. First one is Standard Party Goers and second one

is commercial subscribers as they also have to register like party goers in order to know where another

party will be celebrated.

Standard Party Goer Registration Form

12

After entering and saving data

13

Commercial Subscriber Registration Form

14

After entering and saving data

15

Screen Dumps for D8 and D10

16

Invitation Report

17

Screen Dumps for D9 and D10

18

19

Venue Management Form

Before searching with commercial subscriber’s name

After searching with name (Walter Mann)

20

After searching with name (Bruno Louis)

21

22

Normalization of Inviting Message Form

Inviting Message Form

Message Creating Date:

Inviting Message ID:

Commercial Subscriber ID:

Party ID:

Invitation Category:

Dress Code:

Message Description:

Party Goer ID Message Sent Date Remark

InvitingMessageID MsgCreatingDate InvitationCategory DressCode MessageDescription CSID PartyID

InvitingMessageID PartyGoerID MessageSentDate Remark

CSID RegistrationDate CS_category CS_name Email ContactPh Address UserAlias Password Remark

PartyID PartyDate VenueID PartyType PartySize TotalAttendance StartTime EndTime PartyRemark

PartyGoerIDRegistrationDateFullNameTitle MaritalStatus Gender Email ContactPh UserAlias Password Remark

23

Normalization of Venue Management Form

Venue Management Form

Venue Registration Date:

Venue ID:

Venue Type:

Venue Name:

Contact Phone:

Address:

Postcode:

CSID Managing Start Date Management Remark

Venue Remark:

VenueID RegistrationDate VenueType VenueName ContactPhone Address PostCode VenueRemark

CSID RegistrationDate CS_category CS_name Email ContactPh Address UserAlias Password Remark

VenueID CSID ManagingStartDate ManagementRemark