7 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
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
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.
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
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
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
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.
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).
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)
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
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).
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
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.
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
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
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.
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
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
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).
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).
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)
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).
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.
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).
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).
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).
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
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.
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).
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.
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.
