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 )



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)


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)


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)



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.

Documents

K1221692