Recall – The Big Picture
Using FLUX
1. Visit http://flux.qa/ on your internet enabled device
2. Log in using your Monash account (not required if
you are already logged in to Monash)
3. Click on the “+” to join audience
4. Enter the Audience Code:
• Caulfield – 3GANT7
• Fully Flex – 39WRG8
• Malaysia – VTVPLW
5. Select FIT5195 in the Active Presentation menu
6. Answer questions when they pop up
http://flux.qa/1AW6N8
Recall – Data Warehouse
▪ To address the drawback of operational database, and a need
for decision-
making support data, data warehouse is needed.

▪ A data warehouse is a multi-dimensional view of databases,
with
aggregates and pre-computed summaries.
➢ In many ways, it is basically doing aggregates in advance;
that is exactly pre-
computation done at the design level, rather than at the query
level.
Recall – Data Warehouse
Star Schema
▪ A Star Schema is a design representation of a multi-
dimensional view. It is a
data modeling technique used to map multidimensional decision
support
data into a relational database.
▪ The reason for the star schema’s development is that existing
relational
modeling techniques: ER and normalization, did not yield a
database
structure that served the advanced data analysis requirements
well.

Star Schema Components
▪ There are Three main components of the Star Schema:
1. Facts
2. Dimensions
3. Attributes
1. Facts
Facts are numeric measurements (values) that represent a
specific business aspect
or activity.
For example, sales figures are numeric measurements that
represent product and/or
service sales.
2. Dimensions
Dimensions are qualifying characteristics that provide
additional perspectives to a
given fact.

For example, sales might be viewed from specific dimension(s),
such as sales
location, sales period, sales product, etc.
Star Schema Notation
▪ A Sales Star Schema
➢ Fact:
• Sales
➢ Dimensions:
• Time
• Product
• Branch
▪ Notation-wise, the Fact uses a bolder line, to differentiate
between Fact
from Dimensions.
▪ A Sales Star Schema
➢ Fact:

• Sales
➢ Dimensions:
• Time
• Product
• Branch
▪ The lines that represent a relationship
between the fact and dimensions can be
straight lines or bended lines.
▪ Using the star schema notation, the
number of dimensions can be unlimited.
▪ If there is more dimensions, then we just
add more dimensions linked to the Fact.
3. Attributes
Each dimension table contains attributes.

For example:
Product dimension: Prod Type,
Description.
Location dimension: Region,
State,
City.
Time dimension: Year,
Month.
▪ Sales Star Schema
(b) Sales Star Schema complete with the Attributes(a) Outline
star schema for Sales
E/R Diagram Notation

(a) An Entity in E/R Diagram
(b) Relationships in E/R Diagram
Associative
Relationship
Non-Associative
Relationship
Transformation Process

Case Study #1
Case Study #1: International College
The admission office handles enrolment, payment, and
marketing campaigns to international
students, often through educational agents located overseas.
This admission office has an
operational system that maintains all the details of international
students enrolled in the College.
Payment details are also handled by this office. Basically, the
operational system has the following
features:
▪ Every student details are kept in the database. This includes
the courses that the students enroll.
▪ As the College is a multi-campus university, some courses are
offered in a different campus. The
admission office handles international students of all campuses.
▪ Some international students coming to the College are handled
by an educational agent. This is
particularly common for the first course that a student enrolls
in. Subsequent courses are not
normally handled by an agent, because the students themselves

deal directly with the College.
▪ International students pay tuition fees several times (normally
once every semester) for each
course they are doing.
The College now requires a data warehouse for analysis
purposes. The analysis is needed for identifying at least the
following questions:
1. How many students come from certain countries?
2. What is the total income for certain postgraduate
courses?
3. How many students are handled by certain agents?
4. How the number of enrolment of courses fluctuates
across the year?
▪ College Star Schema
➢ Fact:

• Number of Students
• Total Income
➢ Dimensions:
• Country
• Agent
• Course
• Year
Case Study #2
Case Study #2: Sales
▪ Suppose that we would like to analyze
Total Sales from various point of
views, such as Quarter, Branch, and
Product Category.
Case Study #2: Sales

➢ Fact:
• Total Sales
➢ Dimensions:
• Time
• Branch
• Product Category
Two Column Table
Methodology
Two Column Table Methodology
When creating a star schema, you need to
imagine that the data you want to analyse
consists of two columns.
The first column is the category (e.g. A, C,
D, E), and the second column is the
statistical numerical figure (e.g. B).

The second column (e.g. B) has to be
consistent throughout all the two-column
tables.
One Fact Measurement:
▪ Case Study 1: Analysis of Accountants
Suppose the CPA organization would like to analyze its
members (i.e.
accountants) in a particular city. Assume that the organization
has the full
details of its members.
Education Number of Accountants
Diploma 84953
Bachelor 349203
Higher Degree 98943
Others 2322

▪ We can also look at the figures from the gender point of view,
like:
▪ Another way to analyze number of accountants is form the
type of the accountant job
itself; something like:
▪ Note that the figures are fictitious, and the “Types” of
Accountants (indicating different
roles of accountants) are also fictitious.
Gender Number of Accountants
Male 434322
Female 89932
Type Number of Accountants
Government 3843
Private Business 45303
Personal 45930
etc
etc

▪ You can further identify other example to analyze number of
accountants. In
the above three tables, the first angle to look at the number of
accountants
is from the educational background, the last one is from the
type of the
accountant itself, whether it is a private business accountant,
etc.
▪ As you can see, the second column is CONSISTENTLY
UNIFORM. In the
above example, it is number of accountants. The first column
changes
depending on from which angle that you want to see.
▪ Therefore, in this case study, the star schema could look like
the following:
The second column in the two-column

tables, which is the numerical fact
measurement (e.g. column B) can
actually be multiple columns (call them:
B1, B2, B3), as long as all of these
columns (e.g. B1, B2, B3) relate to all of
the categories (e.g. A, C, D, E).
Multiple Fact Measurements:
▪ Case Study 2: Student Enrollment
The University Administrator(s) needs to keep track of the
number of
enrollment for particular unit or campus and the students’
performance
each year in order to maintain the University performance. The
head of
admin has assigned you the task of developing a small Data
Warehouse in
which to keep track the enrollment and performance statistics.

▪ For example:
▪ Another example could be something like this:
Subject Number of Students Total Score
Database 8 539
Java 5 327
SAP 1 63
Network 2 105
Semester Number of Students Total Score
One 9 618
Two 7 416
F1 F2
F1 F2
▪ In analyzing number of students (apart from the subject and
semester as
shown above), you could also see the number of student from
another

angle, for example from the campus and grade:
Campus Number of Students Total Score
Main 9 658
City 5 271
DE 2 105
F1 F2
▪ For example:
Grade Number of Students Total Score
HD 3 253
D 4 300
C 4 256
P 2 105
N 3 120
F1 F2

▪ The first columns of the above examples are the dimensions,
whereas
the other columns that contain the
statistical/summarized/aggregated
values is the fact.
▪ In the above example, the fact is then
STUDENT_ENROLLMENT_FACT,
and the dimensions are SUBJECT, SEMESTER, GRADE and
CAMPUS.
▪ The star schema for the STUDENT ENROLLMENT is shown
as follows:
End of Week 2 Lecture
Oracle/FIT5195-3-Bridge Table.pdf
Week 3 – Bridge Tables
Semester 1, 2020
FIT5195 – Business Intelligence
and Data Warehousing

Developed by:
Agnes Haryanto
[email protected]
Soon Lay-Ki
[email protected]
MONASH
INFORMATION
TECHNOLOGY
Agenda
1. Bridge Tables
2. Temporary Tables
1. Temporary Dimension Tables
2. Temporary Tables in the Operational Database
Using FLUX
1. Visit http://flux.qa/ on your internet enabled device
2. Log in using your Monash account (not required if
you are already logged in to Monash)
3. Click on the “+” to join audience

4. Enter the Audience Code:
• Caulfield – 3GANT7
• Fully Flex – 39WRG8
• Malaysia – VTVPLW
5. Select FIT5195 in the Active Presentation menu
6. Answer questions when they pop up
http://flux.qa/1AW6N8
Bridge Tables
Bridge Tables
▪ A bridge table is a table that links between two dimensions;
and only one
of these two dimensions are linked to the fact.
➢ As a result, the star schema becomes a snowflake schema.
Bridge Tables
▪ Two reasons on why a dimension cannot be connected directly
to the Fact:
▪

a) The Fact table has a fact measure, and the dimension has a
key identity. In
order to connect a dimension to the Fact, the dimension’s key
identity must
contribute directly to the calculation of the fact measure.
Unfortunately, this
cannot happen if the operational database does not have this
data.
b) The operational database does not have this data if the
relationship between
two entities in the operational database that hold the
information about
dimension’s key identity and the intended fact measure is a
many-many
relationship.
Bridge Tables
Case Study #1
Case Study #1 – A Product Sales Case Study
▪ A company management team would like to
analyze the statistics of its product sales

history. The analysis is needed to identify
popular products, suppliers supplying those
products, the best time to purchase more
stock, etc.
▪ A small data warehouse is to be built to keep
track of the statistics.
▪ The management is particularly interested in
analyzing the total sales (quantity * price) by
product, customer suburbs, sales time
periods (month and year), and supplier.

➢ Fact:
• Total Sales
➢ Dimensions:
• Product
• Customer locations/suburbs
• Time period
• Supplier
▪ Possible Two-Column Methodology Tables:
ProductNo TotalSales
A1 $130,000
B2 $15,900

C3 $2,500,000
… …
TimeID TotalSales
201801 $25,000
201802 $4,700
201803 $3,500
… …
Suburb TotalSales
Caulfield $6,500
Chadstone $12,000
Clayton $1,800
… …
(a) Product point of view (b) Time point of view (c) Suburb
point of view
➢ Fact:

• Total Sales
➢ Dimensions:
• Product
• Customer locations/suburbs
• Time period
• Supplier
SupplierID TotalSales
S1 $77,000
S2 $5,700
S3 $12,500
… …
Supplier point of view

S1 $77,000
S2 $5,700
S3 $12,500
… …
Supplier point of view
S1 $77,000
S2 $5,700
S3 $12,500
… …

Bridge Table
▪ To create Time Dimension:
- create table TimeDim as
select
distinct to_char(SalesDate, ’YYYYMM’) as TimeID,
to_char(SalesDate, ’YYYY’) as Year,
to_char(SalesDate, ’MM’) as Month
from Sales;
▪ To create Customer Location Dimension:
- create table CustLocDim as
select distinct Suburb, Postcode
from Customer;
▪ To create Product Dimension:
- create table ProductDim as

select distinct ProductNo, ProductName
from Product;
▪ To create Bridge Table:
- create table ProductSupplierBridge as
select *
from StockSupplier;
▪ To create Supplier Dimension:
- create table SupplierDim as
select SupplierID, Name as SupplierName
from Supplier;
▪ To create Fact Table:
- create table ProductSalesFact as
Select
to_char(S.SalesDate, ’YYYYMM’) as TimeID,
P.ProductNo,
C.Suburb,
sum(SI.QtySold*P.Price) as TotalSales

from Sales S, Product P, Customer C, SalesItem SI
where S.SalesNo = SI.SalesNo
and SI.ProductNo= P.ProductNo
and C.CustomerID = S.CustomerID
group by
to_char(S.SalesDate, ’YYYYMM’), P.ProductNo, C.Suburb;
Bridge Tables
Case Study #2
Case Study #2 – A Truck Delivery Case Study
▪ A trucking company is responsible for picking up goods from
warehouses of a retail chain
company, and delivering the goods to individual retail stores.
▪ A truck carry goods during a single trip, which is
identified by TripID, and delivers these goods to
multiple stores. Trucks have different capacities
for both the volumes they can hold and the

weights they can carry.
▪ At the moment, a truck makes several trips each
week. An operational database is being used to
keep track the deliveries, including the scheduling
of trucks, which provide timely deliveries to
stores.
▪ A trip may pick up goods from many
warehouses
o i.e. a many-many relationship between
Warehouse and Trip
▪ A trip uses one truck only, and a truck may
have many trips in the history
o i.e. a many-1 relationship between Trip and
Truck
▪ A trip delivers goods (e.g. TVs, fridges, etc)
potentially to several stores

o a many-many relationship between Trip and
Store, which is represented by the Destination
table
▪ Sample data in the operational database:
WarehouseID Location
W1 Warehouse1
W2 Warehouse1
W3 Warehouse1
… …
(d) Truck Table
(b) Trip Table (c) TripFrom Table
TripID Date TotalKm TruckID
Trip1 14-Apr-2018 370 Truck1
Trip4 15-Jul-2018 450 Truck1

… … … …
TripID WarehouseID
Trip1 W1
Trip1 W2
Trip1 W3
Trip2 W1
Trip2 W2
… …
TruckID VolCapacity WeightCategory CostPerKm
Truck1 250 Medium $1.20
Truck2 300 Medium $1.50
Truck3 100 Small $0.80
Truck4 550 Large $2.30
Truck5 650 Large $2.50
… … … …
StoreID StoreName Address
M1 MyStore City Melbourne
M2 MyStore Chaddy Chadstone

M3 MyStore HiPoint High Point
M4 MyStore Donc Doncaster
M5 MyStore North Northland
M6 MyStore South Southland
M7 MyStore East Eastland
M8 MyStore Knox Knox
… …
TripID StoreID
Trip1 M1
Trip1 M2
Trip1 M4
Trip1 M3
Trip1 M8
Trip2 M4
Trip2 M1
Trip2 M2
… …
(a) Warehouse Table

(e) Store Table (f) Destination Table
▪ The management of this trucking company would like to
analyze the deliver cost, based on
trucks, time period, and store.
➢ Fact:
• Total Delivery Cost
(distance * cost per kilometre)
➢ Dimensions:
• Truck
• Time period
• Store

▪ From the Truck point of view, Truck1 has two trips (e.g. Trip1
and Trip4), with the total kilometres of
820km (370km + 450km). The cost for Truck1 is $1.20. Hence,
calculating the cost for Truck1 is
straightforward. Other trucks can be calculated this way.
▪ From the Period point of view, 14-Apr-2018 has three trips
(e.g. Trip1,Trip2, and Trip3). Trip1 (370km) is
delivered by Truck1 which costs $1.20/km. Trip2 and Trip 3, on
the same day, can be calculated the same
way. Hence, on 14-Apr-2018, the total cost can be calculated.
▪ From the Store point of view; The cost is calculated
based on Trip, but a trip delivers goods to many
stores. Therefore, the delivery cost for each store
cannot be calculated. The delivery cost is for the trip –
not for the store.
Solution

Model 1 – Using a Bridge Table

OracleFIT5195-2-Star Schema.pdfWeek 2 – Star SchemaSe.docx

Recommended

Recommended

More Related Content

Similar to OracleFIT5195-2-Star Schema.pdfWeek 2 – Star SchemaSe.docx

Similar to OracleFIT5195-2-Star Schema.pdfWeek 2 – Star SchemaSe.docx (20)

More from vannagoforth

More from vannagoforth (20)

Recently uploaded

Recently uploaded (20)

OracleFIT5195-2-Star Schema.pdfWeek 2 – Star SchemaSe.docx