K1221692
-
Upload
a-hassan-azimi -
Category
Documents
-
view
16 -
download
1
Transcript of K1221692
I
Database Report Advanced Database Systems: 2014 / 15
Name: Hassan Azimi
K Number: 1221692
II
TABLE OF CONTENTS
INTRODUCTION V
THE CONCEPTUAL DATA MODEL 2
THE CLASS DIAGRAM 2 ASSUMPTIONS 3 MAJOR DESIGN DECISIONS 4
THE RELATIONAL DATA MODEL 6
DATA DICTIONARY 7
MAJOR DESIGN DECISIONS 12
IMPLEMENTATION 13
PRODUCTION TABLE 13 PRODUCTION_TYPE TABLE 14 PERFORMANCE TABLE 15 VOLUNTEER_STAFF TABLE 16 AVAILABILITY TABLE 17 DUTIES TABLE 18 MEMBERS TABLE 19 CUSTOMERS TABLE 20 BOOKINGS TABLE 21 PAYMENTS TABLE 22 TICKETS TABLE 23 SEATS TABLE 24 SEAT_STATUS TABLE 25 ROWS TABLE 26 BLOCKS TABLE 27 PRICES TABLE 28 PRICE_BAND TABLE 29 ASSIGN_HELPERS TABLE WITH COMPOSITE KEY 30
CONSTRAINTS 31
PRODUCTION AND PRODUCTION_TYPE TABLES 31
III
AVAILABILITY AND VOLUNTEER_STAFF TABLES 32 MEMBERS AND CUSTOMERS TABLES 33 VOLUNTEER_STAFF AND MEMBERS TABLE 34 BOOKINGS AND CUSTOMERS TABLES 35 PAYMENTS AND BOOKINGS TABLES 36 BOOKINGS AND TICKETS TABLE 37 TICKETS AND PERFORMANCE TABLES 38 TICKETS AND SEATS TABLES 39 SEATS AND SEATS_STATUS TABLES 40 SEATS AND ROWS TABLES 41 ROWS AND BLOCKS TABLES 42 PRICE_BAND AND BLOCKS TABLES 43 PRICE AND PRICE_BAND TABLES 44 PRODUCTION AND PRICE TABLES 45 DUTIES AND PRODUCTION_TYPE TABLES 46 ASSIGN_HELPERS AND PERFORMACE TABLES 47 ASSIGN_HELPERS AND DUTIES TABLES 48 ASSIGN_HELPERS AND VOLUNTEER_STAFF TABLES 49
FUNCTIONAL QUERIES 50
7 QUERY FOR DATABASE FUNCTIONALITY DEMONSTRATION 50 5 QUERY FOR DATABASE CONSTRAINT DEMONSTRATION 57
CONCLUSION 62
IV
TABLE OF FIGURES Figure 3 - Production Table Snapshot ------------------------------------------------------------------------------------- 13 Figure 4 - Production Type Table Snapshot ------------------------------------------------------------------------------- 14 Figure 5 - Performance Table Snapshot ----------------------------------------------------------------------------------- 15 Figure 6 - Volunteer Staff Table Snapshot --------------------------------------------------------------------------------- 16 Figure 7 - Availability Table Snapshot ------------------------------------------------------------------------------------- 17 Figure 8 – Duties Table Snapshot ------------------------------------------------------------------------------------------- 18 Figure 9 - Members Table Snapshot ---------------------------------------------------------------------------------------- 19 Figure 10 - Customers Table Snapshot ------------------------------------------------------------------------------------- 20 Figure 11 - Bookings Table Snapshot -------------------------------------------------------------------------------------- 21 Figure 12 - Payments Table Snapshot -------------------------------------------------------------------------------------- 22 Figure 13 - Tickets Table Snapshot ----------------------------------------------------------------------------------------- 23 Figure 14 - Seats Table Snapshot ------------------------------------------------------------------------------------------- 24 Figure 15 - Seat Status Table Snapshot ------------------------------------------------------------------------------------ 25 Figure 16 - Rows Table Snapshot ------------------------------------------------------------------------------------------- 26 Figure 17 - Blocks Table Snapshot ----------------------------------------------------------------------------------------- 27 Figure 18 - Prices Table Snapshot ------------------------------------------------------------------------------------------ 28 Figure 19 - Price Band Table Snapshot ------------------------------------------------------------------------------------ 29 Figure 20 - Assign Helpers Table Snapshot ------------------------------------------------------------------------------- 30 Figure 21 - Production and Production Type Constraint ---------------------------------------------------------------- 31 Figure 22 - Availability and Volunteer Staff Constraint ----------------------------------------------------------------- 32 Figure 23 - Members and Customers Constraint ------------------------------------------------------------------------- 33 Figure 24 – Volunteer Staff and Members Constraint ------------------------------------------------------------------- 34 Figure 25 - Bookings and Customers Constraint ------------------------------------------------------------------------- 35 Figure 26 – Payments and Bookings Constraint -------------------------------------------------------------------------- 36 Figure 27 - Bookings and Tickets Constraint ------------------------------------------------------------------------------ 37 Figure 28 - Tickets and Performance Constraint ------------------------------------------------------------------------- 38 Figure 29 - Tickets and Seats Constraint ---------------------------------------------------------------------------------- 39 Figure 30 - Seats and Seat Status Constraint ------------------------------------------------------------------------------ 40 Figure 31 - Seats and Rows Constraint ------------------------------------------------------------------------------------ 41 Figure 32 - Rows and Blocks Constraint ----------------------------------------------------------------------------------- 42 Figure 33 - Price Band and Blocks Constraint ---------------------------------------------------------------------------- 43 Figure 34 - Price and Price Band Constraint ----------------------------------------------------------------------------- 44 Figure 35 - Production and Price Constraint ----------------------------------------------------------------------------- 45 Figure 36 - Duties and Production Type Constraint --------------------------------------------------------------------- 46 Figure 37 - Performance and Assign Helpers Constraint --------------------------------------------------------------- 47 Figure 38 - Assign Helpers and Duties Constraint ----------------------------------------------------------------------- 48 Figure 39 - Assign Helpers and Volunteer Staff Constraint ------------------------------------------------------------- 49 Figure 40 - Reading from Performance Table ---------------------------------------------------------------------------- 50
V
Figure 41 - Updating a Seats' Row Query --------------------------------------------------------------------------------- 51 Figure 42 - After Updating the Seats' Row --------------------------------------------------------------------------------- 51 Figure 43 - Before Deleting a Row ----------------------------------------------------------------------------------------- 52 Figure 44 - Deleting Query -------------------------------------------------------------------------------------------------- 52 Figure 45 - After Deletion Query (The Result) ---------------------------------------------------------------------------- 52 Figure 46 - Before Inserting Data Into Performance Table ------------------------------------------------------------- 53 Figure 47 - Inserting Data Query Snapshot ------------------------------------------------------------------------------- 53 Figure 48 - After Inserting Data Query (The Result) --------------------------------------------------------------------- 53 Figure 49 - Inserting NULL Value ------------------------------------------------------------------------------------------ 54 Figure 50 - Number of Tickets For Every Performance ----------------------------------------------------------------- 55 Figure 51 - Trying to Insert NULL Value Into a Not Nullable Column ------------------------------------------------ 56 Figure 52 - Trying to Inset Data and Using a Foreign Key With No Parent ------------------------------------------ 57 Figure 53 - Trying to Leave Out Primary Key To See If NULL Can Be inserted ------------------------------------- 58 Figure 54 - Joining 3 Tables Using WHERE Clause --------------------------------------------------------------------- 59 Figure 55 - Before Trying To Violate a UNIQUE Constraint ----------------------------------------------------------- 60 Figure 56 - Error After Trying to Violate a UNIQUE Constraint ------------------------------------------------------ 60 Figure 57 - Joining 4 Tables Using INNER JOIN ON ------------------------------------------------------------------- 61
TABLE OF TABLES Table 1 - Availability ----------------------------------------------------------------------------------------------------------- 8 Table 2 - Blocks ----------------------------------------------------------------------------------------------------------------- 8 Table 3 - Bookings -------------------------------------------------------------------------------------------------------------- 8 Table 4 - Customers ------------------------------------------------------------------------------------------------------------ 8 Table 5 - Duties ----------------------------------------------------------------------------------------------------------------- 9 Table 6 - Members -------------------------------------------------------------------------------------------------------------- 9 Table 7 - Payments ------------------------------------------------------------------------------------------------------------- 9 Table 8 - Performance --------------------------------------------------------------------------------------------------------- 9 Table 9 - Price Band Table ---------------------------------------------------------------------------------------------------- 9 Table 10 - Prices --------------------------------------------------------------------------------------------------------------- 10 Table 11 - Production --------------------------------------------------------------------------------------------------------- 10 Table 12 - Production Type -------------------------------------------------------------------------------------------------- 10 Table 13 - Rows ---------------------------------------------------------------------------------------------------------------- 10 Table 14 - Seat Status --------------------------------------------------------------------------------------------------------- 10 Table 15 - Seats ---------------------------------------------------------------------------------------------------------------- 10 Table 16 - Tickets -------------------------------------------------------------------------------------------------------------- 11 Table 17 - Volunteer Staff ---------------------------------------------------------------------------------------------------- 11 Table 18 - Assign Helper Table --------------------------------------------------------------------------------------------- 11
1
INTRODUCTION The purpose of this document is to design and implement a relational Oracle Database
Management System for a theatre company called Raleigh Theatre, which is a small
provincial theatre that stages plays, dance and musical productions catering for a wide variety
of audiences. Raleigh Theatre is a charitable trust, which, through an established programme
of grants, provides financial help and workshops to enable young performers to develop a
career in their chosen theatrical or musical profession. The proposed database management
system will administer seat bookings including the printing of tickets and production
schedules as required. In addition the system should be able to provide comprehensive
information on sales profiles as it is hoped that such information will assist the marketing
activities of the theatre.
The aim of this report is to demonstrate the proposed database for this particular
company to manage the functionalities with productions, booking, customers, seats, rows,
blocks, performance, staff and so on. The information will be gathered, read, analysed first
and then a conceptual class diagram will be generated based on the information provided.
After that, a relational data model will be provided based on the class diagram already
generated. Some major design decision will be discussed based on the decisions made during
the analysis and design before the implementation stage. The data dictionary, which is going
to be the tables representing the data type for every column of the database table will be
represented before the implementation stage to decide what data type must be implemented
for every column of the tables in order for database table to be able to work. Finally there will
be a conclusion at the end to show the critical evaluation of the final product and the entire
project. In this section there will be process of evaluating the result and the lessons learnt by
doing this project.
2
THE CONCEPTUAL DATA MODEL
THE CLASS DIAGRAM
Figure 1 - Class Diagram
-production_type_code (PK)+production_type_description
Production_Types
+block_code (PK)+block_description
Blocks
1
+row_number (PK)+block_code (FK)+seat_capacity
Rows1..*
1
+seat_number (PK)+row_number (FK)-seat_status_code (FK)
Seats
1..*
0..*
-ticket_number (PK)+seat_number (FK)+performance_id (FK)-booking_id (FK)+row_number+block_code+quantity+total_price
Tickets
0..*
1
-payment_id (PK)-booking_id (FK)+free_or_not
Payments
1 -booking_id (PK)-customer_id (FK)+booking_for_date+booking_made_date+booking_seat_count+payment_status
Bookings
0..*
1..*
-customer_id (PK)-first_name-last_name-address-post_code-email-mobile-student_status
Customers
1
1
-production_id (PK)-production_type_code (FK)+production_name+date_from+date_to+production_description+details
Productions
1
1..* 1 -duty_id (PK)-production_type_code (FK)+duties
Duties
-availability_id (PK)-voluneer_staff_id (FK)+date+time+name
Availability
0..*
-member_id (PK)-customer_id (FK)-first_name-last_name-username-passwordwilling_to_assist
Members
0..*
0..1
-seat_status_code (PK)+description
Seat_Status
1
1..*
-voluneer_staff_id (PK)-member_id (FK)+firstname+lastname
Volunteer_Staff 1
0..*
1..*
-performance_id (PK)-production_id (FK)+performance_date+performance_name+details
Performance1..*
1
1
+price_band_id (PK)+block_code (FK)
Price_Band
1..*
1
1
1
0..*
1
+price_id (PK)+price+price_band_id (FK)+production_id (FK)
Prices1..*
1..*
-duty_id (PK)-voluneer_staff_id (PK)performance_id (FK)
Assign_Helpers
1
1
1..*1..*
11..*
have >><< have
<< have
<< have
have >>
have >><< have
<< have
have >>
have >>
<<have
make >>
<< applies as
have >>
<< have
can choose to be >>
has >>
<< assigned to
<< assigned to
<< have
3
ASSUMPTIONS
1. Anyone can join as a customer for the theatre.
2. Customers can become members to get discount tickets although it is not
necessary.
3. Members can chose to become volunteer staff by filling the field willing_to
_assist and they can be added to Volunteer_Staff Table.
4. Volunteer staff can choose to have one or many availability by filling their
availability details into the Availability Table.
5. Every Production_Type can specify its duties into the Duties Table in order
to allow helpers to choose what duties they are willing to take for every
production type such as music, drama and etc.
6. Volunteers’ details such as Availability and Duties can be looked and
assign them to every Performance via Assign_Helpers Table. Every
Performance will have some helpers assigned by this table (with composite
key), which is the table between Duties and Volunteer_Staff tables.
7. Every Production_Type may have one or many Productions.
8. The Productions may have one or many Performance and Prices.
9. The Prices are related to Price_Band, therefore, prices must be chosen from
their bands such as price a, b, c or price d.
10. The Customers may have one or many Bookings.
11. The Bookings may have no or many Payments as bookings can be made
online, over the phone or in person, therefore, customers may or may not turn
up to pay and collect his or her ticket(s).
12. The Bookings that Customers make, can have zero or many Tickets.
13. The Performances can have many Tickets or no Tickets at all.
14. In Ticket details there must be the Seat number, Row number, Block number
along with the quantity and total_price for every Booking that
Customers make in order to let them find these details in their Tickets.
15. The Seats may have zero or many Tickets and every Seats belongs to only
one Rows and every row belong to only one Blocks.
16. Every seat must have one Seat_Status to show either is booked and reserved
or it is empty and ready. However, the Seat_Status can have one or many
Seats as every seat must have a status.
4
MAJOR DESIGN DECISIONS
Upon seeing the rows and the seats with the same numbers and characters, one of the
design decisions has been made was to dividing the seats, rows and blocks tables into three so
the implementation becomes much more effective. Between the staff, having a manager was
another aspect we should have decided because it was considered that every staff has a
manager but every manager does not only one but also has many staff. However, later it was
decided to not have a staff table, as there was assumed there is no need to store the staff
details into the staff table because staff are full time and they must do all the duties as they
are getting paid. Also it was decided to have volunteer staff table to store the members who
willing to assist to see what duties they are willing to take.
One of the major design decisions was after creating the Customer Table because they
can decide to become a member or not, consequently, another table was a requirement in
order to store customers who wanted to be a member into the database and because members
can decide whether they want to assist or not, a CHAR filed was a good idea so then if the filed
was Y then the answer would be yes they are willing to assist and if it was N it means no they
are not willing to assist and become a volunteer staff. Volunteer Staff Table have access to
every performance by Assign_Helpers Table, which is a composite key, however, the key
decision was to have another two tables for availabilities and duties such as Availability and
Duties Tables. Now, volunteer staff who are members willing to assist, have options to fill
out their availability into the Availability Table.
The last decision was decision for relationship between the Bookings and Ticket
Tables. It was determined first relationship between Bookings and Seats and also because
there is relationship between Bookings and Payments, Payments used to have relationship
with Tickets. However, it was decided that relationship between Bookings and Seats are not
needed along with relationship between Payments and Tickets. The decision was to only have
relationship between Bookings and Tickets because Seats has relationship with Tickets and
also Bookings has relationship with Payments.
There are some alternative designs to design some tables in this design. For instance,
the table Duties, there used to be fields such as collection_tickets,
ushering_customers, serving, looking_after and sound_lighting, which used to
represent the duties that every volunteer staff willing to take. These fields used to be CHAR
5
with CHECK IN constraint in the database. This value can be two types such as ether Y or
either N representing the duties helpers willing to take. The value N will represent that the
volunteer staff is not willing to take this specific job when he or she started to work for
production and the value Y will represent that the volunteer staff is willing to take this duty.
However, the other alternative could be that instead of the fields mentioned, which represent
the duties, there could only be one field with the VARCHAR2 data type in this table (Duties) for
every volunteer staff and the data in this field could be hand written in it as it is a text data.
This alternative could be beneficial because the duties could be added as many as they would
like to do and also there would not be any ALTERs for database table in case of any duty
change. Finally, it was decided that to have one filed for every helpers to show what duties
they are willing to take. As every production type have different sort of duties, therefore,
Production_Type table must have relationship with Duties table to show what duties every
production type have. Helpers who willing to assist could pick up these duties based on the
different production type and the data could be stored in a new table with composite key
called Assign_Helpers for every single performance. This table will store duties,
performance and volunteer staff details.
6
THE RELATIONAL DATA MODEL
Figure 2 - Relational Database Model Diagram
Duties*P duty_id NUMBER (5)*F production_type_code NUMBER (5)
duties VARCHAR2 (255 BYTE)
Duties_PK (duty_id)
Performance*P performance_id NUMBER (5)*F production_id NUMBER (5)
performance_date DATEperformance_name VARCHAR2 (255 BYTE)details VARCHAR2 (255 BYTE)
Performance_PK (performance_id)
Tickets*P ticket_number NUMBER (5)*F seat_number NUMBER (5)*F performance_id NUMBER (5)*F booking_id NUMBER (5)* row_number NUMBER (5)* block_code NUMBER (5)
quantity NUMBER (2)
Tickets_PK (ticket_number)
Bookings*P booking_id NUMBER (5)*F customer_id NUMBER (5)
booking_for_date DATEbooking_made_date DATEbooking_seat_count NUMBER (2)
Bookings_PK (booking_id)
Payments*P payment_id NUMBER (5)*F booking_id NUMBER (5)* free_or_not CHAR (1 BYTE)
Payments_PK (payment_id)
Production_Type*P production_type_code NUMBER (5)* description VARCHAR2 (255 BYTE)
Production_Type_PK (production_type_code)
Production*P production_id NUMBER (5)*F production_type_code NUMBER (5)
production_name VARCHAR2 (255 BYTE)date_from DATEdate_to DATEdescription VARCHAR2 (255 BYTE)
Production_PK (production_id)
Seat_Status*P seat_status_code NUMBER (5)
description VARCHAR2 (255 BYTE)
Seat_Status_PK (seat_status_code)
Seats*P seat_number NUMBER (5)*F row_number NUMBER (5)*F seat_status_code NUMBER (5)
Seats_PK (seat_number)
Rows*P row_number NUMBER (5)*F block_code NUMBER (5)
seat_capaciry NUMBER (2)
Rows_PK (row_number)
Prices*P price_id NUMBER (5)
price NUMBER (2,2)*F price_ban_id NUMBER (5)*F production_id NUMBER (5)
Prices_PK (price_id)
Customers*P customer_id NUMBER (5)
first_name VARCHAR2 (255 BYTE)last_name VARCHAR2 (255 BYTE)address VARCHAR2 (255 BYTE)post_code VARCHAR2 (255 BYTE)email VARCHAR2 (255 BYTE)mobile VARCHAR2 (255 BYTE)student_status CHAR (1 BYTE)
Customers_PK (customer_id)
Members*P member_id NUMBER (5)*F customer_id NUMBER (5)
first_name VARCHAR2 (255 BYTE)last_name VARCHAR2 (255 BYTE)
*U username VARCHAR2 (255 BYTE)* password VARCHAR2 (255 BYTE)
willing_to_assist CHAR (1 BYTE)
Members_PK (member_id)username (username)
username (username)
Blocks*P block_code NUMBER (5)
description VARCHAR2 (255 BYTE)
Blocks_PK (block_code)
Price_Band*P price_ban_id NUMBER (5)*F block_code NUMBER (5)
SYS_C00300897 (price_ban_id)
SYS_C00300897 (price_ban_id)
Volunteer_Staff*P volunteer_id NUMBER (5)*F member_id NUMBER (5)
first_name VARCHAR2 (255 BYTE)last_name VARCHAR2 (255 BYTE)
Volunteer_Staff_PK (volunteer_id)
Avai labi l i ty*P availability_id NUMBER (5)*F volunteer_id NUMBER (5)
date DATEtime DATEname VARCHAR2 (255 BYTE)
Availability_PK (availability_id)
Assign_Helpers*PF duty_id NUMBER (5)*PF volunteer_staff_id NUMBER (5)*F PERFORMANCE_ID NUMBER (5)
Assign_Helpers_PK (duty_id, volunteer_staff_id)
5,5
7
As the diagram above showing, the class diagram was converted to the relational data
model diagram quire certainly by creating the tables at first and then altering them and adding
foreign key constraints. Starting form Customers table, customers can make bookings and
payments and get their tickets. It is not necessary to mention that primary keys and foreign
keys can never be NULL. Therefore, except Customers table primary key, it has been decided
that all the fields can be NULL and by NULL it means a NULL value can be inserted for columns.
When interrogating the database with HTML, PHP, JavaScript and CSS it is possible to
validate the input fields and types from users before inserting into the database tables such as
Customers table. However, for the Members table, which has fields such as username and
password, it was decided that these fields could not be NULL and username must be unique
thus UNIQUE constraint added to the Members username filed.
Whilst there was discount price for students, it was also decided that in Customers table
we could have a field called student_status with the CHAR data type length of one. This
will allow the user to choose whether he or she is a student or not by inserting values such as
N or Y into this field. The same applies inside the Payment table for the field free_or_not
because price is free for volunteer staff. By looking into these CHAR fields, there could be
condition to decide what to do for instance with the free cost or student customer using
programming languages conditional statements. For every date it was decided to use DATE
data type for the tables with the fields such as booking_date, performance_date,
availability’s date and time, production’s date_from and date_to. It was decided to have
NUMBER data type for every primary key for convenient to remember and track although it
was possible to have other data types such as CHAR.
The previous design was having many to many relationship between Performance
Table and Volunteer_Staff Table as every volunteer staff can work for many performances
and every performance could have many volunteer staff. Also many to many relationship
between Duties and Performance tables made sense because every performance could have
many duties and the same applied for every duty. Therefore, the decision was to add another
table called Assign_Helpers as a composite key table, which could choose volunteer staff
with their duties selected and assigned to every performance. The helpers now can be chosen
by their duties and assigned to the performance taking into account that every production
type will have different duties.
8
DATA DICTIONARY
Table 1 - Availability
Availability No Column Name PK FK M Data Type
1 availability_id P Y NUMBER (5)
2 volunteer_id F Y NUMBER (5)
3 date Date (7)
4 time Date (7)
5 name VARCHAR (255 BYTE)
Table 2 - Blocks
Blocks No Column Name PK FK M Data Type
1 block_code P Y NUMBER (5)
3 description VARCHAR2 (255 BYTE)
Table 3 - Bookings
Blocks No Column Name PK FK M Data Type
1 booking_id P Y NUMBER (5)
2 customer_id F Y NUMBER (5)
3 booking_for_date Date (7)
4 booking_made_date Date (7)
5 booking_seat_count NUMBER (2)
Table 4 - Customers
Customers No Column Name PK FK M Data Type
1 customer_id P Y NUMBER (5)
2 first_name VARCHAR2 (255 BYTE)
3 last_name VARCHAR2 (255 BYTE)
4 address VARCHAR2 (255 BYTE)
5 post_code VARCHAR2 (255 BYTE)
6 email VARCHAR2 (255 BYTE)
7 mobile VARCHAR2 (255 BYTE)
8 student_status CHAR (1 BYTE)
9
Table 5 - Duties
Duties No Column Name PK FK M Data Type
1 duty_id P Y NUMBER (5)
2 production_type_code F Y NUMBER (5)
3 duties VARCHAR (255 BYTE)
Table 6 - Members
Members No Column Name PK FK M Data Type
1 member_id P Y NUMBER (5)
2 customer_id F Y )
3 first_name VARCHAR2 (255 BYTE)
4 last_name VARCHAR2 (255 BYTE)
5 username Y VARCHAR2 (255 BYTE) UNIQUE
6 password Y VARCHAR2 (255 BYTE)
7 willing_to_assist CHAR (1 BYTE)
Table 7 - Payments
Payments No Column Name PK FK M Data Type
1 payment_id P Y NUMBER (5)
2 booking_id F Y NUMBER (5)
3 free_or_not Y CHAR (1 BYTE)
Table 8 - Performance
Performance No Column Name PK FK M Data Type
1 performance_id P Y NUMBER (5)
2 production_id F Y NUMBER (5)
3 performance_date Date (7)
4 performance_name VARCHAR2 (255 BYTE)
5 details VARCHAR2 (255 BYTE)
Table 9 - Price Band Table
Price_Band No Column Name PK FK M Data Type
1 price_ban_id P Y NUMERIC (5)
2 block_code F Y NUMERIC (5)
10
Table 10 - Prices
Price No Column Name PK FK M Data Type
1 price_id P Y NUMERIC (5)
2 price NUMERIC (5,5)
3 price_ban_id F Y NUMERIC (5)
4 production_id F Y NUMERIC (5)
Table 11 - Production
Production No Column Name PK FK M Data Type
1 production_id P Y NUMBER (5)
2 production_type_code F Y NUMBER (5)
3 production_name VARCHAR2 (255 BYTE)
4 date_from Date (7)
5 date_to Date (7)
6 description VARCHAR2 (255 BYTE)
Table 12 - Production Type
Production_Type No Column Name PK FK M Data Type
1 production_type_code P Y NUMBER (5)
2 description Y VARCHAR2 (255 BYTE)
Table 13 - Rows
Rows No Column Name PK FK M Data Type
1 row_number P Y NUMBER (5)
2 block_code F Y NUMBER (5)
3 seat_capaciry NUMBER (2)
Table 14 - Seat Status
Seat_Status No Column Name PK FK M Data Type
1 seat_status_code P Y NUMBER (5)
2 description VARCHAR2 (255 BYTE)
Table 15 - Seats
Seats No Column Name PK FK M Data Type
11
Seats No Column Name PK FK M Data Type
1 seat_number P Y NUMBER (5)
2 row_number F Y NUMBER (5)
3 seat_status_code F Y NUMBER (5)
Table 16 - Tickets
Tickets No Column Name PK FK M Data Type
1 ticket_number P Y NUMBER (5)
2 seat_number F Y NUMBER (5)
3 performance_id Y NUMBER (5)
4 payment_id F Y NUMBER (5)
5 row_number Y NUMBER (5)
6 block_code Y NUMBER (5)
7 quantity NUMBER (2)
Table 17 - Volunteer Staff
Volunteer_Staff No Column Name PK FK M Data Type
1 volunteer_id P Y NUMBER (5)
2 member_id F Y NUMBER (5)
3 first_name VARCHAR2 (255 BYTE)
4 last_name VARCHAR2 (255 BYTE)
Table 18 - Assign Helper Table
Assign_Helpers No Column Name PK FK M Data Type
1 duty_id P F Y NUMERIC (5)
2 volunteer_staff_id P F Y NUMERIC (5)
3 Performance_id F Y NUMERIC (5)
12
MAJOR DESIGN DECISIONS
One of the major design decisions when converting the class diagram into relational
data model was having a table called Price_Band Table. With different price band such as a,
b, c and d, the confusion was between having any price for any blocks, there are four
different prices for blocks. Therefore, it was considered to have a table called Price_Band
between Prices Table and Block Table. This decision has changed all the design and
implementation.
Another aspect of design decision was assigning helpers from volunteer staff, who are
chosen from customers wanted to be members. Customers could apply for membership if
they would like to and members can choose to become volunteer staff. Volunteer staff will
have availability to represent when they are available to help. As every volunteer staff can
have one to many duties and every duty belong to one or many volunteer staff (many to many
relationship), therefore, this relationship can be resolved by a table called Assign_Helpers
(composite key) form getting its composite key from Duties and Performance Tables
because every performance will have one to many helpers. Also it was decided to connect
Duties Table to Production_Type because every production type such as music, drama and
etc. they have their own duties.
Alternative decision was designing stage between Customers, Bookings and Payments
tables. Assuming that every booking will have a payment either online, over the phone or
collection, therefore, the relationship is every booking may have zero to many payments but
payments can be done if the customer is booked first so every payment is associated with one
booking. All these decisions has changed the design and implementation and sometimes it
was considered to go back and design properly again before implementation.
With columns’ data type such as price, it was cogitated that the precision is 2 and scale
is 2 for the chosen data type and the data type was NUMBER (2,2). However, later when
storing a price larger than 50.00, it was researched that Maximum precision and/or scale is 38
so the data type was changed to NUMBER (5,5) to store the larger numbers.
Finally when inserting data into the tables, as PRIMARY KEYs were ENABLED in every
table, the decision was to start inserting data from the tables without any FOREIGN KEYs
because inserting data to the tables with a FOREIGN KEY need a parent table’s PRIMARY KEY
to be existed in order to fill out the child table’s FOREIGN KEY.
13
IMPLEMENTATION In this section the queries and screenshots of creating all 17 tables, which was designed
for this database is going to be represented and after creating tables there will be queries and
screenshots of constraint such as Foreign Keys will be represented.
PRODUCTION TABLE CREATE TABLE "Production" ( "production_id" NUMBER(5) NOT NULL, "production_type_code" NUMBER(5) NOT NULL, "production_name" VARCHAR2(255) NULL, "date_from" DATE NULL, "date_to" DATE NULL, "description" VARCHAR2(255) NULL, PRIMARY KEY ("production_id") );
Figure 3 - Production Table Snapshot
14
PRODUCTION_TYPE TABLE CREATE TABLE "Production_Type" ( "production_type_code" NUMBER(5) NOT NULL, "description" VARCHAR2(255) NOT NULL, PRIMARY KEY ("production_type_code") );
Figure 4 - Production Type Table Snapshot
15
PERFORMANCE TABLE CREATE TABLE "Performance" ( "performance_id" NUMBER(5) NOT NULL, "production_id" NUMBER(5) NOT NULL, "performance_date" DATE NULL, "performance_name" VARCHAR2(255) NULL, "details" VARCHAR2(255) NULL, PRIMARY KEY ("performance_id") );
Figure 5 - Performance Table Snapshot
16
VOLUNTEER_STAFF TABLE CREATE TABLE "Volunteer_Staff" ( "volunteer_id" NUMBER(5) NOT NULL, "member_id" NUMBER(5) NOT NULL, "first_name" VARCHAR2(255) NULL, "last_name" VARCHAR2(255) NULL, PRIMARY KEY ("volunteer_id") );
Figure 6 - Volunteer Staff Table Snapshot
17
AVAILABILITY TABLE CREATE TABLE "Availability" ( "availability_id" NUMBER(5) NOT NULL, "volunteer_id" NUMBER(5) NOT NULL, "date" DATE NULL, "time" DATE NULL, "name" VARCHAR2(255) NULL, PRIMARY KEY ("availability_id ") );
Figure 7 - Availability Table Snapshot
18
DUTIES TABLE CREATE TABLE "Duties" ( "duty_id" NUMBER(5) NOT NULL, "production_type_code" NUMBER(5) NOT NULL, "duties" VARCHAR2(255) NULL, PRIMARY KEY ("duty_id") );
Figure 8 – Duties Table Snapshot
19
MEMBERS TABLE CREATE TABLE "Members" ( "member_id" NUMBER(5) NOT NULL, "customer_id" NUMBER(5) NOT NULL, "first_name" VARCHAR2(255) NULL, "last_name" VARCHAR2(255) NULL, "username" VARCHAR2(255) NOT NULL, "password" VARCHAR2(255) NOT NULL, "willing_to_assist" CHAR(1) NULL, PRIMARY KEY ("member_id") );
Figure 9 - Members Table Snapshot
In the Member Table it is considered that the field username can be unique so this
query also was used:
ALTER TABLE "Members" ADD CONSTRAINT "username" UNIQUE ("username");
20
CUSTOMERS TABLE CREATE TABLE "Customers" ( "customer_id" NUMBER(5) NOT NULL, "first_name" VARCHAR2(255) NULL, "last_name" VARCHAR2(255) NULL, "address" VARCHAR2(255) NULL, "post_code" VARCHAR2(255) NULL, "email" VARCHAR2(255) NULL, "mobile" VARCHAR2(255) NULL, "student_status" CHAR(1) NULL, PRIMARY KEY ("customer_id") );
Figure 10 - Customers Table Snapshot
21
BOOKINGS TABLE CREATE TABLE "Bookings" ( "booking_id" NUMBER(5) NOT NULL, "customer_id" NUMBER(5) NOT NULL, "booking_for_date" DATE NULL, "booking_made_date" DATE NULL, "booking_seat_count" NUMBER(2) NULL, PRIMARY KEY ("booking_id") );
Figure 11 - Bookings Table Snapshot
22
PAYMENTS TABLE CREATE TABLE "Payments" ( "payment_id" NUMBER(5) NOT NULL, "booking_id" NUMBER(5) NOT NULL, "free_or_not" CHAR(1) NOT NULL, PRIMARY KEY ("payment_id") );
Figure 12 - Payments Table Snapshot
23
TICKETS TABLE CREATE TABLE "Tickets" ( "ticket_number" NUMBER(5) NOT NULL, "seat_number" NUMBER(5) NOT NULL, "performance_id" NUMBER(5) NOT NULL, "booking_id" NUMBER(5) NOT NULL, "row_number" NUMBER(5) NOT NULL, "block_code" NUMBER(5) NOT NULL, "quantity" NUMBER(2) NULL, PRIMARY KEY ("ticket_number") );
Figure 13 - Tickets Table Snapshot
24
SEATS TABLE CREATE TABLE "Seats" ( "seat_number" NUMBER(5) NOT NULL, "row_number" NUMBER(5) NOT NULL, "seat_status_code" NUMBER(5) NOT NULL, PRIMARY KEY ("seat_number") );
Figure 14 - Seats Table Snapshot
25
SEAT_STATUS TABLE CREATE TABLE "Seat_Status" ( "seat_status_code" NUMBER(5) NOT NULL, "description" VARCHAR2(255) NULL, PRIMARY KEY ("seat_status_code") );
Figure 15 - Seat Status Table Snapshot
26
ROWS TABLE CREATE TABLE "Rows" ( "row_number" NUMBER(5) NOT NULL, "block_code" NUMBER(5) NOT NULL, "seat_capaciry" NUMBER(2) NULL, PRIMARY KEY ("row_number") );
Figure 16 - Rows Table Snapshot
27
BLOCKS TABLE CREATE TABLE "Blocks" ( "block_code" NUMBER(5) NOT NULL, "description" VARCHAR2(255) NULL, PRIMARY KEY ("block_code") );
Figure 17 - Blocks Table Snapshot
28
PRICES TABLE CREATE TABLE "Prices" ( "price_id" NUMBER(5) NOT NULL, "price" NUMBER(5,5) NULL, "price_ban_id" NUMBER(5) NOT NULL, "production_id" NUMBER(5) NOT NULL, PRIMARY KEY ("price_id") );
Figure 18 - Prices Table Snapshot
29
PRICE_BAND TABLE CREATE TABLE "Price_Band" ( "price-‐ban_id" NUMBER(5) NOT NULL, "block_code" NUMBER(5) NOT NULL, PRIMARY KEY ("price_ban_id") );
Figure 19 - Price Band Table Snapshot
30
ASSIGN_HELPERS TABLE WITH COMPOSITE KEY CREATE TABLE "Assign_Helpers" ( "duty_id" NUMBER(5) NOT NULL, "volunteer_staff_id" NUMBER(5) NOT NULL, "performance_id" NUMBER(5) NOT NULL, PRIMARY KEY ("duty_id", "volunteer_staff_id") );
Figure 20 - Assign Helpers Table Snapshot
31
CONSTRAINTS In this section the constraint Foreign Key will be represented by the screen shots.
PRODUCTION AND PRODUCTION_TYPE TABLES ALTER TABLE "Production" ADD CONSTRAINT "fk_Production_Production_Type" FOREIGN KEY ("production_type_code") REFERENCES "Production_Type" ("production_type_code");
Figure 21 - Production and Production Type Constraint
32
AVAILABILITY AND VOLUNTEER_STAFF TABLES ALTER TABLE "Availability" ADD CONSTRAINT volunteer_availability FOREIGN KEY("volunteer_id") REFERENCES "Volunteer_Staff"("volunteer_id");
Figure 22 - Availability and Volunteer Staff Constraint
33
MEMBERS AND CUSTOMERS TABLES ALTER TABLE "Members" ADD CONSTRAINT member_fk FOREIGN KEY("customer_id") REFERENCES "Customers"("customer_id");
Figure 23 - Members and Customers Constraint
34
VOLUNTEER_STAFF AND MEMBERS TABLE ALTER TABLE "Volunteer_staff" ADD CONSTRAINT volunteer_member FOREIGN KEY("member_id") REFERENCES "Members"("member_id");
Figure 24 – Volunteer Staff and Members Constraint
35
BOOKINGS AND CUSTOMERS TABLES ALTER TABLE "Bookings" ADD CONSTRAINT booking_customer FOREIGN KEY("customer_id") REFERENCES "Customers"("customer_id");
Figure 25 - Bookings and Customers Constraint
36
PAYMENTS AND BOOKINGS TABLES ALTER TABLE "Payments" ADD CONSTRAINT payment_booking FOREIGN KEY("booking_id") REFERENCES "Bookings"("booking_id");
Figure 26 – Payments and Bookings Constraint
37
BOOKINGS AND TICKETS TABLE ALTER TABLE "Tickets" ADD CONSTRAINT tickets_bookings FOREIGN KEY("booking_id") REFERENCES "Bookings"("booking_id");
Figure 27 - Bookings and Tickets Constraint
38
TICKETS AND PERFORMANCE TABLES ALTER TABLE "Tickets" ADD CONSTRAINT tickets_performance FOREIGN KEY("performance_id") REFERENCES "Performance"("performance_id");
Figure 28 - Tickets and Performance Constraint
39
TICKETS AND SEATS TABLES ALTER TABLE "Tickets" ADD CONSTRAINT tickets_seats FOREIGN KEY("seat_number") REFERENCES "Seats"("seat_number");
Figure 29 - Tickets and Seats Constraint
40
SEATS AND SEATS_STATUS TABLES ALTER TABLE "Seats" ADD CONSTRAINT seats_status FOREIGN KEY("seat_status_code") REFERENCES "Seat_Status"("seat_status_code");
Figure 30 - Seats and Seat Status Constraint
41
SEATS AND ROWS TABLES ALTER TABLE "Seats" ADD CONSTRAINT seat_rows FOREIGN KEY("row_number") REFERENCES "Rows"("row_number");
Figure 31 - Seats and Rows Constraint
42
ROWS AND BLOCKS TABLES ALTER TABLE "Rows" ADD CONSTRAINT rows_blocks FOREIGN KEY("block_code") REFERENCES "Blocks"("block_code");
Figure 32 - Rows and Blocks Constraint
43
PRICE_BAND AND BLOCKS TABLES ALTER TABLE "Price_Band" ADD CONSTRAINT price_ban_blocks FOREIGN KEY("block_code") REFERENCES "Blocks"("block_code");
Figure 33 - Price Band and Blocks Constraint
44
PRICE AND PRICE_BAND TABLES ALTER TABLE "Prices" ADD CONSTRAINT price_price_ban FOREIGN KEY("price_ban_id") REFERENCES "Price_Band"("price_ban_id");
Figure 34 - Price and Price Band Constraint
45
PRODUCTION AND PRICE TABLES ALTER TABLE "Prices" ADD CONSTRAINT price_production FOREIGN KEY("production_id") REFERENCES "Production"("production_id");
Figure 35 - Production and Price Constraint
46
DUTIES AND PRODUCTION_TYPE TABLES ALTER TABLE "Duties" ADD CONSTRAINT duties_production_type FOREIGN KEY("production_type_code") REFERENCES "Production_Type"("production_type_code");
Figure 36 - Duties and Production Type Constraint
47
ASSIGN_HELPERS AND PERFORMACE TABLES ALTER TABLE "Assign_Helpers" ADD CONSTRAINT helpers_performance FOREIGN KEY("PERFORMANCE_ID") REFERENCES "Performance"("performance_id");
Figure 37 - Performance and Assign Helpers Constraint
48
ASSIGN_HELPERS AND DUTIES TABLES ALTER TABLE "Assign_Helpers" ADD CONSTRAINT helpers_duty FOREIGN KEY("duty_id") REFERENCES "Duties"("duty_id");
Figure 38 - Assign Helpers and Duties Constraint
49
ASSIGN_HELPERS AND VOLUNTEER_STAFF TABLES ALTER TABLE "Assign_Helpers" ADD CONSTRAINT helpers_volunteer FOREIGN KEY("volunteer_staff_id") REFERENCES "Volunteer_Staff"("volunteer_id");
Figure 39 - Assign Helpers and Volunteer Staff Constraint
50
FUNCTIONAL QUERIES In this section there will be 12 queries to show the database is fully functional. The first
seven queries will show the ability to insert data, read data, update and alter table within the
database to show the database is working and there is no problem with it. The second five
queries will show the constraint are not violated. There will be frequent table join together
and in some case 3 table join together for demonstration.
7 QUERY FOR DATABASE FUNCTIONALITY DEMONSTRATION -‐-‐ Reading Performance Table SELECT "Performance"."performance_id" AS "PERFORMANCE ID", "Performance"."production_id" AS "PRODUCTION", "Performance"."performance_date" AS "DATE", "Performance"."performance_name" AS "NAME", "Performance"."details" AS "DETAILS" FROM "Performance" ORDER BY "DATE";
Figure 40 - Reading from Performance Table
51
-‐-‐ Updating Seats’ Seat_Status UPDATE "Seats" SET "seat_status_code" = '1' WHERE "seat_number" = 22;
Figure 41 - Updating a Seats' Row Query
Figure 42 - After Updating the Seats' Row
52
Figure 43 - Before Deleting a Row
-‐-‐ Deleting from Availability Table DELETE FROM "Availability" WHERE "availability_id" = 4;
Figure 44 - Deleting Query
Figure 45 - After Deletion Query (The Result)
53
Figure 46 - Before Inserting Data Into Performance Table
-‐-‐ Inserting data into Performance Table INSERT INTO "Performance" ( "performance_id", "production_id", "performance_date", "performance_name", "details"
) VALUES ( '7', '1',
TO_DATE('2014-‐12-‐05 18:00:40', 'YYYY-‐MM-‐DD HH24:MI:SS'), 'Cold Play Music Festival', 'This will take place on O2 Arena' );
Figure 47 - Inserting Data Query Snapshot
Figure 48 - After Inserting Data Query (The Result)
54
-‐-‐ Inserting data in Customers Table and testing NULL columns -‐-‐ This will not be a problem as the column is nullable INSERT INTO "Customers" ( "customer_id", "first_name", "last_name"
) VALUES ( 10, 'James', 'William'
);
Figure 49 - Inserting NULL Value
In this query, which represents INSERT INTO query to insert data into the Customers
Table, Shows that Primary Key is working, and the Customers Table has 7 columns which 5
of them can be NULL. Therefore, in this query 3 columns inserted which the first one is
primary key and because data only inserted for 3 columns the rest of the columns will be
NULL as it is showing in the screenshot.
55
-‐-‐ Number of tickets sold for every performance name SELECT COUNT("Ticket"."ticket_number") AS "Number Of Tickets", "Performance"."performance_name" FROM "Tickets", "Performance" WHERE "Tickets"."performance_id"="Performance"."performance_id" GROUP BY "Performance"."performance_name";
Figure 50 - Number of Tickets For Every Performance
56
-‐-‐Trying to insert a NULL value to a column, which cannot be NULL
-‐-‐ This will give us an error Cannot accept NULL value INSERT INTO "Tickets" ( "ticket_number", "seat_number", "performance_id", "booking_id", "row_number", "block_code", "quantity" ) VALUES ( '6', '13', '2', NULL, '1', '2', '1' );
Figure 51 - Trying to Insert NULL Value Into a Not Nullable Column
57
5 QUERY FOR DATABASE CONSTRAINT DEMONSTRATION
-‐-‐ Trying to INESER data and using a FOREIGN KEY without a parent. This will show an error
INSERT INTO "Volunteer_Staff" ( "volunteer_id", "member_id", "first_name", "last_name" ) VALUES ( '4', '5', 'Hassan', 'Azimi' );
Figure 52 - Trying to Inset Data and Using a Foreign Key With No Parent
58
-‐-‐ Trying to leave out Primary Key, which will be NULL -‐-‐ This will give an error, as Primary Key cannot be NULL INSERT INTO "Customers" ( "first_name", "last_name", "address", "post_code", "email", "mobile", "student_status" ) VALUES ( 'Jamshid', 'Dehmeshki', '22 Kingston University', 'KU12 9UT', '[email protected]', '07543561332', 'N');
Figure 53 - Trying to Leave Out Primary Key To See If NULL Can Be inserted
59
-‐-‐ Production AND Production_Type Join using WHERE clause SELECT "Production_Type"."description" AS "PRODUCTION TYPE", "Production"."production_name", "Production"."date_from", "Production"."date_to", "Production"."description", "Production"."description" AS "PRODUCTION DESCRIPTION" FROM "Production_Type", "Production" WHERE "Production_Type"."production_type_code" =
"Production"."production_type_code";
Figure 54 - Joining 3 Tables Using WHERE Clause
60
Figure 55 - Before Trying To Violate a UNIQUE Constraint
-‐-‐ Trying to violate the UNIQUE constraint -‐-‐ This will give an error INSERT INTO "Members" ( "member_id", "customer_id", "first_name", "last_name", "username", "password", "willing_to_assist" ) VALUES ( '6', '4', 'James', 'Williams', 'hazimi', '123', 'N' );
Figure 56 - Error After Trying to Violate a UNIQUE Constraint
61
-‐-‐ Production_Type | Production | Assign_Helpers | Duties SELECT "Production_Type"."production_type_code" AS "PRODUCTION TYPE", "Production_Type"."description" AS "TYPE", "Production"."production_id" AS "PRODUCTION ID", "Production"."production_name" AS "NAME", "Duties"."duties" AS "DUTIES", "Assign_Helpers"."volunteer_staff_id" AS "VOLUNTEER ID", "Assign_Helpers".PERFORMANCE_ID AS "PERFORMANCE ID" FROM "Tickets" INNER JOIN "Bookings" ON "Bookings"."booking_id" = "Tickets"."booking_id" INNER JOIN "Customers" ON "Customers"."customer_id" = "Bookings"."customer_id" INNER JOIN "Payments" ON "Bookings"."booking_id" = "Payments"."booking_id", "Assign_Helpers" INNER JOIN "Duties" ON "Duties"."duty_id" = "Assign_Helpers"."duty_id" INNER JOIN "Production_Type" ON "Production_Type"."production_type_code" =
"Duties"."production_type_code" INNER JOIN "Production" ON "Production_Type"."production_type_code" =
"Production"."production_type_code" ORDER BY "VOLUNTEER ID";
Figure 57 - Joining 4 Tables Using INNER JOIN ON
62
CONCLUSION One of the aspects of working with database, which needs to be taken into account, is
the design stage strategy especially when working with reasonably big projects. Designing
the database with diagrams such as class diagram, ERD or data model diagram prevents the
frequent alter table when it comes to implementation and after that using the database with
languages such as PHP, .NET, Ruby on Rails, JSP and etc. It happened personally when
database design was not considered so important, the database usage with other languages
and framework completely changed the time and cost of implementation. Planning is the
most important aspect of database design. The results in databases that do not meet needs, do
not meet prospects, or are otherwise unmanageable. It is taught that before switching on the
computer using the tools and software of choice it is essential to sit down and, verify the
requirements, diagram the data, and plan the database. In this project the most time-
consuming part was designing the database other than implementation. The other aspect was
populating data for tables created. In this stage Oracle have an option to either enable the
foreign keys or disable them. In this project as all the foreign keys were enabled already,
therefore it was not possible to populate data inside any table randomly. For example it was
impossible to populate data into the Volunteer_Staff table without having any members
registered in the Members table. Now most of the Oracle 11g’s syntaxes were similar to
MySQL database other than column’s data type. In this project the last constraint was joining
four tables together and with Oracle 11g this was not an issue but with other databases such
as MySQL this sometimes will be frustrating when trying to join more than 2 tables together.
When using "AS" keyword (although it is not necessary) to give aliases to the column name
for the queries such as reading the table(s) using SELECT, it is important to remember that
when the alias or the name chosen has a space between, it must be surrounded with double
quote ("") in order to be able to work but with the short aliases this is not a problem. It is also
learnt that the design will not going to be perfect at the first time rather reading the
requirements, mind-mapping, and listing the needs will help the speed of the database design.
Reviewing back, reading the requirements and changing the plan should not be ignored and
also it is good to keep the design simple. Before adding more tables this is the most important
aspect of the design stage that the assumption with good reasons will be helpful if there is
anything to add to the design but keeping simple by looking at the primary requirement will
help to add to the database and design instead of altering it.