29
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.
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.
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
SalesOrderDetail (Sal SalesO rderID SalesO rderDetailID C arrierTrackingN umber O rderQ ty ProductID U nitPrice U nitPriceDiscount LineTotal row guid M odifiedDate Address (Person) A ddressID A ddressLine1 A ddressLine2 C ity S tateProv inceID P ostalC ode row guid M odifiedDate Contact (Person) C ontactID N ameSty le Title F irstN ame M iddleName LastName Suffix EmailA ddress EmailPromotion Phone Passw ordHash Passw ordSalt A dditi lC t CreditCard (Sales) C reditC ardID C ardTy pe C ardNumber ExpM onth ExpYear ModifiedDate CurrencyRate (Sa C urrency RateID C urrency RateDate F romC urrency C ode ToC urrency C ode A v erageRate EndO fDay Rate M odifiedDate Customer (Sales) C ustomerID Territory ID A ccountN umber C ustomerTy pe row guid ModifiedDate SalesPerson (Sale S alesPersonID Territory ID S alesQ uota Bonus C ommissionPct S alesYTD S alesLastYear row guid M odifiedDate ShipMethod (Purch ShipM ethodID N ame ShipBase ShipRate row guid M odifiedDate SalesTerritory (Sales) Territory ID Name C ountry RegionC ode [Group] SalesYTD SalesLastYear C ostYTD C ostLastYear row guid ModifiedDate SalesOrderHeader SalesO rderID SalesReasonID M odifiedDate SalesOrderHeader (Sales) SalesO rderID Rev isionNumber O rderDate DueDate ShipDate Status O nlineO rderF lag SalesO rderNumber PurchaseO rderN umber A ccountNumber C ustomerID C ontactID SalesPersonID Territory ID BillToA ddressID ShipToA ddressID ShipMethodID C reditC ardID C reditC ardA pprov alC ode C urrency RateID SubTotal TaxA mt F reight TotalDue C omment row guid ModifiedDate Product (Production) ProductID Name ProductNumber MakeF lag F inishedGoodsF lag C olor Safety StockLev el ReorderPoint StandardC ost ListPrice Size SizeUnitMeasureC ode WeightUnitMeasureC ode Weight Day sToManufacture ProductLine C lass Sty le ProductSubcategory ID ProductM odelID SellStartDate SellEndDate DiscontinuedDate row guid ModifiedDate ProductSubcategory (P ProductSubcategory ID ProductC ategory ID Name row guid ModifiedDate ProductModel (Production) P roductModelID N ame C atalogDescription Instructions row guid M odifiedDate UnitMeasure (Production) U nitM easureC ode
N ame M odifiedDate ProductCategory (Production) ProductC ategory ID Name row guid ModifiedDate
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.
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 CustomerID CustomerType SalesTerritoryName DimProduct ProductKey ProductID Name MakeFlag FinishedGoodsFlag Size DimSubCategory SubCategoryKey ProductSubCategoryID Name CategoryName DimWaktu WaktuKey Triwulan Tahun Bulan Hari FaktaPenjualan WaktuKey ProductKey SubCategoryKey CustomerKey CurrencyRateKey Jumlah_barang_dijual Total_penjualan CreditCardApprovalCode SubTotal TaxAmt Freight UnitPrice UnitPriceDiscount CarrierTrackingNumber
DimCurrencyRate CurrencyRateKey CurrencyRateID CurrencyRateDate FromCurrencyCode ToCurrencyCode AverageRate DimCustomer CustomerKey CustomerID CustomerType SalesTerritoryName DimProduct ProductKey ProductID SubCategoryKey Name MakeFlag FinishedGoodsFlag Size DimSubCategory SubCategoryKey ProductSubCategoryID Name CategoryName DimWaktu WaktuKey Triwulan Tahun Bulan Hari FaktaPenjualan WaktuKey ProductKey CustomerKey CurrencyRateKey Jumlah_barang_dijual Total_penjualan CreditCardApprovalCode SubTotal TaxAmt Freight UnitPrice UnitPriceDiscount CarrierTrackingNumber
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
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 Skenario ke-1 (record) Skenario ke-2 (record) Skenario ke-3 (record) Skenario ke-4 (record) DimSubCategory 100.800 500.000 100.800 500.000 DimProduct 100.799 100.799 500.000 500.000 DimCustomer 200.000 200.000 200.000 200.000 DimCurrencyRate 13.562 13.562 13.562 13.562 DimWaktu 1.124 1.124 1.124 1.124 FaktaPenjualan 500.039 500.039 500.039 500.039
• 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 Skenario ke-1 (record) Skenario ke-2 (record) Skenario ke-3 (record) Skenario ke-4 (record) DimSubCategory 300.000 3.030.600 300.000 3.000.000 DimProduct 300.000 300.000 3.000.010 3.000.000 DimCustomer 289.702 289.702 289.702 289.702 DimCurrencyRate 13.562 13.562 13.562 13.562 DimWaktu 1.124 1.124 1.124 1.124 FaktaPenjualan 996.187 996.187 996.187 996.187
• 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 Skenario ke-1 (record) Skenario ke-2 (record) Skenario ke-3 (record) Skenario ke-4 (record) DimSubCategory 300.000 5.051.100 300.000 5.051.100 DimProduct 300.000 300.000 5.040.000 5.040.000 DimCustomer 289.702 289.702 289.702 289.702 DimCurrencyRate 13.562 13.562 13.562 13.562 DimWaktu 1.124 1.124 1.124 1.124 FaktaPenjualan 3.000.000 3.000.000 3.000.000 3.000.000
• 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 Skenario ke-1 (record) Skenario ke-2 (record) Skenario ke-3 (record) Skenario ke-4 (record) DimSubCategory 5.051.100 15.152.736 5.051.100 15.152.736 DimProduct 5.040.000 5.040.000 13.621.376 15.040.000 DimCustomer 289.702 289.702 289.702 289.702 DimCurrencyRate 13.562 13.562 13.562 13.562 DimWaktu 1.124 1.124 1.124 1.124 FaktaPenjualan 9.282175 9.282.175 9.282175 9.282.175
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 Skenario ke-1 (record) Skenario ke-2 (record) Skenario ke-3 (record) Skenario ke-4 (record) ProductSubCategory 100.800 500.000 100.800 500.000 Product 100.799 100.799 500.000 500.000 Customer 200.000 200.000 200.000 200.000 CurrencyRate 13.562 13.562 13.562 13.562 Waktu 1.124 1.124 1.124 1.124 SalesOrderDetail 500.039 500.039 500.039 500.039
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 Skenario ke-1 (record) Skenario ke-2 (record) Skenario ke-3 (record) Skenario ke-4 (record) ProductSubCategory 300.000 3.030.600 300.000 3.000.000 Product 300.000 300.000 3.000.010 3.000.000 Customer 289.702 289.702 289.702 289.702 CurrencyRate 13.562 13.562 13.562 13.562 Waktu 1.124 1.124 1.124 1.124 SalesOrderDetail 996.187 996.187 996.187 996.187
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 Skenario ke-1 (record) Skenario ke-2 (record) Skenario ke-3 (record) Skenario ke-4 (record) ProductSubCategory 300.000 5.051.100 300.000 5.051.100 Product 300.000 300.000 5.040.000 5.040.000 Customer 289.702 289.702 289.702 289.702 CurrencyRate 13.562 13.562 13.562 13.562 Waktu 1.124 1.124 1.124 1.124 SalesOrderDetail 3.000.000 3.000.000 3.000.000 3.000.000
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 Skenario ke-1 (record) Skenario ke-2 (record) Skenario ke-3 (record) Skenario ke-4 (record) ProductSubCategory 5.051.100 15.152.736 5.051.100 15.152.736 Product 5.040.000 5.040.000 13.621.376 15.040.000 Customer 289.702 289.702 289.702 289.702 CurrencyRate 13.562 13.562 13.562 13.562 Waktu 1.124 1.124 1.124 1.124 SalesOrderDetail 9.282.175 9.282.175 9.282.175 9.282.175
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 4 CurrencyRateID Int 4 CurrencyRateDate Datetime 8 FromCurrencyCode Nchar 3 ToCurrencyCode Nchar 3 AverageRate Money 8
Kapasitas dari table DimCurrencyRate adalah 30 byte.
Tabel 3.10 Estimasi penggunaan disk space tabel dimcustomer
CustomerKey Int 4
CustomerID Int 4
CustomerType Nchar 1
SalesTerritoryName Nvarchar 50
Kapasitas dari table DimCustomer adalah 59 byte.
Tabel 3.11 Estimasi penggunaan disk space tabel dimproduct
ProductKey Int 4 ProductID Int 4 Name Nvarchar 50 MakeFlag Bit 1 FinishedGoodsFlag Bit 1 Size Nvarchar 5
Kapasitas dari table DimProduct adalah 65 byte.
Tabel 3.12 Estimasi penggunaan disk space tabel dimsubcategory
SubCategoryKey Int 4
ProductSubCategoryID Int 4
Name Nvarchar 50
CategoryName Nvarchar 50
Kapasitas dari table DimSubCategory adalah 108 byte.
Tabel 3.13 Estimasi penggunaan disk space tabel dimwaktu WaktuKey Int 4 Triwulan Int 4 Tahun Int 4 Bulan Int 4 Hari Int 4
Kapasitas dari table DimSubCategory adalah 20 byte.
Tabel 3.14 Estimasi penggunaan disk space tabel faktapPenjualan
WaktuKey Int 4 ProductKey Int 4 SubCategoryKey Int 4 CustomerKey Int 4 CurrencyRateKey Int 4 Jumlah_barang_dijual Money 8 Total_penjualan Int 4 CreditCardApprovalCode Varchar 15 SubTotal Money 8 TaxAmt Money 8 Freight Money 8 UnitPrice Money 8 UnitPriceDiscount Money 8 CarrierTrackingNumber Nvarchar 25
Kapasitas dari table DimSubCategory adalah 112 byte.
Tabel 3.15 Estimasi penggunaan disk space tabel filtertimestamp
Last_ETL_Process_Date Datetime 8
Table_Name Varchar 50
Kapasitas dari table DimSubCategory adalah 58 byte.
Tabel 3.16 Penggunaan total disk space model dimensi star schema skenario pertama dengan jumlah record tabel fakta ± 500.000 record
Nama table Space disk
untuk 1 baris
Jumlah data Total Penggunaan
DimCurrencyRate 30 byte 13562 406860 byte
DimCustomer 59 byte 200000 11800000 byte
DimProduct 65 byte 100799 6551935 byte
DimSubCategory 108 byte 100800 10886400 byte
DimWaktu 20 byte 1124 22480 byte
FaktaPenjualan 112 byte 500039 56004368 byte
FilterTimeStamp 58 byte 6 348 byte
Total 85672391 byte
83664.44 Kbyte
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 4 CurrencyRateID Int 4 CurrencyRateDate Datetime 8 FromCurrencyCode Nchar 3 ToCurrencyCode Nchar 3 AverageRate Money 8
Kapasitas dari table DimCurrencyRate adalah 30 byte.
Tabel 3.18 Estimasi penggunaan disk space tabel dimcustomer
CustomerKey Int 4
CustomerID Int 4
CustomerType Nchar 1
SalesTerritoryName Nvarchar 50
Kapasitas dari table DimCustomer adalah 59 byte.
Tabel 3.19 Estimasi penggunaan disk space tabel dimproduct
ProductKey Int 4 ProductID Int 4 SubCategoryKey Int 4 Name Nvarchar 50 MakeFlag Bit 1 FinishedGoodsFlag Bit 1 Size Nvarchar 5
Kapasitas dari table DimProduct adalah 69 byte.
Tabel 3.20 Estimasi penggunaan disk space tabel dimsubcategory
SubCategoryKey Int 4
ProductSubCategoryID Int 4
Name Nvarchar 50
CategoryName Nvarchar 50
Kapasitas dari table DimSubCategory adalah 108 byte.
Tabel 3.21 Estimasi penggunaan disk space tabel dimwaktu
WaktuKey Int 4
Triwulan Int 4
Tahun Int 4
Bulan Int 4
Hari Int 4
Tabel 3.22 Estimasi penggunaan disk space tabel faktapenjualan WaktuKey Int 4 ProductKey Int 4 CustomerKey Int 4 CurrencyRateKey Int 4 Jumlah_barang_dijual Money 8 Total_penjualan Int 4 CreditCardApprovalCode Varchar 15 SubTotal Money 8 TaxAmt Money 8 Freight Money 8 UnitPrice Money 8 UnitPriceDiscount Money 8 CarrierTrackingNumber Nvarchar 25
Kapasitas dari table DimSubCategory adalah 108 byte.
Tabel 3.23 Estimasi penggunaan disk space tabel filtertimestamp
Last_ETL_Process_Date Datetime 8
Table_Name Varchar 50
Kapasitas dari table DimSubCategory adalah 58 byte.
Tabel 3.24 Penggunaan total disk space model dimensi snowflake skenario pertama dimana tabel fakta berjumlah ± 500.000 record
Nama table Space disk
untuk 1 baris
Jumlah data Total Penggunaan
DimCurrencyRate 30 byte 13562 406860 byte
DimCustomer 59 byte 200000 11800000 byte
DimProduct 69 byte 100799 6955131 byte
DimSubCategory 108 byte 100800 10886400 byte
DimWaktu 20 byte 1124 22480 byte
FaktaPenjualan 108 byte 500039 54004212 byte
FilterTimeStamp 58 byte 6 348 byte
Total 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.
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 Skenario ke-1 (Detik) Skenario ke-2 (Detik) Skenario ke-3 (Detik) Skenario ke-4 (Detik) Subcategory 3,422 13,657 3,766 10,625 Product 2,828 2,781 11,578 10,375 Customer 3,719 4,312 3,094 5,422 CurrencyRate 344 1,484 1,437 1,205 Waktu 312 313 313 250 FaktaPenjualan 14,500 16,391 16,531 18,438 Total 25,125 38,938 36,719 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 Skenario ke-1 (Detik) Skenario ke-2 (Detik) Skenario ke-3 (Detik) Skenario ke-4 (Detik) Subcategory 5,812 93,125 8,750 84,031 Product 6,187 21,015 82,141 64,828 Customer 8,250 3,984 7,656 7,906 CurrencyRate 328 1,485 1,453 297 Waktu 297 328 297 344 FaktaPenjualan 29,953 32,250 98,422 33,453 Total 50,827 152,187 198,719 190,859
• 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 Skenario ke-1 (Detik) Skenario ke-2 (Detik) Skenario ke-3 (Detik) Skenario ke-4 (Detik) Subcategory 8,813 145,937 7,969 162,469 Product 7,844 4,687 148,468 119,156 Customer 4,172 3,406 3,750 3,485 CurrencyRate 1,532 1,437 328 1,422 Waktu 297 282 312 282 FaktaPenjualan 95,047 79,547 125,109 180,797 Total 117,705 235,296 285,936 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 Skenario ke-1 (Detik) Skenario ke-2 (Detik) Skenario ke-3 (Detik) Skenario ke-4 (Detik) Subcategory 169,656 310,735 117,782 345,453 Product 127,719 156,516 432,968 382,891 Customer 5,547 8,625 8,985 7,219 CurrencyRate 391 328 453 297 Waktu 297 786 297 1,688 FaktaPenjualan 693,875 1,013,391 1,189,125 1,078,844 Total 997,485 1.490,381 1.749,610 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.
• 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 Skenario ke-1 (Detik) Skenario ke-2 (Detik) Skenario ke-3 (Detik) Skenario ke-4 (Detik) 500.000 record 25.125 38.938 36.719 46.315 1.000.000 record 50.827 152.187 194.938 190.859 3.000.000 record 117.705 235.296 285.936 467.611 10.000.000 record 997.485 1490.381 1749.610 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 Skenario ke-1 (Detik) Skenario ke-2 (Detik) Skenario ke-3 (Detik) Skenario ke-4 (Detik) Subcategory 3,422 7,375 3,937 7,125 Product 1,422 2,344 10,016 9,282 Customer 2,891 6,469 5,015 4,922 CurrencyRate 1,672 0,313 1,594 1,672 Waktu 0,218 0,219 0,297 0,250 FaktaPenjualan 9,640 11,516 10,937 13,953 Total 19,265 28,236 31,796 37,204
• Skenario dimana tabel fakta ± 1.000.000 record
Tabel 3.31 Detail waktu ETL dimana tabel fakta ± 1.000.000 record
Nama tabel Skenario ke -1 (Detik) Skenario ke -2 (Detik) Skenario ke -3 (Detik) Skenario ke -4 (Detik) Subcategory 3,641 62,375 7,484 75,953 Product 6,391 31,047 94,265 91,547 Customer 8,391 7,453 8,406 5,610 CurrencyRate 0,297 0,313 0,297 0,375 Waktu 0,234 0,250 0,219 0,250 FaktaPenjualan 21,594 24,344 21,984 24,281 Total 40,548 125,782 132,655 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 Skenario ke -1 (Detik) Skenario ke -2 (Detik) Skenario ke -3 (Detik) Skenario ke -4 (Detik) Subcategory 8,234 114,844 9,203 85,938 Product 5,016 17,922 150,625 147,782 Customer 4,391 7,015 4,485 8,328 CurrencyRate 0,187 1,719 0,422 0,360 Waktu 0,219 0,282 0,266 0,328 FaktaPenjualan 62,797 92,187 94,406 106,188 Total 80,844 233,969 259,407 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 Skenario ke-1 (Detik) Skenario ke-2 (Detik) Skenario ke-3 (Detik) Skenario ke-4 (Detik) Subcategory 153,219 324,593 103,109 339,219 Product 136,672 162,522 519,765 567,829 Customer 7,969 8,094 7,750 7,625 CurrencyRate 0,359 0,344 0,313 0,391 Waktu 0,296 0,281 0,282 0,297 FaktaPenjualan 463,125 384,469 336,094 342,719 Total 761,640 880,303 967,313 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.
• 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 berbeda-beda 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 Skenario ke-1 (Detik) Skenario ke-2 (Detik) Skenario ke-3 (Detik) Skenario ke-4 (Detik) 500000 record 19.265 28.236 31.796 37.204 1000000 record 40.548 125.782 128.921 198.016 3000000 record 80.844 233.969 259.407 348.924 10000000 record 761.64 880.303 967.313 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).
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 Skenario ke-1 Skenario ke-2 Skenario ke-3 Skenario ke-4 500.000 record 00:00:19 00:00:27 00:00:26 00:00:33 1.000.000 record 00:00:31 00:02:17 00:04:28 00:04:32 3.000.000 record 00:00:52 00:03:41 00:06:07 00:15:21 10.000.000 record 00:17:17 00:25:27 01:30:11 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 melakukan pengelompokkan data pada tabel product berdasarkan subcategory.
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 Skenario ke -1 Skenario ke -2 Skenario ke -3 Skenario ke -4 500.000 record 00:00:15 00:00:25 00:00:26 00:00:39 1.000.000 record 00:00:35 00:03:44 00:04:45 00:07:08 3.000.000 record 00:00:57 00:05:54 00:08:50 00:18:21 10.000.000 record 00:18:38 00:32:38 01:52:22 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 berbeda-beda sesuai dengan banyaknya record dan model dimensi yang digunakan. Berikut ini adalah jumlah size yang di peroleh berdasarkan jumlah record dan skenario yang dibuat :
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 Skenario ke-1 Skenario ke-2 Skenario ke-3 Skenario ke-4 5000.00 record 90.4 MB 165 MB 184 MB 259 MB 1.000.000 record 199 MB 896 MB 848 MB 1.33 GB 3.000.000 record 248 MB 1.16 GB 1.38 GB 2.28 GB 10.000.000 record 2.37 GB 3.95 GB 4.42 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.
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 Skenario ke-1 Skenario ke-2 Skenario ke-3 Skenario ke-4 500.000 record 93.4 MB 172 MB 196 MB 276 MB 1.000.000 record 213 MB 976 MB 921 MB 1.45 GB 3.000.000 record 291 MB 1.24 GB 1.5 GB 2.48 GB 1.0000.000 record 2.57 GB 4.33 GB 4.86 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.
