BAB 2 TINJAUAN PUSTAKA
2.1
Teori Umum 2.1.1 Pengertian Data
Data adalah fakta atau observasi mentah yang biasanya mengenai fenomena fisik atau transaksi bisnis. Lebih khusus lagi, data adalah ukuran objektif atribut dari entitas seperti orang-orang, tempat, benda, atau kejadian (Indrajani, 2011: 2). Data adalah komponen yang paling penting dalam DBMS, berasal dari sudut pandang end-user. Data bertindak sebagai jembatan yang menghubungkan antara mesin dengan pengguna (Connolly & Begg, 2010: 70).
2.1.2 Pengertian Basis Data
Basis data adalah suatu kumpulan logikal data yang berhubungan dan dekripsi dari data tersebut yang dirancang untuk kebutuhan informasi suatu organisasi (Connolly & Begg, 2010: 65). Basis data adalah kumpulan file yang saling terkait. Basis data tidak hanya merupakan kumpulan file. Record pada setiap file harus memperbolehkan hubungan-hubungan untuk menyimpan file lain (Whitten & Bentley, 2007: 518). Keuntungan basis data (Whitten & Bentley, 2007: 520) yaitu : 1) Kemampuannya untuk menggunakan data yang sama di banyak aplikasi dan sistem. 2) Penyimpanan data dalam format yang fleksibel. Hal ini didefinisikan secara terpisah dari sistem informasi dan programprogram aplikasi yang akan menggunakan basis data. 3) Teknologi basis data menyediakan skalabilitas superior, dalam arti basis data dan sistem yang menggunakannya dapat 7
8
ditingkatkan atau dikembangkan untuk memenuhi kebutuhankebutuhan perubahan pada sebuah organisasi. 4) Kemajuan independensi data yang sangat mengurangi redudansi data, telah meningkatkan fleksibilitas. Berdasarkan pengertian di atas, dapat disimpulkan basis data adalah sekumpulan data yang terintegrasi dan di rancang untuk memelihara informasi dan membuat informasi tersebut tersedia untuk memenuhi suatu kebutuhan organisasi.
2.1.3 Pengertian Database Management System (DBMS)
Database Management System (DBMS) adalah sistem perangkat
lunak
yang
memungkinkan
pengguna
untuk
mendefinisikan, membuat, memelihara, dan mengawasi akses ke database (Connolly & Begg, 2010: 66). Ada beberapa keuntungan dari Database Management System (DBMS) diantaranya (Connolly & Begg, 2010: 77-80) : 1)
Mengendalikan pengulangan data
2)
Menjaga konsistensi data
3)
Mendapatkan banyak informasi dari sejumlah data yang sama
4)
Dapat saling berbagi data
5)
Meningkatkan integritas data
6)
Meningkatkan keamanan data
7)
Menerapkan standarisasi
8)
Dapat mengurangi biaya
9)
Menyeimbangkan konflik kebutuhan
10) Meningkatkan kemampuan pengaksesan dan respon pada data 11) Meningkatkan produktivitas 12) Meningkatkan pemeliharaan melalui kemandirian data 13) Meningkatkan konkurensi 14) Meningkatkan pelayanan backup dan services
9
2.1.3.1 Data Definition Language (DDL)
DDL
merupakan
memperbolehkan
seorang
suatu DBA
bahasa atau
user
yang untuk
mendeskripsikan dan memberi nama suatu entitas, atribut, dan relasi data yang diperlukan oleh aplikasi, bersama dengan integritas dan batasan keamanan datanya (Connolly & Begg, 2010: 92). Perintah-perintah DDL yang digunakan diantaranya: 1)
Create Table, digunakan untuk membuat tabel dengan mengidentifikasikan tipe data untuk setiap kolom.
2)
Alter
Table,
digunakan
untuk
menambah
atau
membuang
atau
membuang kolom dari konstrain. 3)
Drop
Table,
digunakan
untuk
menghapus tabel berserta semua data yang terkait didalamnya. 4)
Create Index, digunakan untuk membuat index pada suatu tabel.
5)
Drop
Index,
digunakan
untuk
membuang
atau
menghapus index yang telah dibuat sebelumnya.
2.1.3.2 Data Manipulation Language (DML)
DML merupakan bahasa yang menyediakan satu set operasi untuk mendukung pengoperasian manipulasi data dasar pada basis data (Connolly & Begg, 2010: 92). Pengoperasian data yang akan dimanipulasi pada umumnya meliputi (Connolly & Begg, 2010: 92): 1)
Penambahan data baru ke dalam basis data.
2)
Modifikasi data yang disimpan dalam basis data.
3)
Pengembalian data yang terdapat dalam basis data.
10
4)
Penghapusan data dari basis data. Perintah-perintah yang ada pada DML diantaranya:
a) Select, digunakan untuk menampilkan sebagian atau seluruh isi dari suatu tabel dan menampilkan kombinasi isi dari beberapa tabel. b) Update, digunakan untuk mengubah isi satu atau beberapa atribut dari suatu tabel. c) Insert, digunakan untuk menambah satu atau beberapa baris nilai baru ke dalam suatu tabel. d) Delete, digunakan untuk menghapus sebagian atau seluruh isi dari suatu tabel.
2.1.4 Perancangan Basis Data (Database Design)
Perancangan basis data merupakan suatu proses pembuatan sebuah desain yang akan mendukung tujuan dan operasi dari perusahaan untuk kebutuhan sistem basis data (Connolly & Begg, 2010: 320). Perancangan suatu basis data terdiri dari tiga fase utama, yaitu perancangan basis data konseptual (Conseptual Database Design), perancangan basis data logikal (Logical Database Design), dan perancangan basis data fisikal (Physical Database Design) (Connolly & Begg, 2010: 467).
2.1.4.1 Perancangan
Basis
Data
Konseptual
(Conceptual
Database Design)
Perancangan basis data konseptual adalah proses membangun sebuah model informasi yang digunakan di perusahaan, yang terlepas dari semua pertimbanganpertimbangan fisik (Connolly & Begg, 2010: 322). Tujuan dari
perancangan
basis
data
konseptual
adalah
11
mengidentifikasi entitas penting beserta atribut-atributnya dan hubungan antara entitas yang satu dengan entitas yang lain (Connolly & Begg, 2010: 465). Entity relationship model merupakan salah satu model yang dapat memastikan pemahaman yang tepat terhadap data dan bagaimana penggunaannya di dalam suatu organisasi. Model ini menggunakan pendekatan Top-Down dalam merancang database, di mulai dengan mengidentifikasikan data penting yang di sebut entity dan relationship antara data yang harus direpresentasikan ke dalam model, kemudian ditambahkan beberapa atribut dan constraint pada entity, attribute dan relationship (Connolly & Begg, 2010: 371).
Langkah 1: Membangun model data konseptual
1.1. Identifikasi tipe entity Langkah
pertama
dalam
membangun
sebuah
konseptual data model adalah menentukan objek utama di mana user terlibat di dalamnya. Tujuan dari langkah ini adalah untuk mengidentifikasi tipe entity (Connolly & Begg, 2010: 471). Tipe entity adalah sekumpulan objek
dengan
diidentifikasikan
properti di
dalam
yang
sama,
perusahaan
yang karena
keberadaannya yang mandiri (Connolly & Begg, 2010: 372). Sedangkan kejadian entity adalah sebuah objek dari satu tipe entity yang dapat di identifikasi secara unik. Tipe entity dapat dikelompokkan menjadi: a) Tipe entity kuat
12
Tipe
entity
kuat
adalah
tipe
entity
yang
keberadaannya tidak bergantung pada tipe entity lainnya (Connolly & Begg, 2010: 383). b) Tipe entity lemah Tipe
entity
lemah
adalah
tipe
entity
yang
keberadaannya bergantung pada tipe entity lainnya (Connolly & Begg, 2010: 383).
Gambar 2.1 Strong Entity dan Weak Entity (Connolly & Begg, 2010: 384)
1.2. Identifikasi tipe relationship Tujuan dari langkah ini adalah untuk mengidentifikasi relationship-relationship penting yang ada di antara tipe entity (Connolly & Begg, 2010: 471). Tipe relationship adalah
sekumpulan
hubungan
antara satu atau lebih entitas (Connolly & Begg, 2010: 374). Relasi menurut hubungan dengan entitas lain dapat dibagi menjadi (Connolly & Begg, 2010: 376) : 1) Binary
Relationship:
Relationship
keterhubungannya antara dua tipe entitas.
yang
13
Gambar 2.2 Binary Relationship (Connolly & Begg, 2010: 376)
2) Ternary
Relationship:
Relasionship
yang
keterhubungannya antara tiga tipe entitas.
Gambar 2.3 Ternary Relationship (Connolly & Begg, 2010: 377)
3) Quarternary
Relationship:
Relationship
keterhubungannya antara empat tipe entitas.
yang
14
Gambar 2.4 Quarternary Relationship (Connolly & Begg, 2010: 377)
Relasi mempunyai batasan (constraint) utama yang harus merefleksikan larangan dalam hubungan seperti di dunia nyata yang disebut multiplicity (Connolly & Begg, 2010: 385). Tanda ◄ menunjukan arah yang benar agar pembaca dapat mengartikan maksud dari relasi tersebut (Contohnya, Branch Has ► Staff).
Gambar 2.5 Identifikasi Relationship (Connolly & Begg, 2010: 376)
15
Multiplicity terdiri dari dua jenis constraint, yaitu (Connolly & Begg, 2010: 390) : a. Cardinality, yaitu penggambaran jumlah maksimum dari kemungkinan batasan sebuah entitas yang ikut berpartisipasi
dalam
sebuah
relasi.
Mapping
Cardinalities menunjukkan jumlah entitas yang dapat
dihubungkan melalui
sebuah hubungan
(Connolly & Begg, 2010: 390). b. Participation,
yaitu
penggambaran
yang
menentukan apakah semua atau hanya beberapa entity occurance (anggota entitas) yang ikut berpartisipasi dalam sebuah hubungan (Connolly & Begg, 2010: 391).
Gambar 2.6 Contoh Cardinality dan Participation (Connolly & Begg, 2010: 391)
16
1.3.
Identifikasi dan asosiasi atribut entitas
dengan
entitas-
dan relationship yang telah dipilih untuk
digambarkan dalam database. Tujuan
dari
langkah
ini
adalah
untuk
mengasosiasikan attribute dengan tipe entity atau tipe relationship yang sesuai (Connolly & Begg, 2010: 474). Atribut adalah properti dari sebuah entity atau relationship. Atribut juga diartikan sebagai properti deskriptif
atau
karakteristik
dari
sebuah
entity
(Connolly & Begg, 2010: 379). Atribut menampung nilai yang menjelaskan setiap kejadian entity dan menggambarkan bagian utama dari data yang di simpan dalam database (Connolly & Begg, 2010: 379). 1) Atribut domain Atribut domain adalah sejumlah nilai yang diizinkan untuk nilai lebih untuk satu atau lebih atribut. Domain menetapkan bahwa sebuah atribut mungkin menahan dan serupa dengan konsep domain pada model relationship (Connolly & Begg, 2010: 379). 2) Atribut simpel Atribut simple adalah sebuah atribut yang di susun dari komponen tunggal dengan keberadaan yang mandiri. Atribut simpel tidak bisa dibagi lebih jauh lagi ke komponen yang lebih kecil. Seperti contoh posisi entity dan gaji karyawan. Atribut simpel dapat di sebut juga atomic atribut (Connolly & Begg, 2010: 379). 3) Atribut komposit Atribut komposit adalah sebuah atribut yang disusun dari komponen yang berlipat ganda, masing-masing
17
dengan sebuah keberadaan yang bebas. Beberapa atribut dapat di bagi lebih jauh lagi ke hasil komponen yang lebih kecil dengan keberadaan mandiri yang dimiliki atribut itu sendiri (Connolly & Begg, 2010: 380). 4) Atribut single-valued Atribut yang mempunyai nilai tunggal untuk setiap kejadian pada sebuah tipe entity (Connolly & Begg, 2010: 380). 5) Atribut multi-valued Atribut yang mempunyai beberapa nilai untuk setiap kejadian pada sebuah tipe entity (Connolly & Begg, 2010: 380). 6) Atribut derivasi Atribut yang mewakili sebuah nilai yang dapat diturunkan dari atribut lain yang berhubungan atau kumpulan dari beberapa atribut, dan tidak harus berasal dari entity yang sama (Connolly & Begg, 2010: 380). 1.4.
Menentukan atribut domain Tujuan
dari
langkah
ini
adalah
untuk
menentukan domain untuk atribut-atribut di dalam data model konseptual local (Connolly & Begg, 2010: 478). 1.5.
Menentukan candidate dan primary key Menentukan kandidat key untuk setiap tipe entitas dan jika ada lebih dari satu candidate key untuk memilih satu untuk dijadikan primary key (Connolly & Begg, 2010: 479). Ada beberapa macam keys, antara lain :
1) Candidate key Candidate key adalah sejumlah kecil atribut yang secara unik mengidentifikasikan setiap kejadian dari setiap tipe entity (Connolly & Begg, 2010: 381).
18
2) Primary key Primary key adalah candidate key yang terpilih untuk mendefinisikan secara unik pada setiap kejadian dari sebuah tipe entity (Connolly & Begg, 2010: 381). 3) Composite key Composite key adalah sebuah candidate key yang terdiri dari dua atau banyak atribut (Connolly & Begg, 2010: 382). 4) Foreign key Foreign key adalah himpunan atribut dalam suatu relationship yang cocok dengan candidate key dari beberapa relationship lainnya (Indrajani, 2011: 42). 5) Alternate key Alternate key adalah candidate key yang tidak terpilih menjadi primary key, atau biasa di sebut secondary key (Indrajani, 2011: 42). 1.6.
Pertimbangan menggunakan konsep modeling yang menarik Untuk mempertimbangkan penggunaan konsep enchanced modeling, seperti spesialisasi, generalisasi, agregasi,
dan
komposisi
entitas-entitas
dengan
menjelaskan satu atau lebih subclasses dari sebuah entity superclass. Subclasses adalah sebuah sub grouping yang jelas dari kejadian sebuah tipe entitas yang perlu digambarkan dalam sebuah model data. Superclass adalah sebuah tipe entitas yang termasuk satu atau lebih sub grouping yang jelas dari kejadiankejadian yang perlu direpresentasikan dalam sebuah model data (Connolly & Begg, 2010: 480). 1.7.
Periksa model untuk redundancy Pada langkah ini dilakukan pemeriksaan model data konseptual lokal dengan objektif spesifik untuk mengidentifikasi apakah ada terjadi redundancy dan
19
menghapus yang sudah ada (Connolly & Begg, 2010: 482). 1.8.
Validasikan
model
konseptual
dengan transaksi
pengguna Langkah ini untuk meyakinkan bahwa model konseptual lokal mendukung transaksi yang dibutuhkan oleh
tampilan
spesifik
yang
dari
merepresentasikan
perusahaan
digunakan
tampilan untuk
menampilkan operasi-operasi secara manual dengan memeriksa 2 pendekatan yang mungkin yaitu (Connolly & Begg, 2010: 483): a.
Model
data
konseptual
lokal
mendukung
transaksi yang diperlukan untuk menggambarkan transaksi. b.
Menggunakan
jalur
transaksi
(Transaction
Pathway). 1.9.
Mengulang model data konseptual lokal dengan pengguna Tujuan langkah ini adalah untuk mengevaluasi model data konseptual lokal dengan pengguna dan meyakinkan bahwa
model data
tersebut adalah
representasi yang nyata dari tampilan (Connolly & Begg, 2010: 485). Model data konseptual meliputi diagram ER dan dokumentasi yang mendukung yang menggambarkan model data.
20
Gambar 2.7 Model Data Konseptual (Connolly & Begg, 2010: 491)
2.1.4.2 Perancangan Basis Data Logikal (Logical Database Design)
Perancangan basis data logikal merupakan proses membangun sebuah model informasi yang digunakan dalam sebuah perusahaan berdasarkan pada sebuah model data yang spesifik, tetapi tidak bergantung pada sebuah DBMS tertentu dan pertimbangan-pertimbangan fisik lainnya (Connolly & Begg, 2010: 467).
Langkah 2: Membangun dan memvalidasi model data logikal
Langkah ini bertujuan untuk membangun model data logical dari model data konseptual, yang telah didapatkan pada
21
tahap sebelumnya, yang merepresentasikan view tertentu untuk menjamin agar strukturnya benar dan mendukung kebutuhan transaksi suatu perusahaan (Connolly & Begg, 2010: 490). Tahapan-tahapan yang dilakukan pada langkah kedua adalah: 2.1.
Menurunkan relasi untuk model data logikal Tahap ini bertujuan untuk mebuat relasi untuk model data logikal untuk merepresentasikan entitas, relasi
dan
atribut
yang
telah
diidentifikasikan
(Connolly & Begg, 2010: 492). Cara-cara
yang
dapat
dilakukan
untuk
mendapatkan relasi dari data model yang ada adalah tipe entitas kuat, tipe entitas lemah, tipe relasi binary one-to-many (1:*), tipe relasi binary one-to-one (1;1), relasi
rekursif
one-to-one
(1;1),
tipe
relasi
superclass/subclass, tipe relasi binary many-to-many (*:*), tipe relasi kompleks, atribut multi-valued. 2.2.
Validasi relasi-relasi menggunakan normalisasi Normalisasi
digunakan
untuk
memastikan
relasi dan atribut yang mendukung kebutuhan dari perusahaan. Proses normalisasi terdiri dari UNF, 1NF, 2NF, 3NF (Connolly & Begg, 2010: 501). 2.3.
Validasi relasi-relasi terhadap transaksi user Tujuan pada tahap ini yaitu untuk memvalidasi model data logikal untuk memastikan bahwa model data mendukung kebutuhan transaksi yang telah tercantum
didalam
spesifikasi
kebutuhan
user
(Connolly & Begg, 2010: 502). Validasi transaksi seperti ini sudah dilakukan pada tahap 1.8, namun kembali dilakukan untuk memeriksa relasi-relasi yang telah dibuat pada langkah sebelumnya juga mendukung transaksi ini. Juga untuk memastikan tidak terdapat
22
kesalahan dalam pembuatan relasi-relasi. 2.4.
Memeriksa integrity constraint Integrity constraint adalah batasan-batasan yang harus ditentukan untuk melindungi basis data agar tetap konsisten (Connolly & Begg, 2010: 502). Tipe integrity constraint, yaitu: a. Required data (data atau nilai yang valid). b. Batasan domain atribut. c. Multiplicity. d. Integritas entitas (entity integrity), primary key pada entitas tidak boleh null. e. Integritas referensial (referential integrity), adalah jika foreign key berisi sebuah nilai yang nilainya harus menunjukkan baris yang ada pada relasi induknya. f. General Constraints.
2.5.
Meninjau kembali model data logikal dengan user Tahapan ini memastikan bahwa model data logikal local yang terbentuk merupakan representasi dari perusahaan (Connolly & Begg, 2010: 506).
2.6.
Menggabungkan model data logikal ke dalam model global (optional step) Tahapan ini bertujuan untuk menggabungkan model data logikal local ke dalam data model single global logical yang mewakili semua user views dari basis data (Connolly & Begg, 2010: 506). Aktivitas dalam tahap ini, yaitu: a. Menggabungkan model data logikal ke dalam model global. b. Validasi model data logikal global. c. Meninjau kembali model data logikal global dengan user.
2.7.
Memeriksa perkembangan di masa depan
23
Tujuan dari tahap ini adalah untuk menentukan apakah ada perubahan yang signifikan dimasa depan dan untuk memperkirakan apakah model data logikal bisa mengakomodasi perubahan tersebut (Connolly & Begg, 2010: 517).
Gambar 2.8 Global Relation Diagram (Connolly & Begg, 2010: 516)
2.1.4.3 Perancangan Basis Data Fisikal (Physical Database Design)
Perancangan basis data fisikal adalah proses untuk menghasilkan deskripsi dari pengimplementasian suatu basis data pada media penyimpanan kedua. Perancangan ini juga menjelaskan relasi dasar, pengaturan file, dan indeks yang
24
digunakan untuk mencapai akses data yang efisien, integrity constraint yang terkait, serta ukuran keamanan (Connolly & Begg, 2010: 523)
Langkah 3: Menerjemahkan model data logikal global untuk target DBMS
Langkah ini bertujuan untuk menghasilkan skema basis data relational
dari
model
data
logikal
yang
dapat
diimplementasikan pada DBMS pilihan (Connolly & Begg, 2010: 524). Bagian pertama dari proses ini melibatkan perbandingan
informasi
yang
dikumpulkan
selama
perancangan basis data logikal. Sedangkan bagian kedua dari proses ini menggunakan informasi tersebut untuk menghasilkan desain relasi dasar. Proses ini memerlukan pengetahuan yang mendalam mengenai fungsionalitas yang ditawarkan DMBS pilihan. 3.1. Merancang relasi dasar Langkah
ini
bertujuan
untuk
menentukan
bagaimana representasikan relasi dasar dalam model data logikal ke dalam DBMS (Connolly & Begg, 2010: 525). 3.2. Merancang representasi dari derived data Menentukan
bagaimana
merepresentasikan
beberapa derived data yang terdapat dalam model data logikal ke dalam DBMS (Connolly & Begg, 2010: 526). 3.3. Merancang general constraint Perubahan terhadap data dapat dibatasi oleh general constraint yang mengatur transaksi dalam dunia nyata. Perancangan batasan ini tergantung pada pemilihan DBMS yang akan digunakan. Beberapa DBMS menyediakan fasilitas ini, namun ada juga yang
25
tidak menyediakannya, sehingga untuk menentukan batasan harus dilakukan pada program aplikasi (Connolly & Begg, 2010: 528).
Langkah 4: Merancang organisasi file dan indeks
Langkah ini bertujuan untuk menentukan organisasi file yang optimal untuk menyimpan relasi dasar dan indeks yang dibutuhkan untuk mencapai hasil yang baik, yaitu dengan cara dimana relasi dan bisnis data akan dipegang di tempat penyimpanan akhir sekunder (Connolly & Begg, 2010: 529). 4.1. Menganalisa transaksi Analisa transaksi berfungsi untuk memahami fungsi dari transaksi yang akan dijalankan pada bisnis data dan untuk menganalisa transaksi yang penting (Connolly & Begg, 2010: 529). 4.2. Memilih organisasi file Bertujuan untuk menentukan organisasi file yang efisien untuk setiap relasi dasar. Ada lima tipe organisasi file, yaitu heap, hash, indexed sequential office access method (ISAM), b-tree, dan clusters (Connolly & Begg, 2010: 534). 4.3. Memilih indeks Menentukan apakah dengan menambahkan indeks akan meningkatkan kinerja
dari system
(Connolly & Begg, 2010: 535). 4.4. Memperkirakan disk space yang dibutuhkan Memperkirakan jumlah dari disk space yang dibutuhkan untuk mendukung implementasi basis data pada secondary storage (Connolly & Begg, 2010: 541).
26
Langkah 5: Mendesain user view
Mendesain user view yang telah diidentifikasi selama pengumpulan kebutuhan (Connolly & Begg, 2010: 542).
Langkah 6: Mendesain mekanisme keamanan
Membatasi pengaksesan basis data oleh user yang tidak berhak dan menspesifikasikan basis data yang dapat diakses oleh user (Connolly & Begg, 2010: 542).
Gambar 2.9 Model Data Fisikal (Connolly & Begg, 2010: 526)
27
2.1.5 Structural Constraint
Constraint merupakan pembatas dalam sebuah relationship. Jenis utama dari constraint pada suatu relationship dinamakan multiplicity (Connolly & Begg, 2010: 385). Multiplicity adalah banyaknya kejadian yang mungkin pada sebuah tipe entity yang mungkin berhubungan dengan suatu kejadian dari tipe entity lain pada suatu relationship (Connolly & Begg, 2010: 385). Derajat yang paling umum pada suatu relationship adalah biner. Jenis-jenis relationship biner terdiri : 1)
One-to-one relationship (1:1) Hubungan relasi satu ke satu yaitu setiap entitas pada himpunan entitas A berhubungan paling banyak dengan satu entitas pada himpunan entitas B (Connolly & Begg, 2010: 386).
Gambar 2.10 One to One Relationship (Connolly & Begg, 2010: 386)
2)
One-to-many relationship (1:*)
28
Setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B, tetapi setiap entitas pada entitas B dapat berhubungan dengan satu entitas pada himpunan entitas A (Connolly & Begg, 2010, p. 387).
Gambar 2.11 One to Many Relationship (Connolly & Begg, 2010: 388)
3)
Many to Many (*:*) Setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B (Connolly & Begg, 2010: 388).
29
Gambar 2.12 Many to Many Relationship (Connolly & Begg, 2010: 389)
2.1.6 Teori Data Flow Diagram (DFD)
Data flow diagram adalah sebuah tool yang digunakan untuk menggambarkan aliran data yang melalui sebuah sistem dan pengerjaan pemrosesan yang dikerjakan sistem (Whitten & Bentley, 2007: 317). Hanya ada tiga simbol dan satu koneksi yang digunakan, yaitu (Whitten & Bentley, 2007: 317): 1.
Persegi panjang yang bertepi bulat merepresentasikan proses atau pekerjaan yang harus diselesaikan.
2.
Bujur sangkar merepresentasikan external agents. External agents adalah orang luar, unit organisasi, sistem, atau organisasi yang berinteraksi dengan sistem, disebut juga dengan external entity (Whitten & Bentley, 2007: 319).
3.
Kotak terbuka merepresentasikan data stores, biasa disebut juga files atau basis data.
4.
Panah merepresentasikan aliran data, input, dan output, kepada atau dari proses.
30
Gambar 2.13 Simple Data Flow Diagram (Whitten & Bentley, 2007: 318)
Context data flow diagram adalah sebuah model proses yang digunakan untuk mendokumentasikan lingkup dari sistem, biasa disebut juga environmental model (Whitten & Bentley, 2007: 339).
31
Gambar 2.14 Context Data Flow Diagram (Whitten & Bentley, 2007: 340)
System diagram adalah diagram yang menunnjukkan semua kejadian pada sistem yang terdapat pada single diagram. System diagram merupakan pecahan dari single process yang terdapat pada context diagram (Whitten & Bentley, 2007: 348).
32
Gambar 2.15 System Diagram (Whitten & Bentley, 2007: 350-351)
2.1.7 Teori Flowchart
Flowchart adalah representasi grafikal dari sebuah sistem yang menjelaskan aspek-aspek sistem informasi secara jelas, tepat, dan logis yang digunakan terutama untuk menjelaskan relasi fisik di antara entitas-entitas kuncinya (Hall, 2011: 8).
33
2.1.8 8 Golden Rules
Dalam perancangan antarmuka harus memperhatikan aturanaturan yang terangkum dalam 8 golden rules (Shneiderman & Plaisant, 2010: 88), yaitu : 1. Berusaha untuk konsisten Hal ini sangat penting bagi antarmuka user agar user tidak mengalami kesulitan dalam mencari sebuah informasi. Oleh karena itu, tampilan layar harus dibuat konsisten antara yang satu dengan yang lainnya. 2. Melayani usability universal Hal ini dimaksudkan agar pembuat aplikasi dapat mengenali kebutuhan pengguna yang beragam dan desain yang bersifat plasticity, serta memfasilitasi transformasi dari konten. Dalam sistem juga dapat ditambahkan fitur bagi pemula, seperti penjelasan, dan fitur untuk para ahli, seperti shortcut dan aksi timbal balik yang lebih cepat sehingga dapat memperkaya desain antarmuka dan meningkatkan persepsi kualitas sistem. 3. Memberikan umpan balik yang informatif Ketika user melakukan aksi harus ada umpan balik agar user menjadi terarah dan tidak tersesat dalam pencarian informasi. 4. Merancang dialog yang memberikan penutupan Berinteraksi dengan komputer sama halnya seperti pada saat berdialog. Aksi yang berurutan harus diorganisasi dan memiliki awal, tengah, dan akhir. User perlu mengetahui kapan aksi tersebut berakhir. Umpan balik yang informatif pada saat sekumpulan aksi telah dilakukan akan memberikan kepuasan bagi user, serta mengindikasikan bahwa user boleh melakukan aksi selanjutnya. 5. Mencegah terjadinya error Desain
sebuah
sistem
harus
memungkinkan
user
untuk
menghindari kesalahan yang serius. Sebagai contoh, membuat
34
menu yang tidak bisa diakses menjadi berwarna abu-abu. Jika user melakukan
kesalahan,
antarmuka
harus
dapat
mendeteksi
kesalahan tersebut dan menawarkan instruksi yang sederhana dan spesifik untuk pemulihan. 6. Memungkinkan pembalikan aksi yang mudah User dapat kembali pada aksi yang telah dilakukan sebelumnya jika terdapat kesalahan, sehingga user berani memilih menu yang tidak umum. 7. Mendukung pusat kendali internal Kepuasan user akan tinggi jika user merasakan bahwa dia telah memegang kendali, sedangkan kepuasan user akan rendah jika komputer yang memegang kendali. 8. Mengurangi beban ingatan jangka pendek Ingatan jangka pendek manusia sangat terbatas. Oleh karena itu harus dilakukan hal-hal yang memungkinkan user tidak perlu mengingat apa pun. Sebagai contoh, daripada meminta user untuk mengetik nama file yang akan diterima, lebih baik apabila sistem dibuat agar terdapat tombol attach file sehingga user tinggal menekan tombol tersebut untuk mengambil file.
2.2
Teori Khusus 2.2.1 PHP
PHP adalah bahasa server-side scripting yang dirancang khusus untuk web (Welling & Thomson, 2005). Dalam sebuah halaman HTML, Anda dapat menanamkan kode PHP yang akan dijalankan setiap kali halaman dikunjungi. Kode PHP yang anda intepretasikan pada web server dan akan menghasilkan output HTML atau lainnya yang akan dilihat oleh pengunjung. Performa PHP sangat efisien, dengan menggunakan server tunggal yang tidak mahal, Anda dapat melayani jutaan hits per hari. Jka Anda menggunakan sejumlah besar server komoditas, kapasitas Anda secara efektif akan menjadi tidak terbatas.
35
2.2.2 XAMPP
XAMPP adalah distribusi Apache yang kecil dan ringan yang mengandung teknologi pengembangan web yang paling umum dalam satu paket. Kapasitas kontennya yang kecil dan portabilitasnya membuatnya menjadi tool yang ideal bagi pengguna dalam mengembangkan dan melakukan testing di aplikasi PHP dan MySQL (Dvorski, 2007).
2.2.3 System Ticketing
System Ticketing merupakan suatu aplikasi perangkat lunak yang dirancang untuk mengkoordinasikan pekerjaan beberapa orang yang mungkin memiliki masalah dalam pekerjaannya. Informasi dalam tiket dapat digunakan untuk menghasilkan laporan statistik tertentu. Efisiensi dan keakuratan operator dapat ditingkatkan karena cara kerja sistem tiket yang otomatis (Johnson, 1992).
2.2.4 Help Desk
Help desk otomatis berfungsi untuk mengambil informasi yang dibutuhkan untuk membantu user secepat dan semudah mungkin baik bagi user yang ahli maupun yang tidak ahli. Sistem help desk dibangun agar user dari jarak tertentu dapat mendapatkan informasi secara langsung sehingga help desk sering disebut dengan sistem pengambilan informasi, hal ini dapat dilakukan beberapa user sekaligus. Help desk dapat dikatakan baik jika dapat menangani kasus-kasus yang ada dengan konsisten (Motoda, 1997).
36
2.3
Hasil Penelitian atau Produk Sebelumnya
Penjelasan mengenai beberapa penelitian terdahulu mengenai aplikasi sejenis yang terdapat dalam bab satu akan dijelaskan sebagai berikut. 1.
Qoyyimah (2011) Penelitian ini berjudul “Rancang Bangun Help Desk Ticketing System” pada PT. Primus Indojaya. Dalam pengembangan helpdesk ticketing system ini, penulis menggunakan metodologi berorientasi pada objek yaitu iteration waterfall dengan dimodelkan menggunakan Unified Modelling Language (UML), perancangan database dan perancangan layar. Tools yang digunakan adalah XAMPP 1.7.1 dengan spesifikasi Apache 2.2.11 sebagai web server. PHP versi 5.2.9 sebagai bahasa pemograman dan MySQL versi 5.1.33 sebagai database. Dengan diterapkannya sistem ini, peneliti mengharapkan helpdesk dapat tersimpan secara terpusat dalam database dan juga pembuatan laporan secara otomatis dalam sistem.
2.
Gemar Ahmad Jembarata (2011) Penelitian ini berjudul “Perancangan dan Pembangunan Trouble Ticket Management” dan dibuat dengan berbasiskan web yang menggunakan expert system” pada Badan Pengkajian dan Penerapan Teknologi (BPPT). Trouble Ticket Management yang dibuat dilengkapi dengan sistem pakar sederhana yang dapat membantu pengguna sistem dalam menyelesaikan permasalahan. Metodologi yang digunakan adalah metode pengumpulan data dan metode pengembangan sistem. Metode pengumpulan data dengan mengunakan metode observasi, wawancara, dan studi pustaka. Sedangkan metode pengembangan sistem dengan menggunakan Rapid Application Development. Kesimpulan dari penelitian adalah membuat sistem berbasis web, sistem dapat membantu pegawai dalam menyelesaikan sendiri permasalahan yang terjadi maupun melaporkannya langsung tanpa harus mengantri terlebih dahulu, yang akhirnya permasalahan dapat langsung didata dan ditangani sehingga efektifitas kerja pun akan tercipta.
37
3.
Dingding Wang, Tao Li, Shenghuo Zhu, dan Yihong Gong (2010) Penelitian yang dilakukan berjudul “iHelp: An Intelligent Online Helpdesk System”. Variabel penelitian adalah kebutuhan terhadap sebuah helpdesk system yang dapat mengatasi kesulitan dalam menangkap makna semantik dari setiap kasus dan memiliki representasi hasil yang baik. Metode penelitian menggunakan studi kasus dimana peneliti membuat dua skenario masing-masing kasus dan membandingkan hasil perbandingan dengan solusi yang telah dibuat sebelumnya dan studi pengguna dimana sebuah survei dilakukan terhadap enam belas mahasiswa dengan tingkat dan jurusan yang berbeda. Kesimpulan yang dihasilkan dari penelitian yang telah dilakukan adalah sistem dapat menemukan pola solusi secara otomatis interaksi pengguna dengan sistem sebelumnya dan performa iHelp yang tinggi diakibatkan karena adanya pendekatan semantic case ranking, case clustering dengan model bahasa campuran dan symmetric matrix factorization, dan rangkuman request-focused multidocument.
38
