bab 3 3 analisis dan uji coba - thesis.binus.ac.idthesis.binus.ac.id/doc/bab3/2010-1-00258-if bab...

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.

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

SalesOrderDetail (SalSalesO rderID

SalesO rderDetailID

C arrierTrackingNumber

O rderQ ty

ProductID

UnitPrice

UnitPriceDiscount

LineTotal

row guid

ModifiedDate

Address (Person)A ddressID

A ddressLine1

A ddressLine2

C ity

StateProv inceID

PostalC ode

row guid

ModifiedDate

Contact (Person)C ontactID

NameSty le

Title

F irstName

MiddleName

LastName

Suffix

EmailA ddress

EmailPromotion

Phone

Passw ordHash

Passw ordSalt

A dditi lC t

CreditCard (Sales)C reditC ardID

C ardTy pe

C ardNumber

ExpMonth

ExpYear

ModifiedDate

CurrencyRate (SaC urrency RateID

C urrency RateDate

F romC urrency C ode

ToC urrency C ode

A v erageRate

EndO fDay Rate

ModifiedDate

Customer (Sales)C ustomerID

Territory ID

A ccountNumber

C ustomerTy pe

row guid

ModifiedDate

SalesPerson (SaleSalesPersonID

Territory ID

SalesQ uota

Bonus

C ommissionPct

SalesYTD

SalesLastYear

row guid

ModifiedDate

ShipMethod (PurchShipMethodID

Name

ShipBase

ShipRate

row guid

ModifiedDate

SalesTerritory (Sales)Territory ID

Name

C ountry RegionC ode

[Group]

SalesYTD

SalesLastYear

C ostYTD

C ostLastYear

row guid

ModifiedDate

SalesOrderHeaderSalesO rderID

SalesReasonID

ModifiedDate

SalesOrderHeader (Sales)SalesO rderID

Rev isionNumber

O rderDate

DueDate

ShipDate

Status

O nlineO rderF lag

SalesO rderNumber

PurchaseO rderNumber

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

S izeUnitMeasureC ode

WeightUnitMeasureC ode

Weight

Day sToManufacture

ProductLine

C lass

Sty le

ProductSubcategory ID

ProductModelID

SellStartDate

SellEndDate

DiscontinuedDate

row guid

ModifiedDate

ProductSubcategory (PProductSubcategory ID

ProductC ategory ID

Name

row guid

ModifiedDate

ProductModel (Production)ProductModelID

Name

C atalogDescription

Instructions

row guid

ModifiedDate

UnitMeasure (Production)UnitMeasureC ode

Name

ModifiedDate

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.

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.

DimCurrencyRateCurrencyRateKey

CurrencyRateID

CurrencyRateDate

FromCurrencyCode

ToCurrencyCode

AverageRate

DimCustomerCustomerKey

CustomerID

CustomerType

SalesTerritoryName

DimProductProductKey

ProductID

Name

MakeFlag

FinishedGoodsFlag

Size

DimSubCategorySubCategoryKey

ProductSubCategoryID

Name

CategoryName

DimWaktuWaktuKey

Triwulan

Tahun

Bulan

Hari

FaktaPenjualanWaktuKey

ProductKey

SubCategoryKey

CustomerKey

CurrencyRateKey

Jumlah_barang_dijual

Total_penjualan

CreditCardApprovalCode

SubTotal

TaxAmt

Freight

UnitPrice

UnitPriceDiscount

CarrierTrackingNumber

Gambar 3.2 Star schema diagram

34

DimCurrencyRateCurrencyRateKey

CurrencyRateID

CurrencyRateDate

FromCurrencyCode

ToCurrencyCode

AverageRate

DimCustomerCustomerKey

CustomerID

CustomerType

SalesTerritoryName

DimProductProductKey

ProductID

SubCategoryKey

Name

MakeFlag

FinishedGoodsFlag

Size

DimSubCategorySubCategoryKey

ProductSubCategoryID

Name

CategoryName

DimWaktuWaktuKey

Triwulan

Tahun

Bulan

Hari

FaktaPenjualanWaktuKey

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

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 Skenario ke-1

(record) Skenario ke-2



(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

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.000.000 record sedangkan tabel lainnya tetap.


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 .


menjadi ± 3.000.000 record.

Tabel 3.2 Jumlah data pada tabel berdasarkan skenario di atas Nama tabel Skenario ke-1




(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

37


Data pada adventureworks ditambahkan sehingga menghasilkan jumlah fakta ±

3.000.000 record. Dari skenario ini dibuat 4 skenario baru, yakni :





Kemudian jumlah record pada tabel subcategory diperbesar menjadi ±

5.000.000 record.



record.








(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

38


Data pada adventureworks ditambahkan sehingga menghasilkan jumlah tabel

fakta ± 10.000.00 record. Dari skenario ini dibuat 4 skenario baru, yakni :





Kemudian jumlah record pada table subcategory diperbesar menjadi ±

15.000.000 record.



record.







(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

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 Skenario ke-1




(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

40

2. Jumlah record pada tabel salesorderdetail ditambahkan sebanyak ± 1.000.000

record

a. Skenario pertama



sebanyak ± 1.000.000 record sedangkan tabel lainnya tetap.

b. Skenario kedua


kemudian record pada tabel productsubcategory diperbesar menjadi ±

3.000.000 record.

c. Skenario ketiga


kemudian record pada tabel product diperbesar menjadi ± 3.000.000 record.

d. Skenario keempat








(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

41


record

a. Skenario pertama


Adventureworks. Kemudian jumlah record pada salesorderdetail diperbesar


b. Skenario kedua


kemudian record pada tabel productsubcategory diperbesar menjadi ±

5.000.000 record.

c. Skenario ketiga


kemudian record pada tabel product diperbesar menjadi ± 5.000.000 record.

d. Skenario keempat








(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

42


record

a. Skenario pertama




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








(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

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 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.

44

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 byteDimCustomer 59 byte 200000 11800000 byteDimProduct 65 byte 100799 6551935 byteDimSubCategory 108 byte 100800 10886400 byteDimWaktu 20 byte 1124 22480 byteFaktaPenjualan 112 byte 500039 56004368 byteFilterTimeStamp 58 byte 6 348 byteTotal 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 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 Kapasitas dari table DimSubCategory adalah 20 byte.

46

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 byteDimCustomer 59 byte 200000 11800000 byteDimProduct 69 byte 100799 6955131 byteDimSubCategory 108 byte 100800 10886400 byteDimWaktu 20 byte 1124 22480 byteFaktaPenjualan 108 byte 500039 54004212 byteFilterTimeStamp 58 byte 6 348 byteTotal 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 Skenario ke-1

(Detik) Skenario ke-2



(Detik) Subcategory 3,422 13,657 3,766 10,625Product 2,828 2,781 11,578 10,375Customer 3,719 4,312 3,094 5,422CurrencyRate 344 1,484 1,437 1,205Waktu 312 313 313 250FaktaPenjualan 14,500 16,391 16,531 18,438Total 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) Subcategory 5,812 93,125 8,750 84,031Product 6,187 21,015 82,141 64,828Customer 8,250 3,984 7,656 7,906CurrencyRate 328 1,485 1,453 297Waktu 297 328 297 344FaktaPenjualan 29,953 32,250 98,422 33,453Total 50,827 152,187 198,719 190,859

48






(Detik) Subcategory 8,813 145,937 7,969 162,469Product 7,844 4,687 148,468 119,156Customer 4,172 3,406 3,750 3,485CurrencyRate 1,532 1,437 328 1,422Waktu 297 282 312 282FaktaPenjualan 95,047 79,547 125,109 180,797Total 117,705 235,296 285,936 467,611






(Detik) Subcategory 169,656 310,735 117,782 345,453Product 127,719 156,516 432,968 382,891Customer 5,547 8,625 8,985 7,219CurrencyRate 391 328 453 297Waktu 297 786 297 1,688FaktaPenjualan 693,875 1,013,391 1,189,125 1,078,844Total 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.

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


• 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)




500.000 record 25.125 38.938 36.719 46.3151.000.000 record 50.827 152.187 194.938 190.8593.000.000 record 117.705 235.296 285.936 467.61110.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) Subcategory 3,422 7,375 3,937 7,125Product 1,422 2,344 10,016 9,282Customer 2,891 6,469 5,015 4,922CurrencyRate 1,672 0,313 1,594 1,672Waktu 0,218 0,219 0,297 0,250FaktaPenjualan 9,640 11,516 10,937 13,953Total 19,265 28,236 31,796 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 Skenario ke -1

(Detik) Skenario ke -2





Tabel 3.32 Detail waktu ETL dimana tabel fakta ± 3.000.000 record Nama tabel Skenario ke -1






Tabel 3.33 Detail waktu ETL dimana tabel fakta ± 10.000.000 record Nama tabel Skenario ke-1




(Detik) Subcategory 153,219 324,593 103,109 339,219Product 136,672 162,522 519,765 567,829Customer 7,969 8,094 7,750 7,625CurrencyRate 0,359 0,344 0,313 0,391Waktu 0,296 0,281 0,282 0,297FaktaPenjualan 463,125 384,469 336,094 342,719Total 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.

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


• Jumlah record pada tabel dimensi waktu sama tetapi menghasilkan waktu yang


• 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





500000 record 19.265 28.236 31.796 37.2041000000 record 40.548 125.782 128.921 198.0163000000 record 80.844 233.969 259.407 348.92410000000 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).

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 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:331.000.000 record 00:00:31 00:02:17 00:04:28 00:04:323.000.000 record 00:00:52 00:03:41 00:06:07 00:15:2110.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.

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 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:391.000.000 record 00:00:35 00:03:44 00:04:45 00:07:083.000.000 record 00:00:57 00:05:54 00:08:50 00:18:2110.000.000 record 00:18:38 00:32:38 01:52:22 09:07:48


• 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

:

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 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


• 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 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


• 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.

bab 3 3 analisis dan uji coba - thesis.binus.ac.idthesis.binus.ac.id/doc/bab3/2010-1-00258-if bab...

Documents