BAB 3 3 ANALISIS DAN UJI COBA Pada bab ini dilakukan analisis terhadap kelebihan dan kekurangan dari model dimensi star schema dan dimensi snowflake, mempersiapkan data yang digunakan pada OLTP, membuat skenario perbandingan pada dimensi star schema dan snowflake yang digunakan untuk uji coba, melakukan perhitungan penggunaan disk space yang digunakan pada setiap skenario, melakukan uji coba ETL, dan melakukan proses OLAP (menggunakan Analysis Services).
3.1 Analisis kelebihan dan kekurangan star schema dan snowflake Pada bagian ini dijabarkan keuntungan dan kerugian antara dimensi star schema dan dimensi snowflake berdasarkan literatur yang didapatkan pada bab 2.
3.1.1 Kelebihan dan kekurangan dimensi star schema Keuntungan dimensi star schema : 1. Mudah dipahami pengguna karena karena modelnya lebih sederhana. Star schema menggambarkan dengan jelas bagaimana pengguna berpikir dan memerlukan data untuk query dan analisis. Skema bintang menggambarkan hubungan antar tabel sama seperti cara pengguna melihat hubungan tersebut secara normal. 2. Mengoptimalkan navigasi sehingga pengguna lebih mudah mencari isi. Skema bintang mengoptimalisasikan navigasi melewati database sehingga lebih mudah dilihat. Meskipun hasil query terlihat kompleks, tetapi navigasi itu memudahkan pengguna. 29
30 3. Hasil dari proses eksekusi query juga relatif lebih cepat. Skema bintang paling cocok untuk pemrosesan query karena skema ini berpusat pada query. Tanpa bergantung pada banyak dimensi dan kompleksitas query, setiap query akan dengan mudah dijalankan, pertama dengan memilih baris dari table dimensi dan kemudian menemukan baris yang sama di tabel fakta.
Kerugian dimensi star schema : 1. Ukuran penyimpanan relatif lebih besar. Karena ada data yang berulang sehingga disk space yang digunakan lebih banyak. 2. Maintenance dan update lebih sulit. Karena tabel yang tidak normal, sehingga maintenance dan update lebih sulit.
3.1.2 Kelebihan dan kekurangan dimensi snowflake Keuntungan dari dimensi snowflake: 1. Ukuran penyimpanan kecil di dalam tempat penyimpanan. 2. Struktur yang normal lebih mudah untuk di-update dan di-maintenance.
Kerugian dari dimensi snowflake : 1. Skema snowflake kurang jelas dan pengguna akhir terhambat oleh kompleksitas. 2. Sulit untuk mencari isi karena terlalu kompleks. Pengguna lebih sulit mencari data yang ingin diinginkan karena datanya ada pada dimensi snowflake karena harus melalui dimensi star schema. 3. Performa query menurun karena adanya penambahan join table antar dimensi.
31 Setelah mengetahui keuntungan dan kerugian dari dimensi star schema dan
dimensi snowflake, akan dilakukan penelitian untuk mengetahui kebenaran dari teori diatas. 3.1.3 Hipotesa awal Berdasarkan kelebihan dan kekurangan yang telah dijabarkan diatas. Diambil dua hipotesa awal yang disebut juga hipotesa zero (nol) yaitu : •
Model dimensi snowflake lebih cepat dari model dimensi star schema
•
Model dimensi snowflake menggunakan disk space yang lebih kecil dari model dimensi star schema
Berdasarkan dari kedua hipotesa diatas, dilakukan uji coba kedua model dimensi dalam proses ETL dan proses OLAP.
3.2 Mempersiapkan data yang digunakan pada OLTP untuk uji coba Pada bagian ini dipersiapkan database OLTP yang digunakan untuk melakukan uji coba ETL. Database yang digunakan adalah database adventureworks yang merupakan database sampel yang telah disiapkan oleh Microsoft SqlServer 2005. Database adventureworks ini dapat diperoleh dengan cara melakukan instalasi tambahan pada Microsoft SqlServer 2005. Karena jumlah tabel yang dimiliki oleh adventureworks cukup banyak, maka akan diambil sebagian tabel yang digunakan untuk membuat skenario. Berikut gambar relation tabel yang digunakan dalam skenario yang dibuat :
32 ProductCategory (Production)
Customer (Sales)
P roductC ategory ID
SalesTerritory (Sales)
C ustomerID
N ame
Territory ID
Territory ID
row guid
N ame
A ccountN umber
M odifiedDate
C ountry RegionC ode
C ustomerTy pe
S alesP ersonID
S alesYTD
Territory ID
S alesLastYear
S alesQ uota
C ostYTD
Bonus
C ostLastYear
C ommissionP ct
P roductS ubcategory ID
row guid
S alesYTD
P roductC ategory ID
M odifiedDate
S alesLastYear
row guid M odifiedDate
Product (Production) P roductID
ProductSubcategory (P
N ame P roductN umber M akeF lag F inishedG oodsF lag C olor
SalesPerson (Sale
[G roup]
N ame
row guid
row guid
M odifiedDate
M odifiedDate
S afety S tockLev el
SalesOrderHeader (Sales)
ReorderP oint S tandardC ost
SalesOrderDetail (Sal
ListP rice
S alesO rderID
S ize
DueDate
C arrierTrackingN umber
WeightU nitM easureC ode
S hipDate
O rderQ ty
Weight
S tatus
P roductID
Day sToM anufacture
O nlineO rderF lag
U nitP rice
P roductLine
S alesO rderN umber
U nitP riceDiscount
C lass
A ccountN umber
row guid
P roductS ubcategory ID
M odifiedD ate
P roductM odelID
CreditCard (Sales)
S ellS tartDate
CurrencyRate (Sa C urrency RateID C urrency RateDate F romC urrency C ode ToC urrency C ode A v erageRate E ndO fDay Rate M odifiedD ate
P urchaseO rderN umber
LineTotal
S ty le
Rev isionN umber O rderDate
S alesO rderD etailID
S izeU nitM easureC ode
S alesO rderID
Address (Person)
C ustomerID
A ddressID
C ontactID
A ddressLine1
S alesP ersonID
A ddressLine2
Territory ID
C ity
BillToA ddressID
S tateP rov inceID
S ellE ndDate
C reditC ardID
DiscontinuedDate
C ardTy pe
row guid
C ardN umber
C ontactID
S hipToA ddressID
P ostalC ode
E xpM onth
N ameS ty le
S hipM ethodID
row guid
E xpYear
Title
C reditC ardID
M odifiedDate
M odifiedDate
F irstN ame
C reditC ardA pprov alC ode
M iddleN ame
C urrency RateID
LastN ame
S ubTotal
S hipM ethodID
P roductM odelID
S uffix
TaxA mt
N ame
N ame
E mailA ddress
F reight
S hipBase
C atalogDescription
E mailP romotion
TotalDue
S hipRate
Instructions
P hone
C omment
row guid
row guid
P assw ordH ash
row guid
M odifiedD ate
M odifiedDate
P assw ordS alt
M odifiedDate
ProductModel (Production)
Contact (Person)
A dditi
lC
ShipMethod (Purch
M odifiedDate t
SalesOrderHeader S alesO rderID
UnitMeasure (Production)
S alesReasonID
U nitM easureC ode
M odifiedD ate
N ame M odifiedDate
Gambar 3.1 Adventureworks diagram
Pada saat dilakukan perbandingan uji coba ETL dengan jumlah data awal yang terdapat pada adventureworks menghasilkan perbedaan waktu yang kecil, bahkan hampir tidak ada.
33
3.3 Skenario yang digunakan pada model dimensi star schema dan snowflake Berdasarkan tabel-tabel dan relasi yang ada pada gambar 3.1, dilakukan pembuatan skenario, dan dari skenario tersebut akan dibuat sejumlah record yang berbeda–beda dari tabel fakta. Ilustrasi skenario yang digunakan adalah supervisor dari perusahaan A ingin mendapatkan laporan penjualan barang meliputi jumlah barang yang terjual dan total penjualan dimana laporan tersebut dapat dilihat dari segi product, product subcategory, currency rate, dan customer. Supervisor perusahaan juga ingin melihat laporan tersebut dalam periode bulanan, quartal, dan tahunan. Dari permintaan tersebut, maka dibuatlah diagram OLAP dimensi star schema dan snowflake. DimCurrencyRate CurrencyRateKey CurrencyRateID CurrencyRateDate FromCurrencyCode ToCurrencyCode AverageRate
DimCustomer CustomerKey
FaktaPenjualan WaktuKey
CustomerID
ProductKey
CustomerType
SubCategoryKey
SalesTerritoryName
CustomerKey CurrencyRateKey
DimSubCategory SubCategoryKey ProductSubCategoryID Name CategoryName
Jumlah_barang_dijual
DimProduct
Total_penjualan
ProductKey
CreditCardApprovalCode
ProductID
SubTotal
Name
TaxAmt
MakeFlag
Freight
FinishedGoodsFlag
UnitPrice
Size
UnitPriceDiscount CarrierTrackingNumber
Gambar 3.2 Star schema diagram
DimWaktu WaktuKey Triwulan Tahun Bulan Hari
34 DimCurrencyRate CurrencyRateKey CurrencyRateID CurrencyRateDate FromCurrencyCode ToCurrencyCode AverageRate
DimProduct ProductKey ProductID SubCategoryKey Name
FaktaPenjualan WaktuKey ProductKey
MakeFlag
CustomerKey
FinishedGoodsFlag
CurrencyRateKey
Size
Jumlah_barang_dijual
WaktuKey
Total_penjualan
Triwulan
CreditCardApprovalCode
Tahun
SubTotal
Bulan
TaxAmt
Hari
DimWaktu
Freight
DimSubCategory SubCategoryKey ProductSubCategoryID
UnitPrice UnitPriceDiscount CarrierTrackingNumber
Name CategoryName
DimCustomer CustomerKey CustomerID CustomerType SalesTerritoryName
Gambar 3.3 Snowflake diagram
Diagram star schema (gambar 3.2) terdiri dari tabel fakta penjualan, dimensi currencyrate, dimensi subcategory, dimensi product, dimensi customer dan dimensi waktu dimana dimensi subcategory dan dimensi product terpisah, sehingga dimensi subcategory terhubung langsung dengan fakta penjualan. Sedangkan diagram snowflake (gambar 3.3) memiliki perbedaan daripada star schema dimana tabel dimensi
35
subcategory dan dimensi product terhubung sehingga tabel dimensi subcategory tidak terhubung langsung dengan fakta penjualan. Berikut sejumlah skenario yang digunakan untuk uji coba ETL dengan model dimensi star schema dan snowflake dimana jumlah data bervariasi, yakni : • Tabel fakta dengan jumlah data ± 500.000 record Record pada adventureworks ditambahkan sehingga menghasilkan jumlah fakta ± 500.000 record. Dari skenario ini dibuat 4 skenario baru yakni : 1. Skenario
pertama
dibuat
dengan
menggunakan
data
dari
database
adventureworks. Kemudian jumlah record pada tabel fakta diperbesar menjadi ± 500.000 record sedangkan jumlah tabel lainnya tetap. 2. Skenario kedua dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel subcategory diperbesar menjadi ± 500.000 record. 3. Skenario ketiga dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel product diperbesar menjadi ± 500.000 record. 4. Skenario keempat dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel subcategory dan product diperbesar menjadi ± 500.000 record. Tabel 3.1 Jumlah data pada setiap tabel berdasarkan skenario di atas Nama tabel DimSubCategory DimProduct DimCustomer DimCurrencyRate DimWaktu FaktaPenjualan
Skenario ke-1 (record) 100.800 100.799 200.000 13.562 1.124 500.039
Skenario ke-2 (record) 500.000 100.799 200.000 13.562 1.124 500.039
Skenario ke-3 (record) 100.800 500.000 200.000 13.562 1.124 500.039
Skenario ke-4 (record) 500.000 500.000 200.000 13.562 1.124 500.039
36 • Tabel fakta dengan jumlah data ± 1.000.000 record Data pada adventureworks ditambahkan sehingga menghasilkan jumlah fakta ±
1.000.000 record. Dari skenario ini dibuat 4 skenario baru, yakni : 1. Skenario
pertama
dibuat
dengan
menggunakan
data
dari
database
adventureworks. Kemudian jumlah record pada tabel fakta diperbesar menjadi ± 1.000.000 record sedangkan tabel lainnya tetap. 2. Skenario kedua dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada table subcategory diperbesar menjadi ± 3.000.000 record. 3. Skenario ketiga dibuat dengan menggunakan data dari skenario pertama . Kemudian jumlah record pada tabel product diperbesar menjadi ± 3.000.000 record. 4. Skenario keempat dibuat dengan menggunakan data dari skenario pertama . Kemudian jumlah record pada tabel subcategory dan product diperbesar menjadi ± 3.000.000 record.
Tabel 3.2 Jumlah data pada tabel berdasarkan skenario di atas Nama tabel DimSubCategory DimProduct DimCustomer DimCurrencyRate DimWaktu FaktaPenjualan
Skenario ke-1 (record) 300.000 300.000 289.702 13.562 1.124 996.187
Skenario ke-2 (record) 3.030.600 300.000 289.702 13.562 1.124 996.187
Skenario ke-3 (record) 300.000 3.000.010 289.702 13.562 1.124 996.187
Skenario ke-4 (record) 3.000.000 3.000.000 289.702 13.562 1.124 996.187
37 • Tabel fakta dengan jumlah data ± 3.000.000 record Data pada adventureworks ditambahkan sehingga menghasilkan jumlah fakta ±
3.000.000 record. Dari skenario ini dibuat 4 skenario baru, yakni : 1. Skenario
pertama
dibuat
dengan
menggunakan
data
dari
database
adventureworks. Kemudian jumlah record pada tabel fakta diperbesar menjadi ± 3.000.000 record sedangkan tabel lainnya tetap. 2. Skenario kedua dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel subcategory diperbesar menjadi ± 5.000.000 record. 3. Skenario ketiga dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel product diperbesar menjadi ± 5.000.000 record. 4. Skenario keempat dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel subcategory dan product diperbesar menjadi ± 5.000.000 record.
Tabel 3.3 Jumlah data pada tabel berdasarkan skenario di atas Nama tabel DimSubCategory DimProduct DimCustomer DimCurrencyRate DimWaktu FaktaPenjualan
Skenario ke-1 (record) 300.000 300.000 289.702 13.562 1.124 3.000.000
Skenario ke-2 (record) 5.051.100 300.000 289.702 13.562 1.124 3.000.000
Skenario ke-3 (record) 300.000 5.040.000 289.702 13.562 1.124 3.000.000
Skenario ke-4 (record) 5.051.100 5.040.000 289.702 13.562 1.124 3.000.000
38 • Tabel fakta dengan jumlah data ± 10.000.000 record Data pada adventureworks ditambahkan sehingga menghasilkan jumlah tabel
fakta ± 10.000.00 record. Dari skenario ini dibuat 4 skenario baru, yakni : 1. Skenario
pertama
dibuat
dengan
menggunakan
data
dari
database
adventureworks. Kemudian jumlah record pada tabel fakta diperbesar menjadi ± 10.000.000 record sedangkan tabel lainnya tetap. 2. Skenario kedua dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada table subcategory diperbesar menjadi ± 15.000.000 record. 3. Skenario ketiga dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel product diperbesar menjadi ± 13.000.000 record. 4. Skenario keempat dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel subcategory dan product diperbesar menjadi ± 15.000.000 record.
Tabel 3.4 Jumlah data pada tabel berdasarkan skenario di atas Nama tabel DimSubCategory DimProduct DimCustomer DimCurrencyRate DimWaktu FaktaPenjualan
Skenario ke-1 (record) 5.051.100 5.040.000 289.702 13.562 1.124 9.282175
Skenario ke-2 (record) 15.152.736 5.040.000 289.702 13.562 1.124 9.282.175
Skenario ke-3 (record) 5.051.100 13.621.376 289.702 13.562 1.124 9.282175
Skenario ke4 (record) 15.152.736 15.040.000 289.702 13.562 1.124 9.282.175
39
3.4 Persiapan data OLTP berdasarkan skenario yang dibuat Berdasarkan skenario yang telah dibuat subbab di atas, dilakukan penambahan jumlah record pada beberapa tabel. Berikut persiapan data yang dilakukan : 1. Jumlah record pada tabel salesorderdetail ditambahkan sebanyak ± 500.000 record a. Skenario pertama Skenario
pertama
adalah
dengan
menggunakan
data
dari
database
adventureworks. Kemudian jumlah record pada salesorderdetail diperbesar sebanyak ± 500.000 record sedangkan tabel lainnya tetap. b. Skenario kedua Skenario kedua dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel productsubcategory diperbesar menjadi ± 500.000 record. c. Skenario ketiga Skenario ketiga dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel product diperbesar menjadi ± 500.000 record. d. Skenario keempat Skenario keempat dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel productsubcategory dan product diperbesar menjadi ± 500.000 record. Tabel 3.5 Jumlah data tabel berdasarkan skenario di atas Nama tabel ProductSubCategory Product Customer CurrencyRate Waktu SalesOrderDetail
Skenario ke-1 (record) 100.800 100.799 200.000 13.562 1.124 500.039
Skenario ke-2 (record) 500.000 100.799 200.000 13.562 1.124 500.039
Skenario ke-3 (record) 100.800 500.000 200.000 13.562 1.124 500.039
Skenario ke-4 (record) 500.000 500.000 200.000 13.562 1.124 500.039
40 2. Jumlah record pada tabel salesorderdetail ditambahkan sebanyak ± 1.000.000 record a. Skenario pertama Skenario
pertama
adalah
dengan
menggunakan
data
dari
database
adventureworks. Kemudian jumlah record pada salesorderdetail diperbesar sebanyak ± 1.000.000 record sedangkan tabel lainnya tetap. b. Skenario kedua Skenario kedua dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel productsubcategory diperbesar menjadi ± 3.000.000 record. c. Skenario ketiga Skenario ketiga dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel product diperbesar menjadi ± 3.000.000 record. d. Skenario keempat Skenario keempat dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel productsubcategory dan product diperbesar menjadi ± 3.000.000 record.
Tabel 3.6 Jumlah data tabel berdasarkan skenario di atas Nama tabel ProductSubCategory Product Customer CurrencyRate Waktu SalesOrderDetail
Skenario ke-1 (record) 300.000 300.000 289.702 13.562 1.124 996.187
Skenario ke-2 (record) 3.030.600 300.000 289.702 13.562 1.124 996.187
Skenario ke-3 (record) 300.000 3.000.010 289.702 13.562 1.124 996.187
Skenario ke-4 (record) 3.000.000 3.000.000 289.702 13.562 1.124 996.187
41 3. Jumlah record pada tabel salesorderdetail ditambahkan sebanyak ± 3.000.000 record a. Skenario pertama Skenario
pertama
adalah
dengan
menggunakan
data
dari
database
Adventureworks. Kemudian jumlah record pada salesorderdetail diperbesar sebanyak ± 3.000.000 record sedangkan tabel lainnya tetap. b. Skenario kedua Skenario kedua dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel productsubcategory diperbesar menjadi ± 5.000.000 record. c. Skenario ketiga Skenario ketiga dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel product diperbesar menjadi ± 5.000.000 record. d. Skenario keempat Skenario keempat dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel productsubcategory dan product diperbesar menjadi ± 5.000.000 record.
Tabel 3.7 Jumlah data tabel berdasarkan skenario di atas Nama tabel ProductSubCategory Product Customer CurrencyRate Waktu SalesOrderDetail
Skenario ke-1 (record) 300.000 300.000 289.702 13.562 1.124 3.000.000
Skenario ke-2 (record) 5.051.100 300.000 289.702 13.562 1.124 3.000.000
Skenario ke-3 (record) 300.000 5.040.000 289.702 13.562 1.124 3.000.000
Skenario ke-4 (record) 5.051.100 5.040.000 289.702 13.562 1.124 3.000.000
42 4. Jumlah record pada tabel salesorderdetail ditambahkan sebanyak ± 10.000.000 record a. Skenario pertama Skenario pertama adalah dengan menggunakan data dari database adventureworks. Kemudian jumlah record pada salesorderdetail diperbesar sebanyak ± 10.000.000 record sedangkan tabel lainnya tetap. b. Skenario kedua Skenario kedua dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel productsubcategory diperbesar menjadi ± 15.000.000 record. c. Skenario ketiga Skenario ketiga dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel product diperbesar menjadi ± 13.000.000 record. d. Skenario keempat Skenario keempat dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel productsubcategory dan product diperbesar menjadi ± 15.000.000 record. Tabel 3.8 Jumlah data tabel berdasarkan skenario di atas Nama tabel ProductSubCategory Product Customer CurrencyRate Waktu SalesOrderDetail
Skenario ke-1 (record) 5.051.100 5.040.000 289.702 13.562 1.124 9.282.175
Skenario ke-2 (record) 15.152.736 5.040.000 289.702 13.562 1.124 9.282.175
Skenario ke-3 (record) 5.051.100 13.621.376 289.702 13.562 1.124 9.282.175
Skenario ke-4 (record) 15.152.736 15.040.000 289.702 13.562 1.124 9.282.175
43
3.5 Perhitungan penggunaan disk space untuk data OLAP Perhitungan penggunaan disk space untuk data OLAP dilakukan pada tiap skenario yang telah dijabarkan, untuk membandingkan penggunaan disk space pada model dimensi star schema dan snowflake. 3.5.1 Penggunaan disk space pada model dimensi star schema Perkiraan penggunaan kebutuhan disk space pada skenario awal untuk model dimensi star schema adalah sebagai berikut : Tabel 3.9 Estimasi penggunaan disk space tabel dimcurrencyrate CurrencyRateKey Int CurrencyRateID Int CurrencyRateDate Datetime FromCurrencyCode Nchar ToCurrencyCode Nchar AverageRate Money Kapasitas dari table DimCurrencyRate adalah 30 byte.
4 4 8 3 3 8
Tabel 3.10 Estimasi penggunaan disk space tabel dimcustomer CustomerKey CustomerID CustomerType SalesTerritoryName Kapasitas dari table DimCustomer adalah 59 byte.
Int Int Nchar Nvarchar
4 4 1 50
Tabel 3.11 Estimasi penggunaan disk space tabel dimproduct ProductKey ProductID Name MakeFlag FinishedGoodsFlag Size Kapasitas dari table DimProduct adalah 65 byte.
Int Int Nvarchar Bit Bit Nvarchar
4 4 50 1 1 5
Tabel 3.12 Estimasi penggunaan disk space tabel dimsubcategory SubCategoryKey Int ProductSubCategoryID Int Name Nvarchar CategoryName Nvarchar Kapasitas dari table DimSubCategory adalah 108 byte.
4 4 50 50
44 Tabel 3.13 Estimasi penggunaan disk space tabel dimwaktu WaktuKey Triwulan Tahun Bulan Hari Kapasitas dari table DimSubCategory adalah 20 byte.
Int Int Int Int Int
4 4 4 4 4
Tabel 3.14 Estimasi penggunaan disk space tabel faktapPenjualan WaktuKey Int ProductKey Int SubCategoryKey Int CustomerKey Int CurrencyRateKey Int Jumlah_barang_dijual Money Total_penjualan Int CreditCardApprovalCode Varchar SubTotal Money TaxAmt Money Freight Money UnitPrice Money UnitPriceDiscount Money CarrierTrackingNumber Nvarchar Kapasitas dari table DimSubCategory adalah 112 byte.
4 4 4 4 4 8 4 15 8 8 8 8 8 25
Tabel 3.15 Estimasi penggunaan disk space tabel filtertimestamp Last_ETL_Process_Date Datetime Table_Name Varchar Kapasitas dari table DimSubCategory adalah 58 byte.
8 50
Tabel 3.16 Penggunaan total disk space model dimensi star schema skenario pertama dengan jumlah record tabel fakta ± 500.000 record Nama table DimCurrencyRate DimCustomer DimProduct DimSubCategory DimWaktu FaktaPenjualan FilterTimeStamp Total
Space disk untuk 1 baris 30 byte 59 byte 65 byte 108 byte 20 byte 112 byte 58 byte
Jumlah data 13562 200000 100799 100800 1124 500039 6
Total Penggunaan 406860 byte 11800000 byte 6551935 byte 10886400 byte 22480 byte 56004368 byte 348 byte 85672391 byte 83664.44 Kbyte 81.7 MByte
45
3.5.2 Penggunaan disk space pada model dimensi snowflake Perkiraan penggunaan kebutuhan disk space pada skenario awal untuk model dimensi snowflake adalah sebagai berikut : Tabel 3.17 Estimasi penggunaan disk space tabel dimcurrencyrate CurrencyRateKey Int CurrencyRateID Int CurrencyRateDate Datetime FromCurrencyCode Nchar ToCurrencyCode Nchar AverageRate Money Kapasitas dari table DimCurrencyRate adalah 30 byte.
4 4 8 3 3 8
Tabel 3.18 Estimasi penggunaan disk space tabel dimcustomer CustomerKey CustomerID CustomerType SalesTerritoryName Kapasitas dari table DimCustomer adalah 59 byte.
Int Int Nchar Nvarchar
4 4 1 50
Tabel 3.19 Estimasi penggunaan disk space tabel dimproduct ProductKey ProductID SubCategoryKey Name MakeFlag FinishedGoodsFlag Size Kapasitas dari table DimProduct adalah 69 byte.
Int Int Int Nvarchar Bit Bit Nvarchar
4 4 4 50 1 1 5
Tabel 3.20 Estimasi penggunaan disk space tabel dimsubcategory SubCategoryKey Int ProductSubCategoryID Int Name Nvarchar CategoryName Nvarchar Kapasitas dari table DimSubCategory adalah 108 byte.
4 4 50 50
Tabel 3.21 Estimasi penggunaan disk space tabel dimwaktu WaktuKey Triwulan Tahun Bulan Hari Kapasitas dari table DimSubCategory adalah 20 byte.
Int Int Int Int Int
4 4 4 4 4
46 Tabel 3.22 Estimasi penggunaan disk space tabel faktapenjualan WaktuKey Int ProductKey Int CustomerKey Int CurrencyRateKey Int Jumlah_barang_dijual Money Total_penjualan Int CreditCardApprovalCode Varchar SubTotal Money TaxAmt Money Freight Money UnitPrice Money UnitPriceDiscount Money CarrierTrackingNumber Nvarchar Kapasitas dari table DimSubCategory adalah 108 byte.
4 4 4 4 8 4 15 8 8 8 8 8 25
Tabel 3.23 Estimasi penggunaan disk space tabel filtertimestamp Last_ETL_Process_Date Datetime Table_Name Varchar Kapasitas dari table DimSubCategory adalah 58 byte.
8 50
Tabel 3.24 Penggunaan total disk space model dimensi snowflake skenario pertama dimana tabel fakta berjumlah ± 500.000 record Nama table DimCurrencyRate DimCustomer DimProduct DimSubCategory DimWaktu FaktaPenjualan FilterTimeStamp Total
Space disk untuk 1 baris 30 byte 59 byte 69 byte 108 byte 20 byte 108 byte 58 byte
Jumlah data 13562 200000 100799 100800 1124 500039 6
Total Penggunaan 406860 byte 11800000 byte 6955131 byte 10886400 byte 22480 byte 54004212 byte 348 byte 84075431 byte 82104.91 Kbyte 80.18 Mbyte
3.6 Pengujian ETL Setelah menyiapkan data yang sesuai dengan skenario yang ditentukan di atas, dilakukan pengujian ETL (Extract, Transform, Loading). Uji coba ETL dilakukan secara berulang-ulang pada setiap skenario, dari skenario satu sampai skenario empat, dan terdapat perbedaan waktu ETL pada satu skenario yang dilakukan berulang-ulang.
47
Perbedaan waktu yang terjadi tidak tetap. Seperti pada skenario satu dengan skenario dua, skenario dua dengan skenario tiga, rentang waktunya selalu berbeda. Perbedaan waktu tersebut dapat dipengaruhi oleh berbagai faktor, seperti jumlah program yang sedang dikerjakan oleh CPU, respon CPU, berbagai faktor lainnya.
3.6.1 Uji coba pada model dimensi Star schema Hasil dari uji coba ETL pada model dimensi Star schema dari semua skenario sebagai berikut : • Skenario dimana tabel fakta berjumlah ± 500.000 record Tabel 3.25 Detail waktu ETL dimana fakta berjumlah ± 500.000 record Nama tabel Subcategory Product Customer CurrencyRate Waktu FaktaPenjualan Total
Skenario ke-1 (Detik) 3,422 2,828 3,719 344 312 14,500 25,125
Skenario ke-2 (Detik) 13,657 2,781 4,312 1,484 313 16,391 38,938
Skenario ke-3 (Detik) 3,766 11,578 3,094 1,437 313 16,531 36,719
Skenario ke-4 (Detik) 10,625 10,375 5,422 1,205 250 18,438 46,315
• Skenario dimana tabel fakta berjumlah ± 1.000.000 record Tabel 3.26 Detail waktu ETL dimana tabel fakta berjumlah ± 1.000.000 record Nama tabel Subcategory Product Customer CurrencyRate Waktu FaktaPenjualan Total
Skenario ke-1 (Detik) 5,812 6,187 8,250 328 297 29,953 50,827
Skenario ke-2 (Detik) 93,125 21,015 3,984 1,485 328 32,250 152,187
Skenario ke-3 (Detik) 8,750 82,141 7,656 1,453 297 98,422 198,719
Skenario ke-4 (Detik) 84,031 64,828 7,906 297 344 33,453 190,859
48 • Skenario dimana tabel fakta berjumlah ± 3.000.000 record Tabel 3.27 Detail waktu ETL dimana tabel fakta berjumlah ± 3.000.000 record Nama tabel Subcategory Product Customer CurrencyRate Waktu FaktaPenjualan Total
Skenario ke-1 (Detik) 8,813 7,844 4,172 1,532 297 95,047 117,705
Skenario ke-2 (Detik) 145,937 4,687 3,406 1,437 282 79,547 235,296
Skenario ke-3 (Detik) 7,969 148,468 3,750 328 312 125,109 285,936
Skenario ke-4 (Detik) 162,469 119,156 3,485 1,422 282 180,797 467,611
• Skenario dimana tabel fakta berjumlah ± 10.000.000 record Tabel 3.28 Detail waktu ETL dimana tabel fakta berjumlah ± 10.000.000 record Nama tabel Subcategory Product Customer CurrencyRate Waktu FaktaPenjualan Total
Skenario ke-1 (Detik) 169,656 127,719 5,547 391 297 693,875 997,485
Skenario ke-2 (Detik) 310,735 156,516 8,625 328 786 1,013,391 1.490,381
Skenario ke-3 (Detik) 117,782 432,968 8,985 453 297 1,189,125 1.749,610
Skenario ke-4 (Detik) 345,453 382,891 7,219 297 1,688 1,078,844 1.816,392
Beberapa hasil yang didapatkan dari tabel di atas : •
Waktu tabel dimensi subcategory pada skenario kedua lebih besar daripada skenario pertama karena jumlah record pada skenario kedua lebih banyak.
•
Waktu pada skenario ketiga lebih kecil dari skenario kedua karena jumlah record tabel dimensi subcategory pada skenario ketiga sama dengan jumlah record pada skenario pertama.
•
Waktu tabel dimensi product pada skenario pertama lebih besar dari skenario kedua padahal memiliki jumlah record yang sama, hal ini karena beberapa faktor yang telah dituliskan di atas. Hal yang sama juga terjadi pada skenario ketiga dan keempat tabel dimensi product.
49 •
Jumlah record pada tabel dimensi customer sama tetapi menghasilkan waktu yang berbeda-beda karena beberapa faktor yang telah disebutkan di atas.
•
Jumlah record pada dimensi currencyrate sama tetapi menghasilkan waktu yang berbeda-beda karena beberapa faktor yang telah disebutkan di atas.
•
Jumlah record pada tabel dimensi waktu sama tetapi menghasilkan waktu yang berbeda-beda karena beberapa faktor yang telah disebutkan di atas.
•
Jumlah record pada fakta sama tetapi menghasilkan waktu yang berbeda-beda karena beberapa faktor yang telah disebutkan di atas. Tabel 3.29 Perhitungan total waktu ETL untuk setiap skenario pada model dimensi star schema
Jumlah record tabel fakta 500.000 record 1.000.000 record 3.000.000 record 10.000.000 record
Skenario ke-1 (Detik) 25.125 50.827 117.705 997.485
Skenario ke-2 (Detik) 38.938 152.187 235.296 1490.381
Skenario ke-3 (Detik) 36.719 194.938 285.936 1749.610
Skenario ke-4 (Detik) 46.315 190.859 467.611 1816.392
3.6.2 Uji coba pada model dimensi Snowflake Hasil dari uji coba ETL pada model dimensi snowflake dari semua skenario sebagai berikut : • Skenario dimana tabel fakta ± 500.000 record Tabel 3.30 Detail waktu ETL dimana tabel fakta ± 500.000 record Nama tabel Subcategory Product Customer CurrencyRate Waktu FaktaPenjualan Total
Skenario ke-1 (Detik) 3,422 1,422 2,891 1,672 0,218 9,640 19,265
Skenario ke-2 (Detik) 7,375 2,344 6,469 0,313 0,219 11,516 28,236
Skenario ke-3 (Detik) 3,937 10,016 5,015 1,594 0,297 10,937 31,796
Skenario ke-4 (Detik) 7,125 9,282 4,922 1,672 0,250 13,953 37,204
50 • Skenario dimana tabel fakta ± 1.000.000 record Tabel 3.31 Detail waktu ETL dimana tabel fakta ± 1.000.000 record Nama tabel Subcategory Product Customer CurrencyRate Waktu FaktaPenjualan Total
Skenario ke -1 (Detik) 3,641 6,391 8,391 0,297 0,234 21,594 40,548
Skenario ke -2 (Detik) 62,375 31,047 7,453 0,313 0,250 24,344 125,782
Skenario ke -3 (Detik) 7,484 94,265 8,406 0,297 0,219 21,984 132,655
Skenario ke -4 (Detik) 75,953 91,547 5,610 0,375 0,250 24,281 198,016
• Skenario dimana tabel fakta ± 3.000.000 record Tabel 3.32 Detail waktu ETL dimana tabel fakta ± 3.000.000 record Nama tabel Subcategory Product Customer CurrencyRate Waktu FaktaPenjualan Total
Skenario ke -1 (Detik) 8,234 5,016 4,391 0,187 0,219 62,797 80,844
Skenario ke -2 (Detik) 114,844 17,922 7,015 1,719 0,282 92,187 233,969
Skenario ke -3 (Detik) 9,203 150,625 4,485 0,422 0,266 94,406 259,407
Skenario ke -4 (Detik) 85,938 147,782 8,328 0,360 0,328 106,188 348,924
• Skenario dimana tabel fakta ± 10.000.000 record Tabel 3.33 Detail waktu ETL dimana tabel fakta ± 10.000.000 record Nama tabel Subcategory Product Customer CurrencyRate Waktu FaktaPenjualan Total
Skenario ke-1 (Detik) 153,219 136,672 7,969 0,359 0,296 463,125 761,640
Skenario ke-2 (Detik) 324,593 162,522 8,094 0,344 0,281 384,469 880,303
Skenario ke-3 (Detik) 103,109 519,765 7,750 0,313 0,282 336,094 967,313
Skenario ke-4 (Detik) 339,219 567,829 7,625 0,391 0,297 342,719 1.258,080
Beberapa hasil yang didapatkan dari tabel di atas : •
Waktu tabel dimensi subcategory pada skenario kedua lebih besar daripada skenario pertama karena jumlah record pada skenario kedua lebih banyak.
51 •
Waktu pada skenario ketiga lebih kecil dari skenario kedua karena jumlah record tabel dimensi subcategory pada skenario ketiga sama dengan jumlah record pada skenario pertama.
•
Waktu tabel dimensi product pada skenario pertama lebih besar dari skenario kedua padahal memiliki jumlah record yang sama, hal ini karena beberapa faktor yang telah dituliskan di atas. Hal yang sama juga terjadi pada skenario ketiga dan keempat tabel dimensi product.
•
Jumlah record pada tabel dimensi customer sama tetapi menghasilkan waktu yang berbeda-beda karena beberapa faktor yang telah disebutkan di atas.
•
Jumlah record pada dimensi currencyrate sama tetapi menghasilkan waktu yang berbeda-beda karena beberapa faktor yang telah disebutkan di atas.
•
Jumlah record pada tabel dimensi waktu sama tetapi menghasilkan waktu yang berbeda-beda karena beberapa faktor yang telah disebutkan di atas.
•
Jumlah record pada tabel fakta sama tetapi menghasilkan waktu yang berbedabeda karena beberapa faktor yang telah disebutkan di atas. Tabel 3.34 Perhitungan waktu total ETL untuk setiap skenario pada model dimensi snowflake
Jumlah record tabel fakta 500000 record 1000000 record 3000000 record 10000000 record
Skenario ke-1 (Detik) 19.265 40.548 80.844 761.64
Skenario ke-2 (Detik) 28.236 125.782 233.969 880.303
Skenario ke-3 (Detik) 31.796 128.921 259.407 967.313
Skenario ke-4 (Detik) 37.204 198.016 348.924 1257.689
3.7 Pengujian hasil proses OLAP (Analysis Services) Setelah diperoleh hasil dari ETL, maka dilakukan perhitungan waktu proses analysis dan besar size database pada proses OLAP (pada Analysis Services). Perhitungan dilakukan pada semua skenario dari hasil ETL.
52
3.7.1 Waktu proses analysis OLAP Perhitungan waktu proses OLAP dengan menggunakan tools SQL Server Analysis Services kemudian mencatat waktu yang dibutuhkan. Oleh karena waktu yang diperoleh memiliki rentang waktu yang cukup lebar, maka pencatatan waktu dilakukan dengan format jam, menit, dan detik (hh:mm:ss).
3.7.1.1 Waktu proses OLAP dengan model dimensi star schema Pencatatan waktu dari proses OLAP dengan model dimensi star schema sebagai berikut : Tabel 3.35 Waktu proses OLAP pada star schema Jumlah record tabel fakta 500.000 record 1.000.000 record 3.000.000 record 10.000.000 record
Skenario ke-1 00:00:19 00:00:31 00:00:52 00:17:17
Skenario ke-2 00:00:27 00:02:17 00:03:41 00:25:27
Skenario ke-3 00:00:26 00:04:28 00:06:07 01:30:11
Skenario ke-4 00:00:33 00:04:32 00:15:21 04:02:00
hasil yang didapatkan dari tabel di atas : •
Semakin besar jumlah record tabel fakta, semakin besar waktu yang dibutuhkan pada proses OLAP.
•
Waktu pada skenario pertama paling cepat, karena jumlah record yang dimiliki paling sedikit (penambahan record hanya pada tabel fakta).
•
Waktu pada skenario keempat paling lama, karena jumlah record yang dimiliki paling banyak (penambahan record pada tabel fakta, dimensi subcategory, dan dimensi
product)
dan
juga
membutuhkan
waktu
untuk
pengelompokkan data pada tabel product berdasarkan subcategory.
melakukan
53
3.7.1.2 Waktu proses OLAP dengan model dimensi snowflake Pencatatan waktu dari proses OLAP dengan model dimensi snowflake sebagai berikut . Tabel 3.36 Waktu proses OLAP pada snowflake Jumlah record tabel fakta 500.000 record 1.000.000 record 3.000.000 record 10.000.000 record
Skenario ke -1 00:00:15 00:00:35 00:00:57 00:18:38
Skenario ke -2 00:00:25 00:03:44 00:05:54 00:32:38
Skenario ke -3 00:00:26 00:04:45 00:08:50 01:52:22
Skenario ke -4 00:00:39 00:07:08 00:18:21 09:07:48
hasil yang didapatkan dari tabel di atas : •
Semakin besar jumlah record tabel fakta, semakin besar waktu yang dibutuhkan pada proses OLAP.
•
Waktu pada skenario pertama paling cepat, karena jumlah record yang dimiliki paling sedikit (penambahan record hanya pada tabel fakta).
•
Waktu pada skenario keempat paling lama, karena jumlah record yang dimiliki paling banyak (penambahan record pada tabel fakta, dimensi subcategory, dan dimensi product).
3.7.2 Size database hasil analysis OLAP Pada akhir proses analysis OLAP, dihasilkan database yang ukurannya berbedabeda sesuai dengan banyaknya record dan model dimensi yang digunakan. Berikut ini adalah jumlah size yang di peroleh berdasarkan jumlah record dan skenario yang dibuat :
54
3.7.2.1 Size database hasil proses OLAP dengan model dimensi star schema Pengukuran size database hasil proses OLAP dengan model dimensi star schema sebagai berikut :
Tabel 3.37 Size database hasil proses OLAP pada star schema Jumlah record tabel fakta 5000.00 record 1.000.000 record 3.000.000 record 10.000.000 record
Skenario ke-1
Skenario ke-2
Skenario ke-3
Skenario ke-4
90.4 MB 199 MB 248 MB 2.37 GB
165 MB 896 MB 1.16 GB 3.95 GB
184 MB 848 MB 1.38 GB 4.42 GB
259 MB 1.33 GB 2.28 GB 6.04 GB
hasil yang didapatkan dari tabel di atas : •
Size database pada skenario pertama paling kecil karena jumlah record yang terdapat pada skenario pertama paling kecil (penambahan record hanya pada tabel fakta).
•
Size database pada skenario kempat paling besar karena jumlah record yang terdapat pada skenario keempat paling besar (penambahan record pada tabel fakta, dimensi subcategory, dan dimensi product).
•
Size database pada skenario kedua dan ketiga ukurannya berbeda-beda berdasarkan jumlah record tabel dimensi subcategory dan dimensi product.
55
3.7.2.2 Size database hasil proses OLAP dengan model dimensi snowflake Pengukuran size database hasil proses OLAP dengan model dimensi snowflake sebagai berikut : Tabel 3.38 Size database hasil proses OLAP pada snowflake Jumlah record tabel fakta 500.000 record 1.000.000 record 3.000.000 record 1.0000.000 record
Skenario ke-1
Skenario ke-2
Skenario ke-3
Skenario ke-4
93.4 MB 213 MB 291 MB 2.57 GB
172 MB 976 MB 1.24 GB 4.33 GB
196 MB 921 MB 1.5 GB 4.86 GB
276 MB 1.45 GB 2.48 GB 6.67 GB
hasil yang didapatkan dari tabel di atas : •
Size database pada skenario pertama paling kecil karena jumlah record yang terdapat pada skenario pertama paling kecil (penambahan record hanya pada tabel fakta).
•
Size database pada skenario kempat paling besar karena jumlah record yang terdapat pada skenario keempat paling besar (penambahan record pada tabel fakta, dimensi subcategory, dan dimensi product).
•
Size database OLAP pada skenario kedua dan ketiga ukurannya berbeda-beda berdasarkan jumlah record tabel dimensi subcategory dan dimensi product.
