7 BAB 2 TINJAUAN PUSTAKA 2.1 Teori Umum 2.1.1

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