2. Data Warehouse
Database relasional yang dirancang untuk
melakukan queri dan analisis.
Berisi data-data historis yang berasal dari
data-data transaksi.
Sebuah organisasi dapat mengkonsolidasi
data-data dari beberapa sumber.
3. Skema
Terdiri dari obyek-obyek DB seperti tabel,
views, dan indeks
Ada beberapa bentuk skema, contoh:
star, snowflake
4. Fakta (Fact)
Dalam sebuah DW, sejumlah queri
menanyakan tentang fakta
Cth, 20% tertinggi pelanggan setia
Fakta: transaksi dari kartu pelanggan
Karakteristik
Transaksi yang terjadi di masa lalu dan tidak
mengalami perubahan.
Dapat dianalisis dengan banyak cara dengan
menghubungkan beberapa atribut antar tabel.
5. Tabel Fakta (Fact Table)
Sebuah tabel yang berisi fakta
Berisi angka, dan kolom tambahan
(sebagai ukuran proses bisnis)
Memiliki 2 jenis kolom:
Mengandung fakta
foreign key dari tabel-tabel dimensi
6. Dimensi (Dimension)
Struktur tabel yang digunakan untuk
mengelompokkan data agar pengguna
dapat mencari jawaban dari masalah
bisnis yang terjadi.
Contoh: Produk, Waktu, Lokasi,
Pelanggan
7. Contoh
Perusahaan Video membangun DW untuk
menganalisis seluruh penjualan produknya di
semua cabang perusahaannya dalam waktu
tertentu
Dampak promosi sebuah produk terhadap penjualan
produk lain yang berhubungan?
Penjualan produk sebelum dan sesudah promosi?
Fakta
Penjualan (unit terjual atau disewa) dan laba
Dimensi
Produk, lokasi (toko), promosi, waktu
8. Pertimbangan Utama
Data warehouse mendukung business process,
bukan queri khusus
Harus memahami informasi yang akan
digunakan
Tantangan:
Solusi sebaiknya efektif untuk digunakan dalam
waktu tertentu (3-5 tahun)
Desain sebaiknya memungkinkan untuk melakukan
queri yang belum diketahui
9. Identifikasi Fakta & Dimensi
Diberikan model entitas yang besar
1. Mencari transaksi pokok dalam proses bisnis
2. Menentukan dimensi utama untuk
menerapkan fakta
3. Memastikan bahwa calon tabel fakta bukan
tabel dimensi
4. Memastikan bahwa calon tabel dimensi
bukanlah tabel fakta
5. Jika ada 3 atau 4 perubahan kembali ke
langkah 2
10. 1. Mencari transaksi pokok
dalam proses bisnis
Menentukan bisnis dan identifikasi jenis
transaksi
Transaksi yang menggambarkan kejadian dasar
Cth., data transaksi akun yang dilakukan oleh
nasabah bank
Apakah informasi ini dilakukan oleh
perusahaan?
Jangan menganggap bahwa transaksi yang
terjadi adalah fakta
Rancangan dibuat untuk merekam data
transaksi yang paling detil agar tidak terjadi
restrukturisasi desain skema
11. Contoh
Pertimbangkan informasi penjualan dari
toko cabang
Data yang disimpan
Store_id, Product_id, Tanggal, Penjualan
Proses bisnis yang berjalan pada
lingkupnya (basket), cth., transaksi
penjualan secara individu dan bukan
penjualan secara aggregat
Fakta harus berupa transaksi basket
12. 2. Menentukan Dimensi Utama
Untuk Fakta
Mencari entitas yang terhubung langsung
dengan fakta
Fokuskan pada dimensi utama
14. Entitas mungkin tampak sebagai tabel
fakta, tapi mungkin juga kombinasi antara
fakta dan dimensi
Pertimbangkan apakah atribut dirancang
sesuai kebutuhan data entry
Data dalam tabel fakta tidak
diperbolehkan mengandung berbagai
kejadian dengan periode waktu yang
berbeda-beda
3. Memastikan Jika Fakta adalah
Dimensi
16. Contoh (Cont.)
Code Address Zip Code Date Code Date
Address Date
Cable laid
Date sub
added
• Akan mempengaruhi ukuran DB
• Queri dalam DB Operasional akan jauh lebih mudah
17. 4. Memastikan Jika Dimensi
adalah Fakta
Sebuah entitas bisa berupa dimensi atau
fakta
Pertimbangkan inti analisis dari proses
bisnis
Good check: berdasar pada berapa
entitas dimensi bisa ditampilkan, jika >3
kemungkinan adalah fakta
20. Merancang Fact Table
Tidak ada batasan ukuran fact table
Keseimbangan antara ukuran fact table
dan nilai data
21. Teknik Memperkecil Ukuran Fact
Tables
Identifikasi periode-periode yang penting
untuk mendukung keputusan
Penentuan sampel untuk mencukupi
permintaan data secara terperinci
Pemilihan kolom-kolom yang sesuai untuk
pengambilan keputusan
22. Teknik (Cont.)
Memperkecil ukuran kolom
Penentuan kunci intelligent atau non-
intelligent
Penentuan format waktu
Partisi fact table (Next group)
23. 1. Identifikasi Periode Waktu
yang Signifikan
Gambarlah grafik periodik yang
menunjukkan waktu dan kebutuhan
secara detil dari tiap fungsi.
Cth., perbandingan jumlah penjualan
produk musiman seperti pakaian musim
dingin, buku teks dll.
Sales Analysis
Jan ‘98 July ‘98 Jan ‘99
24. 2. Menentukan sampel untuk
memenuhi kebutuhan data
Sesuaikan terhadap kondisi dimana
kebutuhan analisis digunakan untuk
menganalisis tren.
Proses bisnis tidak membutuhkan data
detil.
Simpanlah sampel dan hitung nilai
aggregatnya.
25. 3. Pemilihan kolom yang tepat
Tentukan apakah data opsional perlu
disimpan ke dalam tabel fakta.
Contoh, tabel yang terhubung dengan
rekening bank.
Kolom yang diperlukan adalah:
Acc#, IC#, Amt#, Bank # or Branch#
Kolom tambahan seperti nama Teller dan
waktu input data diperlukan berdasarkan
kebutuhan saja.
26. 4. Minimization of Column Size
Saving per row can have significant effect
on total table size
e.g., a typical transaction table contains 4
billion rows (2 million customers, 3
transactions per day per customer for 2 or
3 yr period) saving of 20 bytes per row will
save 20 x 4 =80 GB
27. 5. Intelligent /Non-intelligent keys
A fact table can be structured in two ways using
Intelligent keys:
Each key represents unique identifier for the item in
the real world
Non-Intelligent:
Each unique key is generated automatically and
refers to unique identifier of the item in the real world
29. Time id
Date
Sales id
Salesman Name
Sales id
Cust id
Vehicle id
Time id
Sales_price
Vehicle id
Vehicle Description
Sales Analysis
Salesman
Sales Vehicle
Time
Non – Intelligent Keys
30. Comparison
Advantages
Intelligent keys improve query performance
by avoiding joins
Disadvantages
For intelligent keys, if any of the unique
identifier changes, a lot of rows in fact table
have to be updated to reflect new identifiers
31. 6. Determination of format of
storing time
Time information can be stored in many
ways within fact table, e.g.,
Use of foreign key into time dimension table
Actual physical dates are stored within
dimension table
32. Determination of format of storing
time (Cont.)
Possible techniques to store dates are
Storing the physical date
Storing an offset from the inherent start of the
table
Storing a date range
Use physical dates rather than foreign
keys as the cost of storing is minimum
33. Determination of format of storing
time (Cont.)
A fact table is usually partitioned in a unit
of time (e.g. week, month,quarter etc)
Dates can be referred as offsets from the
inherent start
Storage costs are low. Two bytes enough
to store up to 31 numbers
34. Determination of format of storing
time (Cont.)
Disadvantages:
Queries have to be constructed to convert physical
dates into date offsets.
E.g.: To return sum of transactions on ‘9-Jan-00’
Select count(*) from customer
where date=‘9-Jan-00’ – ‘1-Jan-00’;
Solution:
If access tools can’t interpret offset, create view that
looks like logical table by adding offset to start date
35. Date Range
Significant saving in disk capacity and
query performance
Reduces table size
Has significance when changes occur
substantially over time
36. Date Range (Cont.)
Select count (*) from customer where
date between (st_date,end_date);
A number of access tools may not be able
to process fact tables in this view
Sometimes a Cartesian product is formed
by joining time dimension table against
date range in the fact table
37. Date Range (Cont.)
Cost of Cartesian product is high, it
requires
Significant processing power
Temporary space
Consider the use of date range if access
tools can cope directly with structure and
do not allow data expansion
38. Designing Dimension Table
Done after fact tables are designed
dimension tables support querying on fact
tables
Wrong design is not a major disaster
volumes relatively small
restructuring costs relatively small
40. Star Dimension
Denormalized tables
put reference information into a single table
speed up query performance
Rely on perceived use of information by
typical queries
Not appropriate when additional data is
not accessed often
overhead of scanning expanded table
41. Star Dimension (cont.)
View enrollment size by department,
faculty
acad_year, mod#, enrollment
mod#, title, dept#
dept#, department, fac#
fac#, faculty
1
n
1
n
mod#, title, dept#, department, faculty#, faculty
Put under same table
43. Hierarchies and Network
Not possible to denormalize all entities
into star dimensions
Many-to-many relationships should not
be denormalized into star dimension
not efficient
Multiple hierarchies are used to
represent different views
denormalized the hierarchy likely to be
used by most queries
44. Hierarchies and Network (cont.)
Example
Fact
Dimension
Dimension
Dimension
Dimension
Dimension Dimension Dimension
Dimension Dimension Dimension
45. Hierarchies and Network (cont.)
Useful if query profiles do not change to a
point where other hierarchy becomes more
popular
existing star dimension table is useless
For minor changes
add columns
note impact on canned queries if columns are
dropped or modified
46. Dimensions That Vary Over
Time
Change in business
t-shirts move from menswear to unisex
baked beans move from canned foods to canned
vegetables
May need to support queries that compare
facts based on present and past groupings
for example, to compare sales by departments
between past and present, need to use both old
and new classification
instead of updating record in dimension table,
add new record and validity dates
47. Dimensions That Vary Over
Time (cont.)
Year 1996
select sum(s.revenue_achieved)
from sales_year_to_date s, product_dimension pd
where s.product_id = pd.id
and pd.department = ‘Menswear’
and pd.end_date > 1-Jan-96
and pd.start_date < 31-Dec-96;
Year 1997
select sum(s.revenue_achieved)
from sales_year_to_date s, product_dimension pd
where s.product_id = pd.id
and pd.department = ‘Menswear’
and pd.end_date > 1-Jan-97
and pd.start_date < 31-Dec-97;
48. Dimensions That Vary Over
Time (cont.)
If query needs to compare a significant
event in corporate calendar, year on year,
keep in time dimension
Great Singapore Sales in 1998 is from 15 Jul
to 15 Aug
Great Singapore Sales in 1999 is from 10 Jun
to 10 Jul
Instead of just joining sales_year_to_date
and product_dimension tables, now we
also join with time_dimension table.
49. Managing Large Dimension Tables
Need to watch out for dimension tables that
grow too large over time
especially for those dimension tables that store
new values instead of updating existing tuples
Indicated by:
size similar to that of fact table
full table scan takes too long
Horizontal partition the large dimension tables
product_dimension_1990s
product_dimension_2000s
50. Designing Starflake Schema
Starflake schema
combination of denormalized star and normalized
snowflake schemas, plus some additional ideas
Difficult to restructure all entities into a set of
distinct dimensions
common for entities to span one or more
dimensions
for example, common for stores to apply local
pricing for products, thus need to join product and
store tables instead of getting the price from
product table
allow a degree of crossover between dimensions
52. Designing Starflake Schema (cont.)
Crossovers of starflake schema will reduce over time
once system is operational
requirements become better understood
expect greatest amount of change for outlying entities
Degree of change should decrease as we move from
outlying entities towards fact tables
need not spend much time on requirements that use outlying
entities
Need to direct query to most appropriate source
starflake schema not supported by access tools
create views and synonyms on fact tables to be used by
access tools
53. Multidimensional Schemas
Class of decision support queries that
analyze data by representing facts and
dimensions within a multidimensional cube
Each dimension occupy an axis, and values
within the cube correspond to factual
transactions
Trend analysis
Good for viewing statistical
operations/aggregations
apply functions against planes of cube
cube can be pivoted, sliced, diced
55. Multidimensional Schemas (cont.)
Cube extracts data from data warehouse
created as physical stores in many access tools
populate on demand or in advance
If data warehouse is constantly being
accessed, performance will be poor
most appropriate solution is when cube satisfies
majority of queries, but require substantial design
effort
