BAB 2 LANDASAN TEORI

Transkripsi

1 BAB 2 LANDASAN TEORI 2.1 Data Pengertian Data Menurut Hall (2001,p14), data adalah fakta yang dapat atau tidak dapat diproses (disuling, dirangkum atau diperbaiki) dan tidak berpengaruh secara langsung pada pengguna. Sebaliknya, informasi menyebabkan pengguna melakukan suatu tindakan yang dapat dilakukan atau tidak dilakukan. Menurut Laudon (2006, p13), data adalah kumpulan fakta yang masih mentah yang menjelaskan aktifitas-aktifitas yang terjadi dalam organisasi atau lingkungan fisik, sebelum terorganisir dan diubah menjadi bentuk yang dimengerti dan dapat digunakan. Jadi, data adalah sumber dari informasi yang nantinya dapat digunakan menjadi suatu bentuk yang lebih berguna dan berarti. 2.2 Sistem Basis Data Pengertian Sistem Basis Data Basis data saat ini merupakan bagian dari kehidupan sehari-hari yang tanpa kita sadari, bahwa kita selalu menggunakannya. Basis data atau yang kita kenal dengan nama database adalah kumpulan data yang berelasi. Sedangkan Database Management System (DBMS) merupakan perangkat lunak yang mengatur dan mengontrol akses ke basis data. 7

2 8 Maka pengertian sistem basis data adalah kumpulan program aplikasi yang berinteraksi dengan basis data. Contoh aplikasi database adalah, aplikasi database perpustakaan universitas Bina Nusantara. Aplikasi ini dapat memberikan informasi mengenai keterangan buku di perpustakaan, keterangan pembaca, dan keterangan peminjaman. Aplikasi ini dapat mengetahui informasi buku melalui indeks yang terkomputerisasi dengan menggunakan bar code. Bar code berfungsi untuk mengetahui kapan buku ini masuk dan keluar di perpustakaan. Menurut Connolly (2002, p14), database adalah sebuah pembagian kumpulan data yang berelasi secara logika, dan keterangan data yang didesain untuk mendapatkan informasi yang dibutuhkan sebuah organisasi. Basis data dapat melakukan pelaporan data besar dimana semua bagian dan pengguna dapat menggunakannya, menghilangkan data berulang, dan semua data diintegrasikan dengan meminimumkan duplikasi data. Basis data juga sebagai system catalog (data dictionary atau metadata) yang mampu mendeskripsikan dirinya sebagai kumpulan record yang terintegrasi, data yang berelasi secara logika terdiri dari entities, attributes, dan relationships di mana ketiganya dianalisa untuk kebutuhan informasi pada perusahaan Pendekatan File Based System Menurut Connolly (2002, p7), filed-based system adalah kumpulan program aplikasi yang melayani end-user seperti pembuatan laporan. Setiap program mendefinisi dan mengatur masing-masing datanya sendiri.

3 9 Sistem ini berjalan secara manual dalam pengisian data, data disimpan pada lemari penyimpanan. Sistem ini tidak dapat menyimpan data dalam jumlah besar. Masalahnya sistem ini memiliki keterbatasan dalam mengolah data, seperti: 1. Data yang terpisah dan terisolasi. 2. Duplikasi data, data yang sama terdapat pada program aplikasi lain. 3. Ketergantungan data, perubahan yang terjadi pada satu program, menyebabkan penyesuaian dengan program lain, penyesuaian tersebut membuat stuktur program awal kembali. 4. Format file yang tidak kompatibel, program ditulis dengan bahasa yang berbeda-beda sehingga tidak mudah mengakses file lain. 5. Query / ukuran aplikasi yang tetap Aplikasi Basis Data Contoh aplikasi basis data menurut Kronke (2006, p5) dapat dikategorikan sebagai berikut: 1. Aplikasi Basis Data Single User Aplikasi ini digunakan penjual tunggal yang menjaga alur pelanggan dan merupakan hubungan penjual dengan pelanggan. Contoh : sales contact manager, penggunanya satu sales dengan ukuran data sebesar 1000 baris, dan produknya database terpusat. Misalnya Gold Mine and Act.

4 10 2. Aplikasi Basis Data Multiuser Aplikasi ini digunakan lebih dari satu pengguna. Contoh : aplikasi jadwal pasien yang digunakan oleh 15 sampai 50 pengguna, seperti perawat, dokter, dan bagian administrasi. Besar data mencapai baris data dengan 5 sampai 10 tabel yang berbeda. 3. Aplikasi Basis Data e-commerce Aplikasi ini digunakan untuk memasukkan data pemesanan, penagihan, pengiriman, dan layanan pelanggan. Contohnya : Amazon.com dan Drugstore.com yang menggunakan halaman web yang mereka kirim ke konsumen. Konsumen dapat mengoperasikan dengan menambah belanja, memesan pembelian, dan pembatalan pembelian. 4. Aplikasi Basis Data Data Mining Aplikasi ini menggunakan data yang dihasilkan dari proses pemesanan dan sistem operasi lain untuk menghasilkan informasi yang membantu mengatur perusahaan dengan merangkum data yang ada. 2.3 Model Relasional Di dalam model relasional, semua data secara logika terstruktur dalam tabel. Setiap tabel mempunyai nama dan terdiri dari kolom-kolom yang dinamakan atribut. Setiap baris mengandung setiap nilai untuk setiap atribut. Di dalam model relational dikenal istilah-istilah relation, attribute, domain, degree, dan cardinality. Menurut Connolly (2002, p72), relation atau relasi adalah sebuah tabel yang terdiri dari baris dan kolom. Atribut adalah penamaan kolom yang ada di dalam sebuah tabel. Domain adalah kumpulan dari nilai-nilai yang diijinkan

5 11 pada satu atau lebih atribut. Tuple adalah penamaan baris yang terdapat dalam sebuah tabel. Degree of a relation adalah jumlah atribut yang dapat ditampung. Cardinality of a relation adalah jumlah baris yang terdapat pada sebuah tabel. 2.4 Basis Data Relasional Menurut Connolly (2002, p74), relasional database merupakan kumpulan relasi yang sudah dinormalisasikan dengan nama berbeda. Ciri-ciri yang dimiliki oleh sebuah relasi antara lain: - Memiliki nama yang berbeda antara satu relasi dengan relasi lainnya di dalam skema relasional. - Setiap cell di dalam relasi mengandung sebuah nilai tunggal. - Setiap atribut memiliki nama berbeda. - Nilai dari sebuah atribut berasal dari domain yang sama. - Setiap baris pada relasi berbeda, tidak ada baris yang bernilai sama. - Urutan dari atribut tidak terlalu berpengaruh. - Secara teoritis, urutan dari tuple atau baris tidak berpengaruh namun dalam implementasinya, urutannya dapat mempengaruhi waktu pengaksesan. Karena antara setiap baris tidak memiliki nilai sama, maka diperlukan sebuah relational key yang dapat mengidentifikasikan setiap baris di dalam relasi secara unik.

6 12 Beberapa relational key yang dikenal antara lain sebagai berikut: a. Super key Sebuah atribut atau kumpulan dari atribut yang secara unik mengidentifikasi baris yang ada dalam sebuah relasi. b. Candidate key Sebuah candidate key harus memiliki dua ciri-ciri, yaitu secara unik mengidentifikasi sebuah baris dan tidak ada nilai lain yang memiliki sifat yang unik tersebut (irreducibility). c. Primary key Merupakan candidate key yang dipilih untuk mengidentifikasi baris-baris di dalam sebuah relasi secara unik. d. Foreign key Merupakan atribut atau kumpulan atribut di dalam sebuah relasi yang juga merupakan candidate key. e. Composite key Merupakan gabungan dari dua atribut atau lebih yang membentuk sebuah primary key. 2.5 Database Management System Menurut Connolly (2002, p16), Database Management System (DBMS) adalah sebuah sistem perangkat lunak yang memungkinkan user mendefinisi, membentuk, mengatur dan mengontrol akses ke database. DBMS berinteraksi dengan pengguna aplikasi program dan database.

7 13 DBMS menyediakan fasilitas-fasilitas sebagai berikut : 1. Data Definition Language (DDL), yang berguna untuk menspesifikasi tipe data, struktur, dan constraint data. Semua spesifikasi di simpan dalam database. 2. Data Manipulation Language (DML), yang dapat menambah, mengubah, dan menghapus, dan mengembalikan data dengan memberikan fasilitas data query berupa query language. Query language yang sering digunakan adalah Structured Query Language (SQL). 3. Pengendalian akses database, antara lain: - Sistem keamanan : mencegah user yang tidak memiliki hak akses untuk mengakses database. - Sistem Integrasi, menjaga konsistensi data. - Pengendalian share data. - Backup dan Recovery sistem. - Katalog deskripsi data dalam database 4. Mekanisme View untuk menyediakan data yang diinginkan dan diperlukan user saja Komponen DBMS Ada lima komponen utama dalam DBMS, yaitu : 1. Hardware, yang berupa komputer hingga jaringan komputer. 2. Software, yaitu DBMS, aplikasi program, sistem operasi, dan software jaringan (bila diperlukan untuk jaringan). 3. Data yang merupakan data operasional dan metadata yang digunakan perusahaan.

8 14 4. Prosedur, yaitu instruksi dan aturan yang harus ada pada desain dan kegunaan dari database dan DBMS. 5. People, antara lain: - Data Administration (DA) DA mengatur sumber daya data, meliputi perencanaan database, pengembangan dan pemeliharaan standar, kebijakan, prosedur, dan desain database logikal dan konseptual. - Database Administration (DBA) DBA mengatur realisasi fisik dari aplikasi database yang meliputi desain fisik database dan implementasi, pengaturan keamanan dan kontrol integritas, pengawasan performa sistem dan pengaturan ulang database. - Designer Database (Logical dan Fisical) Desainer database logikal melakukan identifikasi data (entiti dan atribut), hubungan antara data, dan batasan data yang disimpan dalam database. Desainer database fisikal memutuskan bagaimana desain database logikal diimplementasikan. - Application Developers Application developers mengimplementasikan program aplikasi yang menyediakan kebutuhan bagi end-user. - End-User End User dapat digolongkan menjadi 2 bagian, yaitu :

9 15 1. Naïve users, adalah pengguna yang tidak perlu tahu mengenai DBMS, hanya mengoperasikan dengan perintah sederhana dan memilih pilihan dari menu. 2. Sophisticated users, pengguna yang mengetahui struktur basis data dan fasilitas DBMS Keuntungan dan Kerugian DBMS Ada beberapa keuntungan yang didapat dengan memakai DBMS, yaitu: - Mengontrol redudansi data. - Konsistensi data. - Lebih banyak informasi dari jumlah data yang sama. - Share data. - Meningkatkan integritas data. - Meningkatkan keamanan. - Standar pelaksanaan. - Skala ekonomi (data operasional organisasi dijadikan satu database dan membuat aplikasi pada satu sumber data sehingga akan penghematan biaya). - Keseimbangan aksesibilitas data dan data responsiveness. - Meningkatkan produktivitas. - Meningkatkan pemeliharaan melalui data independence. - Meningkatkan konkurensi (mengurangi loss informasi dan loss integrasi). - Meningkatkan layanan backup dan recovery.

10 16 Sementara itu, yang menjadi kerugian DBMS adalah sebagai berikut: - Kompleksitas. - Ukuran. - Biaya DBMS. - Biaya penambahan perangkat keras. - Biaya konversi (biaya staf spesialis, biaya pelatihan). - Performance ( tidak dapat berjalan secepat yang diinginkan). - Resiko kesalahan yang lebih tinggi. 2.6 Data mart Menurut Kimball (2002, p396), Datamart adalah Bagian dari logikal dan fisikal dari area cakupan yang dimiliki oleh data warehouse. Sedangkan menurut Connoly dan Begg ( 2005, p1171) Data mart merupakan bagian dari data warehouse, yang mendukung kebutuhan informasi bagian departemen atau fungsi bisnis tertentu. Berikut karakteristik yang membedakan antara data mart dengan data warehouse: 1. Data mart berfokus pada kebutuhan pengguna yang berhubungan dengan satu bagian departemen atau fungsi bisnis. 2. Data mart tidak berisi data operasional yang bersifat detil. 3. Data mart lebih dimengerti dan digunakan karena berisi data yang lebih sedikit Dibandingkan data warehouse.

11 Data Warehouse Pengertian Data Warehouse Ada banyak ahli yang mengemukakan pengertian dari data warehouse, berikut ini adalah beberapa pendapatnya: 1. Menurut Inmon (2005, p29), data warehouse adalah koleksi data yang mempunyai sifat berorientasi pada subjek, terintegrasi, variasi waktu, dan koleksi datanya tidak mengalami perubahan dalam mendukung proses pengambilan keputusan di manajemen. 2. Menurut Ralph Kimball (2002,p397), data warehouse adalah The conglomeration of organization s data warehouse staging and presentation areas, where operational data is specifically structured for query and analysis performance. Pengertian tersebut dapat diartikan penggabungan antara tingkatan data warehouse yang ada pada suatu organisasi dengan area prestasi, dimana data operasional secara spesifik disusun untuk query dan analisis performa, serta kemudahan dalam penggunaan. 3. Menurut Berson dan Smith (2001, p4), data warehouse adalah gabungan teknologi yang bertujuan mengefektifkan integrasi database operasional ke dalam lingkungan yang memungkinkan penggunaan secara strategis. 4. Menurut Turban (p418), Data warehouse adalah tempat penyimpanan data historis yang berorientasi subjek, yang diatur agar dapat diakses dan diterima untuk aktivitas proses analisis.

12 18 5. Menurut Paulraj (p14), Data warehouse adalah suatu lingkungan yang terkomputerisasi dimana user dapat menemukan informasi strategis, dapat berhubungan langsung dengan data yang mereka butuhkan untuk membuat keputusan bisnis yang lebih baik. Data warehouse berisi informasi tentang keseluruhan data perusahaan yang telah terintegrasi Karakteristik Data warehouse Menurut Inmon(2005, p29), data warehouse memiliki empat karakteristik utama, antara lain sebagai berikut: 1. Subject-Oriented Data warehouse diorganisasikan ke dalam subjek bisnis yang utama (seperti pelanggan, produk, data penjual) dibandingkan fungsi bisnis yang berjalan (seperti pembuatan faktur, kontrol stok dan penjualan produk.) Operasional Auto Data warehouse Customer Life Policy Health Premium Casuality Claim Gambar 2.1 Data warehouse subject oriented

13 19 2. Integrated Konsep integrated dikaitkan dengan pengambilan sumber data yang berasal dari berbagai sumber yang terpisah. Data yang diambil itu selanjutnya akan di ubah, di format kembali, diurutkan, diringkas, dan seterusnya. Gambar 2.2 Pokok persoalan dari integrasi (Inmon,2005,p31).

14 20 3. Time Variant Sifat rentang waktu terjadi karena adanya perbedaan antara data operasional dan informasional. Pada lingkungan data warehouse, data akurat pada waktu tertentu (harian, bulanan, tahunan). Data warehouse memiliki tempat penyimpanan data historis. Seperti 5 atau 10 tahun lalu bahkan lebih lama lagi yang mungkin akan dipakai untuk membuat perbandingan analisa trend dan peramalan. Operational Data Warehouse - Time horizon current to days - Time Horizon 5 10 Years - Update of Records - Sophisticated snapshots of data - Key structure may or may not contain - Key structure contains an element element of time of time Gambar 2.3 Time Variant (Inmon,2005,p32). 4.Non-volatile Data pada data warehouse, tidak berubah-ubah dan dapat melakukan operasi insert, update, delete pada data yang akan merubah isi dari database. Pada data warehouse ada 2 kegiatan manipulasi data yaitu loading data (mengambil data yang dibutuhkan data warehouse) dan akses data (proses mengakses data warehouse, seperti melakukan query

15 21 atau menampilkan laporan yang dibutuhkan). Dalam data warehouse tidak ada kegiatan update data. Sebagai gantinya, ada snapshot dalam bentuk format statis yang di-load oleh data warehouse. Apabila terjadi perubahan data, snapshot baru terbentuk, kemudian snapshot itu akan disimpan bersama dengan snapshot yang sudah ada dalam data warehouse sehingga jadi historikal data. Gambar 2.4 Pokok persoalan dari nonvolatile (Inmon,2005,p32) Bentuk Data Warehouse Functional Data Warehouse Functional data warehouse ini merupakan bentuk database dimana data warehouse dibuat lebih dari satu dan dikelompokkan berdasarkan masing-masing fungsi yang ada dalam perusahaan, seperti fungsi financial / keuangan, fungsi marketing / pemasaran, fungsi kinerja personalia, dan lain-lain. Keuntungan dari bentuk ini adalah sistem akan mudah dibangun dengan biaya yang relatif murah. Kerugian dari penggunaan

16 22 bentuk ini adalah resiko kehilangan konsistensi data dan terbatasnya kemampuan pengguna dalam hal pengumpulan data. Source Branch Function Data Warehouse Source Function Data Warehouse Operasional Workstation Gambar 2.5 Functional Data Warehouse Centralized Data Warehouse Centralized data warehouse ini merupakan database fisikal tunggal yang memuat semua data untuk area fungsional yang khusus, departemen, divisi, atau perusahaan. Data warehouse ini digunakan ketika terdapat kebutuhan akan data informasional dan terdapat banyak end-user yang sudah terhubung ke komputer pusat atau jaringan. Bentuknya menyerupai functional data warehouse, akan tetapi sumber datanya lebih dahulu dikumpulkan atau diintegrasikan pada suatu tempat terpusat, baru kemudian data tersebut dibagi berdasarkan fungsi-fungsi yang dibutuhkan oleh

17 23 perusahaan. Bentuk data warehouse terpusat ini sering digunakan oleh perusahaan-perusahaan yang belum mempunyai jaringan eksternal. Keuntungan bentuk centralized data warehouse ini adalah data benar-benar terpadu karena konsistensi yang tinggi. Namun demikian membutuhkan waktu yang lama dan biaya yang mahal dalam membentuk data warehouse seperti ini. Source Source Source Centralized data warehouse Function Data Warehouse Function Data Warehouse Operation Gambar 2.6 Centralized Data Warehouse Workstation Distributed Data Warehouse Distributed data warehouse adalah data warehouse dimana komponen tertentu dari data warehouse tersebut didistribusikan melewati sebuah database fisikal yang berbeda. Distributed data warehouse biasanya melibatkan data yang paling teredundansi, dan sebagai akibatnya, menimbulkan proses load dan update yang sangat komplek. Distributed data warehouse ini menggunakan gateway yang berfungsi sebagai jembatan antara lokasi data warehouse

18 24 dengan workstation yang menggunakan sistem yang beranekaragam, sehingga pada bentuk data warehouse ini memungkinkan perusahaan untuk mengakses sumber data yang terdapat diluar lokasi perusahaan (eksternal). Bentuk data warehouse ini mempunyai kelebihan dalam hal pengaksesan data dari luar perusahaan yang telah mengalami sinkronisasi terlebih dahulu dan tetap terjaga konsistensinya. Tetapi bentuk ini juga memiliki kerugian yaitu bentuk ini merupakan yang paling mahal dan paling komplek untuk diterapkan karena sistem operasinya dikelola secara terpisah. Source Source Data warehouse Gateway Source Operation Workstation Gambar 2.7 Distributed Data Warehouse 2.8 Struktur Data warehouse Level kedetailan data dalam struktur data warehouse terbagi menjadi 5 tingkat yaitu: 1. Old Detail Data Mengambarkan data historis secara detail yang digunakan untuk menganalisa suatu trend.

19 25 2. Current Detail Data Data diperoleh secara langsung dari database OLTP. Yang bertujuan untuk memberikan gambaran dari keseluruhan perusahaan. Data diperoleh dari berbagai sumber seperti data profil pelanggan, data transaksi pelanggan, penjualan dan lainlain. 3. Light Summarized Data Merupakan ringkasan dari current detail data. Di dalam tahap ini data belum dapat digunakan untuk pengambilan keputusan karena sifat data belum total summary yang artinya data masih bersifat detail. Light Summarized Data seringkali digunakan sebagai gambaran dari keadaan yang sedang mau pun belum berlangsung 4. Highly Summarized Data Highly summarized data merupakan hasil proses ringkasan yang bersifat total summary. Pada tingkat ini data sangat mudah diakses dan pada akhirnya dapat digunakan sebagai pengambil keputusan bagi para eksekutif perusahaan. Bagi para eksekutif, hal ini sangatlah memudahkan karena mereka hanya perlu membaca atau melakukan analisis dalam waktu yang singkat. 5. Metadata Metadata bukanlah merupakan hasil kegiatan operasional seperti keempat jenis data diatas, namun merupakan komponen penting dalam data warehouse yang menjalankan seluruh proses yang ada. Metadata seringkali disebut data tentang data. Metadata memberi peranan yang penting untuk kefektifan pengunaan data warehouse karena dengan adanya metada akan mempermudah end-user dalam melakukan analisis dan menghemat waktu.

20 26 Metadata digunakan untuk beberapa tujuan yang bervariasi termasuk: - Proses extraction dan loading untuk pemetaan sumber data menjadi bentuk data yang common view. - Proses manajemen data warehouse untuk proses otomatisasi pembentukan tabel ringkasan. - Bagian dari proses manajemen query, yang digunakan untuk mengarahkan query ke sumber data yang paling tepat. Gambar 2.8 Struktur data warehouse Imnon(2005,p34)

21 Arsitektur Data Warehouse Menurut connoly (2002, p1052), ada sepuluh komponen utama yang dimiliki oleh data warehouse yaitu: 1. Operasional Data Sumber data untuk data warehouse bersumber dari data-data berikut: - Mainframe data operasional yang ada dalam jaringan database. - Data departemental yang ada dalam hak akses dalam sistem file. - Data privasi di simpan di dalam server pribadi dan workstation. - Sistem external, seperti internet, atau database yang terkait dengan customer dan suppliers. 2. Operasional Datastore Tempat penyimpanan data operasional yang sifatnya saat ini dan terintegrasi dan dipakai untuk analisis. Biasanya operational datastore terstruktur dan tersuplai dengan data dengan cara yang sama dengan data warehouse. Tetapi memungkinkan untuk memindahkan ke data warehouse secara sederhana. 3. Load Manager Load manager disebut juga sebagai komponen frontend, menampilkan semua operasi gabungan dengan menarik dan menyimpan data ke data warehouse. Data bisa langsung dikeluarkan langsung dari sumber data, atau data store operasional. Operasi yang dilakukan load manager, bisa termasuk transformasi sederhana dari data untuk menyiapkan data yang akan dimasukan data warehouse.

22 28 4. Warehouse Manager Menangani semua operasi yang berhubungan dengan management data dalam data warehouse. Operasi-operasi yang dijalankan oleh warehouse manager, mencakup: a. Analisis data untuk menjaga kekonsistenan data. b. Melakukan transformasi dan penggabungan sumber data dari tempat penyimpanan sementara ke dalam tabel-tabel data warehouse. c. Melakukan denormalisasi (jika perlu). d. Melakukan aggregations (jika perlu). e. Menyimpan (archive) dan backup data. 5. Query Manager Query manager disebut juga sebagai komponen backend, untuk menangani semua operasi yang berhubungan dengan manajemen permintaan user (user queries). Operasi yang dijalankan oleh query manager meliputi kegiatan mengarahakan permintaan ke tabel-tabel data yang tepat dan melakukan penjadwalan eksekusi pada permintaan. 6. Detailed Data Pada bagian ini, warehouse menyimpan detail semua data dalam skema database yang umumnya detail data tidak disimpan secara online, tetapi ada dengan meng-aggregate data sama tingkat detail berikutnya. 7. Lightly and Highly Summarized Data Disini warehouse menyimpan semua data yang dihasilkan oleh manager warehouse secara light dan high. Tujuannya untuk meningkatkan kecepatan performa dari query.

23 29 8. Archive / Back-up Data Digunakan untuk menyimpan detailed data dan data yang telah diringkas. Tujuannya adalah untuk penyimpanan(archiving) dan backup. Data kemudian ditransfer ke media penyimpanan seperti magnetic tape atau optical disk. 9. Metadata Bagian ini digunakan untuk penarikan dan penyimpanan proses data, proses management warehouse, dan juga bagian dari proses management query. 10. End-user Access Tools Prinsip tujuan dari data warehouse, adalah untuk menyediakan informasi sebagai bantuan bagi para pengguna dalam bidang bisnis, yang melakukan strategi untuk pengambilan keputusan. Menurut beberapa ahli, End-user access tools dapat dikategorikan menjadi 5 golongan utama, yaitu: a. Reporting and Query Tools Reporting tools meliputi production reporting tools dan report writer. Production reporting tools digunakan untuk menghasilkan laporan operasional reguler atau daya pemicu kerja yang tinggi. Seperti order customer, invoice, dan gaji karyawan. Query tools untuk relasional data warehouse, di-design untuk menerima SQL dan syntax-nya, untuk query penyimpanan data untuk data warehouse. Tools ini, melindungi end user dari kompleksitas SQL dan struktur database.

24 30 b. Application Development Tools Kebutuhan dari end user, kemampuan membuat laporan yang built-in dan tools query yang tidak mencukupi, dikarenakan kebutuhan analisis tidak bisa dilakukan, atau karena interaksi user membutuhkan tingkat profesional yang tinggi. c. Executive Information System (EIS) tools EIS lebih dikenal sebagai Everybody s information system yang semula dikembangkan untuk mendukung strategi kebutuhan tingkat tinggi. Tools EIS mulanya terasosiasi dengan mainframe, sehingga memungkinkan user membuat aplikasi pendukung pengambilan keputusan, dalam menyediakan overview data organisasi dan mengakses sumber data eksternal. d. OnLine Analitical Proccessing (OLAP) tools Menurut Connolly (2000, p1101), OLAP merupakan istilah yang mendeskripsikan teknologi yang menggunakan multi dimensional view dari data aggregate untuk menyediakan akses yang cepat bagi informasi strategis yang bertujuan untuk proses analisis. OLAP memungkinkan user untuk memperoleh pengertian yang mendalam dan pengetahuan mengenai berbagai aspek dalam perusahaan secara cepat, konsisten, dan akses yang interaktif untuk memperluas kemungkinan dalam berbagai sudut pandang data. OLAP tools yang digunakan dalam perancangan data warehouse ini adalah MOLAP (Multi Dimensional OLAP). MOLAP tools digunakan khusus untuk struktur dan sistem management basis data yang multi

25 31 dimensional yang dapat mengatur dan menganalisis data. Untuk mempertinggi performa query, data secara khusus dijumlah dan disimpan berdasarkan kebutuhan yang telah diramalkan. Struktur data MOLAP menggunakan teknologi array dan teknik penyimpanan melalui management data yang renggang. (Connolly, 2002, p ) Berikut ini beberapa keuntungan yang diperoleh dengan menerapkan OLAP, yaitu : Meningkatkan produktivitas dari end-users bisnis, pengembang teknologi informasi. Meningkatkan penghasilan dan keuntungan potensial dengan memungkinkan perusahaan untuk merespons permintaan pasar lebih cepat. Mengurangi backlog dari pengembangan aplikasi untuk staf teknologi informasi dengan membuat end-users bebas untuk membuat perubahan skema dan memungkinkan organisasi untuk merespons permintaan pasar lebih cepat. Mengurangi lalu lintas jaringan dalam sistem OLTP atau dalam data warehouse. (Connolly, 2002, p1104) e. Data Mining Tools Data mining adalah proses yang memiliki makna tentang korelasi yang baru, patterns, dan trend dengan data dalam jumlah besar menggunakan teknik statistic, matematika, dan kecerdasan buatan. Data mining memiliki potensi untuk menggantikan kemampuan dari OLAP tools, sebagai penampilan utama dari data mining adalah kemampuan

26 32 untuk membangun prediksi dibandingkan dengan model-model retrospective Data Warehouse Data Flows Data flows yang ada pada data warehouse terdiri dari 5 bagian, yaitu, : - Inflow Proses yang berhubungan dengan penarikan, pembersihan, dan mengisi data dari sumber ke dalam data warehouse. - Upflow Proses yang terhubung dengan menambahkan nilai ke data di dalam warehouse, melewati ringkasan pengepakan, dan penyebaran data. - Downflow Prosesnya berhubungan dengan penyimpanan dan back-up data dalam data warehouse. - Outflow Proses yang berhubungan dengan membuat data tersedia untuk endusers. - Metaflow Proses yang berkaitan dengan manajemen meta-data.

27 Metodologi Perancangan Data Warehouse Menurut Connoly, (2002, p1083) Metodologi Perancangan Data Warehouse nine-steps methodology yang terdiri dari: a. Pemilihan Proses Sebuah proses (Fungsi) mengarahkan tentang sebuah subjek yang ada pada suatu data mart. Data mart yang pertama dibangun harus bisa disampaikan pada waktunya, sesuai dengan anggaran dan menjawab sebagian besar pertanyaan bisnis yang penting. Pilihan yang paling tepat untuk data mart adalah yang terkait dengan penjualan. Sumber data sebaiknya yang mudah diakses dan berkualitas tinggi. Sebagai contoh, dalam memilih data mart yang pertama untuk DreamHome pertama kali kita menentukan proses bisnis diskrit dari DreamHome meliputi: o Properti sales. o Properti rentals (leasing). o Properti Viewing. o Properti advertising. o Properti maintenance. Kebutuhan data yang berhubungan dengan proses ini ditunjukkan dengan model ER dari gambar 2.9. Perlu dicatat bahwa model ER sudah disederhanakan dengan memberi label pada entitas dan relasinya saja. Entitas yang digelapkan mewakili inti dari proses bisnis dari DreamHome sesuai yang ditampilkan pada gambar 2.9. Proses bisnis yang terpilih sebagai data mart yang pertama adalah properti sales dari proses bisnis yang ditunjukan pada gambar 2.10.

28 34 Gambar 2.9 Model ER dari DreamHome Gambar 2.10 Model ER yang mewakili data kebutuhan property sales

29 35 b. Pemilihan Grain Dalam pemilihan grains harus menentukan tabel fakta yang mewakili record. Sebagai contoh, entitas PropertySales yang ditunjukan dengan tulisan yang ditebalkan dalam gambar 2.10 mewakili fakta-fakta dari setiap property sale dan menjadi fakta tabel. Oleh karena itu, grain dari tabel fakta propertysale adalah individual. Hanya dengan grain untuk fakta tabel yang sudah terpilih kita dapat menentukan dimensi dari fakta tabel. Sebagai contoh, entitas branch, staff, owner, clientbuyer, propertyforsales, dan promotion. Yang ditunjukan dalam gambar 2.10 akan digunakan untuk referensi data mengenai property sales dan akan menjadi tabel dimensi dari skema bintang property sales.. Selain itu, dimensi waktu juga harus dimasukkan sebagai inti dari dimensi yang harus selalu ada dalam skema bintang. Keputusan grain untuk tabel fakta juga menentukan grain dari setiap tabel dimensi. Sebagai contoh, jika grain untuk tabel fakta property sales adalah individualnya dari property sale, maka grain dari dimensi klien adalah detail dari klien yang mewakili properti tertentu. c. Identifikasi Dimensi Tabel dimensi menyiapkan konteks untuk menanyakan pertanyaan tentang fakta yang ada didalam tabel fakta. Kumpulan dimensi yang dibuat dengan baik akan mempermudah dalam mengerti dan mengunakan data mart. Kemudian mengidentifikasikan detail dimensi yang secukupnya untuk mengambarkan klien dan properti pada grain yang tepat. Sebagai contoh, setiap

30 36 klien dari tabel dimensi ClientBuyer digambarkan dengan atribut clientid, clientno. clientname, clienttype, city, region, dan country. Ketidaklengkapan dari dimensi yang dikumpulkan akan mengurangi fungsi dari data mart sampai ke enterprise. Jika ada dimensi yang sama dalam dua data mart, maka keduanya pasti memiliki dimensi yang sama atau salah satunya pasti melengkapi yang lainnya. Hanya dengan cara ini dua data mart bisa berbagi dalam satu atau lebih dimensi yang ada dalam aplikasi yang sama. Ketika dimensi digunakan dalam lebih dari satu data mart, dimensi yang satunya harus bisa disesuaikan. Sebagai contoh dimensi yang harus disesuaikan antara property sales dan property advertising adalah dimensi time, PropertyForSale, Branch, dan Promotion. Jika dimensidimensi ini tidak sesuai atau mereka dibiarkan menyimpang dari sinkronisasi diantara data mart, maka keseluruhan data pada data warehouse akan gagal, Dikarenakan kedua data mart tidak dapat digunakan bersama-sama. Sebagai contoh dalam gambar 2.11 yang menunjukkan gambar skema bintang untuk property sales dan property advertising dengan time, PropertyForSale, Branch, dan Promotion yang disesuaikan dan ditandai dengan tulisan yang ditebalkan.

31 37 Gambar 2.11 Skema Bintang untuk property sales dan Property advertising d. Pemilihan Fakta Grain dari tabel fakta menentukan fakta mana yang bisa dipakai dalam data mart. Semua fakta harus dinyatakan secara pasti oleh grain. Dengan kata lain, jika grain dari tabel fakta merupakan indiviual property sale, maka semua fakta numeric harus menunjuk kepada bagian penjualan tertentu. Fakta juga harus numerik dan ditambah. Dalam gambar 2.12 digunakan skema bintang proses propery rental dari DreamHome untuk mengambarkan dengan jelas

32 38 struktur tabel fakta. Tabel fakta ini yang dapat digunakan untuk yang bukan numerik, yaitu PromotionName, dan StaffName. Beserta juga, fakta yang tak perlu ditambah lagi yaitu monthlyrent dan sebuah fakta yaitu lastyearrevenue pada granularity yang berbeda dari fakta pada tabel. Gambar 2.13 menunjukkan bagaimana tabel fakta lease ditunjukan pada gambar 2.12 bisa diperbaiki sehingga tabel fakta menjadi struktur yang baik. Tambahan fakta lainnya bisa ditambah ke dalam tabel fakta kapan saja selama fakta itu konsisten dengan grain dari tabel itu. Gambar 2.12 Skema bintang untuk property rental dengan masalah non-numeric dan non additive

33 39 Gambar 2.13 Skema bintang untuk property rental yang sudah diperbaiki e. Penyimpanan perhitungan data yang ada didalam tabel fakta Ketika semua fakta sudah ditentukan, maka fakta ini harus diperiksa kembali. Apakah fakta ini dapat dipakai atau tidak. Contoh umum fakta yang dipakai adalah kebutuhan sebuah toko ketika fakta yang ada dapat membandingkan laba dan rugi. Situasi ini dapat terjadi ketika tabel fakta berdasarkan invoice atau sales. Pada gambar 2.13 menunjukkan bahwa tabel fakta dengan atribut rentduration, totalrent, clientallowance, staffcommission, dan totalrevenue. Ini adalah tipe fakta yang berguna karena bisa menambah

34 40 jumlahnya, dari yang bisa mendapatkan informasi yang berguna seperti rata-rata clientallowance berdasarkan kumpulan beberapa fakta yang ada dalam tabel hasil. Untul menghitung totalrevenue perlu mengambil data clientallowance dan staffcommission dari totalrent. Meski pun totalrevenue bisa selalu diperoleh dari atribut ini, masih diperlukannya untuk menyimpan totalrevenue. Inilah dasar nilai yang benar untuk sebuah enterprise, seperti totalrevenue atau jika ada kemungkinan user salah memperhitungkan totalrevenue. Biaya yang salah direpresentasikan oleh user bisa dikecilkan dengan data storage. f. Mengumpulkan semua tabel dimensi Pada tahap ini, kita kembali ke dalam dimensi tabel dan menambah deskripsi yang sebanyak-banyaknya. Deskripsi harus jelas dan mudah dimengerti sehingga cukup jelas. Sebagai contoh, tabel-tabel dimensi yang telah diperiksa dan akan dipakai, dikumpulkan dan disusun kembali agar mudah dimengerti. g. Pemilihan Durasi Database Durasi dapat mengatur seberapa jauh tabel fakta ini dapat berlaku. Sebagian besar perusahaan, mempunyai kebutuhan untuk melihat data pada periode tertentu dalam jangka waktu satu atau dua tahun. Untuk tipe perusahaan lainnya, seperti asuransi. Mungkin membutuhkan data yang periodenya lebih lama yaitu sekitar lima atau lebih dari lima tahun. Ada 2 fakta yang besar yang dapat diambil dari design data warehouse. Pertama, Semakin tua suatu data semakin sulit unuk digunakan atau dibaca. Kedua, dimensi yang digunakan adalah dimensi yang lebih lama bukan yang saat ini. Masalah seperti ini dikenal

35 41 juga sebagai masalah Slowly Changing dimension yang akan dibahas lebih detail pada point berikutnya. h. Menelusuri Perlahan Perubahan Tabel Dimensi Yang dimaksud dengan masalah slowly changing dimension, contohnya adalah deskripsi yang jelas tentang klien dan cabang yang sudah lama harus dipakai dengan data transaksi yang lama. Data yang penting seperti ini harus dibuat kunci yang umum untuk menghilangkan snapshot yang ganda dari data klien dan cabang dalam periode tertentu. Ada tiga tipe dasar dari dimensi yang berubah secara perlahan, yang pertama ketika atribut dari dimensi ditulis kembali, yang kedua ketika terjadi perubahan dimensi menyebabkan adanya tabel dimensi baru yang dibuat, yang ketiga perubahan atribut dimensi menyebabkan atribut alternatif dibentuk sehingga baik nilai yang lama dan yang baru dapat di akses secara bersamaan pada tabel dimensi yang sama. i. Penentuan Prioritas dan Cara Query Dalam langkah ini, memperkirakan untuk membuat rancangan fisikal. Yang paling penting dalam rancangan fisikal yang memperngaruhi persepsi data mart end-user s adalah urutan dari perintah fisikal yang ada dalam tabel dan ketersediaan ringkasan. Dibalik semua ini ada tambahan rancangan fisikal yang mempengaruhi administration, backup, indexing performance, dan security. Pada langkah terakhir dalam metodologi ini, harus merancang data mart yang mendukung kebutuhan bisnis proses dan juga mempermudah dalam

36 42 integrasi dengan lain yang terkait dengan data mart untuk data warehouse sebuah perusahaan. Tabel 2.1 menggambarkan daftar dari tabel fakta dan dimensi yang berhubungan dengan skema bintang dari proses bisnis DreamHome. Sebagai contoh, semua tabel yang terhubung dengan dimensi time dan branch. Yang ditunjukan pada tabel 2.1. Model dimensional, yang mengandung lebih dari satu tabel fakta dibagi atau disesuaikan setiap tabel dimensinya yang dikenal dengan istilah fact constellation yang digambarkan pada gambar Gambar 2.14 Model Dimensional untuk Data Warehouse DreamHome

37 43 Gambar ini sudah disederhanakan dengan menunjukkan nama dari tabelnya saja. Tabel fakta di tandai dengan ditebalkan. Tabel 2.1 Tabel Fakta dan dimensi untuk setiap bisnis proses dalam DreamHome Proses Bisnis Tabel Fakta Tabel Dimensi Property Sales Property Sale Time,Branch,staff,PropertyForSale,Owner,ClientBuyer, Promotion Property Rental Lease Time,Branch,staff,PropertyForRent,Owner,ClientRenter, Promotion Property Viewing Property Viewing Time,Branch,PropertyForSale,PropertyForRenter, ClientBuyer, ClientRenter Property Advertising Advert Time,Branch,PropertyForSale,PropertyForRenter, Promotion, Newspaper Property Maintenance Property Maintenance Time, Branch, staff, PropertyForRent Model Dimensional Model dimensional merupakan sebuah perancangan logikal yang bertujuan untuk menampilkan data dalam bentuk standard dan intuitif yang memperbolehkan akses dengan performa yang tinggi. Model dimensional menggunakan konsep model hubungan antar entiti (ER) dengan beberapa batasan yang penting, Setiap model dimensi terdiri dari sebuah tabel dengan sebuah komposit primary key, disebut dengan tabel fakta, dan satu set tabel yang lebih kecil disebut tabel dimensi. Setiap tabel dimensi memiliki sebuah simple primary key yang merespon tepat pada satu komponen composite key di tabel fakta. Dengan kata lain, primary key dari sebuah tabel fakta terdiri atas 2 (dua) atau lebih foreign key. Struktur karakteristik ini disebut dengan skema bintang atau join bintang.

38 44 Model dimensional harus cocok dengan keperluan dari user dan mendukung user untuk akses secara langsung. Selain itu juga modelnya didesain sedemikian rupa sehingga mudah untuk di-maintain dan dapat beradaptasi dengan perubahan mendatang. Fitur penting lainnya dari sebuah model dimensional adalah semua natural keys diganti dengan kunci pengganti (surrogate keys). Ini berarti bahwa setiap kali join antara tabel fakta dengan tabel dimensi selalu didasari oleh kunci pengganti, bukan natural keys. Kegunaan dari kunci pengganti ini adalah memperbolehkan data pada data warehouse untuk memiliki beberapa kebebasan dalam penggunaan data tidak seperti halnya yang diproduksi oleh sistem OLTP. Sebuah sistem OLTP memerlukan struktur yang telah dinormalisasi untuk mengurangi redudansi, validasi untuk input data, mendukung volume yang besar dari transaksi yang bergerak sangat cepat. Sebuah transaksi biasanya melibatkan sebuah proses bisnis, seperti mencatat order atau mencetak pembayaran invoice. Model OLTP sering terlibat seperti jaring laba-laba yang terdiri atas ratusan, bahkan ribuan tabel, sehingga sulit untuk dimengerti. Sebaliknya, model dimensional yang sering digunakan adalah desain bintang (star) atau snowflake yang mudah untuk dimengerti dan sesuai dengan kebutuhan bisnis, mendukung query sederhana dari bisnis, dan menyediakan performa query yang superior dengan meminimalisasi tabeltabel join. Sebagai contoh perbandingan contoh diagram dari model data OLTP yang sederhana dengan data warehouse dimensional model.

39 45 Gambar 2.15 Model data OLTP Gambar 2.16 Model Dimensional

40 Skema Bintang / Star Schema Pengertian Skema Bintang Menurut Connolly (2002, p1079), skema bintang adalah struktur logikal yang mempunyai sebuah table fakta yang berisi data fakta di tengah dan dikelilingi oleh table-tabel dimensi yang berisi data referensi atau keterangan yang biasanya dapat denormalisasi. Menurut Inmon (2005, p128), skema bintang adalah struktur desain yang dibutuhkan untuk mengatur data dengan cara denormalisasi dalam jumlah yang besar ke dalam sebuah entity dalam sebuah data mart untuk mengoptimalkan akses data. Kesimpulannya, Skema bintang adalah suatu stuktur logikal yang mempunyai suatu tabel fakta yang dikelilingi oleh tabel-tabel dimensi yang biasanya melalui proses denormalisasi Contoh skema bintang dapat dilihat pada gambar 2.8, skema bintang mendukung query yang dibutuhkan untuk mengakses penjualan properti Glasgow dengan menggunakan tabel fakta, yaitu PropertySale dan tabel dimensi, yaitu dimensi Time, Branch, Promotion, Owner, PropertyForSale, ClientBuyer, dan Staff.

41 47 Dimension Tables PK PK Time tim eid day w eek month year Branch branchid branchno branchtype city region country Promotion Fact Table PropertySale timeid {FK} propertyid{fk} branchid {FK} clientid {FK} promotionid{fk} staffid{fk} ownerid{fk} offerprice sellingprice salecommission salerevenue Ow ner Dimension Tables PropertyForSale PK PK propertyid propertyno type street city postcode region country ClientBuyer clientid clientno clientname clienttype city region country PK promotionid PK ownerid promotionno promotionname promotiontype ow nerno ow nername ow nertype city region country Dimension Table PK Staff staffid staffno staffname position sex city region country Gambar 2.17 Contoh star schema Sales Property in Glassgow (Connolly, p1080) Perancangan Data Warehouse dengan Skema Bintang Tujuan dari dukungan pengambilan keputusan sering dicapai dengan perancangan database yang dikenal dengan skema bintang. Didalam desain database yang biasa umumnya terdapat hubungan many to many antara relasi entity, dan melakukan penggabungan (join) antar tabel untuk mendapatkan laporan yang sederhana. Hal inilah yang terkadang membuat para pengguna frustasi dalam melakukan query.

42 Keuntungan Menggunakan Skema Bintang Skema bintang memiliki keuntungan yang tidak didapat oleh skema relasional biasa. Keuntungan skema bintang, antara lain: o Respon data yang lebih cepat dihasilkan dari perancangan database. o Kemudahan dalam mengembangkan atau memodifikasi data yang terus berubah. o End user dapat menyesuaikan cara berpikir dan menggunakan data, konsep ini dikenal juga dengan istilah pararel dalam perancangan database. o Menyederhanakan pemahaman dan penelusuran metadata bagi pemakai dan pengembang Perancangan Skema Bintang Skema bintang memiliki dua macam tabel, yaitu; 1. Tabel Fakta (Fact Table) Tabel fakta sering juga disebut tabel major. Tabel ini merupakan inti dari skema bintang dan berisi data actual yang akan dianalisis (data kuantitatif dan transaksi). Filed-field tabel fakta sering disebut measure dan biasanya dalam bentuk numeric. Selalu berisi foreign key dari masing-masing tabel dimensi. Tabel ini dapat terdiri dari banyak kolom dan ribuan baris data.

43 49 2. Tabel Dimensi (Dimension Table) Sering juga disebut tabel minor. Tabel dimensi biasanya lebih kecil dan berisi data yang merupakan deskripsi lanjutan dari data pada tabel fakta Ketentuan Pembacaan Skema Bintang Adapun ketentuan pembacaan skema bintang adalah sebagai berikut: o Bagian yang ada di bawah tabel adalah kolom-kolom dari tabel. o Primary key dan foreign key diberi kotak. o Primary key diarsir, sedangkan foreign key yang bukan primary key tidak o Foreign key yang berhubungan ditunjukan dengan garis yang menghubungkan tabel-tabel. o Kolom yang bukan primary key atau foreign key disebut kolom data pada tabel fakta dan atribut pada tabel dimensi.

44 Jenis-Jenis Skema Bintang Ada beberapa macam jenis skema bintang, yaitu: 1. Simple Star Schema Dalam skema ini, setiap tabel harus memiliki primary key yang terdiri dari satu kolom atau lebih dan primary key tersebut harus bersifat unik. Foreign key adalah kolom pada satu tabel yang nilainya didefinisikan oleh primary key pada tabel lain. Gambar 2.18 Simple Star Schema (Poe, 1996, p124)

45 51 2. Multiple Fact Star Schema Skema bintang dapat memiliki lebih dari satu tabel fakta, karena adanya fakta yang tidak saling berhubungan. Misalnya di samping penjualan, terdapat tabel fakta forecasting dan tabel fakta result. Walaupun terdapat banyak tabel fakta, tabel dimensinya tetap digunakan bersama-sama. Gambar 2.19 Multiple Fact Star Schema (Poe, 1996, p126)

46 Variasi Skema Bintang Variasi-variasi yang ada pada skema bintang, yaitu : 1. Skema Snowflake Snowflake merupakan variasi lain dari skema bintang di mana tabel dimensi dari skema bintang tidak mengandung atau berisi data yang didenormalisasi. Prinsip dasar dari skema ini tidak jauh berbeda dari skema bintang. Penggunaan tabel dimensi sangatlah menonjol, karena itulah perbedaan mendasar dari skema bintang dan skema snowflake. Skema snowflake menggunakan beberapa tabel fakta dan tabel dimensi yang sudah mengalami normalisasi, sedangkan skema bintang menggunakan tabel dimensi yang masih denormalisasi. Skema snowflake dibuat berdasarkan OLTP sehingga semua data akan termuat detail dalam setiap tabel fakta dan tabel dimensi. Keuntungan dari skema snowflake adalah kecepatan memindahkan data dari data OLTP ke dalam metadata, sebagai kebutuhan dari alat pengambil keputusan tingkat tinggi di mana dengan tipe seperti ini seluruh struktur dapat digunakan sepenuhnya, dan banyak yang beranggapan lebih nyaman merancang dalam normal ketiga. Kerugian yang didapat adalah memiliki masalah besar dalam hal kinerja (performance), hal ini disebabkan semakin banyaknya join antar tabel-tabel yang dilakukan dalam skema snowflake ini maka semakin lambat kinerja yang dilakukan. Sebuah skema bintang yang menyediakan atribut yang lengkap, konsisten, dan mudah dimengerti memungkinkan bagi pemakai untuk

47 53 memperoleh penampilan data yang mudah digunakan dan mudah dimengerti. Perancangan skema bintang yang baik membantu pemakai untuk menulis pencarian yang diinginkan dengan cara yang dimengerti Estimasi Disk Ada beberapa langkah yang diperlukan dalam menghitung kapasitas disk: 1. Menentukan jumlah baris di dalam tabel (num_rows). 2. Ukuran tergantung pada tipe data dan panjangnya. o Jumlah kolom (num_cols). o Jumlah fixed length column (byte) (fixed_datasize). o Jumlah variable length column (Num_variable_cols). o Ukuran maksimal variable length column (max_var_size). 3. Menghitung null bitmap jika dalam tabel terdapat fixed length Column. Null bitmap (null_bitmap) = 2 + ((Num_cols+7):8) 4. Menghitung kapasitas jika terdapat variable length column dalam tabel. Total size of variable length columns (variable_data_size) = 2+(num_variable_cols x 2) + max_var_size 5. Menghitung ukuran baris. Total row size(row_size)=fixed_data_size + variable_data_size + Nullbitmap+4 6. Menghitung jumlah baris per halaman (8096 byte per page). Numbers of rows per page (Rows_per_page) = 8096 : (row_size + 2) 7. Jika terdapat clustered index didalam tabel, maka menghitung free rows per page didasarkan pada fill factor. Jika tidak ada clustered index yang dibuat, maka fill factor diasumsikan sebagai 100.

48 54 Number of free row per page(free_rows_per_page) = 8096 x ((100 fill factor) : 100) : (row_size+2) 8. Menghitung jumlah halaman yang dibutuhkan untuk menyimpan semua baris. Number of pages (num_pages)= num_rows : (rows_per_page free_rows_per_page) 9. Menghitung kapasitas yang dibutuhkan untuk menyimpan data dalam tabel (8192 byte per pages). Tabel size (bytes) = 8192 x num_pages Menghitung ukuran tabel dengan index Berikut ini cara yang digunakan untuk menghitung tabel yang di dalamnya terdapat index: 1. Menghitung kapasitas yang digunakan untuk menyimpan data. 2. Menghitung kapasitas yang digunakan untuk menyimpan index clustered. 3. Menghitung kapasitas yang digunakan untuk menyimpan index nonclustered. 4. Menghitung nilai-nilai yang telah dihitung diatas. Pada setiap perhitungan selalu mencantumkan jumlah baris yang akan ada di dalam tabel. Number of rows in the table = num_rows Menghitung kapasitas yang digunakan untuk menyimpan data: - space used to store data = data_spaced_used

49 55 Menghitung kapasitas yang digunakan untuk menyimpan index: 1. Definisi dari index dapat berupa fixed length dan variable length column. Jumlah kolom dalam index key (num_key_cols). Jumlah semua fixed length column key (byte) (fixed_key_size). Jumlah variable length column dalam index key (num_variable_key_cols). Ukuran maksimum dari variable length column key (max_var_key_size). 2. Index Null Bitmap (Index_Null_bitmap) = 2+((Num_key_cols + 7): 8) 3. Jika terdapat variable length column dalam index, maka dihitung berapa kapasitas yang digunakan untuk menyimpan kolom dalam baris index. Total size of variable lenght columns (variable_key_size) = 2+(num_variable_key_cols x 2) + max_var_key_size 4. Menghitung ukuran baris index. Total index row size (Index_row_size) = fixed_key_size + variable_key_size + index_null_bitmap Menghitung jumlah baris per halaman (8096 byte per page). Number of index rows per page (Index_rows_per_page) = 8096 : (index_row_size + 2) 6. Menghitung jumlah halaman yang dibutuhkan untuk menyimpan semua baris index pada setiap level dari index. Number of pages (level 0) (num_pages_level_0) = (data_space_used : 8192) : index_rows_per_page Number of pages (level 1) (num_pages_level_0) = num_pages_level_0 : index_rows_per_page

50 56 Perhitungan terus dilakukan sampai level n (num_pages_level_n) sama dengan satu (index root page). Menghitung jumlah halaman yang dibutuhkan untuk menyimpan setiap level dari index. Total number of pages (num_index_pages) = num_pages_level_0 + num_pages_level_ num_pages_level_n 7. Menghitung ukuran index (8192 byte per page) index size (bytes) = 8192 x num_index_pages Menghitung ukuran tabel. Total tabel size (bytes) = data_space_used + clustered_index_size + nonclustered_index_size +...n Menghitung pertumbuhan setiap tahun selama lima tahun. 1. Menghitung master Rn = R (n-1) * (1 + i ) n R = Jumlah record n = Tahun i = Persentase Pertumbuhan data, sebesar 10% 2. Menghitung Transaksi Rn = R (n-1) + R (n-1) * (1 + i ) R = Jumlah record n = Tahun i = Persentase Pertumbuhan data, sebesar 10%