Download - Model Kubus Data
Edward Purba DW & OLAP
Model Kubus DataModel Kubus Data
• Melihat data sebagai kubus
Edward Purba DW & OLAP
Skema Star (Dalam RDBMS)Skema Star (Dalam RDBMS)
Ukuran
Edward Purba DW & OLAP
Contoh Skema StarContoh Skema Star
Ukuran
Edward Purba DW & OLAP
Sk
ema
Sta
r D
enga
n
Sk
ema
Sta
r D
enga
n
Dat
a S
amp
elD
ata
Sam
pel
Edward Purba DW & OLAP
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.
Edward Purba DW & OLAP
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
Edward Purba DW & OLAP
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
Edward Purba DW & OLAP
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
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
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.
Edward Purba DW & OLAP
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...
Edward Purba DW & OLAP
Skema Konstelasi FaktaSkema Konstelasi Fakta
DollarsUnitsPrice
District Fact Table
District_IDPRODUCT_KEYPERIOD_KEY
DollarsUnitsPrice
Region Fact Table
Region_IDPRODUCT_KEYPERIOD_KEY
PERIOD KEY
Store Dimension Time Dimension
Product Dimension
STORE KEYPRODUCT KEYPERIOD KEY
DollarsUnitsPrice
Period DescYearQuarterMonthDayCurrent FlagSequence
Fact Table
PRODUCT KEY
Store DescriptionCityStateDistrict IDDistrict Desc.Region_IDRegion Desc.Regional Mgr.
Product Desc.BrandColorSizeManufacturer
STORE KEY
Edward Purba DW & OLAP
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
Region_IDPRODUCT_KEYPERIOD_KEY
PERIOD KEY
Store Dimension Time Dimension
Product Dimension
STORE KEYPRODUCT KEYPERIOD KEY
DollarsUnitsPrice
Period DescYearQuarterMonthDayCurrent FlagSequence
Fact Table
PRODUCT KEY
Store DescriptionCityStateDistrict IDDistrict Desc.Region_IDRegion Desc.Regional Mgr.
Product Desc.BrandColorSizeManufacturer
STORE KEY
Edward Purba DW & OLAP
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” ...
Edward Purba DW & OLAP
Skema SnowflakeSkema Snowflake
STORE KEY
Store Dimension
Store DescriptionCityStateDistrict IDDistrict Desc.Region_IDRegion Desc.Regional Mgr.
District_IDDistrict Desc.Region_ID
Region_ID
Region Desc.Regional Mgr.
STORE KEYPRODUCT KEYPERIOD KEY
DollarsUnitsPrice
Store Fact Table
DollarsUnitsPrice
District Fact Table
District_IDPRODUCT_KEYPERIOD_KEY Dollars
UnitsPrice
RegionFact Table
Region_IDPRODUCT_KEYPERIOD_KEY
Edward Purba DW & OLAP
Skema SnowflakeSkema Snowflake
• 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
Region Desc.Regional Mgr.
STORE KEYPRODUCT KEYPERIOD KEY
DollarsUnitsPrice
Store Fact Table
DollarsUnitsPrice
District Fact Table
District_IDPRODUCT_KEYPERIOD_KEY Dollars
UnitsPrice
RegionFact Table
Region_IDPRODUCT_KEYPERIOD_KEY
Edward Purba DW & OLAP
Skema SnowflakeSkema Snowflake
• 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
Region Desc.Regional Mgr.
STORE KEYPRODUCT KEYPERIOD KEY
DollarsUnitsPrice
Store Fact Table
DollarsUnitsPrice
District Fact Table
District_IDPRODUCT_KEYPERIOD_KEY Dollars
UnitsPrice
RegionFact Table
Region_IDPRODUCT_KEYPERIOD_KEY
Edward Purba DW & OLAP
Suatu Konsep Hierarki:Suatu Konsep Hierarki:Dimensi (location)Dimensi (location)
all
Europe North_America
MexicoCanadaSpainGermany
Vancouver
M. WindL. Chan
...
......
... ...
...
all
region
office
country
TorontoFrankfurtcity
Edward Purba DW & OLAP
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
Edward Purba DW & OLAP
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
Edward Purba DW & OLAP
Contoh Kubus DataContoh Kubus Data
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
Edward Purba DW & OLAP
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
Edward Purba DW & OLAP
Browsing Suatu Kubus DataBrowsing Suatu Kubus Data
• Visualisasi• Kapabilitas OLAP• Manipulasi Interaktif
Edward Purba DW & OLAP
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”)
Edward Purba DW & OLAP
Operasi Kubus Data OLAPOperasi Kubus Data OLAP
• 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)
Edward Purba DW & OLAP
Operasi Kubus Data OLAPOperasi Kubus Data OLAP
Edward Purba DW & OLAP
Operasi Kubus Data OLAPOperasi Kubus Data OLAP
Edward Purba DW & OLAP
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)
Edward Purba DW & OLAP
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
Edward Purba DW & OLAP
Contoh Kubus DataContoh Kubus Data
Edward Purba DW & OLAP
Contoh Kubus DataContoh Kubus Data
Edward Purba DW & OLAP
Contoh Kubus DataContoh Kubus Data
Edward Purba DW & OLAP
Contoh Kubus DataContoh Kubus Data