BAB 3 3 ANALISIS DAN UJI COBA. dimensi star schema dan dimensi snowflake, mempersiapkan data yang digunakan pada
|
|
|
- Suharto Oesman
- 6 tahun lalu
- Tontonan:
Transkripsi
1 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 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
2 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 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.
3 31 Setelah mengetahui keuntungan dan kerugian dari dimensi star schema dan dimensi snowflake, akan dilakukan penelitian untuk mengetahui kebenaran dari teori diatas 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 Database adventureworks ini dapat diperoleh dengan cara melakukan instalasi tambahan pada Microsoft SqlServer 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 :
4 32 ProductCategory (Production) Customer (Sales) ProductC ategory ID CustomerID Name TerritoryID row guid A ccountnumber CustomerType row guid Product (Production) ProductID ProductSubcategory (P Name ProductSubcategory ID ProductNumber ProductC ategory ID MakeFlag Name F inishedgoodsf lag row guid Color SafetyStockLevel ReorderPoint StandardCost SalesOrderDetail (Sal ListP rice SalesOrderID Size SalesOrderDetailID SizeUnitMeasureCode C arriertrackingn umber WeightUnitMeasureC ode OrderQty Weight ProductID Day stomanufacture UnitPrice ProductLine U nitpricediscount Class LineTotal Style row guid ProductSubcategory ID ProductModelID SellStartDate CreditCard (Sales) SellEndDate CreditCardID DiscontinuedDate CardType Contact (Person) row guid CardNumber C ontactid ExpMonth NameStyle ExpYear Title FirstName MiddleName ProductModel (Production) LastN ame ProductModelID Suffix Name A ddress C atalogdescription Promotion Instructions Phone row guid Passw ordhash Passw ordsalt Additi lc t UnitMeasure (Production) U nitm easurec ode Name SalesTerritory (Sales) Territory ID Name C ountry RegionC ode [Group] SalesYTD SalesLastYear CostYTD CostLastYear row guid SalesOrderHeader (Sales) SalesOrderID RevisionNumber OrderDate DueDate ShipDate Status OnlineOrderFlag SalesO rdernumber PurchaseO rdernumber A ccountnumber CustomerID C ontactid SalesPersonID TerritoryID BillToA ddressid ShipToA ddressid ShipMethodID CreditCardID CreditCardApprovalCode CurrencyRateID SubTotal TaxAmt Freight TotalDue Comment row guid SalesPerson (Sale S alespersonid TerritoryID SalesQuota Bonus C ommissionpct SalesYTD SalesLastYear row guid CurrencyRate (Sa CurrencyRateID CurrencyRateDate FromCurrencyCode ToCurrencyCode AverageRate EndOfDayRate Address (Person) AddressID A ddressline1 A ddressline2 City StateProv inceid PostalCode row guid ShipMethod (Purch ShipMethodID Name ShipBase ShipRate row guid SalesOrderHeader SalesOrderID SalesReasonID 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.
5 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 FaktaPenjualan WaktuKey ProductKey SubCategoryKey CustomerKey CurrencyRateKey Jumlah_barang_dijual Total_penjualan CreditCardApprovalCode SubTotal TaxAmt Freight UnitPrice UnitPriceDiscount CarrierTrackingNumber DimSubCategory SubCategoryKey ProductSubCategoryID Name CategoryName DimWaktu WaktuKey Triwulan Tahun Bulan Hari Gambar 3.2 Star schema diagram
6 34 DimCurrencyRate CurrencyRateKey CurrencyRateID CurrencyRateDate FromCurrencyCode ToCurrencyCode AverageRate DimProduct ProductKey ProductID SubCategoryKey Name MakeFlag FinishedGoodsFlag Size DimSubCategory SubCategoryKey ProductSubCategoryID Name CategoryName FaktaPenjualan WaktuKey ProductKey CustomerKey CurrencyRateKey Jumlah_barang_dijual Total_penjualan CreditCardApprovalCode SubTotal TaxAmt Freight UnitPrice UnitPriceDiscount CarrierTrackingNumber DimWaktu WaktuKey Triwulan Tahun Bulan Hari 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
7 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 ± record Record pada adventureworks ditambahkan sehingga menghasilkan jumlah fakta ± record. Dari skenario ini dibuat 4 skenario baru yakni : 1. pertama dibuat dengan menggunakan data dari database adventureworks. Kemudian jumlah record pada tabel fakta diperbesar menjadi ± record sedangkan jumlah tabel lainnya tetap. 2. kedua dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel subcategory diperbesar menjadi ± record. 3. ketiga dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel product diperbesar menjadi ± record. 4. keempat dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel subcategory dan product diperbesar menjadi ± record. Tabel 3.1 Jumlah data pada setiap tabel berdasarkan skenario di atas Nama tabel ke-1 ke-4 DimSubCategory DimProduct DimCustomer DimCurrencyRate DimWaktu FaktaPenjualan
8 36 Tabel fakta dengan jumlah data ± record Data pada adventureworks ditambahkan sehingga menghasilkan jumlah fakta ± record. Dari skenario ini dibuat 4 skenario baru, yakni : 1. pertama dibuat dengan menggunakan data dari database adventureworks. Kemudian jumlah record pada tabel fakta diperbesar menjadi ± record sedangkan tabel lainnya tetap. 2. kedua dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada table subcategory diperbesar menjadi ± record. 3. ketiga dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel product diperbesar menjadi ± record. 4. keempat dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel subcategory dan product diperbesar menjadi ± record. Tabel 3.2 Jumlah data pada tabel berdasarkan skenario di atas Nama tabel ke-1 ke-4 DimSubCategory DimProduct DimCustomer DimCurrencyRate DimWaktu FaktaPenjualan
9 37 Tabel fakta dengan jumlah data ± record Data pada adventureworks ditambahkan sehingga menghasilkan jumlah fakta ± record. Dari skenario ini dibuat 4 skenario baru, yakni : 1. pertama dibuat dengan menggunakan data dari database adventureworks. Kemudian jumlah record pada tabel fakta diperbesar menjadi ± record sedangkan tabel lainnya tetap. 2. kedua dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel subcategory diperbesar menjadi ± record. 3. ketiga dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel product diperbesar menjadi ± record. 4. keempat dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel subcategory dan product diperbesar menjadi ± record. Tabel 3.3 Jumlah data pada tabel berdasarkan skenario di atas Nama tabel ke-1 ke-4 DimSubCategory DimProduct DimCustomer DimCurrencyRate DimWaktu FaktaPenjualan
10 38 Tabel fakta dengan jumlah data ± record Data pada adventureworks ditambahkan sehingga menghasilkan jumlah tabel fakta ± record. Dari skenario ini dibuat 4 skenario baru, yakni : 1. pertama dibuat dengan menggunakan data dari database adventureworks. Kemudian jumlah record pada tabel fakta diperbesar menjadi ± record sedangkan tabel lainnya tetap. 2. kedua dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada table subcategory diperbesar menjadi ± record. 3. ketiga dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel product diperbesar menjadi ± record. 4. keempat dibuat dengan menggunakan data dari skenario pertama. Kemudian jumlah record pada tabel subcategory dan product diperbesar menjadi ± record. Tabel 3.4 Jumlah data pada tabel berdasarkan skenario di atas Nama tabel ke-1 ke- 4 DimSubCategory DimProduct DimCustomer DimCurrencyRate DimWaktu FaktaPenjualan
11 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 ± record a. pertama pertama adalah dengan menggunakan data dari database adventureworks. Kemudian jumlah record pada salesorderdetail diperbesar sebanyak ± record sedangkan tabel lainnya tetap. b. kedua kedua dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel productsubcategory diperbesar menjadi ± record. c. ketiga ketiga dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel product diperbesar menjadi ± record. d. keempat keempat dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel productsubcategory dan product diperbesar menjadi ± record. Tabel 3.5 Jumlah data tabel berdasarkan skenario di atas Nama tabel ke-1 ke-4 ProductSubCategory Product Customer CurrencyRate Waktu SalesOrderDetail
12 40 2. Jumlah record pada tabel salesorderdetail ditambahkan sebanyak ± record a. pertama pertama adalah dengan menggunakan data dari database adventureworks. Kemudian jumlah record pada salesorderdetail diperbesar sebanyak ± record sedangkan tabel lainnya tetap. b. kedua kedua dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel productsubcategory diperbesar menjadi ± record. c. ketiga ketiga dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel product diperbesar menjadi ± record. d. keempat keempat dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel productsubcategory dan product diperbesar menjadi ± record. Tabel 3.6 Jumlah data tabel berdasarkan skenario di atas Nama tabel ke-1 ke-4 ProductSubCategory Product Customer CurrencyRate Waktu SalesOrderDetail
13 41 3. Jumlah record pada tabel salesorderdetail ditambahkan sebanyak ± record a. pertama pertama adalah dengan menggunakan data dari database Adventureworks. Kemudian jumlah record pada salesorderdetail diperbesar sebanyak ± record sedangkan tabel lainnya tetap. b. kedua kedua dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel productsubcategory diperbesar menjadi ± record. c. ketiga ketiga dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel product diperbesar menjadi ± record. d. keempat keempat dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel productsubcategory dan product diperbesar menjadi ± record. Tabel 3.7 Jumlah data tabel berdasarkan skenario di atas Nama tabel ke-1 ke-4 ProductSubCategory Product Customer CurrencyRate Waktu SalesOrderDetail
14 42 4. Jumlah record pada tabel salesorderdetail ditambahkan sebanyak ± record a. pertama pertama adalah dengan menggunakan data dari database adventureworks. Kemudian jumlah record pada salesorderdetail diperbesar sebanyak ± record sedangkan tabel lainnya tetap. b. kedua kedua dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel productsubcategory diperbesar menjadi ± record. c. ketiga ketiga dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel product diperbesar menjadi ± record. d. keempat keempat dibuat dengan menggunakan data dari skenario pertama yang kemudian record pada tabel productsubcategory dan product diperbesar menjadi ± record. Tabel 3.8 Jumlah data tabel berdasarkan skenario di atas Nama tabel ke-1 ke-4 ProductSubCategory Product Customer CurrencyRate Waktu SalesOrderDetail
15 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 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.
16 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 ± record Nama table Space disk Jumlah data Total Penggunaan untuk 1 baris DimCurrencyRate 30 byte byte DimCustomer 59 byte byte DimProduct 65 byte byte DimSubCategory 108 byte byte DimWaktu 20 byte byte FaktaPenjualan 112 byte byte FilterTimeStamp 58 byte byte Total byte Kbyte 81.7 MByte
17 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.
18 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 ± record Nama table Space disk Jumlah data Total Penggunaan untuk 1 baris DimCurrencyRate 30 byte byte DimCustomer 59 byte byte DimProduct 69 byte byte DimSubCategory 108 byte byte DimWaktu 20 byte byte FaktaPenjualan 108 byte byte FilterTimeStamp 58 byte byte Total byte Kbyte 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.
19 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 Uji coba pada model dimensi Star schema Hasil dari uji coba ETL pada model dimensi Star schema dari semua skenario sebagai berikut : dimana tabel fakta berjumlah ± record Tabel 3.25 Detail waktu ETL dimana fakta berjumlah ± record Nama tabel ke-1 ke-4 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 FaktaPenjualan 14,500 16,391 16,531 18,438 Total 25,125 38,938 36,719 46,315 dimana tabel fakta berjumlah ± record Tabel 3.26 Detail waktu ETL dimana tabel fakta berjumlah ± record Nama tabel ke-1 ke-4 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, Waktu FaktaPenjualan 29,953 32,250 98,422 33,453 Total 50, , , ,859
20 48 dimana tabel fakta berjumlah ± record Tabel 3.27 Detail waktu ETL dimana tabel fakta berjumlah ± record Nama tabel ke-1 ke-4 Subcategory 8, ,937 7, ,469 Product 7,844 4, , ,156 Customer 4,172 3,406 3,750 3,485 CurrencyRate 1,532 1, ,422 Waktu FaktaPenjualan 95,047 79, , ,797 Total 117, , , ,611 dimana tabel fakta berjumlah ± record Tabel 3.28 Detail waktu ETL dimana tabel fakta berjumlah ± record Nama tabel ke-1 ke-4 Subcategory 169, , , ,453 Product 127, , , ,891 Customer 5,547 8,625 8,985 7,219 CurrencyRate Waktu ,688 FaktaPenjualan 693,875 1,013,391 1,189,125 1,078,844 Total 997, , , ,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.
21 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 ke-1 ke record record record record Uji coba pada model dimensi Snowflake Hasil dari uji coba ETL pada model dimensi snowflake dari semua skenario sebagai berikut : dimana tabel fakta ± record Tabel 3.30 Detail waktu ETL dimana tabel fakta ± record Nama tabel ke-1 ke-4 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
22 50 dimana tabel fakta ± record Tabel 3.31 Detail waktu ETL dimana tabel fakta ± record Nama tabel ke -1 ke -2 ke -3 ke -4 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, , , ,016 dimana tabel fakta ± record Tabel 3.32 Detail waktu ETL dimana tabel fakta ± record Nama tabel ke -1 ke -2 ke -3 ke -4 Subcategory 8, ,844 9,203 85,938 Product 5,016 17, , ,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, ,188 Total 80, , , ,924 dimana tabel fakta ± record Tabel 3.33 Detail waktu ETL dimana tabel fakta ± record Nama tabel ke-1 ke-4 Subcategory 153, , , ,219 Product 136, , , ,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, , , ,719 Total 761, , , ,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.
23 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 ke-1 ke record record record record 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.
24 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) Waktu proses OLAP dengan model dimensi star schema berikut : Pencatatan waktu dari proses OLAP dengan model dimensi star schema sebagai Tabel 3.35 Waktu proses OLAP pada star schema Jumlah record tabel fakta ke-1 ke-2 ke-3 ke record 00:00:19 00:00:27 00:00:26 00:00: record 00:00:31 00:02:17 00:04:28 00:04: record 00:00:52 00:03:41 00:06:07 00:15: 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.
25 Waktu proses OLAP dengan model dimensi snowflake berikut. Pencatatan waktu dari proses OLAP dengan model dimensi snowflake sebagai Tabel 3.36 Waktu proses OLAP pada snowflake Jumlah record tabel fakta ke -1 ke -2 ke -3 ke record 00:00:15 00:00:25 00:00:26 00:00: record 00:00:35 00:03:44 00:04:45 00:07: record 00:00:57 00:05:54 00:08:50 00:18: 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) 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 :
26 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 ke-1 ke-2 ke-3 ke record 90.4 MB 165 MB 184 MB 259 MB record 199 MB 896 MB 848 MB 1.33 GB record 248 MB 1.16 GB 1.38 GB 2.28 GB 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.
27 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 ke-1 ke-2 ke-3 ke record 93.4 MB 172 MB 196 MB 276 MB record 213 MB 976 MB 921 MB 1.45 GB record 291 MB 1.24 GB 1.5 GB 2.48 GB 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.
BAB 4 4 PEMBAHASAN. implementasi program, dan evaluasi. Analisis lanjutan berisi analisis dari waktu ETL,
BAB 4 4 PEMBAHASAN Pada bab ini dibahas analisis lanjutan berdasarkan hasil uji coba pada bab 3, implementasi program, dan evaluasi. Analisis lanjutan berisi analisis dari waktu ETL, besar penggunaan disk
LAMPIRAN. 2) Membuat tabel-tabel dimensi dan fakta yang sesuai dengan skema bintang yang. if exists (select * from dbo.sysobjects where id = object_id
LAMPIRAN Langkah-langkah pembuatan data warehouse : 1) Membuat database baru untuk menampung data warehouse, yang bernama OLAP_mobs. 2) Membuat tabel-tabel dimensi dan fakta yang sesuai dengan skema bintang
LAMPIRAN. 1) Membuat database baru untuk menampung data warehouse, yang bernama
LAMPIRAN Langkah-langkah pembuatan data warehouse : 1 Membuat database baru untuk menampung data warehouse, yang bernama OtoBITzOLAP. 2 Membuat tabel-tabel dimensi dan fakta yang sesuai dengan skema bintang
[Data Warehouse] [6/C2 & 6/D2]
![[Data Warehouse] [6/C2 & 6/D2]](/thumbs/63/50394662.jpg "[Data Warehouse] [6/C2 & 6/D2]")
[Data Warehouse] [6/C2 & 6/D2] [ Chapter 6] Pemodelan Data Warehouse Dedy Alamsyah, S.Kom, M.Kom [NIDN : 0410047807] Pemodelan Data Ada dua pendekatan yang diterima sebagai best practice untuk memodelkan
Gambar 4.57 Rancangan Pivot Tabel Total Purchase Return Dalam Quantity
123 Gambar 4.57 Rancangan Pivot Tabel Total Purchase Return Dalam Quantity Gambar 4.58 Rancangan Pivot Tabel Total Purchase Return Berdasarkan Vendor Area Dalam Rupiah 124 Gambar 4.59 Rancangan Pivot Tabel
Implementasi migrasi database didasarkan pada kebutuhan untuk memindahkan
BAB 4 IMPLEMENTASI DAN EVALUASI MIGRASI DATABASE 4.1. Implementasi Implementasi migrasi database didasarkan pada kebutuhan untuk memindahkan objek-objek database dari satu DBMS ke DBMS lainnya. Implementasi
Data Warehouse dan Decision Support System. Arif Basofi
Data Warehouse dan Decision Support System Arif Basofi Referensi Data Warehouse, STMIK Global Informatika MDP. M. Syukri Mustafa,S.Si., MMSI, Sistem Basis Data II (Data Warehouse), 2008. Hanim MA, Data
IMPLEMENTASI DAN EVALUASI. tugas-tugas yang akan dilakukan dalam tahap implementasi. Berikut penjadwalan. Gambar 4.1 Gambar Jadwal Implementasi
88 BAB 4 IMPLEMENTASI DAN EVALUASI 4.1 Implementasi 4.1.1 Jadwal Implementasi Untuk menghasilkan implementasi yang baik dibutuhkan penjadwalan tugas-tugas yang akan dilakukan dalam tahap implementasi.
BAB 4 RANCANGAN DATA WAREHOUSE YANG DIUSULKAN. Pada perancangan Data Warehouse Kementerian Dalam Negeri Bagian
180 BAB 4 RANCANGAN DATA WAREHOUSE YANG DIUSULKAN 4.1 Arsitektur Data Warehouse Pada perancangan Data Warehouse Kementerian Dalam Negeri Bagian Kependudukan, kami mengusulkan sebuah Data Warehouse terpusat
yang ingin ditampilkan.
130 Gambar 4.38 Tampilan Grafik Batang Laporan Penjualan Dalam halaman grafik ini terdapat drop down menu untuk melihat jenis laporan penjualan. Jenis laporan penjualan dibagi menjadi empat, yaitu total
BAB II LANDASAN TEORI
BAB II LANDASAN TEORI 2.1. Data Data adalah sebuah rekaman dari fakta-fakta, konsep-konsep, atau instruksiinstruksi pada media penyimpanan untuk komunikasi perolehan, dan pemrosesan dengan cara otomatis
BAB III ANALISIS DAN PERANCANGAN SISTEM
BAB III ANALISIS DAN PERANCANGAN SISTEM Proses analisis dan perancangan sistem merupakan suatu prosedur yang dilakukan untuk pemeriksaan masalah dan penyusunan alternatif pemecahan masalah yang timbul
Computer Science, University of Brawijaya. Putra Pandu Adikara, S.Kom VIEW & TABLE. Basis Data 2
Computer Science, University of Brawijaya Putra Pandu Adikara, S.Kom VIEW & TABLE Basis Data 2 View View View merupakan virtual table di mana isinya (kolom dan baris) didefinisikan dari suatu query (yang
DATAMULTIDIMENSI. DATAWAREHOUSE vs DATAMART FIRDAUS SOLIHIN UNIVERSITAS TRUNOJOYO
DATAMULTIDIMENSI FIRDAUS SOLIHIN UNIVERSITAS TRUNOJOYO DATAWAREHOUSE vs DATAMART DATAWAREHOUSE Perusahaan, melingkupi semua proses Gabungan datamart Data didapat dari proses Staging Merepresentasikan data
BAB 4 PERANCANGAN DAN IMPLEMENTASI
BAB 4 PERANCANGAN DAN IMPLEMENTASI 4.1 Arsitektur Data Warehouse Pelaksanaan perancangan data warehouse dimulai dari perumusan permasalahan yang dihadapi oleh perusahaan kemudian dilanjutkan dengan pencarian
BAB 4 PERANCANGAN DAN IMPLEMENTASI DATA WAREHOUSE
84 BAB 4 PERANCANGAN DAN IMPLEMENTASI DATA WAREHOUSE 4.1 Perancangan Data warehouse 4.1.1 Arsitektur Data warehouse Berdasarkan hasil dari penelitian yang dilakukan pada PT. Mega Solusi Teknologi, maka
BAB 4 PERANCANGAN DATA WAREHOUSE YANG DIUSULKAN. data warehouse terpusat (centralized data warehouse). Arsitektur ini merupakan bentuk
BAB 4 PERANCANGAN DATA WAREHOUSE YANG DIUSULKAN 4.1. Arsitektur Data Warehouse Dalam perancangan data warehouse pada Rumah Sakit Husada menggunakan data warehouse terpusat (centralized data warehouse).
BAB 4 DATA WAREHOUSE YANG DIUSULKAN. KTL adalah menggunakan anatomi data warehouse terpusat (centralized data
BAB 4 DATA WAREHOUSE YANG DIUSULKAN 4.1 Arsitektur Data Warehouse Jenis perancangan arsitektur data warehouse yang akan dibangun untuk PT KTL adalah menggunakan anatomi data warehouse terpusat (centralized
Rangga Praduwiratna
Mengenal Datatypes SQL Server 2005 Rangga Praduwiratna ziglaret@yahoo.co.nz http://geeks.netindonesia.net/blogs/ziglaret Lisensi Dokumen: Seluruh dokumen di IlmuKomputer.Com dapat digunakan, dimodifikasi
LAMPIRAN. create proc varchar(40))as. update filtertimestamp set last_etl=getdate()
L1 LAMPIRAN S tored Procedure pada database OLAP 1. Stored Procedure proc filtertimehistory create proc filtertimehistory(@tabel varchar(40as if exists ( select * from filtertimestamp where namatable=@tabel
BAB III METODE PENELITIAN
15 BAB III METODE PENELITIAN Sistem informasi geografis persebaran hotspot di Indonesia merupakan suatu sistem yang bertujuan untuk memantau dan memberikan informasi mengenai persebaran hotspot yang ada
UNIVERSITAS BINA NUSANTARA. Jurusan Teknik Informatika. Skripsi School of Computer Science. Semester Ganjil Tahun 2011/2012. Ike Nadiavari
UNIVERSITAS BINA NUSANTARA Jurusan Teknik Informatika Skripsi School of Computer Science Semester Ganjil Tahun 2011/2012 Data Warehouse untuk Sales dan Inventory pada DKSH Indonesia Ike Nadiavari 1200955726
BAB 4 PERANCANGAN SISTEM DATA WAREHOUSE. Artsitektur data warehouse yang akan digunakan oleh PT. Toyota Astra
BAB 4 PERANCANGAN SISTEM DATA WAREHOUSE 4.1 Arsitektur Data Warehouse Artsitektur data warehouse yang akan digunakan oleh PT. Toyota Astra Motor adalah arsitektur data warehouse terpusat (Centralized Data
ANALISIS MASALAH DAN PERANCANGAN SISTEM
62 BAB 3 ANALISIS MASALAH DAN PERANCANGAN SISTEM 3.1 Latar Belakang Permasalahan Perkembangan teknologi database terjadi dengan sangat cepat. Penemuan teknologi On Line Transaction Processing (OLTP) memungkinkan
BAB I PENDAHULUAN 1.1 Latar Belakang
BAB I PENDAHULUAN 1.1 Latar Belakang Perkembangan teknologi informasi yang semakin pesat ditunjukkan dengan munculnya beragam perangkat teknologi yang mempermudah manusia dalam memonitor perkembangan usahanya
ABSTRAK. Kata Kunci: ETL, Data Warehouse, Visualisasi Data, Bagan. Universitas Kristen Maranatha
ABSTRAK Implementasi dari sistem ETL (Extract-Transform-Load) basis data, Data Warehouse, dan Visualisasi Data akan dilakukan untuk PT.Wahana Karet Persada sebagai bentuk tindak lanjut pengolahan data
Bab 3 Perancangan Sistem
Bab 3 Perancangan Sistem Penelitian adalah suatu proses mencari sesutu secara sistematis dalam waktu yang ralelatif lama dengan menggunakan metode ilmiah serta aturan yang berlaku. Konseptualisasi proses
Bab 3 Metode dan Perancangan Sistem
Bab 3 Metode dan Perancangan Sistem Penelitian ini dimulai dari pengambilan data penjualan PT. Sinar Niaga Sejahtera Point Ambarawa yang kemudian diteruskan dengan permintaan ijin untuk melakukan replikasi
Rekayasa Independent Data Mart untuk Analisa Produk Komersial dan Usaha Kecil dan Menengah : Studi Kasus Bank XYZ
Rekayasa Independent Data Mart untuk Analisa Produk Komersial dan Usaha Kecil dan Menengah : Studi Kasus Bank XYZ Jonny Zarman 1, Devi Fitrianah 2 Prodi Teknik Informatika, Fakultas ilmu Komputer, Universitas
Lecture s Structure. Bagaimana Strukturnya. Data Warehouse Methodology (I) Yudi Agusta, PhD Data Warehouse and Data Mining, Lecture 5
Data Warehouse Methodology (I) Yudi Agusta, PhD Data Warehouse and Data Mining, Lecture 5 Copyright Yudi Agusta, PhD 2006 Lecture s Structure Teknik Data Warehouse Pengidentifikasian Keperluan Pengambilan,
ABSTRAK. v Universitas Kristen Maranatha
ABSTRAK Pertumbuhan yang pesat dari akumulasi data telah menciptakan kondisi kaya akan data tapi minim informasi. Data Warehouse merupakan penemuan informasi baru dengan mengelelola sejumlah data dalam
Pemodelan Data Warehouse
Pemodelan Data Warehouse Budi Susanto Teknik Informatika Universitas Kristen Duta Wacana Yogyakarta 10/31/11 budi susanto 1 Tujuan Memahami konsep dasar data warehouse Memahami pemodelan berbasis dimensi
LAMPIRAN-LAMPIRAN. CREATE INDEX [DimCustomer_CustomerType_Idx] ON [dbo].[dimcustomer]([customertype]) ON [PRIMARY] GO
![LAMPIRAN-LAMPIRAN. CREATE INDEX [DimCustomer_CustomerType_Idx] ON [dbo].[dimcustomer]([customertype]) ON [PRIMARY] GO](/thumbs/64/52057537.jpg "LAMPIRAN-LAMPIRAN. CREATE INDEX [DimCustomer_CustomerType_Idx] ON [dbo].[dimcustomer]([customertype]) ON [PRIMARY] GO")
L1 LAMPIRAN-LAMPIRAN Lampiran A. Database Code A.1 Tabel DimCustomer CREATE TABLE [dbo].[dimcustomer] ( [CustomerId] [varchar] (20) COLLATE SQL_Latin1_General_CP1_CI_AS NOT [CustomerType] [varchar] (10)
BAB 4 PERANCANGAN SISTEM. menggunakan data warehouse terpusat (centralized data warehouse). Adapun
BAB 4 PERANCANGAN SISTEM 4.1 Arsitektur Data Warehouse Dalam perancangan data warehouse pada Mandiri Tabungan Rencana menggunakan data warehouse terpusat (centralized data warehouse). Adapun beberapa alasan
BAB 2 LANDASAN TEORI. Database adalah suatu koleksi / kumpulan dari data yang persistent, yaitu ada
BAB 2 LANDASAN TEORI 2.1 Teori Database Database adalah suatu koleksi / kumpulan dari data yang persistent, yaitu ada yang berbeda satu dengan yang lainnya dan biasanya merupakan data yang bersifat sementara
BAB III ANALISA DAN DESAIN SISTEM
BAB III ANALISA DAN DESAIN SISTEM III.1. Analisis Masalah Masalah-masalah yang sering dihadapi oleh PT. Matahari Department Store Grand Palladium Medan sulit dalam mengelola diskon aging akan suatu produk
MINI PROJECT - 4. Kelompok 4 : Kecerdasan Bisnis (Kelas B)
MINI PROJECT - 4 Kecerdasan Bisnis (Kelas B) Kelompok 4 : Muhammad Farhan N (5213100045) Izzatun Nafsi A (521300067) Nur Sofia Arianti (5213100077) Nance Arsita Citra (5213100084) Fitri Larasati (5213100175)
UNIVERSITAS BINA NUSANTARA. Jurusan Teknik Informatika Skripsi Sarjana Komputer Semester Ganjil tahun 2006/2007
UNIVERSITAS BINA NUSANTARA Jurusan Teknik Informatika Skripsi Sarjana Komputer Semester Ganjil tahun 2006/2007 ANALISIS DAN PERANCANGAN DATA WAREHOUSE PEMBELIAN DAN PENJUALAN PADA PT MEGAH JAYA PRATAMA
sekali maka user dapat memberikan tanda check pada checkbox bertulisan Do
121 mapping pada field tertentu maka user dapat memberikan tanda check pada checkbox bertulisan Promotion Name, Start Date, End Date, Min Quantity, dan Max Quantity. Namun bila user merasa tidak membutuhkan
BAB 4 IMPLEMENTASI DAN EVALUASI. dirancang maka langkah selanjutnya adalah mengimplementasikan data. tahapan implementasi dan waktu yang dibutuhkan:
BAB 4 IMPLEMENTASI DAN EVALUASI 4.1 Implementasi Setelah informasi perusahaan telah dikumpulkan dan data warehouse telah dirancang maka langkah selanjutnya adalah mengimplementasikan data warehouse pada
BAB IV PERANCANGAN SISTEM
BAB IV PERANCANGAN SISTEM Pembahasan BAB IV mengenai proses perancangan data warehouse meliputi proses integrasi, pemodelan database dan dashboard interface. 4.1 Perencanaan Tahap perencanaan penelitian
BAB I PENDAHULUAN 1.1 Latar Belakang Masalah
BAB I PENDAHULUAN 1.1 Latar Belakang Masalah Informasi merupakan sebuah elemen penting dalam kehidupan manusia yang semakin lama semakin maju. Dengan adanya informasi, kita bisa mengetahui beberapa hal
BAB 4 IMPLEMENTASI DAN EVALUASI
BAB 4 IMPLEMENTI DAN EVALUI 4.1 Implementasi Sistem Untuk mengetahui nilai manfaat dari perancangan tools yang tertuang dalam pembuatan Analytical CRM, maka perlu dilakukan implementasi. Untuk pelaksanaan
BAB I PENDAHULUAN 1.1 Latar Belakang Masalah
BAB I PENDAHULUAN 1.1 Latar Belakang Masalah Perkembangan teknologi informasi selalu dituntut untuk dapat memenuhi berbagai kebutuhan di segala bidang kehidupan yang semakin lama semakin meningkat dan
ANALISA PERBANDINGAN DATA WAREHOUSE DENGAN SKEMA STAR DAN SNOWFLAKES (STUDI KASUS: AKADEMIK IT TELKOM)
ANALISA PERBANDINGAN DATA WAREHOUSE DENGAN SKEMA STAR DAN SNOWFLAKES (STUDI KASUS: AKADEMIK IT TELKOM) Insan Luthfi Habibi¹, Kiki Maulana², Kusuma Ayu Laksitowening³ ¹Teknik Informatika,, Universitas Telkom
BAB 4 PERANCANGAN SISTEM YANG DIUSULKAN. Perancangan data warehouse dilakukan dalam beberapa tahap. Adapun
BAB 4 PERANCANGAN SISTEM YANG DIUSULKAN 4.1 Sistem yang Diusulkan Perancangan data warehouse dilakukan dalam beberapa tahap. Adapun tahapan-tahapan tersebut adalah: a. Mempelajari latar belakang dan tujuan
1. Merancang arsitektur data warehouse. 2. Merancang data warehouse. 3. Merancang skema bintang. yang ada di dalam data warehouse.
BAB 4 PERANCANGAN SISTEM YANG DIUSULKAN 4.1 Perancangan Data Warehouse Berdasarkan hasil analisa yang telah dilakukan pada bab sebelumnya mengenai permasalahan yang dihadapi dan informasi yang dibutuhkan
BAB 4 DATA WAREHOUSE YANG DIUSULKAN
57 BAB 4 DATA WAREHOUSE YANG DIUSULKAN 4.1 Arsitektur Data Warehouse Pada awalnya, perancangan data warehouse dimulai dengan mencari data dari berbagai sumber yang berhubungan dengan pembuatan laporan
BAB 4 PERANCANGAN DATA WAREHOUSE. diterapkan adalah arsitektur data warehouse terpusat. Alasan memilih arsitektur data
BAB 4 PERANCANGAN DATA WAREHOUSE 4.1 Arsitektur Data Warehouse Dalam merancang data warehouse untuk PT. Saga Machie, arsitektur yang diterapkan adalah arsitektur data warehouse terpusat. Alasan memilih
BAB I PENDAHULUAN. Berkembangnya teknologi dan informasi saat ini telah menghasilkan kumpulan
1 BAB I PENDAHULUAN 1.1 Latar Belakang Berkembangnya teknologi dan informasi saat ini telah menghasilkan kumpulan data diberbagai bidang ilmu pengetahuan, bisnis ataupun pemerintahan. Pada proses penyediaan
FAST berarti sistem ditargetkan untuk memberikan response terhadap user dengan secepat mungkin, sesuai dengan analisis yang dilakukan.
OLAP OLAP (Online Analytical Processing), merupakan metode pendekatan untuk menyajikan jawaban dari permintaan proses analisis yang bersifat dimensional secara cepat. Pengertian OLAP itu sendiri dapat
BAB 4 RANCANGAN DATA WAREHOUSE YANG DIUSULKAN
BAB 4 RANCANGAN DATA WAREHOUSE YANG DIUSULKAN 4.1 Arsitektur Data Warehouse Pada awalnya, perancangan data warehouse dimulai dengan mencari data dari berbagai sumber, baik internal maupun eksternal, yang
BAB 4 PERANCANGAN DAN IMPLEMENTASI DATA WAREHOUSE. 4.1 Anatomi dan Arsitektur Data Warehouse Perusahaan Teh Tong Tji
BAB 4 PERANCANGAN DAN IMPLEMENTASI DATA WAREHOUSE 4.1 Anatomi dan Arsitektur Data Warehouse Perusahaan Teh Tong Tji Dalam perancangan data warehouse untuk Perusahaan Teh Tong Tji digunakan bentuk data
Jurnal Ilmiah Komputer dan Informatika (KOMPUTA) 1 Edisi...Volume..., Bulan 20..ISSN : PEMBANGUNAN INDEPENDENT DATA MART PADA OPTIK YUDA
Jurnal Ilmiah Komputer dan Informatika (KOMPUTA) 1 PEMBANGUNAN INDEPENDENT DATA MART PADA OPTIK YUDA Dinar Priskawati 1, Dian Dharmayanti 2 Teknik Informatika Universitas Komputer Indonesia Jl. Dipatiukur
BAB III ANALISA DAN PERANCANGAN SISTEM
BAB III ANALISA DAN PERANCANGAN SISTEM 3.1 Gambaran Umum PT. XYZ merupakan suatu perusahaan yang terletak di Bekasi yang bergerak dalam bidang food industries yaitu mie instan dengan berbagai macam variant.
BAB 2 2 LANDASAN TEORI. Menurut Inmon (2002, p388), data adalah rekaman dari fakta-fakta, konsepkonsep,
BAB 2 2 LANDASAN TEORI 2.1 Pengertian Data Menurut Inmon (2002, p388), data adalah rekaman dari fakta-fakta, konsepkonsep, atau instruksi-instruksi pada media penyimpanan untuk komunikasi, pengambilan,
http://www.brigidaarie.com Apa itu database? tempat penyimpanan data yang saling berhubungan secara logika Untuk apa database itu?? untuk mendapatkan suatu informasi yang diperlukan oleh suatu organisasi
1. Hasil ERD dari Tabel satu adalah sebagai berikut: Figure 1: ERD Apotik. 2. Syntax CREATE tabel untuk masing - masing tabel :
Tugas Basis Data Nama : Kartika Dwi H/2212106016 1. Hasil ERD dari Tabel satu adalah sebagai berikut: Figure 1: ERD Apotik 2. Syntax CREATE tabel untuk masing - masing tabel : Tabel Pelanggan Create table
BAB 4 PERANCANGAN DAN IMPLEMENTASI. memproyeksikan hal hal berikut: 1. Jalannya investasi dari proses bisnis yang berjalan pada perusahaan
BAB 4 PERANCANGAN DAN IMPLEMENTASI 4.1. Identifikasi Kebutuhan Informasi Kebutuhan informasi dari PT. Corfina Capital adalah untuk dapat memproyeksikan hal hal berikut: 1. Jalannya investasi dari proses
BAB 4 RANCANGAN S IS TEM YANG D IUS ULKAN
BAB 4 RANCANGAN S IS TEM YANG D IUS ULKAN 4.1 Arsitektur Data Warehouse Dalam perancangan data warehouse ini, arsitektur yang akan digunakan adalah arsitektur data warehouse terpusat. Bentuk ini terlihat
BAB I DASAR- DASAR OLAP
BAB I DASAR- DASAR OLAP Olap Online Analytical Processing, atau disingkat OLAP adalah sebuah pendekatan secara cepat menyediakan jawaban-jawaban terhadap kueri analitik yang multidimensi di dalam alam.
BAB IV PERANCANGAN DATA WAREHOUSE
BAB IV PERANCANGAN DATA WAREHOUSE 4.1 Arsitektur Data Warehouse Berdasarkan penelitian yang dilakukan pada PT. Makmur Pangan Kharisma, arsitektur data warehouse yang cocok digunakan adalah bentuk data
Physical Modeling of Data Warehouse using Unified Modeling Language (UML) Muhammad Iqbal Dzulhaq Dendy Jonas Rudi Triwibowo
Physical Modeling of Data Warehouse using Unified Modeling Language (UML) Muhammad Iqbal Dzulhaq Dendy Jonas Rudi Triwibowo Data Warehouse Design Framework Arsitektur dari sebuah data warehouse biasanya
BAB I PENDAHULUAN.
1 BAB I PENDAHULUAN 1.1. Latar Belakang Informasi yang cepat dan akurat sangat dibutuhkan dalam kehidupan sehari-hari, Informasi akan menjadi suatu elemen penting dalam perkembangan masyarakat saat ini
DATAWAREHOUSE. Sukarsa:Pasca Elektro Unud. I Made Sukarsa
DATAWAREHOUSE I Made Sukarsa Evolusi Sistem Informasi Decision Support System database Database (I,U,D,R) ETL DW (Read) Masalah : integrasi /konsistensi OLTP Normalisasi/Den ormalisasi OLAP Denormalisasi
PERANCANGAN DAN IMPLEMENTASI DATA WAREHOUSE MENGGUNAKAN SCHEMA SNOWFLAKE UNTUK MENGETAHUI TREND PRODUKSI DAN PEMASARAN PRODUK
PERANCANGAN DAN IMPLEMENTASI DATA WAREHOUSE MENGGUNAKAN SCHEMA SNOWFLAKE UNTUK MENGETAHUI TREND PRODUKSI DAN PEMASARAN PRODUK Novia Busiarli 1), Mardhiya Hayati 2) 1), 2,)3) Teknik Informatika STMIK AMIKOM
Bab 1 Pendahuluan 1.1 Latar Belakang Masalah
Bab 1 Pendahuluan 1.1 Latar Belakang Masalah Kebutuhan akan informasi dan pengetahuan di kehidupan modern saat ini menjadi suatu yang sangat penting bagi manusia maupun organisasi pada saat ini. Informasi
BAB 4 PERANCANGAN DATA WAREHOUSE
BAB 4 PERANCANGAN DATA WAREHOUSE 4.1 Arsitektur Data warehouse Rancangan data warehouse yang diusulkan untuk PT. Antar Mitra Prakarsa ialah rancangan yang menggunakan arsitektur data warehouse terpusat.
BAB III ANALISIS DAN RANCANGAN SISTEM 3.1. Metode Penilitian Berikut merupakan metode-metode penelitian yang digunakan dalam mengumpulkan data yang
BAB III ANALISIS DAN RANCANGAN SISTEM 3.1. Metode Penilitian Berikut merupakan metode-metode penelitian yang digunakan dalam mengumpulkan data yang terkait dengan penelitian. 3.1.1. Metode Pengumpulan
BAB II LANDASAN TEORI
BAB II LANDASAN TEORI I.1. TEORI DASAR I.1.1. OLAP I.1.1.1. SEPUTAR OLAP Online Analytical Processing (OLAP) merupakan suatu metode pendekatan untuk menyajikan jawaban dari permintaan proses analisis yang
BAB I PENDAHULUAN Latar Belakang
BAB I PENDAHULUAN Pada bab ini dijabarkan tentang latar belakang, rumusan masalah, batasan masalah, tujuan dan manfaat penelitian, metode penelitian, serta sistematika penulisan laporan dari tugas akhir
BAB 1 I PENDAHULUAN. terbarukan untuk mengelola dan mengolah data tersebut. Perkembangan database
BAB 1 I PENDAHULUAN 1.1. Latar Belakang Perkembangan teknologi saat ini sudah sangat pesat dengan data yang berjumlah cukup besar dan juga semakin dibutuhkannya sebuah pengembangan terbarukan untuk mengelola
Modul 3 : Query Penggabungan Tabel
Modul 3 : Query Penggabungan Tabel Tujuan Praktikum - Mahasiswa dapat membedakan perbedaan macam-macam join tabel. - Mahasiswa mampu melakukan query untuk join tabel. - Mahasiswa dapat membedakan union,
BAB 4 PERANCANGAN SISTEM. di Bab 3, maka dibuat data warehouse dan langkahnya adalah sebagai berikut : Memilih Proses (Choosing the Process)
BAB 4 PERANCANGAN SISTEM 4.1 Perancangan Data Warehouse Untuk memecahkan masalah yang ada PT. Harmoni Dharma Abadi seperti yang ada di Bab 3, maka dibuat data warehouse dan langkahnya adalah sebagai berikut
PERANCANGAN DATA MART BAGIAN PENJUALAN MOTOR BEKAS(USED MOTOR CYCLE ) PADA CV. ATLAS MOTOR
PERANCANGAN DATA MART BAGIAN PENJUALAN MOTOR BEKAS(USED MOTOR CYCLE ) PADA CV. ATLAS MOTOR Randy Permana, S. Kom, M. Kom, Fakultas Ilmu Komputer Universitas Putra Indonesia YPTK Padang e-mail : randy.permana@rocketmail.com
Datawarehouse dan OLAP (Overview) Diambil dari presentasi Jiawei Han
Datawarehouse dan OLAP (Overview) yudi@upi.edu Diambil dari presentasi Jiawei Han Apa Data warehouse? Database pendukung keputusan yang terpisah dengan database operasional Platform untuk konsolidasi
BAB III ANALISA DAN PERANCANGAN
BAB III ANALISA DAN PERANCANGAN 3.1. Analisis Sistem Pada bagian ini akan dijelaskan lebih detail tentang proses bisnis perusahaan saat ini, permasalahan-permasalahan yang sering muncul serta kebutuhan-kebutuhan
BAB 4 SISTEM YANG DIUSULKAN. memberikan akses penuh untuk melihat bentuk fisik sistem Basis Data dan Data
BAB 4 SISTEM YANG DIUSULKAN 4.1 Modifikasi Sistem yang Berjalan Berdasarkan kebijakan perrusahaan, Hotel Four Seasons Jakarta tidak memberikan akses penuh untuk melihat bentuk fisik sistem Basis Data dan
BAB III ANALISA DAN DESAIN SISTEM
BAB III ANALISA DAN DESAIN SISTEM III.1. Analisa Sistem Yang Berjalan Untuk mengetahui kekurangan dan kelebihan sistem tersebut, maka perlu diketahui bagaimana sistem yang sedang berjalan pada perusahaan.
BAB III ANALISIS DAN DESAIN SISTEM. proses analisis dan desain Dashboard Sistem Pengisian Pulsa Elektronik.
BAB III ANALISIS DAN DESAIN SISTEM Bab analisis dan desain sistem ini berisi tentang perancangan sistem yang terdiri dari proses analisis dan desain Dashboard Sistem Pengisian Pulsa Elektronik. 3.1. Analisis
BAB I PENDAHULUAN 1.1. Latar Belakang Masalah
BAB I PENDAHULUAN 1.1. Latar Belakang Masalah Dewasa ini perkembangan teknologi komputer mengalami kemajuan yang pesat. Hampir setiap tahun perusahaan berusaha untuk mengoptimalkan fungsi dari teknologi
Abstrak. Kata kunci: Data Warehouse, Database, preprocesssing, OLAP. v Universitas Kristen Maranatha
Abstrak Data transaksi Eureka Foodcourt U.K. Maranatha menjadi kesempatan bagi pihak manajemen untuk dimanfaatkan. Pembuatan data warehouse merupakan suatu tahapan bagus bagi Eureka Foodcourt Universitas
BAB III ANALISA DAN DESAIN SISTEM
BAB III ANALISA DAN DESAIN SISTEM III.1. Analisis Masalah Pada bab ini akan di bahas mengenai Analisis Masalah pada bagian Pembelian dan Penjualan Udang dalam pengolahan persediaan akhir stok udang, diantaranya
LAMPIRAN. /****** Object: Table [dbo].[dimensiactionoffice] Script Date: 01/21/2011
![LAMPIRAN. /****** Object: Table [dbo].[dimensiactionoffice] Script Date: 01/21/2011](/thumbs/63/49221830.jpg "LAMPIRAN. /****** Object: Table [dbo].[dimensiactionoffice] Script Date: 01/21/2011")
LAMPIRAN SQL Query untuk pembuatan tabel OLTP USE [DW1] /****** Object: Table [dbo].[dimensiactionoffice] Script Date: 01/21/2011 08:08:43 ******/ SET ANSI_NULLS ON SET QUOTED_IDENTIFIER ON SET ANSI_PADDING
UNIVERSITAS BINA NUSANTARA. Jurusan Teknik Informatika Skripsi Sarjana Komputer Semester Genap tahun 2005/2006
UNIVERSITAS BINA NUSANTARA Jurusan Teknik Informatika Skripsi Sarjana Komputer Semester Genap tahun 2005/2006 ANALISIS DAN PERANCANGAN KHASANAH DATA PENJUALAN ONLINE PADA PT. BHINNEKA MENTARI DIMENSI Ridwan
Techno, ISSN Volume 12 No. 1, April 2011 Hal
Techno, ISSN 1410-8607 Volume 12 No. 1, April 2011 Hal. 13-18 IMPLEMENTASI ONLINE ANALYTICAL PROCESSING (OLAP) PADA STUDI KASUS SISTEM INFORMASI MANAJEMEN PERIJINAN MENGGUNAKAN ALAT BANTU MICROSOFT BUSINESS
Jurnal String Vol. 1 No. 1 Tahun 2016 ISSN: PERANCANGAN DATA WAREHOUSE PADA PERPUSTAKAAN YAYASAN LENTERA INSAN
PERANCANGAN DATA WAREHOUSE PADA PERPUSTAKAAN YAYASAN LENTERA INSAN Aulia Paramita Program Studi Teknik Informatika, Universitas Indraprasta PGRI Email: aulia.pps@gmail.com Abstrak Data merupakan suatu
BAB III ANALISA DAN DESAIN SISTEM
BAB III ANALISA DAN DESAIN SISTEM III.1. Analisa Sistem Yang Berjalan Sistem yang saat ini sedang berjalan di Rutan Kelas I Medan dalam hal pengolahan remisi tahanan masih dilakukan menggunakan aplikasi
BAB IV HASIL PRAKTEK KERJA DAN ANALISIS
BAB IV HASIL PRAKTEK KERJA DAN ANALISIS 4.1 Analisis Sistem Pencatatan Penjualan Kredit Selama ini aplikasi untuk kegiatan operasional yang digunakan oleh Unit Warungan Primer Koperasi Karyawan Manunggal
HASIL DAN PEMBAHASAN. Microsoft SQL Server Microsoft Sharepoint Microsoft.Net Framework 4.0.
3 warehouse dan data mart memiliki batasan yang sangat tipis, namun perbedaan ini tidak perlu dikhawatirkan karena secara subtansi tujuan dari pembuatannya memiliki kesamaan (Noviandi 2010). Konsep data
BAB 3 ANALISIS DAN PERANCANGAN SISTEM
38 BAB 3 ANALISIS DAN PERANCANGAN SISTEM 3.1 Analisis Perusahaan 3.1.1 Riwayat Perusahaan PT. Artha Envirotama didirikan pada tanggal 25 Juli 2000 oleh Bapak Yohanes Roman. Perusahaan ini pertama kali
Data Warehouse dan Data Mining Oleh : Asep Jalaludin,S.T.,M.M.
Data Warehouse dan Data Mining Oleh : 1 Definisi : Data Warehouse O Data Warehouse adalah Pusat repositori informasi yang mampu memberikan database berorientasi subyek untuk informasi yang bersifat historis
BAB II TINJAUAN PUSTAKA DAN LANDASAN TEORI
BAB II TINJAUAN PUSTAKA DAN LANDASAN TEORI 2.1. Tinjauan Pustaka Pembuatan data warehouse telah banyak dilakukan oleh perusahaanperusahaan industri yang berorientasi profit. Data warehouse diharapkan mampu
BAB II LANDASAN TEORI. Dasar-dasar teori tersebut akan digunakan sebagai landasan berpikir dalam
BAB II LANDASAN TEORI Dalam merancang dan membangun suatu sistem informasi, dasar-dasar teori yang akan digunakan sangatlah penting untuk diketahui terlebih dahulu. Dasar-dasar teori tersebut akan digunakan
P10 Database SQL Server 2008
P10 Database SQL Server 2008 A. Tujuan Mahasiswa dapat membuat database dan data source pada SQL Server 2008 Mahasiswa dapat membuat tabel dan relationship tabel pada SQL Server 2008 B. Pembahasan SQL
ANALISIS DAN PERANCANGAN DATAWAREHOUSE BAGIAN KEPENDUDUKAN PADA KEMENTERIAN DALAM NEGERI SKRIPSI. Oleh. Poltak Caesarrio Hutagaol
ANALISIS DAN PERANCANGAN DATAWAREHOUSE BAGIAN KEPENDUDUKAN PADA KEMENTERIAN DALAM NEGERI SKRIPSI Oleh Poltak Caesarrio Hutagaol 1000861440 Febriwanto.MP.Hutagalung 1000883605 Lam Rejeki Purba 1000889792
BAB III ANALISA DAN DESAIN SISTEM
BAB III ANALISA DAN DESAIN SISTEM III.1. Analisa Sistem Yang Berjalan Pada bagian administrasi, pengolahan data tersebut diawali dari data order kertas ke bagian administrasi dengan mencatat data order
ANALISIS DAN PERANCANGAN DATA WAREHOUSE PADA PT. GLOBAL INFORMASI BERMUTU (STUDI KASUS : PEMBELIAN, PENJUALAN, DAN PRODUKSI)
ANALISIS DAN PERANCANGAN DATA WAREHOUSE PADA PT. GLOBAL INFORMASI BERMUTU (STUDI KASUS : PEMBELIAN, PENJUALAN, DAN PRODUKSI) SKRIPSI Oleh Ninawati 1000843072 Donna Cherie 1000845462 Ita Wana 1000854492
BAB 4 RANCANGAN SISTEM YANG DIUSULKAN
82 BAB 4 RANCANGAN SISTEM YANG DIUSULKAN 4.1 Usulan Prosedur yang Baru Gambar 4.1 Flowchart Usulan Sistem Reporting yang Baru Usulan prosedur baru untuk reporting anggaran operasional mill production pada
BAB 4 IMPLEMENTASI DAN EVALUASI. jadwal implementasi yang berlangsung selama kurang lebih 2 bulan.
BAB 4 IMPLEMENTASI DAN EVALUASI 4.1 Implementasi Untuk mempermudah proses implementasi pada perusahaan, maka dibuat jadwal implementasi yang berlangsung selama kurang lebih 2 bulan. Waktu(minggu) Proses