Database Design and Implementation Coursework by May Hnit Oo Khin

1. 1

2. 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.
3

4. 2. Conceptual Data Model of Quorum Party Database System
invitingMsgID partyGoerID partyGoerID partyGoerID partyID
M 1 1 M partyGoer
InvitationDetails receive partyGoer participate
(0,M) Attendance
(3,M) (0,M) (3,M)
d
M age
hold Standard Full
1 membership
invitingMsgID Duration
(1,M) o
M
Party
InvitingMessage Gold record
Animal
(1,1)
(1,1) 1
M
M describe 1
(3,M)
create (1,M)
CSubscriberID partyID
partyID CSubscriberID
1
total
(0,M) Attendance
Commercial 1 M M 1
deal with PartyDetails consist of Party
Subscriber (0,M) (1,1) (1,1) (1,M)
emp
er
(1,1)
own
M
loye
(1,1)
CSubscriberID venueID accept
e
(0,M) venueID
1 M
1
(0,M) (0,M)
own
1
M Venue M 1
promote has Venue
Management (1,1)
(1,1) (0,M)
4

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)
5

6. 4. Normalization
Normalization of Party Goer Attendance Form
Party Goer Attendance Form
Party 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
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
SEE APPENDIX (PG-21)
6

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;
7

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

9. 9

10. 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
11

12. After entering and saving data
12

13. Commercial Subscriber Registration Form
13

14. After entering and saving data
14

15. Screen Dumps for D8 and D10
15

16. Invitation Report
16

17. Screen Dumps for D9 and D10
17

18. 18

19. Venue Management Form
Before searching with commercial subscriber’s name
After searching with name (Walter Mann)
19

20. After searching with name (Bruno Louis)
20

21. 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
22

23. Normalization of Venue Management Form
Venue Management Form
Venue Registration Date:
Venue ID:
Venue Type:
Venue Name:
Contact Phone:
Address:
Postcode:
Venue Remark:
CSID Managing Start Date Management 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
23