Model Kubus Data

Edward Purba DW & OLAP

Model Kubus DataModel Kubus Data

• Melihat data sebagai kubus


Skema Star (Dalam RDBMS)Skema Star (Dalam RDBMS)

Ukuran


Contoh Skema StarContoh Skema Star

Ukuran


Sk

ema

Sta

r D

enga

n

Sk

ema

Sta

r D

enga

n

Dat

a S

amp

elD

ata

Sam

pel


Skema Star Dengan Skema Star Dengan Data SampelData Sampel

• Fakta product nomor 110 selama periode 002:– 30 unit terjual di toko S1. Total penjualan dalam

dollar 1500, dan total cost dalam dollar 1200– 40 unit terjual di toko S3. Total penjualan dalam

dollar 2000, dan total cost dalam dollar 1200• Ukuran tabel fakta:

– Misal jumlah total toko 1000, jumlah total product 10000, jumlah total periode 24 (data berharga 2 tahun)

– Misal rata-rata 50% (atau 5000) record penjualan selama suatu bulan tertentu.


Skema Star Dengan Skema Star Dengan Data SampelData Sampel

• Ukuran tabel fakta:– Taksiran jumlah baris dalam tabel fakta dihitung

sebagai berikut:total baris= 1000 toko x 5000 produk aktif x

24 bulan = 120,000,000 baris

– Tebal fakta memiliki 6 field, dimana rata-rata field panjangnya 4 byte.Total size=120,000,000 baris x 6 field x 4

byte/field = 2,880,000,000 bytes


Skema Star “Klasik”Skema Star “Klasik” Suatu tabel fakta tunggal

dengan data detail dan ringkasan

Primary key tabel fakta hanya memiliki satu kolom key per dimensi

Masing-masing key dibangun Masing-masing dimensi adalah

suatu tabel tunggal, yang didenormalisasi

Keuntungan: Mudah dipahami, mudah didefinisikan secara hierarki, mengurangi jumlah join fisik, low maintenance, metadata sangat sederhana

Kekurangan: Ringkasan data dalam tabel fakta menghasilkan kinerja yang buruk untuk level ringkasan dan juga untuk tabel dimensi yang besar

PERIOD KEY

Store Dimension Time Dimension

Product Dimension

STORE KEYPRODUCT KEYPERIOD KEY

DollarsUnitsPrice

Period DescYearQuarterMonthDayCurrent FlagResolutionSequence

Fact Table

PRODUCT KEY

Store DescriptionCityStateDistrict IDDistrict Desc.Region_IDRegion Desc.Regional Mgr.Level

Product Desc.BrandColorSizeManufacturerLevel

STORE KEY


Skema Star “Klasik”Skema Star “Klasik”

Kekurangan terbesar: tabel dimensi harus membawa suatu indikator level sehingga setiap record dan setiap query harus menggunakannya. Dalam contoh dibawah, tanpa level kendali, key untuk seluruh store dalam region NORTH, termasuk agregasi pada region dan distrik akan dikeluarkan dari tabel fakta, mengeluarkan error.

PERIOD KEY


Product Dimension


DollarsUnitsPrice

Period DescYearQuarterMonthDayCurrent FlagResolutionSequence

Fact Table

PRODUCT KEY

Store DescriptionCityStateDistrict IDDistrict Desc.Region_IDRegion Desc.Regional Mgr.Level

Product Desc.BrandColorSizeManufacturerLevel

STORE KEY

Contoh: Select A.STORE_KEY, A.PERIOD_KEY, A.dollars from Fact_Table A

where A.STORE_KEY in (select STORE_KEYfrom Store_Dimension Bwhere region = “North” and Level = 2)

dan seterusnya…..

Level diperlukanbila agregasi disimpan dengan fakta detail.


Problem “Level”Problem “Level”

• Level adalah suatu problem sebab level potensial menyebabkan error. Jika pembuat query, manusia atau program, melupakan ini, jawaban yang salah dipastikan bisa terjadi.

• Salah satu alternatif: model konstelasi fakta...


Skema Konstelasi FaktaSkema Konstelasi Fakta

DollarsUnitsPrice

District Fact Table

District_IDPRODUCT_KEYPERIOD_KEY

DollarsUnitsPrice

Region Fact Table

Region_IDPRODUCT_KEYPERIOD_KEY

PERIOD KEY


Product Dimension


DollarsUnitsPrice

Period DescYearQuarterMonthDayCurrent FlagSequence

Fact Table

PRODUCT KEY

Store DescriptionCityStateDistrict IDDistrict Desc.Region_IDRegion Desc.Regional Mgr.

Product Desc.BrandColorSizeManufacturer

STORE KEY


Skema Konstelasi FaktaSkema Konstelasi Fakta

Dalam konstelasi fakta, tabel agregasi dibuat terpisah dari detail, karenanya adalah tak mungkin mengambil, misalnya, detail Store ketika meng-query tabel fakta District.

Keuntungan Utama: Indikator “Level” tidak diperlukan lagi didalam tabel dimensi, karena tidak ada data agregasi yang disimpan dengan level detail lebih rendah.

Kerugian: Tabel dimensi masih tetap sangat besar dalam beberapa kasus, yang akan memperlambat kinerja; front-end harus mampu mendeteksi keberadaan fakta agregasi, yang memerlukan metadata yang lebih ekstensif

DollarsUnitsPrice

District Fact Table

District_IDPRODUCT_KEYPERIOD_KEY

DollarsUnitsPrice

Region Fact Table


PERIOD KEY


Product Dimension


DollarsUnitsPrice

Period DescYearQuarterMonthDayCurrent FlagSequence

Fact Table

PRODUCT KEY


Product Desc.BrandColorSizeManufacturer

STORE KEY


Alternatif Lain Untuk “Level”Alternatif Lain Untuk “Level”

• Konstelasi fakta adalah suatu alternatif yang baik untuk skema star, tetapi ketika dimensi memiliki kardinalitas yang sangat tinggi, sub-selects dalam tabel dimensi bisa menjadi suatu sumber kelambatan.

• Suatu alternatif adalah menormalisasikan tabel dimensi melalui level atribut, dimana setiap tabel dimensi yang lebih kecil menunjuk ke suatu tabel agregasi fakta yang sesuai, “Skema Snowflake” ...


Skema SnowflakeSkema Snowflake

STORE KEY

Store Dimension


District_IDDistrict Desc.Region_ID

Region_ID

Region Desc.Regional Mgr.


DollarsUnitsPrice

Store Fact Table

DollarsUnitsPrice

District Fact Table

District_IDPRODUCT_KEYPERIOD_KEY Dollars

UnitsPrice

RegionFact Table




• Tidak ada LEVEL dalam tabel dimensi

• Tabel dimensi dinormalisasikan dengan menguraikan pada level atribut

• Masing-masing tabel dimensi memiliki satu key untuk setiap level dari hierarki dimensi

• Key level terendah mengabungkan tabel dimensi ke tabel fakta dan tabel level atribut lebih rendah

Bagaimana ini bekerja? Cara terbaik query dibangun adalah dengan memahami level ringkasan apa yang ada, dan mencari tabel atribut snowflake normal, membatasinya untuk kunci, lalu memilih dari tabel fakta

STORE KEY

Store Dimension

Store DescriptionCityStateDistrict IDDistrict Desc.Region_ IDRegion Desc.Regional Mgr.

District_ IDDistrict Desc.Region_ ID

Region_ ID



DollarsUnitsPrice

Store Fact Table

DollarsUnitsPrice

District Fact Table


UnitsPrice

RegionFact Table




• Fitur tambahan: tabel dimensi Store asli, yang didenormalisasi sepenuhnya, dipertahankan utuh, karena query tertentu bisa mengambil keuntungan melalui seluruh isi yang dikandungnya.

• Dalam praktek, mulai dengan skema start dan buat “snowflakes” dengan query. Ini mengurangi kebutuhan untuk membuat ekstraksi terpisah untuk setiap tabel, dan integritas referensial diwarisi dari tabel dimensi

Keuntungan: Kinerja terbaik saat query melibatkan agregasi

Kerugian: maintenance dan metadata yang rumit, ledakan jumlah tabel didalam database

STORE KEY

Store Dimension

Store DescriptionCityStateDistrict IDDistrict Desc.Region_ IDRegion Desc.Regional Mgr.

District_ IDDistrict Desc.Region_ ID

Region_ ID



DollarsUnitsPrice

Store Fact Table

DollarsUnitsPrice

District Fact Table


UnitsPrice

RegionFact Table



Suatu Konsep Hierarki:Suatu Konsep Hierarki:Dimensi (location)Dimensi (location)

all

Europe North_America

MexicoCanadaSpainGermany

Vancouver

M. WindL. Chan

...

......

... ...

...

all

region

office

country

TorontoFrankfurtcity


Data Multidimensi Data Multidimensi

• Volume Sales sebagai suatu fungsi dari product, month, dan region

Pro

duct

Regio

n

Month

Dimensi: Product, Location, TimePath intisari hierarkikal

Industry Region Year

Category Country Quarter

Product City Month Week

Office Day


Contoh Kubus DataContoh Kubus Data

1010

4747

3030

1212

JuiceJuice

ColaCola

Milk Milk

CreaCreamm

NYNY

LALA

SFSF

Volume Volume Sales Sales sebagai sebagai suatu suatu fungsi fungsi time, time, city, dan city, dan productproduct3/1 3/2 3/3 3/1 3/2 3/3

3/43/4

DateDate



Total penjualan TV Setahun di U.S.A.Date

Produ

ct

Cou

ntr

ysum

sum TV

VCRPC

1Qtr 2Qtr 3Qtr 4Qtr

U.S.A

Canada

Mexico

sum


Bentuk Kubus Yang Terkait Bentuk Kubus Yang Terkait Dengan Kubus DataDengan Kubus Data

all

product date country

product,date product,country date, country

product, date, country

0-D(apex) cuboid

1-D cuboids

2-D cuboids

3-D(base) cuboid


Browsing Suatu Kubus DataBrowsing Suatu Kubus Data

• Visualisasi• Kapabilitas OLAP• Manipulasi Interaktif


Operasi Kubus Data OLAPOperasi Kubus Data OLAP

• Roll up (drill-up): merujuk ke peningkatan hierarki atau pengurangan dimensi (diberikan total sales by “city”, di roll-up untuk mendapatkan total sales by “state”)

• Drill down (roll down, kebalikan roll-up): merujuk ke penurunan hierarki atau penambahan dimensi (diberikan total sales by “state”, di roll-down untuk mendapatkan total sales by “city”)

• Slice: merujuk ke pemilihan dimensi yang digunakan untuk melihat kubus (“customer” by “product” by “date”)



• Dice: merujuk ke pemilihan posisi sesungguhnya sepanjang dimensi (bagian dari kubus slice dimana product = “Mr. Snowman”)

• Pivot (rotasi): reorientasi kubus, visualisasi, 3D ke sebarisan bidang 2D

• Operasi lain:

– drill across: melibatkan lebih dari satu tabel fakta

– drill through: melalui level terbawah dari kubus tersebut ke tabel back-end relasionalnya (menggunakan SQL)






Rancangan Suatu Data Warehouse: Rancangan Suatu Data Warehouse: Suatu Kerangka Analisa BisnisSuatu Kerangka Analisa Bisnis

• Tinjauan perihal rancangan dari suatu data warehouse

– Top-down

• Memungkinkan seleksi informasi yang relevan, yang perlu untuk data warehouse (perspektif user)

– Sumber data

• Membuka informasi yang akan ditangkap, disimpan, dan ditangani oleh sistem operasi (perspektif sumber data)


Rancangan Suatu Data Warehouse: Rancangan Suatu Data Warehouse: Suatu Kerangka Analisa BisnisSuatu Kerangka Analisa Bisnis

– Data warehouse

• Terdiri dari tabel-tabel fakta dan dimensi tabel (tinjauan dari dalam data warehouse)

– Query bisnis

• Melihat perspektif data dalam warehouse dari sisi tinjauan end-user









Documents

Model Kubus Data