Get Instant Help From 5000+ Experts For
question

Writing: Get your essay and assignment written from scratch by PhD expert

Rewriting: Paraphrase or rewrite your friend's essay with similar meaning at reduced cost

Editing:Proofread your work by experts and improve grade at Lowest cost

And Improve Your Grades
myassignmenthelp.com
loader
Phone no. Missing!

Enter phone no. to receive critical updates and urgent messages !

Attach file

Error goes here

Files Missing!

Please upload all relevant files for quick & complete assistance.

Guaranteed Higher Grade!
Free Quote
wave

Introduction and Overview

Company Overview:

Midlands Theatre (MT) is a chain of small theatres that are found within the suburbs of several cities and towns within the Midlands, including Leicester and Birmingham. It specialises in high quality theatre productions that may be seen to be insufficiently “mainstream” for the general population. The company purchased its first theatre in January 1982, and since then has seen substantial increases in the number of clients that want to visit a local theatre to see a production that is more alternative to those typically found within the city centre theatres and/or large entertainment complexes. In response to the growing client base, MT sometimes offers a matinee (i.e., afternoon) performance of a popular production in addition to the traditional evening performance time.

Alongside the increase in number of theatre goers comes the issue of managing the additional bookings and ticketing requirements. The Managing Director of MT, Ms. Heritage, has decided that a computerised booking system for MT is needed. Although the ultimate aim is to enable the on-line booking of tickets for any MT productions at any MT theatres, Ms. Heritage would like a simple booking system to be created first. This first version booking system will automate the existing manual booking processes, which are detailed below.

Information regarding current booking processes at Midlands Theatre (MT):

Each of the theatres in MT’s portfolio has a schedule of productions for a given month in a particular calendar year. For instance, a schedule for a production entitled “Wind Blows”, which ran for one week at the Cropston Theatre during March 2018, is provided in Table 1.

Table 1.  Example of one week performance at the Cropston Theatre

Name of Production

Day and Date

Afternoon

Evening

“Wind Blows”

Scriptwriters: William

Director: Henry

Monday 7/3/2018

No performance

7.30pm

 

Tuesday 8/3/2018

No performance

7.30pm

 

Wednesday 9/3/2018

2.30pm

7.30pm

 

Thursday 10/3/2018

No performance

7.30pm

 

Friday 11/3/2018

2.30pm

7.30pm

 

Saturday 12/3/2018

2.30pm

7.30pm

 

Sunday 13/3/2018

2pm – note earlier start

6.45pm – note earlier start

Only one production is shown at a theatre at a time, and some of the more popular productions run both afternoon (matinee) and evening performances.

Productions could be at a theatre for several weeks, although the majority of productions run only for a few days over one week. The run of the next production cannot start until the previous production has ended (in other words there is no interleaving of the performance runs of different productions).  It is common for the same production to have runs in all of MT’s theatres - one theatre after another - so that the widest number of potential clients for a production is reached.

When a potential theatre goer wants to purchase a ticket for a particular performance of a production at a MT theatre in advance, s/he contacts the central booking service via the website, telephone or an App. Whenever a ticket is purchased, a unique purchase number is allocated, the performance to be attended, the theatre, the client details (such as name, postcode and house number, and telephone), the total amount paid and the method of payment (cash, Paypal, debit card or credit card) and the method of ticket delivery (either by mail/email or by client pick up from the local theatre box office) are recorded. If several tickets are bought at the same time by the same person, each ticket is recorded as if it were bought separately.  

Table 2. Further Information about each Entity (Type) on the EER Diagram

Entity Type

Entity Instance

Theatre

A particular MT theatre e.g., Cropston

Production

A particular production e.g., How the Wind Blows

Performance

A particular performance of a production run, e.g., a performance of Wind Blows at Cropston Theatre on Monday 7/3/18 at 7.30pm

Client

A particular client of a theatre e.g., Mr Eric Charles

TicketPurchase

A particular ticket bought for a particular performance e.g., Ticket Purchase No. 29, which is for Cropston Theatre for the 9/3/18 performance  at 7.30pm of  Wind Blows and is bought by Ms Helen w2544.

Any remaining tickets for a performance are available to buy on the day from the local theatre box office. The same details are recorded, although clearly in this case the ticket will always be collected from the local theatre box office!

A relational database has been created according to the ERD.  The tables

are as follows:

  • Theatre(Theatre#, Name, Address, MainTel);
  • Production(P#, Title, ProductionDirector, PlayAuthor);
  • Performance(Per#, P#, Theatre#, pDate, pHour, pMinute, Comments);
  • Client(Client#, title, name, address, telNo, e-mail);
  • TicketPurchase(Purchase#, Client#, Per#, PaymentMethod, DeliveryMethod, TotalAmount).

Having established the online transaction processing database, Ms. Heritage wants more intelligence information from the available data and she is looking for a potential data warehouse for MT.  As the first step in this process, she expects to setup a data mart for ticket sales as the first step.  The data mart should satisfy the following analysis requirements:

  • Yearly total sale for each theatre.
  • All clients who visited MT theatres in at least 4 different months in a year.
  • List the titles, production directors and play authors of all products with the highest total sale.

Here, by ticket sale value, we refer to the value of money rather than number of tickets.  For this data mart, only the data involved in ticket sales are stored, and any data not involved in at least one ticket sale should not be included.

You can access the OLTP database in my database schema: ops$yyang00.  For example, you can access the data for Theatres using the following SQL statement:

select * from ops$yyang00.theatre;

You are to develop a prototype of ORACLE data mart for ticket sales as a part of a potential data warehouse for MT.  For this assignment you are required to work individually.

You have been given the MT company scenario, together with an Extended Entity Relationship (EER) Diagram and corresponding tables for the existing relational database. 

Task 1: Analyse the given database design and the requirement for data mart, identify the dimensions and fact for your data mart  

Task 2: Design the star schema for the data mart and identify the corresponding PKs and FKs  

Task 3: According to given data and requirements, determine the relevant attributes and suitable granularity in your data mart  

Task 4: Map your star schema to logical relations  

Task 5: Create the corresponding tables in Oracle using SQL

Task 6: Identify your source data from the OLTP database and design your data extraction rules.  You need to give a detailed mapping and transformation list from the source to the destination.

Task 7: Implement your data extraction, transformation and loading through Oracle SQL.  The number of rows extracted into each dimension or fact table in your data mart should be printed from Oracle query.

Task 8: Comment on how your data mart satisfies the requirements of MT.  Implement the required data analysis requirements for both data mart and the original OLTP database.  Compare your queries and comments on the advantages of data mart in analysis operations. Test results from Oracle query should be included.

Evidence of the successful execution of your queries is required.  For large outputs, you need to provide only the last page of outputs with the number of rows in the end.

Introduction and Overview

Identification of dimension tables are based on the dimensions that are the companion of the facts for a warehouse. These attributes present in the dimension table is used later for making the queries and data retrieval. The dimension tables identified here are DimClient (stores client details), DimProduction (stores production details of the plays), DimTheatre (stores theatre details), DimCalendar (This dimension table has been created to store each day, week, month, date month name, etc. in a year that act as a whole calendar), DimShowtime (stores show times and names of the performance).

Identification of the fact tables has been done on the basis of the measurements, facts and amount details of the business. The table used for facts has been named FactPerformance here. It stores the foreign key of all the dimension tables along with the amounts, methods, and dates. It is used for analytical evaluation of the business.

Figure 1: Star Schema of Data Mart

Source: created by author

 

Figure 2: Logical relations between the entities in Data Mart

Source: created by author

DimTheatre

CREATE TABLE DimTheatre (

  TheatreID VARCHAR(10) NOT NULL,

  Name VARCHAR(45) NULL,

  Address VARCHAR(45) NULL,

  MainTel INT NULL,

  PRIMARY KEY (TheatreID));

DimProduction

CREATE TABLE DimProduction (

  Pid VARCHAR(10) NOT NULL,

  Title VARCHAR(45) NULL,

  PDirector VARCHAR(45) NULL,

  Playauthor VARCHAR(45) NULL,

  PRIMARY KEY (Pid));

DimShowtime

CREATE TABLE DimShowTime (

  Name VARCHAR(45) NULL,

  Hour number(2) NULL,

  Minute number(2) NULL,

  PRIMARY KEY (hour,minute));

DimClient

CREATE TABLE DimClient (

  ClientID VARCHAR(10) NOT NULL,

  Title VARCHAR(45) NULL,

  Name VARCHAR(45) NULL,

  street varchar(45) not null,

  town   varchar(45) not null,

  country varchar(45) not null,

  Telno INT NULL,

  email VARCHAR(45) NULL,

  PRIMARY KEY (ClientID));

DimCalendar

CREATE TABLE DimCalendar AS

WITH base_calendar AS

  (SELECT CurrDate          AS Day_ID,

    1                       AS Day_Time_Span,

    CurrDate                AS Day_End_Date,

    TO_CHAR(CurrDate,'Day') AS Week_Day_Full,

    TO_CHAR(CurrDate,'DY')  AS Week_Day_Short,

    TO_NUMBER(TRIM(leading '0'

  FROM TO_CHAR(CurrDate,'D'))) AS Day_Num_of_Week,

    TO_NUMBER(TRIM(leading '0'

  FROM TO_CHAR(CurrDate,'DD'))) AS Day_Num_of_Month,

    TO_NUMBER(TRIM(leading '0'

  FROM TO_CHAR(CurrDate,'DDD'))) AS Day_Num_of_Year,

    UPPER(TO_CHAR(CurrDate,'Mon')

    || '-'

    || TO_CHAR(CurrDate,'YYYY')) AS Month_ID,

    TO_CHAR(CurrDate,'Mon')

    || ' '

    || TO_CHAR(CurrDate,'YYYY') AS Month_Short_Desc,

    RTRIM(TO_CHAR(CurrDate,'Month'))

    || ' '

    || TO_CHAR(CurrDate,'YYYY') AS Month_Long_Desc,

    TO_CHAR(CurrDate,'Mon')     AS Month_Short,

    TO_CHAR(CurrDate,'Month')   AS Month_Long,

    TO_NUMBER(TRIM(leading '0'

  FROM TO_CHAR(CurrDate,'MM'))) AS Month_Num_of_Year,

    'Q'

    || UPPER(TO_CHAR(CurrDate,'Q')

    || '-'

    || TO_CHAR(CurrDate,'YYYY'))     AS Quarter_ID,

    TO_NUMBER(TO_CHAR(CurrDate,'Q')) AS Quarter_Num_of_Year,

    CASE

      WHEN TO_NUMBER(TO_CHAR(CurrDate,'Q')) <= 2

      THEN 1

      ELSE 2

    END AS half_num_of_year,

    CASE

      WHEN TO_NUMBER(TO_CHAR(CurrDate,'Q')) <= 2

      THEN 'H'

        || 1

        || '-'

        || TO_CHAR(CurrDate,'YYYY')

      ELSE 'H'

        || 2

        || '-'

        || TO_CHAR(CurrDate,'YYYY')

    END                      AS half_of_year_id,

    TO_CHAR(CurrDate,'YYYY') AS Year_ID

  FROM

    (SELECT level n,

      -- Calendar starts at the day after this date.

      TO_DATE('31/12/2017','DD/MM/YYYY') + NUMTODSINTERVAL(level,'DAY') CurrDate

    FROM dual

      -- Change for the number of days to be added to the table.

      CONNECT BY level <= 365

    )

  )

SELECT day_id,

  day_time_span,

  day_end_date,

  week_day_full,

  week_day_short,

  day_num_of_week,

  day_num_of_month,

  day_num_of_year,

  month_id,

  COUNT(*) OVER (PARTITION BY month_id)    AS Month_Time_Span,

  MAX(day_id) OVER (PARTITION BY month_id) AS Month_End_Date,

  month_short_desc,

  month_long_desc,

  month_short,

  month_long,

  month_num_of_year,

  quarter_id,

  COUNT(*) OVER (PARTITION BY quarter_id)    AS Quarter_Time_Span,

  MAX(day_id) OVER (PARTITION BY quarter_id) AS Quarter_End_Date,

  quarter_num_of_year,

  half_num_of_year,

  half_of_year_id,

  COUNT(*) OVER (PARTITION BY half_of_year_id)    AS Half_Year_Time_Span,

  MAX(day_id) OVER (PARTITION BY half_of_year_id) AS Half_Year_End_Date,

  year_id,

  COUNT(*) OVER (PARTITION BY year_id)    AS Year_Time_Span,

Identified Dimension Tables

  MAX(day_id) OVER (PARTITION BY year_id) AS Year_End_Date

FROM base_calendar

ORDER BY day_id;

alter table dimcalendar

add primary key (Day_id);

FactPerformance

CREATE TABLE FactPerformance (

  Ticktno VARCHAR(45) NOT NULL,

  TheatreID VARCHAR(10) NOT NULL,

  Pid VARCHAR(10) NOT NULL,

  showhour int NOT NULL,

showminute int not null,

  ClientID VARCHAR(10) NOT NULL,

  amount DECIMAL(10,2) NULL,

  Deliverymethod varchar(25) NOT NULL,

  PaymentMethod varchar(25) NOT NULL,

  PerformanceDate Date,

  PRIMARY KEY (Ticktno),

  CONSTRAINT fk_Performance_Theatre

    FOREIGN KEY (TheatreID)

    REFERENCES DimTheatre (TheatreID),

  CONSTRAINT fk_Performance_date

    FOREIGN KEY (performancedate)

    REFERENCES dimcalendar (day_ID),

  CONSTRAINT fk_Performance_Production1

    FOREIGN KEY (Pid)

    REFERENCES DimProduction (Pid),

  CONSTRAINT fk_Performance_Showtime1

    FOREIGN KEY (showhour,showminute)

    REFERENCES DimShowtime (hour,minute),

  CONSTRAINT fk_FactPerformance_DimClient1

    FOREIGN KEY (ClientID)

    REFERENCES DimClient (ClientID));

DimTheatre

Figure 3: Data sources mapped for Dimension table theatre

Source: created by author

DimClient

Figure 4: Data sources mapped for Dimension table client

Source: created by author

DimShowtime

Figure 5: Data sources mapped for Dimension table showtime

Source: created by author

DimProduction

 

Figure 6: Data sources mapped for Dimension table production

Source: created by author

FactPerformance

Figure 7: Data sources mapped for Fact table FactPerformance

Source: created by author

DimClient

insert into dimclient

select * from client;

Dimshowtime

insert into dimshowtime

select distinct  comments,phour, pminute from performance;

DimTheatre

insert into dimtheatre

select * from theatre;

DimProduction

insert into dimproduction

select * from production;

FactPerformance

insert into factperformance

select t.purchase, p.theatreid,p.p,

p.phour,p.pminute,t.clientid,t.totalamount,

t.deliverymethod,t.paymentmethod,p.pdate

from

performance p

inner join

ticketpurchase t

on t.per=p.per;

Query1

select sum(fp.amount) as "Total Sales",

extract(year from fp.performancedate) as "Year",

dt.name from factperformance fp

inner join dimtheatre dt on

dt.theatreid=fp.theatreid group by (dt.name,extract(year from fp.performancedate));

 

Figure 8: Output of Query 1

Source: created by author

Query2

select c.name from dimclient c,

factperformance f where f.clientid=c.clientid  group by c.name

having count(extract (month from f.performancedate)) >4;

 

Figure 9: Output of Query 1

Source: created by author

Query3

select  sum(fp.amount) as "Total sales",

p.title, p.pdirector,

p.playauthor from factperformance fp

inner join dimproduction p on

p.pid=fp.pid group by (p.title,p.pdirector,p.playauthor)

order by sum(fp.amount) desc;

 

Figure 10: Output of Query 3

Source: created by author

A Data Mart is basically represented as subset of the relational database as the data in the Data Mart is extracted from the relational databases. Although some of the data is generated from the other sources. For example, for better date reference a Calendar table is created and populated here with the help of procedures and formulas. The date key here is referenced to the date column in the fact table. Also, it does not need to populate dates while the system is in use as it will automatically can be referred to the calendar table as it holds all the dates and same dates are not needed to be input in the fact table more than once. Hence, the size of the Data Mart is comparatively less than the Relational databases. Apart from that, the transaction reports are clear as the each particular transaction is stored here as a separate row. Also the relational models requires a lot of joining tables for the query. Whereas the Data Mart has stored all the factual data in the one table. If dimension attributes are needed in the query then also it requires minimum joining conditions.

Anand, N. and Kumar, M., 2013, July. Modeling and optimization of extraction-transformation-loading (ETL) processes in data warehouse: An overview. In 2013 Fourth International Conference on Computing, Communications and Networking Technologies (ICCCNT) (pp. 1-5). IEEE.

Jukic, N., Vrbsky, S. and Nestorov, S., 2016. Database systems: Introduction to databases and data warehouses. Prospect Press.

Mansmann, S., Rehman, N.U., Weiler, A. and Scholl, M.H., 2014. Discovering OLAP dimensions in semi-structured data. Information Systems, 44, pp.120-133.

Sadoghi, M., Bhattacherjee, S., Bhattacharjee, B. and Canim, M., 2016. L-Store: A real-time OLTP and OLAP system. arXiv preprint arXiv:1601.04084.

Selene Xia, B. and Gong, P., 2014. Review of business intelligence through data analysis. Benchmarking: An International Journal, 21(2), pp.300-311.

Sharma, S. and Jain, R., 2014, February. Modeling ETL process for data warehouse: an exploratory study. In 2014 Fourth International Conference on Advanced Computing & Communication Technologies (pp. 271-276). IEEE.

Sidi, E., El Merouani, M., Amin, E. and Abdelouarit, A., 2016. Star Schema Advantages on Data Warehouse: Using Bitmap Index and Partitioned Fact Tables. International Journal of Computer Applications, 975, p.8887.

Sohail, A. and Dominic, P.D.D., 2015. From ER model to star model: a systematic transformation approach. International Journal of Business Information Systems, 18(3), pp.249-267.

Cite This Work

To export a reference to this article please select a referencing stye below:

My Assignment Help. (2020). ORACLE Data Mart For Ticket Sales For Midlands Theatre (MT) Company Essay.. Retrieved from https://myassignmenthelp.com/free-samples/imat5167-data-warehouse-design-and-olap.

"ORACLE Data Mart For Ticket Sales For Midlands Theatre (MT) Company Essay.." My Assignment Help, 2020, https://myassignmenthelp.com/free-samples/imat5167-data-warehouse-design-and-olap.

My Assignment Help (2020) ORACLE Data Mart For Ticket Sales For Midlands Theatre (MT) Company Essay. [Online]. Available from: https://myassignmenthelp.com/free-samples/imat5167-data-warehouse-design-and-olap
[Accessed 28 February 2024].

My Assignment Help. 'ORACLE Data Mart For Ticket Sales For Midlands Theatre (MT) Company Essay.' (My Assignment Help, 2020) <https://myassignmenthelp.com/free-samples/imat5167-data-warehouse-design-and-olap> accessed 28 February 2024.

My Assignment Help. ORACLE Data Mart For Ticket Sales For Midlands Theatre (MT) Company Essay. [Internet]. My Assignment Help. 2020 [cited 28 February 2024]. Available from: https://myassignmenthelp.com/free-samples/imat5167-data-warehouse-design-and-olap.

Get instant help from 5000+ experts for
question

Writing: Get your essay and assignment written from scratch by PhD expert

Rewriting: Paraphrase or rewrite your friend's essay with similar meaning at reduced cost

Editing: Proofread your work by experts and improve grade at Lowest cost

loader
250 words
Phone no. Missing!

Enter phone no. to receive critical updates and urgent messages !

Attach file

Error goes here

Files Missing!

Please upload all relevant files for quick & complete assistance.

Other Similar Samples

support
Whatsapp
callback
sales
sales chat
Whatsapp
callback
sales chat
close