1 BAB 2 TINJAUAN PUSTAKA Pada bab tinjauan pustaka akan

BAB 2
TINJAUAN PUSTAKA
Pada bab tinjauan pustaka akan dibahas secara ringkas mengenai teori yang berkaitan
dengan basis data, teori yang terkait tema penelitian, serta hasil penelitian atau
produk sebelumnya.
2.1 Teori yang Berkaitan dengan Basis Data
Dalam tinjauan pustaka yang berhubungan dengan basis data akan diuriakan secara
ringkas antara lain: data, informasi, tabel, basis data (database), sistem manajemen
basis data, Database Management System (DBMS), komponen DBMS, keuntungan
dan kerugian DBMS, fungsi DBMS, bahasa basis data (Database Language), data
definition language (DDL), data manipulation language (DML), pemodelan relasi
entitas (Entity-Relationship Modelling), normalisasi (Normalization), daur hidup
basis data (Database Life Cycle), dan lain-lain.
2.1.1 Pengertian Data
Menurut Indrajani (2011:2), data adalah fakta atau observasi mentah yang
biasanya mengenai fenomena fisik atau transaksi bisnis.
Menurut William dan Sawyer (2007:25), data terdiri dari fakta-fakta dan gambar
mentahan yang akan di proses menjadi informasi.
Menurut Jonathan Lukas (2006:39), Data adalah kenyataan atau fakta penting
yang tercatat atau terekam yang dapat diproses oleh komputer atau manusia dan
memiliki arti yang bermacam-macam.
Sedangkan Menurut Kamus Bahasa Indonesia (2008:1580), data adalah
kenyataan yang ada dan berfungsi sebagai sumber bahan untuk menyusun suatu
pendapat.
2.1.2 Pengertian Informasi
Menurut William dan Sawyer (2007:25), informasi adalah data yang telah
dirangkum atau dimanipulasi dalam bentuk lain untuk pengambilan keputusan.
7
8
Menurut R. Kelly Rainer dan Casey G. Cagielski (2011:10), Informasi mengacu
pada data yang telah terorganisasi sehingga data tersebut memiliki makna dan
nilai kepada penerima data tersebut.
2.1.3 Pengertian Tabel
Menurut Kamus Bahasa Indonesia (2008:1580), Pengertian Tabel adalah daftar
yang berisi ikhtisar sejumlah data informasi, biasanya berupa kata-kata dan
bilangan yg tersusun secara tersistem, urut ke bawah pada lajur dan deret
tertentu dengan garis pembatas sehingga dapat dengan mudah disimak.
Menurut Thomas Connolly dan Carolyn Begg (2005:72), Suatu relasi adalah
tabel dengan kolom dan baris.
Menurut Thomas Connolly dan Carolyn Begg (2005:72), Sebuah atribut adalah
kolom dari suatu relasi. Dalam model relasional, relasi digunakan untuk
menyimpan informasi tentang objek yang akan direpresentasikan dalam basis
data. Suatu relasi direpresentasikan sebagai tabel dua dimensi dimana baris tabel
tersebut sesuai dengan catatan individu dan kolom tabel sesuai dengan atribut.
Atribut dapat muncul dalam urutan keberapapun dan akan tetap memiliki relasi
yang sama. karena menyampaikan makna yang sama, Sebuah atribut adalah
kolom yang bernama relasi.
Menurut Thomas Connolly dan Carolyn Begg (2005:72), Sebuah domain adalah
himpunan nilai diperbolehkan untuk satu atau lebih atribut.
Menurut Thomas Connolly dan Carolyn Begg (2005:73), Tuple adalah baris dari
suatu relasi. Unsur-unsur relasi adalah baris atau tuple dalam tabel. Dalam relasi
Cabang, setiap baris berisi empat nilai, satu untuk setiap atribut. Tuple dapat
muncul dalam urutan apapun dan relasi akan tetap relasi yang sama, dan
karenanya menyampaikan makna yang sama.
2.1.4 Pengertian Basis Data
Menurut Gerald V.Post (2005:2), basis data adalah kumpulan data yang
disimpan dalam format standar, yang dirancang untuk digunakan bersama oleh
beberapa pengguna.
9
Menurut Indrajani (2011:2), basis data adalah kumpulan data yang berelasi
secara logis dan deskripsi data tersebut, yang dirancang untuk memenuhi
informasi yang dibutuhkan oleh suatu organisasi.
Sedangkan menurut William dan Sawyer (2007:464), basis data adalah
kumpulan data yang saling berelasi, yang diatur secara logis, yang dirancang dan
dibangun untuk tujuan khusus. sebuah teknologi untuk mengumpulkan banyak
fakta yang memungkinkan anda memotong, membuang, dan menggabungkan
serta memasang data dengan beragam cara.
2.1.5 Database Management System (DBMS)
Menurut Gerald V.Post (2005:2), DBMS adalah perangkat lunak yang
mendefinisikan basis data, menyimpan data, mendukung bahasa query,
menghasilkan laporan, dan menciptakan entri data pada layar.
Menurut Thomas Connolly dan Carolyn Begg (2005:16), DBMS adalah Sebuah
sistem perangkat lunak yang memungkinkan pengguna untuk mendefinisikan,
membuat, memelihara, dan mengontrol akses ke basis data.
Beberapa fasilitas yang disediakan DBMS:
1. Data Definition Language (DDL), memungkinkan pengguna untuk
menentukan jenis, struktur data dan masalah pada data yang akan disimpan
dalam basis data.
2. Data Manipulation Language (DML), memungkinkan pengguna untuk
menambahkan, memperbaharui, menghapus, dan memperoleh data dari
basis data.
3. Query Languange Memiliki repositori pusat untuk semua data dan
mendeskripsikan data yang memungkinkan DML menyediakan fasilitas
umum untuk penyelidikan data.
2.1.5.1 Komponen DBMS
Menurut Thomas Connolly dan Carolyn Begg (2005:18–21), DBMS
dibagi menjadi 5 Komponen yaitu:
10
Gambar 2.1 Komponen DBMS
1. Perangkat keras (Hardware)
DBMS dan aplikasi membutuhkan hardware untuk menjalankannya.
Hardware
meliputi
komputer
pribadi
(personal
computer),
mainframe, dan jaringan komputer. Beberapa DBMS hanya dapat
berjalan pada hardware atau operating system tertentu, dan yang
lainnya dapat berjalan pada berbagai hardware atau operating system.
Amount of memory and disk space diperlukan untuk menjalankan
DBMS.
2. Perangkat lunak (Software)
Komponen perangkat lunak (software) terdiri dari DBMS dan
program aplikasi beserta sistem operasinya, termasuk perangkat lunak
jaringan (network software) jika DBMS sedang digunakan melalui
sebuah jaringan tertentu.
3. Data
Data adalah komponen penting dalam DBMS. Data bertindak sebagai
penghubung antara komponen mesin dan manusia. Basis data berisi
data operasional dan metadata.
4. Prosedur (Procedure)
Prosedur mengacu pada instruksi dan aturan yang mengatur desain
dan penggunaan basis data. Pengguna sistem dan staf yang mengatur
basis
data
memerlukan
dokumentasi
prosedur
tentang
cara
menggunakan atau menjalankan sistem. Beberapa instruksi tentang
cara penggunaan basis data adalah:
a. Masuk ke DBMS,
b. Menggunakan fasilitas DBMS tertentu atau program aplikasi,
c. Memulai dan menghentikan DBMS,
11
d. Membuat backup dari basis data,
e. Menangani hardware atau software yang rusak,
f. Mengubah struktur tabel, mengatur basis data di beberapa disk,
meningkatkan kinerja atau menyimpan arsip data ke penyimpanan
sekunder.
5. Pengguna (People)
Komponen terkahir adalah pengguna yang terlibat dengan sistem.
Menurut Thomas Connolly dan Carolyn Begg (2005:21–24), Kita
dapat mengidentifikasi empat jenis
pengguna yang berpartisipasi
dalam lingkungan DBMS yaitu:
a. Pengelola data dan basis data (Data and Database Administrator)
Data dan database administrator memiliki peran dalam
pengelolaan
dan
pengendalian
DBMS
dan
data.
Data
Administrator (DA) bertanggung jawab atas pengelolaan sumber
daya data yang termasuk dalam perencanaan basis data,
pengembangan dan pemeliharaan, kebijakan dan prosedur, dan
desain basis data konseptual atau logikal.
Database Administrator (DBA) bertanggung jawab untuk fisikal
basis data, termasuk desain fisikal basis data dan implementasi,
keamanan
dan
integritas
kontrol,
pemeliharaan
sistem
operasional, dan memastikan kinerja yang memuaskan dari
aplikasi untuk pengguna.
b. Desainer basis data (Database Designer)
Dalam proyek desain basis data yang besar, kita dapat
membedakan antara dua jenis desainer yaitu desainer basis data
logikal dan desainer basis data fisikal. Perancang basis data
logikal berkaitan dengan mengidentifikasi data (entitas dan
atribut), relasi antara data, dan kendala pada data yang akan
disimpan dalam basis data.
Sedangkan bagian desain basis data fisikal sangat tergantung pada
target DBMS, dan mungkin ada lebih dari satu cara untuk
12
menerapkan mekanismenya. Akibatnya, desainer basis data fisikal
harus sepenuhnya menyadari fungsi dari target DBMS dan harus
memahami kelebihan dan kekurangan dari setiap alternatif untuk
implementasi tertentu. Perancang basis data fisikal harus mampu
memilih strategi penyimpanan data yang memperhitungkan
penggunaan.
c. Pembangun aplikasi (Application Developer)
Setelah
basis
menyediakan
data
dilaksanakan,
fungsi
untuk
program
end-user
aplikasi
yang
yang
harus
diimplimentasikan. Ini merupakan tanggung jawab pengembang
aplikasi. Biasanya, pengembang aplikasi bekerja dari spesifikasi
yang dihasilkan oleh sistem analis. Setiap program berisi
pernyataan yang meminta DBMS untuk melakukan beberapa
operasi pada basis data. Ini termasuk mengambil data, insert,
update, dan delete data.
d. Pengguna akhir (End-User)
Para end-users adalah client untuk basis data yang telah dirancang
dan
diimplementasikan,
melayani
kebutuhan
dan
sedang
informasi
dipertahankan
mereka.
End-User
untuk
dapat
diklasifikasikan menurut cara mereka menggunakan sistem:
i. Pengguna awam (Naïve users) biasanya menyadari DBMS.
Mereka mengakses basis data melalui program aplikasi
yang buat khusus dalam suatu operasi yang sesederhana
mungkin. Mereka menggunakan operasi basis data dengan
memasukkan perintah sederhana atau dengan memilih dari
menu. Ini menandakan bahwa mereka tidak perlu tahu apaapa tentang basis data atau DBMS. Sebagai contoh, asisten
kasir di supermarket lokal menggunakan barcode reader
untuk mengetahui harga suatu item. selanjutnya, ada
program aplikasi yang membaca barcode, melihat harga
dari item dalam basis data, mengurangi jumlah basis data
13
yang berisi jumlah item di stok, dan menampilkan harga di
kasir.
ii. Pengguna hebat (Sophisticated users) Adalah seseorang yang
terbiasa dengan struktur basis data dan fasilitas yang
ditawarkan
oleh
DBMS.
sophisticated
users
dapat
menggunakan query bahasa tingkat tinggi seperti SQL
untuk melakukan operasi yang diperlukan. Beberapa
sophisticated users bahkan dapat menulis program aplikasi
untuk mereka gunakan sendiri.
2.1.5.2 Keuntungan dan Kerugian Dalam Menggunakan DBMS
Menurut Thomas Connolly dan Carolyn Begg (2005:26–30), ada beberapa
keuntungan dan kerugian dalam menggunakan DBMS yaitu:
1. Keuntungan
a. Pengendalian redudansi data (Control of data redudancy)
pendekatan basis data berusaha untuk menghilangkan redundansi
dengan cara mengintegrasikan file tersebut sehingga beberapa
salinan data yang sama tidak disimpan. Namun pendekatan basis
data
tidak
menghilangkan
redundansi
sepenuhnya,
hanya
mengendalikan jumlah redudansi yang ada di basis data.
Contohnya, Jika suatu saat dibutuhkan duplikat data untuk suatu
proses relasi (relationship) atau di saat yang lain dibutuhkan
duplikat data untuk meningkatkan kinerja sistem.
b. Konsistensi data (Data consistency)
Dengan
menghilangkan
atau
mengontrol
redundansi,
kita
mengurangi risiko terjadinya tidak konsistennya data.
c. Informasi lebih lanjut dari jumlah data yang sama (More
information from the same amount of data)
Dengan integrasi data operasional, dimungkinkan bagi organisasi
untuk memperoleh informasi tambahan dari data yang sama.
14
d. Berbagi data (Sharing of data)
Biasanya sharing of data digunakan oleh pengguna atau
departemen yang memiliki file. Di sisi lain, basis data seluruh
organisasi dapat dibagi (share) oleh semua pengguna yang
berwenang. Dengan cara ini, bila banyak pengguna maka lebih
banyak sharing of data. Aplikasi ini juga dapat mengandalkan
fungsi yang disediakan oleh DBMS, seperti definisi data,
manipulasi, concurrency dan recovery control, daripada harus
menyediakan fungsi-fungsi ersebut sendiri.
e. Peningkatan integritas data (Improved data integrity)
Integritas basis data mengacu pada validitas dan konsistensi data
yang tersimpan. Integritas biasanya dinyatakan dalam berbagai hal
masalah yaitu, konsistensi bahwa aturan basis data tidak
diperbolehkan untuk dilanggar.
f. Peningkatan keamanan (Improved security)
Keamanan basis data adalah perlindungan basis data dari pengguna
yang tidak berwenang. Tanpa langkah-langkah keamanan yang
sesuai, integrasi membuat data lebih rentan dibandingkan dengan
sistem berbasis file. Namun, integrasi memungkinkan DBA untuk
mendefinisikannya,
dan
DBMS
Ini
memungkinkan
untuk
mengambil nama pengguna dan password untuk mengidentifikasi
orang-orang yang berwenang untuk menggunakan basis data.
Akses pengguna yang berwenang diperbolehkan pada system basis
data dapat dibatasi oleh jenis operasi (pengambilan data, insert,
update, dan delete)
g. Penegakan standar (Enforcement of standards)
Integrasi
memungkinkan
DBA
untuk
mendefinisikan
dan
menegakkan standar yang diperlukan. Hal Ini termasuk dalam
departemen, standar organisasi nasional atau internasional untuk
hal-hal seperti format data yang digunakan untuk memfasilitasi
pertukaran data antara sistem, konvensi penamaan, standar
dokumentasi, prosedur update, dan aturan akses data.
15
h. Skala ekonomi (Economy of scale)
Menggabungkan semua data operasional organisasi ke dalam satu
basis data, dan menciptakan satu set aplikasi yang bekerja pada
salah satu sumber data, dapat menghasilkan penghematan biaya.
Dalam kasus ini, anggaran yang biasanya akan dialokasikan untuk
masing-masing
departemen
untuk
pengembangan
dan
pemeliharaan sistem berbasis file yang dapat dikombinasikan,
mungkin mengakibatkan total biaya yang lebih rendah. Anggaran
yang dikombinasikan dapat digunakan untuk membeli konfigurasi
sistem yang lebih sesuai dengan kebutuhan organisasi.
i. Neraca persyaratan yang saling bertentangan (Balance of
Conflicting requirements)
Biasanya sistem berbasis file dibuat untuk aplikasi tertentu seperti
pemfakturan, sehingga kinerjanya sangat baik. Namun, DBMS
dibuat lebih umum untuk dapat menangani beberapa aplikasi secara
bersamaan pada satu aplikasi saja. Akibatnya beberapa aplikasi
yang berjalan kinerjanya tidak secepat sebelumnya.
j. Peningkatan aksesibilitas data dan responsifitas (Improved Data
accessibility and responsiveness)
sebagai hasil integrasi, data yang melintasi batas-batas departemen
diakses secara langsung ke End-user. Ini memberikan sebuah
sistem dengan fungsionalitas yang memiliki banyak potensi,
misalnya digunakan untuk menyediakan layanan yang lebih baik
kepada
End-user
menyediakan
atau
bahasa
klien
query
organisasi.
atau
Banyak
penulis
laporan
DBMS
yang
memungkinkan pengguna untuk mengajukan pertanyaan adhoc dan
memperoleh informasi yang diperlukan di terminal mereka.
k. Peningkatan produktivitas (Increased Productivity)
DBMS menyediakan banyak fungsi standar yang biasanya
programmer harus menulis dalam aplikasi yang berbasis file. Pada
tingkat dasar, DBMS menyediakan semua rutinitas penanganan
berkas tingkat rendah dalam program aplikasi. Penyediaan fungsi
16
ini memungkinkan programmer untuk berkonsentrasi pada fungsi
tertentu yang diperlukan oleh pengguna tanpa harus khawatir
tentang rincian pelaksanaan tingkat rendah. Banyak DBMS juga
menyediakan lingkungan generasi keempat yang terdiri dari suatu
alat untuk menyederhanakan pengembangan aplikasi basis data.
Hal ini menyebabkan peningkatan produktivitas programmer dan
mengurangi waktu pengembangan (dengan penghematan biaya
yang terkait)
l. Peningkatan pemeliharaan melalui data independence (Improved
Maintenance through data independence)
Dalam sistem berbasis file, deskripsi data dan logika untuk
mengakses data yang dibangun ke dalam setiap program aplikasi,
membuat program tergantung pada data. Sebuah perubahan pada
struktur data, atau perubahan dengan cara data disimpan pada disk,
dapat
memerlukan
perubahan
substansial
program
yang
dipengaruhi oleh perubahan. Sebaliknya, DBMS memisahkan
deskripsi data dari aplikasi, sehingga membuat aplikasi kebal
terhadap perubahan dalam deskripsi data.
m. Peningkatan konkurensi (Increased concurrency)
Dalam beberapa sistem berbasis file, jika dua atau lebih pengguna
yang diizinkan untuk mengakses file yang sama secara bersamaan,
memungkinkan akses akan mengganggu satu sama lain, sehingga
akan terjadi hilangnya informasi atau bahkan hilangnya integritas.
Banyak DBMS yang mengelola akses basis data secara bersamaan
dan memastikan masalah tersebut tidak terjadi.
n. Peningkatan layanan backup dan recovery (Improved backup and
recovery services)
Banyak sistem berbasis file yang menempatkan tanggung jawab
pada pengguna untuk memberikan langkah-langkah supaya
melindungi data dari kegagalan ke sistem komputer atau program
aplikasi. Dalam hal kegagalan, cadangan recovery dari pekerjaan
yang telah di backup dimasukkan kembali. Sebaliknya, DBMS
17
modern menyediakan fasilitas untuk meminimalkan jumlah
pengolahan data yang hilang.
2. Kerugian
a. Kompleksitas (Complexity)
Penyediaan fungsi dari DBMS yang baik diharapkan akan
membuat DBMS menjadi perangkat lunak yang sangat komplek.
Database designers and developers, the data and database
administrator, dan end-user harus memahami fungsi ini untuk
mengambil keuntungan. Kegagalan untuk memahami sistem dapat
menyebabkan desain yang buruk, yang dapat memiliki konsekuensi
serius bagi suatu organisasi.
b. Ukuran (Size)
Kompleksitas dan besarnya fungsionalitas membuat DBMS
menjadi bagian yang sangat besar sebagai software yang
menempati banyak ruang disk dan membutuhkan memori yang
besar untuk menjalankan DBMS secara efisien.
c. Biaya DBMS (Cost of DBMS)
Biaya DBMS bervariasi, tergantung pada lingkungan dan fungsi
yang disediakan. Misalnya, DBMS single-user untuk komputer
pribadi hanya US $100. Namun, mainframe multi-user DBMS
yang melayani ratusan pengguna bisa sangat mahal yaitu sekitar
US $100.000 atau bahkan US $1.000.000. Ada juga tambahan
biaya untuk pemeliharaan setiap tahunnya.
d. Biaya hardware tambahan (Additional hardware cost)
Penyimpanan disk untuk DBMS dan basis data mungkin
memerlukan
pembelian
ruang
penyimpanan
tambahan.
Selanjutnya, untuk mencapai kinerja yang diinginkan, maka perlu
untuk membeli mesin yang lebih besar, bahkan mungkin sebuah
mesin yang khusus untuk menjalankan DBMS.
e. Biaya konversi (Cost of conversion)
Dalam beberapa situasi, biaya tambahan untuk DBMS dan
hardware bisa tidak sebanding dengan biaya konversi aplikasi yang
18
sudah ada untuk dijalankan pada DBMS dan hardware yang baru.
Biaya ini termasuk biaya pelatihan staff untuk menggunakan sistem
yang baru, dan memungkinkan untuk memperkerjakan staff ahli
untuk membantu konversi dan menjalankan sistem. Biaya
merupakan satu alasan utama mengapa beberapa organisasi merasa
terikat dengan sistem mereka saat ini dan tidak dapat beralih ke
teknologi basis data yang lebih modern.
f. Kinerja (Performance)
Biasanya sistem berbasis file dibuat untuk suatu aplikasi tertentu
seperti pemfakturan, sehingga kinerjanya sangat baik. Namun,
DBMS dibuat lebih umum sehingga dapat menangani beberapa
aplikasi secara bersamaan daripada satu aplikasi saja yang berjalan.
Akibatnya beberapa aplikasi yang berjalan kinerjanya tidak secepat
sebelumnya.
g. Dampak kegagalan (Higher impact of a failure)
Karena semua pengguna dan aplikasi bergantung pada ketersediaan
DBMS, kegagalan pada komponen-komponen tertentu dapat
mengakibatkan operasi berhenti.
2.1.5.3 Fungsi DBMS
Menurut Thomas Connolly dan Carolyn Begg (2005:48–52), ada beberapa
fungsi DBMS, yaitu:
1. Penyimpanan, pengambilan, dan memperbarui data (Data storage,
retrieval, and update)
DBMS harus melengkapi pengguna dengan kemampuan untuk
menyimpan, mengambil, dan data dalam basis data.
2. Katalog yang dapat diakses pengguna (a user – accessible catalog)
DBMS harus memiliki katalog di mana deskripsi item data disimpan
dan dapat diakses oleh pengguna.
3. Transaksi pendukung (Transaction support)
DBMS harus memberikan suatu mekanisme yang memastikan bahwa
semua pembaruan yang dibuat sesuai dengan transaksi yang diberikan
atau tidak satupun dari mereka yang membuat.
19
4. Layanan pengendalian concurrency (Concurrency control services)
DBMS harus menyediakan mekanisme untuk memastikan bahwa basis
data diperbarui dengan benar ketika beberapa pengguna memperbarui
basis data secara bersamaan.
5. Layanan perbaikan (Recovery Services)
DBMS harus memberikan suatu cara untuk memulihkan basis data
dengan cara apapun jika basis data sedang mengalami kerusakan.
6. Layanan otoritas (Authorization services)
DBMS harus menyediakan mekanisme untuk memastikan bahwa hanya
pengguna resmi yang dapat mengakses basis data.
7. Mendukung komunikasi data (Support for data communication)
DBMS harus mampu berintegrasi dengan komunikasi perangkat lunak.
8. Layanan integritas (Integrity services)
DBMS harus menyediakan sarana untuk memastikan bahwa data dalam
basis data dan perubahan data mengikuti aturan-aturan tertentu.
9. Layanan independensi data (Services to promote data independence)
DBMS harus mencakup fasilitas untuk mendukung kemandirian
program dari struktur yang sebenarnya dari basis data.
10. Layanan utilitas (Utility services)
DBMS harus menyediakan satu set layanan utilitas.
2.1.6 Bahasa Basis Data (Database Language)
Menurut Thomas Connolly dan Carolyn Begg (2005:39–41), Sebuah sub-bahasa
data terdiri dari dua bagian: Data Definition Language (DDL) dan Data
Manipulation Language (DML) DDL digunakan untuk menentukan skema basis
data dan DML digunakan untuk kedua membaca dan memperbarui basis data.
Bahasa ini disebut sub-bahasa data karena mereka tidak termasuk konstruksi
untuk semua komputasi kebutuhan seperti bersyarat atau pernyataan berulang,
yang disediakan oleh bahasa pemrograman tingkat tinggi.
2.1.6.1 Data Definition Language (DDL)
Menurut Thomas Connolly dan Carolyn Begg (2005:40), DDL adalah
sebuah bahasa yang memungkinkan DBA atau pengguna untuk
20
mendeskripsikan dan menamai entitas, atribut, dan relasi yang dibutuhkan
untuk aplikasi, bersama dengan integritas terkait dan kendala keamanan.
DDL digunakan untuk mendefinisikan skema atau memodifikasi yang
sudah ada. Hal ini tidak dapat digunakan untuk memanipulasi data.
Hasil penyusunan laporan DDL adalah satu set tabel yang disimpan dalam
khusus
file
kolektif
disebut
sistem
katalog.
Sistem
katalog
mengintegrasikan metadata, yaitu data yang menggambarkan objek dalam
basis data dan membuatnya lebih mudah bagi objek yang akan diakses
atau dimanipulasi. Metadata berisi definisi catatan, item data, dan bendabenda lain yang menarik bagi pengguna atau diwajibkan oleh DBMS.
2.1.6.2 Data Manipulation Language (DML)
Menurut Thomas Connolly dan Carolyn Begg (2005:40–42), DML adalah
sebuah bahasa yang menyediakan seperangkat operasi untuk mendukung
operasi manipulasi data dasar pada data yang dimiliki dalam basis data.
Operasi manipulasi data biasanya meliputi berikut ini:
1. Penyisipan data baru ke dalam basis data.
2. Modifikasi data yang disimpan dalam basis data.
3. Pengambilan data yang terdapat dalam basis data.
4. Penghapusan data dari basis data.
DML dibagi menjadi 2 jenis, yaitu procedural dan non-procedural.
Procedural DML adalah Sebuah bahasa yang memungkinkan pengguna
untuk memberitahu sistem data apa yang dibutuhkan dan bagaimana cara
untuk mendapatkan data. Sedangkan non-procedural DML adalah Sebuah
bahasa yang memungkinkan pengguna untuk menyatakan apa yang
dibutuhkan data daripada memikirkan bagaimana data tersebut harus
didapatkan.
Fungsi utama dari DBMS adalah untuk mendukung manipulasi data, di
mana pengguna dapat membuat laporan yang akan menyebabkan
manipulasi data tersebut terjadi. Manipulasi data berlaku untuk tingkat
eksternal, konseptual, dan internal. Namun, di tingkat internal yang kita
21
harus mendefinisikan prosedur tingkat rendah yang agak rumit yang
memungkinkan akses data yang efisien. Sebaliknya, di tingkat yang lebih
tinggi, penekanan ditempatkan pada kemudahan penggunaan dan usaha
diarahkan untuk memberikan interaksi pengguna yang efisien dengan
sistem. Bagian dari DML yang melibatkan pengambilan data disebut
bahasa query. Sebuah bahasa query dapat didefinisikan sebagai tingkat
tinggi dengan tujuan khusus, bahasa yang digunakan untuk memenuhi
permintaan beragam untuk pengambilan data dalam basis data.
2.1.7 Integrity Enhancement Feature
Menurut Thomas Connolly dan Carolyn Begg (2005:164–168) ada lima jenis
integrity constraint yaitu:
1. Required Data
Beberapa kolom harus berisi nilai yang valid dan tidak diperbolehkan
mengandung null. null berbeda dari kosong atau nol, karena digunakan untuk
merepresentasikan data yang tidak tersedia, atau tidak berlaku . Sebagai
contoh, setiap anggota staf harus memiliki posisi pekerjaan yang terkait
(misalnya, Manager, Asisten, dan sebagainya). Standar ISO menyediakan
kolom specifier NOT NULL di CREATE dan ALTER TABLE untuk
menyediakan tipe constraint. The ISO default adalah NULL. Sebagai contoh,
untuk menentukan bahwa posisi kolom dari tabel staf tidak dapat null, kita
mendefinisikan kolom sebagai:
Position VARCHAR (10) NOT NULL
2. Domain Constraints
Setiap kolom memiliki domain. Misalnya, jenis kelamin anggota staf adalah
'M' atau 'F', sehingga domain kolom jenis kelamin dari tabel staf adalah
karakter tunggal yang terdiri dari 'M' atau 'F'. Standar ISO menyediakan dua
mekanisme untuk menentukan domain dalam CREATE dan ALTER TABLE.
Yang pertama adalah CHECK, yang memungkinkan constraint didefinisikan
pada kolom atau seluruh tabel. Format CHECK adalah:
CHECK (SearchCondition)
22
Dalam kolom
constraint, CHECK dapat referensi hanya kolom yang
ditetapkan. Dengan demikian, untuk memastikan bahwa kolom jenis kelamin
hanya dapat ditetapkan sebagai 'M' atau 'F', kita bisa mendefinisikan kolom
sebagai:
CHAR seks NOT NULL CHECK (IN seks ('M', 'F'))
Namun, standar ISO memungkinkan domain harus didefinisikan secara lebih
eksplisit menggunakan CREATE DOMAIN:
CREATE DOMAIN DomainName [AS] dataType
[DEFAULT defaultOption]
[CHECK (searchCondition)]
3. Entity Integrity
Primary key dari tabel harus unik, memiliki nilai non-null di setiap baris.
Sebagai contoh, setiap baris dari tabel PropertyForRent memiliki nilai yang
unik untuk jumlah properti propertyNo, properti yang unik mengidentifikasi
di setiap baris. Standar ISO mendukung integritas entitas PRIMARY KEY di
CREATE dan ALTER TABLE. Sebagai contoh, untuk menentukan primary
key dari tabel PropertyForRent, yaitu:
PRIMARY KEY(propertyNo)
Untuk menentukan gabungan primary key, kita menentukan beberapa nama
kolom dalam PRIMARY KEY, dipisahkan dengan tanda koma. Sebagai
contoh, untuk menentukan primary key dari tabel Viewing, yang terdiri dari
kolom clientNo dan propertyNo, yaitu:
PRIMARY KEY(clientNo, propertyNo)
PRIMARY KEY ditentukan hanya sekali di setiap tabel. Namun, masih
mungkin untuk memastikan keunikan untuk setiap tombol alternatif dalam
tabel menggunakan kata kunci UNIQUE. Setiap kolom yang terdapat
UNIQUE juga harus dinyatakan sebagai NOT NULL. Mungkin ada banyak
UNIQUE di setiap tabel yang diperlukan. SQL untuk menolak setiap operasi
INSERT atau UPDATE yang mencoba untuk menciptakan nilai duplikat
dalam setiap candidate key (yaitu, primary key atau alternate key). Misalnya,
dengan tabel Viewing kita bisa juga menulis:
clientNo VARCHAR(5) NOT NULL,
propertyNo VARCHAR(5) NOT NULL, UNIQUE (clientNo, propertyNo)
23
4. Referential Integrity
Foreign key adalah kolom, atau set kolom, yang menghubungkan setiap baris
dalam tabel anak yang berisi foreign key ke baris dari tabel induk yang
mengandung nilai candidate key yang cocok. Referential integrity berarti, jika
foreign key mengandung nilai,maka nilai tersebut harus mengacu pada nilai
yang ada pada baris yang berlaku dalam tabel induk. Sebagai contoh, jumlah
cabang kolom branchNo dalam tabel PropertyForRent menghubungkan
properti untuk baris dalam tabel Branch di mana properti ditugaskan. Jika
nomor cabang tidak null, maka harus berisi nilai yang valid dari branchNo di
kolom tabel Branch, atau properti ditugaskan untuk kantor cabang yang tidak
valid. Standar ISO mendukung definisi foreign key dengan klausa FOREIGN
KEY di CREATE dan ALTER TABLE. Sebagai contoh, untuk menentukan
forign key branchNo dari tabel PropertyForRent, yaitu :
FOREIGN KEY(branchNo) REFERENCES Branch
SQL menolak setiap operasi INSERT atau UPDATE yang mencoba untuk
menciptakan nilai foreign key dalam tabel anak tanpa nilai candidate key yang
cocok dalam tabel induk. SQL diperlukan untuk setiap operasi UPDATE atau
DELETE yang mencoba untuk memperbarui atau menghapus nilai candidate
key dalam tabel induk yang memiliki beberapa baris yang cocok di tabel anak
tergantung pada tindakan referensial ditentukan menggunakan ON UPDATE
dan ON DELETE dari FOREIGN KEY. Ketika pengguna mencoba untuk
menghapus baris dari tabel induk, dan ada satu baris atau lebih cocok di tabel
anak, SQL mendukung empat pilihan mengenai tindakan yang harus diambil:
a. CASCADE: Menghapus baris dari tabel induk dan secara otomatis
menghapus baris dalam tabel anak yang sesuai. Karena ini baris dihapus
mungkin sendiri memiliki candidate key yang digunakan sebagai foreign
key dalam tabel lain, aturan foreign key untuk tabel adalah trigger, dan
juga secara cascading.
b. SET NULL: Menghapus baris dari tabel induk dan menetapkan nilai
foreign key dalam tabel anak ke NULL. Ini hanya berlaku jika kolom
foreign key tidak memiliki kualifikasi NOT NULL yang ditentukan.
24
c. SET DEFAULT: Menghapus baris dari tabel induk dan mengatur setiap
komponen foreign key dalam tabel anak dengan nilai default yang
ditentukan. Ini hanya berlaku jika kolom foreign key memiliki nilai
DEFAULT yang ditentukan.
d. NO ACTION: Menolak operasi telah terhapus dari tabel induk. Ini adalah
pengaturan default jika ON DELETE aturan dihilangkan.
FOREIGN KEY (staffNo) REFERENCES Staff ON DELETE SET NULL
FOREIGN KEY (ownerNo) REFERENCES PrivateOwner ON UPDATE
CASCADE
5. General Constraint
Memperbaharui tabel dapat dibatasi oleh aturan dari perusahaan yang
mengatur transaksi dunia nyata yang diwakili oleh pembaharuan. Sebagai
contoh, DreamHome mungkin memiliki aturan yang mencegah anggota staf
dari mengelola lebih dari 100 properti pada waktu yang sama. Standar ISO
memungkinkan kendala umum yang akan ditentukan menggunakan CHECK
dan UNIQUE dari CREATE dan ALTER TABLE dan CREATE ASSERTION.
Kita telah membahas CHECK dan klausa UNIQUE di awal bagian ini.
CREATE ASSERTION merupakan kendala integritas yang tidak terkait
langsung dengan definisi tabel. Format pernyataan itu adalah:
CREATE ASSERTION AssertionName
CHECK (searchCondition)
2.1.8 Pemodelan Relasi Entitas (Entity-Relatioship Modelling)
Menurut Thomas Connolly dan Carolyn Begg (2005:342), Pemodelan relasi
entitas (Entity-Relatioship Modelling) adalah pendekatan top-down untuk
merancang basis data yang dimulai dengan mengidentifikasi data penting yang
disebut entitas dan relasi antara data yang harus direpresentasikan dalam model.
Kemudian menambahkan rincian seperti informasi mengenai entitas dan relasi
yang disebut atribut. Dan setiap kendala pada entitas, relasi, dan atribut.
Pemodelan ER adalah teknik penting untuk setiap perancang basis data untuk
menguasai dan membentuk dasar dari metodologi yang disajikan.
25
2.1.8.1 Entity Types
Menurut Thomas Connolly dan Carolyn Begg (2005:343), Entity types
adalah sekelompok objek dengan sifat yang sama, yang diidentifikasi oleh
perusahaan seperti memiliki eksistensi independen.
Menurut Thomas Connolly dan Carolyn Begg (2005:345), Entity
occurrence adalah Sebuah objek yang unik yang bisa diidentifikasikan dari
suatu entity.
Secara umum, Tipa entitas dapat diklasifikasikan menjadi :
1. Strong Entity Type
Menurut Thomas Connolly dan Carolyn Begg (2005:354), Strong Entity
Type adalah Sebuah tipe entitas yang keberadaannya tidak tergantung
pada beberapa tipe entitas lainnya. Sebuah tipe entitas disebut kuat jika
keberadaannya tidak tergantung pada keberadaan tipe entitas lain.
2. Weak Entity Type
Menurut Thomas Connolly dan Carolyn Begg (2005:355), Weak entity
type adalah Sebuah tipe entitas yang keberadaannya tergantung pada
beberapa tipe entitas lainnya. Jenis weak entity kadang-kadang disebut
sebagai anak, ketergantungan, atau entitas bawahan dan jenis strong
entity sebagai orangtua, pemilik, atau badan yang dominan.
2.1.8.2 Relationship Types
Menurut Thomas Connolly dan Carolyn Begg (2005:346), Relationship
types adalah sekumpulan relasi antar entitas yang memiliki arti. Dan Setiap
jenis relasi yang terjadi diberi nama yang menggambarkan fungsi.
Relationship Occurance adalah suatu relasi unik antara satu atau lebih entitas
yang teridentifikasi dalam tipe entitas.
2.1.8.3 Atribute
Menurut Thomas Connolly dan Carolyn Begg (2005:350), Attribute adalah
sebuah properti dari suatu entitas atau tipe relasi. Sedangkan attribute
domain adalah himpunan nilai-nilai yang di ijinkan untuk satu atau lebih
atribut.
26
Attribute dapat diklasifikasikan sebagai berikut, yaitu:
1. Simple attribute
Menurut Thomas Connolly dan Carolyn Begg (2005:351), simple
attribute adalah sebuah atribut yang terdiri dari komponen tunggal
dengan keberadaan yang independen.
2. Composite attribute
Menurut Thomas Connolly dan Carolyn Begg (2005:351), composite
attribute adalah sebuah atribut yang terdiri dari beberapa komponen,
masing-masing dengan keberadaan yang independen.
3.
Single-valued attribute
Menurut Thomas Connolly dan Carolyn Begg (2005:351), Singlevalued attribute adalah sebuah atribut yang memegang nilai tunggal
untuk setiap kejadian dari suatu tipe entitas.
4.
Multi-valued attribute
Menurut Thomas Connolly dan Carolyn Begg (2005:352), Multivalued attribute adalah sebuah atribut yang memegang beberapa nilai
untuk setiap kejadian dari suatu entity.
5.
Derived attribute
Menurut Thomas Connolly dan Carolyn Begg (2005:352), Derived
attribute adalah sebuah atribut yang mewakili nilai yang diturunkan
dari nilai atribut terkait atau himpunan atribut, belum tentu dalam
jenis entitas yang sama.
2.1.8.4 Kunci (Keys)
1. Candidate Key
Menurut Thomas Connolly dan Carolyn Begg (2005:352), Candidate
Key
adalah
sejumlah
kecil
atribut
unik
dari
entitas
yang
mengidentifikasikan setiap kejadian dari suatu tipe entitas.
2. Primary Key
Menurut Thomas Connolly dan Carolyn Begg (2005:353), Primary
key adalah candidate key yang dipilih karena unik untuk
mengidentifikasi setiap kejadian dari suatu tipe entitas.
27
3. Composite Key
Menurut Thomas Connolly dan Carolyn Begg (2005:353), Composite
key adalah candidate key yang terdiri dari dua atau lebih atribut.
4. Alternate Key
Menurut Thomas Connolly dan Carolyn Begg (2005:79), Alternate
Key adalah
Candidate Key yang tidak terpilih menjadi primary key.
5. Forign Key
Menurut Thomas Connolly dan Carolyn Begg (2005:79), Foreign key
adalah Sebuah atribut atau sekumpulan atribut dalam satu relasi yang
sama dengan candidate key beberapa relasi lainnya.
6. Super Key
Menurut Thomas Connolly dan Carolyn Begg (2005:79), Super key
adalah Sebuah atribut atau sekumpulan atribut, yang secara unik
mengidentifikasi tuple dalam relasi.
2.1.8.5 Structural Constraint
Berikut ini merupakan kendala yang dapat terjadi di dalam sebuah relas,
yaitu sebagai berikut:
1. Multiplicity
Menurut Thomas Connolly dan Carolyn Begg (2005:356), Multiciplity
adalah kejadian dari suatu entity yang mungkin berelasi dengan
kejadian dari tipe entitas terkait melalui relasi tertentu. Kami menguji
tiga jenis relasi menggunakan kendala integritas berikut :
a. One-to-One (1:1) Relationship
b. One-to-Many (1:*) Relationships
c. Many-to-Many (*:*) Relationships
2. Multiplicity for Complex Relationships
Menurut Thomas Connolly dan Carolyn Begg (2005:361), Multiplicity
for Complex Relationships adalah kejadian dari tipe entitas dalam
relasi ketika yang lain (n-1) nilainya tetap.
Multiplicity sebenarnya terdiri atas dua constraint yang berbeda, yaitu:
28
a. Cardinality
Menurut Thomas Connolly dan Carolyn Begg (2005:363),
Cardinality menjelaskan mengenai jumlah relasi maksimum yang
memungkinkan terjadinya entitas yang berpartisipasi dalam tipe
relasi tertentu.
b. Participant
Menurut Thomas Connolly dan Carolyn Begg (2005:363),
Participant menentukan apakah semua atau hanya beberapa
entitas saja yang berpartisipasi dalam suatu relasi.
2.1.9 Entity Relationship Diagram (ERD)
Menurut Thomas Connolly dan Carolyn Begg (2005:343), konsep dasar model
Entity-Relationship, yaitu entitas, relasi, dan atribut. Dalam setiap bagian
menggambarkan bagaimana konsep-konsep dasar ER diwakili dan digambarkan
dalam diagram ER menggunakan UML.
Menurut Indrajani (2011:18), Entity Relational (ER) Modeling adalah sebuah
pendekatan top-down dalam perancangan basis data yang dimulai dengan
mengidentifikasikan data-data terpenting yang disebut dengan entitas dan
hubungan antara entitas-entitas tersebut yang digambarkan dalam suatu model.
2.1.10 Normalisasi (Normalization)
Menurut Thomas Connolly dan Carolyn Begg (2005:388), Normalisasi adalah
Sebuah teknik untuk menghasilkan himpunan relasi dengan properti yang
diinginkan, yang sesuai dengan kebutuhan data dari suatu perusahaan.
Menurut Thomas Connolly dan Carolyn Begg (2005:403), Unormalized Form
(UNF) adalah sebuah tabel yang berisi satu atau lebih kelompok berulang.
Berikut ini merupakan tahap tingkatan normalisasi:
1. First Normal Form (1NF)
Menurut Thomas Connolly dan Carolyn Begg (2005:403), First Normal
Form (1NF) adalah Sebuah relasi dimana setiap baris dan kolom berisi
satu dan hanya satu nilai, tidak ada perhitungan. Sebuah relasi akan berada
dalam bentuk 1NF jika repeating group sudah hilang. Ada dua pendekatan
29
untuk menghilangkan repeating group pada tabel yang tidak normal
(unnormalized table), yaitu:
a. Dengan memasukkan data yang sesuai kedalam kolom yang kosong
dari basis yang mengandung kata yang berulang.
b. Dengan menempatkan data yang berulang bersama salinan dari atribut
kunci pada relasi yang terpisah.
2. Second Normal Form (2NF)
Menurut Thomas Connolly dan Carolyn Begg (2005:407), Second Normal
Form (2NF) adalah suatu relasi yang ada dalam Bentuk Normal Pertama
dan setiap atribut bukan non-primer-key sepenuhnya fungsionalitas
tergantung pada primary key.
c.
Third Normal Form (3NF)
Menurut Thomas Connolly dan Carolyn Begg (2005:409), Third Normal
Form (3NF) adalah suatu relasi yang ada di Bentuk Normal Pertama dan
Kedua dan di mana tidak ada atribut non-primer-key transitif bergantung
pada primary key.
Menurut Thomas Connolly dan Carolyn Begg (2005:409), Third Normal
Form (3NF) adalah suatu relasi yang ada di Bentuk Normal Pertama dan
Kedua dan di mana tidak ada atribut non-primer-key transitif bergantung
pada primary key.
d. Boyce Codd Normal Form (BCNF)
Menurut Thomas Connolly dan Carolyn Begg (2005:419), Boyce Codd
Normal Form (BCNF) adalah suatu relasi yang ada pada BCNF, jika, setiap
determinan adalah kunci kandidat.
e.
Fourth Normal Form (4NF)
Menurut Thomas Connolly dan Carolyn Begg (2005:430), Fourth Normal
Form (4NF) adalah sebuah relasi yang ada pada bentuk normal Boyce-Codd
dan tidak mengandung ketergantungan banyak nilai.
f. Fifth Normal Form (5NF)
Menurut Thomas Connolly dan Carolyn Begg (2005:431), Fifth Normal
Form (5NF) adalah sebuah relasi yang tidak ketergantungan yang
bergabung.
30
2.1.11 Database Application Lifecycle (DBLC)
Gambar 2.2 Database System Development Lifecycle (DBLC)
31
Menurut Thomas Connolly dan Carolyn Begg (2005:284), Dalam merancang
aplikasi sistem basis data diperlukan tahapan-tahapan terstruktur yang harus
diikuti, tahapan-tahapan tersebut dinamakan lifecycle aplikasi basis data.
Tahapan-tahapan dari lifecycle aplikasi basis data adalah sebagai berikut:
Tabel 2.1 Penjelasan Database System Development Lifecycle (DBLC)
Perencanaan basis data
Perencanaan bagaimana tahapan lifecycle
dapat direalisasikan secara efisien dan
(database planning)
efektif.
Menentukan ruang lingkup dan batas-
Definisi sistem
batas dari sistem basis data, termasuk
(system definition)
pandangan utama pengguna, dan area
aplikasi.
Analisis dan pengumpulan kebutuhan
Pengumpulan dan analisis persyaratan
(requirements collection and analysis)
untuk sistem basis data baru.
Perancangan basis data
(database design)
Seleksi DBMS
(DBMS selection) (optional)
Perancangan aplikasi
Perancangan konseptual, logikal, dan
fisikal dari basis data.
Memilih DBMS yang cocok untuk
sistem basis data.
Merancang user interface dan program
aplikasi
(application design)
yang
menggunakan
dan
memproses basis data.
Membangun model kerja dari sistem
basis data, yang memungkinkan para
Prototipe
(prototyping) (optional)
desainer
atau
memvisualisasikan
pengguna
dan
untuk
mengevaluasi
bagaimana sistem akhir akan terlihat dan
berfungsi.
32
Implementasi
(implementation)
Membuat definisi basis data fisik dan
program aplikasi.
Mengambil data dari sistem lama ke
Konversi data dan loading
sistem baru dan jika memungkinkan,
(data conversion and loading)
mengubah aplikasi yang ada untuk
dijalankan pada basis data baru .
Pengujian
Sistem basis data diuji untuk kesalahan
dan divalidasi terhadap persyaratan yang
(testing)
ditentukan oleh pengguna .
Sistem
basis
dilaksanakan
data
lalu
sepenuhnya
sistem
ini
terus
Operasi pemeliharaan
dipantau dan dipelihara. Bila perlu,
(operational maintenance)
persyaratan baru dimasukkan ke dalam
sistem
basis
data
melalui
tahap
sebelumnya dari lifecycle .
2.1.12 Relasi Kunci (Relational Keys)
1. Candidate key
Set minimal attribut yang unik mendefinisikan setiap kejadian pada
suatu entity. (Thomas Connolly dan Carolyn Begg, 2005:352)
2. Primary key
Kandidat kunci unik yang dipilih untuk mengidentifikasikan setiap
kejadian dari suatu entity. (Thomas Connolly dan Carolyn Begg,
2005:353)
3. Composite key
Kandidat kunci yang terdiri dari dua atau lebih attribut (Thomas
Connolly dan Carolyn Begg, 2005:353)
33
2.1.13 Strong and Weak Entity Types
Menurut Thomas Connolly dan Carolyn Begg (2005:354), Tipe entitas adalah
sekelompok objek dengan sifat yang sama, yang di identifikasi oleh perusahaan
yang independen keberadaannya.
Ada 2 jenis tipe entitas, yaitu:
1. Tipe entitas kuat (Strong entity types)
Sebuah tipe entitas yang keberadaannya tidak tergantung pada beberapa tipe
entitas lainnya. (Thomas Connolly dan Carolyn Begg, 2005:354).
2. Tipe entitas lemah (Weak entity types)
Sebuah tipe entitas yang keberadaannya tergantung pada beberapa tipe
entitas lainnya. (Thomas Connolly dan Carolyn Begg, 2005:355).
2.1.14 Perencanaan Basis Data (Database Planning)
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:285),
perencanaan basis data adalah aktivitas pengelolaan yang memungkinkan
tahapan dari siklus hidup basis data (Database Lifecycle) untuk direalisasikan
seefisien dan seefektif mungkin. Perencanaan basis data harus terintegrasi
dengan keseluruhan system informasi. Ada dua hal utama dalam merumuskan
strategi sistem informasi, yaitu:
1. Identifikasi rencana dan tujuan perusahaan dengan Kebutuhan sistem
informasi perusahaan berikutnya.
2. Evaluasi sistem informasi saat ini untuk menentukan kekuatan dan kelemahan
yang ada saat ini.
Melakukan penilaian Teknologi Informasi yang mungkin memiliki peluang
untuk menghasilkan keunggulan yang kompetitif.
2.1.15 Definisi Sistem (System Definition)
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:286),
definisi sistem menjelaskan mengenai ruang lingkup dan batasan dari aplikasi
basis data dan pandangan pengguna lain. Sebelum mencoba untuk merancang
sebuah sistem basis data, hal penting yang harus dilakukan adalah
34
mengidentifikasi batasan-batasan dari sistem yang sedang diselidiki. Hal ini
sangat penting dilakukan dalam proses perancangan basis data agar lebih
terfokus pada sistem yang akan dibuat.
2.1.15.1 Tampilan Pengguna (User Views)
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:287),
tampilan pengguna Mendefinisikan apa yang dibutuhkan dari sistem basis data
dari perspektif peran maupun pekerjaan tertentu (seperti Manager atau
Supervisor) atau bidang aplikasi enterprise (seperti pemasaran, personalia, atau
stok kontrol). Sebuah sistem basis data dapat memiliki satu atau lebih
pandangan pengguna. Mengidentifikasi pandangan pengguna merupakan aspek
penting pengembangan sistem basis data karena membantu untuk memastikan
bahwa tidak ada pengguna utama basis data dilupakan ketika mengembangkan
persyaratan untuk sistem basis data baru.
2.1.16 Pengumpulan dan Analisis Kebutuhan
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:287),
Pengumpulan dan Analisis Kebutuhan adalah Proses mengumpulkan dan
menganalisis informasi tentang bagian dari organisasi yang akan didukung oleh
sistem basis data, dan menggunakan informasi ini untuk mengidentifikasi
persyaratan untuk sistem baru.
Tahap ini melibatkan pengumpulan dan analisis informasi mengenai bagian dari
perusahaan yang akan dilayani oleh basis data. Ada banyak teknik untuk
mengumpulkan informasi ini yang disebut teknik pencarian fakta. Informasi
yang dikumpulkan meliputi :
1. deskripsi data yang digunakan atau yang dihasilkan.
2. rincian tentang bagaimana data akan digunakan atau dihasilkan.
3. persyaratan tambahan untuk sistem basis data baru.
Kegiatan penting lainnya yang terkait dengan tahap ini adalah memutuskan
bagaimana menangani situasi jika lebih dari satu tampilan pengguna untuk
sistem basis data. Ada tiga pendekatan utama untuk mengelola persyaratan
sistem basis data dengan beberapa tampilan pengguna, yaitu :
1. pendekatan terpusat (the centralized approach)
Kebutuhan untuk tiap pandangan pemakai disatukan menjadi satu set
35
kebutuhan untuk aplikasi basis data. Umumnya pendekatan ini dipakai jika
basis datanya tidak terlalu kompleks.
2. pendekatan integrasi pandangan (the view integration approach)
Kebutuhan untuk tiap pandangan pemakai digunakan untuk membangun
sebuah model yang terpisah yang mepresentasikan tiap pandangan pemakai
tersebut. Hasil dari data-data model tersebut kemudian digabung
dalam rancangan basis data.
3. kombinasi kedua pendekatan tersebut (a combination of both approaches)
2.1.17 Perancangan Basis Data (Database Design)
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:291),
Perancangan basis data adalah proses menciptakan desain yang akan
mendukung pernyataan dan tujuan misi perusahaan untuk sistem basis data yang
diperlukan.
Pada bagian ini akan membahas mengenai gambaran dari pendekatan utama
untuk desain basis data. Selain itu juga mendiskusikan tujuan dan penggunaan
pemodelan data dalam desain basis data. tiga tahapan desain basis data yaitu
desain konseptual, logikal, dan fisikal.
Pendekatan dalam perancangan basis data, antara lain :
1. Bottom-Up
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:291),
bottom-up dimulai pada tingkat dasar atribut (yaitu, sifat entitas dan relasi),
yang melalui analisis relasi antara atribut, dikelompokkan ke dalam relasi
yang mewakili jenis entitas dan relasi antar entitas.
2. Top-Down
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:292),
Top-Down merupakan Sebuah strategi yang lebih tepat untuk desain basis
data yang. Pendekatan ini dimulai dengan pengembangan model data yang
berisi entitas dan relasi tingkat tinggi dan kemudian menerapkan perbaikan
top-down untuk mengidentifikasi entitas tingkat rendah, relasi, dan atribut
yang terkait. Pendekatan top-down diilustrasikan menggunakan konsep
36
Entity-Relationship (ER) model, dimulai dengan identifikasi entitas dan
relasi antara entitas, yang menarik bagi organisasi.
3. Inside-Out
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:292),
Pendekatan inside-out berkaitan dengan pendekatan bottom-up tetapi
berbeda, dengan terlebih dahulu mengidentifikasi satu set entitas utama dan
kemudian menyebar keluar untuk mempertimbangkan entitas lain, relasi,
dan atribut yang berelasi dengan yang pertama kali diidentifikasi.
4. Mixed Strategy
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg (2005:292),
Pendekatan strategi campuran menggunakan kedua pendekatan bottom-up
dan top-down untuk berbagai bagian dari model sebelum akhirnya
menggabungkan semua bagian bersama-sama.
2.1.17.1 Perancangan Basis Data Konseptual (Conceptual Database
Design)
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg
(2005:293), Perancangan basis data konseptual adalah proses membangun
sebuah model dari data yang digunakan dalam suatu perusahaan,
independen dari semua pertimbangan fisikal.
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg
(2005:442), Tujuan perancangan basis data konseptual adalah untuk
membangun sebuah model data konseptual dari persyaratan data dari
perusahaan.
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg
(2005:440–459), Langkah-langkah dalam membangun model data
konseptual adalah sebagai berikut :
1. Membangun model data konseptual
a. Langkah 1.1
: Mengdentifikasi tipe entitas
b. Langkah 1.2
: Mengidentifikasi tipe relasi
c. Langkah 1.3
: Mengidentifikasi dan mengasosiasikan atribut
dengan entitas atau relasi jenis
37
d. Langkah 1.4
: Menentukan domain atribut
e. Langkah 1.5
: Menentukan candidate, primary, and alternate
key attributes
f. Langkah 1.6
: Mempertimbangkan penggunaan konsep
model yang disempurnakan (langkah
opsional)
g. Langkah 1.7
: Memeriksa model untuk redundansi
h. Langkah 1.8
: Validasi model konseptual terhadap transaksi
pengguna
i. Langkah 1.9
: Ulasan model data konseptual dengan
pengguna
Berikut adalah penjelasan dari langkah-langkah diatas.
1. Langkah 1 : Membangun model data konseptual
membangun model data konseptual sesuai dengan kebutuhan data pada
perusahaan, Tahap pertama dalam perancangan basis data konseptual
adalah membangun satu atau lebih model data konseptual yang sesuai
dengan kebutuhan data dari perusahaan. (Thomas Connolly dan
Carolyn Begg, 2005:442–443)
Tahapan-tahapan yang dilakukan pada langkah pertama adalah :
1. Langkah 1.1 : Mengidentifikasi tipe entitas
Mendefinisikan
objek-objek
utama
user.
Objek-objek
ini
merupakan tipe-tipe entitas untuk model tersebut. Salah satu
metode untuk mengidentifikasi entitas adalah dengan memeriksa
spesifikasi kebutuhan user dengan mengidentifikasi kata benda.
Contohnya adalah staff number, staff name, property number,
property room dan sebagainya. (Thomas Connolly dan Carolyn
Begg, 2005:443–444)
2. Langkah 1.2 : Mengidentifikasi tipe relasi
Setelah mengidentifikasi tipe entitas, langkah selanjutnya yaitu
mengidentifikasikan semua relasi-relasi penting yang ada diantara
tipe
entitas
yang
telah
diidentifikasikan.
Setelah
38
mengidentifikasikan relasi, langkah selanjutnya yaitu menentukan
multiplicity dari setiap relasi. Batasan multiply digunakan untuk
memeriksa dan memelihara kualitas data. (Thomas Connolly dan
Carolyn Begg, 2005:445–447)
3. Langkah 1.3 : Mengidentifikasi dan menghubungkan atribut
dengan tipe entitas atau relationship
Langkah berikutnya yaitu mengidentifikasi atribut-atribut yang
terdapat dalam suatu entitas. Biasanya berupa kata benda atau
frasa kata benda dari spesifikasi kebutuhan user. Ada 3 jenis
atribut, yaitu : Simple atau composite attributes, single atau multivalue attributes, derived attributes. (Thomas Connolly dan
Carolyn Begg, 2005:447–450)
4. Langkah 1.4 : Menentukan domain atribut
Tahap ini bertujuan untuk menentukan domain atribut di model
data konseptual lokal. Domain merupakan kumpulan nilai-nilai
yang diperbolehkan untuk satu atau lebih atribut. Sebuah model
data yang baik menentukan domain untuk setiap atribut dan
termasuk sekumpulan nilai-nilai yang diperbolehkan untuk atribut
juga ukuran dan format dari atribut. (Thomas Connolly dan
Carolyn Begg, 2005:450-451)
5. Langkah 1.5 : Menentukan atribut candidate key, primary key,
dan alternate key
Candidate key adalah kunci yang unik atau tidak mungkin sama
atau
berbeda
dengan
yang
lain,
dapat
dipakai
untuk
mengidentifikasi satu baris dalam tipe entitas. Primary key adalah
candidate key yang dipilih sebagai kunci primer untuk
mengidentifikasikan setiap entitas. Langkah ini bertujuan untuk
mengidentifikasi candidate key untuk setiap tipe entitas, jika
terdapat lebih dari satu candidate key kemudian pilih salah
satunya menjadi primary key. Alternate key merupakan candidate
key yang tidak dipilih menjadi primary key. (Thomas Connolly
dan Carolyn Begg, 2005:451–452)
39
6. Langkah 1.6 : Mempertimbangkan penggunaan enhanced
modeling concepts (optional step)
Mempertimbangkan penggunaan enhanced modeling concepts
seperti specialization atau generalization, aggregation, dan
composition. Jika memilih pendekatan specialization, usahakan
untuk
memperhatikan
perbedaan
antara
entitas
dengan
mendefinisikan satu atau lebih subclass dari sebuah entitas
superclass.
Jika
memilih
menggunakan
pendekatan
generalization, usahakan untuk mengidentifikasikan fitur-fitur
umum antara entitas untuk mendefinisikan generalisasi entitas
superclass.
Pendekatan
aggregation
digunakan
untuk
mempresentasikan relasi “mempunyai sesuatu” atau “bagian dari”
relasi antara tipe-tipe entitas, dimana yang satu mempresentasikan
“keseluruhan” dan yang lain sebagai “bagiannya”. Pendekatan
composition digunakan untuk mempresentasikan sebuah asosiasi
antara tipe-tipe entitas dimana terdapat kepemilikan yang kuat
dan relasi antara “keseluruhan” dan “bagiannya”. (Thomas
Connolly dan Carolyn Begg 2005:453–481)
7. Langkah 1.7 : Cek model untuk redudansi
Tahap ini bertujuan untuk memeriksa model data konseptual
lokal, apakah masih ada redudansi pada model. Dua aktivitas
pada tahap ini, yaitu :
i. Memeriksa kembali relasi one-to-one (1 :1)
Saat identifikasi entitas, mungkin saja kita menemukan dua
entitas yang merepresentasikan objek yang sama pada
perusahaan. Untuk kejadian ini kedua entitas tersebut harus
digabungkan. Jika primary key berbeda, pilih salah satu
untuk menjadi primary key dan biarkan yang lain menjadi
alternate key.
ii. Menghilangkan relasi yang redundan
Data model yang baik sangat diharapkan untuk tidak
memiliki relasi yang redudan. Suatu relasi dikatakan
40
redudansi jika terdapat informasi yang sama yang
diperbolehkan oleh relasi lain.
iii. Mempertimbangkan dimensi waktu Dimensi waktu dalam
relasi
sangat
penting dalam menentukan
redudansi.
(Thomas Connolly dan Carolyn Begg, 2005:453–456)
8. Langkah 1.8 : Validasi model konseptual lokal dengan transaksi
user
Tahap ini bertujuan untuk memastikan bahwa model konseptual
mendukung kebutuhan transaksi yang diperlukan bagi view. Dua
pendekatan untuk memastikan model data konseptual mendukung
kebutuhan transaksi, yaitu:
i.
Mendeskripsikan transaksi
Memeriksa apakah semua informasi (entitas, relasi, dan
atributnya) yang dibutuhkan oleh setiap transaksi telah
disediakan oleh model, dengan mendokumentasikan
sebuah deskripsi dari setiap kebutuhan transaksi.
ii.
Menggunakan jalur transaksi
Memvalidasi model data terhadap kebutuhan transaksi
yang melibatkan diagram yang merepresentasikan jalur
setiap transaksi dalam diagram ER. (Thomas Connolly dan
Carolyn Begg, 2005:456–458)
9. Langkah 1.9 : Meninjau kembali model data konseptual lokal
dengan user Pada langkah ini, user akan meninjau ulang model
data konseptual. Jika terjadi anomali pada model data, maka harus
dilakukan perubahan yang mungkin memerlukan pengulangan
langkah-langkah sebelumnya. Proses ini akan terus diulang
sampai model data benar-benar menjadi representasi aktual dari
perusahaan. (Thomas Connolly dan Carolyn Begg, 2005:458)
2.1.17.2 Perancangan Basis Data Logikal (Logical Database Design)
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg
(2005:294), Perancangan basis data logikal adalah proses membangun
sebuah model dari data yang digunakan dalam suatu perusahaan
41
berdasarkan pada model data yang spesifik, tetapi independen dari DBMS
tertentu dan pertimbangan fisik lainnya.
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg
(2005:442), Tujuan perancangan basis data logikal adalah untuk
menerjemahkan model data konseptual menjadi model data logikal dan
kemudian untuk memvalidasi model ini untuk memeriksa bahwa itu secara
struktural benar dan mampu mendukung transaksi yang diperlukan.
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg
(2005:462–493) Langkah-langkah dalam membangun model data logikal
adalah sebagai berikut:
2. Langkah 2 : Membangun model data logikal
a. Langkah 2.1
: Menurunkan relasi untuk model data logikal
b. Langkah 2.2
: Validasi relasi dengan menggunakan
normalisasi
c. Langkah 2.3
: Validasi relasi terhadap transaksi pengguna
d. Langkah 2.4
: Memeriksa kendala integritas
e. Langkah 2.5
: Meninjau kembali model data logikal dengan
pengguna
f. Langkah 2.6
: Menggabungkan model data logikal ke dalam
model global (optional step)
g. Langkah 2.7
: Memeriksa perkembangan di masa depan
Berikut adalah penjelasan dari langkah-langkah diatas.
a. Langkah 2.1 : Menurunkan relasi untuk model data logikal
Tahap ini bertujuan untuk membuat relasi untuk model data
logikal untuk merepresentasikan entitas, relasi dan atribut yang
telah diidentifikasikan. 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 (*:*),
42
tipe relasi kompleks, atribut multi-valued. (Thomas Connolly dan
Carolyn Begg, 2005:463–472)
b. Langkah 2.2 : Validasi relasi menggunakan normalisasi
Normalisasi digunakan untuk memastikan relasi dan atribut yang
mendukung kebutuhan dari perusahaan. Juga redudansi data yang
minimal pada relasi untuk menghindari masalah yang mungkin
terjadi. Proses normalisasi terdiri dari UNF, 1NF, 2NF, 3NF.
(Thomas Connolly dan Carolyn Begg, 2005:473–474)
c. Langkah 2.3 : Validasi relasi terhadap transaksi pengguna.
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. 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. (Thomas Connolly dan Carolyn Begg,
2005:474)
d. Langkah 2.4 : Memeriksa kendala integritas.
Kendala integritas adalah batasan-batasan yang harus ditentukan
untuk melindungi basis data agar tetap konsisten (Thomas
Connolly dan Carolyn Begg, 2005:474–478)
Tipe integrity constraint, yaitu :
i. required data
ii. attribute domain constraints
iii. multiplicity
iv. entity integrity
v. referential integrity
vi. general constraints
43
e. Langkah 2.5 : Meninjau Kembali model data logikal dengan
pengguna
Tahapan ini Untuk meninjau model data logikal dengan pengguna
dan untuk memastikan bahwa mereka mempertimbangkan model
data yang terbentuk merupakan representasi data perusahaan
tersebut. (Thomas Connolly dan Carolyn Begg, 2005:478–479)
f. Langkah 2.6 : Menggabungkan model data logikal ke dalam
model global (optional step)
Tahapan ini bertujuan untuk menggabungkan model data logical
local ke dalam data model single global logical yang mewakili
semua user views dari basis data. Aktivitas dalam tahap ini, yaitu:
i. Menggabungkan model data logikal lokal ke dalam model
global,
ii. Validasi model data logikal global,
iii. Meninjau kembali model data logikal global dengan user
(Thomas Connolly dan Carolyn Begg, 2005:479–590).
g. Langkah 2.7 : Memeriksa perkembangan di masa depan
Tujuan dari tahap ini adalah untuk menentukan apakah ada
perubahan
yang
signifikan
di
masa
depan
dan
untuk
memperkirakan apakah model data logikal bisa mengakomodasi
perubahan tersebut. (Thomas Connolly dan Carolyn Begg,
2005:490)
2.1.17.3 Perancangan Basis Data Fisikal (Physical Database Design)
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg
(2005:294), Perancangan basis data fisikal adalah proses dalam
menghasilkan deskripsi implementasi basis data pada secondary storage,
hal ini menggambarkan relasi dasar, organisasi file, dan indeks yang
digunakan untuk mencapai akses yang efisien terhadap data, setiap kendala
integritas yang terkait dan tahap – tahap keamanan.
44
Menurut Thomas Thomas Connolly dan Carolyn Carolyn Begg
(2005:496–517), Langkah-langkah dalam membangun model data logikal
adalah sebagai berikut :
3. Langkah 3
: Menerjemahkan model data logikal global
untuk sasaran DBMS
a. Langkah 3.1
: Merancang relasi dasar
b. Langkah 3.2
: Merancang representasi dari derived data
c. Langkah 3.3
: Merancang kendala umum
4. Langkah 4
: Merancang organisasi file dan indeks
a. Langkah 4.1
: Menganalisa transaksi
b. Langkah 4.2
: Memilih organisasi file
c. Langkah 4.3
: Memilih indeks
d. Langkah 4.4
: Memperkirakan kebutuhan ruang disk
5. Langkah 5
: Mendesain user view
6. Langkah 6
: Mendesain mekanisme keamanan
7. Langkah 7
: Mempertimbangkan petunjuk controlled
redundancy
8. Langkah 8
: Memonitor dan memperbaiki sistem
operasional
Berikut adalah penjelasan dari langkah-langkah diatas.
3. Langkah 3 : Menerjemahkan model data logikal global untuk sasaran
DBMS
Langkah ini bertujuan untuk menghasilkan skema basis data relational
dari model data logikal yang dapat diimplementasikan pada DBMS
pilihan. 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. (Thomas Connolly
dan Carolyn Begg, 2005:497–498)
a. Langkah 3.1 : Merancang relasi dasar
Menentukan bagaimana mempresentasikan relasi dasar dalam
model data logikal ke dalam DBMS.
45
(Thomas Connolly dan Carolyn Begg, 2005:498–499)
b. Langkah 3.2: Merancang representasi dari derived data
Menentukan bagaimana mempresentasikan beberapa derived data
yang terdapat dalam model data logikal ke dalam DBMS.
(Thomas Connolly dan Carolyn Begg, 2005:499–501)
c. Langkah 3.3 : Merancang kendala umum
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. (Thomas
Connolly dan Carolyn Begg, 2005:501)
4. 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 basis
data akan dipegang di tempat penyimpanan akhir sekunder. (Thomas
Connolly dan Carolyn Begg, 2005:501–502)
a. Langkah 4.1 : Menganalisa transaksi
Analisa transaksi berfungsi untuk memahami fungsi dari transaksi
yang akan dijalankan pada basis data dan untuk menganalisa
transaksi yang penting. (Thomas Connolly dan Carolyn Begg,
2005:502–506)
b. Langkah 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. (Thomas Connolly dan Carolyn Begg, 2005:506–508)
c. Langkah 4.3 : Memilih indeks
Menentukan
apakah
dengan
meningkatkan kinerja dari sistem.
menambahkan
indeks
akan
46
(Thomas Connolly dan Carolyn Begg, 2005:508–514)
d. Langkah 4.4 : Memperkirakan kebutuhan ruang disk
Memperkirakan jumlah dari disk space yang dibutuhkan untuk
mendukung implementasi basis data pada secondary storage.
(Thomas Connolly dan Carolyn Begg, 2005:514–515)
5. Langkah 5 : Mendesain user view
Mendesain user view yang telah diidentifikasi selama pengumpulan
kebutuhan. (Thomas Connolly dan Carolyn Begg, 2005:515–516)
6. Langkah 6 : Mendesain mekanisme keamanan
Membatasi pengaksesan basis data oleh user yang tidak berhak dan
menspesifikasikan basis data yang dapat diakses oleh user. (Thomas
Connolly dan Carolyn Begg, 2005:516)
7. Langkah7 : Mempertimbangkan petunjuk controlled redundancy
Melakukan normalisasi agar dapat meningkatkan kinerja dari sistem
dan menghilangkan redudansi. (Thomas Connolly dan Carolyn Begg,
2005:519)
8. Langkah 8 : Memonitor dan memperbaiki sistem operasional
Memonitor sistem operasional dan meningkatkan kinerja dari sistem
dengan memperbaiki desain yang tidak sesuai atau perubahan
kebutuhan. (Thomas Connolly dan Carolyn Begg, 2005:532)
2.2 Teori yang Terkait Tema Penelitian
Dalam tinjauan pustaka yang berhubungan dengan hal-hal khusus tentang topik
skripsi dan alat bantu analisis dan perancangan basis data akan diruaikan secara
ringkas, antara lain : pembayaran, honorarium, pertimbangan pembayaran
honorarium pada PT PLN (Persero) UDIKLAT Jakarta, keputusan pembayaran
honorarium pada PT PLN (Persero) UDIKLAT Jakarta, istilah-istilah ketentuan
umum pada PT PLN (Persero) UDIKLAT Jakarta dan alat bantu(tools) yang
digunakan seperti LAN (Local Area Network), intranet,
protokol, web server,
menjelajah web(web browser), web basis data(database), PHP, MySQL, diagram
aliran data(data flow diagram), dan STD(state transition diagram), JavaScript, CSS
(Cascading Style Sheets), HTML(hypertext markup language), prepared statements.
47
2.2.1 Pengertian Honorarium
Menurut Kamus Besar Bahasa Indonesia (2009:330), Honorarium adalah gaji
atau imbal jasa berupa uang untuk pegawai bukan pegawai negeri (yang bekerja
di suatu instansi atau kedinasan).
KPPN JAKARTA I. 20 September (2008). Daftar Kata dan Istilah (Online),
diakses 1 Desember 2013 dari http://www.kppn-jktsatu.web.id/index.php?pilih
=kamus&aksi=baca&kata=honorarium.
honorarium
diartikan
sebagai
pembayaran atas jasa yang diberikan pada suatu kegiatan tertentu.
2.2.2 Ketentuan Pembayaran Honorarium pada PT PLN (Persero)
UDIKLAT Jakarta
a. bahwa ketentuan pemberian honorarium sebagai penghargaan / kompensasi
atas kegiatan mengajar dan atau setara yang diselenggarakan oleh PT PLN
(Persero) Pusat Pendidikan dan Pelatihan, sudah tidak sesuai dengan
perkembangan lingkungan perusahaan yang wajar, layak, dan memadai,
b. bahwa pemberian penghargaan sebagaimana dimaksud pada huruf a, perlu
dilakukan penyesuaian agar dapat digunakan untuk mengembangkan
kemampuan kompetensi keinstrukturan dan atau peningkatan kompetensi
individu instruktur / penceramah / setara,
c. bahwa dengan mempertimbangkan hal-hal sebagaimana dimaksud pada huruf
a dan b, perlu menetapkan keputusan Kepala PT PLN (Persero) Pusat
Pendidikan dan Pelatihan tentang honorarium bagi tenaga pengajar dan
penyusun materi diklat di lingkungan PT PLN (Persero) Pusat Pendidikan
dan Pelatihan.
2.2.3 Keputusan Pembayaran Honorarium Pada PT PLN (Persero)
UDIKLAT Jakarta
1. Anggaran dasar PT PLN (Persero),
2. Keputusan Direksi PT PLN (Persero) Nomor : 319.K/DIR/2008 tentang
Organisasi PT PLN (Persero) Pusat Pendidikan dan Pelatihan,
3. Keputusan Direksi PT PLN (Persero) Nomor : 017.K/DIR/2010 tentang
Organisasi dan Tata Kerja PT PLN (Persero),
48
4. Keputusan General Manajer PT PLN (Persero) Jasa Pendidikan dan Pelatihan
Nomor: 159 K/PUSDIKLAT/2008 tentang Bagan Susunan Jabatan (BSJ)
pada Organisasi Kantor Induk PT PLN (Persero) Pusat Pendidikan dan
Pelatihan.
2.2.4 Istilah-istilah ketentuan umum pada PT PLN (Persero) UDIKLAT
Jakarta
1. Perseroan adalah PT PLN (Persero) yang didirikan dengan Akte Notaris
Sutjipto, SH No.169 Tahun 1994,
2. Direksi adalah Direksi Perseroan,
3. Pusdiklat adalah PT PLN (Persero) Pusat Pendidikan dan Pelatihan,
4. UDIKLAT adalah PT PLN (Persero) Unit Pendidikan dan Pelatihan,
5. Kepala adalah Kepala PT PLN (Persero) Pusat Pendidikan dan Pelatihan,
6. Diklat Reguler adalah kegiatan pendidikan dan pelatihan yang terjadwal
secara rutin dan materi buku yang telah ditetapkan melalui keputusan
Kepala PT PLN (Persero) Pusdiklat,
7. Pegawai adalah Pegawai Perseroan dan atau Pegawai Anak Perusahaan
Perseroan,
8. workshop/sejenis adalah kegiatan pendidikan dan pelatihan atau bentuk lain
proses belajar mengajar, yang tidak terjadwal rutin atau bersifat insidentil
dan materinya belum/tidak dibakukan d engan keputusan Kepala PLN
Pusdiklat,
9. Instruktur adalah orang yang melaksanakan tugas mengajar pada kegiatan
pendidikan dan pelatihan reguler, baik dengan status Pegawai atau tidak
berstatus Pegawai termasuk Asisten Instruktur,
10. Asisten Instruktur adalah orang yang melakukan proses magang mengajar
untuk menjadi Instruktur dengan pengawasan Instruktur atau orang yang
membantu Instruktur dalam sistem mengajar metoda praktek/sejenis secara
aktif terlibat dalam proses belajar praktek/sejenis,
11. Instruktur Tetap adalah pemangku jabatan fungsional pada Pusdiklat /
UDIKLAT dengan sebutan jabatan Instruktur
12. Instruktur Tidak Tetap adalah orang yang bertugas dalam proses belajar
mengajar dan tidak berstatus sebagai Instruktur Tetap,
49
13. Penceramah adalah seseorang yang ditugaskan memberikan ceramah atau
sebagai narasumber pada kegiatan workshop/sejenis,
14. Mentor adalah aktifitas yang dilakukan oleh Pegawai selaku mentor kepada
Pegawai siswa diklat selama melaksanakan on the job training(OJT) berupa
pengenalan lingkungan kerja, arahan, berbagi pengalaman, memfasilitasi
dan panutan untuk melaksanakan tugas/pekerjaan secara efektif dan efisien,
15. Sertifikat Instruktur adalah sertifikat Instruktur yang diberikan oleh
Pusdiklat setelah diterbitkan keputusan ini,
16. SPPD adalah surat perintah perjalanan dinas.
2.2.5 Pengertian LAN (Local Area Network)
Menurut William dan Sawyer (2007:321), LAN (Local Area Network) atau
jaringan lokal adalah menghubungkan komputer dan piranti dalam cakupan
geografis yang terbatas, misalnya pada satu kantor, satu gedung, atau kumpulan
gedung yang berdekatan.
Menurut Jonathan Lukas (2006:12–130, LAN atau Jaringan area lokal adalah
jaringan yang menyediakan hubungan komunikasi dalam berbagai peralatan,
sehingga peralatan yang ada dalam jaringan mampu memberi dan menerima
informasi dari peralatan lainnya yang ada dalam jaringan tersebut. Konsep
komunikasi pada LAN umumnya mengunakan cara broadcast bukan cara
switch. Dengan teknik brodcast, tidak diperlukan switching node dalam jaringan.
Disemua station akan terdapat transceiver yang melakukan komunikasi ke
media, dimana media dipakai bersama-sama.
2.2.6 Pengertian Jaringan Klien-Server (Client-Server)
Menurut William dan Sawyer (2007:322), Jaringan Klien-Server (Client-Server)
terdiri dari klien (client) yaitu mikrokomputer yang meminta data dan server
yaitu komputer yang menyampaikan data. Pada sebuah LAN client-server,
pengguna mikrokomputer perorangan atau klien berbagi jasa dari komputer
sentral yang disebut server. Dalam hal ini server merupakan jenis server file
sehingga para pengguna bias berbagi file atau program.
50
Gambar 2.3 LAN Klien-Server
2.2.7 Pengertian Intranet
Menurut William dan Sawyer (2007:323), Intranet adalah jaringan pribadi
internal dalam sebuah organisasi yang menggunakan infrastruktur serta standar
internet dan web.
Menurut Indrajani (2011:274), Intranet merupakan suatu situs web atau grup
situs yang dimiliki oleh suatu organisasi, sehingga hanya dapat diakses oleh
anggota-anggota organisasi tersebut. Berada di belakang firewall dan hanya
dapat diakses oleh orang yang merupakan anggota dari organisasi yang sama.
2.2.8 Pengertian Protokol
Menurut William dan Sawyer (2007:324), Protokol adalah sekumpulan konvensi
yang mengatur pertukaran data antar komponen perangkat keras dan atau
perangkat lunak dalam jaringan komunikasi. Setiap peranti yang terhubung ke
jaringan memiliki alamat IP (internet protocol) sehingga komputer lain di
jaringan dapat mengirim data ke alamat tersebut dengan tepat. Peranti pengirim
dan penerima harus mengikuti protokol yang sama.
51
Menurut James F. Kurose dan Keith W. Ross (2003,p8), protokol
mendefinisikan format dan urutan pesan yang dipertukarkan antara dua atau
lebih entitas dalam berkomunikasi, serta mengambil tindakan pada transmisi dan
atau melakukan penerimaan pesan atau kegiatan lainnya.
Menurut Jonathan Lukas (2006:14), Protokol didefinisikan sebagai kumpulan
aturan yang telah diorganisasikan dengan baik agar dua entitas dapat melakukan
pertukaran data dengan kehandalan yang tinggi.
2.2.9 Pengertian Web Server
Menurut James F. Kurose dan Keith W. Ross (2003 ,p90), Web Server adalah
objek web yang masing-masing memiliki alamat dari URL. server web juga
menerapkan sisi server HTTP. Beberapa server web yang populer yaitu Apache
dan Microsoft Internet Information Server. HTTP mendefinisikan bagaimana
web klien (misalnya browser) melakukan request halaman web dari web server
dan bagaimana cara mentransferkan halaman web tersebut ke klien.
2.2.10 Pengertian Menjelajah Web (Web Browser)
Menurut Williams dan Sawyer (2007:64), Menjelajah web (web browser) adalah
perangkat lunak yang memungkinkan anda mencari dan mengakses beragam
komponen web.
Menurut James F. Kurose dan Keith W. Ross (2003:89), browser adalah agen
pengguna untuk web. Web browser dapat menampilkan halaman web yang
diminta dan menyediakan berbagai fitur navigasi dan konfigurasi. web browser
yang juga menerapkan pada sisi klien HTTP.
2.2.11 Pengertian Web Basis Data (Web Database)
Menurut Tirtha Indara Lesmana, Michael Onesimus Sumlang, Haryanto (2013).
Analisa dan Perancangan Sistem Basis Data Pemesanan Makanan dan Minuman
serta Ketersediaan Meja Pada Restoran Raja Kepiting. School of Computer
Science, Teknik Informatika, Universitas Bina Nusantara, Jakarta. “Web
Database System are systems in which both web and database technologies are
used”. Dapat artikan bahwa web database system adalah sistem dimana
52
dipadukannya teknologi web dan basis data (database). Oleh karena itu web
basis data menyediakan akses yang lebih luas ke dalam sistem basis data. Cara
ini digunakan untuk mendistribusikan sistem dan banyak servis melalui sistem
yang terintegrasi.
2.2.12 Pengertian PHP
Menurut Deni Sutaji (2012:2), PHP (PHP Hpertext Preprocessor) adalah kode
atau skrip yang akan dieksekusi pada server-side. Skrip PHP akan membuat
suatu aplikasi dapat diintegrasikan ke dalam HTML, sehingga suatu halaman
web tidak lagi bersifat statis, namun menjadi bersifat dinamis. Sifat server-side
berarti pengerjaan skrip dilakukan di server, baru kemudian hasilnya dikirimkan
ke browser.
Menurut Luke W. dan Laura T. (2008:2), PHP adalah sebuah bahasa skrip dari
sisi server (server-side scripting) yang di rancang khusus untuk web. Pada
halaman HTML, anda bisa menggunakan kode PHP yang akan di eksekusi
setiap kali mengunjungi web. Kode PHP ditafsirkan di web server dan
menghasilkan HTML atau output lain yang pengunjung web akan lihat.
Keunggulan PHP adalah :
 Performa(performance)
 Skalabilitas(scalability)
 Antar muka untuk banyak sistem basis data yang berbeda
 Terpasang library untuk banyak tugas web umum
 Murah
 Mudah dipelajari dan digunakan
 Mendukung penuh terhadap object-oriented
 Portabilitas(portability)
 Fleksibilitas pendekatan perkembangan
 Ketersediaan source code
 Ketersediaan support dan dokumentasi
53
2.2.13 Pengertian MySQL
Menurut Deni Sutaji (2012:40), MySQL adalah DBMS yang di distribusikan
secara gratis dibawah lisensi dari General Public License (GPL), dimana setiap
orang bebas untukmenggunakannya tetapi tidak bolehuntuk dijadikan program
induk turunan bersifat close source (komersial). MySQL sebenarnya merupakan
turunan dari salah satu konsep utama dalam basis data sejak lama, SQL
(Structured Query Language). SQL adalah sebuah konsep pengoprasian basis
data terutama untuk proses seleksi, pemasukan, pengubahan, dan penghapusan
data yang dimungkinkan dapat dikerjakan dengan mudah dan otomatis.
Menurut Luke W. dan Laura T. (2008:3) MySQL (diucapkan My-Ess-Que-Ell)
adalah relational database management system (RDBMS) yang sangat cepat dan
kuat. MySQL server mengontrol akses ke data anda untuk memastikan banyak
user bisa bekerja secara bersamaan, memberikan akses yang cepat, dan
memastikan hanya user yang berwenang dapat mengakses.Oleh karena itu,
MySQL adalah banyak pengguna (multi-user) dan multi-thread server sehingga
dapat digunakan pada server yang memiliki multi-CPU. MySQL menggunakan
SQL (Stuctured Query Language) yang merupakan standar bahasa query basis
data. Keunggulan MySQL adalah :
 Performa tinggi
 Murah
 Terstruktur dan mudah dipelajari
 Portabilitas
 Ketersediaan source code
 Ketersediaan support
2.2.14 Pengertian Diagram Aliran Data (Data Flow Diagram)
Menurut Indrajani (2011:11), Diagram Aliran Data (Data Flow Diagram) adalah
sebuah alat yang menggambarkan aliran data sampai sebuah sistem selesai, dan
kerja atau proses dilakukan dalam sistem tersebut.
54
2.2.14.1 Komponen Utama Diagram Aliran Data (Data Flow Diagram)
Menurut Indrajani (2011:11), Dalam DFD terdapat 4 komponen utama,
yaitu :
1. agen ekternal (external agent)
Agen eksternal mendefinisikan orang atau sebuah unit organisasi,
sistem lain, atau organisasi yang berada diluar sistem proyek tapi
dapat mempengaruhi kerja sistem,
2. proses (process)
proses adalah penyelenggaraan kerja atau jawaban, datangnya aliran
data atau kondisinya,
3. simpanan Data (data store)
data store adalah penyimpanan data
4. arus data (data flow)
arus data mempresentasikan sebuah input data ke dalam sebuah proses
atau output dari data atau informasi pada sebuah proses.
Tabel 2.2 Beberapa komponen DFD
Simbol DeMarco dan
Yourdan
Keterangan
Kesatuan luar
(source)
Proses
(process)
Simbol Gane dan
Sarson
55
Aliran data
(data flow)
Simpanan data
(data store)
2.2.14.2 Jenis-jenis Diagram Aliran Data (Data Flow Diagram)
Jenis-jenis DFD adalah sebagai berikut :
1. level 0 (diagram konteks) merupakan sebuah proses yang berada
diposisi pusat,
2. level 1 (diagram nol) merupakan sebuah proses yang terdapat di level
0 yang dipecahkan menjadi beberapa proses lainnya. Sebaiknya
maksimum 7 proses untuk sebuah diagram konteks,
3. level 2 (diagram rinci)
a. level ini merupakan diagram yang merincikan diagram level 1,
b. tanda * digunakan hanya jika proses tersebut tidak dapat dirincikan
lagi. 2.0* artinya proses level rendah yang tidak dapat dirincikan
lagi,
c. penomoran yang dilakukan berdasarkan urutan proses.
56
Gambar 2.4 Contoh diagram konteks
Dari gambar tersebut terlihat, terdapat 1 proses, 3 entitas, dan 9 aliran data.
Entitas pemasok memiliki 1 aliran masuk dan 2 aliran keluar. Entitas
pelanggan memiliki 2 aliran masuk dan 2 aliran keluar. Entitas manajer
memiliki 4 aliran keluar.
Aliran masuk adalah entitas kedalam sistem, sedangkan aliran keluar
sebaliknya yaitu aliran data dari sistem entitas.
2.2.14.3 Perbandingan Sistem Diagram Alir dengan DFD
Berikut ini merupakan perbandingan Sistem Diagram Alir dengan DFD :
57
Tabel 2.3 Tabel Perbandingan Sistem Aliran Data dengan DFD
Sistem Diagram Alir
DFD
Menekankan pada kata yang spesifik dan
Menunjukkan bagaimana data di proses
apa yang akan dilakukan pada data
dan menjelaskan aspek fisikal yang telah
tersebut. Juga menjelaskan isi aliran data,
pasti.
proses, penyimpanan data, dan sumber
serta tujuan dari data tersebut.
Biasanya digunakan untuk
mendokumentasikan elemen fisikal dari
sistem informasi akuntansi, baik yang
sistem telah ada maupun sistem baru
Lebih cocok digunakan untuk analisis
proses sebuah sistem.
didesain.
Memerlukan notasi yang bervariasi.
Hanya memerlukan 4 notasi.
2.2.15 Pengertian Diagram Keadaan Transisi (State Transition Diagram)
Menurut Indrajani (2011:17), diagram keadaan transisi (state transition
diagram) adalah suatu kondisi yang menunjukkan keadaan tertentu, dimana
suatu sistem dapat ada dan transisi menghasilkan keadaan tertentu yang baru.
Biasanya digunakan dalam sistem yang waktu nyata(real time).
2.2.15.1 Hal-hal yang terdapat dalam STD
Hal-hal yang terdapat dalam STD, antara lain :
1.
keada
an system (system state) adalah setiap empat persegi panjang
menggambarkan satu keadaan sistem dari sistem secara keseluruhan,
2.
keada
an berubah (change of state)
58
3.
kondis
i dan aksi (conditions and actions)
Siaga
Menunggu
panggilan
Rekaman
pesan
Memutar
ulang
Menjawab
panggilan
Gambar 2.5 Contoh DFD
Keadaan 1
Keadaan 2
Keadaan 3
Gambar 2.6 Keadaan Berubah (Change of State)
Memainkan
pesan
59
Keadaan 1
Kondisi
Aksi
Keadaan 2
Gambar 2.7 Kondisi dan Aksi (Conditions and Actions)
2.2.16 Pengertian JavaScript
Menurut Williams dan Lawyer (2007:543), JavaScript adalah bahasa scripting
berorientasi objek yang populer didukung dalam web browser.
Menurut Robin Nixon (2009:7), JavaScript diciptakan untuk memungkinkan
akses scripting untuk semua elemen dari sebuah dokumen HTML.
2.2.17 Pengertian CSS (Cascading Style Sheets)
Menurut Luke W. dan Laura T. (2008:858), CSS (Cascading Style Sheets)
digunakan untuk memperindah tampilan pada halaman aktif statis, dinamis, dan
AJAX. Menggunakan CSS memungkinkan pengembang web (developer) untuk
mengubah definisi tag, class, atau ID dalam satu dokumen (style sheet) dan
seketika akan berubah efek di semua halaman yang terhubung dalam style sheet.
Menurut Roki Aditama (2013:37), CSS (Cascading Style Sheets) merupakan
salah satu bahasa pemrograman web yang bertujuan untuk membuat web kita
menjadi lebih menarik dan terstruktur, dalam CSS kita bisa merubah warna
tabel, besar font, atau tata letak menu yang terkendali dari CSS sehingga semua
jendela web yang berkaitan dengan perubahan tersebut secara otomatis dapat
berubah, dengan CSS kita tidak perlu membuat style pada setiap file PHP,
karena cukup dengan satu file CSS kita telah bisa mengontrol semua style yang
kita inginkan pada setiap file PHP yang akan ditampilkan nanti di browsernya.
2.2.18 Pengertian HTML (Hypertext Markup Language)
Menurut Williams dan Lawyer (2007:67), HTML (hypertext markup language)
adalah sekumpulan perintah khusus disebut tag atau markup yang dipakai untuk
60
menentukan struktur, bentuk, dan link pada dokumen ke dokumen multimedia
lain di web.
Menurut Indrajani (2011:275), HTML (hypertext markup language) merupakan
bahasa standard yang digunakan untuk mendisain hampir seluruh halaman web,
dimana
kita
dapat
mengontrol
tampilan
web
page
dan
kontennya,
mempublikasikan dokumen secara online, membuat form online untuk
pendaftaran atau transaksi, dan menambahkan objek-objek sperti image, audio,
video, dan java applet ke dalam dokumen HTML. HTML adalah aplikasi
Standarized Generalized Markup Language (SGML), yaitu sistem untuk
mendifinisikan tipe dokumen terstruktur dan menetapkan bahasa untuk
merepresentasikan tipe dokumen tersebut.
2.2.19 Prepared Statements
The PHP Group. 5 April (2014). Prepared statements and stored procedures
(Online), diakses 27 Januari 2014 dari id1.php.net/pdo.prepared-statements.
Banyak dari basis data terbaru mendukung konsep prepared statements.
Prepared statements dianggap sebagai semacam template terkompilasi untuk
SQL bahwa aplikasi ingin dijalankan dan dapat disesuaikan dengan
menggunakan parameter variabel. prepared statements menawarkan dua
manfaat utama :
1. Query hanya perlu dipersiapkan sekali, tetapi dapat dijalankan beberapa kali
dengan parameter yang sama atau berbeda.
2. Parameter untuk prepared statements tidak perlu dikutip, driver secara
otomatis menangani ini. Jika sebuah aplikasi eksklusif menggunakan
prepared statements, developer dapat yakin bahwa tidak akan terjadi injeksi
SQL.
2.2.20 Pengertian Interaksi Manusia dan Komputer
Menurut Indrajani (2011:74-75), Interaksi manusia dan komputer adalah disiplin
ilmu yang berhubungan dengan perancangan, evaluasi dan implementasi sistem
komputer interaktif untuk digunakan oleh manusia. Serta studi fenomenafenomena besaryang berhubungan dengannya. Terdapat delapan aturan emas
dalam merancang user interface. Delapan aturan tersebut dapat digunakan dalam
61
sebuah sistem yang interaktif dan membutuhkan sebuah validasi dan pengaturan
untuk sebuah tampilan domain yang spesifik.
Tabel 2.4 Delapan Aturan Emas IMK
Tahapan
1. Berusaha untuk konsistensi
Penjelasan
Konsistensi
dilakukan
pada
urutan
tindakan, perintah, dan istilah yang
digunakan pada prompt, menu, serta
layar
bantuan.
Contohnya
adalah
konsistensi formulir dalam hal alur form,
warna, menu, tampilan, tulisan, dan
masih banyak lagi.
2. Memenuhi kegunaan bersama
Memungkinkan
pengguna
untuk
menggunakan shortcut, ada kebutuhan
dari pengguna yang telah ahli untuk
meningkatkan
kecepatan
interaksi,
sehingga diperlukan singkatan, tombol
fungsi,
perintah
tersembunyi,
dan
fasilitas makro.
3. Memberikan umpan balik yang
Untuk
informatif
sebaiknya disertakan suatu sistem umpan
balik
setiap
untuk
tindakan
tindakan
yang
operator,
sering
dilakukan dan tidak terlalu penting, dapat
diberikan umpan balik yang sederhana.
Tetapi ketika tindakan merupakan hal
62
yang
penting,
maka
umpan
balik
sebaiknya lebih substansial. Misalnya
muncul suatu suara ketika salah menekan
tombol pada waktu input data atau
muncul pesan kesalahannya.
4. Desain dialog untuk menghasilkan
Urutan tindakan sebaiknya diorganisir
penutupan
dalam suatu kelompok dengan bagian
awal, tengah, dan akhir. Umpan balik
yang
informatif
akan
memberikan
indikasi bahwa cara yang dilakukan telah
benar
dan
dapat
mempersiapkan
kelompok tindakan berikutnya.
5. Mencagah kesalahan
Sedapat
mungkin
sehingga
sistem
pengguna
dirancang
tidak
melakukan
kesalahan
kesalahan
terjadi,
dapat
fatal.
Jika
sistem
dapat
mendeteksi kesalahan dengan cepat dan
memberikan mekanisme yang sederhana
dan mudah dipahami untuk penanganan
kesalahan.
6. Memperkenankan pembalikan aksi
Hal ini dapat mengurangi kekhawatiran
yang mudah
pengguna karena pengguna mengetahui
kesalahan
yang
dilakukan
dapat
dibatalkan, sehingga pengguna tidak
takut untuk
mengeksplorasi
pilihan-
pilihan lain yang belum digunakan.
7. Dukungan internal dari tempat kendali
Pengguna
sistem
ingin
dan
menjadi
sistem
akan
pengontrol
merespon
63
tindakan
yang
dilakukan
pengguna,
daripada pengguna merasa bahwa sistem
mengontrol pengguna. Sebaiknya sistem
dirancang sedemikian rupa sehingga
pengguna menjadi inisiator daripada
responden.
8. Mengurangi beban memori jangka
Keterbatasan
ingatan
manusia
pendek
membutuhkan tampilan yang sederhana
atau banyak tampilan halaman yang
sebaiknya disatukan, serta memberikan
cukup waktu pelatihan untuk kode,
mnemonic, dan urutan tindakan.
Namun menurut Shneiderman & Plaisant (2005:74), prinsip-prinsip ini berasal
dari pengalaman dan disempurnakan selama dua dekade, perlu validasi dan
tuning untuk domain desain khusus. Tidak ada daftar seperti ini yang bisa
diselesaikan, tetapi telah diterima dengan baik sebagai pandauan yang berguna
untuk siswa dan desainer, dalam IMK, terdapat 8 aturan emas (Eight Golden
Rules) yang digunakan dalam perancangan antarmuka pemakai, yaitu :
1. Berusaha untuk konsistensi
Mengikuti aturan ini bisa sulit karena banyak bentuk yang harus konsistensi.
Konsistensi dari urutan tindakan harus diperlukan dalam situasi yang sama,
istilah-istilah yang sama harus digunakan di menu, layar bantuan,
konsistensi warna, tampilan, pengkapitalisasian, dan font.
2. Memenuhi kegunaan bersama
Mengetahui kebutuhan yang beragam dari pengguna dan rancangan untuk
yang kelihatan, memfasilitasi perubahan terhadap isi. Perbedaan pemula dan
pakar, tentang usia, dan keragunan teknologi setiap memperkaya spektrum
persyaratan yang memandu dalam perancangan menambahkan fitur untuk
pemula, seperti penjelasan, dan fitur-fitur untuk yang sudah ahli.
64
3. Memberikan umpan balik informatif
Untuk setiap tindakan pengguna, harus ada umpan balik dari sistem. Untuk
tindakan yang sering dan tindakan yang kecil, tanggepannya harus lebih
banyak.
4. Desain dialog untuk menghasilkan penutupan
Urutan-urutan dari tindakan harus terorganisasi kedalam kelompokkelompok dengan awal, pertengahan, dan akhir. Umpan balik yang
informatif pada penyelesaian terhadap sebuah kelompok tindakan
memberikan operator kepuasan dari penyelesaiannya, rasa lega, dan isyarat
untuk bersiap buat kelompok tindakan selanjutnya.
5. Mencegah kesalahan
Sebanyak mungkin merancang sebuah sistem yang pengguna tidak dapat
melakukan kesalahan yang serius. Jika pengguna melakukan kesalahan
antarmuka harus mendeteksi kesalahannya dan menawarkan instruksi yang
simple dan spesifik untuk memperbaiki kesalahan tersebut.
6. Memungkinkan pembalikan aksi yang mudah
Diharapkan adanya fitur untuk kembali (back) ke aktivitas sebelumnya. Hal
ini bertujuan agar user dapat kembali ke aktivitas sebelumnya jika ternyata
user melakukan suatu kesalahan sehinga user dapat memperbaikinya.
7. Dukungan internal dari tempat kendali
Pengurus yang sudah berpengalaman mempunyai keinginan yang kuat
merasakan bahwa mereka bertanggung jawab atas antarmuka dan merespon
tidakan mereka.
8. Mengurangi beban memori jangka pendek
Keterbatasan memproses informasi pada manusia dalam memori jangka
pendek membutuhkan tampilan yang seadanya, menampilkan beberapa
halaman dikonsolidasi, gerakan windows sering dikurangi, wktu pelatihan
yang menandai akan dibagikan untuk kode, yang membantu ingatan, dan
urutan dari tindakan.
2.3 Hasil Penelitian atau Produk Sebelumnya
65
Pada sub bab hasil penelitian atau produk sebelumnya akan dibahas secara ringkas
mengenai berbagai karya tulis atau jurnal yang berkaitan dengan judul diatas.
2.3.1 Aplikasi Penggajian Pegawai Tetap Berbasis Web
APLIKASI PENGGAJIAN PEGAWAI TETAP BERBASIS WEB
(Studi Kasus pada Politeknik Telkom Bandung)
Vicky Andi Arista
Politeknik Telkom
[email protected]
Abstrak
Sistem penggajian merupakan salah satu sistem yang mempunyai peranan cukup
penting dalam suatu perusahaan termasuk pada Politeknik Telkom. Sistem
penggajian menjadi tanggung jawab staf bagian Sumber Daya Manusia pada
Politeknik Telkom dimana fungsi utamanya adalah memberikan kompensasi untuk
pegawai berupa gaji sebagai ganti atas kontribusi mereka terhadap instansi. Staf
SDM harus menghitung gaji pegawai dengan menggunakan Microsoft Office Excel
yang dibedakan berdasarkan data status kepegawaian dan jabatan, dimana hal
tersebut sedikit banyak masih mengalami berbagai macam kendala dalam
pengolahan data. Hal ini menjadikan sistem penggajian perlu didukung dengan
sistem informasi yang baik. Berdasarkan permasalahan diatas, maka dibutuhkan
aplikasi yang bisa mengelola proses penggajian agar bisa membantu staf SDM dalam
proses pengelolaannya. Sistem yang dibuat adalah aplikasi penggajian pegawai tetap
berbasis web yang dibangun dengan menggunakan Framework Symfony dan basis
data MySQL. Proses penggajian ini terbagi atas 2 proses yaitu proses pengelolaan
sistem penggajian dan proses penghitungan pajak penghasilan berdasarkan data gaji
pegawai.
Kata Kunci: aplikasi, penggajian, Framework Symfony, MySQL
66
Pendahuluan
Proses penggajian merupakan salah satu kegiatan yang dilakukan oleh bidang SDM
(Sumber Daya Penggajian didalam suatu perusahaan merupakan salah satu event
yang mempunyai peranan sangat penting. Dalam perkembangan Manusia) pada
Politeknik Telkom Bandung. Pada proses penggajian seperti pengolahan data gaji
masih diolah dengan menggunakan Microsoft Excel. Teknologi informasi zaman
sekarang, telah banyak Proses
pengolahan
penggajian dengan perusahaan yang
melakukan pengolahan data secara terkomputerisasi dalam berbagai hal termasuk
dalam mengolah sistem penggajiannya. Sistem penggajian dalam suatu perusahaan
bertugas mencatat dan memproses data yang digunakan untuk membayar gaji
pegawai atas kontribusi yang mereka berikan terhadap perusahaan.
Politeknik Telkom Bandung berdiri tanggal 27 September 2007 yang diresmikan
oleh Direktur Utama PT. Telekomunikasi Indonesia, Tbk Bapak Rinaldi Firmansyah.
Politeknik Telkom Bandung merupakan suatu institusi pendidikan yang berada
dibawah naungan Yayasan Pendidikan Telkom. menggunakan Microsoft Excel
tersebut sedikit banyak masih mengalami berbagai macam kendala dalam
pengolahan data. Kendala pada proses penggajian adalah ketika proses pencarian
data-data fisik atau apabila terjadi perubahan pada data gaji itu sendiri yang akan
membutuhkan waktu yang cukup lama dalam proses pengolahan datanya.
Proyek akhir ini berkonsentrasi terhadap pembangunan aplikasi penggajian berbasis
web yang berguna untuk membantu bagian SDM pada Politeknik Telkom Bandung
dalam mengolah data- data gaji pegawainya. Berdasarkan latar belakang diatas,
maka penulis tertarik mengambil judul : ”Aplikasi Penggajian Pegawai Tetap
Berbasis Web Pada Politeknik Telkom Bandung”. Aplikasi penggajian pegawai tetap
ini dapat membantu bagian SDM dalam proses perhitungan negara yang terutang
oleh orang pribadi atau badan yang bersifat memaksa berdasarkan Undang-Undang
dengan tidak mendapatkan imbalan secara langsung dan digunakan untuk keperluan
negara bagi sebesar-besarnya kemakmuran rakyat (Pasal 1 angka 1 UU KUP)”.
penggajian pada Politeknik Telkom Bandung Djoko (2010) mengungkapkan
bahwa sehingga dapat menghasilkan suatu menghasilkan suatu laporan penggajian
yang berupa slip gaji, jurnal dan buku besar serta laporan pajak yang berupa SSP dan
67
SPT. Namun aplikasi ini hanya menangani proses penggajian pada pegawai tetap dan
tenaga profesional dan tidak menangani perhitungan gaji dosen LB dan pegawai
tidak tetap dan tidak menangani proses absensi pegawai. Acuan perhitungan pada
proses penggajian ini hanya dilihat dari gaji dasar, data tunjangan dan data potongan
sedangkan untuk
pembuatan laporan gaji berupa daftar gaji dan slip gaji serta
laporan pajak yang berupa SSP dan SPT. Metode yang digunakan untuk
mengerjakan proyek akhir adalah SDLC (Software Development Life Cycle) dengan
menggunakan model Waterfall yang terdiri dari :
akuntansi pajak adalah akuntansi yang ada hubungan dengan pajak yang dalam arti,
”...akuntansi yang berkaitan dengan perhitungan perpajakan dan mengacu pada
perundang-undang perpajakan beserta aturan pelaksanaannya” (p. 1).
peraturan
Ayat jurnal yang dibuat adalah : Pada saat pemotongan pajak atas pembayaran gaji
setiap bulan:
a)
Requirements analysis and definition.
b)
System and software design
c)
Implementation and unit testing
d)
Integration and system testing
e)
Operation and Maintenance
Kesimpulan
Berdasarkan analisis dari pembuatan aplikasi untuk proyek akhir ini maka didapat
beberapa kesimpulan, yaitu dengan adanya aplikasi penggajian pegawai tetap
berbasis web ini maka pengolahan data akan lebih terstruktur dan dapat diakomodir
dengan baik. Selain itu, aplikasi juga mampu membuat laporan pajak penghasilan
pasal 21 kedalam bentuk SSP dan SPT. Aplikasi ini juga sudah dapat diintegrasikan
ke dalam sistem informasi yang ada pada Politeknik Telkom sehingga sedikit
banyak
dapat
penggajian.
Saran
membantu meningkatkan kinerja staf SDM dalam pengelolaan
68
Disarankan dapat menghasilkan suatu laporan pajak yang dapat di export ke dalam
bentuk eSPT.
2.3.2 Sistem Penggajian Berbasis Web di Dircomnet Yogyakarta
SISTEM PENGGAJIAN BERBASIS WEB
DI DIRCOMNET YOGYAKARTA
Taufiq Ismail dan Fuad Thohari
Program Studi Teknik Informatika Fakultas Tekniknologi Industri
Universitas Ahmad Dahlan
Jl. Prof. Soepomo, S.H., Janturan Yogyakarta
Email1): [email protected]
ABSTRAK
Dircomnet Yogyakarta adalah suatu badan usaha yang bergerak di bidang jasa
persewaan akses internet, perawatan komputer, dan pemasangan jaringan internet,
memiliki banyak pegawai yang digaji setiap bulannya. Pimpinan sering menangani
order pekerjaan secara langsung di luar kantor. Masalah timbul ketika pimpinan
membutuhkan laporan penggajian dan memberikan kebijakan penggajian pegawai
ketika di luar kantor. Karyawan ingin mengetahui berapa jumlah gaji beserta
rinciannya. Berdasar persoalan tersebut, perlu dibangun suatu sistem penggajian real
time yang dapat menampilkan laporan penggajian dan memberikan kebijakan
penggajian yang dapat diakses dari manapun, serta rinci gaji karyawan yang akan
diterima. Penelitian meliputi pengumpulan data dengan studi pustaka, wawancara
dan observasi. Kemudian melakukan analisis data, perancangan sistem meliputi
DAD dan ERD, perancangan menu, input dan output, serta perancangan WAP.
Program dibangun dengan sistem operasi Windows XP, Internet Explorer, MySql
front, Dreamweaver MX, Openwave Simulator, Apache, menggunakan bahasa
pemrograman PHP, dan terakhir menguji program dengan metode black box test dan
alpha test. Hasil penelitian ini diperoleh sistem penggajian berbasis web yang dapat
memberikan laporan penggajian kepada pimpinan dimanapun berada, pegawai dapat
mengetahui rinci gaji diteriman, dan mengoreksi kesalahan pembayaran gaji.
Berdasarkan hasil pengujian program, disimpulkan bahwa program dapat berjalan
69
dengan baik dan
diimplementasikan.
sudah
memenuhi
kebutuhan
pemakai
serta
layak
Kata kunci : Internet, penggajian,WAP, web.
Hasil dan Pembahasan
Gambaran sistem pertama dalam bentuk Diagram Arus Data. Ada 4 entitas, yaitu
Keuangan, Manajer, Pegawai dan P. Parkir. Enam proses yang ada dalam sistem
yaitu Kelola Data Induk, Kelola Data Kerja, Kelola Data Lembur, Kelola Nominal
Pembayaran, Kelola Penggajian dan Pembuatan Laporan. Gambar berikut
menunjukkan Diagram Arus Data pada level 1.
70
Gambar 2.8 Diagram Arus Data pada level 1 DIRCOMNET
71
Gambar 2.9 Entity Relatianship Diagram DIRCOMNET
Gambar berikut ini adalah struktur dari menu program. Pertama user masuk dengan
login dan password, kemudian muncul menu Data Pegawai, Data Kerja Pegawai,
Data lembur Pegawai, Data kerja P. Parkir, Data Penggajian. Untuk mengakhiri
program, user harus logout.
72
Gambar 2.10 Perancangan menu program DIRCOMNET
Gambar 2.11 Struktur menu web DIRCOMNET
Simpulan
Hasil penelitian ini adalah diperoleh sistem penggajian berbasis web yang dapat
memberikan laporan penggajian bagi pimpinan dimanapun berada, pegawai dapat
mengetahui jumlah gaji yang akan diterimanya, dan mengoreksi jika terjadi
kesalahan pembayaran gaji. Berdasarkan hasil pengujian program maka dapat
disimpulkan bahwa program ini dapat berjalan dengan baik dan sudah memenuhi
kebutuhan pemakai serta layak diimplementasikan.
73
2.3.3 Aplikasi Penggajian dan Penghitungan Pajak Penghasilan Pasal 21
APLIKASI PENGGAJIAN dan PENGHITUNGAN PAJAK
PENGHASILAN PASAL 21
(Studi Kasus pada Kantor Administrasi Pelabuhan Sunda Kelapa )
Novita Tri Astuti
Assoc.Prof.DR.H.Gustian Djuanda
Magdalena Karismariyanti,ST.MBA.
Program Studi Komputerisasi Akuntansi
Politeknik Telkom Bandung
2011
ABSTRAK
Kantor Administrasi Pelabuhan Sunda Kelapa merupakan Unit Pelaksana Teknik
(UPT) yang berada dibawah dan bertanggung jawab langsung kepada Direktur
Jenderal Perhubungan Laut. Sistem penggajian yang dilakukan bagian keuangan
pada Kantor Administrator Pelabuhan Sunda Kelapa masih menggunakan Microsoft
Excel. Dalam hal ini aplikasi penggajian dan penghitungan PPh 21 dibuat untuk
menghitung gaji dan pajak tiap pegawai. Adapun yang menjadi batasan
permasalahannya adalah menghitung gaji pegawai berdasarkan PP No.11 Tahun
2011 dan menghitung PPh 21 sesuai dengan Undang-Undang Pajak Penghasilan
Nomor 36 Tahun 2008. Aplikasi pengghitungan gaji dan PPh 21 menggunakan
aplikasi berbasis web dengan menggunakan bahasa pemrograman PHP (Hypertext
Preprocessor) dan menggunakan database MySQL. Dalam tahap pembangunan
aplikasi penggajian dan penghitungan PPh 21 dilakukan dengan tahapan perencanaan
kebutuhan, analisis kebutuhan, perancangan, implementasi, dan pengujian terhadap
aplikasi. Aplikasi ini diharapkan dapat memudahkan bagian keuangan Kantor
Administrasi Pelabuhan Sunda Kelapa dalam melakukan penghitungan gaji dan PPh
21 tiap pegawai dan membantu dalam melakukan cetak slip gaji dan cetak surat
pemberitahuan pajak terutang (SPT).
Kata Kunci : Kantor Administrasi Pelabuhan Sunda Kelapa, Aplikasi, PPh 21,
Penggajian.
74
Pendahuluan
Kantor Administrator Pelabuhan Sunda Kelapa merupakan Unit Pelaksana Teknik
(UPT) dilingkungan Direktorat Jenderal Perhubungan Laut yang berada dibawah dan
bertanggung jawab langsung kepada Direktur Jenderal Perhubungan Laut. Kantor
Administrator Pelabuhan Sunda Kelapa sebagai pihak yang berwenang untuk
memotong atau memungut pajak terutang pegawainya, mempunyai kewajiban untuk
menghitung dan melaporkan kewajiban perpajakan pegawainya kepada Kantor
Pelayanan Pajak (KPP) terdekat.
Sistem penggajian yang dilakukan bagian keuangan pada Kantor Administrator
Pelabuhan Sunda Kelapa masih menggunakan Microsoft Excel untuk membantu
menghitung gaji yang
didapat setiap karyawan setiap bulannya, cara ini kurang optimal melihat terdapat 52
pegawai yang terdapat di kantor tersebut. Pegawai di Kantor Administrator
Pelabuhan Sunda Kelapa memperoleh gaji setiap bulan dengan menerima amplop
yang berisi gaji masing-masing pegawai dan tercantum besarnya gaji yang diterima
tanpa ada detail komponen gaji. Proses penghitungan dan pembuatan laporan Surat
Pemberitahuan Pajak Terutang (SPT) PPh 21 yang dilakukan secara manual dengan
melakukan pengecekan ulang pada slip gaji per bulan masing-masing pegawai, hal
ini dapat memakan waktu yang cukup lama dalam mengitung dan melaporkan Pajak
Penghasilan pasal 21. Untuk membantu bagian keuangan pada kantor Administrator
Pelabuhan Sunda Kelapa, maka dibuat aplikasi berbasis Web dengan menggunakan
bahasa pemrograman PHP (Hypertext Preprocessor) untuk melakukan penghitungan
gaji dan PPh 21.
Berdasarkan uraian di atas maka akan dilakukan penelitian dengan judul “Aplikasi
Penggajian dan Penghitungan Pajak Penghasilan Pasal 21 (Studi Kasus pada kantor
Administrator Pelabuhan Sunda Kelapa)”
75
Kesimpulan
Berdasarkan analisis dan implementasi aplikasi, kesimpulan yang dapat diambil dari
uraian dan penjelasan diatas adalah :
a. Aplikasi dapat melakukan pencatatan penggajian pada Kantor Administrator
Pelabuhan Sunda Kelapa dengan terdapatnya histori gaji pada aplikasi untuk
melihat data penggajian pegawai yang sudah dilakukan oleh bagian
keuanagan.
b. Aplikasi dapat mengeluarkan slip gaji dengan komponen komponen gaji yang
diterima masing-masing pegawai tiap bulannya.
c. Aplikasi dapat melakukan penghitungan pajak dan mencetak laporan pajak
penghasilan pasal 21 berupa Surat Pemberitahuan Pajak Terutang (SPT) PPh
21 tiap pegawai pertahun.
Saran
Aplikasi ini dapat dikembangkan dan diimplementasikan pada Kantor Administrator
Pelabuhan Sunda Kelapa karena dapat memudahkan bagian keuangan dalam
melakukan penggajian dan penghitungan PPh 21 untuk tiap pegawai. Saran untuk
pengembangan aplikasi ini ke depannya :
a. Untuk penghitungan PPh 21 dapat dikembangakan dengan disesuaikan pada
masa perolehan penghasilan sehingga tidak terikat selama dua belas bulan
saja.
b. Aplikasi penggajian dapat menangani daftar gaji pokok apabila terjadi
perubahan setiap tahunnya sehingga bagian keuangan tidak perlu update
secara manual.