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 program-

program 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 kebutuhan-

kebutuhan 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 suatu bahasa yang

memperbolehkan seorang DBA atau user 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 kolom dari konstrain.

3) Drop Table, digunakan untuk membuang atau

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 pertimbangan-

pertimbangan 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 properti yang sama, yang

diidentifikasikan di dalam perusahaan 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 yang

keterhubungannya antara dua tipe entitas.

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 yang

keterhubungannya antara empat tipe entitas.

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 dengan entitas-

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 kejadian-

kejadian 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 yang merepresentasikan tampilan

spesifik dari perusahaan digunakan 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 aturan-

aturan 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