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 peraturan
perundang-undang perpajakan beserta aturan pelaksanaannya” (p. 1).
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.
