Model data warehouse untuk Operasional petugas pemadam kebakaran Pada dinas pemadam kebakaran provinsi DKI Jakarta

Jurnal Ilmu Komputer VOL. XII No. 1

p-ISSN: 1979-5661

e-ISSN: 2622-321X

Model Data Warehouse untuk Operasional Petugas Pemadam Kebakaran pada Dinas Pemadam Kebakaran Provinsi DKI Jakarta

Kharis Munawar¹, Harco Leslie Hendric Spits Warnars²

¹Computer Systems Department, STMIK Raharja

Jl. Jenderal Sudirman, Babakan, Kec. Tangerang, Kota Tangerang, Banten, Indonesia 15117 [email protected]

²Computer Science Department, BINUS Graduate Program - Doctor of Computer Science, Bina Nusantara university

Jl. Kebon Jeruk Raya No. 27, Kebon Jeruk Jakarta, Indonesia 11480 [email protected]

Abstract

In this paper we design 2 data warehouse design models for the DKI Jakarta fire department. The first data warehouse design model is categorized as a fact constellation schema, where there are 3 fact tables, 2 dimensional tables and 1 sub dimension table, while the second data warehouse design model is a fact constellation schema which consists of only 3 fact tables as well. Both of these data warehouse models are displayed with the intention that the implementation of the data warehouse based on the fire extinguisher data will look different and that will certainly be faster by using the 2nd model which is categorized as an non normal data warehouse model which only consists of 3 fact tables which the lack of a join process in the fact table and the dimensions of the data warehouse will speed up the query process in building the data warehouse report. The design model of the data warehouse is designed based on 4 excel table files, each of which has 1 table downloaded from the DKI Jakarta fire department's website on the website data.jakarta.go.id.

Keywords: Firefighter Data Warehouse, fact constellation Data Warehouse, non Normal data warehouse, Fire department Data Warehouse.

Abstrak

Pada paper ini kami mendesain 2 buah model desain data warehouse untuk dinas pemadam kebakaran DKI Jakarta. Model desain data warehouse yang pertama dikategorikan sebagai fact constellation schema, dimana terdapat 3 fact tabel, 2 dimensi tabel dan 1 sub dimensi tabel, sementara model desain data warehouse yang ke-2 adalah fact constellation schema yang hanya terdiri dari hanya 3 tabel fakta. Kedua model data warehouse ini ditampilkan dengan maksud agar penerapan data warehouse berdasarkan data pemadam kebakaran ini akan terlihat bedanya dan yang pasti akan lebih cepat dengan menggunakan model ke-2 yang dikategorikan sebagai model data warehouse yang tidak normal dimana hanya terdiri dari 3 tabel fakta yang mana kurangnya proses join pada tabel fakta dan dimensi pada data warehouse akan mempercepat proses query dalam membangun laporan data warehouse. Model desain data warehouse tersebut didesain berdasarkan 4 table file excell yang masing-masing memiliki 1 table yang diunduh dari website dinas pemadam kebakaran DKI Jakarta pada website data.jakarta.go.id.

Kata Kunci - Data Warehouse Pemadam Kebakaran, Data Warehouse fact constellation, data warehouse tidak normal, data warehouse departemen pemadam kebakaran

• 1.    Pendahuluan

Salah satu ujung tombak dalam menciptakan keamanan, kenyamanan dan ketentraman bagi masyarakat provinsi DKI Jakarta adalah Dinas pemadam kebakaran yang mampu bekerja secara maksimal, sehingga tingginya tingkat kebakaran dalam beberapa tahun terakhir bisa ditekan. Untuk dapat mewujudkan ini perlu dilakukan pencatatan secara baik agar informasinya dapat dimanfaatkan oleh dinas-dinas terkait yang dapat dimanfaatkan untuk pengaturan tata ruang kota yang dilakukan oleh dinas perizinan, serta pembuatan jalan utama, jalan perumahan, jalan perkampungan oleh dinas pekerjaan umum. Serta penentuan jumlah hidran sesui kebutuhan banyaknya kendaraan operasional dinas pemadam kebakaran.

Selama ini proses pencatatan kejadian oleh dinas pemadam kebakaran dilakukan secara manual dimana informasinya dilakukan dalam bentuk tabel sehingga tidak menggambarkan dengan jelas kelompok informasinya masing-masing, sehingga data yang tercatat tidak mampu memberi informasi dengan cepat serta belum mampu memberikan informasi yang dapat membantu proses pengambilan keputusan. Sistem Informasi adalah pengaturan orang, data, proses dan teknologi informasi yang saling berinteraksi untuk mengumpulkan, memproses, menyimpan dan menyediakan data sebagai sebuah informasi/keluaran yang dibutuhkan untuk mendukung kegiatan sebuah organisasi [4]. Sistem informasi didalam sebuah organisasi bertugas untuk menangkap dan mengelola data untuk menghasilkan informasi yang berguna dan efektif yang mendukung kegiatan organisasi dan seluruh level manajemen yang menggunakan. Sistem informasi akan membutuhkan dukungan teknologi informasi seperti mana yang biasanya sudah lasim bahwa sistem information tidak akan berarti apa-apa tanpa adanya dukungan teknologi informasi[5]. Sehingga dengan adanya dukungan teknologi informasi yang memadai akan membantu dalam proses pengambilan keputusan yang cepat dan tepat.

Dinas provinsi DKI Jakarta memiliki sumber data yang begitu besar yang mana data tersebut dapat diolah menjadi sesuatu yang berguna, data-data yang dimiki tersebut dapat menjadi lebih efesian dengan adanya data warehouse, sehingga mampu membantu dalam proses pengambilan keputusan. Data warehouse bukanlah perangkat keras baru atau perangkat lunak baru namun lingkungan komputer agar bisa menggunakan database agar informasi strategis menjadi lebih cepat dan dapat diandalkan. Data warehouse dibuat oleh proses ETL (Extraction Transformation Loading) yang mendapatkan data dari TPS (Transactional Processing System) atau OLTP (OnLine Transactional Processing)[1,13,14]. Data Warehouse merupakan kelanjutan dari konsep normalisasi model database yang meng- gunakan model database normal untuk penerapan proses transaksi harian yang bebas dari pengulangan data dan mempunyai banyak tabel database[11,15,16].

Sedangkan data warehouse merubah model database normal menjadi tidak normal yang menyebabkan terjadinya pengulangan data dan berkurangnya jumlah tabel database yang pada akhirnya akan meningkatkan performa aplikasi teknologi komputer [6,17,18]. Tujuan membangun data warehouse adalah menyediakan sistem yang memungkinkan data yang tepat menjangkau pengguna akhir yang tepat pada waktu yang tepat. Dengan demikian, tujuan utama penerapan sistem data warehouse ini adalah untuk menyediakan informasi yang relevan dan tepat waktu kepada tingkat manajeman atas dalam format yang mudah dipahami sehingga keputusan layanan kepada masyarakat dapat dibuat secara lebih efisien dan efektif [19,20].

Ungkapan "data warehousing" tidak hanya menunjukkan alat yang efisien untuk integrasi data, namun juga menyiratkan format terwujud dari alat manajemen real-time yang divisualisasikan, mencakup rancangan, rehabilitasi dan perbaikan proyek[2,21,22]. Jadi Data warehouse merupakan lingkungan komputer yang dapat mengumpulkan informasi dari berbagai sumber ke database tunggal. Hal ini memungkinkan pengguna untuk mengajukan pertanyaan dalam lingkungan tunggal dan tanpa mempedulikan integrasi skema[3]. Dengan kata lain Data warehouse adalah database itu sendiri tapi dalam bentuk lain yang lebih kekar dan perkasa [7]. Ada 3 jenis model skema data warehouse yang dapat dibangun yaitu :

• a)    Skema Bintang

Skema bintang adalah struktur logikal yang mempunyai sebuah tabel fakta berisi data faktual yang ditempatkan di tengah, dikelilingi oleh tabel dimensi berisi data referensi (yang

dapat didenormalisasi). Skema bintang mengeksploitasi karakteristik dari data faktual di mana fakta dibuat dari peristiwa yang muncul di masa lalu dan mustahil untuk berubah, dengan mengabaikan bagaimana mereka dianalisis. Karena sebagian besar data dalam data warehouse ditampilkan sebagai fakta, table fakta relatif sangat berhubungan dengan table dimensi. Karena itu, penting untuk memperlakukan data fakta sebagai data referensi yang hanya dapat dibaca (read only reference data), yang tidak akan berubah sepanjang waktu. Tabel fakta yang paling berguna berisi satu atau lebih ukuran numerik, atau ’fakta’, yang terjadi [8].

• b)    Skema Snowflake

Skema Snowflake tersusun dari tabel fakta yang berjumlah lebih dari satu dan dapat dikombinasikan dengan satu atau lebih tabel dimensi ataupun lebih dari satu tabel sub dimensi. Sebuah skema data warehouse dikategorikan sebagai skema snowflake ketika ada sebuah tabel sub dimensi termasuk bagian tabel sub dimensi berikutnya [9].

• c)    Skema Fact Constellation

Fact Constellation schema adalah skema multi dimensional yang berisikan lebih dari satu tabel fakta yang saling berbagi tabel dimensi. Jenis skema ini dapat dilihat sebagai gabungan dari berbagai skema bintang sehingga sering juga disebut dengan nama skema galaksi [10,23,24].

• 2.    Penelitian sebelumnya yang berhubungan dengan Dinas Kebakaran

Pada tulisan yang berjudul “smart communication and relative localization system for firefighters and rescuers” menyajikan sistem komunikasi cerdas untuk penerimaan data simultan dan arah perkiraan kedatangan untuk petugas pemadam kebakaran, penyelamat, dan personil darurat lainnya. Sistem ini terdiri dari enam-port microwave interferometer pasif yang mengubah tantangan pengukuran fase akurat untuk estimasi arah ke pengukuran daya relatif. Hal ini dapat dengan mudah direalisasikan dengan pembacaan indikator kekuatan sinyal yang diterima dari transceiver komersial off-the-shelf murah yang secara bersamaan digunakan untuk komunikasi. Karena struktur IQ diferensial, kekokohan sistem ditingkatkan, bahkan untuk gangguan dan interferensi yang parah, di mana ia masih dapat memberikan sudut relatif anggota tim darurat satu sama lain[12].

Sementara pada tulisan yang berjudul “wildland fire and weather information data warehouse” berbicara tentang layanan Hutan USDA menyimpan data kejadian kebakaran dalam basis data relasional untuk perencanaan, analisis, dan tujuan lainnya. Pengamatan cuaca disimpan dalam database yang sama untuk semua lima lembaga pengelolaan lahan federal dan beberapa lembaga lahan liar negara bagian. Akses yang siap menghadapi kebakaran dan data cuaca memungkinkan manajer, perencana, dan personel operasi untuk membuat keputusan berdasarkan masa lalu dan proyeksi ke masa depan. Presentasi ini membahas filosofi desain di balik database, masalah yang berhubungan dengan perawatan dan pemberian makan dari database dan data yang tersimpan di sana, dan bagaimana data membantu pengguna lapangan.

• 3.    User Requirement Data Warehouse Pada Dinas Pemadam Kebakaran DKI Jakarta

Berdasarkan survey paper mengenai penerapan data warehouse pada Dinas kebakaran di Indonesia ditemui belum ada yang melakukan desain dan implementasi. Oleh karena itu kami mengusulkan sebuah model desain data warehouse pada dinas pemadam kebakaran DKI Jakarta, dimana data-data mengenai dinas kebakaran DKI Jakarta diambil pada website data.jakarta.go.id. Ada banyak data berupa file Microsoft Excel pada website data.jakarta.go.id yang berkenaan dengan data-data dinas pemadam kebakaran DKI Jakarta, dan kami hanya batasi hanya pada 4 file Excell yang terupdate yaitu data-data tahun 2014. Adapun 4 file excell yang didownload adalah:

a) Data-kode-kendaraan-Dan–Pos-Pemadam-Kebakaran-DKI-Jakarta-2014.xls.

Pada file excell ini terdapat 169 baris record data yang terdiri dari terdiri 11 kolom yang terdiri dari kolom: sektor, pos_pemadam, alamat, RT, RW, kelurahan, kecamatan, nomor_polisi, nomor_body, keterangan, no_tlp. Gambar 1 yang memperlihatkan contoh penggalan data file Excell tersebut.

Gambar 1. Data Kode Kendaraan dan pos pemadam

b)  Data-Monitoring-Hydrant-Di-DKI-Jakarta-Tahun-2014.xls.

Pada file excell ini terdapat 860 baris record data yang terdiri dari terdiri 8 kolom yang terdiri dari kolom: sektor, kelurahan, kecamatan, wilyah_kota, alamat, latitude, longitude, Keterangan. Gambar 2 yang memperlihatkan contoh penggalan data file Excell tersebut. Gambar 2 yang memperlihatkan contoh penggalan data file Excell tersebut.

Gambir	Jakarta		Pusat	Jl. Ternate Huk/ JI. Biak
Gambir		Jakarta	Pusat	Jl. Sangau
Gambir		Jakarta	Pusat	∣J∣. Citarum
Gambir		Jakarta	Pusat	Jl. Belawan Huk/Jl. Siantar
Gambir		Jakarta	Pusat	Jl. Tanah Abang V Huk Abdul Muis
Gambir		Jakarta	Pusat	Jl. Musi Huk ∕ Jl. Batang Hari
Gambir		Jakarta	Pusat	Gor Kmakmuran, JI. Hasyim Ashari
Gambir		Jakarta	Pusat	Golden truly, JI. Suryo Pranoto
Gambir		Jakarta	Pusat	Bank Royal, JI. AM. Sangaji
Gambir		Jakarta	Pusat	Pasar Petojo, JI. AM.Sangaji
Gambir		Jakarta	Pusat	Gereja Imanuel, Jl. Ridwan Rais
Gambir		Jakarta	Pusat	Patung Tani, Jl. Ridwan Rais Huk
Gambir		Jakarta	Pusat	Halte Bus, JI. Pejambon
Tanah Abar	Ig	Jakarta	Pusat	Dep. BCA, Jl. Wahid Hasyim
Tanah Abar	Ig	Jakarta	Pusat	Jl. Wahid Hasyim Huk, M-HusniThamrin
Tanah Abar	Ig	Jakarta	Pusat	JI. Kebon Kacang Xl Huk Xlll
Tanah Abar	Ig	Jakarta	Pusat	SD. Sport, JI. Kebon Kacang Raya
Tanah Abar	Ig	Jakarta	Pusat	Kantor Lurah, JI. KH. Mas Mansyur
Tanah Abar	Ig	Jakarta	Pusat	Kantor Camat, JI. KH. Mas Mansyur
Tanah Abar	Ig	Jakarta	Pusat	JI. Plaju, HUK ∕ Jl. Tanjung Karang

Gambar 2. Data Monitoring Hydrant DKI Jakarta

c) Data-Pos-Sektor-Pemadam-Kebakaran-DKI-Jakarta-Tahun-2014.xls

Pada file excell ini terdapat 281 baris record data yang terdiri dari terdiri 21 kolom yang terdiri dari kolom: kode, kode_wilayah, wilayah, sektor, nama_sektor, kecamatan, kelurahan, nama_bangunan, jumlah, peruntukan, status, alamat, kode_pos, no_telp, tahun_pembangunan, luas_tanah(m2), luas_bangunan(m2), tahun_rehab_terakhir, nilai_rehab_ta_tahun_2008, rincian_rehab/bangunan, keterangan. Gambar 3 yang memperlihatkan contoh penggalan data file Excell tersebut.

Gambar 3. Data Pos Sektor Pemadam Kebakaran

d) Data-Wilayah-Pemadam-Kebakaran-DKI-Jakarta-Tahun-2014.xls

Pada file excell ini terdapat 278 baris record data yang terdiri dari terdiri 11 kolom yang terdiri dari kolom: kelurahan, kode, wilayah, sudin, kecamatan, sektor, nama_sektor, kode_pos, nama_kasie_Sektor, nip/nik, jabatan. Gambar 4 yang memperlihatkan contoh penggalan data file Excell tersebut.

	A	B	C	D	E	E
	kelurahan	kode	wi laya∣^	sudin	kecamatan	sektor	nama sektor
2	Duri Pulo	1.11 1	1 O	Kota Administrasi Jakarta Pusat	Gambir	1 O	Sektor Gambir
3	Cidene	1.11.2	1.0	Kota Administrasi Jakarta Pusat	Gambir	1.0	Sektor Gambir
4	Gambir	1.11.3	1.0	Kota Administrasi Jakarta Pusat	Gambir	1.0	Sektor Gambir
5	Kebon Kelapa	1.11 4	10	Kota Administrasi Jakarta Pusat	Gambir	1 O	Sektor Gambir
6	Petojo Utara	1.11.5	1.0	Kota Administrasi Jakarta Pusat	Gambir	10	Sektor Gambir
7	Petojo Selatan	1.11.6	1.0	Kota Administrasi Jakarta Pusat	Gambir	1.0	Sektor Gambir
B	Kampung Bali	112 1	10	Kota Administrasi Jakarta Pusat	Tanah Abang	2 O	Sektor Tanah Abang
9	Kebon Melati	1.12.2	1.0	Kota Administrasi Jakarta Pusat	Tanah Abang	2.0	Sektor Tanah Abang
IO	Kebon Kacang	1.12.3	1.0	Kota Administrasi Jakarta Pusat	Tanah Abang	2.0	Sektor Tanah Abang
11	Bendungan Hilir	1.12.4	1.0	Kota Administrasi Jakarta Pusat	Tanah Abang	2.0	Sektor Tanah Abang
12	Gelora	1.12.5	1.0	Kota Administrasi Jakarta Pusat	Tanah Abang	2.0	Sektor Tanah Abang
13	Karet Tengsin	1.12.6	1.0	Kota Administrasi Jakarta Pusat	Tanah Abang	2.0	Sektor Tanah Abang
14	Petamburan	1.12.7	1.0	Kota Administrasi Jakarta Pusat	Tanah Abang	2.0	Sektor Tanah Abang
15	Menteng	1.13.1	10	Kota Administrasi Jakarta Pusat	Menteng	3 0	Sektor Menteng
16	Pegangsaan	1.13.2	1.0	Kota Administrasi Jakarta Pusat	Menteng	3.0	Sektor Menteng
17	Cikini	1.13.3	1.0	Kota Administrasi Jakarta Pusat	Menteng	3.0	Sektor Menteng
18	Gondangdia	113 4	10	Kota Administrasi Jakarta Pusat	Menteng	3 0	Sektor Menteng
19	Kebon Sirih	1.13.5	1.0	Kota Administrasi Jakarta Pusat	Menteng	3.0	Sektor Menteng
20	Johar Baru	1.14.1	1.0	Kota Administrasi Jakarta Pusat	Johar Baru	4.0	SektorJohar Baru
21	Kampung Rawa	1 14 2	10	Kota Administrasi Jakarta Pusat	Johar Baru	4.0	Sektor Johar Baru
22	Galur	1.14.3	1.0	Kota Administrasi Jakarta Pusat	Johar Baru	4.0	SektorJohar Baru
23	Tanah Tinggi	1.14.4	1.0	Kota Administrasi Jakarta Pusat	Johar Baru	4.0	SektorJohar Baru
24	Rawasari	115 1	10	Kota Administrasi Jakarta Pusat	Cempaka Putih	5 0	Sektor Cempaka Putih
25	Cempaka PutihTimur	1.15.2	1.0	Kota Administrasi Jakarta Pusat	Cempaka Putih	5.0	SektorCempaka Putih
26	Cempaka Putih Barat	1.15.3	1.0	Kota Administrasi Jakarta Pusat	Cempaka Putih	5.0	SektorCempaka Putih
27	Gunung Sahari Selatan	1.16.1	1.0	Kota Administrasi Jakarta Pusat	Kemayoran	6.0	Sektor Kemayoran
28	Kemavoran	1.16.2	1.0	Kota Administrasi Jakarta Pusat	Kemayoran	6.0	Sektor Kemayoran
29	Kebon Kosong	1.16.3	1.0	Kota Administrasi Jakarta Pusat	Kemayoran	6.0	Sektor Kemayoran
30	Serdang	1.16.4	1.0	Kota Administrasi Jakarta Pusat	Kemayoran	6.0	Sektor Kemayoran
31	Harapan Mulia	116 5	10	Kota Administrasi Jakarta Pusat	Kemayoran	6 0	Sektor Kemayoran
3	J. Irnn P^ r» in r» o	1 TR R	i n		Ifpmaunran	A n

Gambar 4. Data Wilayah Pemadam Kebakaran

Dikarenakan data-data tersebut diambil langsung dari website dinas pemadam kebakaran DKI Jakarta, maka tidak terdapat desain OLTP (Online Transactional Processing) atau TPS (Transactional Processing System) yang biasanya digunakan untuk pembacaan data-data yang akan dipindahkan ke data warehouse. Sehingga model Data Warehouse yang dibangun akan dibentuk berdasarkan data-data file excell yang ada, sehingga data-data file excell yang ada tersebut akan dientry secara manual ke data warehouse dan selanjutnya berdasarkan data warehouse tersebut maka akan ada beberapa peluang laporan-laporan yang dapat dihasilkan guna kebutuhan untuk mendukung sistem pengambilan keputusan pada instansi dinas kebakaran DKI Jakarta.

• 4.    Model Desain Data Warehouse Pada Dinas Pemadam Kebakaran DKI Jakarta

  (F) Hidrant	1 ■ 1	(D/SDI Kota	i
  *id.hidrant(PK) Sektor Alamat latitude Longitude Keterangan Id kota (FK)		*id.kota(PK) Kota Kelurahan Kecamatan
  		1

  (D) PosPemadam

  
  

  (F) Kendaraan

  
  
  

(F) PosSektor

’Kode. WiIayah(PK) Nama-Wilayah Sektor Nama.Sektor Nama-Bangunan Perumahan

Status Alamat Kode_pos Notelp Thn-Pembangunan LuaS-Tanah LuaS-Bangunan Thn.Rehab Nilai-Rehab Rincian-Rehab Keterangan Id-Kota(FK) Id-Kasie(FK)

1

ID) Kasie

^tId-Kasie(PK) Nama.Kasie Nip/Nik Jabatan

Gambar 5. Fact Constellation model data warehouse pertama

Berdasarkan analisa dari 4 tabel excell yang diunduh dari website dinas pemadam kebakaran DKI Jakarta, maka sebuah data warehouse dimodelkan pada gambar 5 dibawah ini dimana (D) atau (SD) sebagai tanda tabel Dimensi atau SD=Sub Dimensi :

Model data warehouse diatas dikategorikan sebagai skema fact constellation dimana ada lebih dari Satu fakta tabel berbagi tabel dimensi atau table sub dimensi. Dalam hal ini sesuai yang terlihat pada gambar 5 terdapat 3 fakta table yaitu tabel kendaraan, hidrant dan pos_sektor. Selain itu terdapat 2 tabel dimensi yaitu table posPemadam dan kasie, serta 1 table sub

dimensi yaitu table kota. Yang menarik dari model data warehouse diatas, tabel kota mempunyai 2 perilaku yaitu:

• a.  Sebagai tabel dimensi ketika berhubungan dengan tabel fakta hidrant dan pos sektor.

• b.  Sebagai table sub dimensi ketika berhubungan dengan tabel fakta kendaraan berikut table

dimensi PosPemadam.

Pembentukan tabel-tabel pada data warehouse dibentuk berdasarkan 4 file Excell yang tersebut diatas yaitu:

• a.    Tabel fakta kendaraan dibentuk berdasarkan file Excell Data-kode-kendaraan-Dan–Pos-

Pemadam-Kebakaran-DKI-Jakarta-2014.xls’

• b.    Tabel fact hidrant dibentuk berdasarkan file Excell Data-Monitoring-Hydrant-Di-DKI-Jakarta-Tahun-2014.xls.

• c.    Tabel fact pos_sektor dibentuk berdasarkan file Excell Data-Pos-Sektor-Pemadam-Kebakaran-DKI-Jakarta-Tahun-2014.xls.

(F) Hidrant

•id_hidrant(PK) Sektor Alamat latitude Longitude Keterangan id-kota (PK) Kota Kelurahan Kecamatan	(F) PosSektor
		*Kode_Wilayah(PK) Nama_Wilayah Sektor Nama_Sektor Nama_Bangunan Perumahan Status Alamat Kode_pos Notelp Thn_Pembangunan Luas_Tanah Luas_Bangunan Thn_Rehab NiIaLRehab Rincian_Rehab Keterangan ld_Kasie(PK) Nama_Kasie Nip/Nik Jabatan ld_Kota(PK) Kota Kelurahan Kecamatan
(F) Kendaraan
•nopol(PK) Nomor_body Kantor Notelp Sektor ld_pos(PK) Pos_pemadam Alamat RT RW ld_kota(PK) Kota Kelurahan Kecamatan

• Gambar 6. Fact Constellation model data warehouse kedua

Selain model desain data warehouse diatas ada kemungkinan model desain data warehouse dapat dibentuk sebagai fact constellation model data warehouse kedua yang terdapat pada gambar 6 berikut ini, dimana tanda (F) sebagai tanda F=Tabel Fakta:

Pada model desain ke 2 ini pada gambar 6, tabel dimensi Kasie dihilangkan dan atributnya digabung ke tabel fakta PosSektor, dengan demikian terjadi denormalizasi. Atribut pada tabel sub dimensi Kota digabung dengan tabel dimensi PosPemadam dan digabung pada table fakta Kendaraan dan atribut tabel dimensi Kota digabung ke tabel fakta Hidrant. Sehingga dalam hal

ini sesuai yang terlihat pada gambar 6 terdapat 3 tabel fakta yaitu tabel PosSektor, Hidrant dan Kendaraan.

Jelas model skema fact constellation data warehouse pada gambar 6 akan lebih mempercepat proses pembuatan laporan yang biasa dilakukan oleh data warehouse dimana kecepatan proses pembuatan laporan itu terjadi karena adanya pengurangan jumlah join tabel pada tabel data warehouse sehingga proses query lebih cepat yang pada akhirnya akan mempercepat proses pembuatan laporan. Jelas data warehouse pada gambar 6 mengalami denormalisasi sehingga menjadi model data warehouse yang tidak normal, namun penggunaan model data warehouse yang tidak normal mempercepat proses query dimana hanya menggunakan minimal tabel data warehouse sehingga laporan yang dihasilkan lebih cepat.

• 5.    Proses ETL Data Warehouse Pada Dinas Pemadam Kebakaran DKI Jakarta

Pembuatan proses Extraction Transformation dan Loading (ETL) dilakukan berdasarkan pembuatan laporan yang akan disesuaikan dengan data-data yang terdapat pada model desain data warehouse yang diusulkan. Dalam hal ini diusulkan 3 buah laporan yang akan dibuat berdasarkan hasil query dari kedua model data warehouse tersebut diatas dan laporan-laporan tersebut adalah:

• a.    Laporan daftar sektor

Laporan ini akan menampilkan atribut Kode wilayah, nama wilayah, Sektor, nama Sektor, Id kasie, nama kasie

• b.    Laporan daftar Hidrant

Laporan daftar hidrant ini akan menampilkan atribut IdHidrant, Alamat, latitude, longitude, kota, kelurahan, kecamatan.

• c.    Laporan Daftar Kendaraan

Laporan daftar kendaraan ini akan menampilkan atribut Nopol, NomorBody, kantor, Id_pos, Pos Pemadam, IdKota, kota, kelurahan, kecamatan.

Berikut dibawah ini penjelasan bagaimana ketiga laporan tersebut dibangun dengan menggunakan kedua model data warehouse tersebut diatas seperti yang digambarkan pada gambar 5 dan dan 6 diatas, berikut perintah sql statement yang dibutuhkan untuk menarik data-data dari masing-masing tabel pada kedua model data warehouse diatas tersebut.

• a.    Laporan daftar sektor

Laporan daftar sektor jika dibuat dengan model pertama pada gambar 5 menggunakan 1 tabel fakta Possektor dan 1 table dimensi Kasie yang akan dijoinkan dalam perintah sql statement sebagai query pembuatan laporan. Berikut adalah sql statement untuk pembuatan laporan tersebut:

Select A.Kodewilayah, A.namawilayah, A.Sektor, A.namaSektor, A.Idkasie, B.namakasie

From Possektor A, Kasie B

Where A.Idkasie=B.Idkaise

Sementara jika daftar sektor dibuat dengan model kedua pada gambar 6 hanya menggunakan 1 tabel fakta PosSektor. Berikut adalah sql statement untuk pembuatan laporan tersebut:

Select Kodewilayah, namawilayah, Sektor, namaSektor, Idkasie, namakasie

From Possektor

• b.    Laporan daftar Hidrant

Laporan daftar hidrant jika dibuat dengan model pertama pada gambar 5 menggunakan 1 tabel fakta Hidrant dan 1 table dimensi Kota yang akan dijoinkan dalam perintah sql statement sebagai query pembuatan laporan. Berikut adalah sql statement untuk pembuatan laporan tersebut:

Select A.Id_Hidrant, A.Alamat, A.latitude, A.longitude, B.kota, B.kelurahan, B.kecamatan.

From Hidrant A, Kota B

Where A.Id_kota=B.Id_Kota

Sementara jika daftar sektor dibuat dengan model kedua pada gambar 6 hanya menggunakan 1 tabel fakta Hidrant. Berikut adalah sql statement untuk pembuatan laporan tersebut:

Select IdHidrant, Alamat, latitude, longitude, kota, kelurahan, kecamatan.

From Hidrant

• c.    Laporan Daftar Kendaraan

Laporan daftar kendaraan ini akan menampilkan atribut Nopol, NomorBody, kantor, Id_pos, Pos Pemadam, IdKota, kota, kelurahan, kecamatan.

Laporan daftar kendaraan jika dibuat dengan model pertama pada gambar 5 menggunakan 1 tabel fakta kendaraan, 1 table dimensi PosPemadam dan 1 tabel sub dimensi Kota yang akan dijoinkan dalam perintah sql statement sebagai query pembuatan laporan. Berikut adalah sql statement untuk pembuatan laporan tersebut:

Select A.Nopol, A.Nomor_Body, A.kantor, B.Id_pos, B.Pos Pemadam, B.IdKota,C.kota, C.kelurahan, C.kecamatan.

From Kendaraan A, PosPemadam B, Kota B

Where A.Id_pos=B.Id_pos and B.id_kota=C.Id_Kota

Sementara itu, jika daftar sektor dibuat dengan model kedua pada gambar 6 hanya menggunakan 1 tabel fakta kendaraan. Berikut adalah sql statement untuk pembuatan laporan tersebut:

Select Nopol, Nomor_Body, kantor, Id_pos, Pos Pemadam, IdKota, kota, kelurahan ,kecamatan.

From Kendaraan

• 6.    Kesimpulan

Dari dua model skema yang diracang yaitu Fact Constellation model data warehouse (gambar 5) dan Skema bintang model data warehouse (gambar 6) dapat disimpulkan bahwa model skema bintang data warehouse pada (gambar 6) akan lebih mempercepat proses pembuatan laporan yang biasa dilakukan oleh data warehouse dimana kecepatan proses pembuatan laporan itu terjadi karena adanya pengurangan jumlah join tabel pada tabel data warehouse sehingga proses query lebih cepat yang pada akhirnya akan mempercepat proses pembuatan laporan. Data warehouse pada gambar 6 mengalami denormalisasi sehingga menjadi model data warehouse yang tidak normal, namun penggunaan model data warehouse yang tidak normal mempercepat proses query dimana hanya menggunakan minimal tabel data warehouse sehingga laporan yang dihasilkan lebih cepat.

Daftar Pustaka

• [1]    H.L.H.S, Warnars,”Multidimensional Datwarehouse with Combination formula” in The 2nd International Conference on Information and Communication Technology and Systems (ICTS), Informatics Department, Faculty of Information Technology, Institute of Technology Sepuluh Nopember (ITS), Surabaya, Indonesia, 29 August 2006.

• [2]    T. Park and H. Kim, “A data warehouse-based decision support system for sewer infrastructure management”, Automation in Construction, vol.30, p. 37-49, 2013.

• [3]    W.J. Labio, D.Quass and B.Adelberg, “Physical Database Design for DataWarehouses” in Proceeding 13th International Conference on Data Engineering, Birmingham, United Kingdom, 7-11 April 1997.

• [4]    D.R. Bunton, “Wildland fire and weather information data warehouse” in Proceedings of the Seventh Symposium on Systems Analysis on Forest Resources, Traverse City, MI, USA, 28– 31 May 1997.

• [5]    R.K.R. Prasanna, L.Yang and M. King, “Integrated Information System Model for Emergency Response”, in Procceding of the 13^th International Conference on Automation and Computing, Stafford, United Kingdom, 15^th September 2007.

• [6]    D. Stipanicev, M. Burgaric and L.Bodrozic, “Integration of forest video monitoring system and geographic information system”, in procceding of international symposium ELMAR, Zadar, Croatia, 28-30 Sept 2009

• [7]    S. Chaudhuri and U. Dayal, ”An overview of data warehousing and olap technology”, ACM SIGMOD Record, vol. 26, no. 1, p. 65-74, 1997

• [8]    M.P. Thompson, D.E. Calkin, J. Herynk, C.W. McHugh and K.C. Short, “Airtanker and wildfire management in the US Forest service: examining data availability and exploring usage and cost trends”, International Journal of Wildland Fire, vol. 22, no. 2, p. 223-233, 2012.

• [9]    R.M. Houtman, C.A. Montgomery,A.R. Gagnon, D.E. Calkin,T.G. Dietterich, S. McGregor and M.Crowley, “Allowing a wildfire to burn: estimating the effect on future fire suppression costs”, International Journal of Wildland Fire, vol. 22, no. 7, p. 871-882, 2013.

• [10]    S. Monatesti, J. Murphy, inventors. 1st responder guidance and decision-support system enabling victim tracking and extraction. United States patent application US 11/742,838. 2009 Jan 15.

• [11]    M. Subekti, Junaidi, H.L.H.S. Warnars and Y. Heryadi, “The 3 steps of best data warehouse model design with leaning implementation for sales transaction in franchise restaurant” Cybernetics and Computational Intelligence (CyberneticsCom), 2017 IEEE International Conference on, Phuket, Thailand, 20-22 Nov 2017.

• [12]    F. Luz, S. Mueller, S. Lindner, S. linz, M. Gardill, R.Weigel and A. Koelpin, “Smart Communication And Relative Localization System For Firefighters And Rescuers”., IEEE MTT-S International Microwave Symposium (IMS), Honololu, HI, USA, 4-9 June 2017.

• [13]    H.L.H.S, Warnars and R. Randriatoamanana, “Datawarehouser: A Data Warehouse artist who have ability to understand data warehouse schema pictures”, IEEE TENCON 2016 (Technologies for Smart Nation), pp. 2207-2210, 22-25 Nov 2016, Singapore, 2016.

• [14]  H.L.H.S, Warnars,  “Rancangan Infrastruktur E-Bisnis Business Intelligence  Pada

Perguruan Tinggi”, Journal Telkomnika, vol. 6, no.2, p. 115-124, August 2008.

• [15]  H.L.H.S, Warnars, “Analisa Dampak Investasi Teknologi Informasi Proyek Data

Warehouse Pada Perguruan Tinggi Swasta Dengan Metode Simple Roi”, Journal

Informatika,vol. 9, No. 2, p. 101-108, November 2008.

• [16]  H.L.H.S, Warnars, “Desain ETL dengan contoh kasus Perguruan Tinggi”, Journal

Informatika, vol. 10, no. 2, p. 86-93, November 2009.

• [17]  H.L.H.S, Warnars, “Simple ROI untuk justifikasi investasi proyek Data Warehouse pada

perguruan tinggi swasta”, Journal Ilmiah Teknik Komputer, vol. 1, no.1, p. 64-84, November 2009.

• [18]    H.L.H.S, Warnars, ”Desain model data warehouse dengan contoh kasus perguruan tinggi”, Journal of Industrial Engineering and Management System (JIEMS), vol. 3, no. 1, p. 9-20, February 2010.

• [19]  H.L.H.S, Warnars,”Tata Kelola Database Perguruan Tinggi Yang Optimal Dengan Data

Warehouse”, Journal Telkomnika, vol.8, no. 1, p. 25-34, April 2010.

• [20]  H.L.H.S, Warnars, ”Perbandingan penggunaan Database OLTP (Online Transactional

Processing) dan Data Warehouse”, Creative Communication and Innovative Technology (CCIT) journal, vol. 8, no.1, p. 83-100, September 2014.

• [21]    H.L.H.S, Warnars, E. Suria and D.K. Jeremy, “Pemahaman teori Data Warehouse bagi Mahasiswa tahun awal jenjang strata satu bidang ilmu komputer”, Jurnal informatika, vol. 13, no. 1, p. 20-24, Mei 2015.

• [22]    H.L.H.S, Warnars, ”Multidimensi pada Data Warehouse dengan menggunakan rumus Kombinasi” The 2nd National Seminar, National Seminar Information Technology Application 2006, University of Islam Indonesia, pp. 1-6, Yogyakarta, 17 June 2006.

• [23]    H.L.H.S, Warnars, “Multidimensi pada Data Warehouse dengan menggunakan rumus Kombinasi. The 2nd National Seminar, engineer industry and information technology, Sekolah Tinggi Teknologi Nasional, Yogyakarta, 15 July 2006.

• [24]    I. Zulfa and I.N.T.A. putra, “Sistem Pengambilan Keputusan untuk Penerimaan Pegawai Baru PT.PLN (Persero) Wilayah Aceh dengan Metode Heuristik”, Jurnal Ilmu Komputer, vol. 11, no.2, p. 109-120, 2018.

38